Gestione degli ambienti e delle versioni approvate

Automatizzare i deployment su AWS

Dunieski Otano

Amazon Web Services Solutions Architect

Stesso codice, tre ambienti

• Promuovi una versione Lambda da staging a prod
• Stesso artifact, nessuna ricompilazione
• Una chiamata API aggiorna l'alias prod; il codice non cambia
• È il «build once, deploy many»

Versioni approvate, per servizio

• Lambda: gli alias puntano a versioni della funzione
• ECR + ECS: tag delle immagini + revisioni delle task definition
• API Gateway: stage con deployment
• S3: versioni degli oggetti in bucket con versioning attivo

Come funzionano gli alias Lambda

• Una versione è uno snapshot immutabile della funzione
• Un alias è un puntatore nominato a una versione
• Aggiorna l'alias per promuovere una versione
• Gli alias supportano instradamento ponderato per canary release

Tag ECR e task definition ECS

• Le immagini ECR sono immutabili per digest
• Un tag è un etichetta mobile su un digest
• Le task definition ECS referenziano image:tag o @digest
• In produzione, blocca per digest per fissare i bit esatti

API Gateway: stage in breve

• Uno stage è un deployment dell'API
• Ogni stage ha il proprio URL e una storia dei deployment
• Promuovi deployando l'API allo stage successivo
• Le variabili di stage contengono valori runtime per ambiente

Promuovere una versione

• Crea l'artifact una sola volta
• Valídalo in dev, poi in staging
• Aggiorna l'alias o il tag di prod, niente rebuild
• Lo stesso artifact gira in ogni ambiente

Tenere separata la configurazione

• Il codice resta uguale tra gli ambienti
• La configurazione gestisce le differenze dev vs prod
• Variabili di stage, variabili d'ambiente, Parameter Store, Secrets Manager
• Non hardcodare mai valori di ambiente nell'artifact

Esercitiamoci!

Automatizzare i deployment su AWS