Publié le 1 février 2024, mis à jour le 2 février 2024.
Cible de la migration sur AWS
État avant la migration
Colizey est une marketplace spécialisée dans les articles de sport. Il s’agit d’une application monolithique majoritairement développée en PHP.
Bien que déjà hébergée sur le Cloud, elle n’en tire pas tous ses avantages car est déployée sur une unique machine virtuelle, n’assurant donc aucune scalabilité de l’application, ni redondance. De plus, Colizey est administré et déployé manuellement, ce qui rend chaque mise à jour de l’application risquée car en proie aux erreurs.
Architecture cible
L’architecture cible (voir ci-dessous) que nous avons proposée à Colizey pour sa migration vers AWS se centre autour de Kubernetes. Cet orchestrateur de conteneurs open source est aujourd’hui la référence pour déployer des applications conteneurisées robustes et résilientes dans le Cloud. Kubernetes (K8s) est disponible sur AWS via Elastic Kubernetes Service (EKS) qui propose une gestion managée de K8s à ses utilisateurs (K8s est un composant complexe à installer manuellement et à maintenir).
Pour déployer en continu sur K8s l’application ainsi que les outils qui viennent autour, nous nous appuyons sur ArgoCD, un outil open source bien connu de la communauté Kubernetes, permettant de faire du GitOps : en versionnant l’état désiré de son cluster K8s dans Git, ArgoCD se charge de réconcilier en permanence l’état désiré avec l’état actuel du cluster.
Déployer une nouvelle version de son application consiste à changer un numéro de version dans un fichier, push ses changements sur Git, puis ArgoCD s’occupe du reste. Inversement, un changement manuel fait dans le cluster est immédiatement corrigé par ArgoCD.
Cela permet donc d’avoir une approche du déploiement totalement automatisée et de faire de Git l’unique source de vérité sur l’état de son cluster Kubernetes.
Déroulé du projet
Afin de mesurer le succès du projet au fur et à mesure de son avancée nous avons défini trois succès à atteindre à la fin du projet :
- Les environnements de production et sandbox de Colizey sont migrés sur AWS
- Des environnements éphémères de preview sont accessibles sur AWS
- Une pipeline de CI/CD déploie automatiquement Colizey en production
Après une phase d’avant-projet et de stratégie technique (1 semaine) nous avons défini le plan suivant pour réussir ce projet en 5 semaines :
- Mise en place de la topologie réseau / comptes en Hub & Spoke
- Création de 3 landing zones (Production, Sandbox et QA) et leur tooling (RDS, EKS, ArgoCD, DNS, ELK, etc.)
- Migration des données au fil de l’eau avec Amazon Data Migration Service
- Conteneurisation de l'application Colizey
- Mise en place de la CI/CD avec GitHub Actions
- Création des environnements de preview éphémères
- Mise en production finale
Dans cet article, concentrons-nous sur deux sujets centraux de cette migration : la migration des données, absolument critique pour mettre en production Colizey sur AWS, ainsi la création des environnements applicatifs éphémères, offrant aux développeurs une expérience flexible, dans le pur esprit DevOps.
Focus technique : Migration des données avec Amazon DMS
Amazon Data Migration Service (DMS) est un service se chargeant de migrer vos données dans AWS. DMS supporte de multiples sources de données externes (PostgreSQL, MySQL, MS SQL, Oracle, S3, MongoDB…) ainsi que de multiples cibles au sein d’AWS (RDS, S3, DynamoDB, Redis, DocumentDB, OpenSearch, etc.), il est également capable de transformer la donnée au moment de son transfert, ce qui en fait un outil puissant.
Dans le cadre de la migration de Colizey, nous nous sommes concentrés sur de la migration de PostgreSQL vers PostgreSQL, sans transformation intermédiaire. L’avantage de DMS est de pouvoir répliquer en continu les changements de la base source tant qu’il est en cours de fonctionnement, ceci afin de minimiser le retard à rattraper entre la base source et la base cible au moment final de la migration.
DMS étant connecté à l’intérieur d’un VPC (réseau privé sur votre compte AWS), il a fallu mettre en place une connectivité VPN Site-to-Site entre GCP et AWS afin que DMS puisse se connecter à la base de données source pour commencer à répliquer ses données vers la base de données RDS cible chez AWS.
Nous avons ensuite tâtonné et fait plusieurs tentatives pour choisir les bons réglages adaptés au type de données SQL à transférer. Amazon Data Migration Service propose de configurer le transfert de manière très fine (découpage en chunks, parallélisation, etc…).
Une fois le combo de réglages trouvé, nous avons attendu environ 30 heures pour migrer 1 TB de données, la totalité de la base de données source.
Cette quantité désormais transférée, DMS est passé en mode réplication continue jusqu’au moment où nous avons fait la bascule finale vers AWS et que RDS devenait la base de données de production.
Grâce à Amazon DMS, le downtime lors de la bascule vers AWS a été réduit au maximum (environ 1 heure), le temps de rattraper le retard entre les deux bases et de faire la bascule DNS.
Focus technique : Environnements éphémères avec ArgoCD
Avec Colizey sur AWS, on peut profiter du potentiel d’automatisation du cloud pour accélérer le travail des développeurs, leur faciliter la vie.
Pour permettre aux développeurs de Colizey de tester leurs changements dans un environnement le plus proche de la production, une solution que l’on voit de plus en plus émerger est celle des environnements éphémères de développement.
Lorsqu’un développeur pousse une nouvelle branche de code (contenant par exemple un bugfix, ou une nouvelle fonctionnalité), un processus automatisé va créer une instance de l’application dans un environnement dédié et permettre au développeur d’y accéder, par exemple avec une URL unique.
Pour ce faire nous avons utilisé une fonctionnalité bien utile d’ArgoCD : les ApplicationSet. Un ApplicationSet permet de déployer dynamiquement des applications dans Kubernetes en fonction d’évènements externes. Nous avons donc utilisé sa capacité de Pull Request Generator, afin de créer une instance de l’application Colizey à chaque Pull Request (demande de changement de code) ouverte par les développeurs sur GitHub.
ArgoCD déploie donc une instance de l’application correspondant à la branche poussée par le développeur, et la rend accessible sur internet, sur preview.example.com par exemple. Pour des contraintes relatives au DNS et aux certificats TLS, nous n’avons pas exposé chaque environnement sur une URL unique (par ex : feat-new-button-123abcd.preview.example.com) mais sur une URL unique pour chaque environnement avec du header-based routing.
En fonction de la valeur du header Environment, le développeur était routé sur l’environnement éphémère de son choix (voir schéma ci-dessous).
Pour réduire les coûts de cette fonctionnalité d’environ 25%, nous avons mis en place un job récurrent qui éteignait tous les environnements éphémères (en désactivant le Cluster Autoscaler). Cela réduit également l’empreinte carbone de la fonctionnalité !
Conclusion
En juin dernier, Padok a accompagné Colizey dans sa migration vers AWS en 5 semaines. De la conteneurisation à l’automatisation des déploiements en production, en passant par les environnements de preview éphémères, ce projet a permis à Colizey de réduire de 75% le temps des déploiements en production (5 min vs. 20 min) tout en réduisant le risque d’erreur grâce à leur automatisation. Sur le cloud AWS, Colizey dispose d’une disponibilité et d’une résilience accrue, étant déployée sur plusieurs zones distinctes.
Nous aidons des dizaines d’entreprises comme Colizey à réussir leur migration dans le Cloud et vers la conteneurisation. Pourquoi pas vous ? N’hésitez pas à nous contacter !