Blue/Green con AWS Copilot e GitHub Actions

L’evoluzione delle metodologie di rilascio software nel contesto del cloud computing ha portato alla necessità di sistemi sempre più resilienti, capaci di garantire la continuità del servizio anche durante le fasi critiche di aggiornamento.

Il deployment Blue/Green si è consolidato come uno degli standard industriali più efficaci per raggiungere l’obiettivo del “zero-downtime”, permettendo ai team di ingegneria di testare nuove versioni in ambienti di produzione speculari prima di deviare il traffico degli utenti finali.

In questo scenario, AWS Copilot CLI emerge come uno strumento di astrazione di alto livello che semplifica radicalmente l’orchestrazione di container su Amazon Elastic Container Service (ECS) e AWS Fargate, automatizzando la creazione di infrastrutture complesse che altrimenti richiederebbero una gestione manuale estesa di template CloudFormation o codice Terraform.

Il Paradigma del Deployment Blue/Green nell’Ecosistema AWS

Il concetto di base del deployment Blue/Green prevede l’esistenza di due ambienti identici: l’ambiente “Blue”, che esegue la versione attualmente stabile dell’applicazione, e l’ambiente “Green”, dove viene distribuita la nuova versione.

Questo approccio non solo azzera i tempi di inattività, ma fornisce un meccanismo di rollback istantaneo: se la versione Green manifesta anomalie dopo lo switch del traffico, è sufficiente ripristinare il puntamento del load balancer verso l’ambiente Blue.

All’interno dell’ecosistema AWS, questa strategia viene implementata principalmente attraverso l’integrazione di Amazon ECS con AWS CodeDeploy, il quale gestisce il traffico tra i Target Groups dell’Application Load Balancer (ALB).

L’adozione di AWS Copilot trasforma questo processo in un’esperienza dichiarativa. Copilot non è solo una CLI, ma un orchestratore che interpreta i desiderata dello sviluppatore definiti in un manifesto YAML e genera le risorse AWS necessarie seguendo le “best practices” di architettura.

Quando si configura un servizio di tipo “Load Balanced Web Service”, Copilot predispone automaticamente un Application Load Balancer, un cluster ECS, le definizioni dei task su Fargate e i ruoli IAM necessari per la sicurezza e l’operatività.

Architettura e Meccanismi Interni di AWS Copilot

AWS Copilot opera attraverso una gerarchia di concetti: Applicazioni, Ambienti e Servizi. Un’applicazione è un raggruppamento logico di servizi e ambienti.

Un ambiente rappresenta un isolamento di rete (VPC, subnets) dove i servizi risiedono, tipicamente suddivisi in stadi come “test”, “staging” e “prod”. I servizi sono i componenti containerizzati veri e propri, definiti tramite il file manifest.yml.

Il manifesto è il cuore pulsante della configurazione. Esso permette di definire risorse computazionali (CPU, Memoria), scalabilità automatica e parametri di rete. Per quanto riguarda le strategie di rilascio, la sezione deployment del manifesto offre opzioni per controllare il comportamento durante l’aggiornamento dei task.

Sebbene il valore predefinito sia un rolling update, Copilot espone configurazioni per integrare allarmi CloudWatch che possono innescare rollback automatici se vengono rilevate regressioni nelle metriche di sistema o applicative.

Configurazione del Manifesto per l’Affidabilità

Per garantire che un deployment Blue/Green o un aggiornamento sicuro abbiano successo, è fondamentale configurare correttamente gli health check. Senza parametri accurati, il load balancer potrebbe inviare traffico a container che non hanno completato la fase di bootstrap, portando a errori 502 o 503 per l’utente finale.

# Estratto di un manifesto Copilot per un servizio web bilanciato
http:
  path: '/'
  healthcheck:
    path: '/health'
    port: 80
    success_codes: '200'
    healthy_threshold: 3
    unhealthy_threshold: 2
    interval: 15s
    timeout: 10s
    grace_period: 60s # Tempo concesso all'app per avviarsi prima del primo check.
  deregistration_delay: 30s # Tempo di draining delle connessioni.

In un’architettura Blue/Green gestita da CodeDeploy, questi parametri vengono utilizzati per determinare la salute della flotta “Green” prima di procedere con lo swap del listener. La latenza di disponibilità del servizio può essere modellata matematicamente per ottimizzare i costi rispetto alla velocità di rilascio.

Integrazione di GitHub Actions per l’Automazione CD

GitHub Actions rappresenta il motore di esecuzione ideale per automatizzare il ciclo di vita delle applicazioni Copilot. Grazie alla disponibilità di azioni specifiche come ksivamuthu/aws-copilot-github-action, è possibile integrare comandi Copilot direttamente nel flusso di lavoro Git. L’automazione non si limita al semplice deploy, ma può estendersi alla creazione dinamica di ambienti di anteprima (preview environments) basati su rami (branches) del repository, accelerando il processo di revisione del codice.

Sicurezza e Federazione delle Identità (OIDC)

Un aspetto critico dell’integrazione tra GitHub Actions e AWS è la gestione delle credenziali. L’approccio tradizionale basato su chiavi di accesso IAM statiche (Access Key ID e Secret Access Key) presenta vulnerabilità significative se tali segreti vengono compromessi. La raccomandazione attuale è l’uso di OpenID Connect (OIDC), che permette a GitHub di richiedere token di accesso temporanei a AWS senza l’uso di segreti a lungo termine.

Il meccanismo si basa su una relazione di fiducia (Trust Relationship) configurata in AWS tra un Identity Provider OIDC (puntamento a GitHub) e un ruolo IAM specifico.

Implementando OIDC, il workflow di GitHub può assumere dinamicamente i permessi necessari per eseguire copilot svc deploy, garantendo che solo il codice approvato e proveniente da sorgenti verificate possa alterare l’infrastruttura di produzione.

Guida Tecnica: Implementare Blue/Green con Copilot Action

Per realizzare un sistema Blue/Green completo, è necessario coordinare il manifesto di Copilot, la configurazione dell’ambiente e il workflow di GitHub Actions. Sebbene Copilot gestisca internamente molti aspetti del deployment rolling, l’implementazione di un Blue/Green “puro” con switch bilanciato richiede spesso l’uso di pipeline orchestrate o configurazioni avanzate che si appoggiano a AWS CodeDeploy.

Passo 1: Preparazione dell’Infrastruttura e del Manifesto

Il primo passo consiste nell’inizializzare l’applicazione e l’ambiente. Copilot creerà una VPC con sottoreti pubbliche e private. È buona norma distribuire i task nelle sottoreti private per una maggiore sicurezza, lasciando che l’ALB risieda nelle sottoreti pubbliche per ricevere il traffico internet.

Nel file manifest.yml, è possibile definire parametri che influenzano la strategia di aggiornamento. Ad esempio, l’uso di rollback_alarms permette a Copilot di monitorare lo stato del servizio durante il deploy e annullare l’operazione se le metriche degradano.

deployment:
  rolling: default
  rollback_alarms:
    - CPUUtilizationAlarm
    - Target5xxErrorAlarm

Passo 2: Configurazione del Workflow GitHub Actions

Il workflow deve essere strutturato per gestire l’autenticazione OIDC e invocare la CLI di Copilot. È essenziale impostare correttamente i permessi del GITHUB_TOKEN per consentire la lettura del contenuto e la scrittura dell’id-token.

name: Production Deployment
on:
  push:
    branches: [ main ]

permissions:
  id-token: write # Necessario per OIDC.
  contents: read

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout Repository
        uses: actions/checkout@v4.[31]

      - name: Authenticate with AWS via OIDC
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::ACCOUNT_ID:role/GitHubActionsRole
          aws-region: eu-west-1.[25, 26, 29]

      - name: Setup AWS Copilot
        uses: ksivamuthu/aws-copilot-github-action@v0.0.8
        with:
          command: install.[18, 25]

      - name: Build and Deploy to Production
        uses: ksivamuthu/aws-copilot-github-action@v0.0.8
        with:
          command: svc deploy
          app: 'my-app'
          env: 'prod'
          name: 'web-service'.[17, 23, 25]

In questo flusso, l’azione svc deploy si occupa di costruire l’immagine Docker, caricarla su ECR e aggiornare lo stack CloudFormation del servizio. Sebbene Copilot di default esegua un aggiornamento rolling, la stabilità è garantita dal fatto che i nuovi task vengono portati in stato di salute (healthy) prima che i vecchi vengano drenati.

Strategie Avanzate: Canary e Linear Deployments

Per le applicazioni mission-critical, un semplice switch Blue/Green potrebbe non essere sufficiente. Le strategie Canary permettono di introdurre la nuova versione solo a una piccola frazione di utenti (es. il 10%) per monitorare il comportamento nel mondo reale con un raggio d’azione limitato. Se i segnali telemetrici sono positivi, la percentuale viene incrementata gradualmente.

AWS CodeDeploy, che può essere configurato come backend per i deployment di ECS tramite Copilot, supporta diverse configurazioni di shifting del traffico :

• Linear10PercentEvery1Minute: Il traffico aumenta del 10% ogni minuto fino al 100%.
• Canary10Percent5Minutes: Il 10% del traffico viene spostato immediatamente, seguito dal restante 90% dopo 5 minuti di osservazione.
• AllAtOnce: Lo switch Blue/Green classico, dove tutto il traffico passa istantaneamente alla nuova versione dopo i test iniziali.

L’uso di queste strategie richiede una gestione oculata della persistenza dei dati. Le sessioni utente, ad esempio, devono essere gestite tramite “sticky sessions” sul bilanciatore o, preferibilmente, tramite un archivio di sessioni esterno come Redis per evitare che gli utenti vengano disconnessi durante la migrazione tra Blue e Green.

Gestione dei Dati e Migrazioni di Database in Ambienti Blue/Green

Il deployment di applicazioni containerizzate è spesso la parte più semplice del processo; la vera sfida risiede nella gestione del database. Poiché un deployment Blue/Green comporta la coesistenza di due versioni dell’applicazione, il database deve essere in grado di servire entrambe simultaneamente.

Il Pattern Expand-and-Contract

Per gestire modifiche allo schema del database, i team DevOps utilizzano spesso il pattern “Expand-and-Contract” (espansione e contrazione). Questo processo evita downtime causati da incompatibilità tra il codice e lo schema.

1. Fase di Espansione: Si applica una migrazione al database che aggiunge nuove colonne o tabelle senza rimuovere o modificare quelle esistenti. La versione “Blue” continua a ignorare le nuove aggiunte, mentre la versione “Green” è pronta a usarle.
2. Deployment: Si esegue il deployment della versione Green (Blue/Green switch). Entrambe le versioni operano sul database. In questa fase, il codice deve essere scritto in modo da gestire l’assenza di dati nei nuovi campi per le transazioni avviate dalla versione Blue.
3. Fase di Contrazione: Una volta che la versione Green è stabile e tutto il traffico è stato migrato, si applica una seconda migrazione per rimuovere i vecchi campi non più necessari, ripulendo lo schema.

RDS Blue/Green Deployments

AWS ha introdotto una funzionalità specifica per Amazon RDS che replica l’intero ambiente database per facilitare gli aggiornamenti del motore o modifiche di schema pesanti. RDS crea un ambiente di staging (Green) sincronizzato tramite replica logica con l’ambiente di produzione (Blue). Una volta completati i test sul database Green, è possibile eseguire uno switchover che inverte i ruoli degli endpoint, solitamente con un’interruzione del servizio inferiore al minuto. Questa tecnica è complementare al deployment dei servizi su ECS e dovrebbe essere coordinata all’interno della pipeline di rilascio.

Monitoraggio, Osservabilità e Circuit Breaking

Un deployment automatizzato senza un monitoraggio robusto è intrinsecamente rischioso. AWS Copilot facilita l’osservabilità integrando nativamente CloudWatch Logs e metriche di salute del servizio. Un concetto fondamentale introdotto da ECS e supportato da Copilot è il “Deployment Circuit Breaker”.

Il Circuit Breaker monitora lo stato dei task durante il deployment. Se i task continuano a fallire il lancio o gli health check superando una certa soglia, ECS interrompe automaticamente il deployment e avvia il rollback alla versione precedentemente funzionante. Questo impedisce a un deployment difettoso di consumare risorse inutilmente o di lasciare il servizio in uno stato instabile.

Metriche Chiave per il Successo del Deployment

L’analisi delle prestazioni post-deploy dovrebbe basarsi su metriche oggettive per confermare che la versione Green sia effettivamente superiore o pari alla Blue.

L’integrazione di queste metriche in allarmi CloudWatch collegati al manifesto Copilot (rollback_alarms) permette di chiudere il cerchio dell’automazione, trasformando la pipeline in un sistema auto-correggente.

Verso la Fine del Supporto: Il Futuro di AWS Copilot

È imperativo che le organizzazioni che adottano AWS Copilot oggi siano consapevoli del ciclo di vita del prodotto. AWS ha annunciato che la CLI di Copilot raggiungerà la fine del supporto ufficiale il 12 giugno 2026. Sebbene lo strumento continuerà a funzionare e rimarrà open-source, non riceverà nuovi aggiornamenti di sicurezza o funzionalità direttamente da AWS.

Strategie di Migrazione e Continuità

Per garantire la longevità delle proprie pipeline Blue/Green, i team hanno diverse opzioni di evoluzione.

• Adozione di CloudFormation Generato: Copilot trasforma i manifesti in stack CloudFormation standard. I team possono “estrarre” questi template e gestirli direttamente o tramite strumenti IaC più complessi.
• Migrazione a AWS CDK: Per i team che necessitano di maggiore controllo e programmabilità, l’AWS Cloud Development Kit (CDK) offre astrazioni simili a Copilot ma con la potenza di linguaggi come TypeScript o Python, integrandosi perfettamente con le strategie Blue/Green di CodeDeploy.
• ECS Express Mode: AWS sta promuovendo “Express Mode” come il percorso più rapido per portare i container in produzione, offrendo un approccio semplificato e “opinionated” simile a quello di Copilot, ma gestito direttamente tramite la console e le API ufficiali di ECS.

Sintesi e Raccomandazioni Operative

La creazione di un sistema di deployment Blue/Green con AWS Copilot e GitHub Actions rappresenta l’apice della maturità DevOps per molte startup e aziende di medie dimensioni. L’equilibrio tra la facilità d’uso della CLI e la flessibilità dell’automazione CI/CD permette di ridurre drasticamente il “time-to-market” garantendo al contempo un’affidabilità di grado enterprise.

Per i professionisti che implementano questa soluzione, si consigliano i seguenti pilastri operativi:

1. Immutabilità: Trattare ogni rilascio come un nuovo set di infrastrutture. Non modificare mai i task esistenti; lasciate che Copilot e ECS gestiscano la sostituzione degli ambienti.
2. Test a Sinistra (Shift-Left): Integrare test unitari e di integrazione pesanti nel workflow di GitHub Actions prima che il comando copilot svc deploy venga eseguito.
3. Monitoraggio Proattivo: Non limitarsi agli health check di base. Utilizzare CloudWatch Container Insights per avere una visibilità granulare sulle performance dei singoli task durante la transizione Blue/Green.
4. Sicurezza Federata: Abbandonare immediatamente l’uso di chiavi IAM statiche a favore di OIDC per tutte le interazioni tra GitHub e AWS.

In conclusione, sebbene la tecnologia sottostante evolva e i nomi degli strumenti possano cambiare, i principi del rilascio software sicuro e automatizzato rimangono costanti. L’investimento nella comprensione delle dinamiche di shifting del traffico, gestione dello stato e osservabilità ripagherà l’organizzazione in termini di stabilità e fiducia degli utenti finali, indipendentemente dallo strumento di orchestrazione scelto.