{"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\/sk\/blog\/administrirovanie\/besprostojnaya-migratsiya-rabbitmq-v-kubernetes","title":{"rendered":"Zlo\u017eit\u00e1 migr\u00e1cia RabbitMQ do Kubernetes","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Zlo\u017eit\u00e1
\n
\nRabbitMQ \u2013 spr\u00e1vy broker nap\u00edsan\u00fd v jazyku Erlang, ktor\u00fd umo\u017e\u0148uje organizova\u0165 odoln\u00fd klaster s plnou replik\u00e1ciou d\u00e1t na viacer\u00fdch uzloch, pri\u010dom ka\u017ed\u00fd uzol m\u00f4\u017ee obsluhova\u0165 po\u017eiadavky na \u010d\u00edtanie a z\u00e1pis. S mno\u017estvom klastrov Kubernetes v produkcii podporujeme ve\u013ek\u00e9 mno\u017estvo in\u0161tal\u00e1ci\u00ed RabbitMQ a stretli sme sa s potrebou migr\u00e1cie d\u00e1t z jedn\u00e9ho klasteru do druh\u00e9ho bez v\u00fdpadku.<\/a><\/noindex><\/p>\n

T\u00e1to oper\u00e1cia bola pre n\u00e1s nevyhnutn\u00e1 minim\u00e1lne v dvoch pr\u00edpadoch:<\/p>\n

    \n
  1. Prenos \u00fadajov z klasteru RabbitMQ, ktor\u00fd nie je v Kubernetes, do nov\u00e9ho \u2013 u\u017e \"kubernetizovan\u00e9ho\" (t.j. funguj\u00faceho v pod'ach K8s) \u2013 klasteru.<\/li>\n
  2. Migr\u00e1cia RabbitMQ v r\u00e1mci Kubernetes z jedn\u00e9ho namespace do druh\u00e9ho (napr\u00edklad, ak s\u00fa kont\u00fary rozdelen\u00e9 priestorami mien, tak pre prenos infra\u0161trukt\u00fary z jedn\u00e9ho kont\u00faru do druh\u00e9ho).<\/li>\n<\/ol>\n

    \nNavrhnut\u00fd recept v \u010dl\u00e1nku je orientovan\u00fd na situ\u00e1cie (ale nie je nimi obmedzen\u00fd), v ktor\u00fdch existuje star\u00fd klaster RabbitMQ (napr\u00edklad z 3 uzlov), ktor\u00fd je bu\u010f u\u017e v K8s, alebo na nejak\u00fdch star\u00fdch serveroch. S n\u00edm pracuje aplik\u00e1cia umiestnen\u00e1 v Kubernetes (u\u017e tam alebo v perspekt\u00edve):<\/p>\n

    \"Zlo\u017eit\u00e1
    \n
    \n\u2026 a pred nami stoj\u00ed \u00faloha jeho migr\u00e1cie do nov\u00e9ho produk\u010dn\u00e9ho prostredia v Kubernetes.<\/p>\n

    Najprv bude op\u00edsan\u00fd v\u0161eobecn\u00fd pr\u00edstup k samotnej migr\u00e1cii, a a\u017e po tom \u2013 technick\u00e9 detaily jej realiz\u00e1cie.<\/p>\n

    Algoritmus migr\u00e1cie<\/h2>\n

    \nPrv\u00fd, predbe\u017en\u00fd krok pred ak\u00fdmiko\u013evek akciami \u2013 overenie, \u010di je v starej in\u0161tal\u00e1cii RabbitMQ zapnut\u00fd re\u017eim vysokej dostupnosti (HA<\/a><\/noindex>). D\u00f4vod je zrejm\u00fd \u2013 predsa nechceme strati\u0165 \u017eiadne \u00fadaje. Na vykonanie tejto kontroly m\u00f4\u017eeme vst\u00fapi\u0165 do administr\u00e1torskej sekcie RabbitMQ a v karte Admin \u2192 Policies sa uisti\u0165, \u017ee je nastaven\u00e1 hodnota ha-mode: all<\/code>:<\/p>\n

    \"Zlo\u017eit\u00e1
    \n
    \n\u010eal\u0161\u00edm krokom je spustenie nov\u00e9ho klasteru RabbitMQ v pod'ach Kubernetes (v na\u0161om pr\u00edpade, napr\u00edklad pozost\u00e1vaj\u00faceho z 3 uzlov, ale ich po\u010det m\u00f4\u017ee by\u0165 aj in\u00fd).<\/p>\n

    Potom spoj\u00edme star\u00fd a nov\u00fd klaster RabbitMQ a z\u00edskame jedin\u00fd klaster (zo 6 uzlov):<\/p>\n

    \"Zlo\u017eit\u00e1
    \n
    \nSp\u00fa\u0161\u0165a sa proces synchroniz\u00e1cie \u00fadajov medzi star\u00fdmi a nov\u00fdmi klastrami RabbitMQ. Po tom, \u010do sa v\u0161etky \u00fadaje synchronizuj\u00fa medzi v\u0161etk\u00fdmi uzlami v klasteri, m\u00f4\u017eeme prepn\u00fa\u0165 aplik\u00e1ciu na pou\u017e\u00edvanie nov\u00e9ho klasteru:<\/p>\n

    \"Zlo\u017eit\u00e1
    \n
    \nPo t\u00fdchto oper\u00e1ci\u00e1ch sta\u010d\u00ed vyradi\u0165 star\u00e9 uzly z RabbitMQ klasteru a pres\u0165ahovanie m\u00f4\u017eeme pova\u017eova\u0165 za dokon\u010den\u00e9:<\/p>\n

    \"Zlo\u017eit\u00e1
    \n
    \nTento sch\u00e9ma sme opakovane aplikovali v na\u0161ej produkcii. Pre vlastn\u00e9 pohodlie sme ju v\u0161ak implementovali v r\u00e1mci \u0161pecializovan\u00e9ho syst\u00e9mu, ktor\u00fd distribuuje typick\u00e9 konfigur\u00e1cie RMQ na mno\u017estv\u00e1ch klastrov Kubernetes (pre t\u00fdch, ktor\u00ed s\u00fa zvedav\u00ed: hovor\u00edme o     addon-operator<\/a><\/noindex>, o ktorom sme ned\u00e1vno hovorili<\/a><\/noindex>)<\/i>. Ni\u017e\u0161ie bud\u00fa uveden\u00e9 samostatne vybran\u00e9 in\u0161trukcie, ktor\u00e9 si m\u00f4\u017ee ka\u017ed\u00fd aplikova\u0165 na svoje in\u0161tal\u00e1cie, aby vysk\u00fa\u0161al navrhovan\u00e9 rie\u0161enie v praxi.<\/p>\n

    Sk\u00fa\u0161ame v praxi<\/h2>\n

    <\/p>\n

    Po\u017eiadavky<\/h3>\n

    \nRekvizity s\u00fa ve\u013emi jednoduch\u00e9:<\/p>\n

      \n
    1. Kubernetes cluster (vhodn\u00fd aj minikube);<\/li>\n
    2. Klastre RabbitMQ (m\u00f4\u017ee by\u0165 nasaden\u00fd aj na bare metal, a vytvoren\u00fd ako be\u017en\u00fd klaster v Kubernetes z ofici\u00e1lneho Helm chartu).<\/li>\n<\/ol>\n

      \nPre ni\u017e\u0161ie uveden\u00fd pr\u00edklad som nasadil RMQ v Kubernetes a nazval ho rmq-old<\/code>.<\/p>\n

      Pr\u00edprava testovacieho prostredia<\/h3>\n

      \n1. Stiahneme Helm chart a trochu ho uprav\u00edme:<\/p>\n

      helm fetch --untar stable\/rabbitmq-ha<\/code><\/pre>\n
      \nPre pohodlie nastav\u00edme heslo, ErlangCookie<\/code> a nastav\u00edme politiku ha-all<\/code>, aby sa fronty synchronizovali medzi v\u0161etk\u00fdmi uzlami klastru RMQ:<\/p>\n
      rabbitmqPassword: guest\nrabbitmqErlangCookie: mae9joopaol7aiVu3eechei2waiGa2we\ndefinitions:\npolicies: |-\n  {\n    \"name\": \"ha-all\",\n    \"pattern\": \".*\",\n    \"vhost\": \"\\\/\",<\/code><\/pre>\n
      \n2. In\u0161talujeme chart:<\/p>\n
      helm install . --name rmq-old --namespace rmq-old<\/code><\/pre>\n
      \n3. Vst\u00fapime do administr\u00e1cie RabbitMQ, vytvor\u00edme nov\u00fa frontu a prid\u00e1me nieko\u013eko spr\u00e1v. Bud\u00fa potrebn\u00e9 na to, aby sme sa po migr\u00e1cii presved\u010dili, \u017ee v\u0161etky d\u00e1ta zostali zachovan\u00e9 a ni\u010d sa nestratilo:<\/p>\n
      \"Zlo\u017eit\u00e1
      \n
      \nTestovacie prostredie je pripraven\u00e9: m\u00e1me \u201estar\u00fd\u201c RabbitMQ s d\u00e1tami, ktor\u00e9 je potrebn\u00e9 prenies\u0165.<\/p>\n
      Migr\u00e1cia klastru RabbitMQ<\/h3>\n
      \n1. Na za\u010diatok nasad\u00edme nov\u00fd RabbitMQ v druh\u00e9m<\/b> namespace s rovnak\u00fdmi<\/b> ErlangCookie<\/code> a heslom pre pou\u017e\u00edvate\u013ea. Na to vykon\u00e1me vy\u0161\u0161ie pop\u00edsan\u00e9 oper\u00e1cie, pri\u010dom zmen\u00edme posledn\u00fd pr\u00edkaz na in\u0161tal\u00e1ciu RMQ na nasleduj\u00faci:<\/p>\n
      helm install . --name rmq-new --namespace rmq-new<\/code><\/pre>\n
      \n2. Teraz je potrebn\u00e9 spoji\u0165 nov\u00fd klaster so star\u00fdm. Za t\u00fdmto \u00fa\u010delom sa prihl\u00e1sime do ka\u017ed\u00e9ho z pod'ov nov\u00e9ho<\/b> RabbitMQ a vykon\u00e1me pr\u00edkazy:<\/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
      \nV premennej OLD_RMQ<\/code> sa nach\u00e1dza adresa jedn\u00e9ho z uzlov star\u00e9ho<\/b> klastru RMQ.<\/p>\n
      Tieto pr\u00edkazy zastavia aktu\u00e1lny uzol nov\u00e9ho<\/b> klastru RMQ, pripoja ho k star\u00e9mu klastru a op\u00e4\u0165 spustia.<\/p>\n
      3. Klaster RMQ zo 6 uzlov je pripraven\u00fd:<\/p>\n
      \"Zlo\u017eit\u00e1
      \n
      \nJe potrebn\u00e9 po\u010dka\u0165, k\u00fdm sa spr\u00e1vy synchronizuj\u00fa medzi v\u0161etk\u00fdmi uzlami. Nie je \u0165a\u017ek\u00e9 uh\u00e1dnu\u0165, \u017ee \u010das synchroniz\u00e1cie spr\u00e1v z\u00e1vis\u00ed od v\u00fdkonu hardv\u00e9ru, na ktorom je cluster nasaden\u00fd, a od po\u010dtu spr\u00e1v. V popisovanom scen\u00e1ri ich je len 10, a preto sa \u00fadaje synchronizovali okam\u017eite, ale pri dostato\u010dne ve\u013ekom po\u010dte spr\u00e1v m\u00f4\u017ee synchroniz\u00e1cia trva\u0165 hodiny.<\/p>\n
      Tak\u017ee, stav synchroniz\u00e1cie:<\/p>\n
      \"Zlo\u017eit\u00e1
      \n
      \nTu +5<\/code> znamen\u00e1, \u017ee spr\u00e1vy s\u00fa u\u017e na e\u0161te<\/b> 5 uzloch (okrem toho, ktor\u00fd je uveden\u00fd v poli Node<\/code>). T\u00fdmto sp\u00f4sobom sa synchroniz\u00e1cia \u00faspe\u0161ne uskuto\u010dnila.<\/p>\n
      4. Ost\u00e1va len prepn\u00fa\u0165 v aplik\u00e1cii adresu RMQ na nov\u00fd cluster (konkr\u00e9tne kroky z\u00e1visia od technologick\u00e9ho r\u00e1mca, ktor\u00fd pou\u017e\u00edvate, a \u010fal\u0161\u00edch \u0161pecif\u00edk aplik\u00e1cie), po \u010dom sa m\u00f4\u017eete rozl\u00fa\u010di\u0165 so star\u00fdm.<\/p>\n
      Pre posledn\u00fa oper\u00e1ciu (t.j. u\u017e po<\/b> prepn\u00fa\u0165 aplik\u00e1ciu na nov\u00fd cluster) sa prihl\u00e1ste na ka\u017ed\u00fd uzol star\u00e9ho<\/b> clusteru a vykonajte pr\u00edkazy:<\/p>\n
      rabbitmqctl stop_app\nrabbitmqctl reset<\/code><\/pre>\n
      \nCluster sa 'zabudol' na star\u00e9 uzly: star\u00fd RMQ m\u00f4\u017eete odstr\u00e1ni\u0165, \u010d\u00edm sa presun dokon\u010d\u00ed.<\/p>\n
      Pozn\u00e1mka<\/b>: Ak pou\u017e\u00edvate RMQ so certifik\u00e1tmi, tak z\u00e1sadne sa ni\u010d nemen\u00ed \u2014 proces migr\u00e1cie sa uskuto\u010dn\u00ed presne takto.<\/i><\/p>\n
      Zhrnutie<\/h2>\n
      \nOp\u00edsan\u00e1 sch\u00e9ma je vhodn\u00e1 takmer vo v\u0161etk\u00fdch pr\u00edpadoch, ke\u010f potrebujeme prenies\u0165 RabbitMQ alebo jednoducho pres\u0165ahova\u0165 do nov\u00e9ho clustra.<\/p>\n
      V na\u0161om pr\u00edpade nastali probl\u00e9my len raz, ke\u010f sa na RMQ obracalo z mnoh\u00fdch miest a nemali sme mo\u017enos\u0165 zmeni\u0165 adresu RMQ na nov\u00fa. Vtedy sme spustili nov\u00fd RMQ v rovnakom namespace s rovnak\u00fdmi zna\u010dkami, aby sa umiestnil pod existuj\u00face slu\u017eby a Ingressy, a pri spusten\u00ed podu sme manipulovali so zna\u010dkami, odstra\u0148ovali ich na za\u010diatku tak, aby na pr\u00e1zdny RMQ nechodili po\u017eiadavky, a prid\u00e1vali ich sp\u00e4\u0165 po synchroniz\u00e1cii spr\u00e1v.<\/p>\n
      Rovnak\u00fa strat\u00e9giu sme aplikovali pri aktualiz\u00e1cii RabbitMQ na nov\u00fa verziu so zmenenou konfigur\u00e1ciou \u2014 v\u0161etko fungovalo ako hodinky.<\/p>\n
      P.S.<\/h2>\n
      \nAko logick\u00e9 pokra\u010dovanie tohto materi\u00e1lu pripravujeme \u010dl\u00e1nky o MongoDB (migr\u00e1cia z hardv\u00e9rov\u00e9ho servera do Kubernetes) a MySQL (ako pripravujeme t\u00fato DBMS vo vn\u00fatri Kubernetes). Bude publikovan\u00fd v najbli\u017e\u0161\u00edch mesiacoch.<\/p>\n
      P.P.S.<\/h2>\n
      \nPre\u010d\u00edtajte si tie\u017e na na\u0161om blogu:<\/p>\n