Les plus assidus d’entre vous l’auront constaté, il y a eu du changement dans votre barre d’adresse ces dernières semaines. En effet, le blog a basculé de https://blog.d2si.io en https://blog.revolve.team.

Mais alors comment on a fait ? Je ne pouvais évidemment pas rater l’occasion de faire un article opportuniste sur notre migration de domaine et les impacts que cela a pour un wordpress hébergé dans AWS.

Once upon a time

Historiquement, ce composant peu prioritaire dans l’infrastructure de D2SI a été maintenu en “best effort”, et la structure était minimale:

• Une machine EC2 Ubuntu dans un subnet public
• Une IP fixe branchée sur la machine
• Un wordpress installé sur la machine
• Une base de données RDS
• Un domaine sur l’IP fixe
• Un certificat let’s encrypt
• Un cron pour pousser des backups dans S3 tous les jours
• C’est tout

Ça a marché pendant des années, mais il était temps de faire évoluer cette infrastructure, car:

1. La connaissance de ce composant s’était peu à peu effritée au fil des départs ou des actions manuelles réalisées dessus par les différents intervenants
2. Le besoin de reproduire facilement l’installation de ce composant sur un écosystème “de dev” pour tester des choses se faisait de plus en plus fréquente
3. La nécessité de renforcer la stratégie de backup était un sujet majeur (si le cron de la machine s’était arrêté, personne ne l’aurait jamais su)

Nous avions donc déjà, en début d’année 2020, automatisé tout ce composant en suivant le schéma d’architecture du whitepaper d’AWS:

• Fini le cron pour les backups, cela sera désormais porté par Aurora et AWS Backup pour l’EFS et les EBS.
• Fini le certificat let’s encrypt qui, quand certbot plante, ne se renouvelle pas tout seul: on utilise désormais AWS Certificate Manager.
• Tout automatique, tout Terraform et intégré à notre GitLab: créer un réplica de dev pour tester des trucs prend quelques minutes seulement.

Know Your enemy

Comme vous l’avez-vu au paragraphe précédent, je connaissais bien la bestiole. Il est temps de présenter un schéma simplifié de son architecture :

Une telle phase d’analyse, si nous n’avions pas récemment réécrit l’infrastructure aurait été dans tous les cas primordiale.

Plan, Prepare, Repeat

Sachez que comme dans un tour de magie en close-up, je ne me suis pas pointé le jour du spectacle en mode “allez j’vous le fais j’ai vu un tuto YouTube”. Une telle bascule nécessite quelques jours de préparation pour sécuriser les 3 piliers de toute migration réussie.

1. Planifier. J’aime planifier. Ecrire des documents de plusieurs centaines de mots décrivant ce qu’on va faire et ce qui va se passer. Faire des diagrammes. Faire des hypothèses. Trouver des solutions. Avoir un plan, mec, c’est la base.

L’objectif était de préparer le nouveau domaine en réalisant les pointages DNS en avance pour avoir une propagation complète et avoir la capacité de basculer les redirections de manière applicative pour une apparition en un claquement de doigts.

Je ne vous détaillerai pas tout mon plan car il était long, mais globalement, l’idée de base était de faire porter dans un premier temps la redirection par WordPress afin de fournir la souplesse de la bascule et du rollback du côté de l’interface d’administration, qui est maîtrisée par l’équipe marketing, puis dans un second temps de déporter ce traitement redirections sur le load balancer applicatif AWS pour réduire la charge d’une requête “inutile” sur le composant PHP.

2. Préparer. Avoir un plan c’est bien, avoir ce qu’il faut pour l’appliquer, c’est mieux.

La stratégie était:

• Avoir le contrôle sur le domaine cible pour créer des certificats dans AWS.
• Valider la possibilité de double certificat dans le load balancer.
• Valider le comportement de WordPress lorsqu’une requête arrive avec un host différent de celui configuré.
• Avoir ou assimiler les compétences AWS et WordPress nécessaires pour réagir en cas d’ennui le jour X (dont la date est restée inconnue assez longtemps).

3. Répéter. Comme l’a récemment rappelé le directeur de l’OMS sur un autre sujet qui n’a rien à voir, il est primordial de tester, tester et tester encore.

Nous avons testé avec des domaines inutilisés, que nous avions en stock, une bascule de l’environnement de dev entre deux domaines pour valider l’implacable -que dis-je- l’infaillible plan de plusieurs de lignes que j’avais écrit avec tout le détail de l’opération. Évidemment, suite aux différents tests nous avons ajusté certains paramètres du génial plan que nous allions réaliser pour le bien de l’humanité.

Le jour J

Le jour venu, c’est très simple, il suffit d’appliquer l’implacable plan préparé à l’avance.

Bien évidemment, rien ne se passe jamais comme prévu, il faut donc être capable, d’abord de savoir si c’est en train de merder et ensuite avoir les moyens de se démerder.

Est-ce qu’on peut improviser au dernier moment ?

Non. Quand vous venez chercher votre voiture chez le garagiste, il ne vous dis pas « ah attends, je vais mettre un dernier tour de clé par là j’ai une idée ».

Et si j’ai un problème inattendu ?

Alors on improvise. Oui, j’ai dit le contraire juste avant. Mais pas n’importe comment. Vous devez vous être préparés à savoir où chercher. Par exemple:

• Le blog ne répond plus (timeout)
  • Côté machine: vérifier si le nginx est up, vérifier les règles iptables, vérifier la configuration, tester un accès local
  • Côté AWS: vérifier les security group, les règles du load balancer, les NACL, les règles de routages, la passerelle Internet, les target group et leur statut.
• Le blog crée un boucle de redirection
  • Identifier les rebonds, faire l’inventaire des endroits où une redirection peut s’opérer, faire des coupe-circuits pour identifier le souci.
• Le contenu est incorrect
  • Valider la migration des articles, savoir remonter une sauvegarde si besoin, savoir s’il y a du cache et quels composants en sont responsables.

Cela demande une bonne connaissance du logiciel que vous avez migré (WordPress, en l’occurrence) , mais également de l’écosystème AWS. Et surtout dans ces cas là, il est toujours utile de ne pas prendre ces décisions seul. On peut se tromper sur les interprétations et faire « pire qu’avant » en voulant corriger.

Conclusion

Alors, spoiler alert: tout s’est bien déroulé. Je n’ai pas de problème intéressant à raconter car nous n’en avons pas eu. L’ordre a été donné d’enclencher les leviers et un quart de tour de clé plus tard, le domaine avait basculé.

A retenir, lors de votre prochaine migration, n’oubliez pas:

• Planifiez
• Préparez
• Répétez

Et faites appel à un consultant D2SI Devoteam Revolve si vous avez un doute 🙂