{"id":33075,"date":"2019-10-31T21:50:35","date_gmt":"2019-10-31T18:50:35","guid":{"rendered":"https:\/\/prohoster.info\/blog\/besprostojnaya-migratsiya-rabbitmq-v-kubernetes\/"},"modified":"2019-10-31T21:50:35","modified_gmt":"2019-10-31T18:50:35","slug":"besprostojnaya-migratsiya-rabbitmq-v-kubernetes","status":"publish","type":"post","link":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/besprostojnaya-migratsiya-rabbitmq-v-kubernetes","title":{"rendered":"Udenproblematisk migration af RabbitMQ til Kubernetes","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Udenproblematisk
\n
\nRabbitMQ \u2013 en meddelelsesbroker skrevet i Erlang, der muligg\u00f8r oprettelse af en fejltolerant klynge med fuld datareplication p\u00e5 flere noder, hvor hver node kan h\u00e5ndtere foresp\u00f8rgsler om l\u00e6sning og skrivning. Med mange Kubernetes-klynger i produktion underst\u00f8tter vi et stort antal RabbitMQ-installationer og har m\u00f8dt behovet for at migrere data fra en klynge til en anden uden nedetid.<\/a><\/noindex><\/p>\n

Denne operation var n\u00f8dvendig for os i mindst to tilf\u00e6lde:<\/p>\n

    \n
  1. Overf\u00f8rsel af data fra en RabbitMQ-klynge, der ikke er i Kubernetes, til en ny \u2013 allerede \"kubernetes-eret\" (dvs. fungerende i K8s-pods) \u2013 klynge.<\/li>\n
  2. Migration af RabbitMQ inden for Kubernetes fra et namespace til et andet (for eksempel, hvis konturerne er afgr\u00e6nset af namespaces, s\u00e5 for at flytte infrastrukturen fra \u00e9n kontur til en anden).<\/li>\n<\/ol>\n

    \nDen opskrift, der foresl\u00e5s i artiklen, er rettet mod situationer (men begr\u00e6nses ikke til dem), hvor der er en gammel RabbitMQ-klynge (f.eks. best\u00e5ende af 3 noder), der enten allerede er i K8s eller p\u00e5 nogle gamle servere. Den fungerer med en applikation, der er placeret i Kubernetes (allerede der eller i perspektiv):<\/p>\n

    \"Udenproblematisk
    \n
    \n\u2026 og vi st\u00e5r over for opgaven med at migrere den til en ny produktion i Kubernetes.<\/p>\n

    F\u00f8rst vil den generelle tilgang til selve migrationen blive beskrevet, derefter de tekniske detaljer om dens implementering.<\/p>\n

    Migrationsalgoritmen<\/h2>\n

    \nDet f\u00f8rste, indledende skridt f\u00f8r nogen handlinger \u2013 er at kontrollere, at den gamle RabbitMQ-installation har h\u00f8j tilg\u00e6ngelighed aktiveret (HA<\/a><\/noindex>). \u00c5rsagen er \u00e5benbar \u2013 vi \u00f8nsker jo ikke at miste nogen data. For at foretage denne kontrol kan du g\u00e5 ind i RabbitMQ-administrationspanelet og under fanen Admin \u2192 Policies sikre dig, at v\u00e6rdien er sat til ha-mode: all<\/code>:<\/p>\n

    \"Udenproblematisk
    \n
    \nN\u00e6ste skridt er at oprette en ny RabbitMQ-klynge i Kubernetes-pods (i vores tilf\u00e6lde f.eks. best\u00e5ende af 3 noder, men antallet kan v\u00e6re et andet).<\/p>\n

    Derefter sammenkobler vi den gamle og den nye RabbitMQ-klynge og f\u00e5r en enkelt klynge (best\u00e5ende af 6 noder):<\/p>\n

    \"Udenproblematisk
    \n
    \nProcessen til synkronisering af data mellem de gamle og de nye RabbitMQ-klynger initieres. N\u00e5r alle data er synkroniseret mellem alle noder i klyngen, kan vi skifte applikationen til at bruge den nye klynge:<\/p>\n

    \"Udenproblematisk
    \n
    \nEfter disse operationer er det tilstr\u00e6kkeligt at fjerne de gamle noder fra RabbitMQ-klyngen, og flytningen kan betragtes som afsluttet:<\/p>\n

    \"Udenproblematisk
    \n
    \nDenne ops\u00e6tning har vi gentagne gange anvendt i vores produktion. Men for vores egen bekvemmelighed har vi realiseret den som en specialiseret system, der distribuerer standardkonfigurationer af RMQ p\u00e5 flere Kubernetes-klynger. (til dem, der er nysgerrige: det handler om     addon-operator<\/a><\/noindex>, which we for nylig fortalte vi<\/a><\/noindex>)<\/i>. Nedenfor vil der blive pr\u00e6senteret specielle instruktioner, som enhver kan anvende p\u00e5 deres egne installationer for at pr\u00f8ve den foresl\u00e5ede l\u00f8sning i praksis.<\/p>\n

    Pr\u00f8ver i praksis<\/h2>\n

    <\/p>\n

    Krav<\/h3>\n

    \nKravene er meget enkle:<\/p>\n

      \n
    1. Kubernetes klynge (minikube virker ogs\u00e5);<\/li>\n
    2. RabbitMQ-klyngen (kan b\u00e5de v\u00e6re implementeret p\u00e5 bare metal og oprettet som en almindelig klynge i Kubernetes fra det officielle Helm-diagram).<\/li>\n<\/ol>\n

      \nTil det beskrevne eksempel har jeg implementeret RMQ i Kubernetes og navngivet den rmq-old<\/code>.<\/p>\n

      Forberedelse af testmilj\u00f8et<\/h3>\n

      \n1. Hent Helm-diagrammet og rediger det lidt:<\/p>\n

      helm fetch --untar stable\/rabbitmq-ha<\/code><\/pre>\n
      \nFor nemheds skyld s\u00e6tter vi en adgangskode, ErlangCookie<\/code> og laver en politik ha-all<\/code>, s\u00e5 k\u00f8erne som standard synkroniseres mellem alle noderne i RMQ-klyngen:<\/p>\n
      rabbitmqPassword: guest\nrabbitmqErlangCookie: mae9joopaol7aiVu3eechei2waiGa2we\ndefinitions:\npolicies: |-\n  {\n    \"name\": \"ha-all\",\n    \"pattern\": \".*\",\n    \"vhost\": \"\\\/\",\n    \"definition\": {\n      \"ha-mode\": \"all\",\n      \"ha-sync-mode\": \"automatic\",\n      \"ha-sync-batch-size\": 81920\n    }\n  }<\/code><\/pre>\n
      \n2. Installerer diagrammet:<\/p>\n
      helm install . --name rmq-old --namespace rmq-old<\/code><\/pre>\n
      \n3. G\u00e5 ind i RabbitMQ adminpanelet, opret en ny k\u00f8 og tilf\u00f8j nogle beskeder. De vil v\u00e6re n\u00f8dvendige for at sikre, at alle data er bevaret og intet er g\u00e5et tabt efter migrationen:<\/p>\n
      \"Udenproblematisk
      \n
      \nTestmilj\u00f8et er klar: vi har den 'gamle' RabbitMQ med de data, der skal overf\u00f8res.<\/p>\n
      Migration af RabbitMQ-klynge<\/h3>\n
      \n1. For det f\u00f8rste skal vi implementere en ny RabbitMQ i en anden<\/b> navnerummet med de samme<\/b> ErlangCookie<\/code> og adgangskode for brugeren. For at g\u00f8re dette udf\u00f8rer vi de tidligere n\u00e6vnte operationer og \u00e6ndrer den endelige installationskommando for RMQ til f\u00f8lgende:<\/p>\n
      helm install . --name rmq-new --namespace rmq-new<\/code><\/pre>\n
      \n2. Nu skal den nye klynge sammenf\u00f8jes med den gamle. For at g\u00f8re dette g\u00e5r vi ind i hver af pod'erne ny<\/b> RabbitMQ og udf\u00f8rer kommandoerne:<\/p>\n
      export OLD_RMQ=rabbit@rmq-old-rabbitmq-ha-0.rmq-old-rabbitmq-ha-discovery.rmq-old.svc.cluster.local && \n  rabbitmqctl stop_app && \n  rabbitmqctl join_cluster $OLD_RMQ && \n  rabbitmqctl start_app<\/code><\/pre>\n
      \nI variablen OLD_RMQ<\/code> er adressen p\u00e5 en af noderne i den gamle<\/b> RMQ-klynge.<\/p>\n
      Disse kommandoer stopper den nuv\u00e6rende node ny<\/b> fra RMQ-klyngen, forbinder den til den gamle klynge og starter den igen.<\/p>\n
      3. RMQ-klyngen med 6 noder er klar:<\/p>\n
      \"Udenproblematisk
      \n
      \nDu skal vente, indtil beskederne synkroniseres mellem alle noder. Det er ikke sv\u00e6rt at g\u00e6tte, at synkroniseringstiden for beskeder afh\u00e6nger af hardwarekapaciteten, som klyngen er implementeret p\u00e5, og af antallet af beskeder. I det beskrevne scenarie er der kun 10 beskeder, s\u00e5 dataene blev synkroniseret \u00f8jeblikkeligt, men ved et tilstr\u00e6kkeligt stort antal beskeder kan synkroniseringen tage timer.<\/p>\n
      S\u00e5, synkroniseringsstatus:<\/p>\n
      \"Udenproblematisk
      \n
      \nHer +5<\/code> betyder, at beskederne allerede er endnu<\/b> p\u00e5 5 noder (udover den, der er angivet i feltet Node<\/code>). S\u00e5ledes er synkroniseringen succesfuld.<\/p>\n
      4. Det er kun tilbage at skifte applikationens RMQ-adresse til den nye klynge (de specifikke handlinger her afh\u00e6nger af den teknologi, du bruger, og anden specifik applikationsinformation), hvorefter du kan sige farvel til den gamle.<\/p>\n
      Til den sidste operation (dvs. allerede efter<\/b> skift af applikationen til den nye klynge) g\u00e5r vi ind p\u00e5 hver node i den gamle<\/b> i klyngen og udf\u00f8rer kommandoerne:<\/p>\n
      rabbitmqctl stop_app\nrabbitmqctl reset<\/code><\/pre>\n
      \nKlyngen har \"glemt\" de gamle noder: den gamle RMQ kan slettes, hvormed flytningen er f\u00e6rdig.<\/p>\n
      Bem\u00e6rk<\/b>: Hvis du bruger RMQ med certifikater, \u00e6ndrer det principielt ikke noget - migrationsprocessen vil finde sted p\u00e5 n\u00f8jagtig samme m\u00e5de.<\/i><\/p>\n
      Konklusioner<\/h2>\n
      \nDen beskrevne metode passer stort set til alle tilf\u00e6lde, hvor vi skal overf\u00f8re RabbitMQ eller blot flytte til en ny klynge.<\/p>\n
      I vores tilf\u00e6lde opstod der kun problemer \u00e9n gang, da RMQ blev tilg\u00e5et fra mange steder, og vi ikke havde mulighed for at \u00e6ndre RMQ-adressen overalt til den nye. S\u00e5 lancerede vi den nye RMQ i det samme navnerum med de samme labels for at den kunne falde ind under de eksisterende tjenester og Ingress'er, og ved at starte pod'en manuelt manipulerede vi labels ved at fjerne dem i starten, s\u00e5 der ikke blev sendt foresp\u00f8rgsler til den tomme RMQ, og tilf\u00f8jede dem igen efter synkroniseringen af beskeder.<\/p>\n
      Vi anvendte samme strategi ved opgradering af RabbitMQ til en ny version med \u00e6ndret konfiguration - alt k\u00f8rte som smurt.<\/p>\n
      P.S.<\/h2>\n
      \nSom en logisk forts\u00e6ttelse af dette materiale forbereder vi artikler om MongoDB (migration fra fysisk server til Kubernetes) og MySQL (hvordan vi forbereder denne DBMS inden for Kubernetes). De vil blive offentliggjort i de kommende m\u00e5neder.<\/p>\n
      P.P.S.<\/h2>\n
      \nL\u00e6s ogs\u00e5 p\u00e5 vores blog:<\/p>\n