{"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":"Kompleksne RabbitMQ migratsioon Kubernetesesse","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Kompleksne
\n
\nRabbitMQ on Erlangi kirjutatud s\u00f5numibroker, mis v\u00f5imaldab organiseerida talitlush\u00e4ireteta klastrit t\u00e4ieliku andmete replikatsiooniga mitmele s\u00f5lmele, kus iga s\u00f5lm suudab teenindada lugemis- ja kirjutamissoove. Olles tootes mitmeid Kubernetes klastri, toetame suurt hulka RabbitMQ paigaldisi ja seisime silmitsi vajadusega migreerida andmed \u00fchest klastrist teise ilma seiskumiseta.<\/a><\/noindex><\/p>\n

See operatsioon oli vajalik meile v\u00e4hemalt kahe juhtumi puhul:<\/p>\n

    \n
  1. Andmete \u00fcleviimine RabbitMQ klastrist, mis ei asu Kuberneteses, uude - juba \u201ekuberneeritud\u201c (st toimiv K8s pod'ides) - klastrisse.<\/li>\n
  2. RabbitMQ migratsioon Kuberneteses \u00fche nimede ruumist teise (n\u00e4iteks, kui piirid on jagatud nimede ruumide kaudu, siis infrastruktuuri \u00fcleviimiseks \u00fchest piirist teise).<\/li>\n<\/ol>\n

    \nArtiklis pakutud retsept on suunatud olukordadele (aga mitte ainult neile), kus on vana RabbitMQ klaster (n\u00e4iteks koosneb 3 s\u00f5lmest), mis asub kas K8s-is v\u00f5i m\u00f5nel vanemal serveril. Selle kallal t\u00f6\u00f6tab rakendus, mis on paigutatud Kubernetesesse (kas juba seal v\u00f5i perspektiivis):<\/p>\n

    \"Kompleksne
    \n
    \n\u2026 ja meie ees on \u00fclesanne migreerida see uude produktsiooni Kubernetesesse.<\/p>\n

    Esiteks kirjeldatakse \u00fcldist l\u00e4henemist migreerimisele, seej\u00e4rel tehnilisi \u00fcksikasju selle rakendamisest.<\/p>\n

    Migreerimise algoritm<\/h2>\n

    \nEsimene, eelnev etapp enne igasuguseid tegevusi - kontrollimine, et vanas RabbitMQ paigalduses on aktiveeritud k\u00f5rge saadavuse re\u017eiim (HA<\/a><\/noindex>). P\u00f5hjus on ilmne - me ei soovi kaotada andmeid. Selle kontrollimiseks saab siseneda RabbitMQ administraatori paneeli ja vahekaardil Admin \u2192 Policies veenduda, et v\u00e4\u00e4rtus on seatud ha-mode: all<\/code>:<\/p>\n

    \"Kompleksne
    \n
    \nJ\u00e4rgmine samm - t\u00f5stame \u00fcles uue RabbitMQ klastris pod'ides Kuberneteses (n\u00e4iteks koosnedes 3 s\u00f5lmest, kuid neid v\u00f5ib olla ka teisi).<\/p>\n

    P\u00e4rast seda \u00fchendame vana ja uue RabbitMQ klastrid, saades \u00fche klastrisse (6 s\u00f5lme):<\/p>\n

    \"Kompleksne
    \n
    \nAlgatatakse andmete s\u00fcnkroonimise protsess vana ja uue RabbitMQ klastrite vahel. P\u00e4rast seda, kui k\u00f5ik andmed s\u00fcnkroniseeritakse nii, et k\u00f5ik s\u00f5lmed klastris, saame rakenduse suunata kasutama uut klastrit:<\/p>\n

    \"Kompleksne
    \n
    \nP\u00e4rast neid toiminguid piisab, kui v\u00f5tta RabbitMQ klastri vanad s\u00f5lmed v\u00e4lja ja kolimine v\u00f5ib lugeda l\u00f5petatuks:<\/p>\n

    \"Kompleksne
    \n
    \nSeda me oleme korduvalt kasutanud meie tootmises. Kuid enda mugavuse huvides rakendasime selle spetsialiseeritud s\u00fcsteemi raames, mis levitab t\u00fc\u00fcpilisi RMQ konfiguratsioone paljudele Kubernetes klastritele. (neile, kellel on huvi: r\u00e4\u00e4gime     addon-operator<\/a><\/noindex>, millest me hiljuti r\u00e4\u00e4kisime.<\/a><\/noindex>)<\/i>Allpool on esitatud eraldi juhised, mida iga\u00fcks saab rakendada oma paigaldustes, et proovida pakutavat lahendust praktikas.<\/p>\n

    Proovime praktikas<\/h2>\n

    <\/p>\n

    N\u00f5uded<\/h3>\n

    \nN\u00f5uded on v\u00e4ga lihtsad:<\/p>\n

      \n
    1. Kubernetes klaster (sobib ka minikube);<\/li>\n
    2. RabbitMQ klaster (v\u00f5ib olla paigaldatud bare metal'i peale v\u00f5i loodud tavaliseks klastri Kubernetes'is ametlikust Helm-keskkonnast).<\/li>\n<\/ol>\n

      \nAllpool kirjeldatud n\u00e4ite jaoks paigaldasin RMQ Kubernetes'is ja nimetasime selle rmq-old<\/code>.<\/p>\n

      Stendi ettevalmistamine<\/h3>\n

      \n1. Laadime alla Helm-chart'i ja redigeerime seda veidi:<\/p>\n

      helm fetch --untar stable\/rabbitmq-ha<\/code><\/pre>\n
      \nMugavuse huvides m\u00e4\u00e4rame parooli, ErlangCookie<\/code> ja loome poliitika ha-all<\/code>, et vaikimisi j\u00e4rjekorrad s\u00fcnkroniseeritakse k\u00f5igi RMQ klastri 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. Paigaldame chart'i:<\/p>\n
      helm install . --name rmq-old --namespace rmq-old<\/code><\/pre>\n
      \n3. Siseneme RabbitMQ halduss\u00fcsteemi, loome uue j\u00e4rjekorra ja lisame paar s\u00f5numit. Need on vajalikud, et p\u00e4rast migratsiooni saaksime veenduda, et k\u00f5ik andmed on s\u00e4ilinud ja me ei ole midagi kaotanud:<\/p>\n
      \"Kompleksne
      \n
      \nTeststend on valmis: meil on \u00abvana\u00bb RabbitMQ andmetega, mis tuleb \u00fcle kanda.<\/p>\n
      RabbitMQ klastrite migratsioon<\/h3>\n
      \n1. Esiteks paigaldame uue RabbitMQ teises<\/b> nimetuses sama ja parooliga kasutajale. Selleks teeme \u00fclaltoodud toimingud, muutes RMQ paigaldamise l\u00f5ppk\u00e4sku j\u00e4rgmisele:<\/b> ErlangCookie<\/code> helm install . --name rmq-new --namespace rmq-new<\/p>\n
      2. N\u00fc\u00fcd tuleb \u00fchendada uus klaster vanaga. Selleks siseneme igasse pod'i<\/code><\/pre>\n
      \nuue RabbitMQ ja t\u00e4idame k\u00e4sud:<\/b> 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<\/p>\n
      OLD_RMQ<\/code><\/pre>\n
      \nMu variables on \u00fche vana<\/code> RMQ klastris oleva s\u00f5lme aadress. Need k\u00e4sud peatavad praeguse s\u00f5lme<\/b> RMQ klastri, \u00fchendavad selle vanasse klastrisse ja k\u00e4ivitavad uuesti.<\/p>\n
      3. RMQ klaster, kus on 6 s\u00f5lme, on valmis: RabbitMQ ja t\u00e4idame k\u00e4sud:<\/b> RMQ klaster, liidetakse vanale klasterile ja k\u00e4ivitatakse uuesti.<\/p>\n
      3. RMQ klaster koosneb 6 s\u00f5lmest ja on valmis:<\/p>\n
      \"Kompleksne
      \n
      \nPeate ootama, kuni s\u00f5numid s\u00fcnkroonitakse k\u00f5igi s\u00f5lmede vahel. Ei ole raske arvata, et s\u00f5numite s\u00fcnkroonimise aeg s\u00f5ltub klastrit k\u00e4itavast riistvarast ja s\u00f5numite arvust. Kirjeldatud stsenaariumis on neid ainult 10, seega andmed s\u00fcnkrooniti hetkega, kuid piisavalt suures s\u00f5numite arvus v\u00f5ib s\u00fcnkroonimine kesta tunde.<\/p>\n
      Nii et, s\u00fcnkroonimise staatus:<\/p>\n
      \"Kompleksne
      \n
      \nSiin +5<\/code> t\u00e4hendab, et s\u00f5numid on juba veel<\/b> 5 s\u00f5lmes (lisaks sellele, mis on m\u00e4rgitud v\u00e4ljale Node<\/code>). Nii et, s\u00fcnkroonimine l\u00e4ks edukalt l\u00e4bi.<\/p>\n
      4. J\u00e4\u00e4b vaid rakenduses RMQ aadress vahetada uuele klastrile (konkreetsed tegevused s\u00f5ltuvad teie kasutatavast tehnoloogiapaagist ja muudest rakenduse erip\u00e4radest), p\u00e4rast mida saab vanaga h\u00fcvasti j\u00e4tta.<\/p>\n
      Viimase toimingu jaoks (st p\u00e4rast<\/b> rakenduse m\u00f5nel uuele klastrile \u00fcleviimine) siseneme iga s\u00f5lme Need k\u00e4sud peatavad praeguse s\u00f5lme<\/b> klastris ja t\u00e4idame k\u00e4sud:<\/p>\n
      rabbitmqctl stop_app\nrabbitmqctl reset<\/code><\/pre>\n
      \nKlastril on \"unustanud\" vanad s\u00f5lmed: vana RMQ-deleting ja kolimine on l\u00f5petatud.<\/p>\n
      M\u00e4rkus<\/b>: Kui kasutate RMQ-d sertifikaatidega, siis p\u00f5him\u00f5tteliselt ei muutu midagi \u2014 kolimisprotsess toimub t\u00e4pselt samamoodi.<\/i><\/p>\n
      J\u00e4reldused<\/h2>\n
      \nKirjeldatud skeem sobib praktiliselt k\u00f5ikides olukordades, kui peame RabbitMQ-d \u00fcleviima v\u00f5i lihtsalt uuele klastrile kolima.<\/p>\n
      Meie puhul tekkisid raskused vaid \u00fcks kord, kui RMQ-d kasutati paljusid kohti, ja meil ei olnud v\u00f5imalust igal pool RMQ aadressi uuele vahetada. Siis k\u00e4ivitasime uue RMQ sama nimekirjaga samas nimes, nii et see vastaks juba olemasolevatele teenustele ja Ingress'idele, ja k\u00e4ivitasime pod'i k\u00e4sitsi m\u00e4rkide manipuleerimisega, eemaldades need alguses, et t\u00fchjad RMQ-le ei laekuks p\u00e4ringud, ja lisades need p\u00e4rast s\u00f5numite s\u00fcnkroonimist tagasi.<\/p>\n
      Sarnast strateegiat kasutasime RabbitMQ versiooniuuendamiseks koos muudetud konfiguratsiooniga \u2014 k\u00f5ik t\u00f6\u00f6tas nagu kell.<\/p>\n
      P.S.<\/h2>\n
      \nSelle teema loogilise j\u00e4tkuna valmistame ette artikleid MongoDB (migratsioon rauaserverist Kubernetesesse) ja MySQL (kuidas me seda andmebaasi Kuberneteses valmistame). Need avaldatakse l\u00e4hikuudel.<\/p>\n
      P.P.S.<\/h2>\n
      \nLugege ka meie blogist:<\/p>\n