{"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\/cs\/blog\/administrirovanie\/besprostojnaya-migratsiya-rabbitmq-v-kubernetes","title":{"rendered":"N\u00e1ro\u010dn\u00e1 migrace RabbitMQ do Kubernetes","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"N\u00e1ro\u010dn\u00e1
\n
\nRabbitMQ \u2013 broker zpr\u00e1v napsan\u00fd v jazyce Erlang, kter\u00fd umo\u017e\u0148uje organizaci vysoce dostupn\u00e9ho clusteru s plnou replikac\u00ed dat na n\u011bkolik uzl\u016f, p\u0159i\u010dem\u017e ka\u017ed\u00fd uzel m\u016f\u017ee obsluhovat po\u017eadavky na \u010dten\u00ed a z\u00e1pis. Vzhledem k tomu, \u017ee m\u00e1me v produk\u010dn\u00edm prost\u0159ed\u00ed n\u011bkolik cluster\u016f Kubernetes, podporujeme velk\u00e9 mno\u017estv\u00ed instalac\u00ed RabbitMQ a setkali jsme se s pot\u0159ebou migrace dat z jednoho clusteru do druh\u00e9ho bez v\u00fdpadku.<\/a><\/noindex><\/p>\n

Tato operace byla nutn\u00e1 minim\u00e1ln\u011b ve dvou p\u0159\u00edpadech:<\/p>\n

    \n
  1. P\u0159enos dat z clusteru RabbitMQ, kter\u00fd nen\u00ed v Kubernetes, do nov\u00e9ho \u2014 ji\u017e \"kubernezovan\u00e9ho\" (tj. funguj\u00edc\u00edho v pod K8s) \u2014 clusteru.<\/li>\n
  2. Migrace RabbitMQ v r\u00e1mci Kubernetes z jednoho namespace do druh\u00e9ho (nap\u0159\u00edklad pokud jsou obrysy omezeny prostory jmen, pak pro p\u0159enos infrastruktury z jednoho obrysu do druh\u00e9ho).<\/li>\n<\/ol>\n

    \nNavrhovan\u00fd recept v \u010dl\u00e1nku je zam\u011b\u0159en na situace (ale nen\u00ed jimi omezen), kdy existuje star\u00fd cluster RabbitMQ (nap\u0159\u00edklad ze 3 uzl\u016f), kter\u00fd je bu\u010f ji\u017e v K8s, nebo na n\u011bjak\u00fdch star\u00fdch serverech. S n\u00edm pracuje aplikace um\u00edst\u011bn\u00e1 v Kubernetes (u\u017e tam nebo v budoucnu):<\/p>\n

    \"N\u00e1ro\u010dn\u00e1
    \n
    \n\u2026 a p\u0159ed n\u00e1mi stoj\u00ed \u00fakol jeho migrace do nov\u00e9ho produk\u010dn\u00edho prost\u0159ed\u00ed v Kubernetes.<\/p>\n

    Nejprve bude pops\u00e1n obecn\u00fd p\u0159\u00edstup k samotn\u00e9 migraci, a teprve pot\u00e9 \u2013 technick\u00e9 detaily jej\u00ed realizace.<\/p>\n

    Algoritmus migrace<\/h2>\n

    \nPrvn\u00ed, p\u0159edb\u011b\u017en\u00fd krok p\u0159ed jak\u00fdmikoli akcemi \u2013 zkontrolovat, \u017ee ve star\u00e9 instalaci RabbitMQ je zapnut\u00fd re\u017eim vysok\u00e9 dostupnosti (HA<\/a><\/noindex>). D\u016fvod je z\u0159ejm\u00fd \u2013 nechceme p\u0159ece p\u0159ij\u00edt o \u017e\u00e1dn\u00e1 data. K ov\u011b\u0159en\u00ed tohoto stavu lze vstoupit do administrace RabbitMQ a v z\u00e1lo\u017ece Admin \u2192 Policies se ujistit, \u017ee je nastavena hodnota ha-mode: all<\/code>:<\/p>\n

    \"N\u00e1ro\u010dn\u00e1
    \n
    \nDal\u0161\u00edm krokem je spu\u0161t\u011bn\u00ed nov\u00e9ho clusteru RabbitMQ v podech Kubernetes (v na\u0161em p\u0159\u00edpad\u011b nap\u0159\u00edklad slo\u017een\u00e9ho ze 3 uzl\u016f, ale jejich po\u010det m\u016f\u017ee b\u00fdt i jin\u00fd).<\/p>\n

    Pot\u00e9 spoj\u00edme star\u00fd a nov\u00fd cluster RabbitMQ a z\u00edsk\u00e1me jednotn\u00fd cluster (ze 6 uzl\u016f):<\/p>\n

    \"N\u00e1ro\u010dn\u00e1
    \n
    \nSpou\u0161t\u00ed se proces synchronizace dat mezi star\u00fdm a nov\u00fdm clusterem RabbitMQ. Jakmile se v\u0161echna data synchronizuj\u00ed mezi v\u0161emi uzly v clusteru, m\u016f\u017eeme p\u0159epnout aplikaci na pou\u017e\u00edv\u00e1n\u00ed nov\u00e9ho clusteru:<\/p>\n

    \"N\u00e1ro\u010dn\u00e1
    \n
    \nPo t\u011bchto operac\u00edch sta\u010d\u00ed odpojit star\u00e9 uzly z clusteru RabbitMQ a p\u0159esun m\u016f\u017eeme pova\u017eovat za dokon\u010den\u00fd:<\/p>\n

    \"N\u00e1ro\u010dn\u00e1
    \n
    \nTento sch\u00e9ma jsme opakovan\u011b aplikovali v na\u0161ich produk\u010dn\u00edch prost\u0159ed\u00edch. Nicm\u00e9n\u011b, pro vlastn\u00ed pohodl\u00ed jsme ji implementovali v r\u00e1mci specializovan\u00e9ho syst\u00e9mu, kter\u00fd distribuuje standardn\u00ed konfigurace RMQ na mnoha clusterech Kubernetes. (pro ty, kdo se zaj\u00edmaj\u00ed: mluv\u00edme o     addon-operator<\/a><\/noindex>, o kter\u00e9m jsme ned\u00e1vno jsme mluvili<\/a><\/noindex>)<\/i>. N\u00ed\u017ee budou uvedeny jednotliv\u00e9 pokyny, kter\u00e9 si ka\u017ed\u00fd m\u016f\u017ee aplikovat na sv\u00fdch instalac\u00edch, aby vyzkou\u0161el navrhovan\u00e9 \u0159e\u0161en\u00ed v akci.<\/p>\n

    Zkou\u0161\u00edme v praxi<\/h2>\n

    <\/p>\n

    Po\u017eadavky<\/h3>\n

    \nPo\u017eadavky jsou velmi jednoduch\u00e9:<\/p>\n

      \n
    1. Kubernetes cluster (vhodn\u00fd je i minikube);<\/li>\n
    2. RabbitMQ cluster (m\u016f\u017ee b\u00fdt nasazen na bare metal, nebo vytvo\u0159en jako b\u011b\u017en\u00fd cluster v Kubernetes pomoc\u00ed ofici\u00e1ln\u00edho Helm chartu).<\/li>\n<\/ol>\n

      \nPro n\u00ed\u017ee popsan\u00fd p\u0159\u00edklad jsem nasadil RMQ v Kubernetes a pojmenoval ho rmq-old<\/code>.<\/p>\n

      P\u0159\u00edprava prost\u0159ed\u00ed<\/h3>\n

      \n1. St\u00e1hneme Helm chart a trochu jej uprav\u00edme:<\/p>\n

      helm fetch --untar stable\/rabbitmq-ha<\/code><\/pre>\n
      \nPro pohodl\u00ed nastav\u00edme heslo, ErlangCookie<\/code> a nastav\u00edme politiku ha-all<\/code>, aby se fronty ve v\u00fdchoz\u00edm nastaven\u00ed synchronizovaly mezi v\u0161emi uzly RMQ clusteru:<\/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. Instalujeme chart:<\/p>\n
      helm install . --name rmq-old --namespace rmq-old<\/code><\/pre>\n
      \n3. P\u0159ihl\u00e1s\u00edme se do admin rozhran\u00ed RabbitMQ, vytvo\u0159\u00edme novou frontu a p\u0159id\u00e1me n\u011bkolik zpr\u00e1v. Ty budou pot\u0159ebn\u00e9 k tomu, abychom po migraci mohli potvrdit, \u017ee v\u0161echna data byla zachov\u00e1na a nic jsme neztratili:<\/p>\n
      \"N\u00e1ro\u010dn\u00e1
      \n
      \nTestovac\u00ed prost\u0159ed\u00ed je p\u0159ipraveno: m\u00e1me \"star\u00fd\" RabbitMQ s daty, kter\u00e9 je t\u0159eba p\u0159en\u00e9st.<\/p>\n
      Migrace RabbitMQ clusteru<\/h3>\n
      \n1. Nejprve nasad\u00edme nov\u00fd RabbitMQ v p\u0159\u00edtelem<\/b> namespace se stejn\u00fdmi<\/b> ErlangCookie<\/code> a heslem pro u\u017eivatele. K tomu provedeme v\u00fd\u0161e popsan\u00e9 operace, p\u0159i\u010dem\u017e zm\u011bn\u00edme koncovou p\u0159\u00edkazovou instalaci RMQ na n\u00e1sleduj\u00edc\u00ed:<\/p>\n
      helm install . --name rmq-new --namespace rmq-new<\/code><\/pre>\n
      \n2. Nyn\u00ed je t\u0159eba spojit nov\u00fd cluster se star\u00fdm. K tomu se p\u0159ihl\u00e1s\u00edme do ka\u017ed\u00e9ho z pod\u016f nov\u00e9ho<\/b> RabbitMQ a provedeme p\u0159\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 prom\u011bnn\u00e9 OLD_RMQ<\/code> se nach\u00e1z\u00ed adresa jednoho z uzl\u016f star\u00e9ho<\/b> clusteru RMQ.<\/p>\n
      Tyto p\u0159\u00edkazy zastav\u00ed aktu\u00e1ln\u00ed uzel nov\u00e9ho<\/b> clusteru RMQ, p\u0159ipoj\u00ed ho ke star\u00e9mu clusteru a znovu ho spust\u00ed.<\/p>\n
      3. RMQ cluster se 6 uzly je p\u0159ipraven:<\/p>\n
      \"N\u00e1ro\u010dn\u00e1
      \n
      \nJe t\u0159eba po\u010dkat, a\u017e se zpr\u00e1vy synchronizuj\u00ed mezi v\u0161emi uzly. Nen\u00ed t\u011b\u017ek\u00e9 uhodnout, \u017ee \u010das synchronizace zpr\u00e1v z\u00e1vis\u00ed na v\u00fdkonu hardware, na kter\u00e9m je cluster nasazen, a na po\u010dtu zpr\u00e1v. V popisovan\u00e9m sc\u00e9n\u00e1\u0159i je jich pouze 10, a proto se data synchronizovala okam\u017eit\u011b, ale p\u0159i dostate\u010dn\u011b velk\u00e9m mno\u017estv\u00ed zpr\u00e1v m\u016f\u017ee synchronizace trvat hodiny.<\/p>\n
      Tak\u017ee, stav synchronizace:<\/p>\n
      \"N\u00e1ro\u010dn\u00e1
      \n
      \nZde +5<\/code> znamen\u00e1, \u017ee zpr\u00e1vy jsou ji\u017e je\u0161t\u011b<\/b> na 5 uzlech (krom\u011b toho, kter\u00fd je uveden v poli Node<\/code>). T\u00edm p\u00e1dem byla synchronizace \u00fasp\u011b\u0161n\u00e1.<\/p>\n
      4. Z\u016fst\u00e1v\u00e1 jen p\u0159epnout v aplikaci adresu RMQ na nov\u00fd cluster (konkr\u00e9tn\u00ed kroky z\u00e1vis\u00ed na technologick\u00e9m stacku, kter\u00fd pou\u017e\u00edv\u00e1te, a jin\u00e9 specifice aplikace), pot\u00e9 se m\u016f\u017eete rozlou\u010dit se star\u00fdm.<\/p>\n
      Pro posledn\u00ed operaci (tj. ji\u017e po<\/b> p\u0159epnut\u00ed aplikace na nov\u00fd cluster) se p\u0159ihl\u00e1s\u00edme na ka\u017ed\u00fd uzel star\u00e9ho<\/b> clusteru a provedeme p\u0159\u00edkazy:<\/p>\n
      rabbitmqctl stop_app\nrabbitmqctl reset<\/code><\/pre>\n
      \nCluster \u00abzapomn\u011bl\u00bb na star\u00e9 uzly: star\u00fd RMQ lze odstranit, \u010d\u00edm\u017e bude migrace dokon\u010dena.<\/p>\n
      Pozn\u00e1mka<\/b>: Pokud pou\u017e\u00edv\u00e1te RMQ s certifik\u00e1ty, princip\u00e1ln\u011b se nic nem\u011bn\u00ed \u2014 proces migrace prob\u011bhne p\u0159esn\u011b stejn\u00fdm zp\u016fsobem.<\/i><\/p>\n
      Z\u00e1v\u011bry<\/h2>\n
      \nPopisovan\u00e1 sch\u00e9ma se hod\u00ed prakticky pro v\u0161echny p\u0159\u00edpady, kdy pot\u0159ebujeme p\u0159en\u00e9st RabbitMQ nebo se jednodu\u0161e p\u0159est\u011bhovat do nov\u00e9ho clusteru.<\/p>\n
      V na\u0161em p\u0159\u00edpad\u011b se komplikace objevily pouze jednou, kdy\u017e se k RMQ p\u0159istupovalo z mnoha m\u00edst, a my nem\u011bli mo\u017enost v\u0161ude zm\u011bnit adresu RMQ na novou. V takov\u00e9m p\u0159\u00edpad\u011b jsme spustili nov\u00fd RMQ ve stejn\u00e9m jmenn\u00e9m prostoru se stejn\u00fdmi \u0161t\u00edtky, aby se dostal pod ji\u017e existuj\u00edc\u00ed slu\u017eby a Ingressy, a p\u0159i spu\u0161t\u011bn\u00ed podu jsme ru\u010dn\u011b manipulovali se \u0161t\u00edtky, jejich\u017e odstran\u011bn\u00edm na za\u010d\u00e1tku jsme zajistili, aby pr\u00e1zdn\u00fd RMQ nereagoval na dotazy, a po synchronizaci zpr\u00e1v jsme je znovu p\u0159idali.<\/p>\n
      Stejnou strategii jsme pou\u017eili p\u0159i aktualizaci RabbitMQ na novou verzi se zm\u011bn\u011bnou konfigurac\u00ed \u2014 v\u0161echno fungovalo jako hodinky.<\/p>\n
      P.S.<\/h2>\n
      \nJako logick\u00e9 pokra\u010dov\u00e1n\u00ed tohoto materi\u00e1lu p\u0159ipravujeme \u010dl\u00e1nky o MongoDB (migrace z fyzick\u00e9ho serveru do Kubernetes) a MySQL (jak tuto DB p\u0159ipravujeme uvnit\u0159 Kubernetes). Ty budou publikov\u00e1ny v n\u00e1sleduj\u00edc\u00edch m\u011bs\u00edc\u00edch.<\/p>\n
      P.P.S.<\/h2>\n
      \nP\u0159e\u010dt\u011bte si tak\u00e9 n\u00e1\u0161 blog:<\/p>\n