Hantera miljöer och godkända versioner

Automatisera driftsättningar på AWS

Dunieski Otano

Amazon Web Services Solutions Architect

Samma kod, tre miljöer

• Befordra en Lambda-version från staging till produktion
• Samma artefakt, ingen ombyggnad
• Ett API-anrop uppdaterar produktionsaliaset; koden ändras aldrig
• Det är "bygg en gång, driftsätt många gånger"

Godkända versioner, per tjänst

• Lambda: alias pekar på funktionsversioner
• ECR + ECS: image-taggar + revisioner av task-definitioner
• API Gateway: stages med deployments
• S3: objektversioner i buckets med versionshantering aktiverad

Så fungerar Lambda-alias

• En version är en oföränderlig ögonblicksbild av funktionen
• Ett alias är en namngiven pekare till en version
• Uppdatera aliaset för att befordra en version
• Alias stöder viktad routing för canary-utgåvor

ECR-taggar och ECS task-definitioner

• ECR-images är oföränderliga per digest
• En tagg är en flyttbar etikett på en digest
• ECS task-definitioner refererar till en image:tag eller @digest
• För produktion, lås till digest för att fästa exakt version

API Gateway-stages, kort förklarat

• En stage är en driftsättning av API:et
• Varje stage har sin egen URL och driftsättningshistorik
• Befordra genom att driftsätta API:et till nästa stage
• Stage-variabler innehåller miljöspecifika körvärden

Befordra en version

• Bygg artefakten en gång
• Validera den i dev, sedan staging
• Uppdatera produktionsaliaset eller taggen, ingen ombyggnad
• Samma artefakt körs i alla miljöer

Håll konfigurationen separat

• Koden förblir densamma i alla miljöer
• Konfigurationen innehåller skillnaderna mellan dev och produktion
• Stage-variabler, miljövariabler, Parameter Store, Secrets Manager
• Hårdkoda aldrig miljövärden i artefakten

Nu kör vi en övning!

Automatisera driftsättningar på AWS