Il y a quelques mois, nous avons intégralement refait le site web d’Oxalide. Bien que le design de celui-ci soit très moderne, nous avons souhaité conserver le même socle applicatif qu’auparavant : Wordpress. De cette façon, nous avons pû réutiliser certains développements, et nous n’avons pas eu besoin de former nos équipes à de nouveaux outils. Cependant, il n’était pas question d’installer Wordpress dans un vhost d’une machine mutualisée. Nous avons donc mis en place une architecture AWS multi-AZ autoscalée ! Nous en avons aussi profité pour créer une machine de pré-production, et mettre en place de la CI ! Les modifications sont dorénavant effectuées en pré-production, et un simple clic dans une interface web permet de lancer un job Jenkins+GitLabCI qui va générer un conteneur Docker et de le pousser en production.

Voici le schéma de cette nouvelle infra :

Schéma

Cette infrastructure est composée des éléments suivants :

  • Une pré-production EC2
  • Deux instances EC2 “ECS Optimized” dans un autoscaling-group multi-AZ
  • Un ELB derrière CloudFront
  • Deux containers Docker portant le site de production
  • Un ECR pour stocker les images Docker
  • Un EFS contenant les medias
  • Une instance RDS Master/Slave

La mise en production s’effectue directement par l’équipe marketing en suivant le pipeline suivant :

Pipeline

Cette nouvelle infrastructure a apporté à notre site les avantages suivants :

  • Une grande résilence
    • Les conteneurs sont déployés dans deux “zones de disponibilités” (AZ).
  • Une capacité à tenir la charge
    • L’autoscaling se charge de déployer de nouveaux conteneurs en cas de fort trafic.
  • Pas de limitations d’usage
    • L’infrastructure n’impose aucun compromis dans l’utilisation de Wordpress.
  • La possibilité d’effectuer un rollback
    • En cas de besoin, le retour à une précédente version est possible en quelques clics.
  • L’autonomie de l’équipe marketing
    • L’interface web de Jenkins rend simples et traçables les mises en production.
  • Une production strictement identique
    • Les images de production sont générées à partir de la machine de pré-production.

Avec cette architecture, nous souhaitions nous prouver que malgré les limitations induites par Wordpress, il est tout à fait possible de l’intégrer d’une manière élégante et qui satisfasse toutes les parties. En effet, Wordpress étant un ensemble très monolithique, nous avons dû mettre en place plusieurs solutions de contournement afin d’intégrer l’outil de la façon qui nous semblait optimale par rapport à nos besoins. Le principal challenge était de pouvoir avoir une pré-production et une production identiques, tout en gérant les mises à jour du core et des différents plugins. Nous sommes parvenus à obtenir cela en plaçant les médias sur un stockage partagé EFS, dans deux répertoires distincts pour la production et la pré-production, et en envoyant le reste des fichiers de la pré-production dans un dépôt GIT. Ensuite, notre processus de déploiement lancé par Jenkins se charge de créer les instances Docker, de synchroniser les médias, de réimporter la base de données, et de déployer la dernière version du site à partir de GIT, contenant les articles et les plugins à jour. Cette approche est pérenne car nous avons effectué le moins de modifications possible dans le code de Wordpress, préférant mettre en place autour de celui-ci des solutions de contournement au niveau du système.