{"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\/et\/blog\/administrirovanie\/besprostojnaya-migratsiya-rabbitmq-v-kubernetes","title":{"rendered":"Ainulaadne RabbitMQ migreerimine Kubernetesesse","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Ainulaadne
\n
\nRabbitMQ \u2013 Erlang keeles kirjutatud s\u00f5numite vahetaja, mis v\u00f5imaldab luua usaldusv\u00e4\u00e4rse klastriga, millel on t\u00e4ielik andmete replikatsioon mitmel s\u00f5lmel, kus iga s\u00f5lm suudab teenindada lugemis- ja kirjutamissoove. Tootmiskeskkonnas oleme haldanud mitmeid Kubernetes klastri, mis t\u00e4hendab, et toetame suurt hulka RabbitMQ paigaldusi ning oleme silmitsi seisnud vajadusega migratsioonida andmeid \u00fchest klastrist teise katkestusteta.<\/a><\/noindex><\/p>\n

See operatsioon oli vajalik meile v\u00e4hemalt kahes olukorras:<\/p>\n

    \n
  1. Andmete edastamine RabbitMQ klastrist, mis ei asunud Kuberneteses, uude \u2013 n\u00fc\u00fcd juba \"kuberiseeritud\" (st K8s pod'ides t\u00f6\u00f6tav) \u2013 klastrisse.<\/li>\n
  2. RabbitMQ migratsioon Kuberneteses \u00fche nimeduse alt teise (n\u00e4iteks kui piirid on jaotatud nimede j\u00e4rgi, siis infrastruktuuri edastamiseks \u00fchest piirist teise).<\/li>\n<\/ol>\n

    \nArtiklis pakutud retsept on suunatud olukordadele (aga mitte ainult nendele), kus on olemas vana RabbitMQ klaster (n\u00e4iteks 3 s\u00f5lmega), mis asub kas juba K8s-is v\u00f5i mingitel vanadel serveritel. Sellega t\u00f6\u00f6tatakse rakendusega, mis on paigutatud Kubernetesesse (kas juba seal v\u00f5i tulevikus):<\/p>\n

    \"Ainulaadne
    \n
    \n\u2026 ja meie ees on \u00fclesanne migratsiooni tegemiseks uude production keskkonda Kubernetes'is.<\/p>\n

    Esmalt kirjeldatakse \u00fcldiselt migratsiooni l\u00e4henemist, seej\u00e4rel jagatakse tehnilisi detaile selle rakendamise kohta.<\/p>\n

    Migratsioonialgoritm<\/h2>\n

    \nEsimene, etapp enne mis tahes toimingute tegemist \u2014 kontrollida, et vana RabbitMQ installatsioonis on sisse l\u00fclitatud k\u00f5rge k\u00e4ttesaadavuse re\u017eiim (HA<\/a><\/noindex>). P\u00f5hjus on ilmne \u2014 me ei taha ju andmeid kaotada. Selle kontrollimiseks saab minna RabbitMQ adminpaneelile ja vahekaardil Admin \u2192 Policies veenduda, et v\u00e4\u00e4rtus on seadistatud ha-mode: all<\/code>:<\/p>\n

    \"Ainulaadne
    \n
    \nJ\u00e4rgmine samm \u2014 t\u00f5stame \u00fcles uue RabbitMQ klastrite Kubernetes'i pod'id (meie puhul n\u00e4iteks koosnedes 3 s\u00f5lmest, kuid nende arv v\u00f5ib olla ka erinev).<\/p>\n

    P\u00e4rast seda \u00fchendame vana ja uue RabbitMQ klastri, saades \u00fche klastrina (6 s\u00f5lmega):<\/p>\n

    \"Ainulaadne
    \n
    \nAlgatatakse andmete s\u00fcnkroonimise protsess vana ja uue RabbitMQ klastri vahel. P\u00e4rast seda, kui k\u00f5ik andmed on k\u00f5igi s\u00f5lmede vahel klastris s\u00fcnkroonitud, saame rakenduse suunata uue klastri kasutamisele:<\/p>\n

    \"Ainulaadne
    \n
    \nP\u00e4rast neid toiminguid piisab, kui eemaldada RabbitMQ klastrist vanad s\u00f5lmed, ja migratsioon on l\u00f5petatud:<\/p>\n

    \"Ainulaadne
    \n
    \nMe oleme seda skeemi korduvalt kasutanud oma tootmises. K\u00fcll aga oleme enda mugavuse huvides realiseerinud selle spetsialiseeritud s\u00fcsteemi raames, mis jagab t\u00fc\u00fcpilisi RMQ konfiguratsioone paljude Kubernetes klastrite vahel. (neile, keda huvitab: on juttu     addon-operator<\/a><\/noindex>, millest me just hiljuti r\u00e4\u00e4kisime<\/a><\/noindex>)<\/i>. Allpool on esitatud eraldi juhised, mida iga\u00fcks saab oma installatsioonides rakendada, et proovida ettepanekut praktikas.<\/p>\n

    Proovime praktikas<\/h2>\n

    <\/p>\n

    N\u00f5uded<\/h3>\n

    \nAndmed on v\u00e4ga lihtsad:<\/p>\n

      \n
    1. Kubernetes klaster (sobib ka minikube);<\/li>\n
    2. RabbitMQ klaster (see v\u00f5ib olla \u00fcles seatud nii bare metalil kui ka tavalisena Kubernetesis ametlikust Helm-chart'ist).<\/li>\n<\/ol>\n

      \nAllpool kirjeldatud n\u00e4ite jaoks olen ma seadistanud RMQ Kubernetesis ja kutsunud seda rmq-old<\/code>.<\/p>\n

      Stendi ettevalmistamine<\/h3>\n

      \n1. Lae alla Helm-chart ja tee sellest veidi muudatusi:<\/p>\n

      helm fetch --untar stable\/rabbitmq-ha<\/code><\/pre>\n
      \nMugavuse m\u00f5ttes seadistame parooli, ErlangCookie<\/code> ja teeme poliitika ha-all<\/code>, et vaikimisi oleksid j\u00e4rjekorrad s\u00fcnkroonitud k\u00f5igi RMQ klastriga seotud s\u00f5lmede vahel:<\/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. Seame diagramm:<\/p>\n
      helm install . --name rmq-old --namespace rmq-old<\/code><\/pre>\n
      \n3. Logi RabbitMQ admin paneeli, loo uus j\u00e4rjekord ja lisa m\u00f5ned s\u00f5numid. Neid on vaja, et p\u00e4rast migreerimist saaksime veenduda, et k\u00f5ik andmed on alles ja me midagi ei kaotanud:<\/p>\n
      \"Ainulaadne
      \n
      \nTestkeskkond on valmis: meil on \"vana\" RabbitMQ andmetega, mis tuleb \u00fcle kanda.<\/p>\n
      RabbitMQ klastrite migreerimine<\/h3>\n
      \n1. Alustame uue RabbitMQ k\u00e4ivitamisega s\u00f5braga<\/b> nimede ruumis samade<\/b> ErlangCookie<\/code> ja kasutaja parooliga. Selleks teeme \u00fclaltoodud operatsioonid, muutes RMQ installimise l\u00f5ppk\u00e4sku j\u00e4rgmisega:<\/p>\n
      helm install . --name rmq-new --namespace rmq-new<\/code><\/pre>\n
      \n2. N\u00fc\u00fcd tuleb \u00fchendada uus klaster vanaga. Selleks logime iga podi uue<\/b> RabbitMQ sisse ja t\u00e4idame j\u00e4rgmised k\u00e4sklused:<\/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
      \nMuutujas OLD_RMQ<\/code> on \u00fche vana RMQ klastrite s\u00f5lme aadress.<\/b> Need k\u00e4sklused peatavad praeguse<\/p>\n
      RMQ klastris s\u00f5lme, liidavad selle vana klastriga ja k\u00e4ivitavad uuesti. uue<\/b> 3. RMQ klaster, mis koosneb 6 s\u00f5lmest, on valmis:<\/p>\n
      3. \u041a\u043b\u0430\u0441\u0442\u0435\u0440 RMQ \u0438\u0437 6 \u0443\u0437\u043b\u043e\u0432 \u0433\u043e\u0442\u043e\u0432:<\/p>\n
      \"Ainulaadne
      \n
      \nPeab ootama, kuni s\u00f5numid s\u00fcnkroniseeritakse k\u00f5igi s\u00f5lmpunktide vahel. Pole raske arvata, et s\u00f5numite s\u00fcnkroniseerimise aeg s\u00f5ltub riistvara v\u00f5imsusest, millel klaster on rajatud, ja s\u00f5numite arvust. Kirjeldatud stsenaariumi puhul on neid vaid 10, seega andmed s\u00fcnkroniseerusid kohe, kuid piisavalt suurte s\u00f5numite arvu korral v\u00f5ib s\u00fcnkroniseerimine kesta tunde.<\/p>\n
      Nii et s\u00fcnkroniseerimise staatus:<\/p>\n
      \"Ainulaadne
      \n
      \nSiit +5<\/code> t\u00e4hendab, et s\u00f5numid on juba veel<\/b> 5 s\u00f5lmpunktis (v\u00e4lja arvatud see, mis on n\u00e4idatud v\u00e4ljal S\u00f5lm<\/code>). Seega on s\u00fcnkroniseerimine \u00f5nnestunud.<\/p>\n
      4. J\u00e4\u00e4b vaid rakenduses RMQ aadress uuele klastrile \u00fcle l\u00fclitada (konkreetsed toimingud s\u00f5ltuvad siin teie kasutatavast tehnoloogiamaastikust ja rakenduse muudest erip\u00e4radest), p\u00e4rast mida saab vanast lahkuda.<\/p>\n
      Viimase operatsiooni jaoks (st p\u00e4rast<\/b> rakenduse uuele klastrile \u00fcleminek) siseneme iga s\u00f5lmpunkti RMQ klastrite s\u00f5lme aadress.<\/b> klastris ja t\u00e4idame k\u00e4sklused:<\/p>\n
      rabbitmqctl stop_app\nrabbitmqctl reset<\/code><\/pre>\n
      \nKlaster on \"unustanud\" vanad s\u00f5lmed: vana RMQ v\u00f5ib eemaldada, millega kolimine on l\u00f5petatud.<\/p>\n
      M\u00e4rkus<\/b>: Kui kasutate RMQ-d koos sertifikaatidega, ei muutu p\u00f5him\u00f5tteliselt midagi \u2014 migratsiooniprotsess toimub t\u00e4pselt nii nagu tavaliselt.<\/i><\/p>\n
      J\u00e4reldused<\/h2>\n
      \nKirjeldatud skeem sobib peaaegu k\u00f5ikidele juhtumitele, kus peame RabbitMQ-d migreerima v\u00f5i lihtsalt uude klastrisse liikuma.<\/p>\n
      Meie juhul tekkis probleeme ainult \u00fcks kord, kui RMQ-le p\u00f6\u00f6rduti paljusid kohti, kuid meil ei olnud v\u00f5imalust adresseerida RMQ-d k\u00f5ikjal. Sel juhul k\u00e4ivitasime uue RMQ sama nimelises ruumis sama etikettidega, et see satuks juba olemasolevate teenuste ja Ingress\u2019ite alla ning pod\u2019i k\u00e4sitsi k\u00e4ivitamisel manipuleerisime etiketiga, eemaldades need alguses, et t\u00fchja RMQ-le ei satuks p\u00e4ringud, ja lisades need tagasi p\u00e4rast s\u00f5numite s\u00fcnkroneerimist.<\/p>\n
      Sama strateegiat rakendasime RabbitMQ uuendamisel uue versiooniga, millel oli muudetud konfiguratsioon \u2014 k\u00f5ik toimis nagu kellav\u00e4rk.<\/p>\n
      P.S.<\/h2>\n
      \nSelle materjali loogilise j\u00e4tkuna valmistame ette artikleid MongoDB (migreerimine rauaserverist Kubernetesesse) ja MySQL (kuidas valmistame ette seda andmebaasi Kuberneteses). Need avaldatakse l\u00e4hikuudel.<\/p>\n
      P.P.S.<\/h2>\n
      \nLugege ka meie blogist:<\/p>\n