Dans le cadre de leur mission, deux consultants Cloud & DevOps chez Agyla.cloud, qui accompagnent notre client PMU, un des plus gros acteurs français de paris hippiques, dans leur projet de migration vers le Cloud AWS, des applications compte, des systèmes de logins clients ainsi que de l’application de prise de paris officielle PMU, nous racontent leur expérience.
Contexte & besoin :
Nous avons intégré ce projet de migration Cloud chez PMU en 2019 et ce projet s’étend sur 2 ans, soit jusqu’en 2021.
L’équipe est composée de 10 personnes, allant de profils développeurs back, DevOps, Product Owners, Scrum Master jusqu’aux Testeurs.
Les challenges et les enjeux de PMU
Nous avons intégré l’équipe en tant que consultants Cloud & DevOps. Nous accompagnons notre client dans sa migration vers le Cloud, à travers le changement de fournisseur d’infrastructure et l’hébergement de toute l’infrastructure sur le cloud d’AWS.
Nous avons donc apporté des modifications importantes afin d’obtenir des résultats notables, qui se résument en :
- Gains financiers à travers :
- Le coût d’infrastructure
- Les coûts d’infogérance : PMU est désormais autonome sur les différents environnements et la maintenance du patrimoine applicatif
- Gains organisationnels à travers :
- L’automatisation de la chaîne de déploiement (les livraisons étaient faites manuellement auparavant)
- L’amélioration du TTM en apportant de la valeur plus rapidement au client
- L’automatisation de l’infogérance
- Gains techniques à travers :
- Une infrastructure désormais dynamique et non plus statique
- L’utilisation de Cloudfront (précédemment c’était Varnish et BigIP)
- Le passage au Serverless (Lambda)
La problématique rencontrée chez PMU concerne la nécessité de fournir de la documentation et donner de la visibilité sur l’infrastructure existante ainsi que d’assurer une migration avec zero downtime (la migration comporte des risques à prendre en considération car cela peut engendrer un impact business critique).
Le projet s’identifie alors par une migration du site officiel de PMU et de toutes les couches services sur AWS.
Concernant la chaîne CI/CD et l’automatisation, la problématique du client portait sur le fait que la chaîne CI/CD dépendait du fournisseur. Il fallait donc repenser la migration avec une nouvelle chaîne CI/CD.
Enfin, il fallait restructurer les équipes car il n’y avait pas à proprement parler chez PMU d’équipe Cloud pour chaque domaine. Il y avait donc une nécessité de constituer une équipe Cloud & DevOps, par domaine.
Quelles actions mener pour résoudre ces problématiques ?
DevOps : Automatisation, migration & déploiement
Le besoin de notre client était d’accélérer les processus, de mettre à l’échelle les environnements et de créer des workflows d’intégration, de distribution et de déploiement continu (CI/CD). Afin de répondre à ce besoin, nous avons réalisé toute l’automatisation des pipelines CI/CD :
- La migration de Jenkins vers Gitlab CI
- La nouvelle gestion des branches gitlab CI
- L’automatisation des templates Gitlab CI pour avoir des pipelines multi-projets
- Faciliter la création et le déploiement des nouveaux environnements
- Automatiser le système d’installation et de déploiement des nouvelles releases applicatives sur tous les environnements (hors production et production)
Il fallait également préparer la stratégie de migration à travers des schémas d’architecture (voir bas de page), créer toute la documentation, faire des audits avec AWS pour le choix des services et faire une étude des impacts.
Nous avons donc débuté le projet via un audit avec une équipe de Professional Services AWS (programme MRP).
Toute la migration a ensuite été divisée par étapes (paris hippiques, paris sportifs… etc).
Il y a eu tout un travail sur la modernisation de quelques applications en utilisant des architectures Serverless.
Sur la partie build nous avons travaillé sur :
- L’automatisation du build d’infra avec Terraform (Infra As Code).
- La mise en oeuvre des mécanismes d’automatisation de déploiement et d’Infra-as-code grâce à nos compétences DevOps, ainsi que l’automatisation des déploiements applicatifs (pipeline Gitlab CI/CD)
- La mise en place de la stratégie de migration de chaque application pour assurer par exemple une migration progressives via des pondération DNS avec les services AWS Route53 et Cloudfront
- La mise en place de la sécurité des applications sur AWS en respectant les bests practices de sécurité et en répondant aux exigences de l’équipe sécurité du client
Sur la partie run, nous avons mis en place :
- Des fiches consignes et des guidelines à suivre pour permettre à l’équipe pilotage de bien escalader les incidents en production
- La configuration des logs : avant la mise en production d’une application migrée, il fallait préparer la gestion de ces logs avec la chaîne ELK existante
- Le run, les mises en prod, les nouvelles releases…
- L’amélioration continue de l’infrastructure migrée et activée sur AWS et des systèmes de CI/CD utilisés.
La sécurité AWS au coeur du projet
Les bonnes pratiques de la sécurité ont été respectées et implémentées au cours du projet de migration des applications sur AWS :
- Application du principe Least-Privileges.
- Sensibilisation des développeurs de l’importance de la sécurité sur le cloud.
- Chiffrement des composants d’infrastructure (EBS, EFS, RDS, Redis) via des clés KMS.
- Stockage des informations sensibles comme des tokens et des mots de passe dans Secrets Manager et Parameter store chiffrés par KMS surtout pour les Lambdas.
- Utilisation des headers de sécurité entre les Cloudfronts et les ALB publiques.
- Protection contre les attaques DDoS en implémentant AWS Shield Advanced.
- Utilisation du service WAF pour sécuriser les applications contre les attaques de type OWASP et limiter les accès aux environnements hors production à usage interne uniquement.
Si nous détaillons un peu plus ce projet par service, nous avons :
Sur la partie Front:
- S3 : stockages des contenus statiques des fronts, stockage des logs etc
- Cloudfront : infrastructures des applications fronts et flexibilité de gestion de caches
- WAF : Firewall afin de sécuriser l’accès sur les environnements hors production et sécurisation contre les vulnérabilités OWASP
- Shield Advanced : protection contre les attaques DDoS
- Lambda Edge : assurer les redirections sur les sites, le système de mise en maintenance, etc
- Route53 : gestions et hébergement des domaines DNS
- ACM : gestions des certificats SSL pour les Cloudfronts et les ALBs
- CloudWatch : monitoring, logs, events
Partie Back:
- Alb : load balancer devant les autoscaling groups pour les applications back (tomcat, java, etc)
- EC2 : instances hébergeant les applications
- ASG : scaling des applications back selon la policy basée sur la CPU des EC2
- EFS : file system partagé entre les applications back (EC2)
- RDS : Mysql bases de données
- Memcached : cache des applications back
- Redis : cache des sessions utilisateurs
- DynamoDB : stockage NoSQL pour les applications back
- Lambda : infra serverless selon le besoin (batch de nuit, processus de mise à jour des entrées des bases de données, etc)
- SSM parameter store: stockage des clés des applications
- KMS : chiffrement des EBS, EFS, Redis, RDS
- SQS : queue pour les process en mode buffering
Quels autres outils/services (hors AWS) ont été mis en place pour le projet ?
Une amélioration de référencement (SEO) à été apportée avec une architecture 100% serverless qui comprend plusieurs services AWS (Lambda, S3, SQS… etc).
Un challenge réussi !
Le projet a permis d’avoir le contrôle sur l’infrastructure en interne et d’améliorer les performances des applications.
De notre côté, le projet de migration PMU nous a permis de développer nos soft & hard skills. La collaboration avec d’autres métiers peut être compliquée dans certaines situations mais grâce à l’application de la méthodologie Scrum Agile, collaborer avec toutes les équipes techniques n’est plus un challenge, au contraire, l’ambiance et la bonne humeur est réellement présente au sein des équipes.
Sur le plan technique, étant donné que c’était notre premier projet de migration, nous avons pu mettre à profit nos expertises, monter en compétences sur l’utilisation d’AWS ainsi que sur l’automatisation et le build d’infrastructure avec les outils de l’IAC.
Le travail avec les développeurs, nous a bien appris à maîtriser les bonnes pratiques de versionning du code, le code review et les tests.
Dans un projet de migration, il est important également de savoir prioriser les tâches et respecter les deadlines pour mener à bien le projet !
Enfin, nous vous proposons une vue complète et détaillée de la résolution des problématiques et le déploiement des services AWS à travers, ci-dessous, deux exemples de diagrammes d’architecture :
Architecture 1:
Architecture 2: