Étapes API Gateway et configuration à l'exécution

Automatiser les déploiements sur AWS

Dunieski Otano

Amazon Web Services Solutions Architect

Trois URL, une API

• La même API de paiement nécessite dev, staging et prod
• Chaque environnement utilise des ressources en aval différentes
• Coder en dur oblige à reconstruire par environnement
• Les variables d'étape règlent ça à l'exécution

Qu'est-ce qu'une étape API Gateway

• Une étape est un déploiement d'une API
• Chaque étape a son URL
• Étapes courantes : dev, staging, prod
• Une définition d'API, plusieurs étapes

Pourquoi les étapes comptent pour les déploiements

• Tester en dev sans toucher à prod
• Promouvoir la même API d'un environnement à l'autre
• Rétrograder une étape sans affecter les autres
• Chaque étape garde son historique de déploiement

Variables d'étape

• Paires clé-valeur propres à une étape
• Référencer avec ${stageVariables.varName}
• À utiliser pour la config par environnement
• Aucune modification du code quand les valeurs diffèrent

Variables d'étape en action

• checkout-api -> étape dev : lambdaAlias = dev
• checkout-api -> étape prod : lambdaAlias = prod
• L'intégration appelle payments:${stageVariables.lambdaAlias}
• Une API cible deux alias Lambda différents

Noms de domaine personnalisés

• L'URL par défaut est peu conviviale : abc123.execute-api.us-east-1.amazonaws.com/dev
• Domaine personnalisé : api.example.com
  • Nécessite un certificat ACM pour TLS
• Le mappage de chemin de base relie les chemins aux étapes
  • api.example.com/v1 → étape prod

Comment tout s'imbrique

• Variables d'étape <-> alias Lambda de la vidéo 2.3
• Même idée pour les versions de définitions de tâches ECS et les noms de tables DynamoDB
• Versions approuvées par environnement, aucun changement de code
• Le chapitre 3 étend cela entre services

Passons à la pratique !

Automatiser les déploiements sur AWS