Omgevingen en goedgekeurde versies beheren

Deployments automatiseren op AWS

Dunieski Otano

Amazon Web Services Solutions Architect

Dezelfde code, drie omgevingen

• Promoot een Lambda-versie van staging naar prod
• Zelfde artefact, geen rebuild
• Eén API-call werkt het prod-alias bij; de code verandert nooit
• Dat is "build once, deploy many"

Goedgekeurde versies per service

• Lambda: aliassen wijzen naar functieversies
• ECR + ECS: imagetags + revisies van taakdefinities
• API Gateway: stages met deployments
• S3: objectversies in buckets met versiebeheer

Hoe Lambda-aliassen werken

• Een versie is een onveranderlijke snapshot van de functie
• Een alias is een benoemde verwijzing naar een versie
• Werk het alias bij om een versie te promoten
• Aliassen ondersteunen gewogen routing voor canary-releases

ECR-tags en ECS-taakdefinities

• ECR-images zijn onveranderlijk per digest
• Een tag is een verplaatsbaar label op een digest
• ECS-taakdefinities verwijzen naar een image:tag of @digest
• In productie: pin op digest om exact dezelfde bits te vergrendelen

API Gateway-stages in het kort

• Een stage is een deployment van de API
• Elke stage heeft een eigen URL en deploymentgeschiedenis
• Promoot door de API naar de volgende stage te deployen
• Stage-variabelen bevatten runtimewaarden per omgeving

Een versie promoten

• Bouw het artefact één keer
• Valideer in dev en daarna staging
• Werk het prod-alias of de tag bij, geen rebuild
• Hetzelfde artefact draait in elke omgeving

Configuratie gescheiden houden

• Code blijft hetzelfde tussen omgevingen
• Configuratie bevat de verschillen tussen dev en prod
• Stage-variabelen, omgevingsvariabelen, Parameter Store, Secrets Manager
• Hardcode nooit omgevingswaarden in het artefact

Laten we oefenen!

Deployments automatiseren op AWS