Meetup AFUP
Septembre 2017
Migration vers AWS
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
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
L’évolution de nos pipelines
❖ Avant :
~ 13 minutes
❖ Après :
< 8 minutes
É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
É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.
É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)
É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)
Et en vrai, ça donne quoi ?
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
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
Les hooks de CodeDeploy
❖ 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
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
Quelques outils supplémentaires
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
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.
Et c’est tout ?
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
En résumé...
Merci à tous !
Des questions ?

Meetup du 21 septembre 2017

  • 1.
  • 2.
    Contexte d’avant lamigration ❖ 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 lamigration ❖ 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 nospipelines ❖ 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èrementautomatisé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 deCodeDeploy
  • 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 denos 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.
  • 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 surveilleret 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.
  • 21.
    Déploiement blue/green Le principelors 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.
  • 24.
    Merci à tous! Des questions ?