{"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\/pt\/blog\/administrirovanie\/besprostojnaya-migratsiya-rabbitmq-v-kubernetes","title":{"rendered":"Migra\u00e7\u00e3o descomplicada do RabbitMQ para Kubernetes","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Migra\u00e7\u00e3o
\n
\nRabbitMQ \u2013 um broker de mensagens escrito em Erlang, que permite organizar um cluster tolerante a falhas com replica\u00e7\u00e3o completa de dados em m\u00faltiplos n\u00f3s, onde cada n\u00f3 pode atender a solicita\u00e7\u00f5es de leitura e grava\u00e7\u00e3o. Com m\u00faltiplos clusters Kubernetes em opera\u00e7\u00e3o de produ\u00e7\u00e3o, n\u00f3s suportamos um grande n\u00famero de instala\u00e7\u00f5es do RabbitMQ e enfrentamos a necessidade de migrar dados de um cluster para outro sem tempo de inatividade.<\/a><\/noindex><\/p>\n

Esta opera\u00e7\u00e3o foi necess\u00e1ria para n\u00f3s em pelo menos dois casos:<\/p>\n

    \n
  1. Transferir dados de um cluster RabbitMQ que n\u00e3o est\u00e1 no Kubernetes para um novo cluster j\u00e1 \"kubernetizado\" (ou seja, funcionando em pods K8s).<\/li>\n
  2. Migra\u00e7\u00e3o do RabbitMQ dentro do Kubernetes de um namespace para outro (por exemplo, se os contornos est\u00e3o separados por namespaces, ent\u00e3o para transferir a infraestrutura de um contorno para outro).<\/li>\n<\/ol>\n

    \nA receita proposta no artigo \u00e9 voltada para situa\u00e7\u00f5es (mas n\u00e3o se limita a elas) em que h\u00e1 um antigo cluster RabbitMQ (por exemplo, de 3 n\u00f3s), que j\u00e1 esteja em K8s ou em alguns servidores antigos. Um aplicativo que j\u00e1 est\u00e1 no Kubernetes (ou com a inten\u00e7\u00e3o de estar) interage com ele:<\/p>\n

    \"Migra\u00e7\u00e3o
    \n
    \n\u2026 e temos a tarefa de sua migra\u00e7\u00e3o para um novo ambiente de produ\u00e7\u00e3o no Kubernetes.<\/p>\n

    Primeiro, ser\u00e1 descrita a abordagem geral \u00e0 migra\u00e7\u00e3o, e s\u00f3 depois os detalhes t\u00e9cnicos de sua implementa\u00e7\u00e3o.<\/p>\n

    Algoritmo de migra\u00e7\u00e3o<\/h2>\n

    \nA primeira etapa preliminar antes de qualquer a\u00e7\u00e3o \u00e9 verificar se na antiga instala\u00e7\u00e3o do RabbitMQ o modo de alta disponibilidade est\u00e1 ativado (HA<\/a><\/noindex>). A raz\u00e3o \u00e9 evidente \u2013 pois n\u00e3o queremos perder dados. Para realizar essa verifica\u00e7\u00e3o, podemos acessar o painel administrativo do RabbitMQ e, na aba Admin \u2192 Policies, confirmar que est\u00e1 definido o valor ha-mode: all<\/code>:<\/p>\n

    \"Migra\u00e7\u00e3o
    \n
    \nO pr\u00f3ximo passo \u00e9 levantar um novo cluster RabbitMQ em pods Kubernetes (no nosso caso, por exemplo, composto por 3 n\u00f3s, mas seu n\u00famero pode ser diferente).<\/p>\n

    Depois disso, n\u00f3s unimos os antigos e novos clusters RabbitMQ, formando um \u00fanico cluster (de 6 n\u00f3s):<\/p>\n

    \"Migra\u00e7\u00e3o
    \n
    \nInicia-se o processo de sincroniza\u00e7\u00e3o de dados entre os antigos e novos clusters RabbitMQ. Ap\u00f3s a sincroniza\u00e7\u00e3o de todos os dados entre todos os n\u00f3s do cluster, podemos mudar o aplicativo para usar o novo cluster:<\/p>\n

    \"Migra\u00e7\u00e3o
    \n
    \nAp\u00f3s essas opera\u00e7\u00f5es, basta remover os n\u00f3s antigos do cluster RabbitMQ, e a migra\u00e7\u00e3o pode ser considerada conclu\u00edda:<\/p>\n

    \"Migra\u00e7\u00e3o
    \n
    \nEste esquema foi aplicado v\u00e1rias vezes em nossa produ\u00e7\u00e3o. No entanto, para nossa conveni\u00eancia, realizamos isso em um sistema especializado que distribui configura\u00e7\u00f5es padr\u00e3o do RMQ em m\u00faltiplos clusters Kubernetes. (para aqueles que est\u00e3o curiosos: trata-se do     addon-operator<\/a><\/noindex>, sobre o qual n\u00f3s falamos recentemente.<\/a><\/noindex>)<\/i>Abaixo, estar\u00e3o apresentadas instru\u00e7\u00f5es espec\u00edficas que qualquer um pode aplicar em suas instala\u00e7\u00f5es para experimentar a solu\u00e7\u00e3o proposta em a\u00e7\u00e3o.<\/p>\n

    Vamos tentar na pr\u00e1tica.<\/h2>\n

    <\/p>\n

    Requisitos<\/h3>\n

    \nOs requisitos s\u00e3o muito simples:<\/p>\n

      \n
    1. Cluster Kubernetes (minikube tamb\u00e9m serve);<\/li>\n
    2. Cluster RabbitMQ (pode ser implementado em bare metal ou como um cluster comum em Kubernetes a partir do chart oficial do Helm).<\/li>\n<\/ol>\n

      \nPara o exemplo descrito abaixo, implantei o RMQ no Kubernetes e o nomeei como rmq-old.<\/code>.<\/p>\n

      Prepara\u00e7\u00e3o do ambiente.<\/h3>\n

      \n1. Baixaremos o chart do Helm e faremos algumas edi\u00e7\u00f5es:<\/p>\n

      helm fetch --untar stable\/rabbitmq-ha<\/code><\/pre>\n
      \nPara conveni\u00eancia, definimos a senha, ErlangCookie,<\/code> e criamos a pol\u00edtica ha-all,<\/code>para que, por padr\u00e3o, as filas sejam sincronizadas entre todos os n\u00f3s do cluster RMQ:<\/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. Instalamos o chart:<\/p>\n
      helm install . --name rmq-old --namespace rmq-old<\/code><\/pre>\n
      \n3. Acesse o painel administrativo do RabbitMQ, crie uma nova fila e adicione algumas mensagens. Elas ser\u00e3o necess\u00e1rias para que, ap\u00f3s a migra\u00e7\u00e3o, possamos garantir que todos os dados foram preservados e que n\u00e3o perdemos nada:<\/p>\n
      \"Migra\u00e7\u00e3o
      \n
      \nO ambiente de teste est\u00e1 pronto: temos um RabbitMQ 'antigo' com os dados que precisam ser transferidos.<\/p>\n
      Migra\u00e7\u00e3o do cluster RabbitMQ.<\/h3>\n
      \n1. Para come\u00e7ar, vamos implantar um novo RabbitMQ no um amigo<\/b> espa\u00e7o de nomes com as mesmas<\/b> ErlangCookie,<\/code> e senha para o usu\u00e1rio. Para isso, realizamos as opera\u00e7\u00f5es descritas acima, alterando o comando final de instala\u00e7\u00e3o do RMQ para o seguinte:<\/p>\n
      helm install . --name rmq-new --namespace rmq-new<\/code><\/pre>\n
      \n2. Agora \u00e9 necess\u00e1rio unir o novo cluster com o antigo. Para isso, acessamos cada um dos pods novos<\/b> RabbitMQ e executamos os comandos:<\/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
      \nNa vari\u00e1vel OLD_RMQ<\/code> \u00e9 o endere\u00e7o de um dos n\u00f3s do antigo<\/b> cluster RMQ.<\/p>\n
      Esses comandos interromper\u00e3o o n\u00f3 atual novos<\/b> do cluster RMQ, o conectar\u00e3o ao antigo cluster e o reiniciar\u00e3o.<\/p>\n
      3. O cluster RMQ de 6 n\u00f3s est\u00e1 pronto:<\/p>\n
      \"Migra\u00e7\u00e3o
      \n
      \n\u00c9 necess\u00e1rio esperar enquanto as mensagens s\u00e3o sincronizadas entre todos os n\u00f3s. N\u00e3o \u00e9 dif\u00edcil adivinhar que o tempo de sincroniza\u00e7\u00e3o das mensagens depende da capacidade do hardware em que o cluster est\u00e1 implementado e da quantidade de mensagens. No cen\u00e1rio descrito, h\u00e1 apenas 10, portanto os dados foram sincronizados instantaneamente, mas com um n\u00famero suficientemente grande de mensagens, a sincroniza\u00e7\u00e3o pode levar horas.<\/p>\n
      Ent\u00e3o, o status da sincroniza\u00e7\u00e3o:<\/p>\n
      \"Migra\u00e7\u00e3o
      \n
      \nAqui +5<\/code> significa que as mensagens j\u00e1 est\u00e3o ainda<\/b> em 5 n\u00f3s (al\u00e9m do que est\u00e1 indicado no campo N\u00f3<\/code>). Assim, a sincroniza\u00e7\u00e3o foi bem-sucedida.<\/p>\n
      4. Resta apenas mudar no aplicativo o endere\u00e7o RMQ para o novo cluster (as a\u00e7\u00f5es espec\u00edficas aqui dependem da pilha tecnol\u00f3gica que voc\u00ea est\u00e1 usando e de outras especificidades do aplicativo), ap\u00f3s o que voc\u00ea pode se despedir do antigo.<\/p>\n
      Para a \u00faltima opera\u00e7\u00e3o (ou seja, j\u00e1 ap\u00f3s<\/b> mudando o aplicativo para o novo cluster), acesse cada n\u00f3 do antigo<\/b> do cluster e execute os comandos:<\/p>\n
      rabbitmqctl stop_app\nrabbitmqctl reset<\/code><\/pre>\n
      \nO cluster 'esqueceu' os n\u00f3s antigos: agora voc\u00ea pode remover o antigo RMQ, e a migra\u00e7\u00e3o estar\u00e1 conclu\u00edda.<\/p>\n
      Nota<\/b>: Se voc\u00ea estiver usando RMQ com certificados, o princ\u00edpio n\u00e3o muda \u2014 o processo de migra\u00e7\u00e3o ser\u00e1 realizado exatamente da mesma forma.<\/i><\/p>\n
      Como resultado, obtemos um servi\u00e7o de \"monitoramento como servi\u00e7o\", automatizado na linha de produ\u00e7\u00e3o de integra\u00e7\u00e3o cont\u00ednua. O desenvolvedor ou testador precisa apenas definir a lista de m\u00e9tricas em um arquivo JSON, e tudo o mais acontece automaticamente. Obtemos um controle de qualidade transparente dos lan\u00e7amentos: todas as notifica\u00e7\u00f5es sobre desempenho, consumo de recursos ou regress\u00f5es arquitet\u00f4nicas.<\/h2>\n
      \nO esquema descrito \u00e9 adequado praticamente para todos os casos em que precisamos transferir o RabbitMQ ou simplesmente migrar para um novo cluster.<\/p>\n
      No nosso caso, as dificuldades ocorreram apenas uma vez, quando o RMQ era acessado de muitos locais, e n\u00e3o t\u00ednhamos a possibilidade de mudar o endere\u00e7o RMQ para o novo em todos eles. Nesse caso, executamos um novo RMQ no mesmo namespace com r\u00f3tulos iguais, para que ele se encaixasse nos servi\u00e7os e Ingress existentes, e ao iniciar o pod manualmente manipulamos os r\u00f3tulos, removendo-os no in\u00edcio, para que o RMQ vazio n\u00e3o recebesse solicita\u00e7\u00f5es, e adicionando-os de volta ap\u00f3s a sincroniza\u00e7\u00e3o das mensagens.<\/p>\n
      Aplicamos a mesma estrat\u00e9gia ao atualizar o RabbitMQ para uma nova vers\u00e3o com configura\u00e7\u00e3o alterada \u2014 tudo funcionou como um rel\u00f3gio.<\/p>\n
      P.S.<\/h2>\n
      \nComo uma continua\u00e7\u00e3o l\u00f3gica deste material, estamos preparando artigos sobre MongoDB (migra\u00e7\u00e3o de servidor f\u00edsico para Kubernetes) e MySQL (como preparamos este SGBD dentro do Kubernetes). Eles ser\u00e3o publicados nos pr\u00f3ximos meses.<\/p>\n
      P.P.S.<\/h2>\n
      \nConfira tamb\u00e9m em nosso blog:<\/p>\n