REX : pipeline de livraison continue Docker sur AWS

REX : pipeline de livraison continue Docker sur AWS

Auteur : Sofiane Malti - Date de publication : juin 25, 2018

De nombreux tutoriaux existent sur la création d’un pipeline de livraison continue « Docker » sur AWS, comme ici par exemple. Souvent, le contexte client n’est pas pris en compte et l’adaptation demande un temps non négligeable. Cet article est le retour d’expérience de la mise en place d’un pipeline d’une livraison continue sur un client grand compte Astrakhan. Il présentera le pipeline mis en place, les difficultés et les avantages de ce modèle. La solution AWS est tellement riche que chaque entreprise peut avoir un modèle de gestion différent. Ainsi, même si ce pipeline n’est pas adapté aux exigences de votre entreprise, il peut vous donner des idées afin d’enrichir votre chaine CI/CD.

Cet article s’adresse à des sachants AWS, les concepts des services utilisés ne sont pas détaillés, et les choix d’architecture client ne sont pas expliqués.

Exigences Client :

• Chaque application possède trois ou quatre comptes AWS. Prod, STG, Int, Dev
• Les services managés AWS sont à favoriser sur les applications du marché
• Le serverless est à favoriser
• Le développement des applications est fait par des intégrateurs externes et des experts DevOps/AWS internes suivent le projet dans les étapes d’architecture, build, déploiement et run
• L’intégrateur peut garder la main sur l’intégration continue.

Dans ce contexte les services codePipeline, cloudFormation ECS /Fargate(container Docker), CloudWatch, Lambda, RDS sont utilisés pour un déploiement d’une application 100% Serverless.

La chaine CD mise en place pour le besoin client.

  • ArticleLivraisonContinue-623x1024
  • 1.0 & 1.1 : Livraison des images Docker sur ECR et des CloudFormation dans un zip (ECS Service & Task Definition).

L’équipe CCoE (Cloud Center of excellence) est en charge de la mise en place de l’infrastructure (VPC, ALB, règle de sécurité, RDS etc).

2 : Le pipeline est automatiquement lancé au dépôt du zip sur le bucket s3.

3 : Le Change set cloudformation est envoyé avec :

  • • Version application déployée
  • • Message de l’intégrateur sur les modifications réalisées
  • • Ressources AWS qui sont modifiées si validation du déploiement

4 : Envoi du mail à l’intégrateur afin de valider le déploiement sur l’environnement d’intégration.

5 : Mise à jour de l’environnement.

Une Lambda lance un cloudformation contenant le task definition et Service ECS.

La lambda utilisée est celle-ci. Cette fonction a été optimisée afin d’envoyer la version(tag) du container à déployer.

6 : Des tests de non-régression peuvent être réalisés. Exemple : Possibilité de se connecter avec un login et mot de passe à l’application. Nom/Prénom présent sur la seconde page.

7 : Un mail est envoyé à l’intégrateur. Si les tests de non-regression et ses tests sont exécutés et validés, il autorise le déploiement sur les environnements de staging et production.

8 : L’ensemble des images docker de l’application est envoyé sur le compte de Production.

9 : Le zip avec la version validée est déployé sur l’environnement de staging.

Note : L’image est envoyée en production pour une gestion plus stricte des droits d’accès à l’image.

Environnement STG, PROD :

Les mêmes étapes sont réalisées en STG et PROD à la différence près que l’équipe projet du client valide l’étape de déploiement sur les environnements.

Conclusion :

Ce pipeline est propre à un contexte client en particulier et un type d’application simple (container web, worker, BDD RDS) avec une équipe d’intégrateur externe. Si l’équipe est interne à l’entreprise, des services comme CodeCommit (gestionnaire de version) et CodeBuild (Build applications) peuvent être suffisants. Si ces outils ne le sont pas, en termes de fonctionnalité de nombreux outils comme Gitlab CI, GitHub sont compatibles avec AWS.

CodePipeline est une solution assez séduisante car complétement intégrée aux outils AWS tels que Cloudformation, CodeBuild, codeCommit et Lambda. Lambda avec sa bibliothéque Python Boto3, dont les inconvénients majeurs sont le vendeur lock-in avec des compétences spécifiques AWS et la maintenance du code lambda, permet tout de même de trouver des solutions aux nombreuses problématiques d’une livraison continue.

Si vous avez besoin d’un REX plus détaillé, n’hésitez pas à nous contacter.