🥇 A RabbitMQ zökkenőmentes migrációja a Kubernetes

A RabbitMQ egy Erlang nyelven írt üzenetközvetítő, amely lehetővé teszi egy feladatátvételi fürt megszervezését teljes adatreplikációval több csomóponton keresztül, ahol minden csomópont kiszolgálhatja az olvasási és írási kéréseket. Mivel számos Kubernetes-fürt üzemel, nagyszámú RabbitMQ-telepítést támogatunk, és szembesültünk azzal, hogy az adatokat egyik fürtből a másikba kell áttelepíteni leállás nélkül.

Erre a műveletre legalább két esetben volt szükségünk:

Adatok átvitele egy nem Kubernetesben található RabbitMQ-fürtből egy új – már „kubernetezett” (vagyis K8s podokban működő) – fürtbe.
A RabbitMQ áttelepítése a Kubernetesen belül az egyik névtérből a másikba (például ha az áramköröket névterek határolják el, akkor az infrastruktúra egyik áramkörről a másikra történő átviteléhez).

A cikkben javasolt recept azokra a helyzetekre összpontosít (de egyáltalán nem korlátozódik rájuk), amikor van egy régi RabbitMQ-fürt (például 3 csomópontból), amely már a K8-ban vagy néhány régi szerveren található. Egy Kubernetesen tárolt alkalmazás (már ott vagy a jövőben) működik vele:

... és azzal a feladattal állunk szemben, hogy költöztessük át a kubernetesi új produkcióba.

Először magának a migrációnak az általános megközelítését ismertetjük, majd ezt követően a megvalósítás technikai részleteit.

Migrációs algoritmus

Az első, előzetes lépés minden művelet előtt annak ellenőrzése, hogy a magas rendelkezésre állási mód engedélyezve van-e a régi RabbitMQ telepítésben (HA). Az ok nyilvánvaló – nem akarunk semmilyen adatot elveszíteni. Az ellenőrzés végrehajtásához lépjen a RabbitMQ adminisztrációs panelre, és az Adminisztrálás → Irányelvek lapon ellenőrizze, hogy az érték be van-e állítva. ha-mode: all:

A következő lépés egy új RabbitMQ klaszter felállítása Kubernetes podokban (esetünkben például 3 csomópontból áll, de ezek száma eltérő lehet).

Ezt követően egyesítjük a régi és az új RabbitMQ klasztereket, így egyetlen klasztert kapunk (6 csomópontból):

Megkezdődik az adatszinkronizálás folyamata a régi és az új RabbitMQ-fürtök között. Miután az összes adatot szinkronizálta a fürt összes csomópontja között, átkapcsolhatjuk az alkalmazást az új fürt használatára:

Ezen műveletek után elegendő eltávolítani a régi csomópontokat a RabbitMQ fürtből, és az áthelyezés befejezettnek tekinthető:

Ezt a sémát sokszor alkalmaztuk a gyártás során. A saját kényelmünk érdekében azonban egy speciális rendszerben implementáltuk, amely a szabványos RMQ konfigurációkat osztja el több Kubernetes-fürt között. (Kíváncsiknak: arról beszélünk addon-operátoramiről mi nemrég mondták el). Az alábbiakban bemutatunk egyedi utasításokat, amelyeket bárki alkalmazhat a telepítései során, hogy kipróbálhassa a javasolt megoldást.

Próbáljuk ki a gyakorlatban

Követelmények

A részletek nagyon egyszerűek:

Kubernetes klaszter (a minikube is működni fog);
RabbitMQ-fürt (csupasz fémre telepíthető, és úgy készíthető, mint egy szokásos fürt a Kubernetesben a hivatalos Helm-diagram alapján).

Az alábbi példában az RMQ-t telepítettem a Kubernetesre, és meghívtam rmq-old.

Állvány előkészítés

1. Töltse le a Helm diagramot, és szerkessze egy kicsit:

helm fetch --untar stable/rabbitmq-ha

A kényelem kedvéért beállítunk egy jelszót, ErlangCookie és politikát csinálni ha-allígy alapértelmezés szerint a sorok szinkronizálva vannak az RMQ-fürt összes csomópontja között:

rabbitmqPassword: guest
rabbitmqErlangCookie: mae9joopaol7aiVu3eechei2waiGa2we
definitions:
policies: |-
  {
    "name": "ha-all",
    "pattern": ".*",
    "vhost": "/",
    "definition": {
      "ha-mode": "all",
      "ha-sync-mode": "automatic",
      "ha-sync-batch-size": 81920
    }
  }

2. Telepítse a diagramot:

helm install . --name rmq-old --namespace rmq-old

3. Lépjen a RabbitMQ adminisztrációs panelre, hozzon létre egy új sort, és adjon hozzá több üzenetet. Ezekre azért lesz szükség, hogy a migráció után megbizonyosodjunk arról, hogy minden adat megőrződik, és nem vesztettünk el semmit:

A tesztpad készen áll: megvan a „régi” RabbitMQ adatátvitelre szoruló adatokkal.

RabbitMQ-fürt áttelepítése

1. Először is telepítsük az új RabbitMQ-t más névtér -val azonos ErlangCookie és jelszót a felhasználó számára. Ehhez a fent leírt műveleteket hajtjuk végre, módosítva az RMQ telepítésének utolsó parancsát a következőre:

helm install . --name rmq-new --namespace rmq-new

2. Most össze kell olvasztani az új fürtöt a régivel. Ehhez lépjen az egyes hüvelyekhez új RabbitMQ, és hajtsa végre a parancsokat:

export OLD_RMQ=rabbit@rmq-old-rabbitmq-ha-0.rmq-old-rabbitmq-ha-discovery.rmq-old.svc.cluster.local && 
  rabbitmqctl stop_app && 
  rabbitmqctl join_cluster $OLD_RMQ && 
  rabbitmqctl start_app

Változóban OLD_RMQ az egyik csomópont címe megtalálható régi RMQ-fürt.

Ezek a parancsok leállítják az aktuális csomópontot új RMQ-fürt, csatolja a régi fürthöz, és indítsa újra.

3. A 6 csomópontból álló RMQ-fürt készen áll:

Várnia kell, amíg az üzenetek szinkronizálódnak az összes csomópont között. Nem nehéz kitalálni, hogy az üzenetszinkronizálási idő a fürtöt telepítő hardver kapacitásától és az üzenetek számától függ. A leírt forgatókönyvben csak 10 darab van, így az adatok azonnal szinkronizálva lettek, de kellően nagy számú üzenet esetén a szinkronizálás órákig is eltarthat.

Tehát a szinkronizálás állapota:

Itt +5 azt jelenti, hogy az üzenetek már megérkeztek több 5 csomóponton (kivéve a mezőben feltüntetetteket Node). Így a szinkronizálás sikeres volt.

4. Már csak az alkalmazásban lévő RMQ címet kell átkapcsolni az új fürtre (a konkrét műveletek itt a használt technológiai veremtől és az alkalmazás egyéb jellemzőitől függenek), ami után búcsút mondhat a réginek.

Az utolsó műveletre (azaz már után az alkalmazás új fürtre váltása) menjen az egyes csomópontokhoz régi fürt, és hajtsa végre a parancsokat:

rabbitmqctl stop_app
rabbitmqctl reset

A klaszter „elfelejtette” a régi csomópontokat: törölheti a régi RMQ-t, ekkor az áthelyezés befejeződik.

Megjegyzés: Ha az RMQ-t tanúsítványokkal használja, akkor semmi alapvetően nem változik - az áthelyezési folyamat pontosan ugyanúgy történik.

Álláspontja

A leírt séma szinte minden olyan esetre alkalmas, amikor a RabbitMQ-t migrálnunk kell, vagy egyszerűen át kell lépnünk egy új fürtbe.

Esetünkben csak egyszer adódtak nehézségek, amikor az RMQ-hoz sok helyről hozzáfértek, és nem volt lehetőségünk mindenhol újra cserélni az RMQ címet. Ezután elindítottunk egy új RMQ-t ugyanabban a névtérben, ugyanazokkal a címkékkel, hogy a meglévő szolgáltatások és Ingresses alá kerüljön, és a pod indításakor kézzel manipuláltuk a címkéket, és az elején eltávolítottuk őket, hogy a kérések ne essenek a üres RMQ-t, és visszaadja őket az üzenetek szinkronizálása után.

Ugyanezt a stratégiát alkalmaztuk, amikor a RabbitMQ-t egy új verzióra frissítettük, megváltozott konfigurációval – minden úgy működött, mint egy óra.

PS

Ennek az anyagnak logikus folytatásaként cikkeket készítünk a MongoDB-ről (migráció hardverkiszolgálóról a Kubernetesre) és a MySQL-ről (hogyan készítjük elő ezt a DBMS-t a Kubernetesen belül). A következő hónapokban fognak megjelenni.

PPS

Olvassa el blogunkon is:

Forrás: will.com

A RabbitMQ zökkenőmentes áttelepítése Kubernetesre