{"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\/es\/blog\/administrirovanie\/besprostojnaya-migratsiya-rabbitmq-v-kubernetes","title":{"rendered":"Migraci\u00f3n no trivial de RabbitMQ en Kubernetes","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Migraci\u00f3n
\n
\nRabbitMQ es un broker de mensajes escrito en Erlang que permite organizar un cl\u00faster tolerante a fallos con replicaci\u00f3n completa de datos en varios nodos, donde cada nodo puede manejar solicitudes de lectura y escritura. Habiendo utilizado m\u00faltiples cl\u00fasteres de Kubernetes en producci\u00f3n, soportamos una gran cantidad de instalaciones de RabbitMQ y hemos enfrentado la necesidad de migrar datos de un cl\u00faster a otro sin tiempo de inactividad.<\/a><\/noindex><\/p>\n

Esta operaci\u00f3n fue necesaria para nosotros en al menos dos casos:<\/p>\n

    \n
  1. Transferir datos de un cl\u00faster de RabbitMQ que no est\u00e1 en Kubernetes a un nuevo cl\u00faster que ya est\u00e1 \"kubernetizado\" (es decir, funcionando en pods de K8s).<\/li>\n
  2. Migrar RabbitMQ dentro de Kubernetes de un namespace a otro (por ejemplo, si los contornos est\u00e1n delimitados por espacios de nombres, para trasladar infraestructura de un contorno a otro).<\/li>\n<\/ol>\n

    \nLa receta propuesta en este art\u00edculo est\u00e1 orientada a situaciones (pero no se limita a ellas) en las que hay un antiguo cl\u00faster de RabbitMQ (por ejemplo, de 3 nodos), que est\u00e1 ya en K8s o en algunos servidores antiguos. Est\u00e1 asociado a una aplicaci\u00f3n que se ubica en Kubernetes (ya sea all\u00ed o en perspectiva):<\/p>\n

    \"Migraci\u00f3n
    \n
    \n\u2026 y se nos presenta la tarea de migrarlo a un nuevo entorno de producci\u00f3n en Kubernetes.<\/p>\n

    Primero se describir\u00e1 el enfoque general para la migraci\u00f3n, y luego se detallar\u00e1n los aspectos t\u00e9cnicos de su implementaci\u00f3n.<\/p>\n

    Algoritmo de migraci\u00f3n<\/h2>\n

    \nEl primer paso preliminar antes de cualquier acci\u00f3n es verificar que la antigua instalaci\u00f3n de RabbitMQ tiene activado el modo de alta disponibilidad (HA<\/a><\/noindex>). La raz\u00f3n es evidente: no queremos perder ning\u00fan dato. Para llevar a cabo esta verificaci\u00f3n, se puede acceder al panel de administraci\u00f3n de RabbitMQ y en la pesta\u00f1a Admin \u2192 Policies asegurarse de que est\u00e1 configurado el valor ha-mode: all<\/code>:<\/p>\n

    \"Migraci\u00f3n
    \n
    \nEl siguiente paso es levantar un nuevo cl\u00faster de RabbitMQ en pods de Kubernetes (en nuestro caso, por ejemplo, compuesto por 3 nodos, pero puede ser cualquier otro n\u00famero).<\/p>\n

    Despu\u00e9s de esto, combinamos el antiguo y el nuevo cl\u00faster de RabbitMQ, obteniendo un \u00fanico cl\u00faster (de 6 nodos):<\/p>\n

    \"Migraci\u00f3n
    \n
    \nSe inicia el proceso de sincronizaci\u00f3n de datos entre el antiguo y el nuevo cl\u00faster de RabbitMQ. Despu\u00e9s de que todos los datos se sincronicen entre todos los nodos del cl\u00faster, podemos cambiar la aplicaci\u00f3n para usar el nuevo cl\u00faster:<\/p>\n

    \"Migraci\u00f3n
    \n
    \nDespu\u00e9s de estas operaciones, es suficiente desconectar los antiguos nodos del cl\u00faster de RabbitMQ y se puede considerar finalizada la migraci\u00f3n:<\/p>\n

    \"Migraci\u00f3n
    \n
    \nHemos utilizado este esquema en producci\u00f3n en varias ocasiones. Sin embargo, para nuestra propia comodidad, lo implementamos en el marco de un sistema especializado que distribuye configuraciones est\u00e1ndar de RMQ en m\u00faltiples cl\u00fasteres de Kubernetes. (para aquellos a quienes les interese: se trata de     addon-operator<\/a><\/noindex>, del cual ya hemos recientemente hablamos de<\/a><\/noindex>)<\/i>. A continuaci\u00f3n se presentar\u00e1n instrucciones espec\u00edficas que cada uno puede aplicar en sus instalaciones para probar la soluci\u00f3n propuesta en acci\u00f3n.<\/p>\n

    Probando en la pr\u00e1ctica<\/h2>\n

    <\/p>\n

    Requisitos<\/h3>\n

    \nLos requisitos son muy sencillos:<\/p>\n

      \n
    1. Cl\u00faster de Kubernetes (tambi\u00e9n sirve minikube);<\/li>\n
    2. Un cl\u00faster RabbitMQ (que puede estar desplegado en bare metal o configurado como un cl\u00faster est\u00e1ndar en Kubernetes utilizando el Helm chart oficial).<\/li>\n<\/ol>\n

      \nPara el ejemplo a continuaci\u00f3n, desplegu\u00e9 RMQ en Kubernetes y lo llam\u00e9 rmq-old<\/code>.<\/p>\n

      Preparaci\u00f3n del entorno<\/h3>\n

      \n1. Descargamos el Helm chart y lo editamos un poco:<\/p>\n

      helm fetch --untar stable\/rabbitmq-ha<\/code><\/pre>\n
      \nPor comodidad, establecemos una contrase\u00f1a, ErlangCookie<\/code> y creamos una pol\u00edtica ha-all<\/code>, para que por defecto las colas se sincronicen entre todos los nodos del cl\u00faster 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 el chart:<\/p>\n
      helm install . --name rmq-old --namespace rmq-old<\/code><\/pre>\n
      \n3. Entramos en la interfaz de administraci\u00f3n de RabbitMQ, creamos una nueva cola y a\u00f1adimos algunos mensajes. Los necesitaremos para asegurarnos, despu\u00e9s de la migraci\u00f3n, de que todos los datos se han preservado y no hemos perdido nada:<\/p>\n
      \"Migraci\u00f3n
      \n
      \nEl entorno de prueba est\u00e1 listo: tenemos un RabbitMQ \"antiguo\" con datos que deben ser transferidos.<\/p>\n
      Migraci\u00f3n del cl\u00faster RabbitMQ<\/h3>\n
      \n1. Primero, desplegaremos un nuevo RabbitMQ en otra<\/b> un espacio de nombres con las mismas<\/b> ErlangCookie<\/code> y contrase\u00f1a para el usuario. Para ello, realizaremos las operaciones descritas anteriormente, modificando el comando final para la instalaci\u00f3n de RMQ de la siguiente manera:<\/p>\n
      helm install . --name rmq-new --namespace rmq-new<\/code><\/pre>\n
      \n2. Ahora es necesario unir el nuevo cl\u00faster con el antiguo. Para ello, accedemos a cada uno de los pod nuevo<\/b> RabbitMQ y ejecutamos los 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
      \nEn la variable OLD_RMQ<\/code> es la direcci\u00f3n de uno de los nodos del antiguo<\/b> cl\u00faster RMQ.<\/p>\n
      Estos comandos detendr\u00e1n el nodo actual nuevo<\/b> del cl\u00faster RMQ, lo unir\u00e1n al cl\u00faster antiguo y lo reiniciar\u00e1n.<\/p>\n
      3. El cl\u00faster RMQ de 6 nodos est\u00e1 listo:<\/p>\n
      \"Migraci\u00f3n
      \n
      \nHay que esperar a que los mensajes se sincronicen entre todos los nodos. No es dif\u00edcil adivinar que el tiempo de sincronizaci\u00f3n de mensajes depende de la capacidad del hardware en el que se despliega el cl\u00faster y de la cantidad de mensajes. En el escenario descrito, hay solo 10, por lo que los datos se sincronizaron instant\u00e1neamente, pero con una cantidad significativamente mayor de mensajes, la sincronizaci\u00f3n puede llevar horas.<\/p>\n
      As\u00ed que, el estado de sincronizaci\u00f3n:<\/p>\n
      \"Migraci\u00f3n
      \n
      \nAqu\u00ed +5<\/code> significa que los mensajes ya est\u00e1n a\u00fan<\/b> en 5 nodos (adem\u00e1s del que se indica en el campo Nodo<\/code>). As\u00ed, la sincronizaci\u00f3n fue exitosa.<\/p>\n
      4. Solo queda cambiar en la aplicaci\u00f3n la direcci\u00f3n de RMQ al nuevo cl\u00faster (las acciones espec\u00edficas aqu\u00ed dependen de la pila tecnol\u00f3gica que est\u00e9s usando y de otras especificidades de la aplicaci\u00f3n), despu\u00e9s de lo cual puedes despedirte del antiguo.<\/p>\n
      Para la \u00faltima operaci\u00f3n (es decir, ya despu\u00e9s de<\/b> cambiando la aplicaci\u00f3n al nuevo cl\u00faster) accedemos a cada nodo del antiguo<\/b> del cl\u00faster y ejecutamos los comandos:<\/p>\n
      rabbitmqctl stop_app\nrabbitmqctl reset<\/code><\/pre>\n
      \nEl cl\u00faster \"ha olvidado\" acerca de los antiguos nodos: se puede eliminar el viejo RMQ, completando as\u00ed la migraci\u00f3n.<\/p>\n
      Nota<\/b>: Si utilizas RMQ con certificados, entonces no hay cambios fundamentales: el proceso de migraci\u00f3n se llevar\u00e1 a cabo exactamente de la misma manera.<\/i><\/p>\n
      Conclusiones<\/h2>\n
      \nEl esquema descrito se adapta pr\u00e1cticamente a todos los casos en que necesitamos trasladar RabbitMQ o simplemente mudarnos a un nuevo cl\u00faster.<\/p>\n
      En nuestro caso, solo tuvimos dificultades una vez, cuando RMQ fue accedido desde m\u00faltiples lugares, y no tuvimos la oportunidad de cambiar la direcci\u00f3n de RMQ a la nueva en todos los lugares. En ese caso, lanzamos un nuevo RMQ en el mismo espacio de nombres con las mismas etiquetas, para que se incluyera en los servicios y Ingress ya existentes, y al iniciar el pod, manipulamos las etiquetas manualmente, elimin\u00e1ndolas al principio para que las solicitudes no llegaran al RMQ vac\u00edo, y volvi\u00e9ndolas a a\u00f1adir despu\u00e9s de la sincronizaci\u00f3n de mensajes.<\/p>\n
      Aplicamos la misma estrategia al actualizar RabbitMQ a una nueva versi\u00f3n con una configuraci\u00f3n modificada: todo funcion\u00f3 a la perfecci\u00f3n.<\/p>\n
      P.D.<\/h2>\n
      \nComo continuaci\u00f3n l\u00f3gica de este material, estamos preparando art\u00edculos sobre MongoDB (migraci\u00f3n de un servidor f\u00edsico a Kubernetes) y MySQL (c\u00f3mo preparamos esta base de datos dentro de Kubernetes). Se publicar\u00e1n en los pr\u00f3ximos meses.<\/p>\n
      P.P.D.<\/h2>\n
      \nTambi\u00e9n puedes leer en nuestro blog:<\/p>\n