{"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\/fr\/blog\/administrirovanie\/besprostojnaya-migratsiya-rabbitmq-v-kubernetes","title":{"rendered":"Migration sans tracas de RabbitMQ vers Kubernetes","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Migration
\n
\nRabbitMQ est un broker de messages \u00e9crit en Erlang, qui permet d'organiser un cluster tol\u00e9rant aux pannes avec r\u00e9plication compl\u00e8te des donn\u00e9es sur plusieurs n\u0153uds, o\u00f9 chaque n\u0153ud peut traiter des requ\u00eates de lecture et d'\u00e9criture. Avec de nombreux clusters Kubernetes en production, nous g\u00e9rons un grand nombre d'installations de RabbitMQ et avons rencontr\u00e9 le besoin de migrer des donn\u00e9es d'un cluster \u00e0 un autre sans temps d'arr\u00eat.<\/a><\/noindex><\/p>\n

Cette op\u00e9ration \u00e9tait n\u00e9cessaire dans au moins deux cas :<\/p>\n

    \n
  1. Transf\u00e9rer des donn\u00e9es d'un cluster RabbitMQ ne fonctionnant pas sous Kubernetes vers un nouveau cluster d\u00e9j\u00e0 'kubernetis\u00e9' (c'est-\u00e0-dire fonctionnant dans des pods K8s).<\/li>\n
  2. Migrer RabbitMQ au sein de Kubernetes d'un namespace \u00e0 un autre (par exemple, si les contours sont d\u00e9limit\u00e9s par des espaces de noms, pour transf\u00e9rer l'infrastructure d'un contour \u00e0 un autre).<\/li>\n<\/ol>\n

    \nLa recette propos\u00e9e dans cet article est ax\u00e9e sur des situations (mais ne s'y limite pas) o\u00f9 il existe un ancien cluster RabbitMQ (par exemple, avec 3 n\u0153uds), qui est soit d\u00e9j\u00e0 dans K8s, soit sur d'anciens serveurs. Il est utilis\u00e9 par une application h\u00e9berg\u00e9e dans Kubernetes (d\u00e9j\u00e0 l\u00e0 ou en perspective) :<\/p>\n

    \"Migration
    \n
    \n\u2026 et nous devons le migrer vers un nouvel environnement de production dans Kubernetes.<\/p>\n

    Nous allons d'abord d\u00e9crire l'approche g\u00e9n\u00e9rale pour la migration, suivie des d\u00e9tails techniques pour sa mise en \u0153uvre.<\/p>\n

    L'algorithme de migration<\/h2>\n

    \nLa premi\u00e8re \u00e9tape, pr\u00e9liminaire, avant toute action, consiste \u00e0 v\u00e9rifier que l'ancien d\u00e9ploiement de RabbitMQ a le mode haute disponibilit\u00e9 activ\u00e9 (HA<\/a><\/noindex>). La raison est \u00e9vidente : nous ne voulons pas perdre de donn\u00e9es. Pour effectuer cette v\u00e9rification, vous pouvez acc\u00e9der \u00e0 l'interface d'administration de RabbitMQ et, sous l'onglet Admin \u2192 Policies, vous assurer que la valeur est d\u00e9finie sur ha-mode: all<\/code>:<\/p>\n

    \"Migration
    \n
    \nL'\u00e9tape suivante consiste \u00e0 d\u00e9ployer un nouveau cluster RabbitMQ dans des pods Kubernetes (dans notre cas, par exemple, compos\u00e9 de 3 n\u0153uds, mais leur nombre peut \u00eatre diff\u00e9rent).<\/p>\n

    Apr\u00e8s cela, nous fusionnons l'ancien et le nouveau cluster RabbitMQ, formant un seul cluster (compos\u00e9 de 6 n\u0153uds) :<\/p>\n

    \"Migration
    \n
    \nLe processus de synchronisation des donn\u00e9es entre l'ancien et le nouveau cluster RabbitMQ est lanc\u00e9. Une fois que toutes les donn\u00e9es sont synchronis\u00e9es entre tous les n\u0153uds du cluster, nous pouvons rediriger l'application vers le nouveau cluster :<\/p>\n

    \"Migration
    \n
    \nApr\u00e8s ces op\u00e9rations, il suffit de sortir les anciens n\u0153uds du cluster RabbitMQ, et le d\u00e9m\u00e9nagement peut \u00eatre consid\u00e9r\u00e9 comme termin\u00e9 :<\/p>\n

    \"Migration
    \n
    \nNous avons plusieurs fois appliqu\u00e9 ce sch\u00e9ma dans notre production. Cependant, pour notre propre commodit\u00e9, nous l'avons r\u00e9alis\u00e9 au sein d'un syst\u00e8me sp\u00e9cialis\u00e9 qui distribue des configurations types de RMQ sur de nombreux clusters Kubernetes. (pour ceux qui sont curieux : il s'agit de     addon-operator<\/a><\/noindex>, dont nous r\u00e9cemment, nous avons parl\u00e9<\/a><\/noindex>)<\/i>. Ci-dessous, des instructions sp\u00e9cifiques seront pr\u00e9sent\u00e9es que chacun peut appliquer sur ses installations pour essayer la solution propos\u00e9e en action.<\/p>\n

    Essayons en pratique<\/h2>\n

    <\/p>\n

    Exigences<\/h3>\n

    \nLes pr\u00e9requis sont tr\u00e8s simples :<\/p>\n

      \n
    1. Un cluster Kubernetes (minikube conviendra aussi);<\/li>\n
    2. Un cluster RabbitMQ (il peut \u00eatre d\u00e9ploy\u00e9 sur du mat\u00e9riel nu ou cr\u00e9\u00e9 comme un cluster normal dans Kubernetes \u00e0 partir du Helm chart officiel).<\/li>\n<\/ol>\n

      \nPour l'exemple d\u00e9crit ci-dessous, j'ai d\u00e9ploy\u00e9 RMQ dans Kubernetes et l'ai nomm\u00e9 rmq-old<\/code>.<\/p>\n

      Pr\u00e9paration de l'environnement<\/h3>\n

      \n1. T\u00e9l\u00e9chargeons le Helm chart et modifions-le l\u00e9g\u00e8rement :<\/p>\n

      helm fetch --untar stable\/rabbitmq-ha<\/code><\/pre>\n
      \nPour notre commodit\u00e9, d\u00e9finissons un mot de passe, ErlangCookie<\/code> et \u00e9tablissons la politique ha-all<\/code>, afin que par d\u00e9faut, les files d'attente soient synchronis\u00e9es entre tous les n\u0153uds du 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. Installons le chart :<\/p>\n
      helm install . --name rmq-old --namespace rmq-old<\/code><\/pre>\n
      \n3. Connectons-nous \u00e0 l'interface d'administration de RabbitMQ, cr\u00e9ons une nouvelle file d'attente et ajoutons quelques messages. Ils seront n\u00e9cessaires pour nous assurer qu'apr\u00e8s la migration, toutes les donn\u00e9es sont conserv\u00e9es et que rien n'est perdu :<\/p>\n
      \"Migration
      \n
      \nL'environnement de test est pr\u00eat : nous avons un RabbitMQ \u00ab ancien \u00bb avec des donn\u00e9es \u00e0 transf\u00e9rer.<\/p>\n
      Migration du cluster RabbitMQ<\/h3>\n
      \n1. Tout d'abord, d\u00e9ployons un nouveau RabbitMQ dans un autre<\/b> un espace de noms avec les m\u00eames<\/b> ErlangCookie<\/code> et mot de passe pour l'utilisateur. Pour cela, ex\u00e9cutons les op\u00e9rations d\u00e9crites ci-dessus, en modifiant la commande finale d'installation de RMQ comme suit :<\/p>\n
      helm install . --name rmq-new --namespace rmq-new<\/code><\/pre>\n
      \n2. Maintenant, il faut joindre le nouveau cluster \u00e0 l'ancien. Pour cela, nous entrons dans chacun des pod\u2019 de du nouveau<\/b> RabbitMQ et ex\u00e9cutons les commandes :<\/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
      \nDans la variable OLD_RMQ<\/code> indique l'adresse d'un des n\u0153uds de l'ancien<\/b> cluster RMQ.<\/p>\n
      Ces commandes arr\u00eateront le n\u0153ud actuel du nouveau<\/b> du cluster RMQ, l'ajouteront \u00e0 l'ancien cluster et le red\u00e9marreront.<\/p>\n
      3. Le cluster RMQ compos\u00e9 de 6 n\u0153uds est pr\u00eat :<\/p>\n
      \"Migration
      \n
      \nVous devez attendre que les messages soient synchronis\u00e9s entre tous les n\u0153uds. Il est facile de deviner que le temps de synchronisation des messages d\u00e9pend de la puissance du mat\u00e9riel sur lequel le cluster est d\u00e9ploy\u00e9 et du nombre de messages. Dans le sc\u00e9nario d\u00e9crit, il n'y en a que 10, donc les donn\u00e9es se sont synchronis\u00e9es instantan\u00e9ment, mais avec un nombre de messages suffisamment \u00e9lev\u00e9, la synchronisation peut durer des heures.<\/p>\n
      Alors, le statut de synchronisation :<\/p>\n
      \"Migration
      \n
      \nIci +5<\/code> signifie que les messages se trouvent d\u00e9j\u00e0 encore<\/b> sur 5 n\u0153uds (en plus de celui indiqu\u00e9 dans le champ N\u0153ud<\/code>). Ainsi, la synchronisation a r\u00e9ussi.<\/p>\n
      4. Il ne reste plus qu'\u00e0 changer l'adresse RMQ dans l'application pour le nouveau cluster (les actions sp\u00e9cifiques ici d\u00e9pendent de la pile technologique que vous utilisez et d'autres sp\u00e9cificit\u00e9s de l'application), apr\u00e8s quoi vous pouvez faire vos adieux au pr\u00e9c\u00e9dent.<\/p>\n
      Pour la derni\u00e8re op\u00e9ration (c'est-\u00e0-dire le apr\u00e8s<\/b> changement d'application vers le nouveau cluster), connectez-vous \u00e0 chaque n\u0153ud de l'ancien<\/b> du cluster et ex\u00e9cutez les commandes :<\/p>\n
      rabbitmqctl stop_app\nrabbitmqctl reset<\/code><\/pre>\n
      \nLe cluster a \u00ab oubli\u00e9 \u00bb les anciens n\u0153uds : vous pouvez supprimer l'ancien RMQ, ce qui conclura le d\u00e9m\u00e9nagement.<\/p>\n
      Remarque<\/b>: Si vous utilisez RMQ avec des certificats, rien ne change fondamentalement \u2014 le processus de d\u00e9m\u00e9nagement se fera exactement de la m\u00eame mani\u00e8re.<\/i><\/p>\n
      Conclusions<\/h2>\n
      \nLe sch\u00e9ma d\u00e9crit convient pratiquement \u00e0 tous les cas o\u00f9 nous devons transf\u00e9rer RabbitMQ ou simplement d\u00e9m\u00e9nager vers un nouveau cluster.<\/p>\n
      Dans notre cas, des difficult\u00e9s n'ont surgi qu'une fois, lorsque RMQ \u00e9tait consult\u00e9 depuis de nombreux endroits, et nous n'avions pas la possibilit\u00e9 de changer l'adresse RMQ sur chacun d'eux. Alors, nous avons lanc\u00e9 un nouveau RMQ dans le m\u00eame espace de noms avec les m\u00eames \u00e9tiquettes, afin qu'il s'int\u00e8gre aux services et Ingress existants, et en lan\u00e7ant le pod manuellement, nous avons manipul\u00e9 les \u00e9tiquettes, en les supprimant d'abord pour que les requ\u00eates n'atteignent pas le RMQ vide, puis en les ajoutant \u00e0 nouveau apr\u00e8s la synchronisation des messages.<\/p>\n
      Nous avons appliqu\u00e9 la m\u00eame strat\u00e9gie lors de la mise \u00e0 jour de RabbitMQ vers une nouvelle version avec une configuration modifi\u00e9e \u2014 tout a fonctionn\u00e9 comme sur des roulettes.<\/p>\n
      P.S.<\/h2>\n
      \nComme suite logique \u00e0 ce mat\u00e9riau, nous pr\u00e9parons des articles sur MongoDB (migration d'un serveur physique vers Kubernetes) et MySQL (comment nous pr\u00e9parons ce SGBD dans Kubernetes). Ils seront publi\u00e9s dans les mois \u00e0 venir.<\/p>\n
      P.P.S.<\/h2>\n
      \nLisez aussi dans notre blog :<\/p>\n