{"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\/it\/blog\/administrirovanie\/besprostojnaya-migratsiya-rabbitmq-v-kubernetes","title":{"rendered":"Migrazione non semplice di RabbitMQ in Kubernetes","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Migrazione
\n
\nRabbitMQ \u2013 un broker di messaggi scritto in Erlang, che consente di organizzare un cluster di alta disponibilit\u00e0 con replicazione completa dei dati su pi\u00f9 nodi, dove ciascun nodo pu\u00f2 gestire richieste di lettura e scrittura. Avendo in produzione diversi cluster Kubernetes, supportiamo un grande numero di installazioni di RabbitMQ e ci siamo trovati di fronte alla necessit\u00e0 di migrare dati da un cluster all'altro senza inattivit\u00e0.<\/a><\/noindex><\/p>\n

Questa operazione \u00e8 stata necessaria almeno in due casi:<\/p>\n

    \n
  1. Trasferimento di dati da un cluster RabbitMQ che non si trova in Kubernetes a un nuovo cluster gi\u00e0 'kubernetesizzato' (cio\u00e8 funzionante in pod K8s).<\/li>\n
  2. Migrazione di RabbitMQ all'interno di Kubernetes da uno namespace a un altro (ad esempio, se i confini sono delimitati dagli spazi dei nomi, per trasferire l'infrastruttura da un confine all'altro).<\/li>\n<\/ol>\n

    \nLa ricetta proposta nell'articolo \u00e8 orientata a situazioni (ma non \u00e8 limitata a queste) in cui esiste un vecchio cluster RabbitMQ (ad esempio, composto da 3 nodi), che si trova gi\u00e0 in K8s o su alcuni vecchi server. Esso \u00e8 utilizzato da un'applicazione ospitata in Kubernetes (gi\u00e0 l\u00ec o in prospettiva):<\/p>\n

    \"Migrazione
    \n
    \n\u2026 e ora abbiamo il compito di migrare in un nuovo production in Kubernetes.<\/p>\n

    Inizialmente verr\u00e0 descritto l'approccio generale alla migrazione, seguito dai dettagli tecnici per la sua implementazione.<\/p>\n

    Algoritmo di migrazione<\/h2>\n

    \nIl primo passo preliminare, prima di intraprendere qualsiasi azione, \u00e8 verificare che nella vecchia installazione di RabbitMQ sia attivata la modalit\u00e0 di alta disponibilit\u00e0 (HA<\/a><\/noindex>). Il motivo \u00e8 ovvio: non vogliamo perdere alcun dato. Per effettuare questa verifica, \u00e8 possibile accedere all'interfaccia di amministrazione di RabbitMQ e nella scheda Admin \u2192 Policies assicurarsi che sia impostato il valore ha-mode: all<\/code>:<\/p>\n

    \"Migrazione
    \n
    \nIl passo successivo consiste nel sollevare un nuovo cluster RabbitMQ nei pod di Kubernetes (nel nostro caso, ad esempio, composto da 3 nodi, ma il numero pu\u00f2 variare).<\/p>\n

    Dopo di ci\u00f2 uniamo i cluster RabbitMQ vecchio e nuovo, ottenendo un unico cluster (di 6 nodi):<\/p>\n

    \"Migrazione
    \n
    \nSi avvia il processo di sincronizzazione dei dati tra i vecchi e i nuovi cluster RabbitMQ. Una volta che tutti i dati sono sincronizzati tra i nodi nel cluster, possiamo switchare l'applicazione per utilizzare il nuovo cluster:<\/p>\n

    \"Migrazione
    \n
    \nDopo queste operazioni \u00e8 sufficiente rimuovere i vecchi nodi dal cluster RabbitMQ, e il trasferimento pu\u00f2 considerarsi completato:<\/p>\n

    \"Migrazione
    \n
    \nQuesto schema \u00e8 stato applicato pi\u00f9 volte nel nostro ambiente di produzione. Tuttavia, per comodit\u00e0, lo abbiamo implementato all'interno di un sistema specializzato che distribuisce configurazioni standard di RMQ su pi\u00f9 cluster Kubernetes. (per coloro che sono curiosi: si tratta di     addon-operator<\/a><\/noindex>, di cui noi abbiamo parlato recentemente<\/a><\/noindex>)<\/i>. Di seguito verranno presentate istruzioni specifiche che chiunque pu\u00f2 applicare alle proprie installazioni per provare la soluzione proposta in azione.<\/p>\n

    Proviamo nella pratica<\/h2>\n

    <\/p>\n

    Requisiti<\/h3>\n

    \nI requisiti sono molto semplici:<\/p>\n

      \n
    1. Cluster Kubernetes (va bene anche minikube);<\/li>\n
    2. Un cluster RabbitMQ (che pu\u00f2 essere distribuito su bare metal o creato come un normale cluster in Kubernetes usando il chart Helm ufficiale).<\/li>\n<\/ol>\n

      \nPer l'esempio descritto di seguito, ho distribuito RMQ in Kubernetes e l'ho chiamato rmq-old<\/code>.<\/p>\n

      Preparazione dell'ambiente<\/h3>\n

      \n1. Scarichiamo il chart Helm e apportiamo alcune modifiche:<\/p>\n

      helm fetch --untar stable\/rabbitmq-ha<\/code><\/pre>\n
      \nPer comodit\u00e0, impostiamo la password, ErlangCookie<\/code> e definiamo la politica ha-all<\/code>, affinch\u00e9, per impostazione predefinita, le code siano sincronizzate tra tutti i nodi del 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. Installiamo il chart:<\/p>\n
      helm install . --name rmq-old --namespace rmq-old<\/code><\/pre>\n
      \n3. Accediamo all'interfaccia di amministrazione di RabbitMQ, creiamo una nuova coda e aggiungiamo alcuni messaggi. Questi saranno necessari per assicurarci, dopo la migrazione, che tutti i dati siano stati conservati e che nulla sia andato perso:<\/p>\n
      \"Migrazione
      \n
      \nIl banco di prova \u00e8 pronto: abbiamo un 'vecchio' RabbitMQ con i dati da trasferire.<\/p>\n
      Migrazione del cluster RabbitMQ<\/h3>\n
      \n1. Iniziamo a distribuire un nuovo RabbitMQ in amico<\/b> uno spazio dei nomi con le stesse<\/b> ErlangCookie<\/code> credenziali e password per l'utente. A tal fine, eseguiamo le operazioni descritte sopra, modificando il comando finale per l'installazione di RMQ nella seguente maniera:<\/p>\n
      helm install . --name rmq-new --namespace rmq-new<\/code><\/pre>\n
      \n2. Ora \u00e8 necessario unire il nuovo cluster a quello esistente. Per farlo, accediamo a ciascun pod di del nuovo<\/b> RabbitMQ ed eseguiamo i comandi:<\/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
      \nNella variabile OLD_RMQ<\/code> \u00e8 l'indirizzo di uno dei nodi del vecchio<\/b> cluster RMQ.<\/p>\n
      Questi comandi fermeranno il nodo corrente del nuovo<\/b> del cluster RMQ, lo uniranno al vecchio cluster e lo riavvieranno.<\/p>\n
      3. Il cluster RMQ composto da 6 nodi \u00e8 pronto:<\/p>\n
      \"Migrazione
      \n
      \n\u00c8 necessario attendere che i messaggi vengano sincronizzati tra tutti i nodi. \u00c8 facile intuire che il tempo di sincronizzazione dei messaggi dipende dalle capacit\u00e0 dell'hardware su cui \u00e8 effettuato il cluster e dal numero di messaggi. Nel caso descritto, ce ne sono solo 10, quindi i dati si sono sincronizzati immediatamente, ma con un numero sufficientemente elevato di messaggi la sincronizzazione pu\u00f2 richiedere ore.<\/p>\n
      Quindi, lo stato di sincronizzazione:<\/p>\n
      \"Migrazione
      \n
      \nQui +5<\/code> significa che i messaggi sono gi\u00e0 presenti ancora<\/b> su 5 nodi (oltre a quello indicato nel campo Node<\/code>). Pertanto, la sincronizzazione \u00e8 avvenuta con successo.<\/p>\n
      4. Resta solo da cambiare nell'app l'indirizzo RMQ al nuovo cluster (le azioni specifiche qui dipendono dalla tecnologia utilizzata e da altre specifiche dell'applicazione), dopo di che si pu\u00f2 salutare il vecchio.<\/p>\n
      Per l'ultima operazione (ossia dopo<\/b> cambiare l'app al nuovo cluster) accediamo a ciascun nodo del vecchio<\/b> del cluster ed eseguiamo i comandi:<\/p>\n
      rabbitmqctl stop_app\nrabbitmqctl reset<\/code><\/pre>\n
      \nIl cluster ha \u201cdimenticato\u201d i vecchi nodi: si pu\u00f2 eliminare il vecchio RMQ, completando cos\u00ec la migrazione.<\/p>\n
      Nota<\/b>: Se stai utilizzando RMQ con certificati, il principio rimane invariato: il processo di migrazione avverr\u00e0 esattamente nello stesso modo.<\/i><\/p>\n
      Conclusioni<\/h2>\n
      \nLo schema descritto si adatta praticamente a tutti i casi in cui dobbiamo trasferire RabbitMQ o semplicemente migrare a un nuovo cluster.<\/p>\n
      Nel nostro caso, abbiamo incontrato difficolt\u00e0 solo una volta, quando RMQ veniva utilizzato da molteplici origini e non avevamo la possibilit\u00e0 di cambiare l'indirizzo di RMQ ovunque. Allora abbiamo avviato un nuovo RMQ nello stesso namespace con etichette identiche, affinch\u00e9 venisse intercettato dai servizi e dagli Ingress gi\u00e0 esistenti, e durante l'avvio del pod abbiamo manipolato le etichette manualmente, rimuovendole inizialmente per impedire che le richieste arrivassero al nuovo RMQ vuoto, aggiungendole nuovamente dopo la sincronizzazione dei messaggi.<\/p>\n
      Abbiamo applicato la stessa strategia durante l'aggiornamento di RabbitMQ a una nuova versione con configurazione modificata: tutto ha funzionato alla perfezione.<\/p>\n
      P.S.<\/h2>\n
      \nCome logico seguito a questo materiale, stiamo preparando articoli su MongoDB (migrazione da server fisico a Kubernetes) e MySQL (come prepariamo questo DBMS all'interno di Kubernetes). Saranno pubblicati nei prossimi mesi.<\/p>\n
      P.P.S.<\/h2>\n
      \nLeggete anche nel nostro blog:<\/p>\n