{"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\/pl\/blog\/administrirovanie\/besprostojnaya-migratsiya-rabbitmq-v-kubernetes","title":{"rendered":"K\u0142opotliwa migracja RabbitMQ do Kubernetes","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"K\u0142opotliwa
\n
\nRabbitMQ \u2013 to napisany w j\u0119zyku Erlang broker wiadomo\u015bci, kt\u00f3ry pozwala na zorganizowanie odpornego na awarie klastra z pe\u0142n\u0105 replikacj\u0105 danych na wielu w\u0119z\u0142ach, gdzie ka\u017cdy w\u0119ze\u0142 mo\u017ce obs\u0142ugiwa\u0107 zapytania do odczytu i zapisu. Posiadaj\u0105c wiele klastr\u00f3w Kubernetes w produkcji, wspieramy du\u017c\u0105 liczb\u0119 instalacji RabbitMQ i stan\u0119li\u015bmy przed konieczno\u015bci\u0105 migracji danych z jednego klastra do drugiego bez przestoj\u00f3w.<\/a><\/noindex><\/p>\n

Operacja ta by\u0142a nam konieczna przynajmniej w dw\u00f3ch przypadkach:<\/p>\n

    \n
  1. Przeniesienie danych z klastra RabbitMQ, kt\u00f3ry nie dzia\u0142a w Kubernetes, do nowego \u2014 ju\u017c \u201eskonfigurowanego pod K8s\u201d (tj. funkcjonuj\u0105cego w podach K8s) \u2014 klastra.<\/li>\n
  2. Migracja RabbitMQ w ramach Kubernetes z jednego namespace do drugiego (na przyk\u0142ad, je\u015bli obszary s\u0105 rozgraniczone przez przestrzenie nazw, to w celu przeniesienia infrastruktury z jednego obszaru do innego).<\/li>\n<\/ol>\n

    \nProponowany w artykule przepis jest skierowany na sytuacje (ale wcale ich nie ogranicza), w kt\u00f3rych istnieje stary klaster RabbitMQ (na przyk\u0142ad sk\u0142adaj\u0105cy si\u0119 z 3 w\u0119z\u0142\u00f3w), kt\u00f3ry znajduje si\u0119 albo ju\u017c w K8s, albo na jakich\u015b starych serwerach. Z nim wsp\u00f3\u0142pracuje aplikacja, umieszczona w Kubernetes (ju\u017c tam lub w perspektywie):<\/p>\n

    \"K\u0142opotliwa
    \n
    \n\u2026 i przed nami stoi zadanie migracji do nowej produkcji w Kubernetes.<\/p>\n

    Na pocz\u0105tku zostanie opisane og\u00f3lne podej\u015bcie do samej migracji, a dopiero p\u00f3\u017aniej \u2014 szczeg\u00f3\u0142y techniczne dotycz\u0105ce jej realizacji.<\/p>\n

    Algorytm migracji<\/h2>\n

    \nPierwszy, wst\u0119pny etap przed jakimikolwiek dzia\u0142aniami \u2014 sprawdzenie, czy w starej instalacji RabbitMQ w\u0142\u0105czony jest tryb wysokiej dost\u0119pno\u015bci (HA<\/a><\/noindex>). Pow\u00f3d jest oczywisty \u2014 nie chcemy przecie\u017c straci\u0107 \u017cadnych danych. Aby to sprawdzi\u0107, mo\u017cna wej\u015b\u0107 do panelu administracyjnego RabbitMQ i w zak\u0142adce Admin \u2192 Policies upewni\u0107 si\u0119, \u017ce ustawiona jest warto\u015b\u0107 ha-mode: all<\/code>:<\/p>\n

    \"K\u0142opotliwa
    \n
    \nNast\u0119pny krok \u2014 uruchamiamy nowy klaster RabbitMQ w podach Kubernetes (w naszym przypadku, na przyk\u0142ad, sk\u0142adaj\u0105cy si\u0119 z 3 w\u0119z\u0142\u00f3w, ale ich liczba mo\u017ce by\u0107 inna).<\/p>\n

    Po tym \u0142\u0105czymy stary i nowy klaster RabbitMQ, uzyskuj\u0105c jeden wsp\u00f3lny klaster (z 6 w\u0119z\u0142\u00f3w):<\/p>\n

    \"K\u0142opotliwa
    \n
    \nInicjowany jest proces synchronizacji danych mi\u0119dzy starym a nowym klastrem RabbitMQ. Po tym, jak wszystkie dane zostan\u0105 zsynchronizowane mi\u0119dzy wszystkimi w\u0119z\u0142ami w klastrze, mo\u017cemy prze\u0142\u0105czy\u0107 aplikacj\u0119 na korzystanie z nowego klastra:<\/p>\n

    \"K\u0142opotliwa
    \n
    \nPo tych operacjach wystarczy wy\u0142\u0105czy\u0107 stare w\u0119z\u0142y z klastra RabbitMQ, a migracj\u0119 mo\u017cna uzna\u0107 za zako\u0144czon\u0105:<\/p>\n

    \"K\u0142opotliwa
    \n
    \nTen schemat wielokrotnie stosowali\u015bmy w naszej produkcji. Jednak dla w\u0142asnej wygody zaimplementowali\u015bmy go w ramach wyspecjalizowanego systemu, kt\u00f3ry rozprowadza typowe konfiguracje RMQ na wielu klastrach Kubernetes. (dla ciekawskich: mowa o     addon-operator<\/a><\/noindex>, o kt\u00f3rym niedawno opowiadali\u015bmy. Poni\u017cej zostan\u0105 przedstawione oddzielne instrukcje, kt\u00f3re ka\u017cdy mo\u017ce zastosowa\u0107 w swoich instalacjach, aby sprawdzi\u0107 proponowane rozwi\u0105zanie w dzia\u0142aniu.<\/a><\/noindex>)<\/i>Sprawdzamy w praktyce<\/p>\n

    Rekwizyty s\u0105 bardzo proste:<\/h2>\n

    <\/p>\n

    Wymagania<\/h3>\n

    \nKlaster Kubernetes (mo\u017ce by\u0107 tak\u017ce minikube);<\/p>\n

      \n
    1. Klaster RabbitMQ (mo\u017ce by\u0107 zainstalowany na bare metal lub stworzony jako zwyk\u0142y klaster w Kubernetes za pomoc\u0105 oficjalnego Helm-chart).<\/li>\n
    2. Dla opisanego poni\u017cej przyk\u0142adu za\u0142o\u017cy\u0142em RMQ w Kubernetes i nazwa\u0142em go<\/li>\n<\/ol>\n

      \nrmq-old Przygotowanie stanowiska<\/code>.<\/p>\n

      1. Pobieramy Helm-chart i nieco go edytujemy:<\/h3>\n

      \nhelm fetch --untar stable\/rabbitmq-ha<\/p>\n

      Dla wygody ustawiamy has\u0142o,<\/code><\/pre>\n
      \nErlangCookie i tworzymy polityk\u0119<\/code> ha-all , aby domy\u015blnie kolejki synchronizowa\u0142y si\u0119 mi\u0119dzy wszystkimi w\u0119z\u0142ami klastra RMQ:<\/code>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  }<\/p>\n
      2. Instalujemy chart:<\/code><\/pre>\n
      \nhelm install . --name rmq-old --namespace rmq-old<\/p>\n
      3. Wchodzimy do panelu administracyjnego RabbitMQ, tworzymy now\u0105 kolejk\u0119 i dodajemy kilka wiadomo\u015bci. B\u0119d\u0105 one potrzebne, aby po migracji upewni\u0107 si\u0119, \u017ce wszystkie dane zosta\u0142y zachowane i nic nie zosta\u0142o utracone:<\/code><\/pre>\n
      \nTestowe stanowisko gotowe: mamy \u201estary\u201d RabbitMQ z danymi, kt\u00f3re nale\u017cy przenie\u015b\u0107.<\/p>\n
      \"K\u0142opotliwa
      \n
      \nMigracja klastra RabbitMQ<\/p>\n
      1. Na pocz\u0105tek uruchomimy nowy RabbitMQ w<\/h3>\n
      \ninnym przestrzeni nazw z<\/b> takim samym i has\u0142em dla u\u017cytkownika. W tym celu wykonamy opisane powy\u017cej operacje, zmieniaj\u0105c ko\u0144cow\u0105 komend\u0119 do instalacji RMQ na nast\u0119puj\u0105c\u0105:<\/b> i tworzymy polityk\u0119<\/code> helm install . --name rmq-new --namespace rmq-new<\/p>\n
      2. Teraz musimy po\u0142\u0105czy\u0107 nowy klaster ze starym. W tym celu wchodzimy do ka\u017cdego z pod\u00f3w<\/code><\/pre>\n
      \nnowego RabbitMQ i wykonujemy polecenia:<\/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
      \nW zmiennej to adres jednego z w\u0119z\u0142\u00f3w<\/code> starego klastra RMQ.<\/b> Te polecenia zatrzymaj\u0105 bie\u017c\u0105cy w\u0119ze\u0142<\/p>\n
      klastra RMQ, do\u0142\u0105cz\u0105 go do starego klastra i ponownie uruchomi\u0105. RabbitMQ i wykonujemy polecenia:<\/b> 3. Klaster RMQ z 6 w\u0119z\u0142ami gotowy:<\/p>\n
      3. Klaster RMQ z 6 w\u0119z\u0142ami gotowy:<\/p>\n
      \"K\u0142opotliwa
      \n
      \nMusisz poczeka\u0107, a\u017c wiadomo\u015bci zsynchronizuj\u0105 si\u0119 mi\u0119dzy wszystkimi w\u0119z\u0142ami. Nie trudno si\u0119 domy\u015bli\u0107, \u017ce czas synchronizacji wiadomo\u015bci zale\u017cy od mocy sprz\u0119tu, na kt\u00f3rym uruchomiony jest klaster, oraz od liczby wiadomo\u015bci. W opisanym scenariuszu jest ich zaledwie 10, wi\u0119c dane zsynchronizowa\u0142y si\u0119 natychmiast, ale przy wystarczaj\u0105co du\u017cej liczbie wiadomo\u015bci synchronizacja mo\u017ce trwa\u0107 godzinami.<\/p>\n
      Status synchronizacji:<\/p>\n
      \"K\u0142opotliwa
      \n
      \nTutaj +5<\/code> oznacza, \u017ce wiadomo\u015bci s\u0105 ju\u017c jeszcze<\/b> na 5 w\u0119z\u0142ach (opr\u00f3cz tego, kt\u00f3ry jest wskazany w polu W\u0119ze\u0142<\/code>). W ten spos\u00f3b synchronizacja przebieg\u0142a pomy\u015blnie.<\/p>\n
      4. Pozostaje tylko prze\u0142\u0105czy\u0107 w aplikacji adres RMQ na nowy klaster (konkretne dzia\u0142ania tutaj zale\u017c\u0105 od u\u017cywanego przez Ciebie stosu technologicznego i innych specyfik aplikacji), po czym mo\u017cna po\u017cegna\u0107 si\u0119 ze star\u0105 wersj\u0105.<\/p>\n
      Aby wykona\u0107 ostatni\u0105 operacj\u0119 (tj. ju\u017c po<\/b> prze\u0142\u0105czenia aplikacji na nowy klaster), wchodzimy na ka\u017cdy w\u0119ze\u0142 klastra RMQ.<\/b> klastra i wykonujemy polecenia:<\/p>\n
      rabbitmqctl stop_app\nrabbitmqctl reset<\/code><\/pre>\n
      \nKlaster \u201ezapomnia\u0142\u201d o starych w\u0119z\u0142ach: mo\u017cna usun\u0105\u0107 stary RMQ, co zako\u0144czy migracj\u0119.<\/p>\n
      Uwaga<\/b>: Je\u015bli u\u017cywasz RMQ z certyfikatami, to zasadniczo nic si\u0119 nie zmienia \u2014 proces migracji b\u0119dzie przebiega\u0142 dok\u0142adnie tak samo.<\/i><\/p>\n
      Wnioski<\/h2>\n
      \nOpisana schemat pasuje praktycznie do wszystkich przypadk\u00f3w, gdy musimy przenie\u015b\u0107 RabbitMQ lub po prostu przeprowadzi\u0107 si\u0119 do nowego klastra.<\/p>\n
      W naszym przypadku trudno\u015bci wyst\u0105pi\u0142y tylko raz, gdy do RMQ zwracano si\u0119 z wielu miejsc, a nie mieli\u015bmy mo\u017cliwo\u015bci zmiany adresu RMQ wsz\u0119dzie. Wtedy uruchomili\u015bmy nowy RMQ w tej samej przestrzeni nazw z identycznymi etykietami, aby pasowa\u0142 do ju\u017c istniej\u0105cych us\u0142ug i Ingress\u00f3w, a przy uruchamianiu pod'a r\u0119cznie manipulowali\u015bmy etykietami, usuwaj\u0105c je na pocz\u0105tku, aby \u017cadne zapytania nie trafia\u0142y na pusty RMQ i dodaj\u0105c je z powrotem po synchronizacji wiadomo\u015bci.<\/p>\n
      T\u0119 sam\u0105 strategi\u0119 zastosowali\u015bmy podczas aktualizacji RabbitMQ do nowej wersji z zmienion\u0105 konfiguracj\u0105 \u2014 wszystko dzia\u0142a\u0142o jak w zegarku.<\/p>\n
      P.S.<\/h2>\n
      \nJako logiczne rozwini\u0119cie tego materia\u0142u przygotowujemy artyku\u0142y na temat MongoDB (migracja z serwera fizycznego do Kubernetes) i MySQL (jak przygotowujemy t\u0119 baz\u0119 danych w Kubernetes). Zostan\u0105 one opublikowane w najbli\u017cszych miesi\u0105cach.<\/p>\n
      P.P.S.<\/h2>\n
      \nPrzeczytaj tak\u017ce na naszym blogu:<\/p>\n