Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà. # Risorse necessarie per le implementazioni di Amazon ECS blue/green Per utilizzare una blue/green distribuzione con trasferimento del traffico gestito, il servizio deve utilizzare una delle seguenti funzionalità: + Elastic Load Balancing + Service Connect Anche i servizi che non utilizzano Service Discovery, Service Connect, VPC Lattice o Elastic Load Balancing possono blue/green utilizzare le implementazioni, ma non ottengono nessuno dei vantaggi dello spostamento del traffico gestito. L'elenco seguente fornisce una panoramica di alto livello di ciò che è necessario configurare per le distribuzioni di Amazon ECS: blue/green + Il servizio utilizza Application Load Balancer, Network Load Balancer o Service Connect. Configurare le risorse appropriate. + Application Load Balancer: per ulteriori informazioni, consultare [Risorse Application Load Balancer per implementazioni blu/green, lineari e canary](alb-resources-for-blue-green.md). + Network Load Balancer: per ulteriori informazioni, consultare [Risorse Network Load Balancer per distribuzioni di Amazon ECS blu/verde, lineare e canary](nlb-resources-for-blue-green.md). + Service Connect: per ulteriori informazioni, consultare [Risorse Service Connect per distribuzioni Amazon ECS blu/green, lineari e canary](service-connect-blue-green.md). + Impostare il controller di implementazione del servizio su `ECS`. + Configurare la strategia di implementazione come `blue/green` nella definizione del servizio. + Facoltativamente, configurare parametri aggiuntivi come: + Tempo di incorporamento per la nuova implementazione + CloudWatch allarmi per il rollback automatico + Hook del ciclo di vita dell'implementazione per il test (si tratta di funzioni Lambda che vengono eseguite in fasi di implementazione specifiche) ## Best practice Segui queste best practice per blue/green implementazioni Amazon ECS di successo: + Configurare controlli dell'integrità appropriati che riflettano accuratamente l'integrità dell'applicazione. + Impostare un tempo di incorporamento che consenta di testare in modo sufficiente l'implementazione verde. + Implementa CloudWatch allarmi per rilevare automaticamente i problemi e attivare i rollback. + Utilizzare gli hook del ciclo di vita per eseguire test automatici in ogni fase di implementazione. + Assicurati che la tua applicazione sia in grado di gestire le revisioni blu e verdi dei servizi in esecuzione simultanea. + Pianifica una capacità del cluster sufficiente per gestire entrambe le revisioni dei servizi durante la distribuzione. + Verificare le procedure di rollback prima di implementarle in produzione. # Risorse Application Load Balancer per implementazioni blu/green, lineari e canary Per utilizzare Application Load Balancers con le blue/green distribuzioni di Amazon ECS, devi configurare risorse specifiche che consentano l'instradamento del traffico tra le revisioni del servizio blu e verde. ## Gruppi di destinazione Per le blue/green implementazioni con Elastic Load Balancing, è necessario creare due gruppi target: + Un gruppo di destinazione primario per la revisione del servizio blu (traffico di produzione attuale) + Un gruppo di destinazione alternativo per la revisione del servizio verde (nuova versione) Entrambi i gruppi di destinazione devono essere configurati con le seguenti impostazioni: + Tipo di destinazione: `IP` (per Fargate o EC2 con modalità di rete `awsvpc`) + Protocollo: `HTTP` (o il protocollo utilizzato dall'applicazione) + Porta: la porta su cui l'applicazione è in ascolto (in genere `80` per HTTP) + VPC: lo stesso VPC delle attività di Amazon ECS + Impostazioni di controllo dell'integrità: configurate per controllare correttamente l'integrità dell'applicazione Durante una blue/green distribuzione, Amazon ECS registra automaticamente le attività con il gruppo target appropriato in base alla fase di distribuzione. **Example Creazione di gruppi di destinazione per gli Application Load Balancer** I seguenti comandi CLI creano due gruppi target da utilizzare con un Application Load Balancer in una distribuzione: blue/green ``` aws elbv2 create-target-group \ --name blue-target-group \ --protocol HTTP \ --port 80 \ --vpc-id vpc-abcd1234 \ --target-type ip \ --health-check-path / \ --health-check-protocol HTTP \ --health-check-interval-seconds 30 \ --health-check-timeout-seconds 5 \ --healthy-threshold-count 2 \ --unhealthy-threshold-count 2 aws elbv2 create-target-group \ --name green-target-group \ --protocol HTTP \ --port 80 \ --vpc-id vpc-abcd1234 \ --target-type ip \ --health-check-path / \ --health-check-protocol HTTP \ --health-check-interval-seconds 30 \ --health-check-timeout-seconds 5 \ --healthy-threshold-count 2 \ --unhealthy-threshold-count 2 ``` ## Application Load Balancer È necessario creare un Application Load Balancer con la seguente configurazione: + Schema: connesso a Internet o interno, a seconda delle esigenze + Tipo di indirizzo IP: IPv4 + VPC: lo stesso VPC delle attività di Amazon ECS + Sottoreti: almeno due sottoreti devono trovarsi in diverse zone di disponibilità + Gruppi di sicurezza: un gruppo di sicurezza che consente il traffico sulle porte del listener Il gruppo di sicurezza collegato all'Application Load Balancer deve avere una regola in uscita che consenta il traffico verso il gruppo di sicurezza collegato alle attività di Amazon ECS. **Example Creazione di un Application Load Balancer** Il seguente comando CLI crea un Application Load Balancer da usare in un'implementazione blu/verde: ``` aws elbv2 create-load-balancer \ --name my-application-load-balancer \ --type application \ --security-groups sg-abcd1234 \ --subnets subnet-12345678 subnet-87654321 ``` ## Listener e regole Per le blue/green distribuzioni, è necessario configurare i listener sull'Application Load Balancer: + Listener di produzione: gestisce il traffico di produzione (in genere sulla porta 80 o 443) + Inizialmente inoltra il traffico al gruppo di destinazione primario (revisione blu del servizio) + Dopo l'implementazione, inoltra il traffico al gruppo di destinazione alternativo (revisione del servizio verde) + Listener di test (facoltativo): gestisce il traffico di test per convalidare la revisione del servizio verde prima di spostare il traffico di produzione + Può essere configurato su una porta diversa (ad esempio, 8080 o 8443) + Inoltra il traffico al gruppo di destinazione alternativo (revisione del servizio verde) durante il test Durante una blue/green distribuzione, Amazon ECS aggiorna automaticamente le regole del listener per indirizzare il traffico verso il gruppo target appropriato in base alla fase di distribuzione. **Example Creazione di un listener di produzione** Il seguente comando CLI crea un listener di produzione sulla porta 80 che inoltra il traffico al gruppo di destinazione primario (blu): ``` aws elbv2 create-listener \ --load-balancer-arn arn:aws:elasticloadbalancing:region:123456789012:loadbalancer/app/my-application-load-balancer/abcdef123456 \ --protocol HTTP \ --port 80 \ --default-actions Type=forward,TargetGroupArn=arn:aws:elasticloadbalancing:region:123456789012:targetgroup/blue-target-group/abcdef123456 ``` **Example Creazione di un listener di test** Il seguente comando CLI crea un listener di test sulla porta 8080 che inoltra il traffico al gruppo di destinazione alternativo (verde): ``` aws elbv2 create-listener \ --load-balancer-arn arn:aws:elasticloadbalancing:region:123456789012:loadbalancer/app/my-application-load-balancer/abcdef123456 \ --protocol HTTP \ --port 8080 \ --default-actions Type=forward,TargetGroupArn=arn:aws:elasticloadbalancing:region:123456789012:targetgroup/green-target-group/ghijkl789012 ``` **Example Creazione di una regola del listener per l'instradamento basato sul percorso** Il seguente comando CLI crea una regola che inoltra il traffico per un percorso specifico al gruppo di destinazione verde per il test: ``` aws elbv2 create-rule \ --listener-arn arn:aws:elasticloadbalancing:region:123456789012:listener/app/my-application-load-balancer/abcdef123456/ghijkl789012 \ --priority 10 \ --conditions Field=path-pattern,Values='/test/*' \ --actions Type=forward,TargetGroupArn=arn:aws:elasticloadbalancing:region:123456789012:targetgroup/green-target-group/ghijkl789012 ``` **Example Creazione di una regola del listener per l'instradamento basato sull'intestazione** Il seguente comando CLI crea una regola che inoltra il traffico con un'intestazione specifica al gruppo di destinazione verde per il test: ``` aws elbv2 create-rule \ --listener-arn arn:aws:elasticloadbalancing:region:123456789012:listener/app/my-application-load-balancer/abcdef123456/ghijkl789012 \ --priority 20 \ --conditions Field=http-header,HttpHeaderConfig='{Name=X-Environment,Values=[test]}' \ --actions Type=forward,TargetGroupArn=arn:aws:elasticloadbalancing:region:123456789012:targetgroup/green-target-group/ghijkl789012 ``` ## Configurazione del servizio È necessario disporre delle autorizzazioni per consentire ad Amazon ECS di gestire le risorse del bilanciatore del carico nei cluster. Per ulteriori informazioni, consulta [Ruolo IAM dell'infrastruttura Amazon ECS per i bilanciatori del carico](AmazonECSInfrastructureRolePolicyForLoadBalancers.md). Quando crei o aggiorni un servizio Amazon ECS per blue/green distribuzioni con Elastic Load Balancing, devi specificare la seguente configurazione. Sostituiscili con i tuoi valori. *user-input* I componenti chiave di questa configurazione sono: + `targetGroupArn`: l'ARN del gruppo di destinazione principale (revisione del servizio blu). + `alternateTargetGroupArn`: l'ARN del gruppo di destinazione alternativo (revisione del servizio verde). + `productionListenerRule`: l'ARN della regola del listener per il traffico di produzione. + `roleArn`: l'ARN del ruolo che consente ad Amazon ECS di gestire le risorse del bilanciamento del carico elastico. + `strategy`: impostato su `BLUE_GREEN` per abilitare implementazioni blu/verdi. + `bakeTimeInMinutes`: la durata in cui le revisioni del servizio blu e verde vengono eseguite contemporaneamente dopo lo spostamento del traffico di produzione. + `TestListenerRule`: l'ARN della regola del listener per il traffico di test. Si tratta di un parametro facoltativo. ``` { "loadBalancers": [ { "targetGroupArn": "arn:aws:elasticloadbalancing:region:123456789012:targetgroup/primary-target-group/abcdef123456", "containerName": "container-name", "containerPort": 80, "advancedConfiguration": { "alternateTargetGroupArn": "arn:aws:elasticloadbalancing:region:account-id:targetgroup/alternate-target-group/ghijkl789012", "productionListenerRule": "arn:aws:elasticloadbalancing:region:account-id:listener-rule/app/load-balancer-name/abcdef123456/listener/ghijkl789012/rule/mnopqr345678", "roleArn": "arn:aws:iam::123456789012:role/ecs-elb-role" } } ], "deploymentConfiguration": { "strategy": "BLUE_GREEN", "maximumPercent": 200, "minimumHealthyPercent": 100, "bakeTimeInMinutes": 5 } } ``` ## Flusso di traffico durante l'implementazione Durante una blue/green distribuzione con Elastic Load Balancing, il traffico attraversa il sistema nel modo seguente: 1. *Stato iniziale*: tutto il traffico di produzione viene instradato al gruppo di destinazione principale (revisione blu del servizio). 1. *Implementazione della revisione del servizio verde*: Amazon ECS implementa le nuove attività e le registra con il gruppo di destinazione alternativo. 1. *Traffico di test*: se è configurato un listener di test, il traffico di test viene instradato al gruppo di destinazione alternativo per convalidare la revisione del servizio verde. 1. *Spostamento del traffico di produzione*: Amazon ECS aggiorna la regola del listener di produzione per instradare il traffico verso il gruppo di destinazione alternativo (revisione del servizio verde). 1. *Tempo di incorporamento*: la durata in cui le revisioni del servizio blu e verde vengono eseguite contemporaneamente dopo lo spostamento del traffico di produzione. 1. *Completamento*: dopo una corretta implementazione, la revisione del servizio blu viene interrotta. Se vengono rilevati problemi durante l'implementazione, Amazon ECS può eseguire automaticamente il rollback instradando il traffico verso il gruppo di destinazione principale (revisione blu del servizio). # Risorse Network Load Balancer per distribuzioni di Amazon ECS blu/verde, lineare e canary Per utilizzare un Network Load Balancer con blue/green distribuzioni Amazon ECS, devi configurare risorse specifiche che consentano il routing del traffico tra le revisioni del servizio blu e verde. Questa sezione spiega i componenti richiesti e la loro configurazione. Quando la configurazione include un Network Load Balancer, Amazon ECS aggiunge un ritardo di 10 minuti alle seguenti fasi del ciclo di vita: + TEST\$1TRAFFIC\$1SHIFT + PRODUCTION\$1TRAFFIC\$1SHIFT Questo ritardo è dovuto a problemi di temporizzazione del Network Load Balancer che possono causare una mancata corrispondenza tra i pesi del traffico configurati e l'effettivo instradamento del traffico nel piano dati. ## Gruppi di destinazione Per le blue/green implementazioni con un Network Load Balancer, è necessario creare due gruppi target: + Un gruppo di destinazione primario per la revisione del servizio blu (traffico di produzione attuale) + Un gruppo di destinazione alternativo per la revisione del servizio verde (nuova revisione del servizio) Entrambi i gruppi di destinazione devono essere configurati con le seguenti impostazioni: + Tipo di destinazione: `ip` (per Fargate o EC2 con modalità di rete `awsvpc`) + Protocollo: `TCP` (o il protocollo utilizzato dall'applicazione) + Porta: la porta su cui l'applicazione è in ascolto (in genere `80` per HTTP) + VPC: lo stesso VPC delle attività di Amazon ECS + Impostazioni di controllo dell'integrità: configurate per controllare correttamente l'integrità dell'applicazione Per i controlli dell'integrità del protocollo TCP, il Network Load Balancer stabilisce una connessione TCP con la destinazione. Se la connessione ha esito positivo, la destinazione viene considerata integra. Per i controlli di HTTP/HTTPS integrità, il Network Load Balancer invia una HTTP/HTTPS richiesta al bersaglio e verifica la risposta. Durante una blue/green distribuzione, Amazon ECS registra automaticamente le attività con il gruppo target appropriato in base alla fase di distribuzione. **Example Creazione di gruppi di destinazione per un Network Load Balancer** I seguenti comandi AWS CLI creano due gruppi target da utilizzare con un Network Load Balancer in una distribuzione: blue/green ``` aws elbv2 create-target-group \ --name blue-target-group \ --protocol TCP \ --port 80 \ --vpc-id vpc-abcd1234 \ --target-type ip \ --health-check-protocol TCP aws elbv2 create-target-group \ --name green-target-group \ --protocol TCP \ --port 80 \ --vpc-id vpc-abcd1234 \ --target-type ip \ --health-check-protocol TCP ``` ## Network Load Balancer È necessario creare un Network Load Balancer con la seguente configurazione: + Schema: connesso a Internet o interno, a seconda delle esigenze + Tipo di indirizzo IP: IPv4 + VPC: lo stesso VPC delle attività di Amazon ECS + Sottoreti: almeno due sottoreti devono trovarsi in diverse zone di disponibilità A differenza degli Application Load Balancer, i Network Load Balancer operano a livello di trasporto (Livello 4) e non utilizzano gruppi di sicurezza. Invece, è necessario assicurarsi che i gruppi di sicurezza associati alle attività di Amazon ECS consentano il traffico dal Network Load Balancer sulle porte del listener. **Example Creazione di un Network Load Balancer** Il seguente comando AWS CLI crea un Network Load Balancer da utilizzare in una distribuzione: blue/green ``` aws elbv2 create-load-balancer \ --name my-network-load-balancer \ --type network \ --subnets subnet-12345678 subnet-87654321 ``` ## Considerazioni sull'utilizzo di NLB con le distribuzioni blue/green Quando utilizzi un Network Load Balancer per le blue/green distribuzioni, considera quanto segue: + **Funzionamento di livello 4**: i Network Load Balancer operano a livello di trasporto (livello 4) e non ispezionano il contenuto a livello di applicazione (livello 7). Ciò significa che non è possibile utilizzare intestazioni o percorsi HTTP per le decisioni di instradamento. + **Controlli dell'integrità**: i controlli dell'integrità di Network Load Balancer sono limitati ai protocolli TCP, HTTP o HTTPS. Per i controlli dell'integrità di TCP, il Network Load Balancer verifica solo che la connessione possa essere stabilita. + **Conservazione della connessione**: i Network Load Balancer conservano l'indirizzo IP di origine del client, che può essere utile per scopi di sicurezza e registrazione. + **Indirizzi IP statici**: i Network Load Balancer forniscono indirizzi IP statici per ogni sottorete, che possono essere utili per la creazione di whitelist o quando i client devono connettersi a un indirizzo IP fisso. + **Traffico di test**: poiché i Network Load Balancer non supportano l'instradamento basato sul contenuto, il traffico di test deve essere inviato a una porta diversa rispetto al traffico di produzione. ## Listener e regole Per le blue/green implementazioni con un Network Load Balancer, è necessario configurare i listener: + Listener di produzione: gestisce il traffico di produzione (in genere sulla porta 80 o 443) + Inizialmente inoltra il traffico al gruppo di destinazione primario (revisione blu del servizio) + Dopo l'implementazione, inoltra il traffico al gruppo di destinazione alternativo (revisione del servizio verde) + Listener di test (facoltativo): gestisce il traffico di test per convalidare la revisione del servizio verde prima di spostare il traffico di produzione + Può essere configurato su una porta diversa (ad es., 8080 o 8443) + Inoltra il traffico al gruppo di destinazione alternativo (revisione del servizio verde) durante il test A differenza degli Application Load Balancer, i Network Load Balancer non supportano regole di instradamento basate sul contenuto. Il traffico viene invece instradato in base alla porta e al protocollo del listener. I seguenti comandi AWS CLI creano listener di produzione e test per un Network Load Balancer: Sostituiscili *user-input* con i tuoi valori. ``` aws elbv2 create-listener \ --load-balancer-arn arn:aws:elasticloadbalancing:region:123456789012:loadbalancer/net/my-network-lb/1234567890123456 \ --protocol TCP \ --port 80 \ --default-actions Type=forward, TargetGroupArn=arn:aws:elasticloadbalancing:region:123456789012:targetgroup/blue-target-group/1234567890123456 aws elbv2 create-listener \ --load-balancer-arn arn:aws:elasticloadbalancing:region:123456789012:loadbalancer/net/my-network-lb/1234567890123456 \ --protocol TCP \ --port 8080 \ --default-actions Type=forward, TargetGroupArn=arn:aws:elasticloadbalancing:region:123456789012:targetgroup/green-target-group/1234567890123456 ``` ## Configurazione del servizio È necessario disporre delle autorizzazioni per consentire ad Amazon ECS di gestire le risorse del bilanciatore del carico nei cluster. Per ulteriori informazioni, consulta [Ruolo IAM dell'infrastruttura Amazon ECS per i bilanciatori del carico](AmazonECSInfrastructureRolePolicyForLoadBalancers.md). Quando crei o aggiorni un servizio Amazon ECS per blue/green distribuzioni con un Network Load Balancer, devi specificare la seguente configurazione: Sostituiscili con i tuoi valori. *user-input* I componenti chiave di questa configurazione sono: + `targetGroupArn`: l'ARN del gruppo di destinazione principale (revisione del servizio blu) + `alternateTargetGroupArn`: l'ARN del gruppo di destinazione alternativo (revisione del servizio verde) + `productionListenerRule`: l'ARN del listener per il traffico di produzione. + `testListenerRule`: (facoltativo) l'ARN del listener per il traffico di test + `roleArn`: l'ARN del ruolo che consente ad Amazon ECS di gestire le risorse di Network Load Balancer. + `strategy`: impostato per `BLUE_GREEN` abilitare le blue/green distribuzioni + `bakeTimeInMinutes`: La durata in cui le revisioni del servizio blu e verde vengono eseguite contemporaneamente dopo lo spostamento del traffico di produzione ``` { "loadBalancers": [ { "targetGroupArn": "arn:aws:elasticloadbalancing:region:123456789012:targetgroup/blue-target-group/1234567890123456", "containerName": "container-name", "containerPort": 80, "advancedConfiguration": { "alternateTargetGroupArn": "arn:aws:elasticloadbalancing:region:123456789012:targetgroup/green-target-group/1234567890123456", "productionListenerRule": "arn:aws:elasticloadbalancing:region:123456789012:listener/net/my-network-lb/1234567890123456/1234567890123456", "testListenerRule": "arn:aws:elasticloadbalancing:region:123456789012:listener/net/my-network-lb/1234567890123456/2345678901234567", "roleArn": "arn:aws:iam::123456789012:role/ecs-nlb-role" } } ], "deploymentConfiguration": { "strategy": "BLUE_GREEN", "maximumPercent": 200, "minimumHealthyPercent": 100, "bakeTimeInMinutes": 5 } } ``` ## Flusso di traffico durante l'implementazione Durante un' blue/green implementazione con un Network Load Balancer, il traffico attraversa il sistema nel modo seguente: 1. *Stato iniziale*: tutto il traffico di produzione viene instradato al gruppo di destinazione principale (revisione blu del servizio). 1. *Implementazione della revisione del servizio verde*: Amazon ECS implementa le nuove attività e le registra con il gruppo di destinazione alternativo. 1. *Traffico di test*: se è configurato un listener di test, il traffico di test viene instradato al gruppo di destinazione alternativo per convalidare la revisione del servizio verde. 1. *Spostamento del traffico di produzione*: Amazon ECS aggiorna il listener di produzione per instradare il traffico verso il gruppo di destinazione alternativo (revisione del servizio verde). 1. *Tempo di incorporamento*: la durata in cui le revisioni del servizio blu e verde vengono eseguite contemporaneamente dopo lo spostamento del traffico di produzione. 1. *Completamento*: dopo una corretta implementazione, la revisione del servizio blu viene interrotta. Se vengono rilevati problemi durante l'implementazione, Amazon ECS può eseguire automaticamente il rollback instradando il traffico verso il gruppo di destinazione principale (revisione blu del servizio). # Risorse Service Connect per distribuzioni Amazon ECS blu/green, lineari e canary Quando si utilizza Service Connect con blue/green le distribuzioni, è necessario configurare componenti specifici per consentire il corretto instradamento del traffico tra le revisioni blu e verde del servizio. Questa sezione spiega i componenti richiesti e la loro configurazione. ## Panoramica dell’architettura Service Connect sviluppa funzionalità di rilevamento servizi e mesh di servizi tramite un proxy sidecar gestito che viene inserito automaticamente nelle attività di Amazon ECS. Questi proxy gestiscono le decisioni di routing, i nuovi tentativi e la raccolta delle metriche, fornendo al contempo il backend del registro dei servizi. AWS Cloud Map Quando si distribuisce un servizio con Service Connect abilitato, il servizio si registra e i servizi client lo scoprono tramite il namespace. AWS Cloud Map In un'implementazione standard di Service Connect, i servizi client si connettono ai nomi di servizio logici e il proxy sidecar gestisce l'instradamento verso le effettive istanze di servizio. Con le blue/green implementazioni, questo modello viene esteso per includere il routing del traffico di test attraverso la configurazione. `testTrafficRules` Durante una blue/green distribuzione, i seguenti componenti chiave interagiscono tra loro: + **Proxy di Service Connect**: tutto il traffico tra i servizi passa attraverso il proxy di Service Connect, che prende decisioni di instradamento in base alla configurazione. + **AWS Cloud Map Registrazione**: sia la distribuzione blu che quella verde si registrano con AWS Cloud Map, ma la distribuzione verde viene inizialmente registrata come endpoint «di test». + **Test dell'instradamento del traffico**: la `testTrafficRules` nella configurazione di Service Connect determina come identificare e instradare il traffico di test verso l'implementazione verde. Ciò viene ottenuto tramite l'**instradamento basato sulle intestazioni**, in cui intestazioni HTTP specifiche nelle richieste indirizzano il traffico verso la revisione di test. Per impostazione predefinita, Service Connect riconosce l'intestazione `x-amzn-ecs-blue-green-test` per i protocolli basati su HTTP quando non vengono specificate regole personalizzate. + **Configurazione del client**: tutti i client nel namespace ricevono automaticamente sia i percorsi di produzione che quelli di test, ma solo le richieste che soddisfano le regole di test andranno all'implementazione verde. Ciò che rende questo approccio efficace è la capacità di gestire la complessità del rilevamento servizi durante le transizioni. Man mano che il traffico si sposta dall'implementazione blu a quella verde, tutti i meccanismi di connettività e rilevamento si aggiornano automaticamente. Non è necessario aggiornare i record DNS, riconfigurare i bilanciatori del carico o implementare le modifiche al rilevamento servizi in modo separato, poiché la mesh di servizi gestisce tutto. ## Instradamento e test del traffico Service Connect offre funzionalità avanzate di routing del traffico per le blue/green implementazioni, tra cui il routing basato su header e la configurazione degli alias client per scenari di test. ### Regole di intestazione del traffico di test Durante le blue/green distribuzioni, è possibile configurare le regole dell'intestazione del traffico di test per indirizzare richieste specifiche alla (nuova) revisione verde del servizio a scopo di test. Ciò consente di convalidare la nuova versione con traffico controllato prima di completare l'implementazione. Service Connect utilizza l'**instradamento basato sulle intestazioni** per identificare il traffico di test. Per impostazione predefinita, Service Connect riconosce l'intestazione `x-amzn-ecs-blue-green-test` per i protocolli basati su HTTP quando non vengono specificate regole personalizzate. Quando questa intestazione è presente in una richiesta, il proxy di Service Connect instraderà automaticamente la richiesta nell'implementazione verde per il test. Le regole di intestazione del traffico di test ti consentono di: + Indirizzare le richieste con intestazioni specifiche alla revisione del servizio verde + Testare nuove funzionalità con un sottoinsieme di traffico + Convalidare il comportamento del servizio prima della conversione completa del traffico + Implementare strategie di test canary + Eseguire test di integrazione in un ambiente simile a quello di produzione Il meccanismo di instradamento basato sulle intestazioni si integra perfettamente con l'architettura applicativa esistente. I servizi client non devono necessariamente essere consapevoli del processo di blue/green distribuzione: includono semplicemente le intestazioni appropriate quando inviano le richieste di test e il proxy Service Connect gestisce automaticamente la logica di routing. Per ulteriori informazioni sulla configurazione delle regole dell'intestazione del traffico di test, consulta [ServiceConnectTestTrafficHeaderRules](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ServiceConnectTestTrafficHeaderRules.html)la pagina *Amazon Elastic Container Service API* Reference. ### Regole di corrispondenza delle intestazioni Le regole di header matching definiscono i criteri per il routing del traffico di test durante le distribuzioni. blue/green È possibile configurare più condizioni di corrispondenza per controllare con precisione quali richieste vengono indirizzate alla revisione del servizio verde. La corrispondenza delle intestazioni supporta: + Corrispondenza esatta del valore dell’intestazione + Verifica della presenza dell’intestazione + Corrispondenza basata su modelli + Combinazioni multiple di intestazioni I casi d’uso di esempio includono il routing delle richieste con stringhe di utenti agenti specifiche, versioni API o flag di funzionalità al servizio verde per i test. Per ulteriori informazioni sulla configurazione dell'header matching, consulta [ServiceConnectTestTrafficHeaderMatchRules](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ServiceConnectTestTrafficHeaderMatchRules.html)*Amazon Elastic Container Service API Reference*. ### Alias client per le distribuzioni blue/green Gli alias client forniscono endpoint DNS stabili per i servizi durante le distribuzioni. blue/green Consentono un instradamento fluido del traffico tra le revisioni dei servizi blu e verdi senza richiedere alle applicazioni client di modificare gli endpoint di connessione. Durante una blue/green distribuzione, gli alias client: + Mantengono coerenti i nomi DNS per le connessioni client + Abilitano lo spostamento automatico del traffico tra le revisioni del servizio + Supportano strategie di migrazione graduale del traffico + Forniscono funzionalità di rollback reindirizzando il traffico alla revisione blu È possibile configurare più alias client per porte o protocolli diversi, consentendo ad architetture di servizio complesse di mantenere la connettività durante le implementazioni. Per ulteriori informazioni sulla configurazione degli alias del client, consulta il *riferimento [ServiceConnectClientAlias](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ServiceConnectClientAlias.html)all'API di Amazon Elastic Container Service*. ### Best practice per l'instradamento del traffico Quando si implementa il routing del traffico per le blue/green distribuzioni con Service Connect, è necessario prendere in considerazione le seguenti best practice: + **Inizia con i test basati sulle intestazioni**: utilizza le regole di intestazione del traffico di test per convalidare il servizio verde con traffico controllato prima di cambiare tutto il traffico. + **Configurare i controlli dell'integrità**: assicurarsi che sia i servizi blu che quelli verdi abbiano la configurazione dei controlli di integrità appropriati per evitare di instradare il traffico verso istanze non integre. + **Monitora le metriche del servizio**: tieni traccia degli indicatori chiave di prestazione per entrambe le revisioni del servizio durante l’implementazione per identificare tempestivamente i problemi. + **Pianificare la strategia di rollback**: configurare gli alias dei client e le regole di instradamento per consentire il ripristino rapido del servizio in caso di problemi. + **Verifica la logica di corrispondenza delle intestazioni**: convalida le regole di corrispondenza delle intestazioni in un ambiente non di produzione prima di applicarle alle implementazioni di produzione. ## Flusso di lavoro di blue/green implementazione di Service Connect Comprendere come Service Connect gestisce il processo blue/green di distribuzione aiuta a implementare e risolvere i problemi delle distribuzioni in modo efficace. Il seguente flusso di lavoro mostra come interagiscono i diversi componenti durante ogni fase dell'implementazione. ### Fasi di implementazione L' blue/green implementazione di Service Connect procede attraverso diverse fasi distinte: 1. **Stato iniziale**: il servizio blu gestisce il 100% del traffico di produzione. Tutti i servizi client nel namespace si connettono al servizio blu tramite il nome del servizio logico configurato in Service Connect. 1. **Registrazione Green Service**: quando la distribuzione verde viene avviata, viene registrata AWS Cloud Map come endpoint di «test». Il proxy di Service Connect nei servizi client riceve automaticamente le configurazioni di instradamento di produzione e test. 1. **Test di instradamento del traffico**: le richieste contenenti le intestazioni del traffico di test (come `x-amzn-ecs-blue-green-test`) vengono instradate automaticamente al servizio verde dal proxy di Service Connect. Il traffico di produzione continua a fluire verso il servizio blu. 1. **Preparazione dello spostamento del traffico**: dopo l'esito positivo dei test, il processo di implementazione prepara lo spostamento del traffico di produzione. Sia i servizi blu che quelli verdi rimangono registrati e integri. 1. **Spostamento del traffico di produzione**: la configurazione di Service Connect si aggiorna per instradare il traffico di produzione verso il servizio verde. Ciò avviene automaticamente senza richiedere aggiornamenti del servizio client o modifiche al DNS. 1. **Periodo di tempo di incorporamento**: la durata in cui le revisioni del servizio blu e verde vengono eseguite contemporaneamente dopo lo spostamento del traffico di produzione. 1. **Annullamento della registrazione al servizio blu**: dopo aver completato con successo lo spostamento e la convalida del traffico, il servizio blu viene annullato e terminato, completando l'implementazione. AWS Cloud Map ### Comportamento del proxy di Service Connect Il proxy Service Connect svolge un ruolo cruciale nella gestione del traffico durante le blue/green implementazioni. La comprensione del suo comportamento aiuta a progettare strategie di test e implementazione efficaci. Comportamenti chiave del proxy durante le implementazioni: blue/green + **Rilevamento automatico del percorso**: il proxy rileva automaticamente sia i percorsi di produzione che quelli di test AWS Cloud Map senza richiedere riavvii delle applicazioni o modifiche alla configurazione. + **Instradamento basato sulle intestazioni**: il proxy esamina le intestazioni di richiesta in entrata e instrada il traffico alla revisione del servizio appropriata in base alle regole del traffico di test configurate. + **Integrazione del controllo dell'integrità**: il proxy instrada il traffico solo verso istanze di servizio integre, escludendo automaticamente le attività non integre dal pool di instradamento. + **Nuovo tentativo e utilizzo di interruttori**: il proxy offre funzionalità integrate di logica di tentativi e interruzione, migliorando la resilienza durante le implementazioni. + **Raccolta di metriche**: il proxy raccoglie metriche dettagliate per i servizi blu e verdi, consentendo un monitoraggio completo durante le implementazioni. ### Aggiornamenti del rilevamento servizi Uno dei principali vantaggi dell'utilizzo di Service Connect per le blue/green implementazioni è la gestione automatica degli aggiornamenti di rilevamento dei servizi. blue/green Le implementazioni tradizionali richiedono spesso aggiornamenti DNS complessi o la riconfigurazione del load balancer, ma Service Connect gestisce queste modifiche in modo trasparente. Durante un'implementazione, Service Connect gestisce: + **Aggiornamenti del namespace**: il namespace di Service Connect include automaticamente gli endpoint di servizio blu e verdi, con regole di instradamento appropriate. + **Configurazione del client**: tutti i servizi client nel namespace ricevono automaticamente informazioni di instradamento aggiornate senza richiedere riavvii o nuove implementazioni. + **Transizione graduale**: gli aggiornamenti di rilevamento servizi avvengono in modo graduale e sicuro, garantendo l'assenza di interruzioni delle richieste in corso. + **Supporto per il rollback**: se è necessario un rollback, Service Connect può ripristinare rapidamente le configurazioni di rilevamento servizi per instradare nuovamente il traffico verso il servizio blu.