Migration en direct
Les serveurs se remplacent : le matériel vieillit, les fournisseurs changent, les régions évoluent. rdc repo migrate déplace un dépôt en cours d’exécution vers une autre machine avec une seule commande, et avec --checkpoint même la mémoire de processus fait le voyage. L’application de démonstration, pulse, maintient un compteur en RAM ; après le déplacement, il continue de compter au lieu de repartir de zéro.
Regarder le tutoriel
Comment ça se déplace
La première phase copie l’essentiel pendant que l’application continue de tourner. La deuxième phase capture les processus en direct (CRIU, pour les conteneurs étiquetés rediacc.checkpoint=true), transporte le delta final plus l’état des processus, et reprend tout sur la nouvelle machine. Le temps d’arrêt correspond au delta, pas aux données.
Étape 1 : La preuve, un compteur en RAM
rdc term connect --machine <machine-name> --repository pulse --command 'docker logs heartbeat_app --tail 5'L'application garde un compteur en mémoire et enregistre un battement toutes les cinq secondes. Le compteur vit uniquement en RAM : un redémarrage du processus le réinitialiserait à un.
memory counter=6 et il monte, un battement toutes les cinq secondes. Le compteur vit uniquement en mémoire de processus. Si le processus redémarrait, il repartirait de un.
Étape 2 : Migrer, en direct
rdc repo migrate --name pulse --from <machine-name> --to <target-machine> --checkpoint --skip-dnsMigrez avec checkpoint : la première phase transfère les 2 Go en masse pendant que la source reste en ligne, puis une courte bascule crée un checkpoint des processus en cours et transfère le delta final. La sortie affiche chaque phase et le temps d'arrêt réel.
La sortie raconte le déplacement : la première phase transfère les 2 Go en volume pendant que la source reste en ligne, puis la ligne de bascule affiche le DOWNTIME réel : quelques dizaines de mégaoctets et environ vingt secondes, pour un dépôt de deux gigaoctets.
Étape 3 : Vérifier la nouvelle destination
rdc repo list --machine <target-machine>Listez les repositories sur la machine cible : pulse est monté, Docker est en cours d'exécution et ses containers sont actifs.
Sur la cible, pulse est monté, Docker est actif, les conteneurs tournent.
Étape 4 : La source est arrêtée
rdc repo list --machine <machine-name>Sur la source, le repository est arrêté et démonté : pas de Docker, zéro container. L'image est conservée comme base pour les futurs transferts delta.
La source liste toujours le dépôt, mais honnêtement : non monté, pas de Docker, zéro conteneur. Rien ne tourne plus là-bas. L’image est conservée exprès comme base pour le prochain transfert delta, de sorte qu’un prochain push retour soit bon marché.
Étape 5 : Le compteur a continué de compter
rdc term connect --machine <target-machine> --repository pulse --command 'docker logs heartbeat_app --tail 5'Les logs sur la nouvelle machine montrent le compteur qui continue depuis l'endroit où le checkpoint l'a figé, sans se réinitialiser à un. La mémoire de processus a fait le voyage.
memory counter=17, puis 18, 19, 20… Il a repris exactement là où le checkpoint l’avait figé, au lieu de repartir de un. C’est la mémoire de processus qui fait le voyage ; l’application n’a jamais remarqué qu’elle avait changé de machine.
Sans
--checkpoint, migrate déplace quand même le disque et les conteneurs ; ils redémarrent à zéro sur la cible au lieu de reprendre en vol.
Suivant : Transfert delta.