Projet Storky : automatiser la migration des applications et des données entre les régions

Alors que Scalingo est désormais disponible dans plusieurs centres de données (appelés régions) et que nous prévoyons d'en ouvrir d'autres à l'avenir, nos clients ressentaient le besoin d'avoir les outils pour migrer leurs données et applications d'une région à l'autre. C'est pourquoi le "Projet Storky" a vu le jour. Nous avons le plaisir d'annoncer aujourd'hui que ce projet a vu le jour : vous avez maintenant la possibilité de migrer des applications d'une région à une autre par vous-même.

Storky en Action

Storky est le nom interne du service chargé de gérer la migration des applications et de leurs données entre les régions. C'est un clin d'œil au cigogne, l'animal emblématique de la région d'origine de Scalingo. Cet animal est connu pour sa capacité à livrer de nouveaux bébés au seuil des nouveaux parents (oui, c'est ainsi que les bébés sont fabriqués ici !). Cette tâche nécessite une grande attention car le colis que porte une cigogne est délicat ! C'est ainsi que nous voyons la migration de vos applications : une tâche difficile qui nécessite une grande attention pour manipuler un colis composé de nombreuses pièces mobiles.

Avec la sortie de Storky, vos migrations d'applications sont dans des mains sûres (ou devrais-je dire "bec" !). Suivez-nous dans ce guide sur la manière dont vous pouvez concrètement migrer vos applications d'une région à une autre.

Migration d'une Application

La migration d'une application s'effectue à l'aide de l'outil en ligne de commande de Scalingo. Veuillez l'installer avant de continuer.

Migrer une application avec notre CLI d'une région à une autre est complètement automatique. Le processus réel est divisé en 4 étapes indépendantes. Chacune d'elles peut être annulée à tout moment.

1. Création de la migration : où nous vérifions que la migration est faisable ; cette étape renvoie un identifiant de migration qui sera nécessaire pour exécuter les étapes suivantes ou pour abandonner la migration.

2. Préparation de la migration : où nous copions le squelette (l'application, les collaborateurs, sa configuration).

3. Migrer les données : cette étape est optionnelle. Toutes les bases de données sont prises en charge sauf InfluxDB.

4. Finalisation de la migration : où nous démarrons la nouvelle application et redirigeons le trafic de l'ancienne application.

Pendant les étapes 1 et 2, l'application source continuera de fonctionner, recevra toujours du trafic. Seules ses paramètres seront gelés pour éviter les interactions avec la plateforme qui pourraient affecter la migration.

Ce n'est qu'au cours des étapes 3 et 4 que l'application source est arrêtée. Cela signifie que le temps d'arrêt attendu et inévitable pour une migration est la durée de la sauvegarde des données de la base de données source et de la restauration des données dans la base de données cible.

Vous pouvez trouver tous les détails techniques concernant chaque étape et comment les exécuter sur la page de documentation "Migration d'Application entre Régions".

Qu'est-ce qui Peut Être Migré ?

Notre outil de migration peut gérer la migration complète d'une application d'une région à une autre !

Pour être plus précis, il va :

• répliquer la formation des conteneurs (nombre, type et taille de la flotte de vos conteneurs)

• copier les paramètres avancés (domaine canonique, forcer HTTPS, sessions persistantes)

• importer les limites douces de l'application (telles que la taille maximale de l'image)

• importer la build qui est actuellement en cours d'exécution sur l'application source (le dernier déploiement réussi)

• importer les variables d'environnement

• importer les collaborateurs qui ont accepté l'invitation (les collaborateurs en attente ne sont pas importés)

• importer l'intégration SCM (GitHub, GitLab, etc.)

• importer les domaines et leurs certificats (à la fois de Let’s Encrypt et ceux ajoutés manuellement)

• importer les notificateurs et les alertes configurées

• importer les drains de logs

• importer les autoscalers

Storky peut également migrer vos données.

Voici les étapes suivies par Storky pour chacun de vos addons provisionnés :

• provisionner une base de données avec le même plan et la même version

• déclencher une sauvegarde sur la base de données source

• une fois ces deux opérations terminées, il restaurera la sauvegarde sur la base de données cible

Inconvénients

Bien que notre objectif initial avec le Projet Storky soit de fournir un outil de migration tout-en-un et complètement automatique, il présente quelques inconvénients.

Les drains de journaux sur les bases de données et la configuration MySQL personnalisée ne seront pas migrés. Si cela vous préoccupe, demandez au support de les activer sur votre application cible.

Si vous utilisez un dépôt distant git sur Scalingo (c'est-à-dire si vous n'utilisez pas notre intégration GitHub ou GitLab), ce dépôt ne sera pas migré. Ce n'est pas vraiment un problème. Vous pourrez lancer git push sur le dépôt cible.

Les vérifications préalables à la migration généreront des erreurs si vous utilisez l'un des éléments suivants : ajout TCP, ajout VPN, ajout Docker ou ajout InfluxDB. Dans ce cas, vous pouvez contacter le support pour obtenir une assistance supplémentaire.

Conclusion

L'objectif de Scalingo est d'automatiser autant de choses que possible pour faciliter la vie d'un développeur. La disponibilité de cet outil est une nouvelle étape obligatoire dans cette direction. Avec les projets de Scalingo d'étendre de nouvelles régions au cours de l'année 2020, cet outil deviendra de plus en plus important pour nos clients.