Gestionarea mediilor și a versiunilor aprobate

Automatizarea implementărilor pe AWS

Dunieski Otano

Amazon Web Services Solutions Architect

Același cod, trei medii

• Promovezi o versiune Lambda din staging în prod
• Același artefact, fără rebuild
• Un singur API call actualizează alias-ul de prod; codul nu se schimbă
• Așa funcționează „build once, deploy many"

Versiuni aprobate, per serviciu

• Lambda: alias-urile indică versiuni ale funcției
• ECR + ECS: taguri de imagine + revizii de definiție de task
• API Gateway: stage-uri cu deployment-uri
• S3: versiuni de obiecte în bucket-uri cu versioning activat

Cum funcționează alias-urile Lambda

• O versiune este un instantaneu imutabil al funcției
• Un alias este un pointer numit către o versiune
• Actualizezi alias-ul pentru a promova o versiune
• Alias-urile suportă rutare ponderată pentru lansări canary

Taguri ECR și definiții de task ECS

• Imaginile ECR sunt imutabile per digest
• Un tag este o etichetă mobilă pe un digest
• Definițiile de task ECS fac referire la un image:tag sau @digest
• Pentru producție, fixează versiunea prin digest pentru a bloca exact bit-ii

Stage-urile API Gateway, pe scurt

• Un stage este un deployment al API-ului
• Fiecare stage are propriul URL și istoric de deployment
• Promovezi prin deployment-ul API-ului către următorul stage
• Variabilele de stage rețin valori de runtime specifice mediului

Promovarea unei versiuni

• Construiești artefactul o singură dată
• Îl validezi în dev, apoi în staging
• Actualizezi alias-ul sau tagul de prod, fără rebuild
• Același artefact rulează în fiecare mediu

Separarea configurației

• Codul rămâne același în toate mediile
• Configurația conține diferențele dintre dev și prod
• Variabile de stage, variabile de mediu, Parameter Store, Secrets Manager
• Nu introduce niciodată valori de mediu direct în artefact

Hai să exersăm!

Automatizarea implementărilor pe AWS