API Gateway-stages en runtimeconfiguratie

Deployments automatiseren op AWS

Dunieski Otano

Amazon Web Services Solutions Architect

Drie URL's, één API

• Dezelfde checkout-API heeft dev, staging en prod nodig
• Elke omgeving raakt andere downstream-resources
• Waarden hardcoden dwingt een rebuild per omgeving af
• Stagevariabelen lossen dit op tijdens runtime

Wat is een API Gateway-stage

• Een stage is een deployment van een API
• Elke stage heeft een eigen URL
• Veelvoorkomende stages: dev, staging, prod
• Eén API-definitie, veel stages

Waarom stages belangrijk zijn voor deployments

• Testen in dev zonder prod te raken
• Dezelfde API door omgevingen heen promoten
• Een stage terugdraaien zonder anderen te raken
• Elke stage houdt zijn eigen deploy-geschiedenis bij

Stagevariabelen

• Sleutel–waardeparen per stage afgebakend
• Verwijs met ${stageVariables.varName}
• Gebruik ze voor config per omgeving
• Geen codewijziging nodig als waarden verschillen

Stagevariabelen in de praktijk

• checkout-api -> dev-stage: lambdaAlias = dev
• checkout-api -> prod-stage: lambdaAlias = prod
• Integratie roept payments:${stageVariables.lambdaAlias} aan
• Eén API raakt twee verschillende Lambda-aliases

Aangepaste domeinnamen

• Standaard-URL is lelijk: abc123.execute-api.us-east-1.amazonaws.com/dev
• Aangepaste domein: api.example.com
  • Vereist een ACM-certificaat voor TLS
• Basispadkoppeling verbindt paden aan stages
  • api.example.com/v1 → prod-stage

Hoe dit samenhangt

• Stagevariabelen <-> Lambda-aliases uit video 2.3
• Zelfde idee voor ECS-taakdefinitieversies en DynamoDB-tabelnamen
• Goedgekeurde versies per omgeving, geen codewijzigingen
• Hoofdstuk 3 breidt dit uit over services heen

Laten we oefenen!

Deployments automatiseren op AWS