É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 checkout a besoin de dev, staging et prod
• Chaque environnement cible des ressources aval différentes
• Coder en dur impose une reconstruction par environnement
• Les variables d'étape règlent cela à l'exécution

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

• Une étape est un déploiement d'une API
• Chaque étape a sa propre 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 impacter prod
• Promouvoir la même API entre environnements
• Rétrograder une étape sans toucher aux autres
• Chaque étape conserve son historique de déploiement

Variables d'étape

• Paires clé-valeur propres à une étape
• Référence via ${stageVariables.varName}
• À utiliser pour la config par environnement
• Aucune modification de code si 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 laide : 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 des chemins aux étapes
  • api.example.com/v1 → étape prod

Comment tout s'articule

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

Passons à la pratique !

Automatiser les déploiements sur AWS