Présentation de la migration d'un projet Magento historique depuis une infrastructure classique vers le cloud via AWS. Avec un processus de déploiement orchestré principalement autour de Jenkins et de CodeDeploy.

1. Meetup AFUP
Septembre 2017
Migration vers AWS

2. Contexte d’avant la migration
❖ Projet commencé en 2011 en PHP 5.3 sur Magento EE
❖ 1 plateforme globale avec 13 boutiques B2B:
➢ Chargements du catalogue (très) longs
➢ Problème de performances
➢ Saturation de la base de données (317K+ produits)
❖ Impossible d’upgrade PHP, Varnish, etc (OS obsolète)
❖ Déployer revient à prier pour que la blackbox fonctionne
❖ Le projet se déploie lui-même

3. Objectifs de la migration
❖ Améliorer les performances (navigation et processus d’import)
❖ Éclatement de la plateforme globale en 12 plateformes indépendantes
❖ Simplifier et réduire au maximum la durée des déploiements
❖ Se rapprocher géographiquement des clients (région AWS)
❖ Profiter des services d’Amazon
❖ Isoler la logique de déploiement de l’e-commerce

4. L’évolution de nos pipelines
❖ Avant :
~ 13 minutes
❖ Après :
< 8 minutes

5. Étape de construction
❖ Nettoyage du répertoire de travail
❖ Récupération des sources du projet avec Git
❖ Récupération des dépendances avec Composer
❖ Préparation des assets avec Grunt :
➢ compilation Less
➢ minification des fichiers JavaScript
➢ optimisation des images

6. Étape de déploiement
❖ Stockage de l’application sous forme d’archive dans un bucket S3
❖ Déploiement de l’archive sur les instances EC2 avec CodeDeploy
❖ Génération de la configuration directement sur les instances EC2
❖ Installation de la nouvelle crontab
❖ Redémarrage des services
Note : Toutes ces actions sont réalisés grâce à AWS CLI ou via CodeDeploy.

7. Étape de d'initialisation
❖ Vidage du cache applicatif depuis Jenkins grâce à l’API de l’application
❖ (Application du nouveau VCL aux différents Varnish)

8. Étape de reporting
❖ Alerte envoyée par e-mail avec la liste des nouveaux commits déployés
❖ (Connecteurs HipChat)
❖ (Tests automatisés avec Blackfire)

9. Et en vrai, ça donne quoi ?

11. CodeDeploy
❖ Déploiements entièrement automatisés
❖ Temps d’arrêt minimaux
❖ Roll-back et restauration possibles nativement
❖ Contrôle centralisé depuis la console AWS
❖ Très facile à adopter

12. Le fichier appspec.yml
❖ Fichier au format YAML
❖ Permet de définir très simplement :
➢ un mapping pour le déploiement
➢ le code à exécuter tout au long du déploiement
➢ les permissions à appliquer sur l’application

13. Les hooks de CodeDeploy

14. ❖ Stockage sécurisé des données de configuration :
➢ sous forme de texte brut
➢ sous forme d’objets chiffrés
❖ Récupérable en CLI très facilement
❖ Possibilité de créer une arborescence personnalisée
EC2 Systems Manager (SSM) - Parameter Store

15. La structure de nos paramètres
❖ Contient tous les paramètres nécessaires
au bon fonctionnement de l’application
❖ Gestion collaborative :
➢ hébergeur pour tous les
credentials des différents services
➢ développeurs pour tous les
paramètres applicatifs

16. Quelques outils supplémentaires

17. Simple Queue Service (SQS)
❖ Service de file d’attente de messagerie (RabbitMQ like)
❖ Utilisable en CLI ou avec le SDK officiel
❖ Interface très complète depuis la console AWS

18. CloudWatch
Permet de surveiller et de monitorer depuis un seul espace et en temps réel :
❖ les ressources utilisées par les applications sur AWS
❖ les logs générés par tous les services et les applications
Il est aussi possible de configurer des alarmes selon nos propres critères.

19. Et c’est tout ?

21. Déploiement blue/green
Le principe lors d’un déploiement :
❖ Provisionnement automatique de nouvelles instances EC2
❖ Déploiement du nouveau code sur ces instances
❖ Transfert du trafic des anciennes vers les nouvelles instances EC2
❖ Décommissionnement automatique des anciennes instances EC2

22. En résumé...

24. Merci à tous !
Des questions ?