Gérer les environnements et les versions approuvées

Automatiser les déploiements sur AWS

Dunieski Otano

Amazon Web Services Solutions Architect

Même code, trois environnements

• Promouvoir une version Lambda de staging vers prod
• Même artefact, pas de rebuild
• Un appel d'API met à jour l'alias prod ; le code ne change jamais
• C'est « build once, deploy many »

Versions approuvées, par service

• Lambda : les alias pointent vers des versions de fonction
• API Gateway : stages avec déploiements
• S3 : versions d'objet dans des buckets avec versioning activé

Fonctionnement des alias Lambda

• Une version est un instantané immuable de la fonction
• Un alias est un pointeur nommé vers une version
• Mettez à jour l'alias pour promouvoir une version
• Les alias prennent en charge le routage pondéré pour les déploiements canari

Tags ECR et définitions de tâche ECS

• Les images ECR sont immuables par digest
• Un tag est une étiquette mobile sur un digest
• Les définitions de tâche ECS référencent une image:tag ou @digest
• En production, pointez par digest pour figer les bits exacts

API Gateway : stages, en bref

• Un stage est un déploiement de l'API
• Chaque stage a son URL et un historique de déploiement
• Promouvoir en déployant l'API vers le stage suivant
• Les variables de stage contiennent des valeurs d'exécution par environnement

Promouvoir une version

• Construire l'artefact une seule fois
• Le valider en dev, puis staging
• Mettre à jour l'alias ou le tag prod, sans rebuild
• Le même artefact tourne dans chaque environnement

Séparer la configuration

• Le code reste identique selon l'environnement
• La configuration porte les différences dev vs prod
• Variables de stage, variables d'env., Parameter Store, Secrets Manager
• Ne jamais coder en dur des valeurs d'environnement dans l'artefact

Passons à la pratique !

Automatiser les déploiements sur AWS