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à.

# Pianificare i container su Amazon ECS
<a name="scheduling_tasks"></a>

Amazon Elastic Container Service (Amazon ECS) è un sistema di simultaneità ottimistica di stato condiviso che fornisce funzionalità di pianificazione flessibili per carichi di lavoro containerizzati. I pianificatori di Amazon ECS utilizzano le stesse informazioni sullo stato del cluster fornite dall'API Amazon ECS per poter prendere decisioni di posizionamento adeguate.

Amazon ECS fornisce un pianificatore di servizi per processi e applicazioni di lunga durata. Consente inoltre di eseguire le attività indipendenti o pianificate per processi batch o attività a esecuzione singola. Puoi specificare le strategie di posizionamento dei processi e i vincoli per l'esecuzione dei processi più adatte alle tue esigenze. Ad esempio, puoi specificare se i processi vengono eseguiti in più zone di disponibilità o all'interno di una singola zona di disponibilità. Puoi inoltre integrare i processi con pianificatori di terze parti o personalizzati.


| Opzione | Quando utilizzare | Ulteriori informazioni | 
| --- | --- | --- | 
| Servizio | Il pianificatore di servizi è ideale per le applicazioni e i servizi stateless di lunga durata. Il pianificatore di servizi, facoltativamente, assicura anche che le attività siano registrate nel bilanciatore del carico di bilanciamento del carico elastico. Puoi aggiornare i servizi gestiti dal pianificatore di servizi. Ciò potrebbe includere l'implementazione di una nuova definizione di attività o la modifica del numero di processi desiderati in esecuzione. Di default, il pianificatore di servizi distribuisce i processi su più zone di disponibilità. Puoi utilizzare vincoli e strategie di posizionamento dei processi per personalizzare le decisioni riguardo al posizionamento dei processi.  | [Servizi Amazon ECS](ecs_services.md) | 
| Processo autonomo | Un'attività autonoma è adatta a processi come i processi batch che eseguono un lavoro e quindi si arrestano. Ad esempio, puoi avere una chiamata di processo RunTask quando il lavoro è in una coda. L'attività recupera il lavoro dalla coda, esegue il lavoro e quindi si chiude. Grazie a RunTask, puoi consentire alla strategia di posizionamento dei processi di default di distribuire i processi in modo casuale in tutto il cluster. In questo modo si riduce al minimo la possibilità che una singola istanza ottenga un numero sproporzionato di processi. | [Attività autonome di Amazon ECS](standalone-tasks.md) | 
| Processi pianificati | Un'attività pianificata è adatta quando si hanno attività da eseguire a intervalli prestabiliti nel cluster, è possibile utilizzare EventBridge Scheduler per creare una pianificazione. Puoi eseguire processi per un'operazione di backup o una scansione del log. La EventBridge pianificazione dello Scheduler che crei può eseguire una o più attività nel cluster in orari specifici. L'evento programmato può essere impostato su un intervallo specifico (eseguito ogni N minuto, ora o giorno). In caso contrario, per una pianificazione più complessa, puoi utilizzare un'espressione cron. | [Utilizzo di Amazon EventBridge Scheduler per pianificare le attività di Amazon ECS](tasks-scheduled-eventbridge-scheduler.md) | 

## Opzioni di calcolo
<a name="compute-option"></a>

Con Amazon ECS, è possibile specificare l'infrastruttura su cui vengono eseguite le attività o i servizi. È possibile usare una strategia per il provider di capacità o un tipo di avvio.

Per Fargate, i provider di capacità sono Fargate e Fargate Spot. Per EC2, il provider di capacità è il gruppo Auto Scaling con le istanze di container registrate.

La strategia per i provider di capacità distribuisce le attività tra i provider di capacità associati al cluster.

In una strategia di provider di capacità possono essere utilizzati solo i provider di capacità che sono già associati a un cluster e hanno uno stato `ACTIVE` o `UPDATING`. Puoi associare un provider di capacità a un cluster durante la creazione di un cluster. 

In una strategia del provider di capacità, il valore di *base* opzionale indica il numero minimo di attività da eseguire su un provider di capacità specificato. Solo un provider di capacità in una strategia di provider di capacità può avere una base definita.

Il valore del *peso* indica la percentuale relativa del numero totale di attività avviate che utilizzano il provider di capacità specificato. Analizza l’esempio seguente. Ad esempio, supponiamo di avere una strategia che contiene due provider di capacità, ognuno con un peso pari a `1`. Una volta raggiunta la percentuale di base, le attività si dividono equamente tra i due provider di capacità. Usando la stessa logica, assumiamo di specificare un peso pari a `1` per *capacityProviderA* e un peso pari a `4` per *capacityProviderB*. Quindi, per ogni attività che viene eseguita utilizzando *capacityProviderA*, quattro attività utilizzano *capacityProviderB*.

L'opzione di calcolo avvia le attività direttamente su Fargate o sulle istanze Amazon EC2 registrate manualmente nei cluster.

# Ciclo di vita dei processi di Amazon ECS
<a name="task-lifecycle-explanation"></a>

Quando viene avviata un'attività, manualmente o come parte di un servizio, questa può attraversare diversi stati prima che termini da sola o venga interrotta manualmente. Alcune attività devono essere eseguite come processi in batch che passano in modo naturale da `PENDING` a `RUNNING` a `STOPPED`. Altre attività, che possono fare parte di un servizio, devono rimanere in esecuzione a tempo indeterminato o a essere ridimensionate in base alle esigenze.

Quando vengono richieste modifiche allo stato delle attività, ad esempio l'interruzione di un'attività o l'aggiornamento del conteggio desiderato di un servizio per aumentarne o ridurne le dimensioni, l'agente del container Amazon ECS traccia tali modifiche come ultimo stato noto dell'attività (`lastStatus`) e stato desiderato dell'attività (`desiredStatus`). È possibile scoprire sia l'ultimo stato noto che lo stato desiderato di un'attività nella console o descrivendo l'attività con l'API o l' AWS CLI.

Il diagramma di seguito mostra il flusso del ciclo di vita dell'attività.

![\[Diagramma degli stati del ciclo di vita dell'attività. Gli stati sono PROVISIONING (In fase di provisioning), PENDING (In attesa), ACTIVATING (In fase di attivazione), RUNNING (In esecuzione), DEACTIVATING (In fase di disattivazione), STOPPING (In fase di arresto).\]](http://docs.aws.amazon.com/it_it/AmazonECS/latest/developerguide/images/task-lifecycle.png)


## Stati del ciclo di vita
<a name="lifecycle-states"></a>

Di seguito è descritto ciascuno stato del ciclo di vita dell'attività.

PROVISIONING  
Amazon ECS deve eseguire operazioni aggiuntive prima che il processo venga avviato. Ad esempio, per le attività che utilizzano la modalità di rete `awsvpc`, deve essere predisposta l'interfaccia di rete elastica.

IN ATTESA  
Si tratta di uno stato di transizione in cui Amazon ECS è in attesa che l'agente del container effettui ulteriori operazioni. Un'attività rimane nello stato in sospeso fino a quando non sono disponibili risorse per l'attività.

ACTIVATING  
Si tratta di uno stato di transizione in cui Amazon ECS deve eseguire operazioni aggiuntive dopo l'avvio dell'attività, ma prima che questa possa passare allo stato `RUNNING`. Questo è lo stato in cui Amazon ECS recupera le immagini dei container, crea i container, configura il networking delle attività, registra i gruppi di destinazione dei bilanciatori del carico e configura il rilevamento servizi.

RUNNING (ESECUZIONE IN CORSO)  
L'attività è in esecuzione.

DEACTIVATING  
Si tratta di uno stato di transizione in cui Amazon ECS deve eseguire operazioni aggiuntive prima che l'attività venga interrotta. Ad esempio, per processi che fanno parte di un servizio che è configurato per l'utilizzo di gruppi di destinazione di Elastic Load Balancing, l'annullamento della registrazione del gruppo di destinazione si verifica durante questo stato.

STOPPING  
Si tratta di uno stato di transizione in cui Amazon ECS è in attesa che l'agente del container effettui ulteriori operazioni.  
Per i contenitori Linux, l'agente del contenitore invierà il segnale di arresto definito nell'immagine del contenitore per notificare che l'applicazione deve terminare e chiudere utilizzando le `STOPSIGNAL` istruzioni. Questo è l'`SIGTERM`impostazione predefinita. Quindi invierà un messaggio `SIGKILL` dopo aver atteso la `StopTimeout` durata impostata nella definizione dell'attività. 

DEPROVISIONING  
Amazon ECS deve eseguire operazioni aggiuntive dopo l'arresto del processo, ma prima che questo passi allo stato `STOPPED`. Ad esempio, per le attività che utilizzano la modalità di rete `awsvpc`, deve essere scollegata e rimossa l'interfaccia di rete elastica.

STOPPED  
L'arresto dell'attività è riuscito.  
Se l'attività è stata interrotta a causa di un errore, consultare [Visualizza gli errori relativi alle attività interrotte in Amazon ECS](stopped-task-errors.md).

ELIMINATO  
Si tratta di uno stato di transizione quando un'operazione viene interrotta. Questo stato non viene visualizzato nella console, ma viene visualizzato in `describe-tasks`.

# In che modo Amazon ECS colloca le attività sulle istanze dei container
<a name="task-placement"></a>

È possibile utilizzare il posizionamento delle attività per configurare Amazon ECS in modo da collocare le tue attività su istanze di container che soddisfano determinati criteri, ad esempio una zona di disponibilità o un tipo di istanza.

Di seguito sono riportati i componenti per il posizionamento delle attività:
+ Strategia di posizionamento delle attività: l'algoritmo per selezionare istanze di container per il posizionamento delle attività o attività per il termine. Ad esempio, Amazon ECS è in grado di selezionare istanze di container a caso oppure in modo tale che i processi vengano distribuiti in modo uniforme all'interno di un gruppo di istanze.
+ Gruppo di attività: un gruppo di attività correlate, ad esempio attività di database.
+ Vincolo di posizionamento delle attività: si tratta di regole che devono essere soddisfatte per inserire un'attività su un'istanza di container. Se il vincolo non viene soddisfatto, l'attività non viene inserita e rimane nello stato `PENDING`. Ad esempio, è possibile utilizzare un vincolo per posizionare attività solo su un particolare tipo di istanza. 

Amazon ECS dispone di algoritmi differenti per le diverse opzioni di capacità. 

## Istanze gestite da Amazon ECS
<a name="managed-instances-launch-type"></a>

Per le attività eseguite su Istanze gestite da Amazon, Amazon ECS deve determinare dove posizionare l'attività e, quando si riduce verticalmente il numero di attività, quali attività terminare. Amazon ECS effettua questa determinazione in base ai requisiti dell'istanza specificati nel modello di avvio del provider di capacità, ai requisiti specificati nella definizione dell'attività come CPU e memoria e ai vincoli di posizionamento delle attività.

**Nota**  
Le istanze gestite da Amazon ECS non supportano strategie di posizionamento delle attività. Amazon ECS farà del suo meglio per distribuire le attività tra zone di disponibilità accessibili.

Quando Amazon ECS posiziona i processi, utilizza la seguente procedura per selezionare le istanze di container:

1. Identificazione delle istanze di container che soddisfano i requisiti di memoria, CPU, GPU e porta nella definizione di attività.

1. Identificazione delle istanze di container che soddisfano i vincoli di posizionamento delle attività.

1. Identificazione delle istanze di container che soddisfano i requisiti di istanza specificati nel modello di lancio del provider di capacità.

1. Selezione delle istanze di container per il posizionamento delle attività.

## EC2
<a name="ec2-launch-type"></a>

Per attività che utilizzano il tipo di lancio EC2, Amazon ECS deve determinare dove posizionare il processo in base ai requisiti specificati nella definizione di attività, ad esempio relativamente a memoria e CPU. Analogamente, quando riduci orizzontalmente il conteggio di processi, Amazon ECS deve determinare quali processi terminare. Puoi applicare vincoli e strategie di posizionamento dei processi per personalizzare il modo in cui Amazon ECS posizione e termina i processi. 

Le strategie di posizionamento dei processi di default dipendono dal fatto che i processi vengano eseguiti manualmente (attività indipendenti) o all'interno di un servizio. Per le attività eseguite come parte di un servizio Amazon ECS, la strategia di posizionamento delle attività è `spread` e utilizza `attribute:ecs.availability-zone`. Non è presente un vincolo predefinito per il posizionamento delle attività non nei servizi. Per ulteriori informazioni, consultare [Pianificare i container su Amazon ECS](scheduling_tasks.md).

**Nota**  
Le strategie di posizionamento dei processi si basano sul miglior tentativo. Amazon ECS prova a posizionare i processi anche quando l'opzione di posizionamento ottimale non è disponibile. Tuttavia, i vincoli di posizionamento delle attività sono vincolanti, per cui potrebbero impedire il posizionamento delle attività. 

Puoi utilizzare strategie e vincoli di posizionamento delle attività contemporaneamente. Ad esempio, puoi utilizzare una strategia di posizionamento e un vincolo di posizionamento delle attività per distribuire le attività all'interno di zone di disponibilità e raggrupparle in bin packing in base alla memoria all'interno di ciascuna zona di disponibilità, ma solo per quanto riguarda le istanze G2.

Quando Amazon ECS posiziona i processi, utilizza la seguente procedura per selezionare le istanze di container:

1. Identificazione delle istanze di container che soddisfano i requisiti di memoria, CPU, GPU e porta nella definizione di attività.

1. Identificazione delle istanze di container che soddisfano i vincoli di posizionamento delle attività.

1. Identificazione delle istanze di container che soddisfano le strategie di posizionamento delle attività.

1. Selezione delle istanze di container per il posizionamento delle attività.

## Fargate
<a name="fargate-launch-type"></a>

Per attività con Fargate, le strategie e i vincoli di posizionamento dei processi non sono supportati. Fargate farà del suo meglio per distribuire le attività tra zone di disponibilità accessibili. Se il provider di capacità include sia Fargate che Fargate Spot, il comportamento di distribuzione sarà indipendente per ogni provider. 

# Dimensionamento automatico di Istanze gestite da Amazon ECS e posizionamento delle attività
<a name="managed-instance-auto-scaling"></a>

Le istanze gestite da Amazon ECS utilizzano algoritmi intelligenti per scalare automaticamente la capacità del cluster e posizionare le attività in modo efficiente nell'infrastruttura. Capire come funzionano questi algoritmi aiuta a ottimizzare le configurazioni dei servizi e a risolvere i problemi di posizionamento.

## Algoritmo di posizionamento delle attività
<a name="managed-instance-task-placement-algorithm"></a>

Le istanze gestite da Amazon ECS utilizzano un sofisticato algoritmo di posizionamento che bilancia disponibilità, utilizzo delle risorse e requisiti di rete durante la pianificazione delle attività.

### Diffusione della zona di disponibilità
<a name="managed-instance-az-spread-behavior"></a>

Per impostazione predefinita, le istanze gestite da Amazon ECS danno priorità alla disponibilità distribuendo le attività su più zone di disponibilità:
+ Per i servizi con più attività, le istanze gestite da Amazon ECS garantiscono la distribuzione su almeno 3 istanze in diverse zone di disponibilità, quando possibile.
+ Questo comportamento fornisce tolleranza ai guasti, ma può comportare un minore utilizzo delle risorse per istanza
+ La diffusione della zona di disponibilità ha la precedenza sull'ottimizzazione del bin packing

### Comportamento di bin packing
<a name="managed-instance-bin-packing"></a>

Sebbene le istanze gestite da Amazon ECS siano in grado di eseguire il bin packing per massimizzare l'utilizzo delle risorse, questo comportamento è influenzato dalla configurazione di rete:
+ Per eseguire il bin packing, configurare il servizio in modo che utilizzi una singola sottorete
+ Le configurazioni a più sottoreti danno priorità alla distribuzione delle zone di disponibilità rispetto alla densità delle risorse
+ Il bin packing è più probabile durante l'avvio iniziale del servizio che durante gli eventi di dimensionamento

### Considerazioni sulla densità dell'ENI
<a name="managed-instance-eni-density"></a>

Per i servizi che utilizzano la modalità di rete `awsvpc`, le istanze gestite da Amazon ECS considerano la densità dell'interfaccia di rete elastica (ENI) quando prendono decisioni di posizionamento:
+ Ogni attività in modalità `awsvpc` richiede un ENI dedicato
+ I tipi di istanza hanno limiti ENI diversi che influiscono sulla densità delle attività
+ Le istanze gestite da Amazon ECS tengono conto della disponibilità ENI durante la selezione delle istanze di destinazione

**Nota**  
Vengono continuamente apportati miglioramenti ai calcoli della densità ENI per ottimizzare le decisioni di posizionamento.

## Logica decisionale del provider di capacità
<a name="managed-instance-capacity-provider-decisions"></a>

I provider di capacità delle istanze gestite da Amazon ECS prendono decisioni di scalabilità e posizionamento in base a diversi fattori:

Requisiti per le risorse  
Requisiti di CPU, memoria e rete per le attività in sospeso

Disponibilità delle istanze  
Capacità e utilizzo attuali tra le istanze esistenti

Vincoli di rete  
Configurazione della sottorete e disponibilità ENI

Distribuzione delle zone di disponibilità  
Mantenimento della tolleranza ai guasti in più zone di disponibilità

## Opzioni di configurazione
<a name="managed-instance-configuration-options"></a>

### Strategia di selezione delle sottoreti
<a name="managed-instance-subnet-strategy"></a>

La configurazione della sottorete influisce in modo significativo sul comportamento di posizionamento delle attività:

Più sottoreti (impostazione predefinita)  
Assegna la priorità alla distribuzione della zona di disponibilità per un'elevata disponibilità  
Può comportare un minore utilizzo di risorse per istanza  
Consigliato per carichi di lavoro di produzione che richiedono tolleranza ai guasti

Sottorete singola  
Consente il bin packing per un maggiore utilizzo delle risorse  
Riduce la tolleranza ai guasti concentrando le attività in un'unica zona di disponibilità  
Adatto a carichi di lavoro di sviluppo o ottimizzati in termini di costi

### Considerazioni sulla modalità di rete
<a name="managed-instance-network-mode-considerations"></a>

La modalità di rete selezionata influisce sulle decisioni di posizionamento:
+ Modalità `awsvpc`: ogni attività richiede un ENI dedicato, limitando la densità delle attività per istanza
+ Modalità `host`: le attività utilizzano direttamente la rete dell'host, con il posizionamento basato principalmente sulla disponibilità delle risorse

### Considerazioni sull'architettura della CPU
<a name="managed-instance-cpu-architecture-considerations"></a>

Quanto `cpuArchitecture` specificato nella definizione dell'attività viene utilizzato per collocare le attività su un'architettura specifica. Se non specifichi un`cpuArchitecture`, Amazon ECS proverà a collocare le attività su qualsiasi architettura CPU disponibile in base alla configurazione del provider di capacità. È possibile specificare `X86_64` o `ARM64`.

## Risoluzione dei problemi di posizionamento delle attività
<a name="managed-instance-troubleshooting-placement"></a>

### Schemi comuni di posizionamento
<a name="managed-instance-common-placement-patterns"></a>

La comprensione degli schemi di posizionamento previsti aiuta a distinguere il comportamento normale dai potenziali problemi:

Distribuzione sparsa  
Attività distribuite su più istanze con utilizzo parziale  
Comportamento normale quando si utilizzano più sottoreti  
Indica la priorità della disponibilità rispetto all'efficienza delle risorse

Posizionamento concentrato  
Attività multiple assegnate a un minor numero di istanze con un utilizzo più elevato  
Previsto quando si utilizza la configurazione a sottorete singola  
Può verificarsi durante l'avvio iniziale del servizio

Distribuzione irregolare  
Alcune istanze sono molto utilizzate mentre altre rimangono sottoutilizzate  
Può indicare limiti ENI o vincoli di risorse  
Valutare la possibilità di rivedere i tipi di istanza e la configurazione

### Ottimizzazione del comportamento di posizionamento
<a name="managed-instance-placement-optimization"></a>

Per ottimizzare il posizionamento delle attività in base a esigenze specifiche:

1. Valutare i requisiti di disponibilità rispetto alle esigenze di ottimizzazione dei costi

1. Scegliere la configurazione di sottorete appropriata in base alle priorità

1. Selezionare i tipi di istanza con una capacità ENI adeguata per la modalità di rete

1. Monitorare i modelli di posizionamento e regolare la configurazione secondo necessità

## Best practice
<a name="managed-instance-best-practices"></a>
+ **Per carichi di lavoro di produzione**: utilizzare più sottoreti in diverse zone di disponibilità per garantire un'elevata disponibilità, accettando il compromesso in termini di utilizzo delle risorse
+ **Per lo sviluppo o il test**: prendere in considerazione la configurazione di una singola sottorete per massimizzare l'utilizzo delle risorse e ridurre i costi
+ **Per la modalità `awsvpc`**: scegliere i tipi di istanza con una capacità ENI sufficiente per evitare vincoli di posizionamento
+ **Per l'ottimizzazione dei costi**: monitorare i modelli di utilizzo e regolare la configurazione del servizio per bilanciare disponibilità ed efficienza
+ **Per la risoluzione dei problemi**: esaminare la configurazione della sottorete e la modalità di rete quando si esaminano schemi di posizionamento imprevisti

# Usare le strategie per definire il posizionamento delle attività su Amazon ECS
<a name="task-placement-strategies"></a>

Per attività che utilizzano il tipo di lancio EC2, Amazon ECS deve determinare dove posizionare il processo in base ai requisiti specificati nella definizione di attività, ad esempio relativamente a memoria e CPU. Analogamente, quando riduci orizzontalmente il conteggio di processi, Amazon ECS deve determinare quali processi terminare. Puoi applicare vincoli e strategie di posizionamento dei processi per personalizzare il modo in cui Amazon ECS posizione e termina i processi. 

Le strategie di posizionamento dei processi di default dipendono dal fatto che i processi vengano eseguiti manualmente (attività indipendenti) o all'interno di un servizio. Per le attività eseguite come parte di un servizio Amazon ECS, la strategia di posizionamento delle attività è `spread` e utilizza `attribute:ecs.availability-zone`. Non è presente un vincolo predefinito per il posizionamento delle attività non nei servizi. Per ulteriori informazioni, consultare [Pianificare i container su Amazon ECS](scheduling_tasks.md).

**Nota**  
Le strategie di posizionamento dei processi si basano sul miglior tentativo. Amazon ECS prova a posizionare i processi anche quando l'opzione di posizionamento ottimale non è disponibile. Tuttavia, i vincoli di posizionamento delle attività sono vincolanti, per cui potrebbero impedire il posizionamento delle attività. 

Puoi utilizzare strategie e vincoli di posizionamento delle attività contemporaneamente. Ad esempio, puoi utilizzare una strategia di posizionamento e un vincolo di posizionamento delle attività per distribuire le attività all'interno di zone di disponibilità e raggrupparle in bin packing in base alla memoria all'interno di ciascuna zona di disponibilità, ma solo per quanto riguarda le istanze G2.

Quando Amazon ECS posiziona i processi, utilizza la seguente procedura per selezionare le istanze di container:

1. Identificazione delle istanze di container che soddisfano i requisiti di memoria, CPU, GPU e porta nella definizione di attività.

1. Identificazione delle istanze di container che soddisfano i vincoli di posizionamento delle attività.

1. Identificazione delle istanze di container che soddisfano le strategie di posizionamento delle attività.

1. Selezione delle istanze di container per il posizionamento delle attività.

È possibile specificare le strategie di posizionamento delle attività nella definizione del servizio o la definizione delle attività utilizzando il parametro `placementStrategy`.

```
"placementStrategy": [
    {
        "field": "The field to apply the placement strategy against",
        "type": "The placement strategy to use"
    }
]
```

Puoi specificare le strategie quando esegui un'attività ([RunTask](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_RunTask.html)), crei un nuovo servizio ([CreateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateService.html)) o aggiorni un servizio esistente ([UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html)).

Nella tabella seguente vengono descritti i tipi e i campi disponibili.


| tipo | Valori di campo validi | 
| --- | --- | 
| binpack Le attività vengono posizionate sulle istanze di container in modo da lasciare la quantità minima di CPU o memoria inutilizzata. Questa strategia riduce al minimo il numero di istanze di container in uso. Quando viene utilizzata questa strategia e viene intrapresa un'operazione di riduzione orizzontale, Amazon ECS termina i processi. Esegui questa operazione in base alla quantità di risorse lasciate sull'istanza di container dopo che il processo è stato terminato. L'istanza di container con il maggior numero di risorse disponibili rimanenti dopo la fine del processo avrà il processo terminato. |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonECS/latest/developerguide/task-placement-strategies.html)  | 
| random Le attività vengono posizionate in modo casuale. | Non utilizzato | 
| spreadLe attività vengono posizionate in modo uniforme in base al valore specificato. Le attività di servizio vengono distribuite in base alle attività di tale servizio. Attività standalone sono distribuite sulle attività dallo stesso gruppo di attività. Per ulteriori informazioni sui gruppi di processi, consulta [Attività Amazon ECS relative al gruppo](task-groups.md). Quando la strategia `spread` viene utilizzata e viene intrapresa un'operazione di riduzione orizzontale, Amazon ECS seleziona i processi da terminare che mantengono un equilibrio in tutte le zone di disponibilità. All'interno di una zona di disponibilità, i processi vengono selezionati in modo casuale. |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonECS/latest/developerguide/task-placement-strategies.html)  | 

Le strategie di posizionamento delle attività possono essere aggiornate anche per i servizi esistenti. Per ulteriori informazioni, consultare [In che modo Amazon ECS colloca le attività sulle istanze dei container](task-placement.md).

Puoi creare una strategia di posizionamento delle attività che utilizzi più strategie tramite la creazione di una serie di strategie nell'ordine in cui desideri che vengano eseguite. Ad esempio, se desideri distribuire le attività tra le zone di disponibilità e raggrupparle in bin packing in base alla memoria all'interno di ciascuna zona di disponibilità, specifica la strategia della zona di disponibilità seguita dalla strategia della memoria. Per le strategie di esempio, consulta [Strategie di collocazione di esempio delle attività di Amazon ECS](strategy-examples.md).

# Strategie di collocazione di esempio delle attività di Amazon ECS
<a name="strategy-examples"></a>

È possibile specificare le strategie di posizionamento delle attività con le seguenti azioni: [CreateService[UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html)](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateService.html), e [RunTask](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_RunTask.html).

**Topics**
+ [Distribuire le attività in modo uniforme all'interno delle zone di disponibilità](#even-az)
+ [Distribuire le attività in modo uniforme su tutte le istanze](#even-instance)
+ [Raggruppare le attività in bin packing in base alla memoria](#binpack)
+ [Posizionare le attività casualmente](#random)
+ [Distribuire le attività in modo uniforme all'interno delle zone di disponibilità e distribuire le attività all'interno delle istanze in ciascuna zona di disponibilità](#az-instance)
+ [Distribuire le attività in modo uniforme all'interno delle zone di disponibilità e raggruppare le attività in bin packing in base alla memoria all'interno di ciascuna zona di disponibilità](#az-memory)
+ [Distribuire le attività in modo uniforme tra le istanze e raggruppare le attività in bin packing in base alla memoria](#instance-memory)

## Distribuire le attività in modo uniforme all'interno delle zone di disponibilità
<a name="even-az"></a>

La strategia seguente distribuisce le attività in modo uniforme all'interno delle zone di disponibilità.

```
"placementStrategy": [
    {
        "field": "attribute:ecs.availability-zone",
        "type": "spread"
    }
]
```

## Distribuire le attività in modo uniforme su tutte le istanze
<a name="even-instance"></a>

La strategia seguente distribuisce le attività in modo uniforme all'interno di tutte le istanze.

```
"placementStrategy": [
    {
        "field": "instanceId",
        "type": "spread"
    }
]
```

## Raggruppare le attività in bin packing in base alla memoria
<a name="binpack"></a>

La strategia seguente raggruppa le attività in bin packing in base alla memoria.

```
"placementStrategy": [
    {
        "field": "memory",
        "type": "binpack"
    }
]
```

## Posizionare le attività casualmente
<a name="random"></a>

La strategia seguente posiziona le attività in modo casuale.

```
"placementStrategy": [
    {
        "type": "random"
    }
]
```

## Distribuire le attività in modo uniforme all'interno delle zone di disponibilità e distribuire le attività all'interno delle istanze in ciascuna zona di disponibilità
<a name="az-instance"></a>

La strategia seguente distribuisce le attività in modo uniforme all'interno delle zone di disponibilità, quindi distribuisce le attività all'interno delle istanze in ciascuna zona di disponibilità.

```
"placementStrategy": [
    {
        "field": "attribute:ecs.availability-zone",
        "type": "spread"
    },
    {
        "field": "instanceId",
        "type": "spread"
    }
]
```

## Distribuire le attività in modo uniforme all'interno delle zone di disponibilità e raggruppare le attività in bin packing in base alla memoria all'interno di ciascuna zona di disponibilità
<a name="az-memory"></a>

La strategia seguente distribuisce le attività in modo uniforme all'interno delle zone di disponibilità, quindi raggruppa le attività in bin packing in base alla memoria all'interno di ciascuna zona di disponibilità.

```
"placementStrategy": [
    {
        "field": "attribute:ecs.availability-zone",
        "type": "spread"
    },
    {
        "field": "memory",
        "type": "binpack"
    }
]
```

## Distribuire le attività in modo uniforme tra le istanze e raggruppare le attività in bin packing in base alla memoria
<a name="instance-memory"></a>

La seguente strategia distribuisce le attività in modo uniforme tra le istanze, quindi raggruppa le attività in bin packing in base alla memoria all'interno di ciascuna istanza. 

```
"placementStrategy": [
    {
        "field": "instanceId",
        "type": "spread"
    },
    {
        "field": "memory",
        "type": "binpack"
    }
]
```

# Attività Amazon ECS relative al gruppo
<a name="task-groups"></a>

È possibile identificare una serie di attività correlate e inserirle in un gruppo di attività. Tutti i processi con lo stesso nome del gruppo di processi sono considerati come un set quando si utilizza la strategia di posizionamento dei processi `spread`. Ad esempio, supponiamo che stia eseguendo diverse applicazioni in un unico cluster, come database e server Web. Per assicurarti che i database siano bilanciati all'interno delle zone di disponibilità, aggiungili a un gruppo di processi denominato `databases`, quindi utilizza la strategia di posizionamento dei processi `spread`. Per ulteriori informazioni, consultare [Usare le strategie per definire il posizionamento delle attività su Amazon ECS](task-placement-strategies.md).

I gruppi di processi possono essere utilizzati anche come vincolo di posizionamento dei processi. Quando specifichi un gruppo di attività nel vincolo `memberOf`, le attività vengono inviate solo alle istanze di container presenti nel gruppo di attività specificato. Per vedere un esempio, consulta [Vincoli di posizionamento di esempio delle attività di Amazon ECS](constraint-examples.md).

Di default, i processi autonomi utilizzano il nome della famiglia della definizione di attività (ad esempio, `family:my-task-definition`) come nome del gruppo di processi se non è specificato un nome di gruppo di processi personalizzato. I processi avviati come parte di un servizio utilizzano il nome del servizio come nome del gruppo di processi e non possono essere modificati.

Si applicano i seguenti requisiti per il gruppo di attività.
+ Il nome di un gruppo di processi deve essere al massimo di 255 caratteri.
+ Ciascuna attività può trovarsi in un solo gruppo.
+ Dopo l'avvio di un processo, non è possibile modificarne il gruppo di attività.

# Definisci quali istanze di container utilizza Amazon ECS per le attività
<a name="task-placement-constraints"></a>

Un vincolo di posizionamento delle attività è una regola relativa a un'istanza di container che Amazon ECS utilizza per determinare se l'attività può essere eseguita sull'istanza. Almeno un'istanza di container deve corrispondere al vincolo. Se non sono presenti istanze corrispondenti al vincolo, l'attività rimane in uno stato `PENDING`. Quando crei un nuovo servizio o ne aggiorni uno esistente, puoi specificare i vincoli di posizionamento delle attività per le attività del servizio. 

È possibile specificare i vincoli di posizionamento delle attività nella definizione del servizio, nella definizione delle attività o nelle attività utilizzando il parametro `placementConstraint`.

```
"placementConstraints": [
    {
        "expression": "The expression that defines the task placement constraints",
        "type": "The placement constraint type to use"
    }
]
```

Nella tabella seguente viene descritta la modalità di utilizzo di questi parametri.


| Tipo di vincolo | Può essere specificato quando | 
| --- | --- | 
| distinctInstancePosizionamento di ciascuna attività attiva in una istanza di container differente.Amazon ECS esamina lo stato desiderato delle attività per il posizionamento delle stesse. Ad esempio, se lo stato desiderato dell'attività esistente è `STOPPED`, (ma l'ultimo stato non lo è), una nuova attività in arrivo può essere posizionata nella stessa istanza nonostante il vincolo di posizionamento `distinctInstance`. Pertanto, è possibile che vengano visualizzate 2 attività con l'ultimo stato di `RUNNING` nella stessa istanza. Consigliamo ai clienti che cercano un forte isolamento per le proprie attività di utilizzare Fargate. Fargate esegue ogni attività in un ambiente di virtualizzazione hardware. Ciò garantisce che tali carichi di lavoro containerizzati non condividono le interfacce di rete, lo spazio di archiviazione temporaneo, la CPU o la memoria di Fargate con altre attività. Per ulteriori informazioni, vedere [Panoramica sulla sicurezza di AWS Fargate](https://d1.awsstatic.com/whitepapers/AWS_Fargate_Security_Overview_Whitepaper.pdf). |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonECS/latest/developerguide/task-placement-constraints.html)  | 
| memberOfPosizionamento delle attività in istanze di container che soddisfano un'espressione.  | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonECS/latest/developerguide/task-placement-constraints.html) | 

Quando si utilizza il tipo di vincolo `memberOf`, è possibile creare un'espressione utilizzando il linguaggio di interrogazione del cluster che definisce le istanze di container in cui Amazon ECS può posizionare le attività. L'espressione è un modo per raggruppare le istanze di container in base agli attributi. L'espressione rientra nel parametro `expression ` di `placementConstraint`.

## Attributi delle istanze di container di Amazon ECS
<a name="attributes"></a>

Puoi aggiungere metadati personalizzati alle istanze di container, note come *attributi*. Ogni attributo ha un nome e un valore di stringa facoltativo. Puoi utilizzare gli attributi integrati offerti da Amazon ECS oppure definire attributi personalizzati.

Le sezioni seguenti contengono attributi incorporati, facoltativi e personalizzati di esempio.

### Attributi integrati
<a name="ecs-automatic-attributes"></a>

Amazon ECS applica automaticamente i seguenti attributi alle istanze di container.

`ecs.ami-id`  
L'ID dell'AMI utilizzato per avviare l'istanza. Un valore di esempio per questo attributo è `ami-1234abcd`.

`ecs.availability-zone`  
La zona di disponibilità dell'istanza. Un valore di esempio per questo attributo è `us-east-1a`.

`ecs.instance-type`  
Il tipo di istanza dell'istanza. Un valore di esempio per questo attributo è `g2.2xlarge`.

`ecs.os-type`  
Il sistema operativo dell'istanza. I valori possibili per questo attributo sono `linux` e `windows`.

`ecs.os-family`  
La versione del sistema operativo dell'istanza.  
Per le istanze Linux, il valore valido è `LINUX`. Per le istanze Windows, ECS imposta il valore nel formato `WINDOWS_SERVER_<OS_Release>_<FULL or CORE>`. I valori validi sono `WINDOWS_SERVER_2022_FULL`, `WINDOWS_SERVER_2022_CORE`, `WINDOWS_SERVER_20H2_CORE`, `WINDOWS_SERVER_2019_FULL`, `WINDOWS_SERVER_2019_CORE` e `WINDOWS_SERVER_2016_FULL`.  
Questo è importante per i contenitori Windows e Windows containers on AWS Fargate perché la versione del sistema operativo di ogni contenitore Windows deve corrispondere a quella dell'host. Se la versione Windows dell'immagine del container è diversa da quella dell'host, il container non si avvia. Per ulteriori informazioni, consultare [Compatibilità delle versioni dei container Windows](https://learn.microsoft.com/en-us/virtualization/windowscontainers/deploy-containers/version-compatibility?tabs=windows-server-2022%2Cwindows-11) sul sito Web della documentazione Microsoft.  
Se il cluster esegue più versioni di Windows, puoi assicurarti che un'attività venga posizionata su un'istanza EC2 in esecuzione sulla stessa versione utilizzando il vincolo di posizionamento: `memberOf(attribute:ecs.os-family == WINDOWS_SERVER_<OS_Release>_<FULL or CORE>)`. Per ulteriori informazioni, consultare [Recupero dei metadati dell'AMI Windows ottimizzata per Amazon ECS](retrieve-ecs-optimized_windows_AMI.md).

`ecs.cpu-architecture`  
Architettura della CPU per l'istanza. I valori di esempio per questo attributo sono `x86_64` e `arm64`.

`ecs.vpc-id`  
VPC in cui è stata avviata l'istanza. Un valore di esempio per questo attributo è `vpc-1234abcd`.

`ecs.subnet-id`  
La sottorete utilizzata dall'istanza. Un valore di esempio per questo attributo è `subnet-1234abcd`.

**Nota**  
Le istanze gestite da Amazon ECS supportano il seguente sottoinsieme di attributi:  
`ecs.subnet-id`
`ecs.availability-zone`
`ecs.instance-type`
`ecs.cpu-architecture`

### Attributi facoltativi
<a name="ecs-optional-attributes"></a>

Amazon ECS può aggiungere i seguenti attributi alle istanze di container.

`ecs.awsvpc-trunk-id`  
Se questo attributo esiste, l'istanza dispone di un'interfaccia di rete trunk. Per ulteriori informazioni, consultare [Aumento delle interfacce di rete delle istanze di container Linux di Amazon ECS](container-instance-eni.md).

`ecs.outpost-arn`  
Se questo attributo esiste, contiene l'Amazon Resource Name (ARN) dell'Outpost. Per ulteriori informazioni, consultare [Amazon Elastic Container Service su AWS Outposts](using-outposts.md).

`ecs.capability.external`  
Se questo attributo esiste, l'istanza viene identificata come un'istanza esterna. Per ulteriori informazioni, consultare [Cluster Amazon ECS per istanze esterne](ecs-anywhere.md).

### Attributi personalizzati
<a name="ecs-custom-attributes"></a>

È possibile applicare attributi personalizzati alle istanze di container. Ad esempio, è possibile definire un attributo con il nome "stack" e un valore di "prod".

Quando si specificano attributi personalizzati, è necessario considerare quanto segue.
+ Il `name` può contenere un massimo di 128 caratteri e può contenere lettere (maiuscole e minuscole), numeri, trattini, caratteri di sottolineatura, barre, barre inverse o punti.
+ Il `value` può contenere un massimo di 128 caratteri e può contenere lettere (maiuscole e minuscole), numeri, trattini, caratteri di sottolineatura, punti, chiocciola (@), barre, barre inverse, due punti o spazi. Il valore non può contenere spazi iniziali o finali.

# Creare espressioni per definire istanze di container per le attività di Amazon ECS
<a name="cluster-query-language"></a>

Le query di cluster sono espressioni che consentono di raggruppare gli oggetti. Ad esempio, puoi raggruppare le istanze di container per attributi, ad esempio la zona di disponibilità, il tipo di istanza o metadati personalizzati. Per ulteriori informazioni, consultare [Attributi delle istanze di container di Amazon ECS](task-placement-constraints.md#attributes).

Dopo aver definito un gruppo di istanze di container, potrai personalizzare Amazon ECS per posizionare i processi su istanze di container basate sul gruppo. Per ulteriori informazioni, consultare [Esecuzione di un'applicazione come attività Amazon ECS](standalone-task-create.md) e [Creazione di un'implementazione di aggiornamenti continui di Amazon ECS](create-service-console-v2.md). Puoi inoltre applicare un filtro di gruppo per elencare le istanze di container.

## Sintassi delle espressioni
<a name="expression-syntax"></a>

Le espressioni presentano la sintassi seguente:

```
subject operator [argument]
```

**Subject**  
L'attributo o il campo da valutare.

`agentConnected`  
Seleziona le istanze di container in base allo stato di connessione dell'agente del container di Amazon ECS. È possibile usare questo filtro per cercare le istanze con agenti di container che sono disconnessi.  
Operatori validi: equals (==), not\$1equals (\$1=), in, not\$1in (\$1in), matches (=\$1), not\$1matches (\$1\$1)

`agentVersion`  
Seleziona le istanze di container in base alla versione dell'agente del container di Amazon ECS. È possibile usare questo filtro per trovare le istanze che eseguono le versioni obsolete dell'agente del container Amazon ECS.  
Operatori validi: equals (==), not\$1equals (\$1=), greater\$1than (>), greater\$1than\$1equal (>=), less\$1than (<), less\$1than\$1equal (<=)

`attribute:attribute-name`  
Seleziona le istanze di container per attributo. Per ulteriori informazioni, consultare [Attributi delle istanze di container di Amazon ECS](task-placement-constraints.md#attributes).

`ec2InstanceId`  
Seleziona le istanze di container in base al loro ID istanza di Amazon EC2.  
Operatori validi: equals (==), not\$1equals (\$1=), in, not\$1in (\$1in), matches (=\$1), not\$1matches (\$1\$1)

`registeredAt`  
Seleziona le istanze di container in base alla loro data di registrazione dell'istanza di container. È possibile usare questo filtro per individuare le istanze appena registrate o le istanze molto vecchie.  
Operatori validi: equals (==), not\$1equals (\$1=), greater\$1than (>), greater\$1than\$1equal (>=), less\$1than (<), less\$1than\$1equal (<=)  
Formati di data validi: 2018-06-18T22:28:28\$100:00, 2018-06-18T22:28:28Z, 2018-06-18T22:28:28, 2018-06-18

`runningTasksCount`  
Seleziona le istanze di container in base al numero di attività in esecuzione. È possibile usare questo filtro per trovare le istanze che sono vuote o quasi vuote (poche attività in esecuzione su di esse).  
Operatori validi: equals (==), not\$1equals (\$1=), greater\$1than (>), greater\$1than\$1equal (>=), less\$1than (<), less\$1than\$1equal (<=)

`task:group`  
Seleziona le istanze di container per gruppo di attività. Per ulteriori informazioni, consultare [Attività Amazon ECS relative al gruppo](task-groups.md).

**Operatore**  
L'operatore di confronto. Sono supportati i seguenti operatori.


|  Operatore  |  Description  | 
| --- | --- | 
|  ==, equals  |  Uguaglianza stringhe  | 
|  \$1=, not\$1equals  |  Disuguaglianza stringhe  | 
|  >, greater\$1than  |  Maggiore di  | 
|  >=, greater\$1than\$1equal  |  Maggiore di o uguale a  | 
|  <, less\$1than  |  Minore di  | 
|  <=, less\$1than\$1equal  |  Minore di o uguale a  | 
|  exists  |  Il soggetto esiste  | 
|  \$1exists, not\$1exists  |  Il soggetto non esiste  | 
|  in  |  Il valore è nell'elenco di argomenti  | 
|  \$1in, not\$1in  |  Il valore non è nell'elenco di argomenti  | 
|  =\$1, matches  |  Corrispondenza modelli  | 
|  \$1\$1, not\$1matches  |  Mancata corrispondenza modelli  | 

**Nota**  
Una singola espressione non può contenere parentesi. Tuttavia, le parentesi possono essere utilizzate per specificare la precedenza in espressioni composte.

**Argomento**  
Per molti operatori, l'argomento è un valore letterale.

Gli operatori `in` e `not_in` prevedono come argomento un elenco di argomenti. È necessario specificare un elenco di argomenti nel modo seguente:

```
[argument1, argument2, ..., argumentN]
```

Gli operatori matches e not\$1matches prevedono un argomento conforme alla sintassi di espressione regolare di Java. Per ulteriori informazioni, consultare [java.util.regex.Pattern](http://docs.oracle.com/javase/6/docs/api/java/util/regex/Pattern.html).

**Espressioni composte**

Puoi combinare espressioni tramite gli operatori booleani seguenti:
+ &&, e
+ \$1\$1, oppure
+ \$1, not

Puoi specificare la precedenza utilizzando le parentesi:

```
(expression1 or expression2) and expression3
```

## Espressioni di esempio
<a name="expression-examples"></a>

Vengono riportate di seguito espressioni di esempio.

**Esempio: uguaglianza stringhe**  
L'espressione seguente seleziona le istanze con il tipo di istanza specificato.

```
attribute:ecs.instance-type == t2.small
```

**Esempio: elenco di argomenti**  
L'espressione seguente seleziona le istanze nelle zone di disponibilità us-east-1a o us-east-1b.

```
attribute:ecs.availability-zone in [us-east-1a, us-east-1b]
```

**Esempio: espressione composta**  
L'espressione composta seguente seleziona le istanze G2 che non si trovano nella zona di disponibilità us-east-1d.

```
attribute:ecs.instance-type =~ g2.* and attribute:ecs.availability-zone != us-east-1d
```

**Esempio: affinità di attività**  
L'espressione seguente seleziona le istanze che non ospitano le attività nel gruppo `service:production`.

```
task:group == service:production
```

**Esempio:non affinità di attività**  
L'espressione seguente seleziona le istanze che non ospitano i processi nel gruppo di database.

```
not(task:group == database)
```

**Esempio: conteggio dell'attività in esecuzione**  
L'espressione seguente seleziona le istanze sulle quali è in esecuzione solo un'attività.

```
runningTasksCount == 1
```

**Esempio: Versione dell'agente del container di Amazon ECS**  
L'espressione seguente seleziona le istanze che eseguono una versione dell' agente del container inferiore a 1.14.5.

```
agentVersion < 1.14.5
```

**Esempio: tempo di registrazione dell'istanza**  
L'espressione seguente seleziona le istanze che sono state registrate prima del 13 febbraio 2018.

```
registeredAt < 2018-02-13
```

**Esempio: ID dell'istanza Amazon EC2**  
L'espressione seguente seleziona le istanze con la seguente istanza Amazon EC2. IDs

```
ec2InstanceId in ['i-abcd1234', 'i-wxyx7890']
```

# Vincoli di posizionamento di esempio delle attività di Amazon ECS
<a name="constraint-examples"></a>

Di seguito sono elencati esempi di vincoli del posizionamento delle attività.

In questo esempio viene utilizzata la restrizione `memberOf` per posizionare attività sulle istanze t2. Può essere specificata con le seguenti azioni: [CreateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateService.html), [UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html), [RegisterTaskDefinition](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_RegisterTaskDefinition.html)e. [RunTask](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_RunTask.html)

```
"placementConstraints": [
    {
        "expression": "attribute:ecs.instance-type =~ t2.*",
        "type": "memberOf"
    }
]
```

L'esempio utilizza il vincolo `memberOf` per posizionare le attività di replica su istanze con attività nel gruppo di attività `daemon-service` del servizio daemon, rispettando tutte le strategie di posizionamento eventualmente specificate. Questo vincolo garantisce che le attività del servizio daemon vengano posizionate sull'istanza EC2 prima delle attività di replica del servizio.

Sostituisci `daemon-service` con il nome del servizio daemon.

```
"placementConstraints": [
    {
        "expression": "task:group == service:daemon-service",
        "type": "memberOf"
    }
]
```

Nell'esempio è utilizzato il vincolo `memberOf` per posizionare i processi su istanze con altri processi nel gruppo di processi `databases`, rispettando tutte le strategie di posizionamento dei processi che sono eventualmente specificate. Per ulteriori informazioni sui gruppi di processi, consulta [Attività Amazon ECS relative al gruppo](task-groups.md). Può essere specificato con le seguenti azioni: [CreateService[UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html)](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateService.html), [RegisterTaskDefinition](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_RegisterTaskDefinition.html), e [RunTask](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_RunTask.html).

```
"placementConstraints": [
    {
        "expression": "task:group == databases",
        "type": "memberOf"
    }
]
```

La restrizione `distinctInstance` posiziona ciascuna attività nel gruppo su un'istanza diversa. Può essere specificato con le seguenti azioni: [CreateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateService.html), [UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html), e [RunTask](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_RunTask.html)

Amazon ECS esamina lo stato desiderato delle attività per il posizionamento delle stesse. Ad esempio, se lo stato desiderato dell'attività esistente è `STOPPED`, (ma l'ultimo stato non lo è), una nuova attività in arrivo può essere posizionata nella stessa istanza nonostante il vincolo di posizionamento `distinctInstance`. Pertanto, è possibile che vengano visualizzate 2 attività con l'ultimo stato di `RUNNING` nella stessa istanza.

```
"placementConstraints": [
    {
        "type": "distinctInstance"
    }
]
```

# Attività autonome di Amazon ECS
<a name="standalone-tasks"></a>

È possibile eseguire l'applicazione come attività quando si dispone di un'applicazione che esegue alcune operazioni e quindi interrompe, ad esempio un processo in batch. Se si desidera eseguire un'operazione una sola volta, è possibile utilizzare la console AWS CLI, APIs, o SDKs.

Se è necessario eseguire l'applicazione in base a una pianificazione basata sulla frequenza, su cronn o una tantum, è possibile creare una pianificazione utilizzando Scheduler. EventBridge 

## Flusso di lavoro delle attività
<a name="task-workflow"></a>

Quando si avviano attività di Amazon ECS (autonome o tramite servizi Amazon ECS), un'attività viene creata e inizialmente spostata nello stato `PROVISIONING`. Quando un'attività è nello stato `PROVISIONING`, non esistono né l'attività né i container perché Amazon ECS deve trovare la capacità di calcolo per posizionare l'attività.

Amazon ECS seleziona la capacità di elaborazione appropriata per l'attività in base al tipo di avvio o alla configurazione del provider di capacità. È possibile utilizzare i fornitori di capacità e le strategie dei provider di capacità con Fargate ed EC2. Con Fargate, non è necessario pensare al provisioning, alla configurazione e alla scalabilità della capacità del cluster. Fargate si occupa di tutta la gestione dell'infrastruttura per le tue attività. Per EC2, è possibile gestire la capacità del cluster registrando le istanze Amazon EC2 nel cluster oppure si può utilizzare il dimensionamento automatico del cluster per semplificare la gestione della capacità di calcolo. Il dimensionamento automatico del cluster si occupa del dimensionamento dinamico della capacità del cluster, per concentrarsi sulle attività in esecuzione. Amazon ECS determina dove posizionare l'attività in base ai requisiti specificati nella definizione dell'attività, ad esempio CPU e memoria, oltre ai vincoli e alle strategie di posizionamento. Per ulteriori informazioni, consultare [In che modo Amazon ECS colloca le attività sulle istanze dei container](task-placement.md).

Se si usa un provider di capacità con dimensionamento gestito abilitato, le attività che non possono essere avviate a causa della mancanza di capacità di elaborazione vengono spostate nello stato `PROVISIONING` anziché avere immediatamente un esito negativo. Dopo aver trovato la capacità di collocare l'attività, Amazon ECS fornisce gli allegati necessari (ad esempio, Elastic Network Interfaces (ENIs) per le attività in `awsvpc` modalità). Utilizza l'agente container Amazon ECS per estrarre le immagini dei container e quindi avviare i container. Dopo il completamento del provisioning e l'avvio dei container pertinenti, Amazon ECS sposta l'attività nello stato `RUNNING`. Per ulteriori informazioni sugli stati delle attività, consultare [Ciclo di vita dei processi di Amazon ECS](task-lifecycle-explanation.md).

# Esecuzione di un'applicazione come attività Amazon ECS
<a name="standalone-task-create"></a>

È possibile creare un'attività per un processo singolo utilizzando Console di gestione AWS.

**Per creare un'attività autonoma (Console di gestione AWS)**

1. [Apri la console nella versione 2. https://console.aws.amazon.com/ecs/](https://console.aws.amazon.com/ecs/v2)

1. La console Amazon ECS consente di creare un'attività autonoma dalla pagina dei dettagli del cluster o dall'elenco di revisione delle definizioni delle attività. Utilizzare la procedura seguente per creare un'attività autonoma in base alla pagina di risorse scelta.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonECS/latest/developerguide/standalone-task-create.html)

1. Per **Cluster esistente**, scegliere il cluster.

   Scegliere **Crea cluster** per eseguire l'attività su un nuovo cluster

1. Scegliere come vengono distribuite le attività nell'infrastruttura cluster. In **Configurazione di calcolo**, scegliere l'opzione desiderata. Per utilizzare una strategia di provider di capacità, è necessario configurare i provider di capacità a livello di cluster. 

   Se il cluster non è stato configurato per utilizzare un provider di capacità, utilizzare invece un tipo di avvio.

   Se si desidera eseguire i carichi di lavoro su istanze gestite da Amazon ECS, è necessario utilizzare l'opzione di strategia del provider di capacità.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonECS/latest/developerguide/standalone-task-create.html)

1. Nella sezione **Configurazione implementazione**, procedere come segue.

   1. Per **Definizione dell'attività**, inserire la definizione dell'attività.
**Importante**  
La console convalida la selezione per garantire che la famiglia di definizioni dell'attività e la revisione selezionate siano compatibili con la configurazione di calcolo definita.

   1. Per **Desired tasks** (Attività desiderate), specifica il numero di attività da avviare.

   1. Per **Gruppo di attività**, inserire il nome del gruppo di attività.

1. Se la tua definizione di attività utilizza la modalità di rete `awsvpc`, espandi **Networking** (Rete). Per specificare una configurazione personalizzata, completa la procedura riportata di seguito.

   1. Per **VPC** seleziona il VPC da utilizzare.

   1. Per **Subnets** (Sottoreti), seleziona una o più sottoreti nel VPC che lo scheduler di attività deve prendere in considerazione quando posiziona le attività.

   1. Per **Gruppi di sicurezza** puoi scegliere un gruppo di sicurezza esistente o crearne uno nuovo. Per utilizzare un gruppo di sicurezza esistente, scegli il gruppo di sicurezza e passa alla fase successiva. Per creare un nuovo gruppo di sicurezza, scegliere **Create a new security group (Crea un nuovo gruppo di sicurezza)**. È necessario specificare un nome e una descrizione del gruppo di sicurezza e aggiungere una o più regole in entrata per il gruppo di sicurezza.

   1. Per **IP pubblico** scegli se assegnare automaticamente un indirizzo IP pubblico all'interfaccia di rete elastica (ENI) del processo stesso.

      AWS Fargate alle attività può essere assegnato un indirizzo IP pubblico quando vengono eseguite in una sottorete pubblica in modo che abbiano un percorso verso Internet. Non è possibile assegnare un IP pubblico alle attività EC2 utilizzando questo campo. Per ulteriori informazioni, consultare [Amazon ECS task networking options for Fargate](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/fargate-task-networking.html) e [Allocate a network interface for an Amazon ECS task](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-networking-awsvpc.html).

1. Se l'attività utilizza un volume di dati compatibile con la configurazione al momento dell'implementazione, è possibile configurarlo espandendo **Volume**.

   Il nome del volume e il tipo di volume vengono configurati durante la creazione di una revisione della definizione di attività e non possono essere modificati quando si esegue un'attività autonoma. Per aggiornare il nome e il tipo di volume, è necessario creare una nuova revisione della definizione di attività ed eseguire un'attività utilizzando la nuova revisione.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonECS/latest/developerguide/standalone-task-create.html)

1. (Facoltativo) Per utilizzare una strategia di posizionamento delle attività diversa da quella predefinita, espandi **Task Placement** (Posizionamento attività), quindi scegli una tra le seguenti opzioni.

    Per ulteriori informazioni, consultare [In che modo Amazon ECS colloca le attività sulle istanze dei container](task-placement.md).
   + **Distribuzione con bilanciamento AZ**: consente di distribuire le attività tra zone di disponibilità e istanze di container nella zona di disponibilità.
   + **AZ Balanced BinPack**: distribuisci le attività tra zone di disponibilità e tra istanze di container con la minor quantità di memoria disponibile.
   + **BinPack**— Distribuisci le attività in base alla quantità minima disponibile di CPU o memoria.
   + **One Task Per Host (Un’attività per host)**: consente di posizionare al massimo un’attività dal servizio in ogni istanza di container.
   + **Personalizzato**: consente di definire una strategia personalizzata di posizionamento delle attività. 

   Se hai scelto **Custom** (Personalizzato), definisci l'algoritmo per il posizionamento delle attività e le regole che vengono prese in considerazione durante il posizionamento delle attività.
   + In **Strategy** (Strategia), per **Type** (Tipo) e **Field** (Campo), scegli l'algoritmo e l'entità da utilizzare per l'algoritmo.

     Puoi aggiungere un massimo di 5 strategie.
   + In **Vincolo**, per **Tipo** ed **Espressione**, scegli la regola e l'attributo per il vincolo.

     Ad esempio, per impostare il vincolo per posizionare le attività su istanze T2, per **Expression** (Espressione), immetti **attribute:ecs.instance-type =\$1 t2.\$1**.

     Puoi aggiungere un massimo di 10 vincoli.

1. (Facoltativo) Per sovrascrivere il ruolo IAM dell'attività o il ruolo di esecuzione dell'attività definito nella definizione dell'attività, espandi **Task overrides** (Sostituzione dei processi), quindi completa la procedura seguente:

   1. Per **Ruolo attività**, scegli un ruolo IAM per questa attività. Per ulteriori informazioni, consultare [Ruolo IAM dell'attività Amazon ECS](task-iam-roles.md).

      Vengono visualizzati solo i ruoli con la relazione di attendibilità `ecs-tasks.amazonaws.com`. Per istruzioni su come creare manualmente un ruolo IAM, consulta [Creazione del ruolo IAM dell'attività](task-iam-roles.md#create_task_iam_policy_and_role).

   1. Per **Ruolo di esecuzione attività**, scegli un ruolo di esecuzione dell'attività. Per ulteriori informazioni, consultare [Ruolo IAM di esecuzione di attività Amazon ECS](task_execution_IAM_role.md).

1. (Facoltativo) Per sovrascrivere i comandi del container e le variabili di ambiente, espandi **Container Overrides** (Sostituzione dei container), quindi espandi il container.
   +  Per inviare al container un comando diverso dal comando di definizione dell'attività, inserisci il comando Docker in **Sostituzione comando**.
   + Per aggiungere una variabile di ambiente, seleziona **Add Environment Variable** (Aggiungi variabile di ambiente). In **Chiave**, digita il nome della variabile di ambiente. Per **Valore** immetti un valore di stringa per il valore di ambiente (senza le virgolette doppie (`" "`)).

     AWS racchiude le stringhe tra virgolette doppie (» «) e passa la stringa al contenitore nel seguente formato:

     ```
     MY_ENV_VAR="This variable contains a string."
     ```

1. (Facoltativo) Per identificare la tua attività, espandi la sezione **Tags** (Tag), quindi configura i tag.

   Per fare in modo che Amazon ECS contrassegni automaticamente tutte le attività appena avviate con il nome del cluster e i tag di definizione delle attività, seleziona **Turn on Amazon ECS managed tags** (Attiva i tag gestiti da Amazon ECS), quindi seleziona **Task definitions** (Definizioni di attività).

   Aggiungi o rimuovi un tag.
   + [Aggiungi un tag] Scegli **Add tag** (Aggiungi tag), quindi effettuare le seguenti operazioni:
     + In **Chiave**, immetti il nome della chiave.
     + In **Valore**, immetti il valore della chiave.
   + [Rimuovere un tag] Accanto al tag, scegliere **Remove tag (Rimuovi tag)**.

1. Scegli **Create** (Crea).

# Utilizzo di Amazon EventBridge Scheduler per pianificare le attività di Amazon ECS
<a name="tasks-scheduled-eventbridge-scheduler"></a>

EventBridge Scheduler è uno strumento di pianificazione senza server che consente di creare, eseguire e gestire attività da un unico servizio gestito centralizzato. Fornisce funzionalità di pianificazione una tantum e ricorrenti indipendentemente dai bus e dalle regole degli eventi. EventBridge Scheduler è altamente personalizzabile e offre una migliore scalabilità rispetto alle regole EventBridge pianificate, con un set più ampio di operazioni e servizi API di destinazione. AWS EventBridge Scheduler fornisce le seguenti pianificazioni che puoi configurare per le tue attività nella console Scheduler: EventBridge 
+ Basata sulla frequenza 
+ Basate su cron

  Puoi configurare le pianificazioni basate su cron in qualsiasi fuso orario.
+ Pianificazioni una tantum

  È possibile configurare le pianificazioni una tantum in qualsiasi fuso orario.

Puoi pianificare Amazon ECS utilizzando Amazon EventBridge Scheduler.

Sebbene sia possibile creare un'attività pianificata nella console Amazon ECS, attualmente la console EventBridge Scheduler offre più funzionalità.

Prima di pianificare un'attività, completa la procedura seguente:

1. Usa la console VPC per ottenere la sottorete IDs in cui vengono eseguite le attività e il gruppo di sicurezza IDs per le sottoreti. Per ulteriori informazioni, consulta [Subnet per il tuo VPC](https://docs.aws.amazon.com/vpc/latest/userguide/configure-subnets.html) e [Controlla il traffico verso AWS le tue risorse utilizzando i gruppi di sicurezza nella](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-security-groups.html) Amazon *VPC* User Guide.

1. Configura il ruolo di esecuzione di EventBridge Scheduler. Per ulteriori informazioni, consulta [Configurare il ruolo di esecuzione](https://docs.aws.amazon.com/scheduler/latest/UserGuide/setting-up.html#setting-up-execution-role) nella *Amazon EventBridge Scheduler User Guide*. 

1. Se si desidera utilizzare una strategia di provider di capacità, è necessario disporre di un provider di capacità associato al cluster.

**Per creare una nuova pianificazione utilizzando la console**

1. Apri la console Amazon EventBridge Scheduler a [https://console.aws.amazon.com/scheduler/casa](https://console.aws.amazon.com/scheduler/home/).

1.  Nella pagina **Pianificazioni**, scegli **Crea pianificazione**. 

1.  Nella pagina **Specifica i dettagli della pianificazione**, nella sezione **Nome e descrizione della pianificazione**, effettua le seguenti operazioni: 

   1. Per **Nome pianificazione**, inserisci un nome per la pianificazione. Ad esempio, **MyTestSchedule**. 

   1. (Facoltativo) Per **Descrizione**, inserisci una descrizione per la pianificazione. Ad esempio, **TestSchedule**.

   1. Per **Gruppo di pianificazioni**, scegliere un gruppo di pianificazioni. Se non hai un gruppo, scegli **predefinito**. Per creare un gruppo di pianificazioni, scegli **crea la tua pianificazione**. 

      I gruppi di pianificazione vengono utilizzati per aggiungere tag a gruppi di pianificazioni. 

1. Scegli le opzioni di pianificazione.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonECS/latest/developerguide/tasks-scheduled-eventbridge-scheduler.html)

1. (Facoltativo) Se hai scelto **Pianificazione ricorrente** nel passaggio precedente, nella sezione **Intervallo di tempo** effettua le seguenti operazioni: 

   1. Per **Fuso orario**, scegli un fuso orario. 

   1. Per **Data e ora di inizio**, inserisci una data valida in formato `YYYY/MM/DD`, quindi specifica un timestamp in formato `hh:mm` 24 ore. 

   1. Per **Data e ora di fine**, inserisci una data valida in formato `YYYY/MM/DD`, quindi specifica un timestamp in formato `hh:mm` 24 ore. 

1. Scegli **Next (Successivo)**. 

1. Nella pagina **Seleziona destinazione**, procedi come segue: 

   1. **Scegli **Tutto APIs**, quindi nella casella di ricerca inserisci ECS.** 

   1. Seleziona **Amazon ECS**.

   1. Nella casella di ricerca, immettete **RunTask**, quindi scegliete **RunTask**.

   1. Per **Cluster ECS**, scegli il cluster.

   1. Per **Attività ECS**, scegli la definizione dell'attività da utilizzare.

   1. Scegliere come vengono distribuite le attività nell'infrastruttura cluster. Espandere le **Opzioni di calcolo**, poi scegliere una delle seguenti opzioni    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonECS/latest/developerguide/tasks-scheduled-eventbridge-scheduler.html)

   1. Per le **sottoreti**, inserite la sottorete IDs in cui eseguire l'operazione.

   1. Per **Gruppi di sicurezza**, immettere il gruppo di sicurezza IDs per la sottorete.

   1. (Facoltativo) Per utilizzare una strategia di posizionamento delle attività diversa da quella predefinita, espandi **Vincolo di posizionamento**, quindi inserisci i vincoli.

       Per ulteriori informazioni, consultare [In che modo Amazon ECS colloca le attività sulle istanze dei container](task-placement.md).

   1. (Facoltativo) Per identificare le attività, configura i tag nella sezione **Tag**.

      Per fare in modo che Amazon ECS assegni automaticamente i tag a tutte le attività appena avviate con i tag di definizione delle attività, seleziona **Abilita tag gestiti da Amazon ECS**.

1. Scegli **Next (Successivo)**. 

1. Nella pagina **Settings (Impostazioni)**, eseguire le operazioni descritte di seguito. 

   1. Per attivare la pianificazione, in **Stato della pianificazione**, attiva **Abilita pianificazione**. 

   1. Per configurare una policy di ripetizione per la tua pianificazione, in **Policy di ripetizione e coda DLQ (Dead-Letter Queue)** effettua le seguenti operazioni:
      + Attiva/disattiva **Riprova**.
      + Per **Tempo massimo di conservazione dell'evento**, inserisci il numero massimo di **ore** e **minuti in** cui EventBridge Scheduler deve conservare un evento non elaborato.
      + La durata massima è 24 ore.
      + Per Numero **massimo di tentativi**, inserisci il numero massimo di volte in cui EventBridge Scheduler riprova la pianificazione se la destinazione restituisce un errore. 

         Il valore massimo è 185 tentativi. 

      Con le politiche di ripetizione dei tentativi, se una pianificazione non riesce a richiamare l'obiettivo, EventBridge Scheduler esegue nuovamente la pianificazione. Se configurato, è necessario impostare il tempo di conservazione massimo e i nuovi tentativi per la pianificazione.

   1. Scegli dove EventBridge Scheduler archivia gli eventi non consegnati.     
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonECS/latest/developerguide/tasks-scheduled-eventbridge-scheduler.html)

   1. Per utilizzare una chiave gestita dal cliente per crittografare l'input di destinazione, in **Crittografia** scegli **Personalizza le impostazioni di crittografia (avanzate)**. 

      Se si sceglie questa opzione, inserire l'ARN di una chiave KMS esistente o scegliere **Crea una AWS KMS key** per accedere alla console AWS KMS . Per ulteriori informazioni su come EventBridge Scheduler crittografa i dati inattivi, consulta [Encryption at rest](https://docs.aws.amazon.com/scheduler/latest/UserGuide/encryption-rest.html) nella *Amazon EventBridge Scheduler* User Guide. 

   1. Per **Autorizzazioni**, scegli **Usa ruolo esistente**, quindi seleziona il ruolo.

      Per fare in modo che EventBridge Scheduler crei un nuovo ruolo di esecuzione per te, scegli **Crea nuovo ruolo** per questa pianificazione. Inserisci, quindi, un nome per **Nome ruolo**. Se scegli questa opzione, EventBridge Scheduler assegna al ruolo le autorizzazioni necessarie per la destinazione basata sul modello. 

1. Scegli **Next (Successivo)**. 

1.  Nella pagina **Rivedi e crea pianificazione**, rivedi i dettagli della pianificazione. In ogni sezione, scegli **Modifica** per tornare a tale passaggio e modificarne i dettagli. 

1. Scegli **Crea pianificazione**. 

   Puoi visualizzare un elenco delle pianificazioni nuove ed esistenti nella pagina **Pianificazioni**. Nella colonna **Stato**, accertati che la nuova pianificazione sia **Abilitata**. 

## Fasi successive
<a name="eventbridge-scheduler-next-steps"></a>

È possibile utilizzare la console EventBridge Scheduler o gestire la pianificazione. AWS CLI Per ulteriori informazioni, consulta [Managing a planning](https://docs.aws.amazon.com/scheduler/latest/UserGuide/managing-schedule.html) nella *Amazon EventBridge Scheduler User Guide*.

# Interruzione di un'attività di Amazon ECS
<a name="standalone-task-stop"></a>

Se non è più necessario mantenere in esecuzione un'attività autonoma, è possibile interrompere l'attività. La console Amazon ECS semplifica l'interruzione di una o più attività.

Non è possibile riavviare un'attività autonoma interrotta.

Se si desidera interrompere un servizio, consultare [Eliminazione di un servizio Amazon ECS utilizzando la console](delete-service-v2.md).

**Per interrompere un'attività autonoma (Console di gestione AWS)**

1. [Apri la console nella versione 2https://console.aws.amazon.com/ecs/.](https://console.aws.amazon.com/ecs/v2)

1. Nel pannello di navigazione scegliere **Cluster**.

1. Nella pagina **Cluster**, scegliere il cluster per accedere alla pagina dei dettagli del cluster.

1. Nella pagina dei dettagli del cluster, scegliere la scheda **Attività**. 

1. È possibile filtrare le attività per tipo di avvio utilizzando l'elenco **Filtra tipo di avvio**.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonECS/latest/developerguide/standalone-task-stop.html)

# Servizi Amazon ECS
<a name="ecs_services"></a>

Puoi utilizzare un servizio Amazon ECS per eseguire e mantenere simultaneamente un determinato numero di istanze di una definizione di attività in un cluster Amazon ECS. Se una delle tue attività non riesce o si interrompe, il pianificatore del servizio Amazon ECS avvia un'altra istanza della definizione di attività per sostituirla. Ciò consente di mantenere il numero desiderato di attività nel servizio.

A scelta, puoi eseguire il tuo servizio con un load balancer. Il load balancer distribuisce il traffico nelle attività associate al servizio.

Ti consigliamo di utilizzare il pianificatore di servizi per le applicazioni e i servizi stateless di lunga durata. Il pianificatore di servizi garantisce che venga seguita la strategia di pianificazione specificata e ripianifica i processi qualora un processo dia esito negativo. Ad esempio, se l'infrastruttura sottostante riporta un errore, il pianificatore del servizio può riprogrammare un'attività. Puoi applicare vincoli e strategie di posizionamento delle attività per personalizzare il modo in cui il pianificatore posiziona e termina le attività. Se un processo in un servizio viene arresto, il pianificatore avvia un nuovo processo per sostituirlo. Questo processo continua finché il servizio non raggiunge il numero di attività desiderato in base alla strategia di pianificazione utilizzata dal servizio.

Il pianificatore di servizi sostituisce inoltre le attività ritenute non integre dopo l'esito negativo di un controllo dell'integrità del container o di un gruppo di destinazione di un bilanciatore del carico. Questa sostituzione dipende dai parametri di definizione del servizio `maximumPercent` e `desiredCount`. Se un'attività è contrassegnata come non integra, il pianificatore di servizi avvierà innanzitutto un'attività di sostituzione. Poi, si verificano le seguenti situazioni.
+ Se lo stato di integrità dell'attività di sostituzione è `HEALTHY`, il pianificatore di servizi interrompe l'attività non integra
+ Se lo stato di integrità dell'attività di sostituzione è `UNHEALTHY`, il pianificatore interromperà l'attività di sostituzione non integra o l'attività esistente non integra per far sì che il numero totale delle attività sia pari a `desiredCount`.

Se il parametro `maximumPercent` impedisce al pianificatore di avviare un'attività di sostituzione, il pianificatore interromperà un'attività non integra alla volta, in modo casuale, per liberare spazio, e poi avvierà un'attività di sostituzione. Il processo di avvio e arresto continua fino a quando tutte le attività non integre vengono sostituite con attività integre. Dopo aver sostituito tutte le attività non integre e aver avviato solo quelle integre, se il numero totale delle attività supera `desiredCount`, le attività integre vengono interrotte casualmente fino a quando il numero totale delle attività è pari a `desiredCount`. Per ulteriori informazioni sui parametri `maximumPercent` e `desiredCount`, consulta [Parametri di definizione del servizio](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service_definition_parameters.html).

Il pianificatore del servizio include una logica che limita la frequenza dei tentativi di riavvio delle attività se queste non riescono a riavviarsi ripetutamente. Se un'attività si interrompe senza essere entrata in uno stato `RUNNING`, il pianificatore del servizio inizia a rallentare in modo incrementale i tentativi di avvio ed emette un messaggio di evento del servizio. Questo comportamento previene l'utilizzo di risorse non necessarie per le attività non riuscite prima che sia risolto il problema. Dopo l'aggiornamento del servizio, il pianificatore del servizio riprende il normale comportamento. Per ulteriori informazioni, consultare [Logica di limitazione del servizio Amazon ECS](service-throttle-logic.md) e [Visualizzare i messaggi relativi agli eventi del servizio Amazon ECS](service-event-messages.md).

## Opzione di calcolo dell'infrastruttura
<a name="service-conmpute-options"></a>

Esistono due opzioni di calcolo che distribuiscono le attività.
+ Una strategia per provider di capacità fa sì che Amazon ECS distribuisca le attività in uno o più provider di capacità. 

  Se si desidera eseguire i carichi di lavoro su istanze gestite da Amazon ECS, è necessario utilizzare l'opzione di strategia del provider di capacità.

  Per la **strategia per provider di capacità**, la console seleziona un'opzione di calcolo di default. Di seguito viene descritto l'ordine utilizzato dalla console per selezionare un valore di default:
  + Se il cluster dispone di una strategia di provider di capacità definita, questa è selezionata.
  + Se nel cluster non è presente una strategia di provider di capacità di default definita, ma sono presenti i provider di capacità di Fargate aggiunti al cluster, è selezionata una strategia di provider di capacità personalizzata che utilizza il provider di capacità `FARGATE`.
  + Se nel cluster non è presente una strategia di provider di capacità di default definita, ma sono presenti uno o più provider di capacità del gruppo Auto Scaling aggiunti al cluster, l'opzione **Usa personalizzato (avanzate)** è selezionata e sarà necessario definire manualmente la strategia.
  + Se nel cluster non è presente una strategia di provider di capacità di default definita e non sono stati aggiunti provider di capacità al cluster, è selezionato il tipo di avvio Fargate.
+ Un tipo di avvio fa sì che Amazon ECS avvii le attività direttamente su Fargate o sulle istanze EC2 registrate nei cluster.

  Se si desidera eseguire i carichi di lavoro su istanze gestite da Amazon ECS, occorre utilizzare l'opzione di strategia del provider di capacità.

  Per impostazione predefinita, il servizio viene avviato nelle sottoreti del cluster VPC.

## Scalabilità automatica del servizio
<a name="service-auto-scaling-options"></a>

Il dimensionamento automatico dei servizi è la capacità di aumentare o diminuire automaticamente il numero desiderato di processi nel servizio Amazon ECS. Amazon ECS utilizza il servizio di Application Auto Scaling per fornire questa funzionalità.

Per ulteriori informazioni, consultare [Scalabilità automatica del servizio Amazon ECS](service-auto-scaling.md).

## Bilanciamento del carico nel servizio
<a name="service-load-balancing-options"></a>

I servizi Amazon ECS ospitati su AWS Fargate supportano Application Load Balancer, Network Load Balancer e Gateway Load Balancer. Utilizzare la tabella seguente per ottenere maggiori informazioni sul tipo bilanciatore del carico da utilizzare.


| Tipo di bilanciatore del carico | Utilizzare in questi casi | 
| --- | --- | 
|  Application Load Balancer  | Traffico di routing HTTP/HTTPS (o livello 7).Gli Application Load Balancer offrono diverse funzionalità che li rendono particolarmente appropriati per l'uso con i servizi Amazon ECS: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonECS/latest/developerguide/ecs_services.html) | 
| Network Load Balancer | Instradare il traffico TCP o UDP (o livello 4). | 
| Gateway Load Balancer | Instradare il traffico TCP o UDP (o livello 4). Usare le appliance virtuali, come firewall, sistemi di prevenzione e rilevamento delle intrusioni, e sistemi di ispezione approfondita dei pacchetti. | 

Per ulteriori informazioni, consultare [Usa il bilanciamento del carico per distribuire il traffico del servizio Amazon ECS](service-load-balancing.md).

## Servizi di interconnessione
<a name="service-connecting-options"></a>

Se è necessaria un'applicazione per connettersi ad altre applicazioni eseguite nei servizi Amazon ECS, Amazon ECS offre i modi seguenti per farlo senza un bilanciatore del carico:
+ Service Connect: consente service-to-service comunicazioni con rilevamento automatico utilizzando nomi brevi e porte standard.
+ Rilevamento servizi: il rilevamento servizi utilizza Route 53 per creare un namespace per il servizio, che ne consente il rilevamento tramite DNS.
+ Amazon VPC Lattice - VPC Lattice è un servizio di rete di applicazioni completamente gestito per connettere, proteggere e monitorare i tuoi servizi su più account e. VPCs È previsto un costo associato al suo utilizzo.

Per ulteriori informazioni, consultare [Interconnessione dei servizi Amazon ECS](interconnecting-services.md).

# Controller e strategie di implementazione dei servizi Amazon ECS
<a name="ecs_service-options"></a>

Prima di implementare il servizio, stabilire le opzioni per l'implementazione e le funzionalità utilizzate dal servizio.

## Strategia di pianificazione
<a name="service-strategy"></a>

Sono disponibili due strategie del pianificatore del servizio:
+ `REPLICA`: la strategia di pianificazione delle repliche colloca e gestisce il numero desiderato di attività nel cluster. Di default, il pianificatore del servizio distribuisce le attività tra le zone di disponibilità. Puoi utilizzare vincoli e strategie di posizionamento delle attività per personalizzare le decisione riguardo al posizionamento delle attività. Per ulteriori informazioni, consultare [Strategia di pianificazione delle repliche](#service_scheduler_replica).
+ `DAEMON`: la strategia di pianificazione del daemon distribuisce esattamente un'attività in ciascuna istanza di container attiva, che soddisfa tutti i vincoli di posizionamento delle attività specificati nel cluster. Quando si utilizza questa strategia, non è necessario specificare un numero di attività desiderato o una strategia di posizionamento delle attività, né utilizzare le policy di Auto Scaling del servizio. Per ulteriori informazioni, consultare [Strategia di pianificazione dei daemon](#service_scheduler_daemon).
**Nota**  
I processi Fargate non supportano la strategia di pianificazione `DAEMON`

### Strategia di pianificazione delle repliche
<a name="service_scheduler_replica"></a>

La strategia di pianificazione delle *repliche* posiziona e gestisce il numero desiderato di attività nel cluster.

Per un servizio che esegue attività su Fargate, quando il pianificatore di servizi avvia nuove attività o arresta quelle in esecuzione, il pianificatore fa del suo meglio per mantenere il bilanciamento tra le zone di disponibilità. Non è necessario specificare strategie di posizionamento delle attività o vincoli.

Quando crei un servizio che esegue le attività su istanze EC2, puoi specificare facoltativamente le strategie e i vincoli di posizionamento delle attività per personalizzare le decisioni relative al posizionamento delle attività. Se non vengono specificati vincoli o strategie di posizionamento delle attività, per impostazione predefinita il pianificatore del servizio distribuisce le attività tra le zone di disponibilità. Il pianificatore di servizi utilizza la logica seguente:
+ Determina quale delle istanze di container nel cluster può supportare la definizione di attività del servizio (in termini, ad esempio, di CPU, memoria, porte e attributi dell'istanza di container necessari).
+ Determina quali istanze di container soddisfano gli eventuali vincoli di posizionamento definiti per il servizio.
+ Se disponi di un servizio di replica che dipende da un servizio daemon (ad esempio, un'attività del router dei log del daemon da eseguire prima della registrazione delle attività), crea un vincolo di posizionamento delle attività che assicuri che le attività del servizio daemon vengano posizionate sull'istanza EC2 prima delle attività del servizio di replica. Per ulteriori informazioni, consultare [Vincoli di posizionamento di esempio delle attività di Amazon ECS](constraint-examples.md).
+ Se hai definito una strategia di posizionamento, utilizzala per selezionare un'istanza tra le candidate rimanenti.
+ Se non è stata definita una strategia di posizionamento, bilancia le attività tra le zone di disponibilità nel cluster con la logica seguente:
  + Ordina le istanze di container valide. Dai priorità alle istanze che hanno il minor numero di attività in esecuzione per questo servizio nella rispettiva zona di disponibilità. Ad esempio, se nella zona A è presente un'attività del servizio in esecuzione e nelle zone B e C nessuna, le istanze di container valide nella zona B o C sono considerate ottimali per il posizionamento.
  + Posiziona la nuova attività del servizio in un'istanza di container valida in una zona di disponibilità ottimale in base alle fasi precedenti. Dai la priorità alle istanze di container con il minor numero di attività in esecuzione per questo servizio.

Si consiglia di utilizzare la funzionalità di ribilanciamento del servizio quando si utilizza la strategia `REPLICA` perché contribuisce a garantire un'elevata disponibilità del servizio.

### Strategia di pianificazione dei daemon
<a name="service_scheduler_daemon"></a>

La strategia di pianificazione *daemon* distribuisce esattamente un'attività in ciascuna istanza di container attiva che soddisfa tutti i vincoli di posizionamento delle attività specificati nel cluster. Il pianificatore del servizio valuta i vincoli di posizionamento delle attività per le attività in esecuzione e interrompe quelle che non rispondono a tali vincoli. Con questa strategia, non è necessario specificare un numero di attività desiderato o una strategia di posizionamento delle attività, né utilizzare le policy di Service Auto Scaling.

Amazon ECS riserva risorse di calcolo dell'istanza di container tra cui CPU, memoria e interfacce di rete per i processi del daemon. Quando avvii un servizio daemon in un cluster con altri servizi di replica, Amazon ECS assegna la priorità all'attività del daemon. Questo significa che l'attività del daemon è la prima da avviare sulle istanze e l'ultima da interrompere dopo aver interrotto tutte le attività delle repliche. La strategia garantisce che le risorse non vengano utilizzate da attività di replica in sospeso e che siano disponibili per le attività del daemon.

Il pianificatore del servizio del daemon non posiziona alcuna attività sulle istanze con stato `DRAINING`. Se un'istanza di container passa a uno stato `DRAINING`, le attività daemon in esecuzione su di essa vengono arrestate. Il pianificatore del servizio inoltre monitora l'aggiunta di nuove istanze di container al cluster, alle quali aggiunge le attività daemon.

Quando si specifica una configurazione di implementazione, il valore del parametro `maximumPercent` deve essere `100` (specificato in percentuale), che è il valore predefinito utilizzato se non è impostato. Il valore predefinito per il parametro `minimumHealthyPercent` è `0` (specificato come percentuale).

Quando modifichi i vincoli di posizionamento per il servizio daemon devi riavviare il servizio. Amazon ECS aggiorna dinamicamente le risorse riservate sulle istanze idonee per l'attività del daemon. Per le istanze esistenti, il pianificatore prova a posizionare l'attività sull'istanza. 

Una modifica della dimensione del processo o della prenotazione della risorsa del container nella definizione di attività avvia una nuova implementazione. Una nuova implementazione inizia anche quando si aggiorna un servizio o si imposta una revisione diversa della definizione dell'attività. Amazon ECS raccoglie la CPU e le prenotazioni di memoria aggiornate per il daemon e quindi blocca tale capacità per il processo del daemon.

Se ci sono risorse insufficienti per uno dei casi precedenti, si verifica quanto segue:
+ Il posizionamento del processo ha esito negativo.
+ Viene generato un evento CloudWatch .
+ Amazon ECS continua a provare a pianificare il processo sull'istanza attendendo che le risorse diventino disponibili. 
+ Amazon ECS libera tutte le istanze riservate che non soddisfano più i criteri di vincolo di posizionamento e interrompe i processi del daemon corrispondenti.

La strategia di pianificazione del daemon può essere utilizzata nei seguenti casi:
+ Esecuzione di container di applicazioni
+ Esecuzione di container di supporto per processi di registrazione, monitoraggio e traccia

Le attività che utilizzano Fargate oppure i tipi di controller di implementazione `CODE_DEPLOY` o `EXTERNAL` non supportano la strategia di pianificazione del daemon.

Quando il pianificatore di servizi arresta i processi in esecuzione, prova a mantenere il bilanciamento tra le zone di disponibilità nel cluster. Il pianificatore utilizza la logica seguente: 
+ Se è stata definita una strategia di posizionamento, utilizzare tale strategia per selezionare le attività da terminare. Ad esempio, se per un servizio è definita una strategia di distribuzione tra zone di disponibilità, viene selezionata un'attività che lascia le attività rimanenti con la migliore distribuzione.
+ Se non è stata definita una strategia di posizionamento, mantieni il bilanciamento tra le zone di disponibilità nel cluster con la logica seguente:
  + Ordina le istanze di container valide. Dai priorità alle istanze che hanno il maggior numero di attività in esecuzione per questo servizio nella rispettiva zona di disponibilità. Ad esempio, se nella zona A è presente un'attività del servizio in esecuzione e nelle zone B e C ne sono presenti due, le istanze di container nella zona B o C sono considerate ottimali per l'arresto.
  + Arresta l'attività del servizio in un'istanza di container in una zona di disponibilità ottimale in base alle fasi precedenti. Dai la priorità alle istanze di container con il maggior numero di attività in esecuzione per questo servizio.

## Controller di implementazione
<a name="service_deployment-controllers"></a>

Il controller di implementazione è il meccanismo che determina il modo in cui le attività vengono implementate per il servizio. Le opzioni valide sono:
+ ECS

  Quando si crea un servizio che utilizza il controller di implementazione `ECS`, è possibile scegliere tra le seguenti strategie di implementazione:
  + `ROLLING`: quando si crea un servizio che utilizza la strategia di implementazione con *aggiornamento in sequenza* (`ROLLING`), il pianificatore del servizio Amazon ECS sostituisce le attività correntemente in esecuzione con le nuove. Il numero di attività che Amazon ECS aggiunge o rimuove dal servizio durante un aggiornamento continuo è controllato dalla configurazione di distribuzione del servizio. 

    Le distribuzioni di aggiornamento continuo sono più adatte per i seguenti scenari:
    + Aggiornamenti graduali ai servizi: è necessario aggiornare il servizio in modo incrementale senza mettere offline l'intero servizio contemporaneamente.
    + Requisiti di risorse limitati: è necessario evitare i costi aggiuntivi in termini di risorse derivanti dall'esecuzione simultanea di due ambienti completi (come richiesto dalle implementazioni blu/verdi).
    + Tempo di implementazione accettabile: l'applicazione può tollerare un processo di implementazione più lungo, poiché gli aggiornamenti continui sostituiscono le attività una per una.
    + Rollback istantaneo non necessario: il servizio può tollerare un processo di rollback che richiede minuti anziché secondi.
    + Processo di implementazione semplice: si preferisce un approccio di implementazione semplice senza la complessità della gestione di più ambienti, gruppi di destinazione e listener.
    + Nessun requisito di bilanciamento del carico: il servizio non utilizza né richiede un load balancer, Application Load Balancer, Network Load Balancer o Service Connect (necessari per le implementazioni). blue/green 
    + Applicazioni stateful: l'applicazione mantiene uno stato che rende difficile l'esecuzione di due ambienti paralleli.
    + Attenzione ai costi: si desidera ridurre al minimo i costi di implementazione evitando l'esecuzione di ambienti duplicati durante l'implementazione.

    Gli aggiornamenti continui sono la strategia di implementazione predefinita per i servizi e forniscono un equilibrio tra sicurezza dell'implementazione ed efficienza delle risorse per molti scenari applicativi comuni.
  + `BLUE_GREEN`: una strategia di implementazione *blu/verde* (`BLUE_GREEN`) è una metodologia di rilascio che riduce i tempi di inattività e i rischi eseguendo due ambienti di produzione identici denominati blu e verde. Con le blue/green implementazioni di Amazon ECS, puoi convalidare nuove revisioni dei servizi prima di indirizzare il traffico di produzione verso di esse. Questo approccio offre un modo più sicuro per implementare le modifiche con la possibilità di ripristinarle rapidamente, se necessario.

    Le blue/green implementazioni di Amazon ECS sono più adatte per i seguenti scenari:
    + Convalida dei servizi: quando è necessario convalidare le nuove revisioni del servizio prima di indirizzare il traffico di produzione verso di esse
    + Azzeramento del tempo di inattività: quando il servizio richiede implementazioni senza tempi di inattività
    + Rollback istantaneo: quando è necessaria la possibilità di eseguire rapidamente il rollback se vengono rilevati problemi
    + Requisito di bilanciatore del carico: quando il servizio utilizza Application Load Balancer, Network Load Balancer o Service Connect
  + `LINEAR`: Una strategia di implementazione *lineare* (`LINEAR`) sposta gradualmente il traffico dall'ambiente di produzione corrente a un nuovo ambiente con incrementi percentuali uguali in un periodo di tempo specificato. Con le implementazioni lineari di Amazon ECS, puoi controllare il ritmo dello spostamento del traffico e convalidare nuove revisioni dei servizi con quantità crescenti di traffico di produzione.

    Le implementazioni lineari di Amazon ECS sono più adatte per i seguenti scenari:
    + Convalida graduale: quando desideri convalidare gradualmente la tua nuova versione del servizio con l'aumento del traffico
    + Monitoraggio delle prestazioni: quando hai bisogno di tempo per monitorare metriche e prestazioni durante l'implementazione
    + Riduzione al minimo del rischio: quando si desidera ridurre al minimo il rischio esponendo la nuova versione al traffico di produzione in modo incrementale
    + Requisito di bilanciatore del carico: quando il servizio utilizza Application Load Balancer, Network Load Balancer o Service Connect
  + `CANARY`: Una strategia di implementazione di *Canary* (`CANARY`) sposta prima una piccola percentuale di traffico verso la nuova revisione del servizio, quindi sposta il traffico rimanente tutto in una volta dopo un periodo di tempo specificato. Ciò consente di testare la nuova versione con un sottoinsieme di utenti prima della distribuzione completa.

    Le implementazioni di Amazon ECS Canary sono più adatte per i seguenti scenari:
    + Test delle funzionalità: quando desideri testare nuove funzionalità con un piccolo sottoinsieme di utenti prima dell'implementazione completa
    + Convalida della produzione: quando è necessario convalidare prestazioni e funzionalità con un traffico di produzione reale
    + Controllo del raggio di esplosione: quando si desidera ridurre al minimo il raggio di esplosione se vengono rilevati problemi nella nuova versione
    + Requisito di bilanciatore del carico: quando il servizio utilizza Application Load Balancer, Network Load Balancer o Service Connect
+ Esterno

  Utilizzare un controller di implementazione di terza parte.
+ Implementazione blu/verde (fornita da) AWS CodeDeploy

  CodeDeploy installa una versione aggiornata dell'applicazione come nuovo set di attività sostitutivo e reindirizza il traffico di produzione dal set di attività dell'applicazione originale al set di attività sostitutivo. Il set di attività originale viene terminato una volta completata l'implementazione. Usare questo controller di implementazione per verificare una nuova implementazione di un servizio prima che questo riceva traffico di produzione.

# Rilevamento degli errori di implementazione di Amazon ECS
<a name="deployment-failure-detection"></a>

Amazon ECS offre due metodi per rilevare gli errori di implementazione:
+ Interruttore automatico di implementazione
+ CloudWatch Allarmi

Entrambi i metodi possono essere configurati per ripristinare automaticamente le implementazioni non riuscite all'ultimo stato valido conosciuto.

Considera i seguenti aspetti:
+ Entrambi i metodi supportano solo i tipi di distribuzione e blue/green distribuzione degli aggiornamenti in sequenza.
+ Quando vengono utilizzati entrambi i metodi, entrambi possono causare un errore di implementazione.
+ Il metodo rollback richiede un'implementazione precedente nello stato COMPLETED.
+ EventBridge gli eventi vengono generati per le modifiche dello stato di distribuzione.

# In che modo l’interruttore di implementazione Amazon ECS rileva i guasti
<a name="deployment-circuit-breaker"></a>

L'interruttore di implementazione è il meccanismo di aggiornamento in sequenza che determina se le attività raggiungono uno stato stazionario. L'interruttore di implementazione dispone di un'opzione che consente di eseguire automaticamente il rollback di un'implementazione con esito negativo a un'implementazione nello stato `COMPLETED`.

Quando la distribuzione di un servizio cambia stato, Amazon ECS invia un evento di modifica dello stato di distribuzione del servizio a EventBridge. Ciò fornisce un modo programmatico per monitorare lo stato delle implementazioni dei servizi. Per ulteriori informazioni, consulta [Eventi di modifica dello stato di implementazione del servizio Amazon ECS](ecs_service_deployment_events.md). Ti consigliamo di creare e monitorare una EventBridge regola con un `eventName` of `SERVICE_DEPLOYMENT_FAILED` in modo da poter intraprendere azioni manuali per avviare la distribuzione. Per ulteriori informazioni, consulta la sezione Guida [introduttiva EventBridge alla](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-get-started.html) *Amazon EventBridge User Guide*.

Quando l'interruttore di implementazione determina il fallimento di un'implementazione, cerca quella più recente con lo stato `COMPLETED`. Si tratta dell'implementazione che viene utilizzata come implementazione di rollback. Quando inizia il rollback, l'implementazione cambia da `COMPLETED` a `IN_PROGRESS`. Ciò significa che l'implementazione non è idonea per un altro rollback fino a quando non raggiunge uno stato `COMPLETED`. Quando l'interruttore di implementazione non rileva un'implementazione nello stato `COMPLETED`, non avvia nuove attività e l'implementazione si blocca. 

Quando si crea un servizio, il pianificatore tiene traccia delle attività che non sono state avviate in due fasi.
+ Fase 1: il pianificatore monitora le attività per vedere se passano allo stato RUNNING.
  + Operazione riuscita: l'implementazione ha la possibilità di passare allo stato COMPLETED perché più di un'attività è passata allo stato RUNNING. Il criterio di errore viene ignorato e l'interruttore passa alla fase 2.
  + Errore: alcune attività consecutive non sono passate allo stato RUNNING e l'implementazione potrebbe passare allo stato FAILED. 
+ Fase 2: l'implementazione entra in questa fase quando è presente almeno un'attività nello stato RUNNING. L'interruttore automatico verifica i controlli dello stato delle attività nell'implementazione attuale in fase di valutazione. I controlli di integrità convalidati sono Elastic Load Balancing AWS Cloud Map , controlli dello stato del servizio e controlli dello stato dei container. 
  + Operazione riuscita: almeno un'attività è in corso e i controlli dell'integrità sono stati superati.
  + Operazione non riuscita: le attività sostituite a causa di errori nei controlli dell'integrità hanno raggiunto la soglia di errore.

Considerate quanto segue quando utilizzate il metodo dell'interruttore automatico di distribuzione su un servizio. EventBridge genera la regola.
+ La risposta `DescribeServices` fornisce informazioni sullo stato di un'implementazione, `rolloutState` e `rolloutStateReason`. Quando viene avviata una nuova implementazione, lo stato di implementazione inizia in `IN_PROGRESS`. Quando il servizio raggiunge uno stato stazionario, lo stato di implementazione passa a `COMPLETED`. Se il servizio non riesce a raggiungere uno stato stazionario e l'interruttore automatico è abilitato, l'implementazione passerà a uno stato `FAILED`. Una implementazione in uno stato `FAILED` non avvierà nuove attività.
+ Oltre agli eventi di modifica dello stato dell'implementazione del servizio che Amazon ECS invia per le implementazioni che sono state avviate e completate, Amazon ECS invia anche un evento quando un'implementazione con l'interruttore automatico attivato non riesce. Questi eventi forniscono dettagli sul motivo per cui un'implementazione non è riuscita o se un'implementazione è stata avviata a causa di un ripristino dello stato precedente. Per ulteriori informazioni, consultare [Eventi di modifica dello stato di implementazione del servizio Amazon ECS](ecs_service_deployment_events.md).
+ Se viene avviata una nuova implementazione perché un'implementazione precedente non è riuscita e si è verificato il ripristino dello stato precedente, il campo `reason` dell'evento di modifica dello stato di implementazione del servizio indicherà che l'implementazione è stata avviata a causa di un ripristino dello stato precedente.
+ L'interruttore automatico di implementazione è supportato solo per i servizi Amazon ECS che utilizzano il controller di implementazione (`ECS`) dell'aggiornamento in sequenza.
+ È necessario utilizzare la console Amazon ECS o, AWS CLI quando si utilizza, l'interruttore automatico di distribuzione con l' CloudWatch opzione. Per ulteriori informazioni, consultare [Creazione di un servizio utilizzando parametri definiti](create-service-console-v2.md#create-custom-service) e [create-service](https://docs.aws.amazon.com/cli/latest/reference/ecs/create-service.html) in *Informazioni di riferimento sull'AWS Command Line Interface *.

L'`create-service` AWS CLI esempio seguente mostra come creare un servizio Linux quando l'interruttore di distribuzione viene utilizzato con l'opzione rollback.

```
aws ecs create-service \
     --service-name MyService \
     --deployment-controller type=ECS \
     --desired-count 3 \
     --deployment-configuration "deploymentCircuitBreaker={enable=true,rollback=true}" \
     --task-definition sample-fargate:1 \
     --launch-type FARGATE \
     --platform-family LINUX \
     --platform-version 1.4.0 \
     --network-configuration "awsvpcConfiguration={subnets=[subnet-12344321],securityGroups=[sg-12344321],assignPublicIp=ENABLED}"
```

Esempio:

L'implementazione 1 è in uno stato `COMPLETED`.

L'implementazione 2 non può essere avviata, quindi l'interruttore esegue il rollback all'implementazione 1. L'implementazione 1 passa allo stato `IN_PROGRESS`.

L'implementazione 3 viene avviata e non è presente alcuna implementazione nello stato `COMPLETED`, quindi l'implementazione non è in grado di eseguire il rollback o avviare attività. 

## Soglia di errore
<a name="failure-threshold"></a>

L'interruttore automatico di implementazione calcola il valore di soglia e quindi lo utilizza per determinare quando modificare lo stato dell'implementazione in `FAILED`.

L'interruttore automatico di distribuzione ha una soglia minima di 3 e una soglia massima di 200 e utilizza i valori della formula seguente per determinare l'errore di distribuzione.

```
Minimum threshold <= 0.5 * desired task count => maximum threshold
```

Quando il risultato del calcolo è superiore al minimo di 3, ma inferiore al massimo di 200, la soglia di errore viene impostata sulla soglia calcolata (arrotondata per eccesso).

**Nota**  
Non è possibile modificare nessuno dei valori di soglia.

Esistono due fasi per il controllo dello stato dell'implementazione.

1. L'interruttore automatico di implementazione monitora i processi che fanno parte dell'implementazione e verifica la presenza di attività con stato `RUNNING`. Il pianificatore ignora i criteri di errore quando un processo nell'implementazione corrente si trova nello stato `RUNNING` e procede alla fase successiva. Quando i processi non riescono a raggiungere lo stato `RUNNING`, l'interruttore automatico di implementazione aumenta di uno il numero di errori. Quando il numero di errori è uguale alla soglia, l'implementazione viene contrassegnata come `FAILED`.

1. Questa fase viene inserita in presenza di uno o più processi nello stato `RUNNING`. L'interruttore automatico di implementazione esegue controlli dell'integrità delle seguenti risorse per i processi nell'implementazione corrente:
   + Load balancer Elastic Load Balancing
   + AWS Cloud Map servizio
   + Controlli dell'integrità dei container di Amazon ECS

   Quando un controllo dell'integrità di un processo HA ESITO NEGATIVO, l'interruttore automatico di implementazione aumenta di uno il numero di errori. Quando il numero di errori è uguale alla soglia, l'implementazione viene contrassegnata come `FAILED`.

La tabella seguente mostra alcuni esempi.


| Conteggio attività desiderato | Calcolo | Threshold | 
| --- | --- | --- | 
|  1  |  <pre>3 <= 0.5 * 1 => 200</pre>  | 3 (il valore calcolato è inferiore al minimo) | 
|  25  |  <pre>3 <= 0.5 * 25 => 200</pre>  | 13 (il valore viene arrotondato per eccesso) | 
|  400  |  <pre>3 <= 0.5 * 400 => 200</pre>  | 200 | 
|  800  |  <pre>3 <= 0.5 * 800 => 200</pre>  | 200 (il valore calcolato è superiore al massimo) | 

Ad esempio, quando la soglia è 3, l'interruttore si avvia con il numero di errori impostato su 0. Quando un'attività non riesce a raggiungere lo stato `RUNNING`, l'interruttore automatico di implementazione aumenta di uno il numero di errori. Quando il numero di errori è uguale a 3, l'implementazione viene contrassegnata come `FAILED`.

Per altri esempi sull'utilizzo dell'opzione di rollback, consulta [Annuncio dell'interruttore automatico di implementazione di Amazon ECS](https://aws.amazon.com/blogs/containers/announcing-amazon-ecs-deployment-circuit-breaker/).

# In che modo CloudWatch gli allarmi rilevano gli errori di distribuzione di Amazon ECS
<a name="deployment-alarm-failure"></a>

Puoi configurare Amazon ECS in modo che la distribuzione non sia riuscita quando rileva che uno specifico CloudWatch allarme è entrato nello `ALARM` stato.

Facoltativamente, è possibile impostare la configurazione per ripristinare un'implementazione non riuscita all'ultima implementazione completata.

L'`create-service` AWS CLI esempio seguente mostra come creare un servizio Linux quando gli allarmi di distribuzione vengono utilizzati con l'opzione rollback.

```
aws ecs create-service \
     --service-name MyService \
     --deployment-controller type=ECS \
     --desired-count 3 \
     --deployment-configuration "alarms={alarmNames=[alarm1Name,alarm2Name],enable=true,rollback=true}" \
     --task-definition sample-fargate:1 \
     --launch-type FARGATE \
     --platform-family LINUX \
     --platform-version 1.4.0 \
     --network-configuration "awsvpcConfiguration={subnets=[subnet-12344321],securityGroups=[sg-12344321],assignPublicIp=ENABLED}"
```

Considera quanto segue quando utilizzi il metodo Amazon CloudWatch alarms su un servizio.
+ La durata in cui le revisioni del servizio blu e verde vengono eseguite contemporaneamente dopo lo spostamento del traffico di produzione. Amazon ECS calcola questo periodo di tempo in base alla configurazione degli allarmi associata all'implementazione. Non è possibile impostare questo valore. 
+ Il parametro della richiesta `deploymentConfiguration` ora contiene il tipo di dati `alarms`. È possibile specificare i nomi degli allarmi, se utilizzare il metodo e se avviare un rollback quando gli allarmi indicano un errore di implementazione. Per ulteriori informazioni, consulta il *riferimento [CreateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateService.html)all'API di Amazon Elastic Container Service*.
+ La risposta `DescribeServices` fornisce informazioni sullo stato di un'implementazione, `rolloutState` e `rolloutStateReason`. Quando viene avviata una nuova implementazione, lo stato di rollout inizia come `IN_PROGRESS`. Quando il servizio raggiunge uno stato stazionario ed è stato raggiunto il tempo di incorporamento, lo stato di rollout passa a `COMPLETED`. Se il servizio non riesce a raggiungere uno stato stazionario e l'allarme è passato allo stato `ALARM`, l'implementazione passerà a uno stato `FAILED`. Una implementazione in uno stato `FAILED` non avvierà nuovi processi.
+ Oltre agli eventi di modifica dello stato dell'implementazione del servizio che Amazon ECS invia per le implementazioni che sono state avviate e completate, Amazon ECS invia un evento anche quando un'implementazione che utilizza gli allarmi non riesce. Questi eventi forniscono dettagli sul motivo per cui un'implementazione non è riuscita o se un'implementazione è stata avviata a causa di un ripristino dello stato precedente. Per ulteriori informazioni, consultare [Eventi di modifica dello stato di implementazione del servizio Amazon ECS](ecs_service_deployment_events.md).
+ Se una nuova implementazione viene avviata perché un'implementazione precedente non è riuscita ed è stato abilitato il ripristino dello stato precedente, il campo `reason` dell'evento di modifica dello stato di implementazione del servizio indicherà che l'implementazione è stata avviata a causa di un ripristino dello stato precedente.
+ Se utilizzi l'interruttore di distribuzione e gli CloudWatch allarmi Amazon per rilevare i guasti, entrambi possono avviare un errore di distribuzione non appena vengono soddisfatti i criteri per entrambi i metodi. Un rollback si verifica quando si utilizza l'opzione di rollback per il metodo che ha restituito l'errore di implementazione.
+ Gli CloudWatch allarmi Amazon sono supportati solo per i servizi Amazon ECS che utilizzano il controller di distribuzione rolling update (`ECS`).
+ È possibile configurare questa opzione utilizzando la console di Amazon ECS o la AWS CLI. Per ulteriori informazioni, consultare [Creazione di un servizio utilizzando parametri definiti](create-service-console-v2.md#create-custom-service) e [create-service](https://docs.aws.amazon.com/cli/latest/reference/ecs/create-service.html) in *Informazioni di riferimento sull'AWS Command Line Interface *.
+ Potresti notare che lo stato di implementazione rimane `IN_PROGRESS` per un periodo di tempo prolungato. Questo perché Amazon ECS non modifica lo stato finché non ha eliminato l'implementazione attiva e ciò avviene solo dopo il tempo di incorporamento. A seconda della configurazione degli allarmi, l'implementazione potrebbe richiedere diversi minuti in più rispetto a quando non sono utilizzati gli allarmi (anche se il nuovo set di attività principali è stato aumentato e la vecchia implementazione è stata ridotta). Se utilizzi i CloudFormation timeout, valuta la possibilità di aumentarli. Per ulteriori informazioni, consultare [Creating wait conditions in a template](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-waitcondition.html) nella *Guida per l'utente di AWS CloudFormation *.
+ Amazon ECS chiama `DescribeAlarms` per eseguire il polling degli allarmi. Le chiamate verranno `DescribeAlarms` conteggiate ai fini delle quote di CloudWatch servizio associate al tuo account. Se disponi di altri AWS servizi che effettuano chiamate`DescribeAlarms`, Amazon ECS potrebbe avere un impatto sulla necessità di interrogare gli allarmi. Ad esempio, se un altro servizio effettua un numero sufficiente di chiamate a `DescribeAlarms` per raggiungere la quota, tale servizio viene limitato e Amazon ECS non sarà in grado di eseguire il polling degli allarmi. Se viene generato un allarme durante il periodo di limitazione, Amazon ECS potrebbe non rilevare l'allarme e il rollback potrebbe non verificarsi. Non ci sono altri impatti sull'implementazione. *Per ulteriori informazioni sulle quote di CloudWatch servizio, consulta le quote di [CloudWatch servizio](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_limits.htm) nella Guida per l'utente. CloudWatch *
+ Se all'inizio di una implementazione un allarme si trova nello stato `ALARM`, Amazon ECS non monitorerà gli allarmi per la durata di tale implementazione (Amazon ECS ignora la configurazione degli allarmi). Questo comportamento risolve il caso in cui si desideri avviare una nuova implementazione per correggere un errore di implementazione iniziale.

## Allarmi consigliati
<a name="ecs-deployment-alarms"></a>

È consigliabile utilizzare i seguenti parametri di allarme:
+ Se utilizzi un Application Load Balancer, utilizza i parametri `HTTPCode_ELB_5XX_Count` e `HTTPCode_ELB_4XX_Count` di Application Load Balancer. Questi parametri controllano i picchi HTTP. Per ulteriori informazioni sulle metriche di Application Load Balancer, consulta CloudWatch le metriche per il tuo Application Load [Balancer nella *User* Guide for Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-cloudwatch-metrics.html).
+ Per un'applicazione esistente, utilizza i parametri `CPUUtilization` e `MemoryUtilization`. Questi parametri controllano la percentuale di CPU e memoria utilizzate dal cluster o dal servizio. Per ulteriori informazioni, consulta [Considerazioni](cloudwatch-metrics.md#enable_cloudwatch).
+ Se utilizzi le Amazon Simple Queue Service code nelle tue attività, utilizza la metrica di `ApproximateNumberOfMessagesNotVisible` Amazon SQS. Questo parametro controlla il numero dei messaggi nella coda che vengono differiti e non sono disponibili per la lettura immediata. *Per ulteriori informazioni sui parametri di Amazon SQS, consulta Parametri [disponibili per CloudWatch Amazon SQS nella Amazon Simple Queue Service Developer](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-available-cloudwatch-metrics.html) Guide.*

## Tempo di incorporamento
<a name="deployment-bake-time"></a>

Quando utilizzi l'opzione di rollback per le distribuzioni dei tuoi servizi, Amazon ECS attende un ulteriore periodo di tempo dopo la distribuzione della revisione del servizio di destinazione prima di inviare un allarme. CloudWatch Questo è indicato come tempo di incorporamento, che inizia dopo che:
+ Tutte le attività per una revisione del servizio di destinazione sono in esecuzione e in buono stato
+ Le revisioni del servizio di origine vengono ridotte allo 0%

Il tempo di incorporamento predefinito è inferiore a 5 minuti. L'implementazione del servizio viene contrassegnata come completa dopo la scadenza del tempo di incorporamento.

È possibile configurare il tempo di incorporamento per un'implementazione continua. Quando utilizzi gli CloudWatch allarmi per rilevare un guasto, se modifichi il tempo di cottura e poi decidi di utilizzare l'impostazione predefinita di Amazon ECS, devi impostare manualmente il tempo di cottura.

# Hook del ciclo di vita per le implementazioni di servizi Amazon ECS
<a name="deployment-lifecycle-hooks"></a>

Quando inizia un'implementazione, passa attraverso le fasi del ciclo di vita. Queste fasi possono trovarsi in stati come IN\$1PROGRESS o SUCCESSFUL. È possibile utilizzare gli hook del ciclo di vita, che sono funzioni Lambda che Amazon ECS esegue in fasi del ciclo di vita specifiche. Le funzioni possono essere le seguenti:
+ Un'API asincrona che convalida il controllo dell'integrità entro 15 minuti.
+ Un'API di sondaggio che avvia un altro processo asincrono che valuta il completamento dell'hook del ciclo di vita. 

Al termine dell'esecuzione della funzione, essa deve restituire un `hookStatus` affinché l'implementazione continui. Se non viene restituito un `hookStatus` o se la funzione ha esito negativo, l'implementazione viene ripristinata. Di seguito sono riportati i valori `hookStatus`:
+ `SUCCEEDED`: l'implementazione continua fino alla fase successiva del ciclo di vita
+ `FAILED`: l'implementazione torna all'ultima riuscita.
+ `IN_PROGRESS`: Amazon ECS esegue nuovamente la funzione dopo un breve periodo di tempo. Per impostazione predefinita, si tratta di un intervallo di 30 secondi, tuttavia questo valore è personalizzabile restituendo un `callBackDelay` insieme a `hookStatus`.

Nell'esempio seguente viene illustrato come restituire un `hookStatus` con un ritardo di callback personalizzato. In questo esempio, Amazon ECS riproverebbe questo hook dopo 60 secondi invece dei 30 secondi predefiniti:

```
{
    "hookStatus": "IN_PROGRESS",
    "callBackDelay": 60
}
```

Quando si verifica un rollback, Amazon ECS esegue gli hook del ciclo di vita per le seguenti fasi del ciclo di vita:
+ PRODUCTION\$1TRAFFIC\$1SHIFT
+ TEST\$1TRAFFIC\$1SHIFT

## Payload del ciclo di vita
<a name="service-deployment-lifecycle-payloads"></a>

 Quando si configurano gli hook del ciclo di vita per le implementazioni di servizi ECS, Amazon ECS richiama questi hook in fasi specifiche del processo di implementazione. Ogni fase del ciclo di vita fornisce un payload JSON con informazioni sullo stato attuale dell'implementazione. Questo documento descrive la struttura del payload per ogni fase del ciclo di vita. 

### Struttura comune del payload
<a name="common-payload-structure"></a>

 I payload in tutte le fasi del ciclo di vita includono i seguenti campi comuni: 
+  `serviceArn`: il nome della risorsa Amazon (ARN) del servizio. 
+  `targetServiceRevisionArn`: l'ARN della revisione del servizio target in fase di implementazione. 
+  `testTrafficWeights`- Una mappa delle revisioni dei servizi in base ARNs alle corrispondenti percentuali di peso del traffico di test. 
+  `productionTrafficWeights`- Una mappa della revisione dei servizi in base ARNs alle corrispondenti percentuali di peso del traffico di produzione. 

### Payload delle fasi del ciclo di vita
<a name="lifecycle-stage-payloads"></a>

#### RECONCILE\$1SERVICE
<a name="reconcile-service"></a>

 Questa fase si verifica all'inizio del processo di implementazione quando il servizio viene riconciliato. Di seguito viene riportato un esempio di payload per questa fase del ciclo di vita.

```
{
  "serviceArn": "arn:aws:ecs:us-west-2:1234567890:service/myCluster/myService",
  "targetServiceRevisionArn": "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/01275892",
  "testTrafficWeights": {
    "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/01275892": 100,
    "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/78652123": 0
  },
  "productionTrafficWeights": {
    "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/01275892": 100,
    "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/78652123": 0
  }
}
```

 **Aspettative in questa fase:** 
+ Il set di attività principale è su scala 0%

#### PRE\$1SCALE\$1UP
<a name="pre-scale-up"></a>

 Questa fase avviene prima che le nuove attività vengano aumentate. Di seguito viene riportato un esempio di payload per questa fase del ciclo di vita.

```
{
  "serviceArn": "arn:aws:ecs:us-west-2:1234567890:service/myCluster/myService",
  "targetServiceRevisionArn": "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/01275892",
  "testTrafficWeights": {},
  "productionTrafficWeights": {}
}
```

 **Aspettative in questa fase:** 
+ Le attività di revisione del servizio verde sono su una scala dello 0%

#### POST\$1SCALE\$1UP
<a name="post-scale-up"></a>

 Questa fase avviene dopo che le nuove attività sono state aumentate e sono integre. Di seguito viene riportato un esempio di payload per questa fase del ciclo di vita.

```
{
  "serviceArn": "arn:aws:ecs:us-west-2:1234567890:service/myCluster/myService",
  "targetServiceRevisionArn": "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/01275892",
  "testTrafficWeights": {},
  "productionTrafficWeights": {}
}
```

 **Aspettative in questa fase:** 
+ Le attività di revisione del servizio verde sono su una scala dello 100%
+ Le attività di revisione del servizio verde sono integre

#### TEST\$1TRAFFIC\$1SHIFT
<a name="test-traffic-shift"></a>

 Questa fase avviene quando il traffico di test viene spostato sulle attività di revisione del servizio verde. 

Di seguito viene riportato un esempio di payload per questa fase del ciclo di vita.

```
{
  "serviceArn": "arn:aws:ecs:us-west-2:1234567890:service/myCluster/myService",
  "targetServiceRevisionArn": "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/01275892",
  "testTrafficWeights": {
    "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/01275892": 100,
    "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/78652123": 0
  },
  "productionTrafficWeights": {}
}
```

 **Aspettative in questa fase:** 
+ Il traffico di test si sta avviando verso le attività di revisione del servizio verde. 

#### POST\$1TEST\$1TRAFFIC\$1SHIFT
<a name="post-test-traffic-shift"></a>

 Questa fase avviene dopo che il traffico di test è stato completamente spostato verso le nuove attività. 

Di seguito viene riportato un esempio di payload per questa fase del ciclo di vita.

```
{
  "serviceArn": "arn:aws:ecs:us-west-2:1234567890:service/myCluster/myService",
  "targetServiceRevisionArn": "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/01275892",
  "testTrafficWeights": {},
  "productionTrafficWeights": {}
}
```

 **Aspettative in questa fase:** 
+ Il 100% del traffico di test è stato spostato verso le attività di revisione del servizio verde. 

#### PRODUCTION\$1TRAFFIC\$1SHIFT
<a name="production-traffic-shift"></a>

 Questa fase avviene quando il traffico di produzione viene spostato sulle attività di revisione del servizio verde. 

```
{
  "serviceArn": "arn:aws:ecs:us-west-2:1234567890:service/myCluster/myService",
  "targetServiceRevisionArn": "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/01275892",
  "testTrafficWeights": {},
  "productionTrafficWeights": {
    "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/01275892": 100,
    "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/78652123": 0
  }
}
```

 **Aspettative in questa fase:** 
+ Il traffico di produzione si sta spostando verso la revisione del servizio verde. 

#### POST\$1PRODUCTION\$1TRAFFIC\$1SHIFT
<a name="post-production-traffic-shift"></a>

 Questa fase avviene dopo che il traffico di produzione è stato spostato completamente alle attività di revisione del servizio verde. 

```
{
  "serviceArn": "arn:aws:ecs:us-west-2:1234567890:service/myCluster/myService",
  "targetServiceRevisionArn": "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/01275892",
  "testTrafficWeights": {},
  "productionTrafficWeights": {}
}
```

 **Aspettative in questa fase:** 
+ Il 100% del traffico di produzione è stato spostato verso le attività di revisione del servizio verde. 

### Categorie della fase del ciclo di vita
<a name="lifecycle-stage-categories"></a>

 Le fasi del ciclo di vita rientrano in due categorie: 

1.  **Fasi di invocazione singole**: queste fasi vengono invocate una sola volta durante l'implementazione di un servizio: 
   + PRE\$1SCALE\$1UP
   + POST\$1SCALE\$1UP
   + POST\$1TEST\$1TRAFFIC\$1SHIFT
   + POST\$1PRODUCTION\$1TRAFFIC\$1SHIFT

1.  **Fasi di invocazione ricorrenti**: queste fasi possono essere invocate più volte durante l'implementazione di un servizio, ad esempio quando si verifica un'operazione di rollback: 
   + TEST\$1TRAFFIC\$1SHIFT
   + PRODUCTION\$1TRAFFIC\$1SHIFT

### Stato dell'implementazione durante gli hook del ciclo di vita
<a name="deployment-status-during-lifecycle-hooks"></a>

 Mentre gli hook del ciclo di vita sono in esecuzione, lo stato di implementazione sarà `IN_PROGRESS` per tutte le fasi del ciclo di vita. 


| Stadio del ciclo di vita | Stato dell'implementazione | 
| --- | --- | 
| RECONCILE\$1SERVICE | IN\$1PROGRESS | 
| PRE\$1SCALE\$1UP | IN\$1PROGRESS | 
| POST\$1SCALE\$1UP | IN\$1PROGRESS | 
| TEST\$1TRAFFIC\$1SHIFT | IN\$1PROGRESS | 
| POST\$1TEST\$1TRAFFIC\$1SHIFT | IN\$1PROGRESS | 
| PRODUCTION\$1TRAFFIC\$1SHIFT | IN\$1PROGRESS | 
| POST\$1PRODUCTION\$1TRAFFIC\$1SHIFT | IN\$1PROGRESS | 

# Interruzione delle implementazioni dei servizi Amazon ECS
<a name="stop-service-deployment"></a>

È possibile interrompere manualmente una distribuzione quando l'interruttore automatico o gli allarmi non hanno rilevato un'installazione difettosa. CloudWatch Sono disponibili i seguenti tipi di interruzione:
+ Rollback: questa opzione ripristina l'implementazione del servizio alla revisione precedente del servizio. 

  È possibile utilizzare questa opzione anche se non è stata configurata l'implementazione del servizio per l'opzione di rollback. 

È possibile interrompere un'implementazione che si trova in uno dei seguenti stati. Per ulteriori informazioni sugli stati di implementazione, consultare [Visualizza la cronologia dei servizi utilizzando le distribuzioni dei servizi Amazon ECS](service-deployment.md).
+ PENDING: l'implementazione del servizio passa allo stato ROLLBACK\$1REQUESTED, quindi viene avviata l'operazione di rollback.
+ IN\$1PROGRESS: l'implementazione del servizio passa allo stato ROLLBACK\$1REQUESTED, quindi viene avviata l'operazione di rollback.
+ STOP\$1REQUESTED: l'implementazione del servizio continua fino all'interruzione.
+ ROLLBACK\$1REQUESTED: l'implementazione del servizio continua l'operazione di rollback.
+ ROLLBACK\$1IN\$1PROGRESS: l'implementazione del servizio continua l'operazione di rollback.

## Procedura
<a name="stop-service-deployment-procedure"></a>

Prima di iniziare, configurare le autorizzazioni richieste per visualizzare le implementazioni dei servizi. Per ulteriori informazioni, consulta [Autorizzazioni richieste per visualizzare le implementazioni del servizio di Amazon ECS](service-deployment-permissions.md).

------
#### [ Amazon ECS Console ]

1. [Apri la console nella versione 2. https://console.aws.amazon.com/ecs/](https://console.aws.amazon.com/ecs/v2)

1. Nella pagina **Cluster**, scegliere il cluster.

1. Nella pagina dei dettagli del cluster, nella sezione **Servizi**, selezionare il servizio.

   Si apre la pagina dei dettagli del servizio.

1. Nella pagina dei dettagli del servizio, scegliere **Implementazioni**.

   Viene visualizzata la pagina delle implementazioni.

1. In **Implementazione in corso**, scegliere **Esegui il rollback**. Quindi, nella finestra di conferma, scegliere **Rollback**.

------
#### [ AWS CLI ]

1. Eseguire `list-service-deployments` per recuperare l'ARN di implementazione del servizio. 

   Sostituiscili *user-input* con i tuoi valori.

   ```
   aws ecs list-service-deployments --cluster cluster-name --service service-name
   ```

   Annotare il `serviceDeploymentArn` per l'implementazione che si desidera interrompere.

   ```
   {
       "serviceDeployments": [
           {
               "serviceDeploymentArn": "arn:aws:ecs:us-west-2:123456789012:service-deployment/cluster-name/service-name/NCWGC2ZR-taawPAYrIaU5",
               "serviceArn": "arn:aws:ecs:us-west-2:123456789012:service/cluster-name/service-name",
               "clusterArn": "arn:aws:ecs:us-west-2:123456789012:cluster/cluster-name",
               "targetServiceRevisionArn": "arn:aws:ecs:us-west-2:123456789012:service-revision/cluster-name/service-name/4980306466373577095",
               "status": "SUCCESSFUL"
           }
       ]
   }
   ```

1. Esegui `stop-service-deployments`. Usare il `serviceDeploymentArn` restituito da `list-service-deployments`.

   *user-input*Sostituiscili con i tuoi valori.

   ```
   aws ecs stop-service-deployment --service-deployment-arn arn:aws:ecs:region:123456789012:service-deployment/cluster-name/service-name/NCWGC2ZR-taawPAYrIaU5 --stop-type ROLLBACK
   ```

------

## Fasi successive
<a name="stop-service-deployment-next-step"></a>

Decidere quali modifiche devono essere apportate al servizio, quindi aggiornare il servizio. Per ulteriori informazioni, consultare [Aggiornamento di un servizio Amazon ECS](update-service-console-v2.md).

# Distribuisci i servizi Amazon ECS sostituendo le attività
<a name="deployment-type-ecs"></a>

Quando viene creato un servizio che utilizza il tipo di implementazione con *aggiornamento in sequenza* (`ECS`), il pianificatore del servizio Amazon ECS sostituisce le attività correntemente in esecuzione con nuove attività. Il numero di attività che Amazon ECS aggiunge o rimuove dal servizio durante un aggiornamento continuo è controllato dalla configurazione di distribuzione del servizio. 

Amazon ECS utilizza i seguenti parametri per determinare il numero di attività:
+ `minimumHealthyPercent`Rappresenta il limite inferiore al numero di attività che devono essere eseguite e funzionanti per un servizio durante una distribuzione continua o quando un'istanza del contenitore si sta esaurendo, come percentuale del numero desiderato di attività per il servizio. Questo valore viene arrotondato per eccesso. Ad esempio, se la percentuale minima di integrità è `50`, il numero di processi desiderato è quattro, il pianificatore può interrompere due processi esistenti prima di avviare due nuovi processi. Allo stesso modo, se la percentuale di integrità minima è 75% e il numero di processi desiderato è due, il pianificatore non può interrompere alcun processo a causa del valore risultante che è anche due.
+ `maximumPercent`Rappresenta il limite massimo al numero di attività che devono essere eseguite per un servizio durante una distribuzione continua o quando un'istanza del contenitore si sta esaurendo, come percentuale del numero desiderato di attività per un servizio. Questo valore viene arrotondato per difetto. Ad esempio, se la percentuale massima è `200` e il numero di attività desiderato è quattro, lo scheduler può avviare quattro nuove attività prima di interrompere quattro attività esistenti. Allo stesso modo, se la percentuale di integrità massima è `125` e il numero di processi desiderato è tre, il pianificatore non può interrompere alcun processo a causa del valore risultante che è esso stesso tre.

Durante una distribuzione continua, quando le attività non funzionano correttamente, Amazon ECS le sostituisce per mantenere il servizio `minimumHealthyPercent` e proteggere la disponibilità. Le attività non corrette vengono sostituite utilizzando la stessa revisione del servizio a cui appartengono. Ciò garantisce che la sostituzione di attività non corrette nella revisione di origine sia indipendente dagli errori delle attività nella revisione di destinazione. Quando l'`maximumPercent`impostazione lo consente, lo scheduler avvia le attività sostitutive prima di interrompere quelle non sane. Se il `maximumPercent` parametro impedisce allo scheduler di avviare prima un'attività sostitutiva, lo scheduler interrompe un'attività non integra alla volta per liberare capacità prima di avviare un'attività sostitutiva.

**Importante**  
Quando si imposta una percentuale di integrità minima o massima, è necessario assicurarsi che lo scheduler possa arrestare o avviare almeno un'attività quando viene attivata un'implementazione. Se il servizio dispone di un'implementazione bloccata a causa di una configurazione di implementazione non valida, verrà inviato un messaggio di evento del servizio. Per ulteriori informazioni, consultare [service (*service-name*) non è stato in grado di interrompere o avviare le attività durante una distribuzione a causa della configurazione della distribuzione del servizio. Aggiorna il valore minimumHealthyPercent o MaximumPercent e riprova.](service-event-messages-list.md#service-event-messages-7).

Le implementazioni in sequenza dispongono di 2 metodi che forniscono un sistema per identificare rapidamente quando un'implementazione di servizi ha avuto esito negativo:
+ [In che modo l’interruttore di implementazione Amazon ECS rileva i guasti](deployment-circuit-breaker.md)
+ [In che modo CloudWatch gli allarmi rilevano gli errori di distribuzione di Amazon ECS](deployment-alarm-failure.md)

I metodi possono essere utilizzati separatamente o insieme. Quando si utilizzano entrambi i metodi, l'implementazione viene impostata come non riuscita non appena vengono soddisfatti i criteri di errore per entrambi i metodi di errore.

Utilizza le seguenti linee guida per determinare quale metodo usare:
+ Interruttore: utilizza questo metodo quando desideri interrompere un'implementazione quando le attività non possono essere avviate.
+ CloudWatch allarmi: utilizzate questo metodo quando desiderate interrompere una distribuzione in base ai parametri dell'applicazione.

Entrambi i metodi supportano il rollback alla revisione del servizio precedente.

## Risoluzione dell’immagine del container
<a name="deployment-container-image-stability"></a>

Per impostazione predefinita, Amazon ECS risolve i tag di immagine dei container specificati nella definizione dell'attività in digest delle immagini del container. Se si crea un servizio che esegue e gestisce una singola attività, tale attività viene utilizzata per stabilire digest di immagini per i container inclusi nell'operazione. Se viene creato un servizio che esegue e gestisce più attività, la prima attività avviata dal pianificatore di servizi durante l'implementazione viene utilizzata per stabilire i digest delle immagini per i container nelle attività.

Se tre o più tentativi di stabilire i digest delle immagini dei container hanno esito negativo, l'implementazione continua senza la risoluzione dei digest delle immagini. Se l'interruttore automatico di implementazione è abilitato, quest'ultima ha esito negativo e viene sottoposta a rollback.

Dopo aver stabilito i digest delle immagini del container, Amazon ECS utilizza i digest per avviare qualsiasi altra attività desiderata e per eventuali futuri aggiornamenti del servizio. Ciò comporta che tutte le attività di un servizio eseguono sempre immagini di container identiche, con conseguente coerenza delle versioni del software.

È possibile configurare questo comportamento per ogni container nell'attività utilizzando il parametro `versionConsistency` nella definizione del container. Per ulteriori informazioni, consultare [versionConsistency](task_definition_parameters.md#ContainerDefinition-versionconsistency).

**Nota**  
Le versioni di Amazon ECS Agent precedenti a `1.31.0` non supportano la risoluzione del digest delle immagini. Le versioni Agent da `1.31.0` a `1.69.0` supportano la risoluzione del digest delle immagini solo per le immagini inviate ai repository Amazon ECR. Le versioni Agent `1.70.0` o successive supportano la risoluzione del digest delle immagini per tutte le immagini. 
La versione della piattaforma minima di Fargate Linux per la risoluzione del digest delle immagini è `1.3.0`. La versione della piattaforma minima di Fargate Windows per la risoluzione del digest delle immagini è `1.0.0`.
Amazon ECS non acquisisce digest di container sidecar gestiti da Amazon ECS, come l'agente di GuardDuty sicurezza Amazon o il proxy Service Connect.
Per ridurre la potenziale latenza associata alla risoluzione delle immagini dei container nei servizi con più attività, eseguire la versione dell'agente Amazon ECS `1.83.0` o successiva sulle istanze di container EC2. Per evitare una potenziale latenza, specificare i digest delle immagini del container nella definizione dell'attività.
Se viene creato un servizio con un numero di attività desiderate pari a zero, Amazon ECS non può stabilire i digest dei container finché non si attiva un'altra implementazione del servizio con un numero di attività desiderate maggiore di zero.
Per stabilire digest di immagini aggiornati, è possibile forzare una nuova implementazione. I digest aggiornati verranno utilizzati per avviare nuove attività e non influiranno sulle attività già in esecuzione. Per ulteriori informazioni su come forzare nuove distribuzioni, consulta il riferimento alle [forceNewDeployment](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html#ECS-UpdateService-request-forceNewDeployment)API di *Amazon ECS.*
Quando si utilizzano provider di capacità EC2, se la capacità di avvio di un'attività non è sufficiente durante l'implementazione iniziale, la coerenza della versione del software potrebbe non funzionare. Per garantire la coerenza delle versioni anche in caso di capacità limitata, impostare esplicitamente `versionConsistency: "enabled"` nella configurazione del container di definizione delle attività anziché fare affidamento sul comportamento predefinito. Ciò fa sì che Amazon ECS attenda che la capacità diventi disponibile prima di procedere con l'implementazione.

# Best practice per i parametri del servizio di Amazon ECS
<a name="service-options"></a>

Per garantire che non si verifichino tempi di inattività delle applicazioni, il processo di implementazione è il seguente:

1. Avviare i nuovi container di applicazioni mantenendo attivi quelli esistenti.

1. Verificare che i nuovi container siano integri.

1. Arrestare i vecchi container.

 A seconda della configurazione di implementazione e della quantità di spazio libero e non riservato nel cluster, potrebbero essere necessari più cicli per completare la procedura per sostituire tutte le vecchie attività con nuove attività. 

Vi sono due opzioni di configurazione del servizio che è possibile utilizzare per modificare il numero:
+ `minimumHealthyPercent`: 100% (impostazione predefinita)

  Il limite inferiore sul numero di attività per cui il servizio deve rimanere nello stato `RUNNING` durante un'implementazione. Si tratta di una percentuale del `desiredCount` arrotondata per eccesso al valore intero più vicino. Questo parametro consente di eseguire l'implementazione senza utilizzare la capacità aggiuntiva del cluster.
+ `maximumPercent`: 200% (impostazione predefinita)

   Il limite superiore sul numero di attività per il servizio che sono consentite nello stato `RUNNING` o `PENDING` durante un'implementazione. Si tratta di una percentuale del `desiredCount` arrotondata per difetto al valore intero più vicino.

**Esempio: opzioni di configurazione predefinite**

Prendiamo in considerazione il seguente servizio con sei attività, implementato in un cluster che può ospitare otto attività in totale. Le opzioni di configurazione predefinite del servizio non consentono all'implementazione di scendere al di sotto del 100% delle sei attività desiderate.

Di seguito è riportato il procedimento di implementazione:

1. L'obiettivo è sostituire le sei attività.

1. Il pianificatore avvia due nuove attività perché le impostazioni predefinite richiedono che vi siano sei attività in esecuzione.

   Ora ci sono sei attività esistenti e due nuove attività.

1. Il pianificatore interrompe due delle attività esistenti.

   Ora ci sono quattro attività esistenti e due nuove attività.

1. Il pianificatore avvia due nuove attività aggiuntive.

   Ora ci sono quattro attività esistenti e quattro nuove attività.

1. Il pianificatore arresta due delle attività esistenti.

   Ora ci sono due attività esistenti e quattro attività nuove.

1. Il pianificatore avvia due nuove attività aggiuntive.

   Ora ci sono due attività esistenti e sei nuove attività.

1. Il pianificatore arresta le ultime due attività esistenti.

   Ora ci sono sei nuove attività.

Nell'esempio precedente, se si utilizzano i valori predefiniti per le opzioni, c'è un'attesa di 2,5 minuti per ogni nuova attività che inizia. Inoltre, il bilanciatore del carico potrebbe dover attendere 5 minuti prima che la vecchia attività si interrompa. 

**Esempio: Modifica `minimumHealthyPercent`**

È possibile velocizzare l'implementazione impostando il valore `minimumHealthyPercent` al 50%.

Prendiamo in considerazione il seguente servizio con sei attività, implementato in un cluster che può ospitare otto attività in totale. Di seguito è riportato il procedimento di implementazione:

1. L'obiettivo è sostituire sei attività.

1. Il pianificatore interrompe tre delle attività esistenti. 

   Sono ancora in esecuzione tre attività esistenti che soddisfano il valore `minimumHealthyPercent`.

1. Il pianificatore avvia cinque nuove attività.

   Ci sono tre attività esistenti e cinque nuove attività.

1. Il pianificatore interrompe tre attività esistenti rimanenti.

   Ci sono cinque nuove attività

1. Il pianificatore avvia le nuove attività finali.

   Ci sono sei nuove attività.

**Esempio: modificare lo spazio libero del cluster**

È inoltre possibile aggiungere altro spazio libero in modo da poter eseguire attività aggiuntive. 

Prendiamo in considerazione il seguente servizio con sei attività, implementato in un cluster che può ospitare dieci attività in totale. Di seguito è riportato il procedimento di implementazione:

1. L'obiettivo è sostituire le attività esistenti.

1. Il pianificatore interrompe tre delle attività esistenti.

   Ci sono tre attività esistenti.

1. Il pianificatore avvia sei nuove attività.

   Ci sono attività esistenti e sei nuove attività

1. Il pianificatore interrompe le tre attività esistenti.

   Ci sono sei nuove attività.

**Raccomandazioni**

Utilizzare i seguenti valori per le opzioni di configurazione del servizio quando le attività sono inattive da qualche tempo e non hanno un tasso di utilizzo elevato.
+ `minimumHealthyPercent`: 50%
+ `maximumPercent`: 200% 

# Creazione di un'implementazione di aggiornamenti continui di Amazon ECS
<a name="create-service-console-v2"></a>

Creare un servizio per eseguire e mantenere simultaneamente un numero specificato di istanze di una definizione di attività in un cluster. Se una delle tue attività non riesce o si interrompe, il pianificatore del servizio Amazon ECS avvia un'altra istanza della definizione di attività per sostituirla. Ciò consente di mantenere il numero desiderato di attività nel servizio.

Decidere i seguenti parametri di configurazione prima di creare un servizio:
+ Esistono due opzioni di calcolo che distribuiscono le attività.
  + Una **strategia per provider di capacità** fa sì che Amazon ECS distribuisca le attività in uno o più provider di capacità. 

    Se si desidera eseguire i carichi di lavoro su istanze gestite da Amazon ECS, occorre utilizzare l'opzione di strategia del provider di capacità.
  + Un **tipo di avvio** fa sì che Amazon ECS avvii le attività direttamente su Fargate o sulle istanze EC2 registrate nei cluster.

    Se si desidera eseguire i carichi di lavoro su istanze gestite da Amazon ECS, occorre utilizzare l'opzione di strategia del provider di capacità.
+ Le definizioni di processo che utilizzano la modalità di rete `awsvpc` o i servizi configurati per l'utilizzo di un load balancer devono disporre di una configurazione di rete. Di default, la console seleziona l'Amazon VPC di default insieme a tutte le sottoreti e il gruppo di sicurezza di default all'interno dell'Amazon VPC di default. 
+ La strategia di posizionamento, ossia la strategia di posizionamento delle attività predefinita, distribuisce le attività in modo uniforme tra le zone di disponibilità. 

  Consigliamo di utilizzare il ribilanciamento delle zone di disponibilità per garantire un'elevata disponibilità del servizio. Per ulteriori informazioni, consultare [Bilanciamento di un servizio Amazon ECS tra zone di disponibilità](service-rebalancing.md).
+ Quando utilizzi il **tipo di avvio** per l'implementazione del servizio, per impostazione predefinita il servizio viene avviato nelle sottoreti del cluster VPC.
+ Per la **strategia per provider di capacità**, la console seleziona un'opzione di calcolo di default. Di seguito viene descritto l'ordine utilizzato dalla console per selezionare un valore di default:
  + Se il cluster dispone di una strategia di provider di capacità definita, questa è selezionata.
  + Se nel cluster non è presente una strategia di provider di capacità di default definita, ma sono presenti i provider di capacità di Fargate aggiunti al cluster, è selezionata una strategia di provider di capacità personalizzata che utilizza il provider di capacità `FARGATE`.
  + Se nel cluster non è presente una strategia di provider di capacità di default definita, ma sono presenti uno o più provider di capacità del gruppo Auto Scaling aggiunti al cluster, l'opzione **Usa personalizzato (avanzate)** è selezionata e sarà necessario definire manualmente la strategia.
  + Se nel cluster non è presente una strategia di provider di capacità di default definita e non sono stati aggiunti provider di capacità al cluster, è selezionato il tipo di avvio Fargate.
+ Le opzioni predefinite per il rilevamento degli errori di implementazione prevedono l'utilizzo dell'opzione **Utilizza l'interruttore di implementazione di Amazon ECS** con l'opzione di **Rollback in caso di errori**.

  Per ulteriori informazioni, consultare [In che modo l’interruttore di implementazione Amazon ECS rileva i guasti](deployment-circuit-breaker.md).
+ Decidere se si desidera che Amazon ECS aumenti o riduca automaticamente il numero desiderato di attività nel servizio. Per informazioni, consulta [Scalabilità automatica del servizio Amazon ECS](service-auto-scaling.md).
+ Se hai bisogno di un'applicazione per connetterti ad altre applicazioni in esecuzione su Amazon ECS, determina l'opzione più adatta alla tua architettura. Per ulteriori informazioni, consultare [Interconnessione dei servizi Amazon ECS](interconnecting-services.md). 
+ Quando viene creato un servizio che utilizza l'interruttore automatico Amazon ECS, Amazon ECS crea un'implementazione e una revisione del servizio. Queste risorse consentono di visualizzare informazioni dettagliate sulla cronologia dei servizi. Per ulteriori informazioni, consulta [Visualizza la cronologia dei servizi utilizzando le distribuzioni dei servizi Amazon ECS](service-deployment.md).

  *Per informazioni su come creare un servizio utilizzando il AWS CLI, consulta [https://docs.aws.amazon.com/cli/latest/reference/ecs/create-service.html](https://docs.aws.amazon.com/cli/latest/reference/ecs/create-service.html)la sezione Reference.AWS Command Line Interface *

  Per informazioni su come creare un servizio utilizzando AWS CloudFormation, consulta [https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-ecs-service.html](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-ecs-service.html)la *Guida per l'AWS CloudFormation utente*.

## Creare un servizio con le opzioni predefinite
<a name="create-default-service"></a>

Puoi utilizzare la console per creare e implementare rapidamente un servizio. Il servizio ha la seguente configurazione:
+ Si implementa nel VPC e nelle sottoreti associate al cluster
+ Implementa un'attività
+ Utilizza l'implementazione in sequenza
+ Utilizza la strategia del provider di capacità con il tuo provider di capacità predefinito
+ Utilizza l'interruttore automatico di implementazione per rilevare i guasti e imposta l'opzione per ripristinare automaticamente l'implementazione in caso di errore

Per implementare un servizio utilizzando i parametri predefiniti, completa la seguente procedura.

**Per creare un servizio (console Amazon ECS)**

1. Apri la console nella [https://console.aws.amazon.com/ecs/versione 2](https://console.aws.amazon.com/ecs/v2).

1. Nella pagina di navigazione, scegli **Cluster**.

1. Nella pagina **Cluster**, scegliere il cluster in cui creare il servizio.

1. Nella scheda **Servizi**, scegliere **Crea**.

   Viene visualizzata la pagina **Crea servizio**.

1. In **Dettagli del servizio**, effettuare le seguenti operazioni:

   1. Per **Definizione di processo**, inserire la famiglia di definizioni di processi e la revisione da utilizzare.

   1. In **Nome servizio**, specificare un nome per il servizio.

1. Per utilizzare ECS Exec per il debug del servizio, selezionare **Attiva ECS Exec** in **Risoluzione dei problemi di configurazione**.

1. Nella sezione **Configurazione implementazione**, procedere come segue.

   1. Per **Attività desiderate**, immettere il numero di attività da avviare e gestire nel servizio.

1. (Facoltativo) Per identificare il servizio e le attività, espandi la sezione **Tags** (Tag), quindi configura i tag.

   Per fare in modo che Amazon ECS contrassegni automaticamente tutte le attività appena avviate con il nome del cluster e i tag di definizione delle attività, seleziona **Turn on Amazon ECS managed tags** (Attiva i tag gestiti da Amazon ECS), quindi seleziona **Task definitions** (Definizioni di attività).

   Per fare in modo che Amazon ECS contrassegni automaticamente tutte le attività appena avviate con il nome del cluster e i tag del servizio, seleziona **Turn on Amazon ECS managed tags** (Attiva i tag gestiti da Amazon ECS), quindi seleziona **Service** (Servizio).

   Aggiungi o rimuovi un tag.
   + [Aggiungi un tag] Scegli **Add tag** (Aggiungi tag), quindi effettuare le seguenti operazioni:
     + In **Chiave**, immetti il nome della chiave.
     + In **Valore**, immetti il valore della chiave.
   + [Rimuovere un tag] Accanto al tag, scegliere **Remove tag (Rimuovi tag)**.

## Creazione di un servizio utilizzando parametri definiti
<a name="create-custom-service"></a>

Per creare un servizio utilizzando i parametri definiti, completare la seguente procedura.

**Per creare un servizio (console Amazon ECS)**

1. Apri la console nella [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2).

1. Determina la risorsa da cui avviare il servizio.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonECS/latest/developerguide/create-service-console-v2.html)

   Viene visualizzata la pagina **Crea servizio**.

1. In Dettagli del servizio, effettuare le seguenti operazioni:

   1. Per **Definizione di processo**, inserire la definizione di processi da utilizzare. Quindi, per **Revisione**, scegliere la revisione da utilizzare.

   1. In **Nome servizio**, specificare un nome per il servizio.

1. Per **Cluster esistente**, scegliere il cluster.

   Scegliere **Crea cluster** per eseguire l'attività su un nuovo cluster

1. Scegliere come vengono distribuite le attività nell'infrastruttura cluster. In **Configurazione di calcolo**, scegliere l'opzione.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonECS/latest/developerguide/create-service-console-v2.html)

1. Per utilizzare ECS Exec per il debug del servizio, selezionare **Attiva ECS Exec** in **Risoluzione dei problemi di configurazione**.

1. Nella sezione **Configurazione implementazione**, procedere come segue.

   1. Per **Service type** (Tipo di servizio), scegli la strategia di pianificazione del servizio.
      + Perché lo scheduler implementi esattamente una attività su ciascuna istanza di container che risponda a tutti i vincoli di posizionamento dell'attività, scegli **Daemon**.
      + Perché lo scheduler posizioni e mantenga il numero di attività desiderato nel cluster, scegli **Replica**.

   1. Se hai scelto **Replica**, per **Desired tasks** (Attività desiderate), immetti il numero di attività da avviare e mantenere nel servizio.

   1. Se è stato scelto **Replica**, per consentire ad Amazon ECS di monitorare la distribuzione delle attività tra le zone di disponibilità e ridistribuirle in caso di squilibrio, in **Ribilanciamento del servizio delle zone di disponibilità**, selezionare **Ribilanciamento del servizio della zona di disponibilità.**

   1. Per **Periodo di tolleranza dei controlli di integrità**, inserire il periodo di tempo (in secondi) durante il quale il pianificatore di servizi ignora i controlli dell'integrità dei container, di bilanciamento dei carichi elastici e di VPC Lattice non integri dopo che è stata avviata un'attività. Se non si specifica un valore per il periodo di tolleranza per il controllo dell’integrità, viene utilizzato il valore predefinito di 0.

   1. Determina il tipo di implementazione per il servizio. Espandere **Opzioni di implementazione**, quindi specificare i seguenti parametri.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonECS/latest/developerguide/create-service-console-v2.html)

   1. Per configurare il modo in cui Amazon ECS rileva e gestisce gli errori di implementazione, espandi **Deployment failure detection** (Rilevamento degli errori di implementazione), quindi scegli le tue opzioni. 

      1. Per interrompere un'implementazione quando le attività non possono essere avviate, seleziona **Use the Amazon ECS deployment circuit breaker** (Usa l'interruttore automatico di implementazione di Amazon ECS).

         Per fare in modo che il software ripristini automaticamente l'implementazione all'ultimo stato di implementazione completata quando l'interruttore automatico di implementazione imposta l'implementazione su uno stato di errore, selezionare **Rollback in caso di errore**.

      1. Per interrompere una distribuzione in base ai parametri dell'applicazione, seleziona **Usa CloudWatch allarmi.** Quindi, dal **nome CloudWatch dell'allarme**, scegli gli allarmi. Per creare un nuovo allarme, vai alla CloudWatch console.

         Per fare in modo che il software ripristini automaticamente la distribuzione all'ultimo stato di distribuzione completato quando un CloudWatch allarme imposta la distribuzione **su uno stato fallito, seleziona Rollback in caso** di errori.

1. Se la definizione dell'attività utilizza la modalità di rete `awsvpc`, è possibile specificare una configurazione di rete personalizzata espandendo **Rete** e quindi effettuare le seguenti operazioni:

   1. Per **VPC** seleziona il VPC da utilizzare.

   1. Per **Subnets** (Sottoreti), seleziona una o più sottoreti nel VPC che lo scheduler di attività deve prendere in considerazione quando posiziona le attività.

   1. Per **Gruppi di sicurezza** è possibile selezionare un gruppo di sicurezza esistente o crearne uno nuovo. Per utilizzare un gruppo di sicurezza esistente, seleziona il gruppo di sicurezza e passa alla fase successiva. Per creare un nuovo gruppo di sicurezza, scegliere **Create a new security group (Crea un nuovo gruppo di sicurezza)**. È necessario specificare un nome e una descrizione del gruppo di sicurezza e aggiungere una o più regole in entrata per il gruppo di sicurezza.

   1. Per **IP pubblico** scegli se assegnare automaticamente un indirizzo IP pubblico all'interfaccia di rete elastica (ENI) del processo stesso.

      AWS Fargate alle attività può essere assegnato un indirizzo IP pubblico quando vengono eseguite in una sottorete pubblica in modo che abbiano un percorso verso Internet. Non è possibile assegnare alle attività EC2 un IP pubblico utilizzando questo campo. Per ulteriori informazioni, consultare [Amazon ECS task networking options for Fargate](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/fargate-task-networking.html) e [Allocate a network interface for an Amazon ECS task](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-networking-awsvpc.html).

1. (Facoltativo) Per connettere il servizio usando Service Connect, espandere **Service Connect**, quindi specificare quanto segue:

   1.  Selezionare **Attiva Service Connect**.

   1. In **Service Connect configuration** (Configurazione Service Connect), specifica la modalità client.
      + Se il servizio esegue un'applicazione client di rete che deve connettersi solo ad altri servizi nel namespace, scegliere **Solo lato client**.
      + Se il servizio esegue un'applicazione di rete o di servizio Web, deve fornire endpoint per questo servizio e si connette ad altri servizi nel namespace, scegliere **Client e server**.

   1. Per utilizzare un namespace differente da quello del cluster predefinito, per **Namespace**, scegliere il namespace del servizio. Può trattarsi di uno spazio dei nomi creato separatamente Regione AWS nello stesso spazio dell'utente Account AWS o di uno spazio dei nomi nella stessa regione condiviso con il proprio account utilizzando (). AWS Resource Access Manager AWS RAM*Per ulteriori informazioni sugli spazi dei AWS Cloud Map nomi condivisi, consulta Condivisione dello spazio dei nomi [tra AWS Cloud Map](https://docs.aws.amazon.com/cloud-map/latest/dg/sharing-namespaces.html) account nella Guida per gli sviluppatori.AWS Cloud Map *

   1. (Facoltativo) Specificare una configurazione del log. Selezionare **Usa la raccolta di log**. L'opzione predefinita invia i log dei contenitori a Logs. CloudWatch Le altre opzioni del driver di registro sono configurate utilizzando. AWS FireLens Per ulteriori informazioni, consulta [Inviare i log di Amazon ECS a un servizio o AWS AWS Partner](using_firelens.md).

      Di seguito sono riportate descrizioni più dettagliate per ogni destinazione di log di container.
      + **Amazon CloudWatch**: configura l'attività per inviare i log dei container a CloudWatch Logs. Vengono fornite le opzioni predefinite dei driver di registro, che creano un gruppo di CloudWatch log per tuo conto. Per specificare un nome del gruppo di log diverso, modifica i valori dell'opzione del driver.
      + **Amazon Data Firehose**: configura l'attività per inviare i log del container a Firehose. Vengono fornite le opzioni di driver di log predefinite che inviano i log a un flusso di consegna Firehose. Per specificare un nome del flusso di consegna diverso, modifica i valori dell'opzione del driver.
      + **Flusso di dati Amazon Kinesis**: configura il processo per inviare log di container a Kinesis Data Streams. Vengono fornite le opzioni di driver di log predefinite che inviano i log a un flusso di consegna Kinesis Data Streams. Per specificare un nome del flusso diverso, modifica i valori dell'opzione del driver.
      + **Amazon OpenSearch Service**: configura l'attività per inviare i log dei container a un dominio OpenSearch di servizio. Devono essere fornite le opzioni del driver di log. 
      + **Amazon S3**: configura l'attività per inviare log di container a un bucket Amazon S3. Vengono fornite le opzioni del driver di log predefinito, ma è necessario specificare un nome del bucket Amazon S3 valido.

   1. (Facoltativo) Per abilitare i log di accesso, segui questi passaggi:

      1. Espandi la **configurazione del registro di accesso**. Per **Format**, scegli **JSON** o`TEXT`.

      1. Per includere i parametri di interrogazione nei log di accesso, selezionate **Includi parametri di interrogazione**.

1. (Facoltativo) Per connettere il servizio usando il rilevamento servizi, espandere **Rilevamento servizi**, ed effettuare le seguenti operazioni:

   1. Selezionare **Utilizza il rilevamento servizi**.

   1. Per utilizzare un nuovo namespace, scegliere **Crea un nuovo namespace** in **Configura namespace**, fornire quindi un nome e una descrizione del namespace. Per utilizzare un namespace esistente, scegliere **Seleziona un namespace esistente**, scegliere quindi il namespace da utilizzare.

   1. Fornire informazioni sul servizio di rilevamento servizi come il nome e la descrizione del servizio.

   1. Per fare in modo che Amazon ECS esegua controlli periodici dello stato di integrità a livello di container, selezionare **Abilita la propagazione dell'integrità delle attività Amazon ECS**.

   1. Per **Tipo di record DNS** seleziona il tipo di record DNS da creare per il servizio. Il rilevamento servizi Amazon ECS supporta solo record **A** e **SRV**, a seconda della modalità di rete specificata dalla definizione di attività. Per informazioni su questi tipi di record, consulta [Tipi di record DNS supportati](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/ResourceRecordTypes.html) nella *Guida per gli sviluppatori di Amazon Route 53*.
      + Se la definizione di attività specificata dalla tua attività di servizio usa la modalità di rete `bridge` o `host`, sono supportati solo i record di tipo **SRV**. Scegli un nome di container e una combinazione di porte da associare al record.
      + Se la definizione di attività specificata dalla tua attività di servizio usa la modalità di rete `awsvpc`, seleziona il tipo di record **A** o **SRV**. Se si sceglie **A**, andare al passaggio successivo. Se si sceglie **SRV**, specificare la porta sulla quale si trova il servizio oppure un nome di container e una combinazione di porte da associare al record.

      Per **TTL**, inserire il tempo in secondi per cui un set di record viene memorizzato nella cache dai resolver DNS e dai browser Web.

1. (Facoltativo) Per collegare il servizio utilizzando VPC Lattice, espandere **VPC Lattice**, quindi effettuare le seguenti operazioni:

   1. Selezionare **Attiva VPC Lattice**

   1. Per **Ruolo dell'infrastruttura**, scegliere il ruolo dell'infrastruttura.

      Se non è stato creato un ruolo, scegliere **Crea ruolo dell'infrastruttura**.

   1. In **Gruppi di destinazione**, scegliere il gruppo o i gruppi di destinazione. È necessario scegliere un gruppo di destinazione compreso tra 1 e 5. Scegliere **Aggiungi gruppo di destinazione** per aggiungere altri gruppi di destinazione. Scegliere il **Nome della porta**, il **Protocollo** e la **Porta** per ogni gruppo di destinazione scelto. 

      Per rimuovere un gruppo di destinazione, scegliere **Rimuovi**.
**Nota**  
Se si desidera aggiungere gruppi di destinazione esistenti, è necessario usare la AWS CLI. *Per istruzioni su come aggiungere gruppi target utilizzando il AWS CLI, consulta [register-targets](https://docs.aws.amazon.com/cli/latest/reference/vpc-lattice/register-targets.html) nella Guida di riferimento. AWS Command Line Interface *
Sebbene un servizio VPC Lattice possa essere collegato a più gruppi di destinazione, un gruppo di destinazione può essere aggiunto solo a un singolo servizio.

   1. Per completare la configurazione VPC Lattice, includendo i nuovi gruppi di destinazione nell'azione predefinita del listener o nelle regole di un servizio VPC Lattice esistente nella console VPC Lattice. Per ulteriori informazioni, consultare [Listener rules for your VPC Lattice service](https://docs.aws.amazon.com/vpc-lattice/latest/ug/listener-rules.html).

1. (Facoltativo) Per configurare un load balancer per il servizio, espandi **Load balancing** (Bilanciamento del carico).

   Scegli il load balancer.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonECS/latest/developerguide/create-service-console-v2.html)

1. (Facoltativo) Per configurare il servizio di dimensionamento automatico, espandere **Dimensionamento automatico del servizio** e quindi specificare i seguenti parametri. Per utilizzare il dimensionamento automatico predittivo, che esamina i dati di caricamento precedenti provenienti dai flussi di traffico, è necessario configurarlo dopo aver creato il servizio. Per ulteriori informazioni, consultare [Usa modelli storici per scalare i servizi Amazon ECS con scalabilità predittiva](predictive-auto-scaling.md).

   1. Per utilizzare il dimensionamento automatico, selezionare **Dimensionamento automatico del servizio**.

   1. Per **Numero minimo di attività**, inserire il limite inferiore del numero di attività che devono essere utilizzate dal servizio di dimensionamento automatico. Il numero desiderato non scenderà al di sotto di questo conteggio.

   1. In **Numero massimo di processi**, specificare il limite superiore del numero di processi che devono essere utilizzati dal servizio di dimensionamento automatico. Il numero desiderato non sarà superiore a questo conteggio.

   1. Scegli il tipo di policy. In **Tipo di policy di dimensionamento**, scegliere una delle opzioni seguenti.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonECS/latest/developerguide/create-service-console-v2.html)

1. (Facoltativo) Per utilizzare una strategia di posizionamento delle attività diversa da quella predefinita, espandi **Task Placement** (Posizionamento attività), quindi scegli una tra le seguenti opzioni.

    Per ulteriori informazioni, consultare [In che modo Amazon ECS colloca le attività sulle istanze dei container](task-placement.md).
   + **Distribuzione con bilanciamento AZ**: consente di distribuire le attività tra zone di disponibilità e istanze di container nella zona di disponibilità.
   + **AZ Balanced BinPack**: distribuisci le attività tra le zone di disponibilità e tra le istanze di container con la minima memoria disponibile.
   + **BinPack**— Distribuisci le attività in base alla quantità minima disponibile di CPU o memoria.
   + **One Task Per Host (Un’attività per host)**: consente di posizionare al massimo un’attività dal servizio in ogni istanza di container.
   + **Personalizzato**: consente di definire una strategia personalizzata di posizionamento delle attività. 

   Se hai scelto **Custom** (Personalizzato), definisci l'algoritmo per il posizionamento delle attività e le regole che vengono prese in considerazione durante il posizionamento delle attività.
   + In **Strategy** (Strategia), per **Type** (Tipo) e **Field** (Campo), scegli l'algoritmo e l'entità da utilizzare per l'algoritmo.

     Puoi aggiungere un massimo di 5 strategie.
   + In **Vincolo**, per **Tipo** ed **Espressione**, scegli la regola e l'attributo per il vincolo.

     Ad esempio, per impostare il vincolo per posizionare le attività su istanze T2, per **Expression** (Espressione), immetti **attribute:ecs.instance-type =\$1 t2.\$1**.

     Puoi aggiungere un massimo di 10 vincoli.

1. Se l'attività utilizza un volume di dati compatibile con la configurazione al momento dell'implementazione, è possibile configurare il volume espandendo **Volume**.

   Il nome e il tipo di volume vengono configurati durante la creazione di una revisione della definizione di attività e non possono essere modificati quando si crea un servizio. Per aggiornare il nome e il tipo di volume, è necessario creare una nuova revisione della definizione di attività e creare un servizio utilizzando la nuova revisione.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonECS/latest/developerguide/create-service-console-v2.html)

1. Per utilizzare ECS Exec per il debug del servizio, selezionare **Attiva ECS Exec** in **Risoluzione dei problemi di configurazione**.

1. (Facoltativo) Per identificare il servizio e le attività, espandi la sezione **Tags** (Tag), quindi configura i tag.

   Per fare in modo che Amazon ECS contrassegni automaticamente tutte le attività appena avviate con il nome del cluster e i tag di definizione delle attività, seleziona **Attiva i tag gestiti di Amazon ECS**, quindi in **Propaga i tag da**, scegli **Definizioni di attività**.

   Per fare in modo che Amazon ECS contrassegni automaticamente tutte le attività appena avviate con il nome del cluster e i tag del servizio, seleziona **Attiva i tag gestiti di Amazon ECS**, quindi in **Propaga i tag da**, scegli **Servizio**.

   Aggiungi o rimuovi un tag.
   + [Aggiungi un tag] Scegli **Add tag** (Aggiungi tag), quindi effettuare le seguenti operazioni:
     + In **Chiave**, immetti il nome della chiave.
     + In **Valore**, immetti il valore della chiave.
   + [Rimuovere un tag] Accanto al tag, scegliere **Remove tag (Rimuovi tag)**.

1. Scegli **Create** (Crea).

## Fasi successive
<a name="create-service-next-steps"></a>

Di seguito sono riportate le operazioni aggiuntive dopo la creazione di un servizio.
+ Configurare il dimensionamento automatico predittivo, che analizza i dati di caricamento precedenti provenienti dai flussi di traffico. Per ulteriori informazioni, consultare [Usa modelli storici per scalare i servizi Amazon ECS con scalabilità predittiva](predictive-auto-scaling.md).
+ Tracciare l'implementazione e visualizzare la cronologia dei servizi dell'interruttore automatico di Amazon ECS. Per ulteriori informazioni, consulta [Visualizza la cronologia dei servizi utilizzando le distribuzioni dei servizi Amazon ECS](service-deployment.md).

# Implementazioni Amazon ECS blue/green
<a name="deployment-type-blue-green"></a>

Una blue/green distribuzione è una metodologia di rilascio che riduce i tempi di inattività e i rischi eseguendo due ambienti di produzione identici denominati blu e verde. Con le blue/green implementazioni di Amazon ECS, puoi convalidare nuove revisioni dei servizi prima di indirizzare il traffico di produzione verso di esse. Questo approccio offre un modo più sicuro per implementare le modifiche con la possibilità di ripristinarle rapidamente, se necessario.

## Vantaggi
<a name="blue-green-deployment-benefits"></a>

Di seguito sono riportati i vantaggi dell'utilizzo delle distribuzioni: blue/green 
+ Riduce i rischi effettuando test con il traffico di produzione prima di cambiare produzione. È possibile convalidare la nuova implementazione con traffico di test prima di indirizzare il traffico di produzione verso di essa.
+ Implementazioni prive di tempo di inattività. L'ambiente di produzione rimane disponibile durante tutto il processo di implementazione, garantendo la disponibilità continua del servizio.
+ Rollback semplificato in caso di rilevamento di problemi. In caso di problemi con l'implementazione verde, è possibile tornare rapidamente all'implementazione blu senza interruzioni prolungate del servizio.
+ Ambiente di test controllato. L'ambiente verde offre uno spazio isolato per testare nuove funzionalità con modelli di traffico reali prima dell'implementazione completa.
+ Processo di implementazione prevedibile. L'approccio strutturato con fasi del ciclo di vita definite rende le implementazioni più coerenti e affidabili.
+ Convalida automatizzata tramite hook del ciclo di vita. È possibile implementare test automatizzati in varie fasi dell'implementazione per verificare la funzionalità.

## Terminologia
<a name="blue-green-deployment-terms"></a>

Di seguito sono riportati i termini di blue/green distribuzione di Amazon ECS:
+ Tempo di incorporamento: la durata in cui le revisioni del servizio blu e verde vengono eseguite contemporaneamente dopo lo spostamento del traffico di produzione.
+ Implementazione blu: l'attuale revisione del servizio di produzione che si desidera sostituire.
+ Implementazione verde: la nuova revisione del servizio che si desidera implementare.
+ Fasi del ciclo di vita: una serie di eventi nell'operazione di implementazione, ad esempio “dopo lo spostamento del traffico di produzione”.
+ Hook del ciclo di vita: una funzione Lambda che verifica l'implementazione in una fase specifica del ciclo di vita.
+ Listener: una risorsa di bilanciamento del carico elastico che controlla le richieste di connessione utilizzando il protocollo e la porta configurata. Le regole definite per un listener determinano il modo in cui Amazon ECS instrada le richieste alle destinazioni registrate.
+ Regola: una risorsa di bilanciamento del carico elastico associata a un listener. Una regola definisce il modo in cui le richieste vengono instradate e consiste in un'azione, una condizione e una priorità.
+ Gruppo di destinazione: una risorsa di bilanciamento del carico elastico utilizzata per indirizzare le richieste verso una o più destinazioni registrate (ad esempio, istanze EC2). Quando si crea un listener, si specifica un gruppo di destinazione per l'operazione predefinita. Il traffico viene inoltrato al gruppo di destinazione specificato nella regola del listener.
+ Spostamento del traffico: il processo utilizzato da Amazon ECS per spostare il traffico dall'implementazione blu all'implementazione verde. Per le blue/green implementazioni di Amazon ECS, tutto il traffico viene spostato dal servizio blu al servizio verde contemporaneamente.

## Considerazioni
<a name="blue-green-deployment-considerations"></a>

Si tenga in considerazione quanto segue quando si sceglie un tipo di implementazione:
+ Utilizzo delle risorse: Blue/green le distribuzioni eseguono temporaneamente le revisioni del servizio blu e verde contemporaneamente, il che può raddoppiare l'utilizzo delle risorse durante le distribuzioni.
+ Monitoraggio dell'implementazione: Blue/green le distribuzioni forniscono informazioni più dettagliate sullo stato dell'implementazione, che consentono di monitorare ogni fase del processo di implementazione.
+ Rollback: Blue/green le implementazioni semplificano il ripristino alla versione precedente se vengono rilevati problemi, poiché la revisione blu viene mantenuta attiva fino alla scadenza del tempo di cottura.
+ Hook del ciclo di vita di Network Load Balancer: se si utilizza un Network Load Balancer per le blue/green distribuzioni, sono disponibili altri 10 minuti per le fasi del ciclo di vita TEST\$1TRAFFIC\$1SHIFT e PRODUCTION\$1TRAFFIC\$1SHIFT. Questo perché Amazon ECS garantisce che lo spostamento del traffico sia sicuro.

# Flusso di lavoro di implementazione dei blue/green servizi Amazon ECS
<a name="blue-green-deployment-how-it-works"></a>

Il processo di blue/green distribuzione di Amazon ECS segue un approccio strutturato con sei fasi distinte che garantiscono aggiornamenti delle applicazioni sicuri e affidabili. Ogni fase ha uno scopo specifico nella convalida e nella transizione dell'applicazione dalla versione attuale (blu) alla nuova versione (verde).

1. **Fase di preparazione**: creare l'ambiente verde insieme a quello blu esistente. Ciò include la fornitura di nuove revisioni dei servizi e la preparazione dei gruppi di destinazione.

1. **Fase di implementazione**: implementazione della nuova revisione del servizio nell'ambiente verde. Amazon ECS avvia nuove attività utilizzando la revisione aggiornata del servizio mentre l'ambiente blu continua a servire il traffico di produzione.

1. **Fase di test**: convalida dell'ambiente verde utilizzando l'instradamento del traffico di test. L'Application Load Balancer indirizza le richieste di test verso l'ambiente verde mentre il traffico di produzione rimane sul blu.

1. **Fase di spostamento del traffico**: spostamento del traffico di produzione dal blu al verde in base alla strategia di implementazione configurata. Questa fase include i punti di controllo di monitoraggio e convalida.

1. **Fase di monitoraggio**: monitoraggio dello stato delle applicazioni, delle metriche delle prestazioni e degli stati di allarme durante il periodo di tempo di incorporamento. Quando vengono rilevati problemi, viene avviata un'operazione di rollback.

1. **Fase di completamento**: finalizzazione dell'implementazione chiudendo l'ambiente blu o mantenendolo per potenziali scenari di rollback, a seconda della configurazione.

## Flusso di lavoro
<a name="blue-green-deployment-workflow"></a>

Il diagramma seguente illustra il flusso di lavoro di blue/green implementazione completo, mostrando l'interazione tra Amazon ECS e Application Load Balancer:

![\[Diagramma completo che mostra il processo di blue/green distribuzione in Amazon ECS con interazioni dettagliate dei componenti, fasi di spostamento del traffico e punti di controllo di monitoraggio\]](http://docs.aws.amazon.com/it_it/AmazonECS/latest/developerguide/images/blue-green.png)


Il flusso di lavoro di implementazione avanzato include i seguenti passaggi dettagliati:

1. **Stato iniziale**: il servizio blu (produzione attuale) gestisce il 100% del traffico di produzione. L'Application Load Balancer dispone di un unico listener con regole che indirizzano tutte le richieste al gruppo di destinazione blu contenente attività blu integre.

1. **Provisioning dell'ambiente verde**: Amazon ECS crea nuove attività utilizzando la definizione di quelle aggiornate. Queste attività vengono registrate presso un nuovo gruppo di destinazione verde, ma inizialmente non ricevono traffico.

1. **Convalida del controllo dell'integrità**: l'Application Load Balancer esegue controlli di integrità sulle attività verdi. Solo quando le attività verdi superano i controlli dell'integrità, l'implementazione passa alla fase successiva.

1. **Test di instradamento del traffico**: se configurate, le regole del listener di Application Load Balancer indirizzano modelli di traffico specifici (come le richieste con intestazioni di test) verso l'ambiente verde per la convalida, mentre il traffico di produzione rimane sul blu. Questo è controllato dallo stesso listener che gestisce il traffico di produzione, utilizzando regole diverse basate sugli attributi della richiesta.

1. **Spostamento del traffico di produzione**: in base alla configurazione di implementazione, il traffico passa dal blu al verde. Nelle blue/green implementazioni ECS, si tratta di uno spostamento immediato (all-at-once) in cui il 100% del traffico viene spostato dall'ambiente blu a quello verde. L'Application Load Balancer utilizza un singolo listener con regole del listener che controllano la distribuzione del traffico tra i gruppi di destinazione blu e verdi in base alle ponderazioni.

1. **Monitoraggio e convalida**: durante l'intero spostamento del traffico, Amazon ECS monitora CloudWatch metriche, stati di allarme e stato di implementazione. I trigger di rollback automatici si attivano se vengono rilevati problemi.

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. **Terminazione dell'ambiente blu**: dopo il corretto spostamento del traffico e la convalida, l'ambiente blu viene terminato per liberare risorse del cluster o mantenuto per consentire una rapida capacità di rollback.

1. **Stato finale**: l'ambiente verde diventa il nuovo ambiente di produzione, che gestisce il 100% del traffico. L'implementazione è contrassegnata come riuscita.

## Fasi del ciclo di vita dell'implementazione
<a name="blue-green-deployment-stages"></a>

Il processo di blue/green implementazione procede attraverso fasi distinte del ciclo di vita (una serie di eventi durante l'operazione di distribuzione, ad esempio «spostamento del traffico dopo la produzione»), ciascuna con responsabilità e punti di controllo di convalida specifici. La comprensione di queste fasi consente di monitorare l'avanzamento dell'implementazione e risolvere i problemi in modo efficace.

 Ogni fase del ciclo di vita può durare fino a 24 ore. Si consiglia di mantenere il valore al di sotto della soglia delle 24 ore. Questo perché i processi asincroni richiedono tempo per attivare gli hook. Il sistema scade, fallisce l'implementazione e quindi avvia un rollback dopo che una fase raggiunge le 24 ore. CloudFormation le distribuzioni hanno restrizioni di timeout aggiuntive. Sebbene il limite delle fasi di 24 ore rimanga in vigore, CloudFormation impone un limite di 36 ore all'intera implementazione. CloudFormation fallisce l'implementazione e quindi avvia un rollback se il processo non viene completato entro 36 ore.


| Fasi del ciclo di vita | Description | Usare questa fase per gli hook del ciclo di vita? | 
| --- | --- | --- | 
| RECONCILE\$1SERVICE | Questa fase si verifica solo quando si avvia una nuova implementazione del servizio con più di 1 revisione del servizio in uno stato ACTIVE. | Sì | 
| PRE\$1SCALE\$1UP | La revisione del servizio verde non è stata avviata. La revisione del servizio blu gestisce il 100% del traffico di produzione. Non è previsto alcun traffico di test. | Sì | 
| SCALE\$1UP | Il momento in cui la revisione del servizio verde aumenta fino al 100% e avvia nuove attività. La revisione del servizio verde non serve alcun traffico a questo punto. | No | 
| POST\$1SCALE\$1UP | La revisione del servizio verde è stata avviata. La revisione del servizio blu gestisce il 100% del traffico di produzione. Non è previsto alcun traffico di test. | Sì | 
| TEST\$1TRAFFIC\$1SHIFT | Le revisioni del servizio blu e verde sono in esecuzione. La revisione del servizio blu gestisce il 100% del traffico di produzione. La revisione del servizio verde migra dallo 0% al 100% del traffico di test. | Sì | 
| POST\$1TEST\$1TRAFFIC\$1SHIFT | Lo spostamento del traffico di test è completo. La revisione del servizio verde gestisce il 100% del traffico di test. | Sì | 
| PRODUCTION\$1TRAFFIC\$1SHIFT | Il traffico di produzione sta passando alla revisione del servizio verde. La revisione del servizio verde sta migrando dallo 0% al 100% del traffico di produzione. | Sì | 
| POST\$1PRODUCTION\$1TRAFFIC\$1SHIFT | Lo spostamento del traffico di produzione è completo. | Sì | 
| BAKE\$1TIME | La durata in cui le revisioni del servizio blu e verde vengono eseguite contemporaneamente. | No | 
| CLEAN\$1UP | La revisione del servizio blu è stata completamente ridotta a 0 attività in esecuzione. La revisione del servizio verde è ora la revisione del servizio di produzione dopo questa fase. | No | 

Ogni fase del ciclo di vita include punti di controllo di convalida integrati che devono essere superati prima di passare alla fase successiva. Se una convalida ha esito negativo, l'implementazione può essere ripristinata automaticamente per mantenere la disponibilità e l'affidabilità del servizio.

Quando si utilizza una funzione Lambda, la funzione deve completare il lavoro o ritornare IN\$1PROGRESS entro 15 minuti. È possibile utilizzare il `callBackDelaySeconds` per ritardare la chiamata a Lambda. Per ulteriori informazioni, vedete [la funzione app.py](https://github.com/aws-samples/sample-amazon-ecs-blue-green-deployment-patterns/blob/main/ecs-bluegreen-lifecycle-hooks/src/approvalFunction/app.py#L20-L25) in sample-amazon-ecs-blue - green-deployment-patterns on. GitHub

# Risorse necessarie per le implementazioni di Amazon ECS blue/green
<a name="blue-green-deployment-implementation"></a>

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
<a name="blue-green-deployment-best-practices"></a>

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
<a name="alb-resources-for-blue-green"></a>

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
<a name="alb-target-groups"></a>

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
<a name="alb-load-balancer"></a>

È 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
<a name="alb-listeners"></a>

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
<a name="alb-service-configuration"></a>

È 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
<a name="alb-traffic-flow"></a>

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
<a name="nlb-resources-for-blue-green"></a>

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
<a name="nlb-target-groups"></a>

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
<a name="nlb-load-balancer"></a>

È 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
<a name="nlb-considerations"></a>

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
<a name="nlb-listeners"></a>

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
<a name="nlb-service-configuration"></a>

È 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
<a name="nlb-traffic-flow"></a>

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
<a name="service-connect-blue-green"></a>

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
<a name="service-connect-blue-green-architecture"></a>

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
<a name="service-connect-blue-green-traffic-routing"></a>

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
<a name="service-connect-test-traffic-header-rules"></a>

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
<a name="service-connect-header-match-rules"></a>

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
<a name="service-connect-client-alias-blue-green"></a>

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
<a name="service-connect-blue-green-best-practices"></a>

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
<a name="service-connect-blue-green-workflow"></a>

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
<a name="service-connect-deployment-phases"></a>

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
<a name="service-connect-proxy-behavior"></a>

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
<a name="service-connect-service-discovery-updates"></a>

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.

# Creazione di una distribuzione Amazon ECS blue/green
<a name="deploy-blue-green-service"></a>

 Utilizzando le blue/green distribuzioni di Amazon ECS, puoi apportare e testare modifiche ai servizi prima di implementarle in un ambiente di produzione. 

## Prerequisiti
<a name="deploy-blue-green-service-prerequisites"></a>

Esegui le seguenti operazioni prima di iniziare una distribuzione. blue/green 

1. Configurazione delle autorizzazioni appropriate.
   + Per informazioni sulle autorizzazioni di bilanciamento del carico elastico, consultare [Ruolo IAM dell'infrastruttura Amazon ECS per i bilanciatori del carico](AmazonECSInfrastructureRolePolicyForLoadBalancers.md).
   + Per informazioni sulle autorizzazioni Lambda, consultare [Autorizzazioni richieste per le funzioni Lambda nelle distribuzioni Amazon ECS blue/green](blue-green-permissions.md)

1.  blue/green Le implementazioni di Amazon ECS richiedono che il servizio utilizzi una delle seguenti funzionalità: Configura 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).

1. Decidi se vuoi eseguire le funzioni Lambda per le fasi del ciclo di vita.
   + PRE\$1SCALE\$1UP
   + POST\$1SCALE\$1UP
   + TEST\$1TRAFFIC\$1SHIFT
   + POST\$1TEST\$1TRAFFIC\$1SHIFT
   + PRODUCTION\$1TRAFFIC\$1SHIFT
   + POST\$1PRODUCTION\$1TRAFFIC\$1SHIFT

   Per ulteriori informazioni, consultare [Create a Lambda function with the console](https://docs.aws.amazon.com/lambda/latest/dg/getting-started.html#getting-started-create-function) nella *Guida per gli sviluppatori di AWS Lambda *.

## Procedura
<a name="deploy-blue-green-service-procedure"></a>

Puoi utilizzare la console o AWS CLI creare un blue/green servizio Amazon ECS.

------
#### [ Console ]

1. [Apri la console nella versione 2https://console.aws.amazon.com/ecs/.](https://console.aws.amazon.com/ecs/v2)

1. Determina la risorsa da cui avviare il servizio.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonECS/latest/developerguide/deploy-blue-green-service.html)

   Si apre la pagina **Crea servizio**.

1. In **Dettagli del servizio**, effettuare le seguenti operazioni:

   1. Per **Famiglia di definizione di attività**, scegliere la definizione di attività da utilizzare. Poi, per **Revisione della definizione di attività**, inserire la revisione da utilizzare.

   1. In **Nome servizio**, specificare un nome per il servizio.

1. Per eseguire il servizio in un cluster esistente, per **Cluster esistente**, scegliere il cluster. Per eseguire il servizio in un nuovo cluster, scegliere **Crea cluster** 

1. Scegliere come vengono distribuite le attività nell'infrastruttura cluster. In **Configurazione di calcolo**, scegliere l'opzione.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonECS/latest/developerguide/deploy-blue-green-service.html)

1. Nella sezione **Configurazione implementazione**, procedere come segue.

   1. Per **Tipo di servizio**, scegliere **Replica**.

   1. Per **Attività desiderate**, immettere il numero di attività da avviare e gestire nel servizio.

   1. Per consentire ad Amazon ECS di monitorare la distribuzione delle attività tra le zone di disponibilità e ridistribuirle in caso di squilibrio, in **Ribilanciamento del servizio delle zone di disponibilità**, selezionare **Ribilanciamento del servizio della zona di disponibilità**.

   1. Per **Periodo di tolleranza dei controlli di integrità**, inserire il periodo di tempo (in secondi) durante il quale il pianificatore di servizi ignora i controlli dell'integrità dei container, di bilanciamento dei carichi elastici e di VPC Lattice non integri dopo che è stata avviata un'attività. Se non si specifica un valore per il periodo di tolleranza per il controllo dell’integrità, viene utilizzato il valore predefinito di 0.

1. 

   1. Per **Tempo di incorporamento**, inserire il numero di minuti in cui entrambe le revisioni del servizio blu e verde verranno eseguite contemporaneamente prima che la revisione blu venga terminata. Ciò consente di avere tempo per la verifica e il test.

   1. (Facoltativo) Eseguire le funzioni Lambda in fasi specifiche dell'implementazione. In **Hook del ciclo di vita di implementazione**, selezionare le fasi per eseguire gli hook del ciclo di vita.

      Per aggiungere un hook del ciclo di vita:

      1. Scegliere **Aggiungi**.

      1. Per **Funzione Lambda**, immettere il nome della funzione o ARN.

      1. Per **Ruolo**, selezionare il ruolo IAM che ha il permesso di invocare la funzione Lambda.

      1. Per **Fasi del ciclo di vita**, selezionare le fasi in cui deve essere eseguita la funzione Lambda.

1. Per configurare il modo in cui Amazon ECS rileva e gestisce gli errori di implementazione, espandi **Deployment failure detection** (Rilevamento degli errori di implementazione), quindi scegli le tue opzioni. 

   1. Per interrompere un'implementazione quando le attività non possono essere avviate, seleziona **Use the Amazon ECS deployment circuit breaker** (Usa l'interruttore automatico di implementazione di Amazon ECS).

      Per fare in modo che il software ripristini automaticamente l'implementazione all'ultimo stato di implementazione completata quando l'interruttore automatico di implementazione imposta l'implementazione su uno stato di errore, selezionare **Rollback in caso di errore**.

   1. Per interrompere una distribuzione in base ai parametri dell'applicazione, seleziona **Usa CloudWatch allarmi.** Quindi, dal **nome CloudWatch dell'allarme**, scegli gli allarmi. Per creare un nuovo allarme, vai alla CloudWatch console.

      Per fare in modo che il software ripristini automaticamente la distribuzione all'ultimo stato di distribuzione completato quando un CloudWatch allarme imposta la distribuzione **su uno stato fallito, seleziona Rollback in caso** di errori.

1. (Facoltativo) Per connettere il servizio usando Service Connect, espandere **Service Connect**, quindi specificare quanto segue:

   1.  Selezionare **Attiva Service Connect**.

   1. In **Service Connect configuration** (Configurazione Service Connect), specifica la modalità client.
      + Se il servizio esegue un'applicazione client di rete che deve connettersi solo ad altri servizi nel namespace, scegliere **Solo lato client**.
      + Se il servizio esegue un'applicazione di rete o di servizio Web, deve fornire endpoint per questo servizio e si connette ad altri servizi nel namespace, scegliere **Client e server**.

   1. Per utilizzare un namespace differente da quello del cluster predefinito, per **Namespace**, scegliere il namespace del servizio. Può trattarsi di uno spazio dei nomi creato separatamente Regione AWS nello stesso spazio dell'utente Account AWS o di uno spazio dei nomi nella stessa regione condiviso con il proprio account utilizzando (). AWS Resource Access Manager AWS RAM*Per ulteriori informazioni sugli spazi dei AWS Cloud Map nomi condivisi, consulta Condivisione dello spazio dei nomi [tra AWS Cloud Map](https://docs.aws.amazon.com/cloud-map/latest/dg/sharing-namespaces.html) account nella Guida per gli sviluppatori.AWS Cloud Map *

   1. (Facoltativo) Configura le regole di test traffic header per le distribuzioni. blue/green In **Instradamento del traffico di test**, specificare quanto segue:

      1. Selezionare **Abilita le regole di intestazione del traffico di test** per instradare richieste specifiche alla revisione del servizio verde durante il test.

      1. Per **Regole di corrispondenza di intestazione**, configurare i criteri per l'instradamento del traffico di test:
         + **Nome dell'intestazione**: inserire il nome dell'intestazione HTTP per la corrispondenza (ad esempio, `X-Test-Version` o `User-Agent`).
         + **Tipo di corrispondenza**: scegliere i criteri di corrispondenza:
           + **Corrispondenza esatta**: richieste di instradamento in cui il valore dell'intestazione corrisponde esattamente al valore specificato
           + **Intestazione presente**: richieste di instradamento che contengono l'intestazione specificata, indipendentemente dal valore
           + **Corrispondenza di schema**: richieste di instradamento in cui il valore dell'intestazione corrisponde a uno schema specificato
         + **Valore dell'intestazione** (se si utilizza la corrispondenza esatta o la corrispondenza di schema): inserire il valore o lo schema a cui far corrispondere l'intestazione.

         È possibile aggiungere più regole di corrispondenza dell'intestazione per creare una logica di instradamento complessa. Le richieste che corrispondono a una qualsiasi delle regole configurate verranno instradate alla revisione del servizio verde per essere testate.

      1. Scegliere **Aggiungi regola di intestazione** per configurare condizioni aggiuntive di corrispondenza dell'intestazione.
**Nota**  
Le regole di intestazione del traffico di test consentono di convalidare nuove funzionalità con traffico controllato prima di portare a termine l'implementazione completa. Ciò consente di testare la revisione del servizio verde con richieste specifiche (come quelle provenienti da strumenti di test interni o utenti beta) mantenendo al contempo il normale flusso di traffico verso la revisione del servizio blu.

   1. (Facoltativo) Specificare una configurazione del log. Selezionare **Usa la raccolta di log**. L'opzione predefinita invia i log dei contenitori a Logs. CloudWatch Le altre opzioni del driver di registro sono configurate utilizzando. AWS FireLens Per ulteriori informazioni, consulta [Inviare i log di Amazon ECS a un servizio o AWS AWS Partner](using_firelens.md).

      Di seguito sono riportate descrizioni più dettagliate per ogni destinazione di log di container.
      + **Amazon CloudWatch**: configura l'attività per inviare i log dei container a CloudWatch Logs. Vengono fornite le opzioni predefinite dei driver di registro, che creano un gruppo di CloudWatch log per tuo conto. Per specificare un nome del gruppo di log diverso, modifica i valori dell'opzione del driver.
      + **Amazon Data Firehose**: configura l'attività per inviare i log del container a Firehose. Vengono fornite le opzioni di driver di log predefinite che inviano i log a un flusso di consegna Firehose. Per specificare un nome del flusso di consegna diverso, modifica i valori dell'opzione del driver.
      + **Flusso di dati Amazon Kinesis**: configura il processo per inviare log di container a Kinesis Data Streams. Vengono fornite le opzioni di driver di log predefinite che inviano i log a un flusso di consegna Kinesis Data Streams. Per specificare un nome del flusso diverso, modifica i valori dell'opzione del driver.
      + **Amazon OpenSearch Service**: configura l'attività per inviare i log dei container a un dominio OpenSearch di servizio. Devono essere fornite le opzioni del driver di log. 
      + **Amazon S3**: configura l'attività per inviare log di container a un bucket Amazon S3. Vengono fornite le opzioni del driver di log predefinito, ma è necessario specificare un nome del bucket Amazon S3 valido.

1. (Facoltativo) Configurare il **Bilanciamento del carico** per l'implementazione blu/verde.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonECS/latest/developerguide/deploy-blue-green-service.html)

1. (Facoltativo) Per identificare il servizio e le attività, espandi la sezione **Tags** (Tag), quindi configura i tag.

   Per fare in modo che Amazon ECS contrassegni automaticamente tutte le attività appena avviate con il nome del cluster e i tag di definizione delle attività, seleziona **Attiva i tag gestiti di Amazon ECS**, quindi in **Propaga i tag da**, scegli **Definizioni di attività**.

   Per fare in modo che Amazon ECS contrassegni automaticamente tutte le attività appena avviate con il nome del cluster e i tag del servizio, seleziona **Attiva i tag gestiti di Amazon ECS**, quindi in **Propaga i tag da**, scegli **Servizio**.

   Aggiungi o rimuovi un tag.
   + [Aggiungi un tag] Scegli **Add tag** (Aggiungi tag), quindi effettuare le seguenti operazioni:
     + In **Chiave**, immetti il nome della chiave.
     + In **Valore**, immetti il valore della chiave.
   + [Rimuovere un tag] Accanto al tag, scegliere **Remove tag (Rimuovi tag)**.

1. Scegli **Create** (Crea).

------
#### [ AWS CLI ]

1. Crea un archivio denominato `service-definition.json` con i seguenti contenuti.

   Sostituiscili con i tuoi valori. *user-input*

   ```
   {
     "serviceName": "myBlueGreenService",
     "cluster": "arn:aws:ecs:us-west-2:123456789012:cluster/sample-fargate-cluster",
     "taskDefinition": "sample-fargate:1",
     "desiredCount": 5,
     "launchType": "FARGATE",
     "networkConfiguration": {
       "awsvpcConfiguration": {
         "subnets": [
           "subnet-09ce6e74c116a2299",
           "subnet-00bb3bd7a73526788",
           "subnet-0048a611aaec65477"
         ],
         "securityGroups": [
           "sg-09d45005497daa123"
         ],
         "assignPublicIp": "ENABLED"
       }
     },
     "deploymentController": {
       "type": "ECS"
     },
     "deploymentConfiguration": {
       "strategy": "BLUE_GREEN",
       "maximumPercent": 200,
       "minimumHealthyPercent": 100,
       "bakeTimeInMinutes": 2,
       "alarms": {
         "alarmNames": [
           "myAlarm"
         ],
         "rollback": true,
         "enable": true
       },
       "lifecycleHooks": [
         {
           "hookTargetArn": "arn:aws:lambda:us-west-2:7123456789012:function:checkExample",
           "roleArn": "arn:aws:iam::123456789012:role/ECSLifecycleHookInvoke",
           "lifecycleStages": [
             "PRE_SCALE_UP"
           ]
         }
       ]
     },
     "loadBalancers": [
       {
         "targetGroupArn": "arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/blue-target-group/54402ff563af1197",
         "containerName": "fargate-app",
         "containerPort": 80,
         "advancedConfiguration": {
           "alternateTargetGroupArn": "arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/green-target-group/cad10a56f5843199",
           "productionListenerRule": "arn:aws:elasticloadbalancing:us-west-2:123456789012:listener-rule/app/my-blue-green-demo/32e0e4f946c3c05b/9cfa8c482e204f7d/831dbaf72edb911",
           "roleArn": "arn:aws:iam::123456789012:role/LoadBalancerManagementforECS"
         }
       }
     ]
   }
   ```

1. Esegui `create-service`.

   *user-input*Sostituiscili con i tuoi valori.

   ```
   aws ecs create-service --cli-input-json file://service-definition.json
   ```

   In alternativa, puoi utilizzare il seguente esempio che crea un servizio di blue/green distribuzione con una configurazione di bilanciamento del carico:

   ```
   aws ecs create-service \
      --cluster "arn:aws:ecs:us-west-2:123456789012:cluster/MyCluster" \
      --service-name "blue-green-example-service" \
      --task-definition "nginxServer:1" \
      --launch-type "FARGATE" \
      --network-configuration "awsvpcConfiguration={subnets=[subnet-12345,subnet-67890,subnet-abcdef,subnet-fedcba],securityGroups=[sg-12345],assignPublicIp=ENABLED}" \
      --desired-count 3 \
      --deployment-controller "type=ECS" \
      --deployment-configuration "strategy=BLUE_GREEN,maximumPercent=200,minimumHealthyPercent=100,bakeTimeInMinutes=0" \
      --load-balancers "targetGroupArn=arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/MyBGtg1/abcdef1234567890,containerName=nginx,containerPort=80,advancedConfiguration={alternateTargetGroupArn=arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/MyBGtg2/0987654321fedcba,productionListenerRule=arn:aws:elasticloadbalancing:us-west-2:123456789012:listener-rule/app/MyLB/1234567890abcdef/1234567890abcdef,roleArn=arn:aws:iam::123456789012:role/ELBManagementRole}"
   ```

------

## Fasi successive
<a name="deploy-blue-green-service-next-steps"></a>
+ Aggiornare il servizio per avviare l'implementazione. Per ulteriori informazioni, consulta [Aggiornamento di un servizio Amazon ECS](update-service-console-v2.md).
+ Monitora il processo di distribuzione per assicurarti che segua lo blue/green schema:
  + La revisione del servizio verde viene creata e aumentata verticalmente
  + Il traffico di test viene instradato alla revisione verde (se configurata)
  + Il traffico di produzione viene spostato alla revisione del servizio verde
  + Dopo il tempo di incorporamento, la revisione blu viene interrotta

# Risoluzione dei problemi relativi alle implementazioni di Amazon ECS blue/green
<a name="troubleshooting-blue-green"></a>

Di seguito vengono fornite soluzioni per problemi comuni che potresti riscontrare durante l'utilizzo di blue/green distribuzioni con Amazon ECS. Blue/green gli errori di distribuzione possono verificarsi durante le seguenti fasi:
+ *Percorso sincrono*: errori che appaiono immediatamente in risposta a chiamate API `CreateService` o `UpdateService`.
+ *Percorso asincrono*: errori che appaiono nel campo `statusReason` di `DescribeServiceDeployments` e causano un rollback dell'implementazione

**Suggerimento**  
Puoi utilizzarlo [Server MCP Amazon ECS](ecs-mcp-introduction.md) con gli assistenti AI per monitorare le implementazioni e risolvere i problemi di implementazione utilizzando il linguaggio naturale.

## Problemi di configurazione del bilanciatore del carico
<a name="troubleshooting-blue-green-load-balancer"></a>

La configurazione del bilanciamento del carico è un componente fondamentale delle blue/green distribuzioni in Amazon ECS. La corretta configurazione delle regole dei listener, dei gruppi di destinazione e dei tipi di bilanciatore del carico è essenziale per implementazioni di successo. Questa sezione tratta i problemi comuni di configurazione del load balancer che possono causare il fallimento delle distribuzioni. blue/green 

Quando si risolvono i problemi relativi al bilanciatore del carico, è importante comprendere la relazione tra le regole dei listener e i gruppi di destinazione. In una distribuzione: blue/green 
+ La regola del listener di produzione indirizza il traffico verso la revisione del servizio attualmente attiva (blu)
+ La regola del listener di test può essere utilizzata per convalidare la nuova revisione del servizio (verde) prima di spostare il traffico di produzione
+ I gruppi di destinazione vengono utilizzati per registrare le istanze di container di ogni revisione del servizio
+ Durante l'implementazione, il traffico viene gradualmente spostato dalla revisione del servizio blu alla revisione del servizio verde modificando i pesi dei gruppi di destinazione nelle regole del listener

### Errori di configurazione delle regole del listener
<a name="troubleshooting-blue-green-listener-rules"></a>

I seguenti problemi riguardano la configurazione errata delle regole del listener per le blue/green distribuzioni.

Utilizzo di un ARN del listener di Application Load Balancer anziché di uno della regola del listener  
*Messaggio di errore*: `productionListenerRule has an invalid ARN format. Must be RuleArn for ALB or ListenerArn for NLB. Got: arn:aws:elasticloadbalancing:us-west-2:123456789012:listener/app/my-alb/abc123/def456`  
*Soluzione*: quando si utilizza un Application Load Balancer, è necessario specificare un ARN della regola del listener per `productionListenerRule` e `testListenerRule`, non un ARN del listener. Per i Network Load Balancer, è necessario utilizzare l'ARN del listener.  
 Per informazioni su come trova l'ARN del listener, consultare [Listener per Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-https-listener.html) nella *Guida per l'utente di Application Load Balancer*. L'ARN per una regola ha il formato `arn:aws:elasticloadbalancing:region:account-id:listener-rule/app/...`.

Utilizzo della stessa regola per i listener di test e di produzione  
*Messaggio di errore*: `The following rules cannot be used as both production and test listener rules: arn:aws:elasticloadbalancing:us-west-2:123456789012:listener-rule/app/my-alb/abc123/def456/ghi789`  
*Soluzione*: è necessario utilizzare regole di listener diverse per il traffico di produzione e quello di test. Creazione di una regola separata del listener per il traffico di test che instrada verso il gruppo di destinazione del test.

Gruppo di destinazione non associato alle regole del listener  
*Messaggio di errore*: `Service deployment rolled back because of invalid networking configuration: Target group arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/myAlternateTG/abc123 is not associated with either productionListenerRule or testListenerRule.`  
*Soluzione*: sia il gruppo di destinazione principale che il gruppo di destinazione alternativo devono essere associati alla regola del listener di produzione o alla regola del listener di test. Aggiornare la configurazione del bilanciatore del carico per assicurarsi che entrambi i gruppi di destinazione siano associati correttamente alle regole del listener.

Regola del listener di test mancante con un Application Load Balancer  
*Messaggio di errore*: `For Application LoadBalancer, testListenerRule is required when productionListenerRule is not associated with both targetGroup and alternateTargetGroup`  
*Soluzione*: quando si utilizza un Application Load Balancer, se entrambi i gruppi di destinazione non sono associati alla regola del listener di produzione, è necessario specificare una regola del listener di test. Aggiungere una `testListenerRule` alla configurazione e assicurarsi che entrambi i gruppi di destinazione siano associati alla regola del listener di produzione o di test. Per ulteriori informazioni, consultare [Listeners for your Application Load Balancers](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-https-listener.html) nella *Guida per l'utente di Application Load Balancer*.

### Errori di configurazione dei gruppi di destinazione
<a name="troubleshooting-blue-green-target-groups"></a>

I seguenti problemi si riferiscono alla configurazione errata del gruppo target per le distribuzioni. blue/green 

Gruppi di destinazione multipli con traffico nella regola del listener  
*Messaggio di errore*: `Service deployment rolled back because of invalid networking configuration. productionListenerRule arn:aws:elasticloadbalancing:us-west-2:123456789012:listener-rule/app/my-alb/abc123/def456/ghi789 should have exactly one target group serving traffic but found 2 target groups which are serving traffic`  
*Soluzione*: prima di iniziare una blue/green distribuzione, assicurati che solo un gruppo target riceva traffico (con un peso diverso da zero) secondo la regola del listener. Aggiornare la configurazione della regola del listener per impostare il peso su zero per qualsiasi gruppo di destinazione che non dovrebbe ricevere traffico.

Duplicare i gruppi di destinazione tra le voci del bilanciatore del carico  
*Messaggio di errore*: `Duplicate targetGroupArn found: arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/myecs-targetgroup/abc123`  
*Soluzione*: ogni ARN del gruppo di destinazione deve essere univoco per tutte le voci del bilanciatore del carico nella definizione del servizio. Rivedere la configurazione e assicurarsi di utilizzare gruppi di destinazione diversi per ogni voce del bilanciatore del carico.

Gruppo di destinazione imprevisto nella regola del listener di produzione  
*Messaggio di errore*: `Service deployment rolled back because of invalid networking configuration. Production listener rule is forwarding traffic to unexpected target group arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/random-nlb-tg/abc123. Expected traffic to be forwarded to either targetGroupArn: arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/nlb-targetgroup/def456 or alternateTargetGroupArn: arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/nlb-tg-alternate/ghi789`  
*Soluzione*: la regola del listener di produzione inoltra il traffico a un gruppo di destinazione non specificato nella definizione del servizio. Assicurarsi che la regola del listener sia configurata per inoltrare il traffico solo ai gruppi di destinazione specificati nella definizione del servizio.   
Per ulteriori informazioni, consultare [forward actions](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-listeners.html#forward-actions) nella *Guida per l'utente per Application Load Balancer*.

### Errori di configurazione del tipo di bilanciatore del carico
<a name="troubleshooting-blue-green-load-balancer-types"></a>

I seguenti problemi riguardano una configurazione errata del tipo di sistema di bilanciamento del carico per le distribuzioni. blue/green 

Combinare configurazioni di Classic Load Balancer, Application Load Balancer o Network Load Balancer.  
*Messaggio di errore*: `All loadBalancers must be strictly either ELBv1 (defining loadBalancerName) or ELBv2 (defining targetGroupArn)`  
I Classic Load Balancer sono la generazione precedente di bilanciatori del carico dal bilanciamento del carico elastico. Consigliamo di eseguire la migrazione a un bilanciatore del carico di generazione attuale. Per ulteriori informazioni, consultare [Migrate your Classic Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/migrate-classic-load-balancer.html).
*Soluzione:.* Utilizzare tutti Classic Load Balancer o tutti Application Load Balancer e Network Load Balancer.  
Per Application Load Balancer e Network Load Balancer, specificare solo il campo `targetGroupArn`.

Utilizzo della configurazione avanzata con un Classic Load Balancer  
*Messaggio di errore*: `advancedConfiguration field is not allowed with ELBv1 loadBalancers`  
*Soluzione: la* configurazione avanzata per le blue/green implementazioni è supportata solo con Application Load Balancer e Network Load Balancer. Se si utilizza un Classic Load Balancer (specificato con `loadBalancerName`), non è possibile utilizzare il campo `advancedConfiguration`. Passare a un Application Load Balancer o rimuovere il campo `advancedConfiguration`.

Configurazione avanzata incoerente tra i bilanciatori del carico  
*Messaggio di errore*: `Either all or none of the provided loadBalancers must have advancedConfiguration defined`  
*Soluzione*: se si utilizzano più bilanciatori del carico, è necessario definire `advancedConfiguration` per tutti o nessuno. Aggiornare la configurazione per garantire la coerenza tra tutte le voci del bilanciatore del carico.

Manca blue/green la configurazione avanzata con distribuzione  
*Messaggio di errore*: `advancedConfiguration field is required for all loadBalancers when using a non-ROLLING deployment strategy`  
*Soluzione*: quando si utilizza una strategia di blue/green distribuzione con Application Load Balancers, è necessario specificare il `advancedConfiguration` campo per tutte le voci relative al load balancer. Aggiungere la necessaria `advancedConfiguration` alla configurazione del bilanciatore del carico.

## Problemi a livello di autorizzazioni
<a name="troubleshooting-blue-green-permissions"></a>

I seguenti problemi riguardano le autorizzazioni insufficienti per le distribuzioni. blue/green 

Policy di attendibilità mancante sul ruolo dell'infrastruttura  
*Messaggio di errore*: `Service deployment rolled back because of invalid networking configuration. ECS was unable to manage the ELB resources due to missing permissions on ECS Infrastructure Role 'arn:aws:iam::123456789012:role/Admin'.`  
*Soluzione*: il ruolo IAM specificato per la gestione delle risorse del bilanciatore del carico non dispone della policy di attendibilità corretta. Aggiornare la policy di attendibilità del ruolo per consentire al servizio di assumere tale ruolo. La policy di attendibilità deve includere:    
****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "ecs.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}
```

Autorizzazioni di lettura mancanti per il ruolo di bilanciatore del carico  
*Messaggio di errore*: `service myService failed to describe target health on target-group myTargetGroup with (error User: arn:aws:sts::123456789012:assumed-role/myELBRole/ecs-service-scheduler is not authorized to perform: elasticloadbalancing:DescribeTargetHealth because no identity-based policy allows the elasticloadbalancing:DescribeTargetHealth action)`  
*Soluzione*: il ruolo IAM utilizzato per la gestione delle risorse del bilanciatore del carico non è autorizzato a leggere le informazioni di integrità della destinazione. Aggiungere l'autorizzazione `elasticloadbalancing:DescribeTargetHealth` alla policy del ruolo. Per informazioni sulle autorizzazioni di bilanciamento del carico elastico, consultare [Ruolo IAM dell'infrastruttura Amazon ECS per i bilanciatori del carico](AmazonECSInfrastructureRolePolicyForLoadBalancers.md).

Autorizzazioni di scrittura mancanti sul ruolo di bilanciatore del carico  
*Messaggio di errore*: `service myService failed to register targets in target-group myTargetGroup with (error User: arn:aws:sts::123456789012:assumed-role/myELBRole/ecs-service-scheduler is not authorized to perform: elasticloadbalancing:RegisterTargets on resource: arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/myTargetGroup/abc123 because no identity-based policy allows the elasticloadbalancing:RegisterTargets action)`  
*Soluzione*: il ruolo IAM utilizzato per la gestione delle risorse del bilanciatore del carico non dispone dell'autorizzazione per registrare le destinazioni. Aggiungere l'autorizzazione `elasticloadbalancing:RegisterTargets` alla policy del ruolo. Per informazioni sulle autorizzazioni di bilanciamento del carico elastico, consultare [Ruolo IAM dell'infrastruttura Amazon ECS per i bilanciatori del carico](AmazonECSInfrastructureRolePolicyForLoadBalancers.md).

Autorizzazione mancante per modificare le regole del listener  
*Messaggio di errore*: `Service deployment rolled back because TEST_TRAFFIC_SHIFT lifecycle hook(s) failed. User: arn:aws:sts::123456789012:assumed-role/myELBRole/ECSNetworkingWithELB is not authorized to perform: elasticloadbalancing:ModifyListener on resource: arn:aws:elasticloadbalancing:us-west-2:123456789012:listener/app/my-alb/abc123/def456 because no identity-based policy allows the elasticloadbalancing:ModifyListener action`  
*Soluzione*: il ruolo IAM utilizzato per la gestione delle risorse del bilanciatore del carico non dispone dell'autorizzazione per modificare i listener. Aggiungere l'autorizzazione `elasticloadbalancing:ModifyListener` alla policy del ruolo. Per informazioni sulle autorizzazioni di bilanciamento del carico elastico, consultare [Ruolo IAM dell'infrastruttura Amazon ECS per i bilanciatori del carico](AmazonECSInfrastructureRolePolicyForLoadBalancers.md).

Per le blue/green distribuzioni, si consiglia di allegare la policy `AmazonECS-ServiceLinkedRolePolicy` gestita al proprio ruolo di infrastruttura, che include tutte le autorizzazioni necessarie per la gestione delle risorse di bilanciamento del carico.

## Problemi relativi agli hook del ciclo di vita
<a name="troubleshooting-blue-green-lifecycle-hooks"></a>

I seguenti problemi riguardano gli agganci del ciclo di vita nelle distribuzioni. blue/green 

Policy di attendibilità errata sul ruolo degli hook di Lambda  
*Messaggio di errore*: `Service deployment rolled back because TEST_TRAFFIC_SHIFT lifecycle hook(s) failed. ECS was unable to assume role arn:aws:iam::123456789012:role/Admin`  
*Soluzione*: il ruolo IAM specificato per l'hook del ciclo di vita di Lambda non dispone della policy di attendibilità corretta. Aggiornare la policy di attendibilità del ruolo per consentire al servizio di assumerlo. La policy di attendibilità deve includere:    
****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "ecs.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}
```

L'hook di Lambda restituisce lo stato FAILED  
*Messaggio di errore*: `Service deployment rolled back because TEST_TRAFFIC_SHIFT lifecycle hook(s) failed. Lifecycle hook target arn:aws:lambda:us-west-2:123456789012:function:myHook returned FAILED status.`  
*Soluzione*: la funzione Lambda specificata come hook del ciclo di vita ha restituito lo stato FAILED. Controlla i log delle funzioni Lambda nei log di Amazon CloudWatch per determinare il motivo dell'errore e aggiorna la funzione per gestire correttamente l'evento di distribuzione.

Autorizzazione mancante per invocare la funzione Lambda  
*Messaggio di errore*: `Service deployment rolled back because TEST_TRAFFIC_SHIFT lifecycle hook(s) failed. ECS was unable to invoke hook target arn:aws:lambda:us-west-2:123456789012:function:myHook due to User: arn:aws:sts::123456789012:assumed-role/myLambdaRole/ECS-Lambda-Execution is not authorized to perform: lambda:InvokeFunction on resource: arn:aws:lambda:us-west-2:123456789012:function:myHook because no identity-based policy allows the lambda:InvokeFunction action`  
*Soluzione*: il ruolo IAM utilizzato per l'hook del ciclo di vita di Lambda non dispone dell'autorizzazione per invocare la funzione Lambda. Aggiungere l'autorizzazione `lambda:InvokeFunction` alla policy del ruolo per l'ARN della funzione Lambda specifica. Per informazioni sulle autorizzazioni Lambda, consultare [Autorizzazioni richieste per le funzioni Lambda nelle distribuzioni Amazon ECS blue/green](blue-green-permissions.md).

Timeout della funzione Lambda o risposta non valida  
*Messaggio di errore*: `Service deployment rolled back because TEST_TRAFFIC_SHIFT lifecycle hook(s) failed. ECS was unable to parse the response from arn:aws:lambda:us-west-2:123456789012:function:myHook due to HookStatus must not be null`  
*Soluzione*: la funzione Lambda è scaduta o ha restituito una risposta non valida. Assicurarsi che la funzione Lambda restituisca una risposta valida con un campo `hookStatus` impostato su `SUCCEEDED` o `FAILED`. Inoltre, verificare che il timeout della funzione Lambda sia impostato in modo appropriato per la logica di convalida. Per ulteriori informazioni, consultare [Hook del ciclo di vita per le implementazioni di servizi Amazon ECS](deployment-lifecycle-hooks.md).  
Esempio di una risposta Lambda valida:  

```
{
  "hookStatus": "SUCCEEDED",
  "reason": "Validation passed"
}
```

# Implementazioni lineari di Amazon ECS
<a name="deployment-type-linear"></a>

Le implementazioni lineari spostano gradualmente il traffico dalla revisione precedente del servizio a quella nuova con incrementi uguali nel tempo, consentendoti di monitorare ogni passaggio prima di passare a quello successivo. Con le implementazioni lineari di Amazon ECS, controlla il ritmo dello spostamento del traffico e convalida nuove revisioni dei servizi con quantità crescenti di traffico di produzione. Questo approccio offre un modo controllato per implementare le modifiche con la possibilità di monitorare le prestazioni ad ogni incremento.

## Risorse coinvolte in una distribuzione lineare
<a name="linear-deployment-resources"></a>

Le seguenti sono le risorse coinvolte nelle distribuzioni lineari di Amazon ECS:
+ Spostamento del traffico: il processo utilizzato da Amazon ECS per spostare il traffico di produzione. Per le implementazioni lineari di Amazon ECS, il traffico viene spostato in incrementi percentuali uguali con tempi di attesa configurabili tra ogni incremento.
+ Percentuale: la percentuale di traffico da spostare in ogni incremento durante un'implementazione lineare. Questo campo utilizza Double come valore e i valori validi sono compresi tra 3,0 e 100,0.
+ Step Bake Time: la durata di attesa tra un incremento di traffico e l'altro durante una distribuzione lineare. I valori validi sono compresi tra 0 e 1440 minuti.
+ Tempo di attesa dell'implementazione: il tempo, in minuti, che Amazon ECS attende dopo aver spostato tutto il traffico di produzione alla nuova revisione del servizio, prima di terminare la vecchia revisione del servizio. Si tratta del periodo in cui le revisioni blu e verde del servizio vengono eseguite contemporaneamente dopo lo spostamento del traffico di produzione.
+ Fasi del ciclo di vita: una serie di eventi nell'operazione di implementazione, ad esempio “dopo lo spostamento del traffico di produzione”.
+ Lifecycle hook: una funzione Lambda che viene eseguita in una fase specifica del ciclo di vita. È possibile creare una funzione che verifichi la distribuzione. Le funzioni Lambda o gli hook del ciclo di vita configurati per PRODUCTION\$1TRAFFIC\$1SHIFT verranno richiamati in ogni fase del trasferimento del traffico di produzione.
+ Gruppo di destinazione: una risorsa di bilanciamento del carico elastico utilizzata per indirizzare le richieste verso una o più destinazioni registrate (ad esempio, istanze EC2). Quando si crea un listener, si specifica un gruppo di destinazione per l'operazione predefinita. Il traffico viene inoltrato al gruppo di destinazione specificato nella regola del listener.
+ Listener: una risorsa di bilanciamento del carico elastico che controlla le richieste di connessione utilizzando il protocollo e la porta configurata. Le regole definite per un listener determinano il modo in cui Amazon ECS instrada le richieste alle destinazioni registrate.
+ Regola: una risorsa di bilanciamento del carico elastico associata a un listener. Una regola definisce il modo in cui le richieste vengono instradate e consiste in un'azione, una condizione e una priorità.

## Considerazioni
<a name="linear-deployment-considerations"></a>

Si tenga in considerazione quanto segue quando si sceglie un tipo di implementazione:
+ Utilizzo delle risorse: le distribuzioni lineari eseguono temporaneamente le revisioni del servizio blu e verde contemporaneamente, il che può raddoppiare l'utilizzo delle risorse durante le distribuzioni.
+ Monitoraggio dell'implementazione: le implementazioni lineari forniscono informazioni dettagliate sullo stato dell'implementazione, consentendoti di monitorare ogni fase del processo di implementazione e ogni incremento del traffico.
+ Rollback: le implementazioni lineari semplificano il ripristino alla versione precedente se vengono rilevati problemi, poiché la revisione blu viene mantenuta attiva fino alla scadenza del tempo di cottura.
+ Convalida graduale: le implementazioni lineari consentono di convalidare la nuova revisione con quantità crescenti di traffico di produzione, offrendo maggiore fiducia nell'implementazione.
+ Durata dell'implementazione: le implementazioni lineari richiedono più tempo per essere completate rispetto alle implementazioni a causa dello spostamento incrementale del all-at-once traffico e dei tempi di attesa tra le fasi.

## Come funziona l'implementazione lineare
<a name="linear-deployment-how-works"></a>

Il processo di distribuzione lineare di Amazon ECS segue un approccio strutturato con sei fasi distinte che garantiscono aggiornamenti delle applicazioni sicuri e affidabili. Ogni fase ha uno scopo specifico nella convalida e nella transizione dell'applicazione dalla versione attuale (blu) alla nuova versione (verde).

1. Fase di preparazione: creare l'ambiente verde insieme a quello blu esistente.

1. Fase di implementazione: implementazione della nuova revisione del servizio nell'ambiente verde. Amazon ECS avvia nuove attività utilizzando la revisione aggiornata del servizio mentre l'ambiente blu continua a servire il traffico di produzione.

1. Fase di test: convalida dell'ambiente verde utilizzando l'instradamento del traffico di test. L'Application Load Balancer indirizza le richieste di test verso l'ambiente verde mentre il traffico di produzione rimane sul blu.

1. Fase di spostamento lineare del traffico: sposta gradualmente il traffico di produzione dal blu al verde con incrementi percentuali uguali in base alla strategia di distribuzione configurata.

1. Fase di monitoraggio: monitoraggio dello stato delle applicazioni, delle metriche delle prestazioni e degli stati di allarme durante il periodo di tempo di incorporamento. Quando vengono rilevati problemi, viene avviata un'operazione di rollback.

1. Fase di completamento: finalizza l'implementazione chiudendo l'ambiente blu.

La fase di spostamento lineare del traffico segue le seguenti fasi:
+ Iniziale: l'implementazione inizia con il 100% del traffico indirizzato alla revisione blu (attuale) del servizio. La (nuova) revisione del servizio verde riceve traffico di prova ma inizialmente nessun traffico di produzione.
+ Spostamento incrementale del traffico: il traffico viene gradualmente spostato dal blu al verde con incrementi percentuali uguali. Ad esempio, con una configurazione a gradini del 10,0%, gli spostamenti del traffico si verificano come segue:
  + Fase 1: dal 10,0% al verde, al 90,0% al blu
  + Fase 2:20,0% verso il verde, 80,0% verso il blu
  + Fase 3:30,0% verso il verde, 70,0% verso il blu
  + E così via fino a quando il 100% raggiunge il verde
+ Step Bake Time: tra ogni incremento del traffico, l'implementazione attende una durata configurabile (step bake time) per consentire il monitoraggio e la convalida delle prestazioni della nuova revisione con l'aumento del carico di traffico. Tieni presente che il tempo di cottura dell'ultimo passaggio viene saltato quando il traffico viene spostato del 100,0%.
+ Lifecycle Hook: le funzioni Lambda opzionali possono essere eseguite in varie fasi del ciclo di vita durante l'implementazione per eseguire convalida, monitoraggio o logica personalizzata automatizzati. Le funzioni Lambda o gli hook del ciclo di vita configurati per PRODUCTION\$1TRAFFIC\$1SHIFT verranno richiamati in ogni fase del trasferimento del traffico di produzione.

## Fasi del ciclo di vita dell'implementazione
<a name="linear-deployment-lifecycle-stages"></a>

Il processo di implementazione lineare procede attraverso fasi distinte del ciclo di vita, ognuna con responsabilità e punti di controllo di convalida specifici. La comprensione di queste fasi consente di monitorare l'avanzamento dell'implementazione e risolvere i problemi in modo efficace.

Ogni fase del ciclo di vita può durare fino a 24 ore e inoltre ogni fase di spostamento del traffico in PRODUCTION\$1TRAFFIC\$1SHIFT può durare fino a 24 ore. Si consiglia di mantenere il valore al di sotto della soglia delle 24 ore. Questo perché i processi asincroni richiedono tempo per attivare gli hook. Il sistema scade, fallisce l'implementazione e quindi avvia un rollback dopo che una fase raggiunge le 24 ore.

CloudFormation le distribuzioni hanno restrizioni di timeout aggiuntive. Sebbene il limite delle fasi di 24 ore rimanga in vigore, CloudFormation impone un limite di 36 ore all'intera implementazione. CloudFormation fallisce l'implementazione e quindi avvia un rollback se il processo non viene completato entro 36 ore.


| Fasi del ciclo di vita | Description | Supporto per Lifecycle Hook | 
| --- | --- | --- | 
| RECONCILE\$1SERVICE | Questa fase si verifica solo quando si avvia una nuova implementazione del servizio con più di 1 revisione del servizio in uno stato ACTIVE. | Sì | 
| PRE\$1SCALE\$1UP | La revisione del servizio verde non è stata avviata. La revisione del servizio blu gestisce il 100% del traffico di produzione. Non è previsto alcun traffico di test. | Sì | 
| SCALE\$1UP | Il momento in cui la revisione del servizio verde aumenta fino al 100% e avvia nuove attività. La revisione del servizio verde non serve alcun traffico a questo punto. | No | 
| POST\$1SCALE\$1UP | La revisione del servizio verde è stata avviata. La revisione del servizio blu gestisce il 100% del traffico di produzione. Non è previsto alcun traffico di test. | Sì | 
| TEST\$1TRAFFIC\$1SHIFT | Le revisioni del servizio blu e verde sono in esecuzione. La revisione del servizio blu gestisce il 100% del traffico di produzione. La revisione del servizio verde migra dallo 0% al 100% del traffico di test. | Sì | 
| POST\$1TEST\$1TRAFFIC\$1SHIFT | Lo spostamento del traffico di test è completo. La revisione del servizio verde gestisce il 100% del traffico di test. | Sì | 
| PRODUCTION\$1TRAFFIC\$1SHIFT | Il traffico viene gradualmente spostato dal blu al verde con incrementi percentuali uguali fino a quando il verde riceve il 100% del traffico. Ogni spostamento del traffico richiama il lifecycle hook con un timeout di 24 ore. | 
| POST\$1PRODUCTION\$1TRAFFIC\$1SHIFT | Lo spostamento del traffico di produzione è completo. | Sì | 
| BAKE\$1TIME | La durata in cui le revisioni del servizio blu e verde vengono eseguite contemporaneamente. | No | 
| CLEAN\$1UP | La revisione del servizio blu è stata completamente ridotta a 0 attività in esecuzione. La revisione del servizio verde è ora la revisione del servizio di produzione dopo questa fase. | No | 

# Risorse richieste per le implementazioni lineari di Amazon ECS
<a name="linear-deployment-implementation"></a>

Per utilizzare una distribuzione lineare con spostamento del traffico gestito, il servizio deve utilizzare una delle seguenti funzionalità:
+ Elastic Load Balancing
+ Service Connect

L'elenco seguente fornisce una panoramica di alto livello di ciò che è necessario configurare per le distribuzioni lineari di Amazon ECS:
+ 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 `linear` nella definizione del servizio.
+ Facoltativamente, configurare parametri aggiuntivi come:
  + Tempo di incorporamento per la nuova implementazione
  + La percentuale di traffico da spostare in ogni incremento.
  + La durata in minuti di attesa tra ogni incremento di spostamento del traffico. 
  + CloudWatch allarmi per il rollback automatico
  + Hook del ciclo di vita della distribuzione (si tratta di funzioni Lambda che vengono eseguite in fasi di distribuzione specifiche come BEFORE\$1INSTALL, PRODUCTION\$1TRAFFIC\$1SHIFT o POST\$1PRODUCTION\$1TRAFFIC\$1SHIFT)

## Best practice
<a name="linear-deployment-best-practices"></a>

Segui queste best practice per implementazioni lineari di Amazon ECS di successo:
+ **Assicurati che la tua applicazione sia in grado di gestire entrambe le revisioni dei servizi in esecuzione contemporaneamente.**
+ **Pianifica una capacità del cluster sufficiente per gestire entrambe le revisioni dei servizi durante la distribuzione.**
+ **Verifica le tue procedure di rollback prima di implementarle in produzione.**
+ Configurare controlli dell'integrità appropriati che riflettano accuratamente l'integrità dell'applicazione.
+ Imposta un tempo di cottura che consenta di testare in modo sufficiente la nuova revisione del servizio.
+ Implementa CloudWatch allarmi per rilevare automaticamente i problemi e attivare i rollback.
+ Scegli le percentuali di passaggi e i tempi di cottura che bilanciano la velocità di implementazione con le esigenze di convalida.
+ Utilizza percentuali di graduale inferiori (5-10%) per le applicazioni critiche per ridurre al minimo l'esposizione al rischio.
+ Imposta tempi di cottura più lunghi per le applicazioni che richiedono tempo per riscaldarsi o stabilizzarsi.
+ Implementa CloudWatch allarmi per rilevare automaticamente i problemi e attivare il rollback a qualsiasi incremento di traffico.
+ Monitora attentamente le metriche delle applicazioni durante ogni spostamento di traffico per rilevare tempestivamente il degrado delle prestazioni.
+ Assicurati che l'applicazione sia in grado di gestire entrambe le revisioni dei servizi in esecuzione simultanea.
+ Testa le tue procedure di rollback con diverse percentuali di traffico prima di implementarle in produzione.

# Creazione di una distribuzione lineare Amazon ECS
<a name="deploy-linear-service"></a>

Utilizzando le distribuzioni lineari di Amazon ECS, puoi spostare gradualmente il traffico in incrementi uguali su intervalli di tempo specifici. Ciò fornisce una convalida controllata in ogni fase del processo di distribuzione.

## Prerequisiti
<a name="deploy-linear-service-prerequisites"></a>

Eseguite le seguenti operazioni prima di iniziare una distribuzione lineare.

1. Configurazione delle autorizzazioni appropriate.
   + Per informazioni sulle autorizzazioni di bilanciamento del carico elastico, consultare [Ruolo IAM dell'infrastruttura Amazon ECS per i bilanciatori del carico](AmazonECSInfrastructureRolePolicyForLoadBalancers.md).
   + Per informazioni sulle autorizzazioni Lambda, consultare [Autorizzazioni richieste per le funzioni Lambda nelle distribuzioni Amazon ECS blue/green](blue-green-permissions.md).

1. Le implementazioni lineari di Amazon ECS richiedono che il servizio utilizzi una delle seguenti funzionalità: Configura 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).

## Procedura
<a name="deploy-linear-service-procedure"></a>

Puoi utilizzare la console o il AWS CLI per creare un servizio di distribuzione lineare Amazon ECS.

------
#### [ Console ]

1. [Apri la console nella versione 2https://console.aws.amazon.com/ecs/.](https://console.aws.amazon.com/ecs/v2)

1. Determina la risorsa da cui avviare il servizio.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonECS/latest/developerguide/deploy-linear-service.html)

   Si apre la pagina **Crea servizio**.

1. In **Dettagli del servizio**, effettuare le seguenti operazioni:

   1. Per **Famiglia di definizione di attività**, scegliere la definizione di attività da utilizzare. Poi, per **Revisione della definizione di attività**, inserire la revisione da utilizzare.

   1. In **Nome servizio**, specificare un nome per il servizio.

1. Per eseguire il servizio in un cluster esistente, per **Cluster esistente**, scegliere il cluster. Per eseguire il servizio in un nuovo cluster, scegliere **Crea cluster** 

1. Scegliere come vengono distribuite le attività nell'infrastruttura cluster. In **Configurazione di calcolo**, scegliere l'opzione.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonECS/latest/developerguide/deploy-linear-service.html)

1. Nella sezione **Configurazione implementazione**, procedere come segue.

   1. Per **Tipo di servizio**, scegliere **Replica**.

   1. Per **Attività desiderate**, immettere il numero di attività da avviare e gestire nel servizio.

   1. Per consentire ad Amazon ECS di monitorare la distribuzione delle attività tra le zone di disponibilità e ridistribuirle in caso di squilibrio, in **Ribilanciamento del servizio delle zone di disponibilità**, selezionare **Ribilanciamento del servizio della zona di disponibilità**.

   1. Per **Periodo di tolleranza dei controlli di integrità**, inserire il periodo di tempo (in secondi) durante il quale il pianificatore di servizi ignora i controlli dell'integrità dei container, di bilanciamento dei carichi elastici e di VPC Lattice non integri dopo che è stata avviata un'attività. Se non si specifica un valore per il periodo di tolleranza per il controllo dell’integrità, viene utilizzato il valore predefinito di 0.

1. In **Configurazione di distribuzione**, configura le impostazioni di distribuzione lineare:

   1. Per **Strategia di distribuzione**, scegli **Linear**.

   1. Per **Percentuale di incremento del traffico**, inserisci la percentuale di traffico da spostare in ogni incremento (ad esempio, 10% per spostare il traffico con incrementi del 10%).

   1. Per **Intervallo tra gli incrementi**, inserisci il tempo di attesa in minuti tra ogni incremento di spostamento del traffico.

   1. Per **Bake time**, inserisci il numero di minuti in cui entrambe le revisioni del servizio blu e verde verranno eseguite contemporaneamente dopo l'ultimo cambio di traffico prima che la revisione blu venga terminata.

   1. (Facoltativo) Eseguire le funzioni Lambda in fasi specifiche dell'implementazione. In **Hook del ciclo di vita di implementazione**, selezionare le fasi per eseguire gli hook del ciclo di vita.

      Per aggiungere un hook del ciclo di vita:

      1. Scegliere **Aggiungi**.

      1. Per **Funzione Lambda**, immettere il nome della funzione o ARN.

      1. Per **Ruolo**, selezionare il ruolo IAM che ha il permesso di invocare la funzione Lambda.

      1. Per **Fasi del ciclo di vita**, selezionare le fasi in cui deve essere eseguita la funzione Lambda.

1. Per configurare il modo in cui Amazon ECS rileva e gestisce gli errori di implementazione, espandi **Deployment failure detection** (Rilevamento degli errori di implementazione), quindi scegli le tue opzioni. 

   1. Per interrompere un'implementazione quando le attività non possono essere avviate, seleziona **Use the Amazon ECS deployment circuit breaker** (Usa l'interruttore automatico di implementazione di Amazon ECS).

      Per fare in modo che il software ripristini automaticamente l'implementazione all'ultimo stato di implementazione completata quando l'interruttore automatico di implementazione imposta l'implementazione su uno stato di errore, selezionare **Rollback in caso di errore**.

   1. Per interrompere una distribuzione in base alle metriche dell'applicazione, seleziona **Usa CloudWatch allarmi**. Quindi, dal **nome CloudWatch dell'allarme**, scegli gli allarmi. Per creare un nuovo allarme, vai alla CloudWatch console.

      Per fare in modo che il software ripristini automaticamente la distribuzione all'ultimo stato di distribuzione completato quando un CloudWatch allarme imposta la distribuzione **su uno stato fallito, seleziona Rollback in caso** di errori.

1. (Facoltativo) Per connettere il servizio usando Service Connect, espandere **Service Connect**, quindi specificare quanto segue:

   1.  Selezionare **Attiva Service Connect**.

   1. In **Service Connect configuration** (Configurazione Service Connect), specifica la modalità client.
      + Se il servizio esegue un'applicazione client di rete che deve connettersi solo ad altri servizi nel namespace, scegliere **Solo lato client**.
      + Se il servizio esegue un'applicazione di rete o di servizio Web, deve fornire endpoint per questo servizio e si connette ad altri servizi nel namespace, scegliere **Client e server**.

   1. Per utilizzare un namespace differente da quello del cluster predefinito, per **Namespace**, scegliere il namespace del servizio. Può trattarsi di uno spazio dei nomi creato separatamente Regione AWS nello stesso spazio dell'utente Account AWS o di uno spazio dei nomi nella stessa regione condiviso con il proprio account utilizzando (). AWS Resource Access Manager AWS RAM*Per ulteriori informazioni sugli spazi dei AWS Cloud Map nomi condivisi, consulta Condivisione dello spazio dei nomi [tra AWS Cloud Map](https://docs.aws.amazon.com/cloud-map/latest/dg/sharing-namespaces.html) account nella Guida per gli sviluppatori.AWS Cloud Map *

   1. (Facoltativo) Configura le regole di test traffic header per le distribuzioni lineari. In **Instradamento del traffico di test**, specificare quanto segue:

      1. Selezionare **Abilita le regole di intestazione del traffico di test** per instradare richieste specifiche alla revisione del servizio verde durante il test.

      1. Per **Regole di corrispondenza di intestazione**, configurare i criteri per l'instradamento del traffico di test:
         + **Nome dell'intestazione**: inserire il nome dell'intestazione HTTP per la corrispondenza (ad esempio, `X-Test-Version` o `User-Agent`).
         + **Tipo di corrispondenza**: scegliere i criteri di corrispondenza:
           + **Corrispondenza esatta**: richieste di instradamento in cui il valore dell'intestazione corrisponde esattamente al valore specificato
           + **Intestazione presente**: richieste di instradamento che contengono l'intestazione specificata, indipendentemente dal valore
           + **Corrispondenza di schema**: richieste di instradamento in cui il valore dell'intestazione corrisponde a uno schema specificato
         + **Valore dell'intestazione** (se si utilizza la corrispondenza esatta o la corrispondenza di schema): inserire il valore o lo schema a cui far corrispondere l'intestazione.

         È possibile aggiungere più regole di corrispondenza dell'intestazione per creare una logica di instradamento complessa. Le richieste che corrispondono a una qualsiasi delle regole configurate verranno instradate alla revisione del servizio verde per essere testate.

      1. Scegliere **Aggiungi regola di intestazione** per configurare condizioni aggiuntive di corrispondenza dell'intestazione.
**Nota**  
Le regole di intestazione del traffico di test consentono di convalidare nuove funzionalità con traffico controllato prima di portare a termine l'implementazione completa. Ciò consente di testare la revisione del servizio verde con richieste specifiche (come quelle provenienti da strumenti di test interni o utenti beta) mantenendo al contempo il normale flusso di traffico verso la revisione del servizio blu.

   1. (Facoltativo) Specificare una configurazione del log. Selezionare **Usa la raccolta di log**. L'opzione predefinita invia i log dei contenitori a Logs. CloudWatch Le altre opzioni del driver di registro sono configurate utilizzando. AWS FireLens Per ulteriori informazioni, consulta [Inviare i log di Amazon ECS a un servizio o AWS AWS Partner](using_firelens.md).

      Di seguito sono riportate descrizioni più dettagliate per ogni destinazione di log di container.
      + **Amazon CloudWatch**: configura l'attività per inviare i log dei container a CloudWatch Logs. Vengono fornite le opzioni predefinite dei driver di registro, che creano un gruppo di CloudWatch log per tuo conto. Per specificare un nome del gruppo di log diverso, modifica i valori dell'opzione del driver.
      + **Amazon Data Firehose**: configura l'attività per inviare i log del container a Firehose. Vengono fornite le opzioni di driver di log predefinite che inviano i log a un flusso di consegna Firehose. Per specificare un nome del flusso di consegna diverso, modifica i valori dell'opzione del driver.
      + **Flusso di dati Amazon Kinesis**: configura il processo per inviare log di container a Kinesis Data Streams. Vengono fornite le opzioni di driver di log predefinite che inviano i log a un flusso di consegna Kinesis Data Streams. Per specificare un nome del flusso diverso, modifica i valori dell'opzione del driver.
      + **Amazon OpenSearch Service**: configura l'attività per inviare i log dei container a un dominio OpenSearch di servizio. Devono essere fornite le opzioni del driver di log. 
      + **Amazon S3**: configura l'attività per inviare log di container a un bucket Amazon S3. Vengono fornite le opzioni del driver di log predefinito, ma è necessario specificare un nome del bucket Amazon S3 valido.

1. (Facoltativo) Configura **il bilanciamento del carico** per la distribuzione lineare.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonECS/latest/developerguide/deploy-linear-service.html)

1. (Facoltativo) Per identificare il servizio e le attività, espandi la sezione **Tags** (Tag), quindi configura i tag.

   Per fare in modo che Amazon ECS contrassegni automaticamente tutte le attività appena avviate con il nome del cluster e i tag di definizione delle attività, seleziona **Attiva i tag gestiti di Amazon ECS**, quindi in **Propaga i tag da**, scegli **Definizioni di attività**.

   Per fare in modo che Amazon ECS contrassegni automaticamente tutte le attività appena avviate con il nome del cluster e i tag del servizio, seleziona **Attiva i tag gestiti di Amazon ECS**, quindi in **Propaga i tag da**, scegli **Servizio**.

   Aggiungi o rimuovi un tag.
   + [Aggiungi un tag] Scegli **Add tag** (Aggiungi tag), quindi effettuare le seguenti operazioni:
     + In **Chiave**, immetti il nome della chiave.
     + In **Valore**, immetti il valore della chiave.
   + [Rimuovere un tag] Accanto al tag, scegliere **Remove tag (Rimuovi tag)**.

1. Scegli **Create** (Crea).

------
#### [ AWS CLI ]

1. Crea un archivio denominato `linear-service-definition.json` con i seguenti contenuti.

   Sostituiscili con i tuoi valori. *user-input*

   ```
   {
     "serviceName": "myLinearService",
     "cluster": "arn:aws:ecs:us-west-2:123456789012:cluster/sample-fargate-cluster",
     "taskDefinition": "sample-fargate:1",
     "desiredCount": 5,
     "launchType": "FARGATE",
     "networkConfiguration": {
       "awsvpcConfiguration": {
         "subnets": [
           "subnet-09ce6e74c116a2299",
           "subnet-00bb3bd7a73526788",
           "subnet-0048a611aaec65477"
         ],
         "securityGroups": [
           "sg-09d45005497daa123"
         ],
         "assignPublicIp": "ENABLED"
       }
     },
     "deploymentController": {
       "type": "ECS"
     },
     "deploymentConfiguration": {
       "strategy": "LINEAR",
       "maximumPercent": 200,
       "minimumHealthyPercent": 100,
       "linearConfiguration": {
         "stepPercentage": 10.0,
         "stepBakeTimeInMinutes":6
       },
       "bakeTimeInMinutes": 10,
       "alarms": {
         "alarmNames": [
           "myAlarm"
         ],
         "rollback": true,
         "enable": true
       }
     },
     "loadBalancers": [
       {
         "targetGroupArn": "arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/blue-target-group/54402ff563af1197",
         "containerName": "fargate-app",
         "containerPort": 80,
         "advancedConfiguration": {
           "alternateTargetGroupArn": "arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/green-target-group/cad10a56f5843199",
           "productionListenerRule": "arn:aws:elasticloadbalancing:us-west-2:123456789012:listener-rule/app/my-linear-demo/32e0e4f946c3c05b/9cfa8c482e204f7d/831dbaf72edb911",
           "roleArn": "arn:aws:iam::123456789012:role/LoadBalancerManagementforECS"
         }
       }
     ]
   }
   ```

1. Esegui `create-service`.

   ```
   aws ecs create-service --cli-input-json file://linear-service-definition.json
   ```

------

## Fasi successive
<a name="deploy-linear-service-next-steps"></a>
+ Aggiornare il servizio per avviare l'implementazione. Per ulteriori informazioni, consulta [Aggiornamento di un servizio Amazon ECS](update-service-console-v2.md).
+ Monitora il processo di implementazione per assicurarti che segua lo schema lineare:
  + La revisione del servizio verde viene creata e aumentata verticalmente
  + Il traffico viene spostato in modo incrementale agli intervalli specificati
  + Ogni incremento attende l'intervallo specificato prima del turno successivo
  + Dopo che tutto il traffico è stato spostato, inizia il tempo di cottura
  + Dopo il tempo di incorporamento, la revisione blu viene interrotta

# Distribuzioni canary di Amazon ECS
<a name="canary-deployment"></a>

Le implementazioni Canary indirizzano innanzitutto una piccola percentuale di traffico verso la nuova revisione per i test iniziali, quindi spostano tutto il traffico rimanente contemporaneamente dopo il completamento con successo della fase canaria. Con le implementazioni di Amazon ECS Canary, convalida le nuove revisioni dei servizi con traffico utente reale, riducendo al minimo l'esposizione al rischio. Questo approccio offre un modo controllato per implementare le modifiche con la possibilità di monitorare le prestazioni e ripristinare rapidamente se vengono rilevati problemi.

## Risorse coinvolte nell'implementazione di un canarino
<a name="canary-deployment-resources"></a>

Le seguenti sono le risorse coinvolte nelle implementazioni di Amazon ECS Canary:
+ Spostamento del traffico: il processo utilizzato da Amazon ECS per spostare il traffico di produzione. Per le implementazioni di Amazon ECS Canary, il traffico viene spostato in due fasi: prima verso la percentuale canaria, quindi verso il completamento della distribuzione.
+ Percentuale canaria: la percentuale di traffico indirizzato alla nuova versione durante il periodo di valutazione.
+ Tempo di cottura di Canary: la durata del monitoraggio della versione Canary prima di procedere con la distribuzione completa.
+ Tempo di attesa dell'implementazione: il tempo, in minuti, che Amazon ECS attende dopo aver spostato tutto il traffico di produzione alla nuova revisione del servizio, prima di terminare la vecchia revisione del servizio. Si tratta del periodo in cui le revisioni blu e verde del servizio vengono eseguite contemporaneamente dopo lo spostamento del traffico di produzione.
+ Fasi del ciclo di vita: una serie di eventi nell'operazione di implementazione, ad esempio “dopo lo spostamento del traffico di produzione”.
+ Lifecycle hook: una funzione Lambda che viene eseguita in una fase specifica del ciclo di vita. È possibile creare una funzione che verifichi la distribuzione.
+ Gruppo di destinazione: una risorsa di bilanciamento del carico elastico utilizzata per indirizzare le richieste verso una o più destinazioni registrate (ad esempio, istanze EC2). Quando si crea un listener, si specifica un gruppo di destinazione per l'operazione predefinita. Il traffico viene inoltrato al gruppo di destinazione specificato nella regola del listener.
+ Listener: una risorsa di bilanciamento del carico elastico che controlla le richieste di connessione utilizzando il protocollo e la porta configurata. Le regole definite per un listener determinano il modo in cui Amazon ECS instrada le richieste alle destinazioni registrate.
+ Regola: una risorsa di bilanciamento del carico elastico associata a un listener. Una regola definisce il modo in cui le richieste vengono instradate e consiste in un'azione, una condizione e una priorità.

## Considerazioni
<a name="canary-deployment-considerations"></a>

Si tenga in considerazione quanto segue quando si sceglie un tipo di implementazione:
+ Utilizzo delle risorse: le implementazioni Canary eseguono contemporaneamente sia i set di attività originali che quelli di Canary durante il periodo di valutazione, aumentando l'utilizzo delle risorse.
+ Volume di traffico: assicurati che la percentuale di Canary generi traffico sufficiente per una convalida significativa della nuova versione.
+ Complessità del monitoraggio: le implementazioni di Canary richiedono il monitoraggio e il confronto delle metriche tra due versioni diverse contemporaneamente.
+ Velocità di rollback: le implementazioni Canary consentono un ripristino rapido riportando il traffico al set di attività originale.
+ Mitigazione del rischio: le implementazioni Canary offrono un'eccellente mitigazione del rischio limitando l'esposizione a una piccola percentuale di utenti.
+ Durata dell'implementazione: le implementazioni di Canary includono periodi di valutazione che prolungano il tempo complessivo di implementazione ma offrono opportunità di convalida.

## Come funzionano le implementazioni di Canary
<a name="canary-how-it-works"></a>

Il processo di distribuzione di Amazon ECS Canary segue un approccio strutturato con sei fasi distinte che garantiscono aggiornamenti delle applicazioni sicuri e affidabili. Ogni fase ha uno scopo specifico nella convalida e nella transizione dell'applicazione dalla versione attuale (blu) alla nuova versione (verde).

1. Fase di preparazione: creare l'ambiente verde insieme a quello blu esistente.

1. Fase di implementazione: implementazione della nuova revisione del servizio nell'ambiente verde. Amazon ECS avvia nuove attività utilizzando la revisione aggiornata del servizio mentre l'ambiente blu continua a servire il traffico di produzione.

1. Fase di test: convalida dell'ambiente verde utilizzando l'instradamento del traffico di test. L'Application Load Balancer indirizza le richieste di test verso l'ambiente verde mentre il traffico di produzione rimane sul blu.

1. Fase di trasferimento del traffico nelle Canarie: sposta la percentuale di traffico configurata verso la nuova revisione del servizio verde durante la fase canaria, seguita dallo spostamento del 100,0% del traffico verso la revisione del servizio verde

1. Fase di monitoraggio: monitoraggio dello stato delle applicazioni, delle metriche delle prestazioni e degli stati di allarme durante il periodo di tempo di incorporamento. Quando vengono rilevati problemi, viene avviata un'operazione di rollback.

1. Fase di completamento: finalizza l'implementazione chiudendo l'ambiente blu.

La fase di trasferimento del traffico nelle Canarie segue le seguenti fasi:
+ Iniziale: l'implementazione inizia con il 100% del traffico indirizzato alla revisione blu (attuale) del servizio. La (nuova) revisione del servizio verde riceve traffico di prova ma inizialmente nessun traffico di produzione.
+ Spostamento del traffico nelle Canarie: si tratta di una strategia di spostamento del traffico in due fasi.
  + Fase 1:10,0% verso il verde, 90,0% verso il blu
  + Fase 2:100,0% verso il verde, 0,0% verso il blu
+ Tempo di cottura per Canary Traffic - Attende una durata configurabile (Canary Bake Time) dopo il cambio di marcia per consentire il monitoraggio e la convalida delle prestazioni della nuova revisione con l'aumento del traffico.
+ Lifecycle Hook: le funzioni Lambda opzionali possono essere eseguite in varie fasi del ciclo di vita durante l'implementazione per eseguire convalida, monitoraggio o logica personalizzata automatizzati. Le funzioni Lambda o gli hook del ciclo di vita configurati per PRODUCTION\$1TRAFFIC\$1SHIFT verranno richiamati in ogni fase del trasferimento del traffico di produzione.

### Fasi del ciclo di vita dell'implementazione
<a name="canary-deployment-lifecycle-stages"></a>

Il processo di implementazione di Canary procede attraverso fasi distinte del ciclo di vita, ognuna con responsabilità e punti di controllo di convalida specifici. La comprensione di queste fasi consente di monitorare l'avanzamento dell'implementazione e risolvere i problemi in modo efficace.

Ogni fase del ciclo di vita può durare fino a 24 ore e inoltre ogni fase di spostamento del traffico in PRODUCTION\$1TRAFFIC\$1SHIFT può durare fino a 24 ore. Si consiglia di mantenere il valore al di sotto della soglia delle 24 ore. Questo perché i processi asincroni richiedono tempo per attivare gli hook. Il sistema scade, fallisce l'implementazione e quindi avvia un rollback dopo che una fase raggiunge le 24 ore.

CloudFormation le distribuzioni hanno restrizioni di timeout aggiuntive. Sebbene il limite delle fasi di 24 ore rimanga in vigore, CloudFormation impone un limite di 36 ore all'intera implementazione. CloudFormation fallisce l'implementazione e quindi avvia un rollback se il processo non viene completato entro 36 ore.


**Fasi del ciclo di vita**  

| Fasi del ciclo di vita | Description | Supporto per Lifecycle Hook | 
| --- | --- | --- | 
| RECONCILE\$1SERVICE | Questa fase si verifica solo quando si avvia una nuova implementazione del servizio con più di 1 revisione del servizio in uno stato ACTIVE. | Sì | 
| PRE\$1SCALE\$1UP | La revisione del servizio verde non è stata avviata. La revisione del servizio blu gestisce il 100% del traffico di produzione. Non è previsto alcun traffico di test. | Sì | 
| SCALE\$1UP | Il momento in cui la revisione del servizio verde aumenta fino al 100% e avvia nuove attività. La revisione del servizio verde non serve alcun traffico a questo punto. | No | 
| POST\$1SCALE\$1UP | La revisione del servizio verde è stata avviata. La revisione del servizio blu gestisce il 100% del traffico di produzione. Non è previsto alcun traffico di test. | Sì | 
| TEST\$1TRAFFIC\$1SHIFT | Le revisioni del servizio blu e verde sono in esecuzione. La revisione del servizio blu gestisce il 100% del traffico di produzione. La revisione del servizio verde migra dallo 0% al 100% del traffico di test. | Sì | 
| POST\$1TEST\$1TRAFFIC\$1SHIFT | Lo spostamento del traffico di test è completo. La revisione del servizio verde gestisce il 100% del traffico di test. | Sì | 
| PRODUCTION\$1TRAFFIC\$1SHIFT | Il traffico di produzione delle Canarie viene indirizzato alla revisione verde e lifecycle hook viene richiamato con un timeout di 24 ore. La seconda fase sposta il traffico di produzione residuo verso la revisione verde. | Sì | 
| POST\$1PRODUCTION\$1TRAFFIC\$1SHIFT | Lo spostamento del traffico di produzione è completo. | Sì | 
| BAKE\$1TIME | La durata in cui le revisioni del servizio blu e verde vengono eseguite contemporaneamente. | No | 
| CLEAN\$1UP | La revisione del servizio blu è stata completamente ridotta a 0 attività in esecuzione. La revisione del servizio verde è ora la revisione del servizio di produzione dopo questa fase. | No | 

### Parametri di configurazione
<a name="canary-configuration-parameters"></a>

Le implementazioni Canary richiedono i seguenti parametri di configurazione:
+ Percentuale delle Canarie: la percentuale di traffico da indirizzare verso la nuova revisione del servizio durante la fase canaria. Ciò consente di eseguire test con un sottoinsieme controllato del traffico di produzione.
+ Tempo di cottura delle Canarie: la durata di attesa durante la fase canaria prima di spostare il traffico rimanente verso la nuova revisione del servizio. Ciò fornisce il tempo necessario per monitorare e convalidare la nuova versione.

### Gestione del traffico
<a name="canary-traffic-management"></a>

Le implementazioni Canary utilizzano gruppi target di sistemi di bilanciamento del carico per gestire la distribuzione del traffico:
+ Gruppo target originale: contiene le attività dell'attuale versione stabile e riceve la maggior parte del traffico.
+ Gruppo target Canary: contiene le attività della nuova versione e riceve una piccola percentuale di traffico per i test.
+ Routing ponderato: il load balancer utilizza regole di routing ponderate per distribuire il traffico tra i gruppi target in base alla percentuale di canarie configurata.

### Monitoraggio e convalida
<a name="canary-monitoring-validation"></a>

Le implementazioni efficaci di Canary si basano su un monitoraggio completo:
+ Controlli sanitari: entrambi i set di attività devono superare i controlli di integrità prima di ricevere traffico.
+ Confronto delle metriche: confronta gli indicatori chiave delle prestazioni tra la versione originale e quella di Canary, come il tempo di risposta, il tasso di errore e la velocità effettiva.
+ Rollback automatico: configura gli CloudWatch allarmi per attivare automaticamente il rollback se la versione Canary mostra prestazioni inferiori.
+ Convalida manuale: utilizza il periodo di valutazione per esaminare manualmente i registri, le metriche e il feedback degli utenti prima di procedere.

### Le migliori pratiche per le implementazioni di Canary
<a name="canary-best-practices"></a>

Segui queste best practice per garantire il successo delle implementazioni di Canary con i relativi servizi.

#### Scegli le percentuali di traffico appropriate
<a name="canary-traffic-percentage"></a>

Considera questi fattori quando selezioni le percentuali di traffico delle Canarie:
+ Inizia in piccolo: inizia con il 5-10% del traffico per ridurre al minimo l'impatto in caso di problemi.
+ Considerate la criticità delle applicazioni: utilizzate percentuali più basse per le applicazioni mission critical e percentuali più alte per i servizi meno critici.
+ Tieni conto del volume di traffico: assicurati che la percentuale canaria generi traffico sufficiente per una convalida significativa.

#### Stabilisci periodi di valutazione appropriati
<a name="canary-evaluation-time"></a>

Configura i periodi di valutazione in base a queste considerazioni:
+ Concedi un tempo sufficiente: imposta periodi di valutazione sufficientemente lunghi da acquisire dati significativi sulle prestazioni, in genere 10-30 minuti.
+ Considerate i modelli di traffico: tenete conto dei modelli di traffico dell'applicazione e dei periodi di picco di utilizzo.
+ Equilibra velocità e sicurezza: periodi di valutazione più lunghi forniscono più dati ma rallentano la velocità di implementazione.

#### Implementa un monitoraggio completo
<a name="canary-monitoring-setup"></a>

Imposta il monitoraggio per monitorare le prestazioni di implementazione di Canary:
+ Metriche chiave: monitora il tempo di risposta, il tasso di errore, la velocità effettiva e l'utilizzo delle risorse per entrambi i set di attività.
+ Rollback basato sugli allarmi: configura gli CloudWatch allarmi per attivare automaticamente il rollback quando le metriche superano le soglie.
+ Analisi comparativa: configura dashboard per confrontare le metriche tra la versione originale e quella di Canary. side-by-side
+ Metriche aziendali: includi metriche specifiche aziendali come i tassi di conversione o il coinvolgimento degli utenti oltre alle metriche tecniche.

#### Pianifica le strategie di rollback
<a name="canary-rollback-strategy"></a>

Preparati a potenziali scenari di rollback con queste strategie:
+ Rollback automatizzato: configura i trigger di rollback automatici in base ai controlli di integrità e alle metriche delle prestazioni.
+ Procedure di rollback manuali: documenta procedure chiare per il rollback manuale quando i trigger automatici non rilevano tutti i problemi.
+ Test di rollback: verifica regolarmente le procedure di rollback per assicurarti che funzionino correttamente quando necessario.

#### Effettua una convalida completa prima dell'implementazione
<a name="canary-testing-validation"></a>

Garantisci una convalida completa prima di procedere con le implementazioni di Canary:
+ Test pre-implementazione: verifica accuratamente le modifiche negli ambienti di staging prima dell'implementazione di Canary.
+ Configurazione del controllo dello stato: assicurati che i controlli dello stato riflettano accuratamente la disponibilità e la funzionalità delle applicazioni.
+ Convalida delle dipendenze: verifica che le nuove versioni siano compatibili con i servizi downstream e upstream.
+ Coerenza dei dati: assicurati che le modifiche allo schema del database e le migrazioni dei dati siano compatibili con le versioni precedenti.

#### Coordina il coinvolgimento del team
<a name="canary-team-coordination"></a>

Garantire un coordinamento efficace del team durante l'impiego dei canarini:
+ Finestre di implementazione: pianifica le implementazioni di Canary durante l'orario lavorativo, quando i team sono disponibili per il monitoraggio e la risposta.
+ Canali di comunicazione: stabilisci canali di comunicazione chiari per lo stato dell'implementazione e la risoluzione dei problemi.
+ Assegnazione dei ruoli: definisci ruoli e responsabilità per il monitoraggio, il processo decisionale e l'esecuzione del rollback.

# Risorse richieste per le implementazioni di Amazon ECS Canary
<a name="canary-deployment-implementation"></a>

Per utilizzare una distribuzione Canary con Managed Traffic Shifting, il tuo servizio deve utilizzare una delle seguenti funzionalità:
+ Elastic Load Balancing
+ Service Connect

L'elenco seguente fornisce una panoramica di alto livello di ciò che è necessario configurare per le distribuzioni di Amazon ECS Canary:
+ 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 `canary` nella definizione del servizio.
+ Facoltativamente, configurare parametri aggiuntivi come:
  + Tempo di incorporamento per la nuova implementazione
  + La percentuale di traffico da indirizzare verso la nuova revisione del servizio durante la fase canaria. 
  + La durata di attesa durante la fase canaria prima di spostare il traffico rimanente verso la nuova revisione del servizio. 
  + CloudWatch allarmi per il rollback automatico
  + Hook del ciclo di vita della distribuzione (si tratta di funzioni Lambda che vengono eseguite in fasi di implementazione specifiche)

## Best practice
<a name="canary-deployment-best-practices"></a>

Segui queste best practice per implementazioni di Amazon ECS olcanary di successo:
+ **Assicurati che la tua applicazione sia in grado di gestire entrambe le revisioni dei servizi in esecuzione contemporaneamente.**
+ **Pianifica una capacità del cluster sufficiente per gestire entrambe le revisioni dei servizi durante la distribuzione.**
+ **Verifica le tue procedure di rollback prima di implementarle in produzione.**
+ 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.
+ Inizia con piccole percentuali di canarino (5-10%) per ridurre al minimo l'impatto in caso di problemi.
+ Stabilisci periodi di valutazione appropriati che offrano tempo sufficiente per una raccolta significativa dei dati sulle prestazioni.
+ Implementa un monitoraggio completo con CloudWatch allarmi per i trigger di rollback automatici.
+ Configura controlli di integrità che riflettano accuratamente la disponibilità e la funzionalità dell'applicazione.
+ Monitora sia le metriche tecniche (tempo di risposta, tasso di errore) che le metriche aziendali durante la valutazione.
+ Assicurati che la tua applicazione sia in grado di gestire la suddivisione del traffico senza problemi di sessione o di stato.
+ Pianifica le procedure di rollback e testale regolarmente per assicurarti che funzionino quando necessario.
+ Pianifica le implementazioni di Canary durante l'orario lavorativo, quando i team possono monitorare e rispondere.
+ Convalida accuratamente le modifiche negli ambienti di staging prima dell'implementazione di Canary.
+ Documenta procedure chiare per l'intervento manuale e le decisioni di ripristino.

# Creazione di una distribuzione Amazon ECS Canary
<a name="deploy-canary-service"></a>

Utilizzando le implementazioni di Amazon ECS Canary, puoi spostare una piccola percentuale di traffico verso la tua nuova revisione del servizio (il «canarino»). Convalida la distribuzione e poi sposta il traffico rimanente tutto in una volta dopo un intervallo specificato. Questo approccio consente di testare nuove funzionalità con un rischio minimo prima dell'implementazione completa.

## Prerequisiti
<a name="deploy-canary-service-prerequisites"></a>

Eseguite le seguenti operazioni prima di iniziare una distribuzione Canary.

1. Configurazione delle autorizzazioni appropriate.
   + Per informazioni sulle autorizzazioni di bilanciamento del carico elastico, consultare [Ruolo IAM dell'infrastruttura Amazon ECS per i bilanciatori del carico](AmazonECSInfrastructureRolePolicyForLoadBalancers.md).
   + Per informazioni sulle autorizzazioni Lambda, consultare [Autorizzazioni richieste per le funzioni Lambda nelle distribuzioni Amazon ECS blue/green](blue-green-permissions.md).

1. Le implementazioni di Amazon ECS Canary richiedono che il servizio utilizzi una delle seguenti funzionalità: Configura 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).

## Procedura
<a name="deploy-canary-service-procedure"></a>

Puoi utilizzare la console o AWS CLI creare un servizio di distribuzione Amazon ECS Canary.

------
#### [ Console ]

1. [Apri la console nella versione 2. https://console.aws.amazon.com/ecs/](https://console.aws.amazon.com/ecs/v2)

1. Determina la risorsa da cui avviare il servizio.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonECS/latest/developerguide/deploy-canary-service.html)

   Si apre la pagina **Crea servizio**.

1. In **Dettagli del servizio**, effettuare le seguenti operazioni:

   1. Per **Famiglia di definizione di attività**, scegliere la definizione di attività da utilizzare. Poi, per **Revisione della definizione di attività**, inserire la revisione da utilizzare.

   1. In **Nome servizio**, specificare un nome per il servizio.

1. Per eseguire il servizio in un cluster esistente, per **Cluster esistente**, scegliere il cluster. Per eseguire il servizio in un nuovo cluster, scegliere **Crea cluster** 

1. Scegliere come vengono distribuite le attività nell'infrastruttura cluster. In **Configurazione di calcolo**, scegliere l'opzione.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonECS/latest/developerguide/deploy-canary-service.html)

1. Nella sezione **Configurazione implementazione**, procedere come segue.

   1. Per **Tipo di servizio**, scegliere **Replica**.

   1. Per **Attività desiderate**, immettere il numero di attività da avviare e gestire nel servizio.

   1. Per consentire ad Amazon ECS di monitorare la distribuzione delle attività tra le zone di disponibilità e ridistribuirle in caso di squilibrio, in **Ribilanciamento del servizio delle zone di disponibilità**, selezionare **Ribilanciamento del servizio della zona di disponibilità**.

   1. Per **Periodo di tolleranza dei controlli di integrità**, inserire il periodo di tempo (in secondi) durante il quale il pianificatore di servizi ignora i controlli dell'integrità dei container, di bilanciamento dei carichi elastici e di VPC Lattice non integri dopo che è stata avviata un'attività. Se non si specifica un valore per il periodo di tolleranza per il controllo dell’integrità, viene utilizzato il valore predefinito di 0.

1. In **Configurazione di distribuzione**, configura le impostazioni di distribuzione di Canary:

   1. Per la **strategia di distribuzione**, scegli **Canary**.

   1. Per la **percentuale di Canarie**, inserisci la percentuale di traffico da passare alla revisione del servizio verde nella prima fase (ad esempio, 10% per il traffico iniziale delle Canarie).

   1. Per **Canary Bake time**, inserisci il tempo di attesa in minuti prima di spostare il traffico rimanente sulla revisione del servizio ecologico.

   1. Per **Tempo di cottura**, inserisci il numero di minuti in cui entrambe le revisioni del servizio blu e verde verranno eseguite contemporaneamente dopo l'ultimo cambiamento di traffico prima che la revisione blu venga interrotta.

   1. (Facoltativo) Eseguire le funzioni Lambda in fasi specifiche dell'implementazione. In **Hook del ciclo di vita di implementazione**, selezionare le fasi per eseguire gli hook del ciclo di vita.

      Per aggiungere un hook del ciclo di vita:

      1. Scegliere **Aggiungi**.

      1. Per **Funzione Lambda**, immettere il nome della funzione o ARN.

      1. Per **Ruolo**, selezionare il ruolo IAM che ha il permesso di invocare la funzione Lambda.

      1. Per **Fasi del ciclo di vita**, selezionare le fasi in cui deve essere eseguita la funzione Lambda.

1. Per configurare il modo in cui Amazon ECS rileva e gestisce gli errori di implementazione, espandi **Deployment failure detection** (Rilevamento degli errori di implementazione), quindi scegli le tue opzioni. 

   1. Per interrompere un'implementazione quando le attività non possono essere avviate, seleziona **Use the Amazon ECS deployment circuit breaker** (Usa l'interruttore automatico di implementazione di Amazon ECS).

      Per fare in modo che il software ripristini automaticamente l'implementazione all'ultimo stato di implementazione completata quando l'interruttore automatico di implementazione imposta l'implementazione su uno stato di errore, selezionare **Rollback in caso di errore**.

   1. Per interrompere una distribuzione in base alle metriche dell'applicazione, seleziona **Usa CloudWatch allarmi**. Quindi, dal **nome CloudWatch dell'allarme**, scegli gli allarmi. Per creare un nuovo allarme, vai alla CloudWatch console.

      Per fare in modo che il software ripristini automaticamente la distribuzione all'ultimo stato di distribuzione completato quando un CloudWatch allarme imposta la distribuzione **su uno stato fallito, seleziona Rollback in caso** di errori.

1. (Facoltativo) Per connettere il servizio usando Service Connect, espandere **Service Connect**, quindi specificare quanto segue:

   1.  Selezionare **Attiva Service Connect**.

   1. In **Service Connect configuration** (Configurazione Service Connect), specifica la modalità client.
      + Se il servizio esegue un'applicazione client di rete che deve connettersi solo ad altri servizi nel namespace, scegliere **Solo lato client**.
      + Se il servizio esegue un'applicazione di rete o di servizio Web, deve fornire endpoint per questo servizio e si connette ad altri servizi nel namespace, scegliere **Client e server**.

   1. Per utilizzare un namespace differente da quello del cluster predefinito, per **Namespace**, scegliere il namespace del servizio. Può trattarsi di uno spazio dei nomi creato separatamente Regione AWS nello stesso spazio dell'utente Account AWS o di uno spazio dei nomi nella stessa regione condiviso con il proprio account utilizzando (). AWS Resource Access Manager AWS RAM*Per ulteriori informazioni sugli spazi dei AWS Cloud Map nomi condivisi, consulta Condivisione dello spazio dei nomi [tra AWS Cloud Map](https://docs.aws.amazon.com/cloud-map/latest/dg/sharing-namespaces.html) account nella Guida per gli sviluppatori.AWS Cloud Map *

   1. (Facoltativo) Configura le regole di test traffic header per le implementazioni Canary. In **Instradamento del traffico di test**, specificare quanto segue:

      1. Selezionare **Abilita le regole di intestazione del traffico di test** per instradare richieste specifiche alla revisione del servizio verde durante il test.

      1. Per **Regole di corrispondenza di intestazione**, configurare i criteri per l'instradamento del traffico di test:
         + **Nome dell'intestazione**: inserire il nome dell'intestazione HTTP per la corrispondenza (ad esempio, `X-Test-Version` o `User-Agent`).
         + **Tipo di corrispondenza**: scegliere i criteri di corrispondenza:
           + **Corrispondenza esatta**: richieste di instradamento in cui il valore dell'intestazione corrisponde esattamente al valore specificato
           + **Intestazione presente**: richieste di instradamento che contengono l'intestazione specificata, indipendentemente dal valore
           + **Corrispondenza di schema**: richieste di instradamento in cui il valore dell'intestazione corrisponde a uno schema specificato
         + **Valore dell'intestazione** (se si utilizza la corrispondenza esatta o la corrispondenza di schema): inserire il valore o lo schema a cui far corrispondere l'intestazione.

         È possibile aggiungere più regole di corrispondenza dell'intestazione per creare una logica di instradamento complessa. Le richieste che corrispondono a una qualsiasi delle regole configurate verranno instradate alla revisione del servizio verde per essere testate.

      1. Scegliere **Aggiungi regola di intestazione** per configurare condizioni aggiuntive di corrispondenza dell'intestazione.
**Nota**  
Le regole di intestazione del traffico di test consentono di convalidare nuove funzionalità con traffico controllato prima di portare a termine l'implementazione completa. Ciò consente di testare la revisione del servizio verde con richieste specifiche (come quelle provenienti da strumenti di test interni o utenti beta) mantenendo al contempo il normale flusso di traffico verso la revisione del servizio blu.

   1. (Facoltativo) Specificare una configurazione del log. Selezionare **Usa la raccolta di log**. L'opzione predefinita invia i log dei contenitori a Logs. CloudWatch Le altre opzioni del driver di registro sono configurate utilizzando. AWS FireLens Per ulteriori informazioni, consulta [Inviare i log di Amazon ECS a un servizio o AWS AWS Partner](using_firelens.md).

      Di seguito sono riportate descrizioni più dettagliate per ogni destinazione di log di container.
      + **Amazon CloudWatch**: configura l'attività per inviare i log dei container a CloudWatch Logs. Vengono fornite le opzioni predefinite dei driver di registro, che creano un gruppo di CloudWatch log per tuo conto. Per specificare un nome del gruppo di log diverso, modifica i valori dell'opzione del driver.
      + **Amazon Data Firehose**: configura l'attività per inviare i log del container a Firehose. Vengono fornite le opzioni di driver di log predefinite che inviano i log a un flusso di consegna Firehose. Per specificare un nome del flusso di consegna diverso, modifica i valori dell'opzione del driver.
      + **Flusso di dati Amazon Kinesis**: configura il processo per inviare log di container a Kinesis Data Streams. Vengono fornite le opzioni di driver di log predefinite che inviano i log a un flusso di consegna Kinesis Data Streams. Per specificare un nome del flusso diverso, modifica i valori dell'opzione del driver.
      + **Amazon OpenSearch Service**: configura l'attività per inviare i log dei container a un dominio OpenSearch di servizio. Devono essere fornite le opzioni del driver di log. 
      + **Amazon S3**: configura l'attività per inviare log di container a un bucket Amazon S3. Vengono fornite le opzioni del driver di log predefinito, ma è necessario specificare un nome del bucket Amazon S3 valido.

1. (Facoltativo) Configura il **bilanciamento del carico per l'implementazione** di Canary.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonECS/latest/developerguide/deploy-canary-service.html)

1. (Facoltativo) Per identificare il servizio e le attività, espandi la sezione **Tags** (Tag), quindi configura i tag.

   Per fare in modo che Amazon ECS contrassegni automaticamente tutte le attività appena avviate con il nome del cluster e i tag di definizione delle attività, seleziona **Attiva i tag gestiti di Amazon ECS**, quindi in **Propaga i tag da**, scegli **Definizioni di attività**.

   Per fare in modo che Amazon ECS contrassegni automaticamente tutte le attività appena avviate con il nome del cluster e i tag del servizio, seleziona **Attiva i tag gestiti di Amazon ECS**, quindi in **Propaga i tag da**, scegli **Servizio**.

   Aggiungi o rimuovi un tag.
   + [Aggiungi un tag] Scegli **Add tag** (Aggiungi tag), quindi effettuare le seguenti operazioni:
     + In **Chiave**, immetti il nome della chiave.
     + In **Valore**, immetti il valore della chiave.
   + [Rimuovere un tag] Accanto al tag, scegliere **Remove tag (Rimuovi tag)**.

1. Scegli **Create** (Crea).

------
#### [ AWS CLI ]

1. Crea un archivio denominato `canary-service-definition.json` con i seguenti contenuti.

   Sostituiscili con i tuoi valori. *user-input*

   ```
   {
     "serviceName": "myCanaryService",
     "cluster": "arn:aws:ecs:us-west-2:123456789012:cluster/sample-fargate-cluster",
     "taskDefinition": "sample-fargate:1",
     "desiredCount": 5,
     "launchType": "FARGATE",
     "networkConfiguration": {
       "awsvpcConfiguration": {
         "subnets": [
           "subnet-09ce6e74c116a2299",
           "subnet-00bb3bd7a73526788",
           "subnet-0048a611aaec65477"
         ],
         "securityGroups": [
           "sg-09d45005497daa123"
         ],
         "assignPublicIp": "ENABLED"
       }
     },
     "deploymentController": {
       "type": "ECS"
     },
     "deploymentConfiguration": {
       "strategy": "CANARY",
       "maximumPercent": 200,
       "minimumHealthyPercent": 100,
       "canaryConfiguration" : {
           "canaryPercent" : 5.0,
           "canaryBakeTime" : 10
       },
       "bakeTimeInMinutes": 10,
       "alarms": {
         "alarmNames": [
           "myAlarm"
         ],
         "rollback": true,
         "enable": true
       }
     },
     "loadBalancers": [
       {
         "targetGroupArn": "arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/blue-target-group/54402ff563af1197",
         "containerName": "fargate-app",
         "containerPort": 80,
         "advancedConfiguration": {
           "alternateTargetGroupArn": "arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/green-target-group/cad10a56f5843199",
           "productionListenerRule": "arn:aws:elasticloadbalancing:us-west-2:123456789012:listener-rule/app/my-canary-demo/32e0e4f946c3c05b/9cfa8c482e204f7d/831dbaf72edb911",
           "roleArn": "arn:aws:iam::123456789012:role/LoadBalancerManagementforECS"
         }
       }
     ]
   }
   ```

1. Esegui `create-service`.

   ```
   aws ecs create-service --cli-input-json file://canary-service-definition.json
   ```

------

## Fasi successive
<a name="deploy-canary-service-next-steps"></a>

Dopo aver configurato la distribuzione di Canary, completa questi passaggi:
+ Aggiornare il servizio per avviare l'implementazione. Per ulteriori informazioni, consulta [Aggiornamento di un servizio Amazon ECS](update-service-console-v2.md).
+ Monitora il processo di implementazione per assicurarti che segua lo schema canarino:
  + La revisione del servizio verde viene creata e aumentata verticalmente
  + Una piccola percentuale del traffico (canarie) viene spostata verso la revisione verde
  + Il sistema attende l'intervallo canarino specificato
  + Il traffico rimanente viene spostato tutto in una volta alla versione verde
  + Dopo il tempo di incorporamento, la revisione blu viene interrotta

## Terminologia di implementazione
<a name="deployment-terminology"></a>

I seguenti termini vengono utilizzati in tutta la documentazione sulla distribuzione di Amazon ECS:

Implementazione blu-verde  
Una strategia di implementazione che crea un nuovo ambiente (verde) accanto all'ambiente esistente (blu), quindi sposta il traffico dal blu al verde dopo la convalida.

Implementazione Canary  
Una strategia di distribuzione che indirizza una piccola percentuale di traffico verso una nuova versione mantenendo la maggior parte sulla versione stabile per la convalida.

Implementazione lineare  
Una strategia di distribuzione che sposta gradualmente il traffico dalla vecchia versione alla nuova versione con incrementi uguali nel tempo.

Distribuzione continua  
Una strategia di distribuzione che sostituisce le istanze della vecchia versione con le istanze della nuova versione una alla volta.

Set di attività  
Una raccolta di attività che eseguono la stessa definizione di attività all'interno di un servizio durante una distribuzione.

Gruppo di destinazione  
Un raggruppamento logico di destinazioni che ricevono traffico da un sistema di bilanciamento del carico durante le distribuzioni.

Controller di implementazione  
Il metodo utilizzato per distribuire nuove versioni del servizio, come Amazon ECS CodeDeploy, o controller esterni.

Rollback  
Il processo di ripristino a una versione precedente dell'applicazione quando vengono rilevati problemi durante la distribuzione.

# Implementare i servizi Amazon ECS utilizzando un controller di terze parti
<a name="deployment-type-external"></a>

Il tipo di implementazione *esterna* consente di usare qualsiasi controller di implementazione di terze parti per il controllo completo sul processo di implementazione per un servizio Amazon ECS. I dettagli del servizio vengono gestiti tramite le operazioni API del servizio di gestione (`CreateService`, `UpdateService` e `DeleteService`) o della gestione dei set di attività (`CreateTaskSet`, `UpdateTaskSet`, `UpdateServicePrimaryTaskSet` e `DeleteTaskSet`). Ciascuna operazione API gestisce un sottoinsieme di parametri di definizione del servizio.

L'operazione API `UpdateService` aggiorna i parametri del periodo di tolleranza per il conteggio desiderato e il controllo dell'integrità di un servizio. Se è necessario aggiornare l'opzione di calcolo, la versione della piattaforma, i dettagli del bilanciatore del carico, la configurazione di rete o la definizione di attività, è necessario creare un nuovo set di attività.

L'operazione API `UpdateTaskSet` aggiorna solo il parametro di dimensionamento per un set di attività.

L'operazione API `UpdateServicePrimaryTaskSet` modifica il set di attività impostato come principale in un servizio. Chiamando l'operazione API `DescribeServices`, vengono restituiti tutti i campi specificati per un set di attività principale. Se viene aggiornato il set di attività principale per un servizio, quando viene definito il nuovo set principale eventuali valori del parametro esistenti sul nuovo ma diversi da quelli impostati sul precedente set di attività in un servizio verranno aggiornati ai nuovi valori. Se non viene definito un set di attività principale per un servizio, i relativi campi nella descrizione del servizio sono nulli.

## Considerazioni sull'implementazione esterna
<a name="deployment-type-external-considerations"></a>

Quando si utilizza il tipo di implementazione esterna, tenere conto di quanto segue:
+ I tipi di load balancer supportati sono un Application Load Balancer o un Network Load Balancer.
+ Fargate oppure i tipi di controller di implementazione `EXTERNAL` non supportano la strategia di pianificazione `DAEMON`.
+ L' AutoScaling integrazione delle applicazioni con Amazon ECS supporta solo il servizio Amazon ECS come destinazione. La dimensione scalabile supportata per Amazon ECS è `ecs:service:DesiredCount`: il numero di attività di un servizio Amazon ECS. Non esiste un'integrazione diretta tra i set di attività Application AutoScaling e Amazon ECS. I set di attività di Amazon ECS calcolano il `ComputedDesiredCount` base al `DesiredCount` di servizio di Amazon ECS.

## Flusso di lavoro dell'implementazione esterna
<a name="deployment-type-external-workflow"></a>

Di seguito è riportato il flusso di lavoro di base per la gestione di un'implementazione esterna su Amazon ECS.

**Come gestire un servizio Amazon ECS tramite un controller di implementazione esterno**

1. Crea un servizio Amazon ECS. L'unico parametro obbligatorio è il nome del servizio. Durante la creazione di un servizio tramite un controller di implementazione esterno, è possibile specificare i parametri indicati di seguito. Tutti gli altri, invece, vengono specificati al momento della creazione di un set di attività nel servizio.  
`serviceName`  
Tipo: stringa  
Obbligatorio: sì  
Il nome del servizio. Sono consentite fino a 255 lettere (maiuscole e minuscole), numeri, trattini e caratteri di sottolineatura. I nomi dei servizi devono essere univoci all'interno di un cluster, ma puoi avere servizi dai nomi simili in più cluster all'interno di una Regione o in più Regioni.  
`desiredCount`  
Il numero di istanze della definizione di attività per il set specificato, da posizionare e mantenere in esecuzione nel servizio.  
`deploymentConfiguration`  
I parametri di implementazione opzionali che determinano quante attività vengono eseguite durante un'implementazione e l'ordine di arresto e di avvio delle attività.   
`tags`  
Tipo: matrice di oggetti   
Obbligatorio: no  
I metadati applicati al servizio per aiutarti a catalogarli e organizzarli. Ogni tag è composto da una chiave e da un valore opzionale, entrambi personalizzabili. Quando un servizio viene eliminato, vengono eliminati anche i tag. Al servizio è possibile applicare un massimo di 50 tag. Per ulteriori informazioni, consultare [Aggiunta di tag alle risorse Amazon ECS](ecs-using-tags.md).  
Quando si aggiorna un servizio, questo parametro non innesca una nuova implementazione del servizio.    
`key`  
Tipo: String  
Limitazioni di lunghezza: lunghezza minima pari a 1. La lunghezza massima è 128 caratteri.  
Obbligatorio: no  
Una parte di una coppia chiave-valore che costituisce un tag. Una chiave è un'etichetta generale che funge da categoria per più valori di tag specifici.  
`value`  
Tipo: String  
Limitazioni di lunghezza: lunghezza minima di 0. La lunghezza massima è 256 caratteri.  
Obbligatorio: no  
La parte facoltativa di una coppia chiave-valore che costituisce un tag. Un valore agisce come descrittore all'interno di una categoria di tag (chiave).  
`enableECSManagedTags`  
Specifica se usare i tag gestiti di Amazon ECS per i processi all'interno del servizio. Per ulteriori informazioni, consultare [Uso dei tag per la risoluzione dei problemi](ecs-using-tags.md#tag-resources-for-billing).  
`propagateTags`  
Tipo: String  
Valori validi: `TASK_DEFINITION` \$1 `SERVICE`  
Obbligatorio: no  
Specifica se copiare i tag dalla definizione di attività o dal servizio nelle attività del servizio. Se non viene specificato alcun valore, i tag non vengono copiati. I tag possono essere copiati solo nelle attività all'interno del servizio durante la creazione del servizio. Per aggiungere tag a un processo dopo la creazione di un servizio o di un processo, utilizza l'operazione API `TagResource`.  
Quando si aggiorna un servizio, questo parametro non innesca una nuova implementazione del servizio.  
`schedulingStrategy`  
La strategia di pianificazione da utilizzare. I servizi che utilizzano un controller di implementazione esterno supportano solo la strategia di pianificazione `REPLICA`.  
`placementConstraints`  
Serie di oggetti vincolo di posizionamento da utilizzare per le attività del servizio. Puoi specificare un massimo di 10 vincoli per attività (questo limite include i vincoli nella definizione di attività e quelli specificati in fase di runtime). Se si utilizza Fargate, i vincoli di posizionamento dei processi non sono supportati.  
`placementStrategy`  
Gli oggetti strategia di posizionamento da utilizzare per le attività del servizio. Puoi specificare un massimo di quattro regole di strategia per ogni servizio.

   Di seguito è illustrato un esempio di definizione per la creazione di un servizio che utilizza un controller di implementazione esterno.

   ```
   {
       "cluster": "",
       "serviceName": "",
       "desiredCount": 0,
       "role": "",
       "deploymentConfiguration": {
           "maximumPercent": 0,
           "minimumHealthyPercent": 0
       },
       "placementConstraints": [
           {
               "type": "distinctInstance",
               "expression": ""
           }
       ],
       "placementStrategy": [
           {
               "type": "binpack",
               "field": ""
           }
       ],
       "schedulingStrategy": "REPLICA",
       "deploymentController": {
           "type": "EXTERNAL"
       },
       "tags": [
           {
               "key": "",
               "value": ""
           }
       ],
       "enableECSManagedTags": true,
       "propagateTags": "TASK_DEFINITION"
   }
   ```

1. Creare un set di attività iniziali. Il set di attività contiene i seguenti i dettagli sul servizio:  
`taskDefinition`  
La definizione delle attività nel set da utilizzare.  
`launchType`  
Tipo: String  
Valori validi: `EC2` \$1 `FARGATE` \$1 `EXTERNAL`  
Obbligatorio: no  
Il tipo di avvio con cui eseguire il servizio. Se non viene specificato un tipo di avvio, per impostazione predefinita viene utilizzato il `capacityProviderStrategy` di default.  
Quando si aggiorna un servizio, questo parametro innesca una nuova implementazione del servizio.  
Se viene specificato un `launchType`, il parametro `capacityProviderStrategy` deve essere omesso.  
`platformVersion`  
▬Tipo: stringa  
Obbligatorio: no  
La versione della piattaforma su cui sono in esecuzione le attività nel servizio. Viene specificata una versione della piattaforma solo per le attività con tipo di avvio Fargate. Se non è specificata, la versione più recente (`LATEST`) viene utilizzata di default.  
Quando si aggiorna un servizio, questo parametro innesca una nuova implementazione del servizio.  
AWS Le versioni della piattaforma Fargate vengono utilizzate per fare riferimento a un ambiente di runtime specifico per l'infrastruttura di attività Fargate. Quando specifichi la versione della piattaforma `LATEST` durante l'esecuzione di un'attività o la creazione di un servizio, ottieni la versione di piattaforma più aggiornata disponibile per le tue attività. Quando incrementi il servizio, tali attività riceveranno la versione della piattaforma specificata nell'implementazione corrente del servizio. Per ulteriori informazioni, consultare [Versioni della piattaforma Fargate per Amazon ECS](platform-fargate.md).  
Le versioni della piattaforma non sono specificate per i processi che utilizzano il tipo di avvio EC2.  
`loadBalancers`  
Un oggetto che rappresenta il load balancer da utilizzare con il tuo servizio. Quando si utilizza un controller di implementazione esterno, sono supportati solo Application Load Balancer e il Network Load Balancer. Se si utilizza un Application Load Balancer, è consentito un solo gruppo di destinazione di Application Load Balancer per ogni set di processi.  
Il frammento di codice seguente mostra un oggetto `loadBalancer` di esempio da utilizzare.  

   ```
   "loadBalancers": [
           {
               "targetGroupArn": "",
               "containerName": "",
               "containerPort": 0
           }
   ]
   ```
Quando si specifica un oggetto `loadBalancer`, è necessario specificare `targetGroupArn` e omettere i parametri `loadBalancerName`.  
`networkConfiguration`  
La configurazione di rete per il servizio. Questo parametro è obbligatorio per le definizioni di attività che utilizzano la modalità di rete `awsvpc` per ricevere la propria interfaccia di rete elastica e non è supportato per altre modalità. Per ulteriori informazioni sul networking per Fargate, consultare [Opzioni di rete di attività di Amazon ECS per Fargate](fargate-task-networking.md).  
`serviceRegistries`  
I dettagli dei registri del servizio di individuazione da assegnare a questo servizio. Per ulteriori informazioni, consultare [Usare il rilevamento servizi per connettere i servizi Amazon ECS con nomi DNS](service-discovery.md).  
`scale`  
Percentuale a virgola mobile del numero desiderato di attività da posizionare e mantenere in esecuzione nel seti di attività. Il valore è specificato come percentuale totale del conteggio desiderato (`desiredCount`) di un servizio. Come valori sono accettati i numeri da 0 a 100.

   Di seguito è riportato un esempio JSON per la creazione di un set di attività per un controller di implementazione esterno.

   ```
   {
       "service": "",
       "cluster": "",
       "externalId": "",
       "taskDefinition": "",
       "networkConfiguration": {
           "awsvpcConfiguration": {
               "subnets": [
                   ""
               ],
               "securityGroups": [
                   ""
               ],
               "assignPublicIp": "DISABLED"
           }
       },
       "loadBalancers": [
           {
               "targetGroupArn": "",
               "containerName": "",
               "containerPort": 0
           }
       ],
       "serviceRegistries": [
           {
               "registryArn": "",
               "port": 0,
               "containerName": "",
               "containerPort": 0
           }
       ],
       "launchType": "EC2",
       "capacityProviderStrategy": [
           {
               "capacityProvider": "",
               "weight": 0,
               "base": 0
           }
       ],
       "platformVersion": "",
       "scale": {
           "value": null,
           "unit": "PERCENT"
       },
       "clientToken": ""
   }
   ```

1. Quando è necessario modificare il servizio, utilizzare l'operazione API `CreateTaskSet`, `UpdateService` o `UpdateTaskSet`, a seconda dei parametri da aggiornare. Se è stato creato un set di attività, utilizzare il parametro `scale` per ogni set di attività in un servizio, per determinare il numero di attività da mantenere in esecuzione nel servizio. Ad esempio, se si dispone di un servizio che contiene un `tasksetA` e si crea un `tasksetB`, è consigliabile testare la validità del `tasksetB` prima di trasferire a esso il traffico di produzione. È possibile impostare il parametro `scale` per entrambi i set di attività su `100`e, una volta pronti a spostare tutto il traffico di produzione nel `tasksetB`, è possibile aggiornare `scale` per `tasksetA` su `0` per ridurlo.

# CodeDeploy implementazioni blu/verdi per Amazon ECS
<a name="deployment-type-bluegreen"></a>

Ti consigliamo di utilizzare la blue/green distribuzione Amazon ECS. Per ulteriori informazioni, consulta [Creazione di una distribuzione Amazon ECS blue/green](deploy-blue-green-service.md).

Il tipo di distribuzione *blu/verde* utilizza il modello di blue/green distribuzione controllato da. CodeDeploy Utilizza questo tipo di implementazione per verificare una nuova implementazione di un servizio prima di inviarvi traffico di produzione. Per ulteriori informazioni, consulta [Cosa c'è CodeDeploy](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html) nella *guida per l'AWS CodeDeploy utente*. Convalida lo stato di un servizio Amazon ECS prima della distribuzione

Esistono tre modi in cui il traffico può variare durante una distribuzione: blue/green 
+ **Canary:** il traffico viene trasferito in due incrementi. Puoi scegliere tra opzioni canary predefinite che specificano la percentuale del traffico reinstradato al set di attività aggiornato nel primo incremento e l'intervallo, in minuti, prima che il traffico rimanente venga reinstradato nel secondo incremento.
+ **Lineare**: il traffico viene spostato in incrementi uguali con lo stesso intervallo di tempo, in minuti, tra ciascun incremento. Puoi scegliere tra opzioni lineari predefinite che specificano la percentuale del traffico reinstradato in ogni incremento e l'intervallo di tempo, in minuti, tra ciascun incremento.
+ **R ll-at-once** — Tutto il traffico viene spostato contemporaneamente dal set di attività originale al set di attività aggiornato.

Di seguito sono riportati CodeDeploy i componenti utilizzati da Amazon ECS quando un servizio utilizza il tipo di blue/green distribuzione:

**CodeDeploy applicazione**  
Una raccolta di CodeDeploy risorse. È costituita da uno o più gruppi di implementazione.

**CodeDeploy gruppo di distribuzione**  
Le impostazioni di implementazione. Comprendono:  
+ Cluster e servizio Amazon ECS
+ Informazioni listener e gruppo di destinazione del bilanciatore del carico
+ Strategia di rollback dell’implementazione
+ Impostazioni di reinstradamento del traffico
+ Impostazioni di terminazione della revisione originale
+ Configurazione dell’implementazione
+ CloudWatch configurazione degli allarmi che può essere impostata per interrompere le distribuzioni
+ Impostazioni SNS o CloudWatch Events per le notifiche
Per ulteriori informazioni, consultare [Working with Deployment Groups](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployment-groups.html) nella *Guida per l'utente di AWS CodeDeploy *.

**CodeDeploy configurazione della distribuzione**  
Speciifica in che modo CodeDeploy indirizza il traffico di produzione verso l'attività sostitutiva impostata durante una distribuzione. Sono disponibili le seguenti configurazioni predefinite di implementazione lineare e canary. È inoltre possibile creare implementazioni lineari e canary personalizzate. Per ulteriori informazioni, consultare [Working with Deployment Configurations](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployment-configurations.html) nella *Guida per l'utente di AWS CodeDeploy *.  
+ **CodeDeployDefault. ECSAllAtOnce**: sposta tutto il traffico verso il container Amazon ECS aggiornato contemporaneamente
+ **CodeDeployDefault. ECSLinear10PercentEvery1Minuti**: Sposta il 10% del traffico ogni minuto fino a quando tutto il traffico non viene spostato.
+ **CodeDeployDefault. ECSLinear10PercentEvery3 minuti**: sposta il 10 percento del traffico ogni 3 minuti fino a quando tutto il traffico non viene spostato.
+ **CodeDeployDefault. ECSCanary10Percent5Minutes**: sposta il 10% del traffico nel primo incremento. Il restante 90% viene reinstradato cinque minuti più tardi.
+ **CodeDeployDefault. ECSCanary10Percent15Minutes**: sposta il 10% del traffico nel primo incremento. Il restante 90% viene distribuito 15 minuti dopo.

**Revisione**  
Una revisione è il file delle specifiche CodeDeploy dell'applicazione (AppSpec file). Nel AppSpec file, si specifica l'ARN completo della definizione dell'attività e il contenitore e la porta del set di attività sostitutivo in cui il traffico deve essere instradato quando viene creata una nuova distribuzione. Il nome del container deve essere uno dei nomi di container cui si fa riferimento nella definizione delle attività. Se la configurazione di rete o la versione della piattaforma è stata aggiornata nella definizione del servizio, è necessario specificare anche tali dettagli nel AppSpec file. Puoi inoltre specificare le funzioni Lambda da eseguire durante gli eventi del ciclo di vita dell'implementazione. Le funzioni Lambda consentono di eseguire i test e restituire i parametri durante l'implementazione. Per ulteriori informazioni, consulta [AppSpec File Reference](https://docs.aws.amazon.com/codedeploy/latest/userguide/reference-appspec-file.html) nella *Guida AWS CodeDeploy per l'utente*.

## Considerazioni
<a name="deployment-type-bluegreen-considerations"></a>

Quando utilizzi il tipo di blue/green distribuzione, considera quanto segue:
+ Quando viene inizialmente creato un servizio Amazon ECS che utilizza il tipo di blue/green distribuzione, viene creato un set di attività Amazon ECS.
+ Il servizio deve essere configurato per utilizzare un sistema Application Load Balancer o un Network Load Balancer. Di seguito sono elencati i requisiti del load balancer:
  + È necessario aggiungere al load balancer un listener di produzione che viene utilizzato per instradare il traffico di produzione.
  + Al load balancer può essere aggiunto un test opzionale che viene utilizzato per instradare il traffico di test. Se specifichi un listener di test, CodeDeploy indirizza il traffico di test verso l'attività sostitutiva impostata durante una distribuzione.
  + I listener di produzione e di test devono appartenere entrambi allo stesso load balancer.
  + È necessario definire un gruppo di destinazione per il bilanciatore del carico. Il gruppo di destinazione instrada il traffico verso l'attività originale impostata in un servizio attraverso il listener di produzione.
  + Quando viene utilizzato un Network Load Balancer, è supportata solo la configurazione dell'implementazione `CodeDeployDefault.ECSAllAtOnce`.
+ Per i servizi configurati per utilizzare la scalabilità automatica del servizio e il tipo di implementazione blu/verde, la scalabilità automatica non viene bloccata durante un'implementazione, ma l'implementazione potrebbe non riuscire in alcune circostanze. Di seguito viene descritto questo comportamento in modo più dettagliato.
  + Se un servizio è scalabile e viene avviata una distribuzione, viene creato il set di attività verde e CodeDeploy aspetterà fino a un'ora prima che il set di attività verde raggiunga lo stato stazionario e non sposterà il traffico finché non lo farà.
  + Se un servizio è in fase di blue/green implementazione e si verifica un evento di scalabilità, il traffico continuerà a variare per 5 minuti. Se il servizio non raggiunge lo stato stazionario entro 5 minuti, CodeDeploy interromperà la distribuzione e la contrassegnerà come fallita.
+ Le attività che utilizzano Fargate oppure i tipi di controller di implementazione `CODE_DEPLOY` non supportano la strategia di pianificazione `DAEMON`.
+ Quando si crea inizialmente un' CodeDeploy applicazione e un gruppo di distribuzione, è necessario specificare quanto segue:
  + È necessario definire due gruppi di destinazione per il bilanciatore del carico. Un gruppo di destinazione deve essere il gruppo di destinazione iniziale definito per il bilanciatore del carico quando il servizio Amazon ECS è stato creato. L'unico requisito del secondo gruppo di destinazione è che non può essere associato a un bilanciatore del carico diverso rispetto a quello utilizzato dal servizio.
+ Quando crei una CodeDeploy distribuzione per un servizio Amazon ECS, CodeDeploy crea un *set di attività sostitutivo* (o *set di attività verde*) nella distribuzione. Se hai aggiunto un listener di test al load balancer, CodeDeploy indirizza il traffico di test verso il set di attività sostitutivo. Questo è il momento in cui è possibile eseguire i test di convalida. Quindi CodeDeploy reindirizza il traffico di produzione dal set di attività originale al set di attività di sostituzione in base alle impostazioni di reinstradamento del traffico per il gruppo di distribuzione.

## Autorizzazioni IAM richieste
<a name="deployment-type-bluegreen-IAM"></a>

Blue/green deployments are made possible by a combination of the Amazon ECS and CodeDeploy APIs. Users must have the appropriate permissions for these services before they can use Amazon ECS blue/greendistribuzioni in o con Console di gestione AWS o. AWS CLI SDKs 

Oltre alle autorizzazioni IAM standard per la creazione e l'aggiornamento dei servizi, Amazon ECS richiede le seguenti autorizzazioni. Queste autorizzazioni sono state aggiunte alla policy IAM `AmazonECS_FullAccess`. Per ulteriori informazioni, consultare [AmazonECS\$1 FullAccess](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonECS_FullAccess).
+ `codedeploy:CreateApplication`
+ `codedeploy:CreateDeployment`
+ `codedeploy:CreateDeploymentGroup`
+ `codedeploy:GetApplication`
+ `codedeploy:GetDeployment`
+ `codedeploy:GetDeploymentGroup`
+ `codedeploy:ListApplications`
+ `codedeploy:ListDeploymentGroups`
+ `codedeploy:ListDeployments`
+ `codedeploy:StopDeployment`
+ `codedeploy:GetDeploymentTarget`
+ `codedeploy:ListDeploymentTargets`
+ `codedeploy:GetDeploymentConfig`
+ `codedeploy:GetApplicationRevision`
+ `codedeploy:RegisterApplicationRevision`
+ `codedeploy:BatchGetApplicationRevisions`
+ `codedeploy:BatchGetDeploymentGroups`
+ `codedeploy:BatchGetDeployments`
+ `codedeploy:BatchGetApplications`
+ `codedeploy:ListApplicationRevisions`
+ `codedeploy:ListDeploymentConfigs`
+ `codedeploy:ContinueDeployment`
+ `sns:ListTopics`
+ `cloudwatch:DescribeAlarms`
+ `lambda:ListFunctions`

**Nota**  
Oltre alle autorizzazioni Amazon ECS standard necessarie per eseguire processi e servizi, gli utenti hanno bisogno anche delle autorizzazioni `iam:PassRole` per utilizzare i ruoli IAM per le attività.

CodeDeploy necessita delle autorizzazioni per chiamare Amazon ECS APIs, modificare Elastic Load Balancing, richiamare le funzioni Lambda e CloudWatch descrivere gli allarmi, oltre alle autorizzazioni per modificare il conteggio desiderato del servizio per tuo conto. Prima di creare un servizio Amazon ECS che utilizza il tipo di blue/green implementazione, devi creare un ruolo IAM (`ecsCodeDeployRole`). Per ulteriori informazioni, consulta [Ruolo CodeDeploy IAM di Amazon ECS](codedeploy_IAM_role.md).

# Migra CodeDeploy blue/green deployments to Amazon ECS blue/green le distribuzioni
<a name="migrate-codedeploy-to-ecs-bluegreen"></a>

CodeDeploy blue/green and Amazon ECS blue/greenle distribuzioni offrono funzionalità simili, ma differiscono nel modo in cui vengono configurate e gestite.

## CodeDeploy panoramica sulla distribuzione in blu e verde
<a name="codedeploy-bluegreen-overview"></a>

Quando crei un servizio Amazon ECS utilizzando CodeDeploy, tu:

1. Creare un bilanciatore del carico con un listener di produzione e (facoltativamente) uno di test. Ogni listener è configurato con un'unica regola (predefinita) che instrada tutto il traffico verso un singolo gruppo di destinazione (il gruppo di destinazione principale).

1. Creare un servizio Amazon ECS, configurato per utilizzare il listener e il gruppo di destinazione, con il tipo `deploymentController` impostato su `CODE_DEPLOY`. La creazione del servizio comporta la creazione di una serie di attività (blu) registrate con il gruppo di destinazione specificato.

1. Crea un gruppo di CodeDeploy distribuzione (come parte di un' CodeDeploy applicazione) e configuralo con i dettagli del cluster Amazon ECS, il nome del servizio, i listener di load balancer, due gruppi target (il gruppo target principale utilizzato nella regola del listener di produzione e un gruppo target secondario da utilizzare per le attività di sostituzione), un ruolo di servizio (per concedere le CodeDeploy autorizzazioni per manipolare le risorse Amazon ECS ed Elastic Load Balancing) e vari parametri che controllano il comportamento di distribuzione.

Con CodeDeploy, le nuove versioni di un servizio vengono distribuite utilizzando`CreateDeployment()`, specificando il nome CodeDeploy dell'applicazione, il nome del gruppo di distribuzione e un AppSpec file che fornisce dettagli sulla nuova revisione e sugli hook opzionali del ciclo di vita. La CodeDeploy distribuzione crea un set di attività sostitutivo (verde) e ne registra le attività con il gruppo target secondario. Quando diventa integra, è disponibile per i test (facoltativo) e per la produzione. In entrambi i casi, il re-instradamento si ottiene modificando la rispettiva regola del listener in modo tale che punti al gruppo di destinazione secondario associato alla serie di attività verde. Il rollback si ottiene modificando la regola del listener di produzione riportandola al gruppo di destinazione primario.

## Panoramica della blue/green distribuzione di Amazon ECS
<a name="ecs-bluegreen-overview"></a>

Con le blue/green distribuzioni di Amazon ECS, la configurazione di distribuzione fa parte del servizio Amazon ECS stesso:

1. È necessario preconfigurare il listener di produzione del bilanciatore del carico con una regola che includa due gruppi di destinazione con pesi pari a 1 e 0.

1. È necessario specificare le seguenti risorse o aggiornare quelle del servizio: 
   + L'ARN di questa regola del listener 
   + I due gruppi di destinazione
   + Un ruolo IAM per concedere ad Amazon ECS l'autorizzazione a chiamare Elastic Load Balancing APIs
   + Un ruolo IAM facoltativo per eseguire le funzioni Lambda
   + Impostare il tipo `deploymentController` su `ECS` e `deploymentConfiguration.strategy` su `BLUE_GREEN`. Ciò si traduce nella creazione di un'implementazione del servizio (blu) le cui attività sono registrate nel gruppo di destinazione primario.

Con Amazon ECS blu/verde, viene creata una nuova revisione del servizio chiamando Amazon ECS `UpdateService()`, trasmettendo i dettagli della nuova revisione. L'implementazione del servizio crea nuove attività di revisione del servizio (verde) e le registra con il gruppo di destinazione secondario. Amazon ECS gestisce le operazioni di re-instradamento e rollback modificando i pesi sulla regola del listener.

## Differenze di implementazione principali
<a name="implementation-differences"></a>

Sebbene entrambi gli approcci comportino la creazione di una serie iniziale di attività, l'implementazione sottostante è diversa:
+ CodeDeploy utilizza un set di attività, mentre Amazon ECS utilizza una revisione del servizio. I set di attività di Amazon ECS sono un costrutto precedente sostituito dalle revisioni e dalle implementazioni dei servizi Amazon ECS. Queste offrono una maggiore visibilità sul processo di implementazione, nonché sulla cronologia di implementazione e revisione del servizio.
+ Con CodeDeploy, gli hook del ciclo di vita vengono specificati come parte del AppSpec file a cui viene fornito. `CreateDeployment()` Ciò significa che gli hook possono essere modificati da un'implementazione all'altra. Con Amazon ECS blu/verde, gli hook sono specificati come parte della configurazione del servizio e qualsiasi aggiornamento richiederebbe una chiamata `UpdateService()`.
+  CodeDeploy Sia Amazon ECS che Amazon ECS blue/green utilizzano Lambda per l'implementazione degli hook, ma gli input e gli output previsti sono diversi.

  Con CodeDeploy, la funzione deve effettuare una chiamata `PutLifecycleEventHookExecutionStatus()` per restituire lo stato dell'hook, che può essere o. `SUCCEEDED` `FAILED` Con Amazon ECS, la risposta di Lambda viene utilizzata per indicare lo stato dell'hook.
+ CodeDeploy richiama ogni hook come chiamata una tantum e prevede la restituzione dello stato di esecuzione finale entro un'ora. Gli hook di Amazon ECS sono più flessibili in quanto possono restituire un indicatore `IN_PROGRESS`, che segnala che l'hook deve essere invocato ripetutamente fino a quando non determina un `SUCCEEDED` o `FAILED`. Per ulteriori informazioni, consultare [Hook del ciclo di vita per le implementazioni di servizi Amazon ECS](deployment-lifecycle-hooks.md).

## Approcci per la migrazione
<a name="migration-paths"></a>

Esistono tre approcci principali alla migrazione dalle distribuzioni. CodeDeploy blue/green to Amazon ECS blue/green Ogni approccio dispone di caratteristiche diverse in termini di complessità, rischio, capacità di rollback e potenziale tempo di inattività.

### Riutilizza le stesse risorse Elastic Load Balancing utilizzate per CodeDeploy
<a name="inplace-update"></a>

Aggiorna il servizio Amazon ECS esistente per utilizzare il controller di distribuzione Amazon ECS con strategia di blue/green distribuzione anziché il controller di CodeDeploy distribuzione. Quando si adotta questo approccio, considerare quanto segue:
+ La procedura di migrazione è più semplice perché si sta aggiornando il controller di implementazione del servizio Amazon ECS e la strategia di implementazione esistenti.
+ Non è previsto un tempo di inattività con una configurazione e una migrazione corrette.
+ Un rollback richiede l'annullamento della revisione del servizio.
+ Il rischio è elevato perché non esiste una configurazione blu/verde parallela.

Utilizzi lo stesso listener di load balancer e gli stessi gruppi target utilizzati per. CodeDeploy Se lo stai usando CloudFormation, vedi. [Migrazione di un modello CloudFormation CodeDeploy blue/green deployment template to an Amazon ECS blue/green CloudFormation](migrate-codedeploy-to-ecs-bluegreen-cloudformation-template.md)

1. Modifica la regola predefinita degli production/test ascoltatori per includere il gruppo target alternativo e imposta il peso del gruppo target primario su 1 e del gruppo target alternativo su 0.

   Infatti CodeDeploy, i listener del load balancer collegato al servizio sono configurati con un'unica regola (predefinita) che indirizza tutto il traffico verso un singolo gruppo di destinazione. Per Amazon ECS blu/verde, i listener del bilanciatore del carico devono essere preconfigurati con una regola che includa i due gruppi di destinazione con pesi. Il gruppo di destinazione principale deve essere ponderato a 1 e il gruppo di destinazione alternativo deve essere ponderato a 0.

1. Aggiornare il servizio Amazon ECS esistente chiamando l'API `UpdateService` e impostando il parametro `deploymentController` su `ECS` e il parametro `deploymentStrategy` su `BLUE_GREEN`. Specificate il ARNs gruppo target, il gruppo target alternativo, il listener di produzione e un listener di test opzionale.

1. Verificare che il servizio funzioni come previsto.

1. Elimina la CodeDeploy configurazione per questo servizio Amazon ECS poiché ora utilizzi Amazon ECS blu/verde.

### Nuovo servizio con il bilanciatore del carico esistente
<a name="new-service-existing-lb"></a>

Questo approccio utilizza la blue/green strategia per la migrazione. 

Quando si adotta questo approccio, considerare quanto segue:
+ Le interruzioni sono minime. Si verificano solo durante lo scambio di porte per il bilanciamento del carico elastico.
+ Un rollback richiede il ripristino dello swap della porta per il bilanciamento del carico elastico.
+ Il rischio è basso perché vi sono configurazioni parallele. Pertanto è possibile eseguire il test prima dello spostamento del traffico.

1. Lascia intatti gli ascoltatori, i gruppi target e il servizio Amazon ECS per la CodeDeploy configurazione in modo da poter tornare facilmente a questa configurazione, se necessario.

1. Creare nuovi gruppi di destinazione e nuovi listener (con porte diverse dai listener originali) utilizzando il bilanciatore del carico esistente. Quindi, crea un nuovo servizio Amazon ECS che corrisponda al servizio Amazon ECS esistente, tranne che lo usi `ECS` come controller di distribuzione, `BLUE_GREEN` come strategia di distribuzione e trasferisci le regole ARNs per i nuovi gruppi target e i nuovi ascoltatori.

1. Verificare la nuova configurazione inviando manualmente il traffico HTTP al servizio. Se tutto va bene, scambiare le porte dei listener originali con quelle dei nuovi listener per instradare il traffico verso la nuova configurazione.

1. Verifica la nuova configurazione e, se tutto continua a funzionare come previsto, elimina la configurazione. CodeDeploy 

### Nuovo servizio con un nuovo bilanciatore del carico
<a name="new-service-new-lb"></a>

Come l'approccio precedente, questo approccio utilizza la blue/green strategia per la migrazione. La differenza fondamentale è che il passaggio dalla CodeDeploy configurazione alla configurazione di Amazon ECS blue/green avviene a un livello di proxy inverso sopra il load balancer. Le implementazioni di esempio per il livello di reverse proxy sono Route 53 e. CloudFront

Questo approccio è adatto ai clienti che dispongono già di questo livello di proxy inverso e se tutte le comunicazioni con il servizio avvengono attraverso di esso (ad esempio, nessuna comunicazione diretta a livello di bilanciatore del carico).

Quando si adotta questo approccio, considerare quanto segue:
+ Ciò richiede un livello di proxy inverso.
+ La procedura di migrazione è più complessa perché è necessario aggiornare il controller di implementazione del servizio Amazon ECS e la strategia di implementazione esistenti.
+ Le interruzioni sono minime. Si verificano solo durante lo scambio di porte per il bilanciamento del carico elastico.
+ Un rollback richiede l'annullamento delle modifiche alla configurazione del proxy.
+ Il rischio è basso perché vi sono configurazioni parallele. Pertanto è possibile eseguire il test prima dello spostamento del traffico.

1. Non modificare intatta la CodeDeploy configurazione esistente (load balancer, listener, gruppi target, servizio Amazon ECS e CodeDeploy gruppo di distribuzione).

1. Crea un nuovo sistema di bilanciamento del carico, gruppi target e listener configurati per le distribuzioni di Amazon ECS blue/green .

   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).

1. Creare un nuovo servizio con `ECS` come controller di implementazione e `BLUE_GREEN` come strategia di implementazione, puntando alle nuove risorse del bilanciatore del carico.

1. Verificare la nuova configurazione testandola tramite il nuovo bilanciatore del carico.

1. Aggiornare la configurazione del proxy inverso per instradare il traffico verso il nuovo bilanciatore del carico.

1. Osserva la nuova revisione del servizio e, se tutto continua a funzionare come previsto, elimina la configurazione. CodeDeploy 

## Fasi successive
<a name="post-migration-considerations"></a>

Dopo la migrazione alle distribuzioni di Amazon ECS: blue/green 
+ Aggiorna gli script e le CI/CD pipeline di distribuzione per utilizzare l'API Amazon ECS anziché `UpdateService` l'API. CodeDeploy `CreateDeployment`
+ Aggiorna il monitoraggio e gli avvisi per tenere traccia delle distribuzioni dei servizi Amazon ECS anziché delle distribuzioni. CodeDeploy 
+ Considerare l'implementazione di test automatici del nuovo processo di implementazione per garantirne il funzionamento previsto.

# Migrazione da una distribuzione di servizi CodeDeploy blue/green to an Amazon ECS blue/green
<a name="migrate-code-deploy-to-ecs-blue-green"></a>

 Utilizzando le blue/green distribuzioni di Amazon ECS, puoi apportare e testare modifiche ai servizi prima di implementarle in un ambiente di produzione. 

È necessario creare nuovi hook del ciclo di vita per la distribuzione di Amazon ECS. blue/green 

## Prerequisiti
<a name="migrate-code-deploy-to-ecs-blue-green-prerequisites"></a>

Esegui le seguenti operazioni prima di iniziare una distribuzione. blue/green 

1. Sostituisci il ruolo Amazon ECS CodeDeploy IAM con le seguenti autorizzazioni.
   + Per informazioni sulle autorizzazioni di bilanciamento del carico elastico, consultare [Ruolo IAM dell'infrastruttura Amazon ECS per i bilanciatori del carico](AmazonECSInfrastructureRolePolicyForLoadBalancers.md).
   + Per informazioni sulle autorizzazioni Lambda, consultare [Autorizzazioni richieste per le funzioni Lambda nelle distribuzioni Amazon ECS blue/green](blue-green-permissions.md).

1. Disattiva CodeDeploy l'automazione. Per ulteriori informazioni, consulta [Lavorare con i gruppi di distribuzione CodeDeploy nella](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployment-groups.html) *Guida CodeDeploy per l'utente*. 

1. Assicurati di disporre delle seguenti informazioni relative alla CodeDeploy blue/green deployment. You can reuse this information for the Amazon ECS blue/green distribuzione:
   + Il gruppo di destinazione della produzione
   + Il listener di produzione
   + La regola di produzione
   + Il gruppo di destinazione di test

     Questo è il gruppo di destinazione per la revisione del servizio verde.

1. Assicurarsi che i gruppi di destinazione dell'Application Load Balancer siano associati correttamente alle regole del listener:
   + Se non si utilizzano i listener di test, entrambi i gruppi di destinazione (produzione e test) devono essere associati alle regole dei listener di produzione.
   + Se si utilizzano i listener di test, un gruppo di destinazione deve essere collegato alle regole dei listener di produzione e l'altro gruppo di destinazione deve essere collegato alle regole dei listener di test.

   Se questo requisito non viene soddisfatto, l'implementazione del servizio avrà esito negativo con il seguente errore: `Service deployment rolled back because of invalid networking configuration. Both targetGroup and alternateTargetGroup must be associated with the productionListenerRule or testListenerRule.`

1. Verificare che non vi siano implementazioni di servizi in corso per il servizio. Per ulteriori informazioni, consulta [Visualizza la cronologia dei servizi utilizzando le distribuzioni dei servizi Amazon ECS](service-deployment.md).

1.  blue/green Le implementazioni di Amazon ECS richiedono che il servizio utilizzi una delle seguenti funzionalità: Configura 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).

1. Decidi se vuoi eseguire le funzioni Lambda per le fasi del ciclo di vita delle fasi della distribuzione di Amazon ECS. blue/green 
   + Prima dell'aumento verticale
   + Dopo l'aumento verticale
   + Spostamento del traffico di test
   + Dopo lo spostamento del traffico di test
   + Spostamento del traffico di produzione
   + Dopo lo spostamento del traffico di produzione

   Creare funzioni Lambda per ogni fase del ciclo di vita. Per ulteriori informazioni, consultare [Create a Lambda function with the console](https://docs.aws.amazon.com/lambda/latest/dg/getting-started.html#getting-started-create-function) nella *Guida per gli sviluppatori di AWS Lambda *.

Per ulteriori informazioni sull'aggiornamento di un controller di implementazione del servizio, consultare [Aggiornare i parametri del servizio Amazon ECS](update-service-parameters.md).

## Procedura
<a name="migrate-code-deploy-to-ecs-procedure"></a>

1. [Apri la console nella versione 2. https://console.aws.amazon.com/ecs/](https://console.aws.amazon.com/ecs/v2)

1. Nella pagina **Cluster**, scegliere il cluster.

   Si apre la pagina dei dettagli del cluster.

1. Dalla scheda **Servizi**, scegliere il servizio.

   Si apre la pagina dei dettagli del servizio.

1. Nel banner, scegliere **Aggiorna tipo di controller di implementazione**.

   Si apre la pagina **Migrare il tipo di controller di implementazione**.

1. Espandere **Nuovo**, quindi specificare i seguenti parametri

   1. Per **Tipo di controller di implementazione**, scegliere **ECS**.

   1. Per **Strategia di implementazione**, scegliere **Blu/verde**.

   1. Per **tempo di incorporamento**, inserire l'ora di esecuzione delle revisioni del servizio blu e verde.

   1. Per eseguire le funzioni Lambda per una fase del ciclo di vita, in **Hook del ciclo di vita di implementazione**, svolgere le seguenti operazioni per ogni funzione Lambda unica:

      1. Scegliere **Aggiungi**.

         Ripetere l'operazione per ogni funzione unica che si desidera eseguire.

      1. Per **Funzione Lambda**, immettere il nome della funzione.

      1. Per **Ruolo**, scegliere il ruolo creato nei prerequisiti con le autorizzazioni blu/verdi.

         Per ulteriori informazioni, consultare [Autorizzazioni richieste per le funzioni Lambda nelle distribuzioni Amazon ECS blue/green](blue-green-permissions.md).

      1. Per **Fasi del ciclo di vita**, selezionare le fasi eseguite dalla funzione Lambda.

      1.  (Facoltativo) Per **Dettagli dell'hook**, inserire una coppia chiave-valore che fornisca informazioni sull'hook.

1. Espandere **Bilanciamento del carico** e configurare quanto segue:

   1. Per **Ruolo**, scegli il ruolo che hai creato nei prerequisiti con le blue/green autorizzazioni.

      Per ulteriori informazioni, consulta [Autorizzazioni richieste per le funzioni Lambda nelle distribuzioni Amazon ECS blue/green](blue-green-permissions.md).

   1. Per **Listener**, scegli il listener di produzione dalla tua distribuzione blu/verde. CodeDeploy 

   1. Per la **regola di produzione**, scegli la regola di produzione dalla tua implementazione blu/verde. CodeDeploy 

   1. Per la **regola di test**, scegli la regola di test dalla tua implementazione CodeDeploy blu/verde.

   1. Per **Target group**, scegli il gruppo target di produzione dalla tua implementazione CodeDeploy blu/verde.

   1. Per **Gruppo target alternativo, scegli il gruppo target** di test dalla tua CodeDeploy implementazione blu/verde.

1. Scegliere **Aggiorna**.

## Fasi successive
<a name="migrate-code-deploy-to-ecs-blue-green-next-steps"></a>
+ Aggiornare il servizio per avviare l'implementazione. Per ulteriori informazioni, consultare [Aggiornamento di un servizio Amazon ECS](update-service-console-v2.md).
+ Monitorare il processo di implementazione per assicurarsi che segua lo schema blu/verde:
  + La revisione del servizio verde viene creata e aumentata verticalmente
  + Il traffico di test viene instradato alla revisione verde (se configurata)
  + Il traffico di produzione viene spostato alla revisione del servizio verde
  + Dopo il tempo di incorporamento, la revisione blu viene interrotta

# Migrazione di un modello CloudFormation CodeDeploy blue/green deployment template to an Amazon ECS blue/green CloudFormation
<a name="migrate-codedeploy-to-ecs-bluegreen-cloudformation-template"></a>

Esegui la migrazione di un CloudFormation modello che utilizza una strategia di distribuzione. CodeDeploy blue/green deployments for Amazon ECS services to one that uses the native Amazon ECS blue/green La migrazione segue l'approccio «Riutilizza le stesse risorse Elastic Load Balancing utilizzate CodeDeploy per». Per ulteriori informazioni, consulta [Migra CodeDeploy blue/green deployments to Amazon ECS blue/green le distribuzioni](migrate-codedeploy-to-ecs-bluegreen.md).

## Modello di origine
<a name="source-template"></a>

Questo modello utilizza `AWS::CodeDeployBlueGreen` transform e `AWS::CodeDeploy::BlueGreen` hook per implementare le blue/green distribuzioni per un servizio Amazon ECS.

### Origine
<a name="code-deploy-source"></a>

Questo è il CloudFormation modello completo che utilizza la distribuzione blu/verde CodeDeploy . *Per ulteriori informazioni, consulta l'[esempio del modello di distribuzione blu/verde](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/blue-green-template-example.html#blue-green-template-example.json) nella Guida per l'utente: AWS CloudFormation *

```
{
  "AWSTemplateFormatVersion": "2010-09-09",
  "Parameters": {
    "Vpc": {
      "Type": "AWS::EC2::VPC::Id"
    },
    "Subnet1": {
      "Type": "AWS::EC2::Subnet::Id"
    },
    "Subnet2": {
      "Type": "AWS::EC2::Subnet::Id"
    }
  },
  "Transform": [
    "AWS::CodeDeployBlueGreen"
  ],
  "Hooks": {
    "CodeDeployBlueGreenHook": {
      "Type": "AWS::CodeDeploy::BlueGreen",
      "Properties": {
        "TrafficRoutingConfig": {
          "Type": "TimeBasedCanary",
          "TimeBasedCanary": {
            "StepPercentage": 15,
            "BakeTimeMins": 5
          }
        },
        "Applications": [
          {
            "Target": {
              "Type": "AWS::ECS::Service",
              "LogicalID": "ECSDemoService"
            },
            "ECSAttributes": {
              "TaskDefinitions": [
                "BlueTaskDefinition",
                "GreenTaskDefinition"
              ],
              "TaskSets": [
                "BlueTaskSet",
                "GreenTaskSet"
              ],
              "TrafficRouting": {
                "ProdTrafficRoute": {
                  "Type": "AWS::ElasticLoadBalancingV2::Listener",
                  "LogicalID": "ALBListenerProdTraffic"
                },
                "TargetGroups": [
                  "ALBTargetGroupBlue",
                  "ALBTargetGroupGreen"
                ]
              }
            }
          }
        ]
      }
    }
  },
  "Resources": {
    "ExampleSecurityGroup": {
      "Type": "AWS::EC2::SecurityGroup",
      "Properties": {
        "GroupDescription": "Security group for ec2 access",
        "VpcId": {"Ref": "Vpc"},
        "SecurityGroupIngress": [
          {
            "IpProtocol": "tcp",
            "FromPort": 80,
            "ToPort": 80,
            "CidrIp": "0.0.0.0/0"
          },
          {
            "IpProtocol": "tcp",
            "FromPort": 8080,
            "ToPort": 8080,
            "CidrIp": "0.0.0.0/0"
          },
          {
            "IpProtocol": "tcp",
            "FromPort": 22,
            "ToPort": 22,
            "CidrIp": "0.0.0.0/0"
          }
        ]
      }
    },
    "ALBTargetGroupBlue": {
      "Type": "AWS::ElasticLoadBalancingV2::TargetGroup",
      "Properties": {
        "HealthCheckIntervalSeconds": 5,
        "HealthCheckPath": "/",
        "HealthCheckPort": "80",
        "HealthCheckProtocol": "HTTP",
        "HealthCheckTimeoutSeconds": 2,
        "HealthyThresholdCount": 2,
        "Matcher": {
          "HttpCode": "200"
        },
        "Port": 80,
        "Protocol": "HTTP",
        "Tags": [
          {
            "Key": "Group",
            "Value": "Example"
          }
        ],
        "TargetType": "ip",
        "UnhealthyThresholdCount": 4,
        "VpcId": {"Ref": "Vpc"}
      }
    },
    "ALBTargetGroupGreen": {
      "Type": "AWS::ElasticLoadBalancingV2::TargetGroup",
      "Properties": {
        "HealthCheckIntervalSeconds": 5,
        "HealthCheckPath": "/",
        "HealthCheckPort": "80",
        "HealthCheckProtocol": "HTTP",
        "HealthCheckTimeoutSeconds": 2,
        "HealthyThresholdCount": 2,
        "Matcher": {
          "HttpCode": "200"
        },
        "Port": 80,
        "Protocol": "HTTP",
        "Tags": [
          {
            "Key": "Group",
            "Value": "Example"
          }
        ],
        "TargetType": "ip",
        "UnhealthyThresholdCount": 4,
        "VpcId": {"Ref": "Vpc"}
      }
    },
    "ExampleALB": {
      "Type": "AWS::ElasticLoadBalancingV2::LoadBalancer",
      "Properties": {
        "Scheme": "internet-facing",
        "SecurityGroups": [
          {"Ref": "ExampleSecurityGroup"}
        ],
        "Subnets": [
          {"Ref": "Subnet1"},
          {"Ref": "Subnet2"}
        ],
        "Tags": [
          {
            "Key": "Group",
            "Value": "Example"
          }
        ],
        "Type": "application",
        "IpAddressType": "ipv4"
      }
    },
    "ALBListenerProdTraffic": {
      "Type": "AWS::ElasticLoadBalancingV2::Listener",
      "Properties": {
        "DefaultActions": [
          {
            "Type": "forward",
            "ForwardConfig": {
              "TargetGroups": [
                {
                  "TargetGroupArn": {"Ref": "ALBTargetGroupBlue"},
                  "Weight": 1
                }
              ]
            }
          }
        ],
        "LoadBalancerArn": {"Ref": "ExampleALB"},
        "Port": 80,
        "Protocol": "HTTP"
      }
    },
    "ALBListenerProdRule": {
      "Type": "AWS::ElasticLoadBalancingV2::ListenerRule",
      "Properties": {
        "Actions": [
          {
            "Type": "forward",
            "ForwardConfig": {
              "TargetGroups": [
                {
                  "TargetGroupArn": {"Ref": "ALBTargetGroupBlue"},
                  "Weight": 1
                }
              ]
            }
          }
        ],
        "Conditions": [
          {
            "Field": "http-header",
            "HttpHeaderConfig": {
              "HttpHeaderName": "User-Agent",
              "Values": [
                "Mozilla"
              ]
            }
          }
        ],
        "ListenerArn": {"Ref": "ALBListenerProdTraffic"},
        "Priority": 1
      }
    },
    "ECSTaskExecutionRole": {
      "Type": "AWS::IAM::Role",
      "Properties": {
        "AssumeRolePolicyDocument": {
          "Version": "2012-10-17",		 	 	 
          "Statement": [
            {
              "Sid": "",
              "Effect": "Allow",
              "Principal": {
                "Service": "ecs-tasks.amazonaws.com"
              },
              "Action": "sts:AssumeRole"
            }
          ]
        },
        "ManagedPolicyArns": [
          "arn:aws:iam::aws:policy/service-role/AmazonECSTaskExecutionRolePolicy"
        ]
      }
    },
    "BlueTaskDefinition": {
      "Type": "AWS::ECS::TaskDefinition",
      "Properties": {
        "ExecutionRoleArn": {"Fn::GetAtt": ["ECSTaskExecutionRole", "Arn"]},
        "ContainerDefinitions": [
          {
            "Name": "DemoApp",
            "Image": "nginxdemos/hello:latest",
            "Essential": true,
            "PortMappings": [
              {
                "HostPort": 80,
                "Protocol": "tcp",
                "ContainerPort": 80
              }
            ]
          }
        ],
        "RequiresCompatibilities": [
          "FARGATE"
        ],
        "NetworkMode": "awsvpc",
        "Cpu": "256",
        "Memory": "512",
        "Family": "ecs-demo"
      }
    },
    "ECSDemoCluster": {
      "Type": "AWS::ECS::Cluster",
      "Properties": {}
    },
    "ECSDemoService": {
      "Type": "AWS::ECS::Service",
      "Properties": {
        "Cluster": {"Ref": "ECSDemoCluster"},
        "DesiredCount": 1,
        "DeploymentController": {
          "Type": "EXTERNAL"
        }
      }
    },
    "BlueTaskSet": {
      "Type": "AWS::ECS::TaskSet",
      "Properties": {
        "Cluster": {"Ref": "ECSDemoCluster"},
        "LaunchType": "FARGATE",
        "NetworkConfiguration": {
          "AwsVpcConfiguration": {
            "AssignPublicIp": "ENABLED",
            "SecurityGroups": [
              {"Ref": "ExampleSecurityGroup"}
            ],
            "Subnets": [
              {"Ref": "Subnet1"},
              {"Ref": "Subnet2"}
            ]
          }
        },
        "PlatformVersion": "1.4.0",
        "Scale": {
          "Unit": "PERCENT",
          "Value": 100
        },
        "Service": {"Ref": "ECSDemoService"},
        "TaskDefinition": {"Ref": "BlueTaskDefinition"},
        "LoadBalancers": [
          {
            "ContainerName": "DemoApp",
            "ContainerPort": 80,
            "TargetGroupArn": {"Ref": "ALBTargetGroupBlue"}
          }
        ]
      }
    },
    "PrimaryTaskSet": {
      "Type": "AWS::ECS::PrimaryTaskSet",
      "Properties": {
        "Cluster": {"Ref": "ECSDemoCluster"},
        "Service": {"Ref": "ECSDemoService"},
        "TaskSetId": {"Fn::GetAtt": ["BlueTaskSet", "Id"]}
      }
    }
  }
}
```

## Fasi della migrazione
<a name="migration-steps"></a>

### Rimuovi risorse specifiche CodeDeploy
<a name="remove-codedeploy-resources"></a>

Non sono più necessarie le seguenti proprietà:
+ La `AWS::CodeDeployBlueGreen` trasformata
+ L'hook `CodeDeployBlueGreenHook`
+ Le risorse `GreenTaskDefinition` e `GreenTaskSet` (saranno gestite da Amazon ECS)
+ La risorsa `PrimaryTaskSet` (Amazon ECS gestirà internamente i set di attività)

### Riconfigurazione del listener del bilanciatore del carico
<a name="reconfigure-load-balancer"></a>

Modificare la risorsa `ALBListenerProdTraffic` per utilizzare un'azione di inoltro con due gruppi di destinazione:

```
{
  "DefaultActions": [
    {
      "Type": "forward",
      "ForwardConfig": {
        "TargetGroups": [
          {
            "TargetGroupArn": {"Ref": "ALBTargetGroupBlue"},
            "Weight": 1
          },
          {
            "TargetGroupArn": {"Ref": "ALBTargetGroupGreen"},
            "Weight": 0
          }
        ]
      }
    }
  ]
}
```

### Aggiornare le proprietà di implementazione
<a name="update-ecs-service"></a>

Aggiornare e aggiungere quanto segue:
+ Cambiare la proprietà `DeploymentController` da `EXTERNAL` a `ECS`.
+ Aggiungere la proprietà `Strategy` e impostarla su BLUE\$1GREEN.
+ Aggiungere la proprietà `BakeTimeInMinutes`.

  ```
  {
    "DeploymentConfiguration": {
      "MaximumPercent": 200,
      "MinimumHealthyPercent": 100,
      "DeploymentCircuitBreaker": {
        "Enable": true,
        "Rollback": true
      },
      "BakeTimeInMinutes": 5,
      "Strategy": "BLUE_GREEN"
    }
  }
  ```
+ Aggiungere la configurazione del bilanciatore del carico al servizio:

  ```
  {
    "LoadBalancers": [
      {
        "ContainerName": "DemoApp",
        "ContainerPort": 80,
        "TargetGroupArn": {"Ref": "ALBTargetGroupBlue"},
        "AdvancedConfiguration": {
          "AlternateTargetGroupArn": {"Ref": "ALBTargetGroupGreen"},
          "ProductionListenerRule": {"Ref": "ALBListenerProdRule"},
          "RoleArn": {"Fn::GetAtt": ["ECSInfrastructureRoleForLoadBalancers", "Arn"]}
        }
      }
    ]
  }
  ```
+ Aggiungere il riferimento alla definizione dell'attività al servizio:

  ```
  {
    "TaskDefinition": {"Ref": "BlueTaskDefinition"}
  }
  ```

### Crea il ECSInfrastructure RolePolicyForLoadBalancers ruolo Amazon
<a name="create-ecs-service-role"></a>

Aggiungi un nuovo ruolo IAM che consente ad Amazon ECS di gestire le risorse di bilanciamento del carico. Per ulteriori informazioni, consulta [Ruolo IAM dell'infrastruttura Amazon ECS per i bilanciatori del carico](AmazonECSInfrastructureRolePolicyForLoadBalancers.md)

## Consigli sui test
<a name="testing-recommendations"></a>

1. Implementare il modello migrato in un ambiente non di produzione.

1. Verificare che il servizio venga implementato correttamente con la configurazione iniziale.

1. Testare un'implementazione aggiornando la definizione dell'attività e osservando il processo di implementazione blu/verde.

1. Verificare che il traffico si sposti correttamente tra le implementazioni blu e verdi.

1. Testare la funzionalità di rollback forzando un errore di implementazione.

## Modello dopo la migrazione
<a name="migrated-template"></a>

### Modello finale
<a name="ecs-bluegreen-template"></a>

Questo è il CloudFormation modello completo che utilizza una blue/green distribuzione Amazon ECS:

```
{
  "AWSTemplateFormatVersion": "2010-09-09",
  "Parameters": {
    "Vpc": {
      "Type": "AWS::EC2::VPC::Id"
    },
    "Subnet1": {
      "Type": "AWS::EC2::Subnet::Id"
    },
    "Subnet2": {
      "Type": "AWS::EC2::Subnet::Id"
    }
  },
  "Resources": {
    "ExampleSecurityGroup": {
      "Type": "AWS::EC2::SecurityGroup",
      "Properties": {
        "GroupDescription": "Security group for ec2 access",
        "VpcId": {"Ref": "Vpc"},
        "SecurityGroupIngress": [
          {
            "IpProtocol": "tcp",
            "FromPort": 80,
            "ToPort": 80,
            "CidrIp": "0.0.0.0/0"
          },
          {
            "IpProtocol": "tcp",
            "FromPort": 8080,
            "ToPort": 8080,
            "CidrIp": "0.0.0.0/0"
          },
          {
            "IpProtocol": "tcp",
            "FromPort": 22,
            "ToPort": 22,
            "CidrIp": "0.0.0.0/0"
          }
        ]
      }
    },
    "ALBTargetGroupBlue": {
      "Type": "AWS::ElasticLoadBalancingV2::TargetGroup",
      "Properties": {
        "HealthCheckIntervalSeconds": 5,
        "HealthCheckPath": "/",
        "HealthCheckPort": "80",
        "HealthCheckProtocol": "HTTP",
        "HealthCheckTimeoutSeconds": 2,
        "HealthyThresholdCount": 2,
        "Matcher": {
          "HttpCode": "200"
        },
        "Port": 80,
        "Protocol": "HTTP",
        "Tags": [
          {
            "Key": "Group",
            "Value": "Example"
          }
        ],
        "TargetType": "ip",
        "UnhealthyThresholdCount": 4,
        "VpcId": {"Ref": "Vpc"}
      }
    },
    "ALBTargetGroupGreen": {
      "Type": "AWS::ElasticLoadBalancingV2::TargetGroup",
      "Properties": {
        "HealthCheckIntervalSeconds": 5,
        "HealthCheckPath": "/",
        "HealthCheckPort": "80",
        "HealthCheckProtocol": "HTTP",
        "HealthCheckTimeoutSeconds": 2,
        "HealthyThresholdCount": 2,
        "Matcher": {
          "HttpCode": "200"
        },
        "Port": 80,
        "Protocol": "HTTP",
        "Tags": [
          {
            "Key": "Group",
            "Value": "Example"
          }
        ],
        "TargetType": "ip",
        "UnhealthyThresholdCount": 4,
        "VpcId": {"Ref": "Vpc"}
      }
    },
    "ExampleALB": {
      "Type": "AWS::ElasticLoadBalancingV2::LoadBalancer",
      "Properties": {
        "Scheme": "internet-facing",
        "SecurityGroups": [
          {"Ref": "ExampleSecurityGroup"}
        ],
        "Subnets": [
          {"Ref": "Subnet1"},
          {"Ref": "Subnet2"}
        ],
        "Tags": [
          {
            "Key": "Group",
            "Value": "Example"
          }
        ],
        "Type": "application",
        "IpAddressType": "ipv4"
      }
    },
    "ALBListenerProdTraffic": {
      "Type": "AWS::ElasticLoadBalancingV2::Listener",
      "Properties": {
        "DefaultActions": [
          {
            "Type": "forward",
            "ForwardConfig": {
              "TargetGroups": [
                {
                  "TargetGroupArn": {"Ref": "ALBTargetGroupBlue"},
                  "Weight": 1
                },
                {
                  "TargetGroupArn": {"Ref": "ALBTargetGroupGreen"},
                  "Weight": 0
                }
              ]
            }
          }
        ],
        "LoadBalancerArn": {"Ref": "ExampleALB"},
        "Port": 80,
        "Protocol": "HTTP"
      }
    },
    "ALBListenerProdRule": {
      "Type": "AWS::ElasticLoadBalancingV2::ListenerRule",
      "Properties": {
        "Actions": [
          {
            "Type": "forward",
            "ForwardConfig": {
              "TargetGroups": [
                {
                  "TargetGroupArn": {"Ref": "ALBTargetGroupBlue"},
                  "Weight": 1
                },
                {
                  "TargetGroupArn": {"Ref": "ALBTargetGroupGreen"},
                  "Weight": 0
                }
              ]
            }
          }
        ],
        "Conditions": [
          {
            "Field": "http-header",
            "HttpHeaderConfig": {
              "HttpHeaderName": "User-Agent",
              "Values": [
                "Mozilla"
              ]
            }
          }
        ],
        "ListenerArn": {"Ref": "ALBListenerProdTraffic"},
        "Priority": 1
      }
    },
    "ECSTaskExecutionRole": {
      "Type": "AWS::IAM::Role",
      "Properties": {
        "AssumeRolePolicyDocument": {
          "Version": "2012-10-17",		 	 	 
          "Statement": [
            {
              "Sid": "",
              "Effect": "Allow",
              "Principal": {
                "Service": "ecs-tasks.amazonaws.com"
              },
              "Action": "sts:AssumeRole"
            }
          ]
        },
        "ManagedPolicyArns": [
          "arn:aws:iam::aws:policy/service-role/AmazonECSTaskExecutionRolePolicy"
        ]
      }
    },
    "ECSInfrastructureRoleForLoadBalancers": {
      "Type": "AWS::IAM::Role",
      "Properties": {
        "AssumeRolePolicyDocument": {
          "Version": "2012-10-17",		 	 	 
          "Statement": [
            {
              "Sid": "AllowAccessToECSForInfrastructureManagement",
              "Effect": "Allow",
              "Principal": {
                "Service": "ecs.amazonaws.com"
              },
              "Action": "sts:AssumeRole"
            }
          ]
        },
        "ManagedPolicyArns": [
          "arn:aws:iam::aws:policy/AmazonECSInfrastructureRolePolicyForLoadBalancers"
        ]
      }
    },
    "BlueTaskDefinition": {
      "Type": "AWS::ECS::TaskDefinition",
      "Properties": {
        "ExecutionRoleArn": {"Fn::GetAtt": ["ECSTaskExecutionRole", "Arn"]},
        "ContainerDefinitions": [
          {
            "Name": "DemoApp",
            "Image": "nginxdemos/hello:latest",
            "Essential": true,
            "PortMappings": [
              {
                "HostPort": 80,
                "Protocol": "tcp",
                "ContainerPort": 80
              }
            ]
          }
        ],
        "RequiresCompatibilities": [
          "FARGATE"
        ],
        "NetworkMode": "awsvpc",
        "Cpu": "256",
        "Memory": "512",
        "Family": "ecs-demo"
      }
    },
    "ECSDemoCluster": {
      "Type": "AWS::ECS::Cluster",
      "Properties": {}
    },
    "ECSDemoService": {
      "Type": "AWS::ECS::Service",
      "Properties": {
        "Cluster": {"Ref": "ECSDemoCluster"},
        "DesiredCount": 1,
        "DeploymentController": {
          "Type": "ECS"
        },
        "DeploymentConfiguration": {
          "MaximumPercent": 200,
          "MinimumHealthyPercent": 100,
          "DeploymentCircuitBreaker": {
            "Enable": true,
            "Rollback": true
          },
          "BakeTimeInMinutes": 5,
          "Strategy": "BLUE_GREEN"
        },
        "NetworkConfiguration": {
          "AwsvpcConfiguration": {
            "AssignPublicIp": "ENABLED",
            "SecurityGroups": [
              {"Ref": "ExampleSecurityGroup"}
            ],
            "Subnets": [
              {"Ref": "Subnet1"},
              {"Ref": "Subnet2"}
            ]
          }
        },
        "LaunchType": "FARGATE",
        "PlatformVersion": "1.4.0",
        "TaskDefinition": {"Ref": "BlueTaskDefinition"},
        "LoadBalancers": [
          {
            "ContainerName": "DemoApp",
            "ContainerPort": 80,
            "TargetGroupArn": {"Ref": "ALBTargetGroupBlue"},
            "AdvancedConfiguration": {
              "AlternateTargetGroupArn": {"Ref": "ALBTargetGroupGreen"},
              "ProductionListenerRule": {"Ref": "ALBListenerProdRule"},
              "RoleArn": {"Fn::GetAtt": ["ECSInfrastructureRoleForLoadBalancers", "Arn"]}
            }
          }
        ]
      }
    }
  }
}
```

# Migrazione da una distribuzione di servizi di aggiornamento in sequenza di Amazon ECS CodeDeploy blu/verde a una distribuzione del servizio di aggiornamento continuo di Amazon ECS
<a name="migrate-code-deploy-to-ecs-rolling"></a>

 Puoi migrare le tue distribuzioni di servizi da una distribuzione CodeDeploy blu/verde a una distribuzione di aggiornamenti continui di Amazon ECS. In questo modo puoi passare dalla CodeDeploy dipendenza all'utilizzo di una distribuzione integrata.

Il pianificatore di servizi di Amazon ECS sostituisce le attività attualmente in esecuzione con nuove attività. Il numero di attività che Amazon ECS aggiunge o rimuove dal servizio durante un aggiornamento continuo è controllato dalla configurazione di distribuzione del servizio.

## Prerequisiti
<a name="migrate-code-deploy-to-ecs-rolling-prerequisites"></a>

Esegui le seguenti operazioni prima di iniziare una blue/green distribuzione. 

1. Non è più necessario il ruolo CodeDeploy IAM di Amazon ECS.

1. Disattiva l' CodeDeploy automazione. Per ulteriori informazioni, consulta [Lavorare con i gruppi di distribuzione CodeDeploy nella](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployment-groups.html) *Guida CodeDeploy per l'utente*.

1. Verificare che non vi siano implementazioni di servizi in corso per il servizio. Per ulteriori informazioni, consultare [Visualizza la cronologia dei servizi utilizzando le distribuzioni dei servizi Amazon ECS](service-deployment.md).

Per ulteriori informazioni sull'aggiornamento di un controller di implementazione del servizio, consultare [Aggiornare i parametri del servizio Amazon ECS](update-service-parameters.md).

## Procedura
<a name="migrate-code-deploy-to-ecs-rolling-procedure"></a>

1. Apri la console nella [https://console.aws.amazon.com/ecs/versione 2](https://console.aws.amazon.com/ecs/v2).

1. Nella pagina **Cluster**, scegliere il cluster.

   Si apre la pagina dei dettagli del cluster.

1. Dalla scheda **Servizi**, scegliere il servizio.

   Si apre la pagina dei dettagli del servizio.

1. Nel banner, scegliere **Migra**.

   Si apre la pagina **Aggiorna configurazione di implementazione**.

1. Espandere **Opzioni di implementazione**, quindi specificare i seguenti parametri.

   1. Per **Tipo di controller di implementazione**, scegliere **ECS**.

   1. Per **Strategia di implementazione**, scegliere **Aggiornamento in sequenza**.

   1. Per **Min running tasks** (Numero minimo di attività in esecuzione), specifica il limite inferiore per il numero di attività nel servizio che devono rimanere nello stato `RUNNING` durante un'implementazione, espresso come percentuale del numero di attività desiderate (arrotondata per eccesso al numero intero più vicino). Per ulteriori informazioni, consultare [Deployment configuration](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service_definition_parameters.html#sd-deploymentconfiguration).

   1. Per **Max running tasks** (Numero massimo di attività in esecuzione), specifica il limite superiore per il numero di attività del servizio consentite nello stato `RUNNING` o `PENDING` durante un'implementazione, espresso come percentuale del numero di attività desiderate (arrotondata per difetto al numero intero più vicino).

1. Espandere **Bilanciamento del carico** e configurare quanto segue:

   1. Per **Ruolo**, scegli il ruolo che hai creato nei prerequisiti con le blue/green autorizzazioni.

      Per ulteriori informazioni, consulta [Autorizzazioni richieste per le funzioni Lambda nelle distribuzioni Amazon ECS blue/green](blue-green-permissions.md).

   1. Per **Listener**, scegli il listener di produzione dalla tua distribuzione blu/verde. CodeDeploy 

   1. Per **Target group**, scegli il gruppo target di produzione dalla tua implementazione blu/verde. CodeDeploy 

1. Scegliere **Aggiorna**.

## Fasi successive
<a name="migrate-code-deploy-to-ecs-rolling-next-steps"></a>

È necessario aggiornare il servizio affinché venga applicata la modifica. Per ulteriori informazioni, consultare [Aggiornamento di un servizio Amazon ECS](update-service-console-v2.md).

# Aggiornare la strategia di implementazione di Amazon ECS
<a name="migrate-deployment-strategies"></a>

Amazon ECS supporta diverse strategie di implementazione per l'aggiornamento dei servizi. È possibile migrare tra queste strategie in base ai requisiti delle applicazioni. Questo argomento spiega come migrare tra distribuzioni continue e distribuzioni. blue/green 

## Informazioni sulle strategie di implementazione di Amazon ECS
<a name="deployment-strategies-overview"></a>

Prima di migrare da una strategia di implementazione all'altra, è importante capire come funziona ciascuna strategia e le relative differenze principali:

**Implementazioni in sequenza**  
In un'implementazione in sequenza, Amazon ECS sostituisce la versione attuale in esecuzione dell'applicazione con una nuova. Il pianificatore del servizio utilizza i parametri di percentuale minima di attività integre e percentuale massima per determinare la strategia di implementazione.  
Le implementazioni in sequenza sono più semplici da configurare ma offrono un minore controllo sul processo di implementazione e sull'instradamento del traffico.

**Implementazioni blu/verdi**  
In una blue/green distribuzione, Amazon ECS crea una nuova versione del servizio (verde) accanto alla versione esistente (blu). Ciò consente di verificare la nuova versione prima di instradarvi il traffico di produzione.  
Le implementazioni blu/verdi offrono un maggiore controllo sul processo di implementazione, comprese le funzionalità di spostamento del traffico, di test e rollback.

## Best practice
<a name="migration-best-practices"></a>

Seguire queste best practice quando si esegue la migrazione tra diverse strategie di implementazione:
+ **Esegui il test in un ambiente non di produzione**: verificare sempre l'aggiornamento in un ambiente non di produzione prima di applicare modifiche ai servizi di produzione.
+ **Pianifica il rollback**: disporre di un piano di rollback nel caso in cui l'aggiornamento non funzioni come previsto.
+ **Monitoraggio durante la transizione**: monitorare attentamente il servizio durante e dopo la migrazione per assicurarsi che continui a funzionare correttamente.
+ **Aggiornamento della documentazione**: aggiornare la documentazione di implementazione in modo tale che rifletta la nuova strategia di implementazione.
+ **Considera l'impatto sul traffico**: informazioni sul modo in cui l'aggiornamento potrebbe influire sul traffico verso il servizio e pianificare di conseguenza.

# Aggiornare la strategia di implementazione dall'aggiornamento in sequenza ad Amazon ECS blu/verde
<a name="update-rolling-to-bluegreen"></a>

Puoi migrare da una distribuzione di aggiornamento continuo a una distribuzione Amazon ECS blue/green quando desideri apportare e testare modifiche ai servizi prima di implementarle in un ambiente di produzione. 

## Prerequisiti
<a name="update-rolling-to-bluegreen-prerequisites"></a>

Prima di migrare il servizio dalla distribuzione progressiva a quella di blue/green distribuzione, assicurati di disporre di quanto segue:
+  Attendere il completamento delle implementazioni attuali. 
+ Un servizio Amazon ECS esistente che utilizza la strategia di implementazione in sequenza.
+ Se si dispone di più revisioni del servizio che servono il traffico, Amazon ECS tenta di consolidare il traffico in un'unica revisione durante la migrazione. Se questa operazione ha esito negativo, potrebbe essere necessario aggiornare manualmente il servizio per utilizzare una singola revisione prima della migrazione.
+ Configurazione delle autorizzazioni appropriate.
  + Per informazioni sulle autorizzazioni di bilanciamento del carico elastico, consultare [Ruolo IAM dell'infrastruttura Amazon ECS per i bilanciatori del carico](AmazonECSInfrastructureRolePolicyForLoadBalancers.md).
  + Per informazioni sulle autorizzazioni Lambda, consultare [Autorizzazioni richieste per le funzioni Lambda nelle distribuzioni Amazon ECS blue/green](blue-green-permissions.md).
+ A seconda della configurazione, è necessario eseguire una delle seguenti operazioni:
  + Se il servizio utilizza il bilanciamento del carico elastico, aggiornare il servizio con la nuova “advancedConfiguration” e avviare un'implementazione in sequenza. 
  + Se il servizio utilizza Service Connect, aggiornarlo e avviare un'implementazione in sequenza. 
  + Se il tuo servizio utilizza sia Elastic Load Balancing che Service Connect, esegui entrambi i passaggi precedenti (puoi usare una sola UpdateService richiesta). 
  + Se il servizio non utilizza nessuna delle opzioni precedenti, non è necessaria alcuna operazione aggiuntiva.
+ Le blue/green implementazioni di Amazon ECS richiedono che il servizio utilizzi una delle seguenti funzionalità. 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).

## Procedura
<a name="update-rolling-to-bluegreen-procedure"></a>

1. Aprire la console Amazon ECS in [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2).

1. Nel pannello di navigazione scegliere **Cluster**.

1. Nella pagina **Cluster**, scegliere il cluster che contiene il servizio su cui eseguire la migrazione.

   Si apre la pagina dei dettagli del cluster.

1. Nella pagina **Dettagli cluster**, scegliere la scheda **Servizi**.

1. Scegliere il servizio, poi selezionare **Aggiorna**.

   Si apre la pagina Aggiorna servizio.

1. Espandere **Opzioni di implementazione**, poi svolgere le seguenti operazioni:

1. Per **Strategia di implementazione**, scegliere **Blu/verde**.

1. Configura le impostazioni di distribuzione blue/green :

   1. Per **Tempo di incorporamento**, inserire il numero di minuti in cui entrambe le revisioni del servizio blu e verde verranno eseguite contemporaneamente prima che la revisione blu venga terminata. 

      Ciò consente di avere tempo per la verifica e il test.

   1. (Facoltativo) Configurare le funzioni Lambda in fasi specifiche dell'implementazione. In **Hook del ciclo di vita di implementazione**, configurare le funzioni Lambda per le seguenti fasi:
      + **Prima dell'aumento verticale**: viene eseguita prima di scalare la revisione del servizio verde
      + **Dopo l'aumento verticale**: viene eseguita prima di scalare la revisione del servizio verde
      + **Spostamento del traffico di test**: viene eseguito durante l'instradamento del traffico di test alla revisione del servizio verde.
      + **Spostamento del traffico dopo il test**: viene eseguito dopo che il traffico di test è stato instradato alla revisione del servizio verde.
      + **Spostamento del traffico di produzione**: viene eseguito durante l'instradamento del traffico di produzione alla revisione del servizio verde.
      + **Spostamento del traffico dopo la produzione**: viene eseguito dopo che il traffico di produzione è stato instradato alla revisione del servizio verde.

      Per aggiungere un hook del ciclo di vita:

      1. Scegliere **Aggiungi**.

      1. Per **Funzione Lambda**, immettere il nome della funzione o ARN.

      1. Per **Ruolo**, scegliere il ruolo IAM che ha il permesso di invocare la funzione Lambda.

      1. Per **Fasi del ciclo di vita**, selezionare le fasi in cui deve essere eseguita la funzione Lambda.

      1. (Facoltativo) Per **Dettagli dell'hook**, inserire una coppia chiave-valore per fornire informazioni aggiuntive all'hook.

1. Configurazione delle impostazioni del bilanciatore del carico:

   1. In **bilanciatore del carico**, verificare che il servizio sia configurato per utilizzare un bilanciatore del carico.

   1. Per **Gruppo di destinazione**, scegliere il gruppo di destinazione primario per l'ambiente di produzione (blu).

   1. Per **Gruppo di destinazione alternativo**, scegliere il gruppo di destinazione per l'ambiente di test (verde).

   1. Per **Regola del listener di produzione**, scegliere la regola del listener per l'instradamento del traffico di produzione.

   1. (Facoltativo) Per **Regola del listener di test**, scegliere una regola del listener per instradare il traffico di test verso l'ambiente verde.

   1. Per **Ruolo**, scegliere il ruolo IAM che consente ad Amazon ECS di gestire il bilanciatore del carico.

1. Rivedere le modifiche alla configurazione, quindi scegliere **Aggiorna**.

## Fasi successive
<a name="update-rolling-to-bluegreen-next-steps"></a>
+ Aggiornare il servizio per avviare l'implementazione. Per ulteriori informazioni, consulta [Aggiornamento di un servizio Amazon ECS](update-service-console-v2.md).
+ Monitora il processo di distribuzione per assicurarti che segua lo blue/green schema:
  + La revisione del servizio verde viene creata e aumentata verticalmente
  + Il traffico di test viene instradato alla revisione verde (se configurata)
  + Il traffico di produzione viene spostato alla revisione del servizio verde
  + Dopo il tempo di incorporamento, la revisione blu viene interrotta

# Aggiornamento della strategia di distribuzione da Amazon ECS blue/green all'aggiornamento progressivo
<a name="update-bluegreen-to-rolling"></a>

Puoi migrare una blue/green distribuzione a una distribuzione con aggiornamento progressivo.

Quando si esegue la migrazione a implementazioni in sequenza, tenere presente le seguenti considerazioni:
+ **Gestione del traffico**: con le implementazioni in sequenza, le nuove attività iniziano a ricevere traffico non appena superano i controlli dell'integrità. Non è prevista una fase di test separata come per le blue/green distribuzioni.
+ **Efficienza delle risorse**: le implementazioni in sequenza in genere utilizzano meno risorse rispetto alle blue/green distribuzioni perché sostituiscono le attività in modo incrementale anziché creare un ambiente duplicato completo.
+ **Complessità del rollback**: le implementazioni continue rendono i rollback più complessi rispetto alle implementazioni. blue/green Se è necessario eseguire il rollback, occorre avviare una nuova implementazione con la definizione dell'attività precedente.
+ **Velocità di implementazione**: il completamento delle implementazioni in sequenza può richiedere più tempo rispetto alle blue/green implementazioni, soprattutto per i servizi con molte attività.
+ **Configurazione del bilanciatore del carico**: la configurazione del bilanciatore del carico esistente continuerà a funzionare con le implementazioni in sequenza, ma il comportamento di spostamento del traffico sarà diverso.

## Prerequisiti
<a name="update-bluegreen-to-rolling-prerequisites"></a>

Prima di migrare il servizio da implementazioni continue, blue/green assicurati di disporre di quanto segue:
+ Un servizio Amazon ECS esistente che utilizza la strategia di blue/green distribuzione
+ Nessuna implementazione in corso per il servizio (attendere il completamento delle implementazioni attuali)
+ Una chiara comprensione del comportamento del servizio con le implementazioni in sequenza

**Nota**  
Non è possibile eseguire la migrazione di un servizio all'implementazione in sequenza se dispone di un'implementazione in corso. Attendere il completamento delle implementazioni attuali prima di procedere.

## Procedura di migrazione
<a name="update-bluegreen-to-rolling-procedure"></a>

Segui questi passaggi per migrare il tuo servizio Amazon ECS blue/green da distribuzioni continue:

1. Aprire la console Amazon ECS in [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2).

1. Nel pannello di navigazione scegliere **Cluster**.

1. Nella pagina **Cluster**, scegliere il cluster che contiene il servizio su cui eseguire la migrazione.

1. Nella pagina **Dettagli cluster**, scegliere la scheda **Servizi**.

1. Selezionare il servizio da migrare, quindi scegliere **Aggiorna**.

1. Nella pagina **Aggiorna servizio**, andare alla sezione **Opzioni di implementazione** ed espanderla se necessario.

1. Per **Strategia di implementazione**, scegliere **Aggiornamento in sequenza**.

1. Configurare le impostazioni di implementazione in sequenza:

   1. Per **Percentuale minima di integrità**, inserire la percentuale minima di attività che devono rimanere nello stato `RUNNING` durante un'implementazione. Questo valore è specificato come una percentuale del numero desiderato di attività per il servizio.

   1. Per **Percentuale massima**, inserire la percentuale massima di attività consentite nello stato `RUNNING` o `PENDING` durante un'implementazione. Questo valore è specificato come una percentuale del numero desiderato di attività per il servizio.

1. Facoltativo: in **Rilevamento degli errori di implementazione**, configurare il modo in cui Amazon ECS rileva e gestisce gli errori di implementazione.

   1. Per abilitare l'interruttore automatico di implementazione, scegliere **Usa l'interruttore automatico di implementazione**.

   1. Per effettuare il rollback automatico delle implementazioni non riuscite, scegliere **Rollback in caso di errore**.

1. Rivedere le modifiche alla configurazione, quindi scegliere **Aggiorna** per salvare le modifiche ed eseguire la migrazione del servizio all'implementazione in sequenza.

Amazon ECS aggiornerà la configurazione del servizio per utilizzare la strategia di implementazione in sequenza. Al prossimo aggiornamento del servizio, questo utilizzerà il processo di implementazione in sequenza.

**Nota**  
Quando esegui la migrazione blue/green da una distribuzione progressiva, Amazon ECS gestisce la transizione mediante:  
Identificazione dell'attuale revisione attiva del servizio che serve il traffico.
Mantenendo la configurazione esistente del bilanciatore del carico ma modificando il modo in cui vengono gestite le nuove implementazioni.
Preparazione del servizio per le future implementazioni in sequenza.

## Fasi successive
<a name="update-bluegreen-to-rolling-next-steps"></a>
+ Aggiornare il servizio per avviare l'implementazione. Per ulteriori informazioni, consultare [Aggiornamento di un servizio Amazon ECS](update-service-console-v2.md).

# Risoluzione dei problemi relativi agli aggiornamenti della strategia di implementazione di Amazon ECS
<a name="troubleshooting-deployment-controller-migration"></a>

Questa sezione fornisce soluzioni ai problemi più comuni che potrebbero verificarsi durante la migrazione delle strategie di implementazione.

## Più revisioni del servizio o set di attività
<a name="troubleshooting-multiple-task-sets"></a>

I seguenti problemi riguardano la disponibilità di più revisioni dei servizi per un'implementazione.

Set di più attività durante l'aggiornamento del controller di implementazione ECS  
*Messaggio di errore*: `Updating the deployment controller is not supported when there are multiple tasksets in the service. Please ensure your service has only one taskset and try again.`  
*Soluzione*: questo errore si verifica quando si tenta di modificare il tipo di controller di implementazione di un servizio con più set di attività attivi. Per risolvere questo problema per il controller di implementazione `CODE_DEPLOY` o `EXTERNAL`:  

1. Controllare i set di attività attuali:

   ```
   aws ecs describe-services --cluster your-cluster-name --services your-service-name --query "services[0].taskSets"
   ```

1. Attendere il completamento delle implementazioni in corso.

1. Forzare una nuova implementazione per eliminare i set di attività:

   ```
   aws ecs update-service --cluster your-cluster-name --service your-service-name --force-new-deployment
   ```

1. Se necessario, eliminare manualmente i set di attività aggiuntivi:

   ```
   aws ecs delete-task-set --cluster your-cluster-name --service your-service-name --task-set task-set-id
   ```

1. Quando rimane un solo set di attività, riprovare ad aggiornare il controller di implementazione.
Per ulteriori informazioni, consultare [Controller e strategie di implementazione dei servizi Amazon ECS](ecs_service-options.md).

Set di attività primarie mancante durante l'aggiornamento del controller di implementazione `ECS`  
*Messaggio di errore*: `Updating the deployment controller requires a primary taskset in the service. Please ensure your service has a primary taskset and try again.`  
*Soluzione*: questo errore si verifica quando si tenta di modificare il tipo di controller di implementazione di un servizio che non dispone di un set di attività primarie. Per risolvere il problema:  

1. Verificare lo stato del servizio e i set di attività. Se nel servizio esiste un set di attività, deve essere contrassegnato come `ACTIVE`. 

   ```
   aws ecs describe-services --cluster your-cluster-name --services your-service-name --query "services[0].taskSets[*].[status,id]
   ```

   Se non ci sono set di attività nello stato `ACTIVE`, effettuare la migrazione dell'implementazione. Per ulteriori informazioni, consultare [Migration approaches](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/migrate-codedeploy-to-ecs-bluegreen.html#migration-paths). 

1. Se il servizio non dispone di attività in esecuzione, implementare almeno un'attività aggiornando il servizio:

   ```
   aws ecs update-service-primary-task-set --cluster your-cluster-name --service your-service-name --primary-task-set your-taskset-id
   ```

   Ciò contrassegnerà l'attività (precedentemente `ACTIVE`) impostata nel servizio come `PRIMARY`.

1. Attendere che l'attività raggiunga uno stato di esecuzione stabile. È possibile controllare lo stato con:

   ```
   aws ecs describe-services --cluster your-cluster-name --services your-service-name --query "services[0].deployments"
   ```

1. Dopo che il servizio dispone di un set di attività primario con attività in esecuzione, riprovare ad aggiornare il controller di implementazione.
Per ulteriori informazioni, consultare [Controller e strategie di implementazione dei servizi Amazon ECS](ecs_service-options.md).

## Mancata corrispondenza tra il tipo di rilevamento degli errori di implementazione e il controller di implementazione
<a name="troubleshooting-failure-detection"></a>

I seguenti problemi si riferiscono a una mancata corrispondenza tra il tipo di rilevamento degli errori di implementazione e il controller di implementazione.

Interruttore automatico di implementazione con controller non ECS  
*Messaggio di errore*: `Deployment circuit breaker feature is only supported with ECS deployment controller. Update to ECS deployment controller and try again.`  
*Soluzione*: questo errore si verifica quando si tenta di abilitare la funzionalità di interruttore automatico di implementazione su un servizio che non utilizza il controller di implementazione `ECS`. L'interruttore automatico di implementazione è compatibile solo con il controller di implementazione `ECS`.  

1. Verificare il controller di implementazione attuale del servizio:

   ```
   aws ecs describe-services --cluster your-cluster-name --services your-service-name --query "services[0].deploymentController"
   ```

1. Aggiornare il servizio per utilizzare il controller di implementazione `ECS`:

   ```
   aws ecs update-service --cluster your-cluster-name --service your-service-name --deployment-controller type=ECS
   ```

1. Dopo che il servizio sta utilizzando il controller di implementazione `ECS`, abilitare l'interruttore automatico di implementazione:

   ```
   aws ecs update-service --cluster your-cluster-name --service your-service-name --deployment-configuration "deploymentCircuitBreaker={enable=true,rollback=true}"
   ```
Per ulteriori informazioni, consultare [In che modo l’interruttore di implementazione Amazon ECS rileva i guasti](deployment-circuit-breaker.md).

Rollback basato sugli allarmi con controller non ECS  
*Messaggio di errore*: `Alarm based rollback feature is only supported with ECS deployment controller. Update to ECS deployment controller and try again.`  
*Soluzione*: questo errore si verifica quando si tenta di configurare il rollback basato sugli allarmi su un servizio che non utilizza il controller di implementazione `ECS`. La funzionalità di rollback basata sugli allarmi è compatibile solo con il controller di implementazione `ECS`.  

1. Verificare il controller di implementazione attuale del servizio:

   ```
   aws ecs describe-services --cluster your-cluster-name --services your-service-name --query "services[0].deploymentController"
   ```

1. Aggiornare il servizio per utilizzare il controller di implementazione `ECS`:

   ```
   aws ecs update-service --cluster your-cluster-name --service your-service-name --deployment-controller type=ECS
   ```

1. Dopo che il servizio sta utilizzando il controller di implementazione `ECS`, configurare il rollback basato sugli allarmi:

   ```
   aws ecs update-service --cluster your-cluster-name --services your-service-name --deployment-configuration "alarms={alarmNames=[your-alarm-name],enable=true,rollback=true}"
   ```
Per ulteriori informazioni, consultare [In che modo CloudWatch gli allarmi rilevano gli errori di distribuzione di Amazon ECS](deployment-alarm-failure.md).

## Mancata corrispondenza tra Service Connect e il controller di implementazione
<a name="troubleshooting-service-connect-mismatch"></a>

I seguenti problemi riguardano una mancata corrispondenza tra Service Connect e il controller di implementazione.

Controller `EXTERNAL` con Service Connect  
*Messaggio di errore*: `The EXTERNAL deployment controller type is not supported for services using Service Connect.`  
*Soluzione*: questo errore si verifica quando si tenta di utilizzare il controller di implementazione `EXTERNAL` con un servizio che ha Service Connect abilitato. Il controller `EXTERNAL` non è compatibile con Service Connect.  

1. Verificare se il servizio dispone di Service Connect abilitato:

   ```
   aws ecs describe-services --cluster your-cluster-name --services your-service-name --query "services[0].serviceConnectConfiguration"
   ```

1. Se è necessario il controller di implementazione `EXTERNAL`, disabilitare Service Connect aggiornando il servizio:

   ```
   aws ecs update-service --cluster your-cluster-name --service your-service-name --service-connect-configuration "{}"
   ```

1. In alternativa, se è necessario utilizzare Service Connect, utilizzare invece il controller di implementazione `ECS`:

   ```
   aws ecs update-service --cluster your-cluster-name --service your-service-name --deployment-controller type=ECS
   ```
Per ulteriori informazioni, consultare [Controller e strategie di implementazione dei servizi Amazon ECS](ecs_service-options.md).

Service Connect con controller non ECS  
*Messaggio di errore*: `Service Connect feature is only supported with ECS (rolling update) deployment controller. Update to ECS deployment controller and try again.`  
*Soluzione*: questo errore si verifica quando si tenta di abilitare Service Connect su un servizio che non utilizza il controller di implementazione `ECS`. La funzionalità di Service Connect è compatibile solo con il controller di implementazione `ECS`.  

1. Verificare il controller di implementazione attuale del servizio:

   ```
   aws ecs describe-services --cluster your-cluster-name --services your-service-name --query "services[0].deploymentController"
   ```

1. Aggiornare il servizio per utilizzare il controller di implementazione ECS:

   ```
   aws ecs update-service --cluster your-cluster-name --service your-service-name --deployment-controller type=ECS
   ```

1. Una volta che il servizio utilizza il controller di implementazione ECS, abilitare Service Connect:

   ```
   aws ecs update-service --cluster your-cluster-name --service your-service-name --service-connect-configuration "enabled=true,namespace=your-namespace"
   ```
Per ulteriori informazioni, consultare [Controller e strategie di implementazione dei servizi Amazon ECS](ecs_service-options.md).

## Mancata corrispondenza tra il tipo di controller e la strategia di pianificazione
<a name="troubleshooting-controller-type-scheduling"></a>

I seguenti problemi riguardano una mancata corrispondenza tra il tipo di controller e la strategia di pianificazione.

Controller `CODE_DEPLOY` con strategia di pianificazione `DAEMON`  
*Messaggio di errore*: `The CODE_DEPLOY deployment controller type is not supported for services using the DAEMON scheduling strategy.`  
*Soluzione*: questo errore si verifica quando si tenta di utilizzare il controller di implementazione CODE\$1DEPLOY con un servizio che utilizza la strategia di pianificazione `DAEMON`. Il controller `CODE_DEPLOY` è compatibile solo con la strategia di pianificazione `REPLICA`.  

1. Verificare l'attuale strategia di pianificazione del servizio:

   ```
   aws ecs describe-services --cluster your-cluster-name --services your-service-name --query "services[0].schedulingStrategy"
   ```

1. Se hai bisogno di blue/green implementazioni, modifica il servizio per utilizzare la strategia di pianificazione: `REPLICA`

   ```
   aws ecs update-service --cluster your-cluster-name --service your-service-name --scheduling-strategy REPLICA
   ```

1. In alternativa, se è necessario utilizzare la strategia di pianificazione `DAEMON`, utilizzare invece il controller di implementazione `ECS`:

   ```
   aws ecs update-service --cluster your-cluster-name --service your-service-name --deployment-controller type=ECS
   ```
Per ulteriori informazioni, consultare [Controller e strategie di implementazione dei servizi Amazon ECS](ecs_service-options.md).

Controller EXTERNAL con strategia di pianificazione DAEMON  
*Messaggio di errore*: `The EXTERNAL deployment controller type is not supported for services using the DAEMON scheduling strategy.`  
*Soluzione*: questo errore si verifica quando si tenta di utilizzare il controller di implementazione ESTERNO con un servizio ECS che utilizza la strategia di pianificazione DAEMON. Il controller EXTERNAL è compatibile solo con la strategia di pianificazione REPLICA.  

1. Verificare l'attuale strategia di pianificazione del servizio:

   ```
   aws ecs describe-services --cluster your-cluster-name --services your-service-name --query "services[0].schedulingStrategy"
   ```

1. Se è necessario utilizzare il controller di implementazione `EXTERNAL`, cambiare il servizio per utilizzare la strategia di pianificazione `REPLICA`:

   ```
   aws ecs update-service --cluster your-cluster-name --service your-service-name --scheduling-strategy REPLICA
   ```

1. In alternativa, se è necessario utilizzare la strategia di pianificazione `DAEMON`, utilizzare invece il controller di implementazione `ECS`:

   ```
   aws ecs update-service --cluster your-cluster-name --service your-service-name --deployment-controller type=ECS
   ```
Per ulteriori informazioni, consultare [Controller e strategie di implementazione dei servizi Amazon ECS](ecs_service-options.md).

Registri di servizio con tipo di avvio esterno  
*Messaggio di errore*: `Service registries are not supported for external launch type.`  
*Soluzione*: questo errore avviene quando si tenta di configurare il rilevamento servizi (registri dei servizi) per un servizio che utilizza il tipo di avvio `EXTERNAL`. Il rilevamento servizi non è compatibile con il tipo di avvio `EXTERNAL`.  

1. Controllare il tipo di avvio attuale del servizio:

   ```
   aws ecs describe-services --cluster your-cluster-name --services your-service-name --query "services[0].launchType"
   ```

1. Se è necessario il rilevamento servizi, modificare il servizio in modo da utilizzare il tipo di avvio `EC2` o `FARGATE`:

   ```
   aws ecs update-service --cluster your-cluster-name --service your-service-name --launch-type FARGATE
   ```

1. In alternativa, se è necessario utilizzare il tipo di avvio `EXTERNAL`, rimuovere la configurazione del registro del servizio:

   ```
   aws ecs update-service --cluster your-cluster-name --service your-service-name --service-registries "[]"
   ```
Per ulteriori informazioni, consultare [Controller e strategie di implementazione dei servizi Amazon ECS](ecs_service-options.md).

## Ripristinare un aggiornamento del controller di implementazione
<a name="troubleshooting-revert"></a>

Se si decide di tornare al controller di implementazione precedente, è possibile eseguire una delle seguenti operazioni:
+ Se lo hai utilizzato CloudFormation, puoi utilizzare il modello precedente per creare un nuovo stack. Per ulteriori informazioni, consultare [Create a stack from](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-create-stack.html) nella *Guida per l'utente di CloudFormation *.
+ Se hai utilizzato la console Amazon ECS o la AWS CLI, puoi aggiornare il servizio. Per ulteriori informazioni, consulta [Aggiornamento di un servizio Amazon ECS](update-service-console-v2.md).

  Se si utilizza il comando update-service, usare l'opzione `--deployment-controller` e impostarla sul controller di implementazione precedente.

# Visualizza la cronologia dei servizi utilizzando le distribuzioni dei servizi Amazon ECS
<a name="service-deployment"></a>

Le implementazioni dei servizi forniscono una visione completa delle implementazioni. Le implementazioni dei servizi forniscono le informazioni seguenti sul servizio:
+ La configurazione del carico di lavoro attualmente implementata (la revisione del servizio di origine)
+ La configurazione del carico di lavoro in fase di implementazione (la revisione del servizio di destinazione)
+ Lo stato dell'implementazione
+ Il numero di attività non riuscite rilevate dall'interruzione del circuito
+ Gli CloudWatch allarmi che sono in allarme
+ Quando l'implementazione del servizio è iniziata e completata
+ I dettagli di un eventuale rollback

Per informazioni sulle proprietà di implementazione del servizio, consultare [Proprietà incluse in un'implementazione del servizio Amazon ECS](service-deployment-property.md).

Le implementazioni dei servizi sono di sola lettura e ciascuna dispone di un ID univoco. 

Vi sono tre fasi di implementazione del servizio:


| Stage | Definizione | Stati associati | 
| --- | --- | --- | 
| Pending (In attesa) | È stata creata un'implementazione del servizio, ma non è stata avviata | IN ATTESA | 
| Continua | Un'implementazione del servizio è in corso |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonECS/latest/developerguide/service-deployment.html)  | 
| Completato  | Un'implementazione del servizio è terminata (con successo o meno) |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonECS/latest/developerguide/service-deployment.html)  | 

Le implementazioni dei servizi vengono utilizzate per comprendere il ciclo di vita del servizio e determinare se vi sono azioni da intraprendere. Ad esempio, se si verifica un rollback, potrebbe essere necessario esaminare l'implementazione del servizio ed esaminare gli eventi del servizio.

È possibile visualizzare la cronologia di 90 giorni più recente per le implementazioni create il o dopo il 25 ottobre 2024 utilizzando la console, l'API e la AWS CLI. 

È possibile interrompere un'implementazione non completata. Per ulteriori informazioni, consultare [Interruzione delle implementazioni dei servizi Amazon ECS](stop-service-deployment.md).

## Ciclo di vita dell'implementazione dei servizi
<a name="service-deployments-lifecycle"></a>

Amazon ECS crea automaticamente una nuova implementazione di servizi quando si verifica una delle seguenti operazioni:
+ Un utente crea un servizio.
+ Un utente aggiorna il servizio e utilizza l'opzione Forza nuova implementazione.
+ Un utente aggiorna una o più proprietà del servizio che richiedono un'implementazione.

Mentre un'implementazione è in corso, Amazon ECS aggiorna le seguenti proprietà di implementazione del servizio per riflettere i progressi dell'implementazione del servizio:
+ Lo stato
+ Il numero di attività in esecuzione

  Il numero di attività in esecuzione indicato nella revisione del servizio potrebbe non corrispondere al numero effettivo di attività in esecuzione. Questo numero rappresenta il numero di attività in esecuzione al termine dell'implementazione. Ad esempio, se sono state avviate attività indipendentemente dall’implementazione del servizio, tali attività non vengono incluse nel conteggio delle attività in esecuzione per la revisione del servizio.
+ Rilevamento di guasti all'interruttore automatico:
  + Il numero di attività non riuscite
+ CloudWatch rilevamento dei guasti degli allarmi
  + Gli allarmi che sono attivi
+ Informazioni di rollback:
  + L'ora di inizio
  + Il motivo del rollback
  + L'ARN della revisione del servizio utilizzata per il rollback
+ Il motivo dello stato

Amazon ECS elimina l'implementazione del servizio quando viene eliminato uno.

## Stati di implementazione del servizio
<a name="service-deployments-states"></a>

Un'implementazione di servizio inizia nello stato `PENDING`. 

La figura seguente mostra gli stati di implementazione del servizio che possono verificarsi dopo lo stato `PENDING`: `IN_PROGRESS`, `ROLLBACK_REQUESTED`, `SUCCESSFUL`, `STOP_REQUESTED`, `ROLLBACK_IN_PROGRESSS`, `ROLLBACK_FAILED`, `ROLLBACK_SUCCESSFUL` e `STOPPED`.

![\[Gli stati di implementazione del servizio STOP_REQUESTED, SUCCESSFUL e ROLLBACK_IN_PROGRESS che possono avvenire dopo lo stato IN_PROGRESS.\]](http://docs.aws.amazon.com/it_it/AmazonECS/latest/developerguide/images/service-deployment-states.png)


Le seguenti informazioni forniscono dettagli sugli stati di implementazione del servizio:
+ `PENDING`: è stata creata una implementazione del servizio, ma non è stata avviata.

  Lo stato può passare a `IN_PROGRESS`, `ROLLBACK_REQUESTED`, `STOP_REQUESTED` o `STOPPED`.
+ `IN_PROGRESS`: l'implementazione del servizio è in corso.

  Lo stato può passare a `SUCCESSFUL`, `STOP_REQUESTED`, `ROLLBACK_REQUESTED`, `ROLLBACK_IN_PROGRESS` e `STOPPED`.
+ `STOP_REQUESTED`: lo stato di implementazione del servizio passa a `STOP_REQUESTED` quando si verifica una delle seguenti condizioni:
  + Un utente avvia una nuova implementazione del servizio.
  + L'opzione di rollback non è utilizzata per il meccanismo di rilevamento degli errori (basato sull'interruttore automatico o sull'allarme) e il servizio non raggiunge lo stato `SUCCESSFUL`.

  Lo stato passa a `STOPPED`.
+  `ROLLBACK_REQUESTED`: lo stato di implementazione del servizio passa a `ROLLBACK_REQUESTED` quando un utente richiede un rollback tramite la console, l'API o la CLI.

  Lo stato può passare a `SUCCESSFUL`, `ROLLBACK_IN_PROGRESS` e `STOPPED`.
+ `SUCCESSFUL`: lo stato di implementazione del servizio passa a `SUCCESSFUL` quando l'implementazione del servizio viene completata correttamente.
+  `ROLLBACK_IN_PROGRESS`: lo stato di implementazione del servizio passa a `ROLLBACK_IN_PROGRESS` quando l'opzione di rollback è in uso per il meccanismo di rilevamento dei guasti (l'interruttore automatico o basato sugli allarmi) e il servizio ha esito negativo.

   Lo stato passa a `ROLLBACK_SUCCESSFUL` o `ROLLBACK_FAILED`.

# Proprietà incluse in un'implementazione del servizio Amazon ECS
<a name="service-deployment-property"></a>

Le seguenti proprietà sono incluse in un'implementazione di servizi.


| Proprietà | Description | 
| --- | --- | 
|  ARN dell'implementazione dei servizi  |  L'ARN del servizio di implementazione.  | 
| ARN del servizio |  L'ARN del servizio per quest'implementazione del servizio.  | 
|  ARN del cluster  |  L'ARN per il cluster che ospita il servizio.  | 
| Ora di creazione dell'implementazione del servizio | L'ora in cui è stata creata l'implementazione del servizio.  | 
| Ora di inizio dell'implementazione del servizio | L'ora in cui è iniziata l'implementazione del servizio.  | 
|  Ora di fine dell'implementazione del servizio  | L'ora in cui è terminata l'implementazione del servizio. | 
| Ora di interruzione dell'implementazione del servizio | L'ora in cui è stata interrotta l'implementazione del servizio.  | 
| Ora di aggiornamento dell'implementazione del servizio | L'ora dell'ultimo aggiornamento dell'implementazione del servizio.  | 
| Revisioni del servizio di origine |  Le revisioni del servizio attualmente in esecuzione.  Per informazioni sulle proprietà incluse, consultare [Proprietà incluse in una revisione del servizio Amazon ECS](service-revision-property.md).  | 
| Configurazione dell’implementazione | I parametri di implementazione che includono la configurazione dell'interruttore automatico, gli allarmi che determinano:[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonECS/latest/developerguide/service-deployment-property.html) | 
| Revisione del servizio di destinazione | La revisione del servizio da implementare. Una volta completata correttamente l'implementazione, la revisione del servizio di destinazione è la revisione del servizio in esecuzione. | 
| Stato dell'implementazione del servizio | Lo stato dell'implementazione del servizio.I valori validi sono PENDING, SUCCESSFUL, STOPPED, STOP\$1REQUESTED, STOP\$1IN\$1PROGRESS, IN\$1PROGRESS, ROLLBACK\$1IN\$1PROGRESS, ROLLBACK\$1SUCCESSFUL e ROLLBACK\$1FAILED. | 
| Informazioni sullo stato dell'implementazione del servizio | Informazioni sul motivo per cui l'implementazione del servizio è nello stato attuale. Ad esempio, l'interruttore automatico ha rilevato un guasto. | 
|  Informazioni di rollback | Le opzioni di rollback utilizzate dall'implementazione del servizio in caso di errore dell'implementazione. | 
| Opzioni di interruttore automatico di implementazione del servizio | L'interruttore automatico che determina l'implementazione del servizio ha avuto esito negativo. | 
| CloudWatch allarmi per l'implementazione del servizio | Gli CloudWatch allarmi che determinano quando l'implementazione di un servizio fallisce. | 

# Autorizzazioni richieste per visualizzare le implementazioni del servizio di Amazon ECS
<a name="service-deployment-permissions"></a>

 Quando si segue la best practice della concessione dei privilegi minimi, è necessario aggiungere ulteriori autorizzazioni per visualizzare le implementazioni del servizio nella console.

È necessario accedere alle seguenti azioni:
+ ListServiceDeployments
+ DescribeServiceDeployments
+ DescribeServiceRevisions

È necessario accedere alle seguenti risorse:
+ Servizio
+ Implementazioni del servizio
+ Revisione del servizio

La seguente policy di esempio contiene le autorizzazioni necessarie e limita le operazioni a un servizio specifico. 

Sostituire `account`, `cluster-name` e `service-name` con i propri valori.

------
#### [ JSON ]

****  

```
{
"Statement": [
    {
        "Effect": "Allow",
        "Action": [
            "ecs:ListServiceDeployments",
            "ecs:DescribeServiceDeployments",
            "ecs:DescribeServiceRevisions"
        ],
        "Resource": [
            "arn:aws:ecs:us-east-1:123456789012:service/cluster-name/service-name",
            "arn:aws:ecs:us-east-1:123456789012:service-deployment/cluster-name/service-name/*",
            "arn:aws:ecs:us-east-1:123456789012:service-revision/cluster-name/service-name/*"
            ]
        }
   ]
}
```

------

# Visualizzare le implementazioni del servizio di Amazon ECS
<a name="view-service-deployment"></a>

È possibile vedere la cronologia di 90 giorni più recente per le implementazioni create il o dopo il 25 ottobre 2024. Le implementazioni del servizio possono avere uno dei seguenti stati:
+ In corso 
+ Pending (In attesa)
+ Completato

 È possibile utilizzare queste informazioni per determinare se è necessario aggiornare la modalità di implementazione del servizio o la revisione del servizio. Per informazioni sulle proprietà incluse, consultare [Proprietà incluse in un'implementazione del servizio Amazon ECS](service-deployment-property.md).

Prima di iniziare, configurare le autorizzazioni richieste per visualizzare le implementazioni dei servizi. Per ulteriori informazioni, consulta [Autorizzazioni richieste per visualizzare le implementazioni del servizio di Amazon ECS](service-deployment-permissions.md).

------
#### [ Amazon ECS Console ]

1. [Apri la console nella versione 2https://console.aws.amazon.com/ecs/.](https://console.aws.amazon.com/ecs/v2)

1. Nella pagina **Cluster**, scegliere il cluster.

1. Nella pagina dei dettagli del cluster, nella sezione **Servizi**, selezionare il servizio.

   Si apre la pagina dei dettagli del servizio.

1. Nella pagina dei dettagli del servizio, scegliere **Implementazioni**.

1. Scegli l'implementazione del servizio da visualizzare.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonECS/latest/developerguide/view-service-deployment.html)

   Si apre la pagina dei dettagli dell'implementazione del servizio.

1. (Facoltativo) Confrontare le revisioni del servizio per visualizzare le differenze.

   In **Revisioni del servizio**, scegliere **Confronta revisioni**, quindi selezionare 2 revisioni da confrontare.

   Le revisioni del servizio vengono visualizzate side-by-side con le differenze evidenziate.

------
#### [ AWS CLI ]

1. Eseguire `list-service-deployments` per recuperare l'ARN di implementazione del servizio. 

   Sostituire le variabili con i propri valori.

   ```
   aws ecs list-service-deployments --cluster cluster-name --service service-name
   ```

   Prendi nota serviceDeploymentArn della distribuzione che desideri visualizzare.

   ```
   {
       "serviceDeployments": [
           {
               "serviceDeploymentArn": "arn:aws:ecs:us-west-2:123456789012:service-deployment/example/sd-example/NCWGC2ZR-taawPAYrIaU5",
               "serviceArn": "arn:aws:ecs:us-west-2:123456789012:service/example/sd-example",
               "clusterArn": "arn:aws:ecs:us-west-2:123456789012:cluster/example",
               "targetServiceRevisionArn": "arn:aws:ecs:us-west-2:123456789012:service-revision/example/sd-example/4980306466373577095",
               "status": "SUCCESSFUL"
           }
       ]
   }
   ```

1. Esegui `describe-service-deployments`. Usare il `serviceDeploymentArn` restituito da `list-service-deployments`.

   Sostituire le variabili con i propri valori.

   ```
   aws ecs describe-service-deployments --service-deployment-arns arn:aws:ecs:region:123456789012:service-deployment/cluster-name/service-name/NCWGC2ZR-taawPAYrIaU5
   ```

------

## Fasi successive
<a name="view-service-deployment-next-step"></a>

È possibile visualizzare i dettagli per le revisioni del servizio nell'implementazione. Per ulteriori informazioni, consultare [Visualizzazione dei dettagli della revisione del servizio di Amazon ECS](view-service-revision.md)

# Revisioni del servizio Amazon ECS
<a name="service-revision"></a>

Una revisione del servizio contiene un record della configurazione del carico di lavoro che Amazon ECS sta tentando di implementare. Ogni volta che crei o distribuisci un servizio, Amazon ECS crea e acquisisce automaticamente la configurazione che stai tentando di distribuire nella revisione del servizio.

 Le revisioni del servizio sono di sola lettura e dispongono di identificatori univoci. Per informazioni sulle proprietà incluse, consultare [Proprietà incluse in una revisione del servizio Amazon ECS](service-revision-property.md).

 Le revisioni del servizio offrono i seguenti vantaggi:
+ Durante l'implementazione di un servizio, è possibile confrontare la revisione del servizio attualmente implementata (origine) con quella che verrà implementata (destinazione).
+ Quando si utilizza l'opzione di rollback per un'implementazione del servizio, Amazon ECS ripristina automaticamente l'implementazione del servizio all'ultima revisione del servizio implementata con successo.
+ Le revisioni del servizio contengono il record della configurazione del carico di lavoro in un'unica risorsa. 

## Ciclo di vita della revisione del servizio
<a name="service-revisions-lifecycle"></a>

Amazon ECS crea automaticamente una nuova revisione del servizio quando si crea un servizio o si aggiorna una proprietà del servizio che avvia un'implementazione.

 Amazon ECS non crea una nuova revisione del servizio per un'operazione di rollback. Amazon ECS utilizza l'ultima revisione del servizio riuscita per il rollback. 

Una revisione del servizio non è modificabile.

Amazon ECS elimina la revisione del servizio quando viene eliminato un servizio.

È possibile visualizzare le revisioni del servizio create il o dopo il 25 ottobre 2024 utilizzando la console, l'API e la CLI.

# Proprietà incluse in una revisione del servizio Amazon ECS
<a name="service-revision-property"></a>

Le seguenti proprietà sono incluse in una revisione del servizio.


| Risorsa | Description | 
| --- | --- | 
|  ARN del servizio  |  L'ARN che identifica il servizio.  | 
|  ARN del cluster  |  L'ARN per il cluster che ospita il servizio.  | 
|  ARN della definizione dell'attività  |  L'ARN della definizione di attività utilizzato per le attività del servizio.  | 
|  Registri del servizio  |  I dettagli dei registri del servizio utilizzati per il rilevamento servizi. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonECS/latest/developerguide/service-revision-property.html)  | 
| fornitori di capacità |  I dettagli della strategia del provider di capacità. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonECS/latest/developerguide/service-revision-property.html)  | 
| Immagini di container |  I dettagli sulle immagini del container.  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonECS/latest/developerguide/service-revision-property.html)  | 
| Rete |  La configurazione di rete per il servizio. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonECS/latest/developerguide/service-revision-property.html)  | 
| Tipo di lancio | L'opzione di calcolo utilizzata per il servizio. | 
| Proprietà specifiche di Fargate |  Quando si utilizza Fargate, queste sono informazioni sulla versione di Fargate. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonECS/latest/developerguide/service-revision-property.html)  | 
| Volumi di Amazon EBS configurati all'implementazione |  La configurazione per un volume specificato nella definizione dell'attività come volume configurato al momento dell'avvio.  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonECS/latest/developerguide/service-revision-property.html)  | 
|  Service Connect |  La configurazione di Service Connect. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonECS/latest/developerguide/service-revision-property.html)  | 
| Bilanciatori del carico del servizio |  I bilanciatori del carico che instradano il traffico del servizio. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonECS/latest/developerguide/service-revision-property.html)  | 
| Monitoraggio del runtime | Indica se il monitoraggio del runtime è attivo. | 
| Data di creazione |  La data di creazione della revisione del servizio.  | 
| Reticolo in VPC |  La configurazione di VPC Lattice per la revisione del servizio.  | 

# Visualizzazione dei dettagli della revisione del servizio di Amazon ECS
<a name="view-service-revision"></a>

È possibile visualizzare informazioni sui seguenti tipi di revisione del servizio creati il o dopo il 25 ottobre 2024:
+ Origine: la configurazione del carico di lavoro attualmente implementata
+ Destinazione: la configurazione del carico di lavoro in fase di implementazione

------
#### [ Amazon ECS Console ]

1. [Apri la console alla v2. https://console.aws.amazon.com/ecs/](https://console.aws.amazon.com/ecs/v2)

1. Nella pagina **Cluster**, scegliere il cluster.

1. Nella pagina dei dettagli del cluster, nella sezione **Servizi**, selezionare il servizio.

   Si apre la pagina dei dettagli del servizio.

1. Nella pagina dei dettagli del servizio, scegliere **Implementazioni**.

1. Scegliere la revisione del servizio da visualizzare.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonECS/latest/developerguide/view-service-revision.html)

------
#### [ AWS CLI ]

1. Eseguire `describe-service-deployments` per recuperare l'ARN della revisione del servizio. 

   Sostituire le variabili con i propri valori.

   ```
   aws ecs describe-service-deployments --service-deployment-arns arn:aws:ecs:region:account-id:service/cluster-name/service-name/NCWGC2ZR-taawPAYrIaU5
   ```

   Annotare il `arn` per `sourceServiceRevisions` o `targetServiceRevisions`.

   ```
   {
       "serviceDeployments": [
           {
               "serviceDeploymentArn": "arn:aws:ecs:us-west-2:123456789012:service-deployment/example/sd-example/NCWGC2ZR-taawPAYrIaU5",
               "serviceArn": "arn:aws:ecs:us-west-2:123456789012:service/example/sd-example",
               "clusterArn": "arn:aws:ecs:us-west-2:123456789012:cluster/example",
               "updatedAt": "2024-09-10T16:49:35.572000+00:00",
               "sourceServiceRevision": {
                   "arn": "arn:aws:ecs:us-west-2:123456789012:service-revision/example/sd-example/4980306466373578954",
                   "requestedTaskCount": 0,
                   "runningTaskCount": 0,
                   "pendingTaskCount": 0
               },
               "targetServiceRevision": {
                   "arn": "arn:aws:ecs:us-west-2:123456789012:service-revision/example/sd-example/4980306466373577095",
                   "requestedTaskCount": 0,
                   "runningTaskCount": 0,
                   "pendingTaskCount": 0
               },
               "status": "IN_PROGRESS",
               "deploymentConfiguration": {
                   "deploymentCircuitBreaker": {
                       "enable": false,
                       "rollback": false
                   },
                   "maximumPercent": 200,
                   "minimumHealthyPercent": 100
               }
           }
       ],
       "failures": []
   }
   ```

1. Esegui `describe-service-revisions`. Usare il `arn` restituito da `describe-service-deployments`.

   Sostituire le variabili con i propri valori.

   ```
   aws ecs describe-service-revisions --service-revision-arns arn:aws:ecs:region:123456789012:service-revision/cluster-name/service-name/4980306466373577095
   ```

------

# Bilanciamento di un servizio Amazon ECS tra zone di disponibilità
<a name="service-rebalancing"></a>

A partire dal 5 settembre 2025, Amazon ECS abilita il ribilanciamento delle zone di disponibilità per tutti i servizi adatti a questa funzionalità. Un servizio è adatto quando la distribuzione della zona di disponibilità è la prima strategia di posizionamento delle attività o quando non esiste una strategia di posizionamento.

Per aiutare le applicazioni a raggiungere un’elevata disponibilità, consigliamo di configurare i servizi multi-task per l’esecuzione su più zone di disponibilità. Per i servizi che specificano come prima strategia di collocamento la distribuzione in zone di disponibilità, AWS fa del suo meglio per distribuire equamente le attività di servizio tra le zone di disponibilità disponibili.

Tuttavia, a volte il numero di attività in esecuzione in una zona di disponibilità non è uguale a quello delle altre zone di disponibilità, ad esempio dopo un’interruzione della zona di disponibilità. Per risolvere questo squilibrio delle attività, puoi abilitare la funzione di ribilanciamento della zona di disponibilità.

Con il ribilanciamento delle zone di disponibilità, Amazon ECS monitora continuamente la distribuzione delle attività nelle zone di disponibilità per ciascuno dei tuoi servizi. Quando Amazon ECS rileva una distribuzione irregolare delle attività, interviene automaticamente per ribilanciare il carico di lavoro nelle zone di disponibilità. Ciò comporta l’avvio di nuove attività nelle zone di disponibilità con il minor numero di attività e la chiusura delle attività nelle zone di disponibilità sovraccariche.

Questa ridistribuzione garantisce che nessuna singola zona di disponibilità diventi un punto di errore, contribuendo a mantenere la disponibilità complessiva delle applicazioni containerizzate. Il processo di ribilanciamento automatico elimina la necessità di interventi manuali, accelerando i tempi di ripristino dopo un evento.

Di seguito è riportata una panoramica del processo di ribilanciamento delle zone di disponibilità:

1. Amazon ECS inizia a monitorare un servizio dopo che ha raggiunto lo stato stazionario e analizza il numero di attività in esecuzione in ciascuna zona di disponibilità.

1. Amazon ECS esegue le seguenti operazioni quando rileva uno squilibrio nel numero di attività in esecuzione in ciascuna zona di disponibilità:
   + Invia un evento di servizio che indica l'inizio del ribilanciamento delle zone di disponibilità.
   + Avvia le attività nelle zone di disponibilità con il minor numero di attività in esecuzione
   + Interrompe le attività nelle zone di disponibilità con il maggior numero di attività in esecuzione.
   + Il pianificatore attende che le attività appena avviate siano `HEALTHY` e `RUNNING` prima di interromperle nella zona di disponibilità sovradimensionata.
   + Invia un evento di servizio con l'esito del ribilanciamento delle zone di disponibilità.

## In che modo Amazon ECS rileva la distribuzione irregolare delle attività
<a name="service-rebalancing-imbalance"></a>

Amazon ECS determina uno squilibrio nel numero di attività in esecuzione in ciascuna zona di disponibilità dividendo il numero di attività desiderate del servizio per il numero di zone di disponibilità configurate. Se il numero di attività desiderate non è suddiviso in modo uniforme, Amazon ECS distribuisce il resto delle attività in modo uniforme tra le zone di disponibilità configurate. Ogni zona di disponibilità deve avere almeno un'attività.

Ad esempio, consideriamo un servizio Amazon ECS con un numero desiderato di due attività configurate per due zone di disponibilità. In questo scenario, il numero di attività desiderate è suddiviso in modo uniforme. Una distribuzione bilanciata corrisponderebbe a un'attività per zona di disponibilità. Se ci sono due attività nella zona di disponibilità 1 e zero attività nella zona di disponibilità 2, Amazon ECS inizierà il ribilanciamento avviando un'attività nella zona di disponibilità 2 prima di interrompere un'attività nella zona di disponibilità 1.

Ora, consideriamo un servizio Amazon ECS con un numero desiderato di tre attività configurate per due zone di disponibilità. In questo scenario, il numero di attività desiderate non viene suddiviso in modo uniforme. Una distribuzione bilanciata sarebbe costituita da un'attività nella zona di disponibilità 1 e due attività nella zona di disponibilità 2, poiché ogni zona di disponibilità ha almeno un'attività e quella rimanente viene posizionata nella zona di disponibilità 2.

Consideriamo un servizio Amazon ECS che ha un numero desiderato di cinque attività configurate per due zone di disponibilità. In questo scenario, il numero di attività desiderate non viene suddiviso in modo uniforme. Una distribuzione bilanciata sarebbe costituita da un'attività nella zona di disponibilità 1 e due attività ciascuna nelle zone di disponibilità 2 e 3. Dopo aver considerato ogni zona di disponibilità con un'attività ciascuna, le due attività rimanenti vengono distribuite equamente tra le zone di disponibilità.

## Considerazioni per la configurazione del ribilanciamento delle zone di disponibilità
<a name="service-rebalancing-configurations"></a>

Quando si desidera configurare il ribilanciamento della zona di disponibilità, considerare quanto segue:
+ Il ribilanciamento delle zone di disponibilità supporta i provider di capacità Fargate ed EC2 ed è supportato sulle istanze gestite da Amazon ECS. Per Fargate, Amazon ECS ridistribuirà automaticamente le attività tra le zone di disponibilità presenti per mantenere l'equilibrio. Per i provider di capacità EC2, Amazon ECS ribilancia le attività tra le istanze di container esistenti nel miglior modo possibile, rispettando le strategie e i vincoli di posizionamento definiti. Tuttavia, Amazon ECS non può avviare nuove istanze in zone di disponibilità sottoutilizzate nell'ambito del processo di ribilanciamento, limitandolo alle istanze di container esistenti.
+ Il ribilanciamento delle zone di disponibilità funziona nelle seguenti configurazioni:
  + Servizi che utilizzano la strategia `Replica`
  + I servizi che specificano la zona di disponibilità si diffondono come prima strategia di posizionamento delle attività oppure non specificano una strategia di posizionamento.
+ Non è possibile utilizzare il ribilanciamento delle zone di disponibilità con servizi che soddisfano uno dei seguenti criteri:
  + Utilizza la strategia `Daemon`
  + Utilizza il tipo di avvio `EXTERNAL` (ECS Anywhere)
  + Utilizza il 100% per il valore `maximumPercent`
  + Utilizza un Classic Load Balancer
  + Utilizza `attribute:ecs.availability-zone` come vincolo di posizionamento delle attività

## Strategie di posizionamento e vincoli di posizionamento con il ribilanciamento delle zone di disponibilità
<a name="service-rebalancing-placement-constraints"></a>

Le strategie di posizionamento determinano il modo in cui Amazon ECS seleziona le istanze di container e le zone di disponibilità per la terminazione del posizionamento delle attività. I vincoli di posizionamento delle attività sono regole che determinano se un'attività può essere eseguita su una specifica istanza di container.

Per EC2, è possibile utilizzare strategie e vincoli di posizionamento insieme al ribilanciamento delle zone di disponibilità. Tuttavia, affinché il ribilanciamento delle zone di disponibilità funzioni, la strategia di posizionamento della distribuzione delle zone di disponibilità deve essere la prima strategia specificata.

Il ribilanciamento delle zone di disponibilità è compatibile con varie combinazioni di strategie di posizionamento. Ad esempio, è possibile creare una strategia che distribuisce innanzitutto le attività in modo uniforme all'interno delle zone di disponibilità, quindi esegue il bin packing delle attività in base alla memoria all'interno di ciascuna zona di disponibilità. In questo caso, il ribilanciamento delle zone di disponibilità funziona perché la strategia di distribuzione delle zone di disponibilità viene specificata per prima.

È importante notare che il ribilanciamento delle zone di disponibilità non funzionerà se la prima strategia nella serie di strategia di posizionamento non è un componente di distribuzione delle zone di disponibilità. Questo requisito garantisce che l'obiettivo principale della distribuzione delle attività sia il mantenimento dell'equilibrio tra le zone di disponibilità, fondamentale per un'elevata disponibilità.

Per ulteriori informazioni sulle strategie e sui vincoli di posizionamento delle attività, consultare [In che modo Amazon ECS colloca le attività sulle istanze dei container](task-placement.md).

Per attività che usano Fargate, le strategie e i vincoli di posizionamento dei processi non sono supportati. Fargate farà del suo meglio per distribuire le attività tra zone di disponibilità accessibili. Se il provider di capacità include sia Fargate che Fargate Spot, il comportamento di distribuzione sarà indipendente per ogni provider.

La strategia seguente di esempio distribuisce le attività in modo uniforme all'interno delle zone di disponibilità, quindi raggruppa le attività in bin packing in base alla memoria all'interno di ciascuna zona di disponibilità. Il ribilanciamento delle zone di disponibilità è compatibile con il servizio perché la strategia `spread` è prioritaria.

```
"placementStrategy": [
    {
        "field": "attribute:ecs.availability-zone",
        "type": "spread"
    },
    {
        "field": "memory",
        "type": "binpack"
    }
]
```

## Attivare il ribilanciamento delle zone di disponibilità
<a name="service-rebalancing-use"></a>

È necessario abilitare il ribilanciamento delle zone di disponibilità per i servizi nuovi ed esistenti.

È possibile abilitare e disabilitare il ribilanciamento delle zone di disponibilità utilizzando la console, APIs AWS CLI, e. CloudFormation

Il comportamento predefinito di `AvailabilityZoneRebalancing` differisce tra le richieste di creazione e di aggiornamento:
+ Per le richieste di creazione di servizi, quando non viene specificato alcun valore per `AvailabilityZoneRebalancing`, Amazon ECS imposta il valore predefinito su `ENABLED`.
+ Per le richieste di aggiornamento dei servizi, quando non viene specificato alcun valore per `AvailabilityZoneRebalancing`, Amazon ECS imposta il valore predefinito del servizio esistente su `AvailabilityZoneRebalancing`. Se il servizio non ha mai avuto un valore `AvailabilityZoneRebalancing` impostato, Amazon ECS lo considera come `DISABLED`.


| Tipo di servizio | "Hello, World\$1" | Console | CLI | 
| --- | --- | --- | --- | 
| Esistente | [UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html) |  [Aggiornamento di un servizio Amazon ECS](update-service-console-v2.md)  | [update-service](https://docs.aws.amazon.com/cli/latest/reference/ecs/update-service.html) | 
| Novità | [CreateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateService.html) |  [Creazione di un'implementazione di aggiornamenti continui di Amazon ECS](create-service-console-v2.md)  | [create-service](https://docs.aws.amazon.com/cli/latest/reference/ecs/create-service.html) | 

L'esempio seguente mostra come abilitare il ribilanciamento del servizio durante la creazione di un nuovo servizio:

```
aws ecs create-service \
    --cluster my-cluster \
    --service-name my-service \
    --task-definition my-task-definition:1 \
    --desired-count 6 \
    --availability-zone-rebalancing ENABLED
```

# Monitorare il ribilanciamento delle zone di disponibilità di Amazon ECS
<a name="track-service-rebalancing"></a>

È possibile verificare se il ribilanciamento delle zone di disponibilità è abilitato per un servizio nella console o chiamando `describe-services`. L'esempio seguente può essere utilizzato per visualizzare lo stato con la CLI.

La risposta sarà `ENABLED` o `DISABLED`.

```
aws ecs describe-services \
    --services service-name \
    --cluster cluster-name \
    --query services[0].availabilityZoneRebalancing
```

## Eventi di servizio
<a name="service-info-events"></a>

Amazon ECS invia eventi di operazioni di servizio per favorire la comprensione del ciclo di vita del ribilanciamento delle zone di disponibilità. 


| Event | Scenario | Tipo | Ulteriori informazioni | 
| --- | --- | --- | --- | 
| SERVICE\$1REBALANCING\$1STARTED | Amazon ECS avvia un'operazione di ribilanciamento delle zone di disponibilità | INFO | [service (*service-name*) non è bilanciato in AZ con *number-tasks* le attività in, in e in. *Availability Zone 1* *number-tasks* *Availability Zone 2* *number-tasks* *Availability Zone 3* Ribilanciamento AZ in corso.](service-rebalancing-event-messages-list.md#service-rebalancing-started) | 
| SERVICE\$1REBALANCING\$1COMPLETED | L'operazione di ribilanciamento delle zone di disponibilità viene completata |  INFO | [service (*service-name*) è bilanciato in AZ con *number-tasks* *number-tasks* task in *Availability Zone 1**Availability Zone 2*, tasks in e *number-tasks* tasks in*Availability Zone 3*.](service-rebalancing-event-messages-list.md#service-rebalancing-completed) | 
| TASKS\$1STARTED | Amazon ECS avvia correttamente le attività nell'ambito dell'operazione di ribilanciamento delle zone di disponibilità | INFO | [*service-name*ha avviato *number-tasks* attività in *Availability Zone* AZ Rebalance:. *task-ids*](service-rebalancing-event-messages-list.md#service-rebalancing-tasks-started) | 
| TASKS\$1STOPPED | Amazon ECS interrompe correttamente le attività nell'ambito dell'operazione di ribilanciamento delle zone di disponibilità | INFO | [*service-name*ha interrotto l'*number-tasks*esecuzione delle attività a *Availability Zone* causa del ribilanciamento AZ:. *task-id*](service-rebalancing-event-messages-list.md#service-rebalancing-tasks-stopped) | 
| SERVICE\$1TASK\$1PLACEMENT\$1FAILURE | Amazon ECS non ha potuto avviare un'attività nell'ambito dell'operazione di ribilanciamento delle zone di disponibilità | ERRORE | Per EC2, vedere [service (*service-name*) non è in grado di inserire un'attività *Availability Zone* perché nessuna istanza del contenitore soddisfa tutti i requisiti.](service-rebalancing-event-messages-list.md#service-rebalancing-placement-failure-instance) Per Fargate, vedere [service (*service-name*) non è in grado di inserire un'attività in*Availability Zone*.](service-rebalancing-event-messages-list.md#service-rebalancing-placement-failure) | 
| TASKSET\$1SCALE\$1IN\$1FAILURE\$1BY\$1TASK\$1PROTECTION | L'operazione di ribilanciamento delle zone di disponibilità è bloccata perché è in uso la protezione delle attività. | INFO | [service (*service-name*) non è riuscito a eseguire AZ Rebalance perché non *task-set-name* è stato in grado di scalare a causa di. *reason*](service-rebalancing-event-messages-list.md#service-rebalancing-task-protection-failure) | 
| SERVICE\$1REBALANCING\$1STOPPED | L'operazione di ribilanciamento delle zone di disponibilità viene interrotta. Amazon ECS invia eventi aggiuntivi che forniscono informazioni aggiuntive. | INFO | [service (*service-name*) ha interrotto AZ Rebalancing.](service-rebalancing-event-messages-list.md#service-rebalancing-operation-stopped) | 

## Eventi di modifica dello stato dei processi
<a name="task-state-change-events"></a>

Amazon ECS invia un evento di modifica dello stato dell'attività (`START`) per ogni attività avviata nell'ambito del processo di ribilanciamento.

Amazon ECS invia un evento di modifica dello stato dell'attività (`STOPPED`) per ogni attività interrotta nell'ambito del processo di ribilanciamento. Il motivo è impostato su `Availability-zone rebalancing initiated by (deployment ecs-svc/deployment-id)`.

Per ulteriori informazioni sugli eventi, consultare [Eventi di modifica dello stato dei processi di Amazon ECS](ecs_task_events.md).

## Risoluzione dei problemi di ribilanciamento del servizio
<a name="service-rebalancing-troubleshooting"></a>

Se si riscontrano problemi con il ribilanciamento del servizio, considerare i seguenti passaggi per la loro risoluzione:

Il ribilanciamento non si avvia  
Verificare che:  
+ Il ribilanciamento del servizio è abilitato per il servizio
+ Il servizio utilizza una configurazione supportata (vedere [Considerazioni per la configurazione del ribilanciamento delle zone di disponibilità](#service-rebalancing-configurations))
+ Il servizio ha raggiunto uno stato stazionario

Errori nel posizionamento delle attività durante il ribilanciamento  
Se si vedono eventi `SERVICE_TASK_PLACEMENT_FAILURE`:  
+ Per EC2: verificare se sono disponibili istanze di container nella zona di disponibilità di destinazione
+ Per Fargate: verificare se ci sono vincoli di risorse o quote di servizio che limitano il posizionamento delle attività
+ Esaminare i vincoli relativi al posizionamento delle attività per assicurarsi che non impediscano una corretta distribuzione delle attività

Il ribilanciamento si interrompe in modo imprevisto  
Se si vedono eventi `SERVICE_REBALANCING_STOPPED`:  
+ Verificare la protezione delle attività che potrebbero bloccare l'operazione
+ Cercare implementazioni simultanee di servizi che potrebbero interrompere il ribilanciamento
+ Rivedere gli eventi di servizio per ulteriori informazioni sul motivo per cui il ribilanciamento è stato interrotto

## Best practice per il ribilanciamento del servizio
<a name="service-rebalancing-best-practices"></a>

Seguire le best practice per ottimizzare il ribilanciamento del servizio:
+ **Monitora le operazioni di ribilanciamento**: imposta gli CloudWatch allarmi per monitorare gli eventi di servizio relativi al ribilanciamento e identificare rapidamente eventuali problemi.
+ **Considerare l'impatto sulle prestazioni**: tenere presente che le operazioni di ribilanciamento possono aumentare temporaneamente l'utilizzo delle risorse man mano che vengono avviate nuove attività prima che quelle precedenti vengano interrotte.
+ **Utilizzare la protezione delle attività in modo strategico**: se si dispone di attività critiche che non devono essere interrotte durante il ribilanciamento, considerare l'utilizzo della protezione delle attività.
+ **Pianificare la capacità di EC2**: per EC2, assicurarsi di disporre di un numero sufficiente di istanze di container in tutte le zone di disponibilità per supportare un ribilanciamento efficace.
+ **Testare il comportamento di ribilanciamento**: prima di affidarsi al ribilanciamento in produzione, testare il comportamento dei servizi durante le operazioni di ribilanciamento in un ambiente non di produzione.

# Usa il bilanciamento del carico per distribuire il traffico del servizio Amazon ECS
<a name="service-load-balancing"></a>

È possibile scegliere di configurare il servizio per l'utilizzo del bilanciamento del carico elastico per l'implementazione uniforme del traffico fra le attività nel servizio.

**Nota**  
Quando si utilizzano set di processi, tutti i processi del set devono essere configurati per utilizzare Elastic Load Balancing o non utilizzare Elastic Load Balancing. 

I servizi Amazon ECS ospitati su AWS Fargate supportano Application Load Balancer, Network Load Balancer e Gateway Load Balancer. Utilizzare la tabella seguente per ottenere maggiori informazioni sul tipo bilanciatore del carico da utilizzare.


| Tipo di bilanciatore del carico | Utilizzare in questi casi | 
| --- | --- | 
|  Application Load Balancer  | Traffico di routing HTTP/HTTPS (o livello 7).Gli Application Load Balancer offrono diverse funzionalità che li rendono particolarmente appropriati per l'uso con i servizi Amazon ECS: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonECS/latest/developerguide/service-load-balancing.html) | 
| Network Load Balancer | Instradare il traffico TCP o UDP (o livello 4). | 
| Gateway Load Balancer | Instradare il traffico TCP o UDP (o livello 4). Usare le appliance virtuali, come firewall, sistemi di prevenzione e rilevamento delle intrusioni, e sistemi di ispezione approfondita dei pacchetti. | 

È consigliabile utilizzare gli Application Load Balancer per i tuoi servizi Amazon ECS, in modo da sfruttare queste funzioni recenti, a meno che il servizio non richieda una funzionalità disponibile solo con i Network Load Balancer o Gateway Load Balancer. Per ulteriori informazioni sull'Elastic Load Balancing e le differenze tra questi tipi di load balancer, consulta la [Guida per l'utente di Elastic Load Balancing](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/).

Con il load balancer paghi solo in base all'uso effettivo. Per ulteriori informazioni, consultare [Prezzi di Elastic Load Balancing](https://aws.amazon.com/elasticloadbalancing/pricing/). 

# Ottimizzare i parametri di controllo dell’integrità del bilanciatore del carico per Amazon ECS
<a name="load-balancer-healthcheck"></a>

I bilanciatori del carico instradano le richieste solamente sui target integri all'interno delle zone di disponibilità per il bilanciatore del carico. Ogni destinazione è registrata in un gruppo di destinazione. Il bilanciatore del carico controlla l'integrità di ogni destinazione, utilizzando le impostazioni di controllo dell'integrità del gruppo di destinazione. Dopo aver registrato una destinazione, deve superare un controllo dell'integrità per essere considerata integra. Amazon ECS monitora il bilanciatore del carico. Il bilanciatore del carico invia periodicamente controlli dell'integrità al container di Amazon ECS. L'agente Amazon ECS monitora e attende che il bilanciatore del carico riferisca sull'integrità del container. Ciò avviene prima di considerare il container in uno stato integro.

Due parametri di controllo dell'integrità del bilanciamento del carico elastico influiscono sulla velocità di implementazione:
+ Intervallo del controllo dell'integrità: determina il periodo di tempo approssimativo, in secondi, tra i controlli dell'integrità di un singolo container. Per impostazione predefinita, il bilanciatore del carico effettua i controlli ogni 30 secondi.

  Questo parametro è nominato:
  + `HealthCheckIntervalSeconds` nell'API di bilanciamento del carico elastico
  + **Intervallo** sulla console Amazon EC2
+ Numero di soglia di integrità: determina il numero di controlli dell'integrità consecutivi superati necessari prima di considerare integro un container non integro. Per impostazione predefinita, il bilanciatore del carico richiede il superamento di cinque controlli di integrità prima di segnalare che il container di destinazione è integro.

  Questo parametro è nominato:
  + `HealthyThresholdCount` nell'API di bilanciamento del carico elastico
  + **Soglia di integrità** sulla console Amazon EC2

**Importante:** per le destinazioni appena registrate, è necessario un solo controllo dell'integrità riuscito per considerare la destinazione integra, indipendentemente dall'impostazione del conteggio delle soglie di integrità. Il numero delle soglie di integrità si applica solo quando una destinazione passa da uno stato non integro a uno stato integro.

Con le impostazioni predefinite, se una destinazione diventa non integra e viene ripristinata, il tempo totale per determinare l'integrità di un container è di due minuti e 30 secondi (`30 seconds * 5 = 150 seconds`).

È possibile accelerare il processo di controllo dell'integrità se il servizio si avvia e si stabilizza in meno di 10 secondi. Per accelerare il processo, ridurre l'intervallo del controllo dell'integrità e il numero delle soglie di integrità.
+ `HealthCheckIntervalSeconds` (nome dell'API di bilanciamento del carico elastico) o **Intervallo** (nome della console Amazon EC2): 5
+ `HealthyThresholdCount` (nome dell'API di bilanciamento del carico elastico) o **Soglia di integrità** (nome della console Amazon EC2): 2

Con questa impostazione, il processo di controllo dell'integrità richiede 10 secondi rispetto all'impostazione predefinita di due minuti e 30 secondi.

Per ulteriori informazioni sui parametri del controllo dell'integrità del bilanciamento del carico elastico, consultare [Health checks for your target groups](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/target-group-health-checks.html) nella *Guida per l'utente del bilanciamento del carico elastico*.

# Ottimizzazione dei parametri di svuotamento della connessione del bilanciatore del carico per Amazon ECS
<a name="load-balancer-connection-draining"></a>

Per consentire l'ottimizzazione, i client mantengono una connessione keep-alive al servizio container. Ciò consente alle richieste successive di quel client di riutilizzare la connessione esistente. Quando si desidera interrompere il traffico verso un container, si invia una notifica al bilanciatore del carico. Il bilanciatore del carico controlla periodicamente se il client ha chiuso la connessione keep-alive. Amazon ECS monitora il bilanciatore del carico e attende che il bilanciatore del carico segnali che la connessione keep-alive è chiusa (la destinazione è in uno stato `UNUSED`).

La quantità di tempo che il bilanciatore del carico attende per spostare la destinazione verso lo stato `UNUSED` corrisponde al ritardo di annullamento della registrazione. È possibile configurare il seguente parametro del bilanciatore del carico per velocizzare le implementazioni.
+ `deregistration_delay.timeout_seconds`: 300 (impostazione predefinita)

Se si dispone di un servizio con un tempo di risposta inferiore a 1 secondo, impostare il parametro sul valore seguente per fare in modo che il bilanciatore del carico attenda solo 5 secondi prima di interrompere la connessione tra il client e il servizio di backend: 
+ `deregistration_delay.timeout_seconds`: 5 

**Nota**  
Non impostare il valore su 5 secondi quando si dispone di un servizio con richieste di lunga durata, come caricamenti lenti di file o connessioni in streaming.

## Reattività SIGTERM
<a name="sigterm"></a>

Amazon ECS invia innanzitutto un segnale di arresto all'attività per notificare che l'applicazione deve essere completata e chiusa. Questo segnale può essere definito nell'immagine del contenitore con l'istruzione STOPSIGNAL e verrà impostato automaticamente su SIGTERM. Poi, Amazon ECS invia un messaggio SIGKILL. Quando le applicazioni ignorano il SIGTERM, il servizio Amazon ECS deve attendere l'invio del segnale SIGKILL per terminare il processo. 

La quantità di tempo che Amazon ECS attende per inviare il messaggio SIGKILL è determinata dalla seguente opzione dell'agente di Amazon ECS:
+ `ECS_CONTAINER_STOP_TIMEOUT`: 30 (impostazione predefinita)

  Per ulteriori informazioni sul parametro Container Agent, consulta [Amazon ECS Container Agent](https://github.com/aws/amazon-ecs-agent/blob/master/README.md) on GitHub.

Per accelerare il periodo di attesa, impostare il parametro dell'agente Amazon ECS sul valore seguente:
+ `ECS_CONTAINER_STOP_TIMEOUT`: 2

  Se l'applicazione impiega più di 1 secondo, moltiplicare il valore per 2 e usare quel numero come valore.

In questo caso, Amazon ECS attende 2 secondi che il container si arresti, quindi invia un messaggio SIGKILL quando l'applicazione non si ferma.

È anche possibile modificare il codice dell'applicazione per intercettare il segnale SIGTERM e reagire ad esso. Di seguito è riportato un esempio in JavaScript: 

```
process.on('SIGTERM', function() { 
  server.close(); 
})
```

Questo codice fa sì che il server HTTP smetta di ascoltare eventuali nuove richieste, finisca di rispondere a tutte le richieste in corso e quindi il processo Node.js termina perché il ciclo di eventi non ha nulla da fare. Pertanto, se impiega solo 500 ms per completare le richieste in corso, termina in anticipo senza dover attendere il timeout di arresto e ricevere un SIGKILL. 

# Utilizzo di un Application Load Balancer per Amazon ECS
<a name="alb"></a>

Un Application Load Balancer seleziona il routing a livello di applicazione (HTTP/HTTPS), supporta il routing in base al percorso e può instradare le richieste a una o più porte su ogni istanza di container nel cluster. Gli Application Load Balancer supportano la mappatura dinamica delle porte dell'host. Ad esempio, se la tua definizione del container del processo specifica la porta 80 per una porta di container NGINX e la porta 0 per la porta dell'host, quest'ultima viene selezionata in modo dinamico nell'intervallo di porte temporaneo dell'istanza di container (ad esempio da 32768 a 61000 nell'AMI ottimizzata per Amazon ECS più recente). Una volta avviata l'attività, il container NGINX viene registrato nell'Application Load Balancer come combinazione di ID istanza e porta, mentre il traffico viene instradato all'ID istanza e alla porta corrispondenti a tale container. Con la mappatura dinamica possono essere presenti più attività di un unico servizio sulla stessa istanza di container. Per ulteriori informazioni, consultare la [Guida per l'utente per Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/).

Per informazioni sulle best practice per impostare i parametri per velocizzare le implementazioni, consultare:
+ [Ottimizzare i parametri di controllo dell’integrità del bilanciatore del carico per Amazon ECS](load-balancer-healthcheck.md)
+ [Ottimizzazione dei parametri di svuotamento della connessione del bilanciatore del carico per Amazon ECS](load-balancer-connection-draining.md)

Quando si utilizzano gli Application Load Balancer con Amazon ECS, tenere presenti le considerazioni seguenti:
+ Amazon ECS richiede il ruolo IAM collegato al servizio, che fornisce le autorizzazioni necessarie per eseguire e annullare la registrazione delle destinazioni nel tuo load balancer al momento dell'avvio e dell'arresto dei processi. Per ulteriori informazioni, consulta [Uso di ruoli collegati ai servizi per Amazon ECS](using-service-linked-roles.md).
+ Per i servizi in una configurazione IPv6 -only, è necessario impostare il tipo di indirizzo IP del gruppo di destinazione dell'Application Load Balancer `dualstack` su o. `dualstack-without-public-ipv4`
+ Per i servizi con attività che utilizzano la modalità di rete `awsvpc`, quando si crea un gruppo di destinazione per il servizio, è necessario scegliere `ip` come tipo di destinazione e non `instance`. Il motivo è che i processi che usano la modalità di rete `awsvpc` sono associati a un'interfaccia di rete elastica e non a un'istanza Amazon EC2.
+ Se il servizio richiede l'accesso a più porte con bilanciamento del carico, ad esempio la porta 80 e la porta 443 per un HTTP/HTTPS servizio, è possibile configurare due listener. Un listener è responsabile di HTTPS che inoltra la richiesta al servizio e un altro listener responsabile del reindirizzamento delle richieste HTTP alla porta HTTPS appropriata. Per ulteriori informazioni, consultare [Create a listener to your Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-listener.html) nella *Guida per l'utente per Application Load Balancer*.
+ La configurazione della sottorete del load balancer deve includere tutte le zone di disponibilità in cui risiedono le tue istanze di container.
+ Dopo aver creato un servizio, la configurazione del load balancer non può essere modificata dalla Console di gestione AWS. È possibile utilizzare AWS Copilot AWS CLI o SDK per modificare la configurazione del bilanciamento del carico solo per il controller di distribuzione `ECS` mobile, non blu/verde o esterno. AWS CloudFormation AWS CodeDeploy Quando aggiungi, aggiorni o rimuovi una configurazione del load balancer, Amazon ECS avvia una nuova implementazione con la configurazione aggiornata di Elastic Load Balancing. Questo causa la registrazione e l'annullamento della registrazione dai load balancer. Si consiglia di verificarlo in un ambiente di test prima di aggiornare la configurazione di Elastic Load Balancing. Per informazioni su come modificare la configurazione, consulta il *riferimento [UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html)all'API di Amazon Elastic Container Service*. 
+ Se l'attività di un servizio non supera i criteri di controllo dell'integrità previsti per il bilanciatore del carico, viene arrestata e riavviata. Questo processo continua finché il servizio raggiunge il numero desiderato di attività in esecuzione.
+ Se riscontri problemi con i servizi abilitati per il load balancer, consulta [Risoluzione dei problemi dei bilanciatori del carico per il servizio in Amazon ECS](troubleshoot-service-load-balancers.md).
+ Quando si utilizza il tipo di destinazione `instance`, le attività e il bilanciatore del carico devono trovarsi nello stesso VPC. Quando si utilizza il tipo di destinazione `ip`, è supportata la connettività tra VPC.
+ Utilizzare un gruppo di destinazione unico per ogni servizio. 

  L'utilizzo dello stesso gruppo di destinazione per più servizi potrebbe causare problemi durante le implementazioni dei servizi.
+ È necessario specificare i gruppi target associati a un Application Load Balancer.

Per informazioni su come creare un Application Load Balancer, consultare [Create an Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-application-load-balancer.html) in *Application Load Balancer*

# Utilizzo di un Network Load Balancer per Amazon ECS
<a name="nlb"></a>

Un Network Load Balancer seleziona il routing a livello di trasporto (TCP/SSL). È in grado di gestire milioni di richieste al secondo. Dopo aver ricevuto una connessione, il bilanciatore del carico seleziona una destinazione dal gruppo di destinazione per la regola predefinita, utilizzando un algoritmo di routing per l'hash del flusso. Tenta quindi di aprire una connessione TCP per la destinazione selezionata sulla porta specificata nella configurazione del listener, Inoltra la richiesta senza modificare le intestazioni. I Network Load Balancer supportano la mappatura dinamica delle porte dell'host. Ad esempio, se la tua definizione del container del processo specifica la porta 80 per una porta di container NGINX e la porta 0 per la porta dell'host, quest'ultima viene selezionata in modo dinamico nell'intervallo di porte temporaneo dell'istanza di container (ad esempio da 32768 a 61000 nell'AMI ottimizzata per Amazon ECS più recente). Una volta avviata l'attività, il container NGINX viene registrato con il Network Load Balancer come combinazione di ID istanza e porta, mentre il traffico viene instradato all'ID istanza e alla porta corrispondenti a tale container. Con la mappatura dinamica possono essere presenti più attività di un unico servizio sulla stessa istanza di container. Per ulteriori informazioni, consultare [User Guide for Network Load Balancers](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/).

Per informazioni sulle best practice per impostare i parametri per velocizzare le implementazioni, consultare:
+ [Ottimizzare i parametri di controllo dell’integrità del bilanciatore del carico per Amazon ECS](load-balancer-healthcheck.md)
+ [Ottimizzazione dei parametri di svuotamento della connessione del bilanciatore del carico per Amazon ECS](load-balancer-connection-draining.md)

Quando si utilizzano i Network Load Balancer con Amazon ECS, tenere presenti le considerazioni seguenti:
+ Amazon ECS richiede il ruolo IAM collegato al servizio, che fornisce le autorizzazioni necessarie per eseguire e annullare la registrazione delle destinazioni nel tuo load balancer al momento dell'avvio e dell'arresto dei processi. Per ulteriori informazioni, consultare [Uso di ruoli collegati ai servizi per Amazon ECS](using-service-linked-roles.md).
+ Non è possibile collegare più di cinque gruppi di destinazione a un servizio.
+ Per i servizi in una configurazione IPv6 -only, è necessario impostare il tipo di indirizzo IP del gruppo di destinazione del Network Load `dualstack` Balancer su.
+ Per i servizi con attività che utilizzano la modalità di rete `awsvpc`, quando si crea un gruppo di destinazione per il servizio, è necessario scegliere `ip` come tipo di destinazione e non `instance`. Il motivo è che i processi che usano la modalità di rete `awsvpc` sono associati a un'interfaccia di rete elastica e non a un'istanza Amazon EC2.
+ La configurazione della sottorete del load balancer deve includere tutte le zone di disponibilità in cui risiedono le tue istanze di container.
+ Dopo aver creato un servizio, la configurazione del load balancer non può essere modificata dalla Console di gestione AWS. È possibile utilizzare AWS Copilot AWS CLI o SDK per modificare la configurazione del bilanciamento del carico solo per il controller di distribuzione `ECS` mobile, non blu/verde o esterno. AWS CloudFormation AWS CodeDeploy Quando aggiungi, aggiorni o rimuovi una configurazione del load balancer, Amazon ECS avvia una nuova implementazione con la configurazione aggiornata di Elastic Load Balancing. Questo causa la registrazione e l'annullamento della registrazione dai load balancer. Si consiglia di verificarlo in un ambiente di test prima di aggiornare la configurazione di Elastic Load Balancing. Per informazioni su come modificare la configurazione, consulta il *riferimento [UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html)all'API di Amazon Elastic Container Service*. 
+ Se l'attività di un servizio non supera i criteri di controllo dell'integrità previsti per il bilanciatore del carico, viene arrestata e riavviata. Questo processo continua finché il servizio raggiunge il numero desiderato di attività in esecuzione.
+ Quando si utilizza un Gateway Load Balancer configurato con indirizzi IP come destinazioni e la conservazione dell'IP client è disabilitata, le richieste vengono viste come provenienti dall'indirizzo IP privato del Gateway Load Balancer. Ciò significa che i servizi dietro un Gateway Load Balancer vengono effettivamente aperti al mondo non appena si consentono le richieste in entrata e i controlli di integrità nel gruppo di sicurezza di destinazione.
+ Per le attività di Fargate, è necessario utilizzare la versione della piattaforma `1.4.0` (Linux) o `1.0.0` (Windows).
+ Se riscontri problemi con i servizi abilitati per il load balancer, consulta [Risoluzione dei problemi dei bilanciatori del carico per il servizio in Amazon ECS](troubleshoot-service-load-balancers.md).
+ Quando si utilizza il tipo di destinazione `instance`, le attività e il bilanciatore del carico devono trovarsi nello stesso VPC. Quando si utilizza il tipo di destinazione `ip`, è supportata la connettività tra VPC.
+ La conservazione dell'indirizzo IP client del Network Load Balancer è compatibile con le destinazioni Fargate.
+ Utilizzare un gruppo di destinazione unico per ogni servizio. 

  L'utilizzo dello stesso gruppo di destinazione per più servizi potrebbe causare problemi durante le implementazioni dei servizi.
+ È necessario specificare i gruppi target associati a un Network Load Balancer.

Per informazioni su come creare un Network Load Balancer, consultare [Creare un Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/create-network-load-balancer.html) in *Network Load Balancer*

**Importante**  
Se la definizione di attività del servizio usa la modalità di rete `awsvpc`, necessaria per Fargate, è necessario scegliere `ip` come tipo di destinazione e non `instance`. Il motivo è che i processi che usano la modalità di rete `awsvpc` sono associati a un'interfaccia di rete elastica e non a un'istanza Amazon EC2.   
Non è possibile registrare le istanze per ID di istanza se hanno i seguenti tipi di istanza: C1,,, CC1, CC2, CG1, G1 CG2 CR1, G2,, M1, M2 HI1 HS1, M3 e T1. È possibile registrare le istanze di questi tipi in base all'indirizzo IP. 

# Utilizzo di un Gateway Load Balancer per Amazon ECS
<a name="glb"></a>

Un Gateway Load Balancer funziona al terzo livello del modello Open Systems Interconnection (OSI), il livello di rete. È in ascolto per tutti i pacchetti IP attraverso tutte le porte e inoltra il traffico al gruppo di destinazione specificato nella regola del listener. Mantiene la persistenza dei flussi verso un dispositivo di destinazione specifico utilizzando 5 tuple (per i flussi) o 3 tuple (per i flussi non TCP/UDP). TCP/UDP Ad esempio, se la tua definizione del container del processo specifica la porta 80 per una porta di container NGINX e la porta 0 per la porta dell'host, quest'ultima viene selezionata in modo dinamico nell'intervallo di porte temporaneo dell'istanza di container (ad esempio da 32768 a 61000 nell'AMI ottimizzata per Amazon ECS più recente). Una volta avviata l'attività, il container NGINX viene registrato con il Gateway Load Balancer come combinazione di ID istanza e porta, mentre il traffico viene instradato all'ID istanza e alla porta corrispondenti a tale container. Con la mappatura dinamica possono essere presenti più attività di un unico servizio sulla stessa istanza di container. Per ulteriori informazioni, consultare [What is a Gateway Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/gateway/introduction.html) in *Gateway Load Balancer*.

Per informazioni sulle best practice per impostare i parametri per velocizzare le implementazioni, consultare:
+ [Ottimizzare i parametri di controllo dell’integrità del bilanciatore del carico per Amazon ECS](load-balancer-healthcheck.md)
+ [Ottimizzazione dei parametri di svuotamento della connessione del bilanciatore del carico per Amazon ECS](load-balancer-connection-draining.md)

Quando si utilizzano i Gateway Load Balancer con Amazon ECS, tenere presenti le considerazioni seguenti:
+ Amazon ECS richiede il ruolo IAM collegato al servizio, che fornisce le autorizzazioni necessarie per eseguire e annullare la registrazione delle destinazioni nel tuo load balancer al momento dell'avvio e dell'arresto dei processi. Per ulteriori informazioni, consulta [Uso di ruoli collegati ai servizi per Amazon ECS](using-service-linked-roles.md).
+ Per i servizi in una configurazione IPv6 solo, è necessario impostare il tipo di indirizzo IP del gruppo di destinazione del Gateway Load `dualstack` Balancer su.
+ Per i servizi con attività che utilizzano una modalità di rete diversa da `awsvpc`, i Gateway Load Balancer non sono supportati.
+ La configurazione della sottorete del load balancer deve includere tutte le zone di disponibilità in cui risiedono le tue istanze di container.
+ Dopo aver creato un servizio, la configurazione del load balancer non può essere modificata dalla Console di gestione AWS. È possibile utilizzare AWS Copilot AWS CLI o SDK per modificare la configurazione del load balancer solo per il controller di distribuzione `ECS` mobile, non blu/verde o esterno. AWS CloudFormation AWS CodeDeploy Quando aggiungi, aggiorni o rimuovi una configurazione del load balancer, Amazon ECS avvia una nuova implementazione con la configurazione aggiornata di Elastic Load Balancing. Questo causa la registrazione e l'annullamento della registrazione dai load balancer. Si consiglia di verificarlo in un ambiente di test prima di aggiornare la configurazione di Elastic Load Balancing. Per informazioni su come modificare la configurazione, consulta il *riferimento [UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html)all'API di Amazon Elastic Container Service*. 
+ Se l'attività di un servizio non supera i criteri di controllo dell'integrità previsti per il bilanciatore del carico, viene arrestata e riavviata. Questo processo continua finché il servizio raggiunge il numero desiderato di attività in esecuzione.
+ Quando si utilizza un Gateway Load Balancer configurato con indirizzi IP come destinazioni, le richieste vengono viste come provenienti dall'indirizzo IP privato del Gateway Load Balancer. Ciò significa che i servizi dietro un Gateway Load Balancer vengono effettivamente aperti al mondo non appena si consentono le richieste in entrata e i controlli di integrità nel gruppo di sicurezza di destinazione.
+ Per le attività di Fargate, è necessario utilizzare la versione della piattaforma `1.4.0` (Linux) o `1.0.0` (Windows).
+ Se riscontri problemi con i servizi abilitati per il load balancer, consulta [Risoluzione dei problemi dei bilanciatori del carico per il servizio in Amazon ECS](troubleshoot-service-load-balancers.md).
+ Quando si utilizza il tipo di destinazione `instance`, le attività e il bilanciatore del carico devono trovarsi nello stesso VPC. Quando si utilizza il tipo di destinazione `ip`, è supportata la connettività tra VPC.
+ Utilizzare un gruppo di destinazione unico per ogni servizio. 

  L'utilizzo dello stesso gruppo di destinazione per più servizi potrebbe causare problemi durante le implementazioni dei servizi.
+ È necessario specificare i gruppi target associati a un Gateway Load Balancer.

Per informazioni su come creare un Gateway Load Balancer, consultare [Getting started with Gateway Load Balancers](https://docs.aws.amazon.com/elasticloadbalancing/latest/gateway/getting-started.html) in *Gateway Load Balancer*

**Importante**  
Se la definizione di attività del servizio usa la modalità di rete `awsvpc`, necessaria per Fargate, è necessario scegliere `ip` come tipo di destinazione e non `instance`. Il motivo è che i processi che usano la modalità di rete `awsvpc` sono associati a un'interfaccia di rete elastica e non a un'istanza Amazon EC2.   
Non è possibile registrare le istanze per ID di istanza se hanno i seguenti tipi di istanza: C1,,, CC1, CC2, CG1, G1 CG2 CR1, G2,, M1, M2 HI1 HS1, M3 e T1. È possibile registrare le istanze di questi tipi in base all'indirizzo IP. 

# Registrazione di più gruppi di destinazione con un servizio Amazon ECS
<a name="register-multiple-targetgroups"></a>

Il servizio Amazon ECS è in grado di servire traffico proveniente da più load balancer ed esporre più porte con carico bilanciato quando si specificano più gruppi di destinazione in una definizione del servizio.

Per creare un servizio che specifichi più gruppi target, devi creare il servizio utilizzando l'API Amazon ECS, l'SDK o un AWS CLI modello. CloudFormation Dopo aver creato il servizio, è possibile visualizzare il servizio e i gruppi di destinazione registrati in esso con la Console di gestione AWS. Devi utilizzare `[UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html)` per modificare la configurazione del load balancer di un servizio esistente.

Più gruppi di destinazione possono essere specificati in una definizione del servizio utilizzando il formato seguente. Per la sintassi completa di una definizione di servizio, vedere [Modello di definizione del servizio](sd-template.md).

```
"loadBalancers":[
   {  
      "targetGroupArn":"arn:aws:elasticloadbalancing:region:123456789012:targetgroup/target_group_name_1/1234567890123456",
      "containerName":"container_name",
      "containerPort":container_port
   },
   {  
      "targetGroupArn":"arn:aws:elasticloadbalancing:region:123456789012:targetgroup/target_group_name_2/6543210987654321",
      "containerName":"container_name",
      "containerPort":container_port
   }
]
```

## Considerazioni
<a name="multiple-targetgroups-considerations"></a>

Considera quanto segue durante la specifica di più gruppi di destinazione in una definizione del servizio:
+ Per i servizi che utilizzano Application Load Balancer o un Network Load Balancer (load balancer di rete), non è possibile collegare più di cinque gruppi di destinazione a un servizio.
+ La specifica di più gruppi di destinazione in una definizione di servizio è supportata solo nelle seguenti condizioni:
  + Il servizio deve utilizzare un sistema Application Load Balancer o un Network Load Balancer.
  + Il servizio deve utilizzare il tipo di controller di implementazione (`ECS`). Può trattarsi della distribuzione native/blue ecologica di Amazon ECS o della distribuzione di aggiornamento progressivo.
+ La specifica di più gruppi di destinazione è supportata per servizi contenenti processi che utilizzano entrambi i tipi di avvio Fargate e EC2.
+ Durante la creazione di un servizio che specifica più gruppi di destinazione, è necessario creare il ruolo collegato ai servizi Amazon ECS. Il ruolo viene creato omettendo il parametro `role` nelle richieste API o la proprietà `Role` in CloudFormation. Per ulteriori informazioni, consulta [Uso di ruoli collegati ai servizi per Amazon ECS](using-service-linked-roles.md).

## Definizioni del servizio di esempio
<a name="multiple-targetgroups-examples"></a>

Di seguito sono riportati alcuni casi d'uso per la specifica di più gruppi di destinazione in una definizione del servizio. Per la sintassi completa di una definizione di servizio, vedere [Modello di definizione del servizio](sd-template.md).

### Disporre di load balancer separati per il traffico interno ed esterno
<a name="multiple-targetgroups-example1"></a>

Nel seguente caso d'uso, un servizio utilizza due load balancer separati, uno per il traffico interno e un secondo per il traffico della connessione Internet, per lo stesso container e porta.

```
"loadBalancers":[
   //Internal ELB
   {  
      "targetGroupArn":"arn:aws:elasticloadbalancing:region:123456789012:targetgroup/target_group_name_1/1234567890123456",
      "containerName":"nginx",
      "containerPort":8080
   },
   //Internet-facing ELB
   {  
      "targetGroupArn":"arn:aws:elasticloadbalancing:region:123456789012:targetgroup/target_group_name_2/6543210987654321",
      "containerName":"nginx",
      "containerPort":8080
   }
]
```

### Esporre più porte dallo stesso container
<a name="multiple-targetgroups-example1"></a>

Nel seguente caso d'uso, un servizio utilizza un load balancer, ma espone più porte dallo stesso container. Ad esempio, un container Jenkins potrebbe esporre la porta 8080 per l'interfaccia Web Jenkins e la porta 50000 per l'API.

```
"loadBalancers":[
   {  
      "targetGroupArn":"arn:aws:elasticloadbalancing:region:123456789012:targetgroup/target_group_name_1/1234567890123456",
      "containerName":"jenkins",
      "containerPort":8080
   },
   {  
      "targetGroupArn":"arn:aws:elasticloadbalancing:region:123456789012:targetgroup/target_group_name_2/6543210987654321",
      "containerName":"jenkins",
      "containerPort":50000
   }
]
```

### Esporre porte da più container
<a name="multiple-targetgroups-example3"></a>

Nel seguente caso d'uso, un servizio utilizza un load balancer e due gruppi di destinazione per esporre porte da container separati.

```
"loadBalancers":[
   {  
      "targetGroupArn":"arn:aws:elasticloadbalancing:region:123456789012:targetgroup/target_group_name_1/1234567890123456",
      "containerName":"webserver",
      "containerPort":80
   },
   {  
      "targetGroupArn":"arn:aws:elasticloadbalancing:region:123456789012:targetgroup/target_group_name_2/6543210987654321",
      "containerName":"database",
      "containerPort":3306
   }
]
```

# Scalabilità automatica del servizio Amazon ECS
<a name="service-auto-scaling"></a>

La *scalabilità automatica* è la capacità di aumentare o diminuire automaticamente il numero di processi nel servizio Amazon ECS. Amazon ECS utilizza il servizio di Application Auto Scaling per fornire questa funzionalità. Per ulteriori informazioni, consultare [Application Auto Scaling User Guide](https://docs.aws.amazon.com/autoscaling/application/userguide/what-is-application-auto-scaling.html).

Amazon ECS pubblica CloudWatch metriche con l'utilizzo medio di CPU e memoria del tuo servizio. Per ulteriori informazioni, consulta [Parametri di utilizzo del servizio Amazon ECS](service_utilization.md). Puoi utilizzare queste e altre CloudWatch metriche per scalare il tuo servizio (aggiungere altre attività) per far fronte a una domanda elevata nelle ore di punta e scalare il servizio (eseguire meno attività) per ridurre i costi nei periodi di basso utilizzo. 

Amazon ECS Service Auto Scaling supporta i seguenti tipi di scalabilità automatica:
+ [Usa una metrica target per scalare i servizi Amazon ECS](service-autoscaling-targettracking.md): aumenta o diminuisci il numero di attività eseguite dal servizio in base al valore di destinazione per un parametro specifico. Questa operazione può essere paragonata al modo in cui il termostato regola la temperatura di una casa. Tu selezioni la temperatura, il termostato si occupa del resto.
+ [Usa incrementi predefiniti basati sugli CloudWatch allarmi per scalare i servizi Amazon ECS](service-autoscaling-stepscaling.md): aumenta o diminuisci il numero di attività eseguite dal servizio in base a una serie di regolazioni di dimensionamento, chiamate regolazioni per fasi, che variano in base alla dimensione dell'utilizzo fuori limite segnalato dall'allarme. 
+ [Usa azioni pianificate per scalare i servizi Amazon ECS](service-autoscaling-schedulescaling.md): aumenta o riduce il numero di processi eseguiti dal servizio in base alla data e all'ora.
+ [Usa modelli storici per scalare i servizi Amazon ECS con scalabilità predittiva](predictive-auto-scaling.md): aumenta o riduce il numero di attività eseguite dal servizio in base all'analisi storica dei dati di carico per rilevare modelli giornalieri o settimanali nei flussi di traffico. 

   

## Considerazioni
<a name="auto-scaling-concepts"></a>

Quando usi le policy di dimensionamento, tieni in considerazione quanto segue:
+ Amazon ECS invia i parametri a intervalli di 1 minuto a. CloudWatch Le metriche non sono disponibili finché i cluster e i servizi non le inviano a e non è possibile creare CloudWatch CloudWatch allarmi per metriche che non esistono. 
+ Le policy di dimensionamento supportano un periodo di attesa. Questo è il numero di secondi da attendere per rendere effettiva un'attività di dimensionamento precedente. 
  + Per gli eventi di dimensionamento orizzontale, l'intenzione è di aumentare continuamente (ma non eccessivamente). Dopo che la scalabilità automatica dei servizi ha correttamente eseguito il dimensionamento orizzontale tramite una policy di dimensionamento, inizia a calcolare il periodo di attesa. La policy di dimensionamento non aumenterà di nuovo la capacità desiderata, a meno che non venga attivato un aumento orizzontale o che venga raggiunto il tempo di raffreddamento. Mentre è attivo il periodo di attesa di incremento, la capacità aggiunta dall'attività di incremento iniziale viene calcolata come parte della capacità desiderata per il successivo evento di incremento. 
  + Per gli eventi di riduzione orizzontale, l'intenzione è di ridurre orizzontalmente in modo conservativo per proteggere la disponibilità dell'applicazione, in modo che le attività di riduzione siano bloccate fino alla scadenza del tempo di raffreddamento. Tuttavia, se un altro allarme attiva un'attività di aumento orizzontale durante il tempo di raffreddamento di riduzione orizzontale, Service Auto Scaling esegue immediatamente la riduzione orizzontale della destinazione. In questo caso, il periodo di attesa di riduzione si interrompe e non viene completato. 
+ Lo scheduler di servizi rispetta il numero desiderato in qualsiasi momento, ma fino a quando avrai policy di dimensionamento e allarmi su un servizio attivi, Service Auto Scaling potrebbe modificare un numero desiderato da te impostato manualmente.
+ Se un numero desiderato del servizio è impostato al di sotto del suo valore di capacità minimo e un allarme avvia un'attività di dimensionamento orizzontale, Service Auto Scaling dimensiona il numero desiderato fino al valore di capacità minimo e continua ad aumentare in base alle necessità e alla policy di dimensionamento associata all'allarme. Tuttavia, un'attività di dimensionamento in riduzione non modifica il numero desiderato, poiché esso è già inferiore al valore di capacità minimo.
+ Se un numero desiderato del servizio è impostato al di sopra del suo valore di capacità massimo e un allarme avvia un'attività di riduzione, Service Auto Scaling aumenta il numero desiderato fino al valore di capacità massimo e continua a ridurre in base alle necessità e alla policy di dimensionamento associata all'allarme. Tuttavia, un'attività di aumento non modifica il numero desiderato, poiché esso è già superiore al valore di capacità massimo.
+ Durante le attività di dimensionamento, il numero reale delle attività in esecuzione in un servizio è il valore che Service Auto Scaling utilizza come punto di partenza, in contrapposizione al numero desiderato. Questo è ciò che dovrebbe essere la capacità di elaborazione. In questo modo si impedisce un dimensionamento eccessivo (fuori controllo) che non può essere soddisfatto, ad esempio, se non ci sono sufficienti risorse di istanze di container per inserire le attività aggiuntive. Se la capacità dell'istanza di container è disponibile in un secondo momento, l'attività di dimensionamento in attesa potrebbe andare a buon fine e, quindi, le attività di dimensionamento potrebbero continuare dopo il periodo di attesa.
+ Se desideri che il numero di attività venga dimensionato a zero quando non è necessario eseguire alcuna operazione, imposta una capacità minima pari a 0. Con le policy di dimensionamento con monitoraggio degli obiettivi, quando la capacità effettiva è 0 e il parametro indica che esiste una domanda di carico di lavoro, Service Auto Scaling attende l'invio di un punto dati prima del dimensionamento orizzontale. In questo caso, viene dimensionato in base alla quantità minima possibile come punto di partenza e quindi riprende il dimensionamento in base al numero effettivo di processi in esecuzione.
+ Application Auto Scaling disattiva la riduzione dei processi mentre sono in corso le implementazioni di Amazon ECS. Tuttavia, durante l'implementazione i processi di dimensionamento orizzontale continuano a verificarsi, a meno che non siano sospesi. Questo comportamento non si applica ai servizi di Amazon ECS che utilizzano il controller di implementazione esterno. Per ulteriori informazioni, consultare [Scalabilità automatica e implementazioni dei servizi](#service-auto-scaling-deployments).
+ Sono disponibili diverse opzioni di Application Auto Scaling per le attività di Amazon ECS. Il monitoraggio degli obiettivi è la modalità più semplice da utilizzare, in quanto è necessario soltanto impostare un valore target per un parametro, ad esempio l'utilizzo medio della CPU. L'autoscaler gestisce automaticamente il numero di attività necessarie per raggiungere tale valore. Il dimensionamento per fasi consente di reagire più rapidamente alle variazioni della domanda, poiché si definiscono le soglie specifiche per i parametri di dimensionamento e il numero di attività da aggiungere o rimuovere quando le soglie vengono superate. In particolare, consente di reagire molto rapidamente alle variazioni della domanda riducendo al minimo il tempo di superamento di una soglia di allarme.

Per ulteriori informazioni sulle best practice per il dimensionamento automatico dei servizi, consultare [Ottimizzazione del dimensionamento automatico del servizio Amazon ECS](capacity-autoscaling-best-practice.md).

## Scalabilità automatica e implementazioni dei servizi
<a name="service-auto-scaling-deployments"></a>

Application Auto Scaling disattiva la riduzione dei processi mentre sono in corso le implementazioni di Amazon ECS. Tuttavia, durante l'implementazione i processi di dimensionamento orizzontale continuano a verificarsi, a meno che non siano sospesi. Questo comportamento non si applica ai servizi di Amazon ECS che utilizzano il controller di implementazione esterno. Se desideri sospendere i processi di scalabilità orizzontale durante le implementazioni in corso, attieniti alla seguente procedura.

1. Chiama il [describe-scalable-targets](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/describe-scalable-targets.html)comando, specificando l'ID della risorsa del servizio associato alla destinazione scalabile in Application Auto Scaling (Esempio:). `service/default/sample-webapp` Registra l'output. Ne avrai bisogno quando chiamerai il comando successivo.

1. Richiamate il [register-scalable-target](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/register-scalable-target.html)comando, specificando l'ID della risorsa, lo spazio dei nomi e la dimensione scalabile. Specifica `true` sia per `DynamicScalingInSuspended` che per `DynamicScalingOutSuspended`.

1. Una volta completata la distribuzione, puoi chiamare il [register-scalable-target](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/register-scalable-target.html)comando per riprendere il ridimensionamento.

Per ulteriori informazioni, consultare [Suspending and resuming scaling for Application Auto Scaling](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-suspend-resume-scaling.html).

# Usa una metrica target per scalare i servizi Amazon ECS
<a name="service-autoscaling-targettracking"></a>

Con le policy di dimensionamento con monitoraggio degli obiettivi, puoi scegliere un parametro e impostare un valore obiettivo. Amazon ECS Service Auto Scaling crea e gestisce gli allarmi che controllano CloudWatch la politica di scalabilità e calcola la regolazione della scalabilità in base alla metrica e al valore target. La politica di scalabilità aggiunge o rimuove le attività di servizio necessarie per mantenere la metrica pari o vicina al valore target specificato. Oltre a mantenere la metrica vicina al valore target, una politica di scalabilità basata sul tracciamento degli obiettivi si adatta anche alle fluttuazioni della metrica dovute a uno schema di carico fluttuante e riduce al minimo le rapide fluttuazioni nel numero di attività in esecuzione nel servizio.

Le policy di tracciamento di Target eliminano la necessità di definire manualmente gli allarmi e gli aggiustamenti di scalabilità. CloudWatch Amazon ECS lo gestisce automaticamente in base alla destinazione impostata.

Tieni presenti le seguenti informazioni quando usi le policy di tracciamento delle destinazioni:
+ Una policy di dimensionamento di monitoraggio obiettivi presuppone che essa debba eseguire un dimensionamento orizzontale quando il parametro specificato supera il valore di destinazione. Non puoi utilizzare una policy di dimensionamento di monitoraggio obiettivi per il dimensionamento orizzontale quando il parametro specificato è inferiore al valore di destinazione.
+ Una policy di dimensionamento di monitoraggio obiettivi non esegue il dimensionamento quando il parametro specificato non dispone di dati sufficienti. Non esegue la scalabilità in quanto la carenza di dati non viene interpretata come basso utilizzo.
+ Potrebbero esserci delle differenze tra il valore di destinazione e i punti di dati dei parametri reali. Ciò avviene perché Service Auto Scaling agisce sempre con prudenza, arrotondando per eccesso o per difetto quando determina la capacità da aggiungere o rimuovere. In questo modo si impedisce l'aggiunta di capacità insufficiente o la rimozione di capacità eccessiva. 
+ Per garantire la disponibilità delle applicazioni, il servizio aumenta in proporzione al parametro il più veloce possibile, ma si riduce in modo più graduale.
+ Application Auto Scaling disattiva la riduzione dei processi mentre sono in corso le implementazioni di Amazon ECS. Tuttavia, durante l'implementazione i processi di dimensionamento orizzontale continuano a verificarsi, a meno che non siano sospesi. Questo comportamento non si applica ai servizi di Amazon ECS che utilizzano il controller di implementazione esterno. Per ulteriori informazioni, consultare [Scalabilità automatica e implementazioni dei servizi](service-auto-scaling.md#service-auto-scaling-deployments).
+ Puoi avere più policy di dimensionamento con monitoraggio degli obiettivi per un servizio Amazon ECS, purché ciascuna di esse utilizzi parametri differenti. Lo scopo di Service Auto Scaling è sempre quello di assegnare la priorità alla disponibilità, quindi il suo comportamento varia a seconda che le policy di monitoraggio degli obiettivi siano pronte o meno per l'aumento o la riduzione orizzontale. Il servizio viene aumentato se una qualsiasi delle policy di monitoraggio delle destinazioni è pronta per l'aumento, ma viene ridotto solo se tutte le policy di monitoraggio delle destinazioni (con la parte di riduzione abilitata) sono pronte per la riduzione. 
+ Non modificare o eliminare gli CloudWatch allarmi gestiti da Service Auto Scaling per una politica di scalabilità di tracciamento degli obiettivi. Service Auto Scaling elimina gli allarmi automaticamente quando elimini la policy di dimensionamento.
+ La `ALBRequestCountPerTarget` metrica per le politiche di scalabilità del tracciamento degli obiettivi non è supportata per il tipo di implementazione. blue/green 

Per ulteriori informazioni sulle policy di dimensionamento di tracciamento target, consulta la sezione relativa alle [policy di dimensionamento di tracciamento target](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-target-tracking.html) nella *Guida per l'utente di Application Auto Scaling*.

# Creazione di una policy di dimensionamento con monitoraggio delle destinazioni per dimensionamento automatico del servizio Amazon ECS
<a name="target-tracking-create-policy"></a>

Creare una policy di scalabilità di tracciamento di destinazione per consentire ad Amazon ECS di aumentare o diminuire automaticamente il numero di attività desiderate nel servizio. Il monitoraggio della destinazione funziona sulla base di un valore metrico target.

## Console
<a name="target-tracking-create-policy-aws-console"></a>

1. Oltre alle autorizzazioni IAM standard per la creazione e l'aggiornamento dei servizi, sono necessarie autorizzazioni aggiuntive. Per ulteriori informazioni, consultare [Autorizzazioni IAM richieste per il dimensionamento automatico dei servizi Amazon ECS](auto-scaling-IAM.md).

1. Determinare le metriche da utilizzare per la policy. Sono disponibili i seguenti parametri:
   +  **ECSServiceMedia CPUUtilization**: l'utilizzo medio della CPU che il servizio dovrebbe utilizzare. 
   + **ECSServiceAverageMemoryUtilization**— Utilizzo medio della memoria che il servizio dovrebbe utilizzare. 
   + **ALBRequestCountPerTarget**— Il numero medio di richieste al minuto che l'attività dovrebbe idealmente ricevere.

1. Apri la console alla [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2).

1. Nella pagina **Cluster**, scegliere il cluster.

1. Nella pagina dei dettagli del cluster, nella sezione **Servizi**, selezionare il servizio.

   Si apre la pagina dei dettagli del servizio.

1. Scegliere **Imposta il numero delle attività**.

1. Nella sezione **Conteggio delle attività del servizio di Amazon ECS**, scegliere **Utilizzare il dimensionamento automatico**.

   Si apre la **Sezione dedicata al conteggio delle attività**.

   1. Per **Numero minimo di attività**, inserire il limite inferiore del numero di attività che devono essere utilizzate dal servizio di dimensionamento automatico. Il numero desiderato non scenderà al di sotto di questo conteggio.

   1. Per **Massimo**, inserire il limite superiore del numero di attività che devono essere utilizzate dal servizio di dimensionamento automatico. Il numero desiderato non sarà superiore a questo conteggio.

   1. Scegli **Save** (Salva).

      Si apre la pagina delle policy.

1. Scegliere **Crea una policy di dimensionamento**.

   Si apre la pagina **Crea policy**.

1. In **Tipo di policy di dimensionamento**, scegli **Monitoraggio obiettivi**.

1. In **Nome policy**, inserire il nome della policy.

1. In **Tipo di parametro**, scegliere i parametri nell'elenco di opzioni.

1. Per **Utilizzo di destinazione**, inserire il valore della destinazione per la percentuale di attività che Amazon ECS deve mantenere. Il dimensionamento automatico del servizio aumenta orizzontalmente la capacità finché l'utilizzo medio arriva a quello di destinazione o finché non raggiunge il numero massimo di attività specificato.

1. In **Impostazioni aggiuntive**, procedere come segue

   1. In **Tempo di raffreddamento di riduzione orizzontale**, immettere la quantità di tempo che deve passare, in secondi, tra il completamento di un'attività di riduzione e l'inizio di un'altra attività di questo tipo. 

   1. Per **Tempo di raffreddamento di aumento orizzontale**, immettere la quantità di tempo, espressa in secondi, da aspettare per rendere effettiva un'attività di aumento precedente.

   1. Per creare una policy di aumento, selezionare **Disabilita riduzione**.

1. Scegliere **Crea una policy di dimensionamento**.

## AWS CLI
<a name="target-tracking-create-policy-aws-cli"></a>

1. Registra il tuo servizio Amazon ECS come destinazione scalabile utilizzando il [register-scalable-target](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/register-scalable-target.html)comando.

1. Crea una politica di scalabilità utilizzando il comando. [put-scaling-policy](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/put-scaling-policy.html)

# Usa incrementi predefiniti basati sugli CloudWatch allarmi per scalare i servizi Amazon ECS
<a name="service-autoscaling-stepscaling"></a>

Con le politiche di scalabilità graduale, puoi creare e gestire gli CloudWatch allarmi che richiamano il processo di scalabilità. Quando viene violato un allarme, Amazon ECS avvia la politica di scalabilità associata a tale allarme. La policy di dimensionamento in fasi ridimensiona le attività utilizzando una serie di regolazioni, note come regolazioni della fase. La portata della regolazione varia in base alla dimensione dell'utilizzo fuori limite segnalato dall'allarme. 
+ Se la violazione supera la prima soglia, Amazon ECS applicherà la prima modifica. 
+ Se la violazione supera la seconda soglia, Amazon ECS applicherà la seconda modifica, e così via.

Si consiglia vivamente di utilizzare policy di dimensionamento del monitoraggio delle destinazioni per eseguire un dimensionamento in base a parametri come l'utilizzo medio della CPU o il numero di richieste medio per destinazione. I parametri che diminuiscono quando la capacità aumenta e aumentano quando la capacità diminuisce possono essere utilizzati per dimensionare proporzionalmente il numero di attività mediante il monitoraggio degli obiettivi. Questo contribuisce a garantire che Amazon ECS segua da vicino la curva della domanda per le applicazioni.

# Creazione di una policy di dimensionamento graduale per il dimensionamento automatico del servizio Amazon ECS
<a name="step-scaling-create-policy"></a>

Creare una politica di scalabilità graduale per consentire ad Amazon ECS di aumentare o diminuire automaticamente il numero di attività desiderate nel servizio. Il dimensionamento graduale viene eseguito in base a un set di adeguamenti del dimensionamento, noti come adeguamenti di fasi, che variano in base alla dimensione dell'utilizzo fuori limite segnalato dall'allarme. 

## Console
<a name="step-scaling-create-policy-aws-console"></a>

1. Oltre alle autorizzazioni IAM standard per la creazione e l'aggiornamento dei servizi, sono necessarie autorizzazioni aggiuntive. Per ulteriori informazioni, consultare [Autorizzazioni IAM richieste per il dimensionamento automatico dei servizi Amazon ECS](auto-scaling-IAM.md).

1. Determinare le metriche da utilizzare per la policy. Sono disponibili i seguenti parametri:
   +  **ECSServiceMedia CPUUtilization**: l'utilizzo medio della CPU che il servizio dovrebbe utilizzare. 
   + **ECSServiceAverageMemoryUtilization**— Utilizzo medio della memoria che il servizio dovrebbe utilizzare. 
   + **ALBRequestCountPerTarget**— Il numero medio di richieste al minuto che l'attività dovrebbe idealmente ricevere.

1. Crea gli CloudWatch allarmi per le metriche. Per ulteriori informazioni, consulta [Creare un CloudWatch allarme basato su una soglia statica](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ConsoleAlarms.html) nella *Amazon CloudWatch User Guide*.

1. Apri la console nella [https://console.aws.amazon.com/ecs/versione 2](https://console.aws.amazon.com/ecs/v2).

1. Nella pagina **Cluster**, scegliere il cluster.

1. Nella pagina dei dettagli del cluster, nella sezione **Servizi**, selezionare il servizio.

   Si apre la pagina dei dettagli del servizio.

1. Scegliere **Imposta il numero delle attività**.

1. Nella sezione **Conteggio delle attività del servizio di Amazon ECS**, scegliere **Utilizzare il dimensionamento automatico**.

   Si apre la **Sezione dedicata al conteggio delle attività**.

   1. Per **Numero minimo di attività**, inserire il limite inferiore del numero di attività che devono essere utilizzate dal servizio di dimensionamento automatico. Il numero desiderato non scenderà al di sotto di questo conteggio.

   1. Per **Massimo**, inserire il limite superiore del numero di attività che devono essere utilizzate dal servizio di dimensionamento automatico. Il numero desiderato non sarà superiore a questo conteggio.

   1. Scegli **Save** (Salva).

      Si apre la pagina delle policy.

1. Scegliere **Crea una policy di dimensionamento**.

   Si apre la pagina **Crea policy**.

1. In **Tipo di policy di dimensionamento**, scegliere **Dimensionamento graduale**.

1. Configurare le proprietà di aumento orizzontale. In **Passaggi per aggiungere attività**, procedere come segue:

   1. In **Nome policy**, inserire il nome della policy.

   1. Per il **nome della CloudWatch sveglia**, scegli la CloudWatch sveglia.

   1. In **Tipo di aggregazione delle metriche**, scegliere come confrontare il parametro selezionato con la soglia definita.

   1. In **Tipi di regolazione**, scegliere se la regolazione si basa su una modifica del numero delle attività o su una modifica della percentuale di attività.

   1. In **Azioni da intraprendere**, inserire i valori relativi all'azione da intraprendere.

      Scegliere **Aggiungere passaggio** per aggiungere azioni aggiuntive.

1. Configurare le proprietà di riduzione orizzontale. In **Passaggi per rimuovere attività**, procedere come segue:

   1. In **Nome policy**, inserire il nome della policy.

   1. Per il **nome della CloudWatch sveglia**, scegli la CloudWatch sveglia.

   1. In **Tipo di aggregazione delle metriche**, scegliere come confrontare il parametro selezionato con la soglia definita.

   1. In **Tipi di regolazione**, scegliere se la regolazione si basa su una modifica del numero delle attività o su una modifica della percentuale di attività.

   1. In **Azioni da intraprendere**, inserire i valori relativi all'azione da intraprendere.

      Scegliere **Aggiungere passaggio** per aggiungere azioni aggiuntive.

1. In **Tempo di raffreddamento**, inserire la quantità di tempo, espressa in secondi, necessaria per rendere effettiva un'attività di dimensionamento precedente. Per una policy di aggiunta, si tratta del periodo successivo a un'attività di aumento orizzontale in cui la politica di scalabilità blocca le attività con aumento orizzontale e limita il numero di attività che possono essere aumentate orizzontalmente alla volta. Per una policy di rimozione, questo è il tempo che deve passare tra un'attività di riduzione e l'inizio di un'altra attività di questo tipo. 

1. Scegliere **Crea una policy di dimensionamento**.

## AWS CLI
<a name="step-scaling-create-policy-aws-cli"></a>

1. Registra il tuo servizio Amazon ECS come destinazione scalabile utilizzando il [register-scalable-target](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/register-scalable-target.html)comando.

1. Crea una politica di scalabilità utilizzando il comando. [put-scaling-policy](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/put-scaling-policy.html)

# Usa azioni pianificate per scalare i servizi Amazon ECS
<a name="service-autoscaling-schedulescaling"></a>

Con il dimensionamento pianificato, è possibile impostare il dimensionamento automatico per l'applicazione in base a variazioni di carico prevedibili, creando azioni pianificate che aumentano o diminuiscono il numero di attività in momenti specifici. Ciò consente di dimensionare l'applicazione in modo proattivo per far fronte alle variazioni di carico prevedibili.

Queste azioni di dimensionamento pianificate consentono di ottimizzare costi e prestazioni. L'applicazione dispone di un numero sufficiente di attività per gestire il picco di traffico infrasettimanale, ma in altri momenti non fornisce il numero di attività eccedente. 

È possibile utilizzare simultaneamente il dimensionamento pianificato e le policy di dimensionamento per ottenere i vantaggi degli approccia proattivi e reattivi al dimensionamento. Dopo l'esecuzione di un'operazione pianificata di dimensionamento, la policy di dimensionamento può continuare a prendere decisioni sull'opportunità di dimensionare ulteriormente il numero di attività. In questo modo è possibile garantire di disporre di un numero di attività sufficiente per la gestione dei carichi dell'applicazione. Sebbene l'applicazione si dimensioni per soddisfare la domanda, la capacità corrente deve rientrare nel numero minimo e massimo di attività impostati dall'operazione pianificata. 

È possibile configurare il dimensionamento della pianificazione utilizzando AWS CLI. Per ulteriori informazioni sul dimensionamento pianificato, consultare [Scheduled Scaling](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-scheduled-scaling.html) nella *Guida per l'utente del dimensionamento automatico delle applicazioni*.

# Creare un'operazione pianificata per il dimensionamento automatico del servizio Amazon ECS
<a name="scheduled-action-create-policy"></a>

Creare un'operazione pianificata per fare in modo che Amazon ECS aumenti o diminuisca il numero di attività eseguite dal servizio in base alla data e all'ora. 

## Console
<a name="scheduled-action-policy-aws-console"></a>

1. [Apri la console nella versione 2https://console.aws.amazon.com/ecs/.](https://console.aws.amazon.com/ecs/v2)

1. Nella pagina **Cluster**, scegliere il cluster.

1. Nella pagina dei dettagli del cluster, nella sezione **Servizi**, selezionare il servizio.

   Si apre la pagina dei dettagli del servizio.

1. Scegliere **Dimensionamento automatico del servizio**.

   Si apre la pagina di dimensionamento automatico del servizio.

1. Se non è stato configurato il dimensionamento automatico del servizio, scegliere **Imposta il numero di attività**.

   Viene visualizzata la sezione **Numero di attività del servizio Amazon ECS**.

   In **Numero di attività del servizio Amazon ECS**, scegliere **Usa il dimensionamento automatico del servizio per modificare il numero di attività desiderato per il servizio**.

   Si apre la **Sezione dedicata al conteggio delle attività**.

   1. Per **Numero minimo di attività**, inserire il limite inferiore del numero di attività che devono essere utilizzate dal servizio di dimensionamento automatico. Il numero desiderato non scenderà al di sotto di questo conteggio.

   1. Per **Massimo**, inserire il limite superiore del numero di attività che devono essere utilizzate dal servizio di dimensionamento automatico. Il numero desiderato non sarà superiore a questo conteggio.

   1. Scegliere **Salva**.

      Si apre la pagina delle policy.

1. Scegliere **Operazioni pianificate** e poi scegliere **Crea**.

   Si apre la pagina **Crea operazione pianificata**.

1. Per **Nome operazione**, inserire un nome univoco.

1. In **Time zone (Fuso orario)**, scegli un fuso orario.

   Tutti i fusi orari elencati provengono dal database del fuso orario IANA. Per ulteriori informazioni, consultare [List of tz database time zones](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones).

1. Per **Ora di inizio**, inserire la **data** e l'**ora** di inizio dell'operazione.

   Se si sceglie una pianificazione periodica, l'ora di avvio definisce quando verrà eseguita la prima operazione pianificata della serie ricorrente.

1. In **Compute (Calcolo)**, seleziona una delle opzioni disponibili.
   + Per dimensionare in base a una pianificazione ricorrente, scegliere la frequenza con cui Amazon ECS esegue l'operazione pianificata.
     + Se si sceglie un'operazione che inizia con **Rate**, viene creata l'espressione cron.
     + Se si sceglie **Cron**, inserire un'espressione cron che specifichi quando eseguire l'operazione. 
   + Per dimensionare una sola volta, scegliere **Una volta**.

1. In **Regolazioni delle attività**, procedere come segue:
   + Per **Minimo**, inserire il numero minimo di attività che il servizio deve eseguire.
   + Per **Massimo**, inserire il numero massimo di attività che il servizio deve eseguire.

1. Scegli **Crea operazione pianificata**.

## CLI
<a name="scheduled-action-aws-cli"></a>

Utilizza AWS CLI quanto segue per configurare le politiche di scalabilità pianificate per il tuo servizio. Sostituisci ogni *user input placeholder* con le tue informazioni.

**Esempio: dimensionamento unico**  
Utilizzate il [put-scheduled-action](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/put-scheduled-action.html)comando seguente con le `--MaxCapacity` opzioni `--start-time "YYYY-MM-DDThh:mm:ssZ"` and e `--MinCapacity` e o entrambe. 

```
aws application-autoscaling put-scheduled-action --service-namespace ecs \
  --resource-id service/my-cluster/my-service \
  --scheduled-action-name my-one-time-schedule \
  --start-time 2021-01-30T12:00:00 \
  --scalable-target-action MinCapacity=3,MaxCapacity=10
```

**Ad esempio: per pianificare il dimensionamento in base a una pianificazione ricorrente**  
Utilizza il seguente comando [put-scheduled-action](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/put-scheduled-action.html). *user input*Sostituiscili con i tuoi valori.

```
aws application-autoscaling put-scheduled-action --service-namespace ecs \
  --resource-id service/my-cluster/my-service \
  --scheduled-action-name my-recurring-action \
  --schedule "rate(5 hours)" \
  --start-time 2021-01-30T12:00:00 \
  --end-time 2021-01-31T22:00:00 \
  --scalable-target-action MinCapacity=3,MaxCapacity=10
```

Il programma di ricorrenza specificato viene eseguito in base al fuso orario UTC. Per specificare un fuso orario diverso, includere l'opzione `--time-zone` e specificare il nome del fuso orario IANA, come nel seguente esempio.

```
--time-zone "America/New_York"
```

Per ulteriori informazioni, consultare [List of tz database time zones](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones).

# Usa modelli storici per scalare i servizi Amazon ECS con scalabilità predittiva
<a name="predictive-auto-scaling"></a>

Il dimensionamento predittivo analizza i dati di caricamento passati provenienti dai flussi di traffico per analizzare i modelli giornalieri o settimanali. Poi utilizza l'analisi per anticipare le esigenze future e aumentare in modo proattivo le attività del tuo servizio secondo necessità.

Il dimensionamento automatico predittivo è particolarmente utile nelle seguenti situazioni:
+ Traffico ciclico: un uso elevato di risorse durante i normali orari di ufficio e un utilizzo ridotto di risorse durante la notte e il weekend.
+ Modelli di on-and-off carico di lavoro ricorrenti ‐ Gli esempi includono l'elaborazione in batch, i test o l'analisi periodica dei dati.
+ Applicazioni con tempi di inizializzazione lunghi: possono influire sulle prestazioni delle applicazioni durante gli eventi di aumento orizzontale, causando una notevole latenza.

Se le applicazioni richiedono molto tempo per l'inizializzazione e il traffico aumenta con uno schema regolare, è consigliabile utilizzare il dimensionamento predittivo. Aiuta a scalare più velocemente aumentando in modo proattivo il numero di attività per i carichi previsti, anziché utilizzare solo politiche di dimensionamento dinamico, come Target Tracking o Step Scaling. Aiutando a evitare la possibilità di effettuare un provisioning eccessivo del numero di attività, il dimensionamento predittivo può anche consentire di risparmiare denaro.

Ad esempio, consideriamo un'applicazione che ha un utilizzo elevato durante l'orario di lavoro e uno ridotto durante la notte. All'inizio di ogni giornata lavorativa, il dimensionamento predittivo può aumentare orizzontalmente le attività prima del primo afflusso di traffico. Ciò permette all'applicazione di mantenere elevata disponibilità e prestazioni quando si passa da un periodo di utilizzo inferiore a un periodo di utilizzo più elevato. Non è necessario attendere che il dimensionamento dinamico reagisca alla variazione di traffico. Inoltre, non è necessario dedicare tempo alla verifica dei modelli di carico dell'applicazione e al tentativo di pianificare la giusta quantità di attività con il dimensionamento programmato.

Il dimensionamento predittivo è una funzionalità a livello di servizio che ridimensiona l'attività del servizio indipendentemente dal dimensionamento della capacità di calcolo sottostante (ad esempio, EC2 o Fargate). Per Fargate, AWS gestisce e ridimensiona automaticamente la capacità sottostante in base ai requisiti delle attività. Per quanto riguarda la capacità di EC2, è possibile utilizzare i provider di capacità del gruppo Auto Scaling per scalare automaticamente le istanze EC2 sottostanti in base ai requisiti di dimensionamento delle attività.

**Topics**
+ [Panoramica del dimensionamento predittivo](#predictive-auto-scaling-overview)
+ [Creazione di una policy di dimensionamento predittivo](predictive-scaling-create-policy.md)
+ [Valutazione delle policy di dimensionamento predittivo](predictive-scaling-graphs.md)
+ [Sovrascrivere la previsione](predictive-scaling-overriding-forecast-capacity.md)
+ [Utilizzare parametri personalizzati](predictive-scaling-custom-metrics.md)

## Funzionamento del dimensionamento predittivo in Amazon ECS
<a name="predictive-auto-scaling-overview"></a>

Qui si possono scoprire le considerazioni sull'utilizzo del dimensionamento predittivo, come funziona e quali sono i limiti.

### Considerazioni sull'utilizzo del dimensionamento predittivo
<a name="predictive-auto-scaling-considerations"></a>
+ Il dimensionamento predittivo deve essere adeguato al carico di lavoro. Si può verificare configurando le policy di dimensionamento in modalità **solo previsione** e vedere cosa consiglia la console. È necessario valutare la previsione e i consigli prima di iniziare a utilizzare il dimensionamento predittivo.
+ Prima che il dimensionamento predittivo possa avviare la previsione, servono almeno 24 ore di dati cronologici. Maggiore è il numero di dati cronologici disponibili, più efficace è la previsione, con un periodo ideale di due settimane. Si dovrà inoltre attendere 24 ore prima che il dimensionamento predittivo possa generare nuove previsioni quando si elimina un servizio Amazon ECS e se ne crea uno nuovo. Un modo per velocizzare questa operazione è utilizzare parametri personalizzati per aggregare i parametri tra il vecchio e il nuovo servizio Amazon ECS.
+ Scegliere una metrica di carico che rappresenta con precisione il carico completo dell'applicazione ed è l'aspetto dell'applicazione su cui è più importante basare il dimensionamento.
+ Il dimensionamento dinamico con dimensionamento predittivo consente di seguire da vicino la richiesta della propria applicazione, in modo ridurre le attività durante le pause e aumentarle durante gli aumenti imprevisti del traffico. Quando sono attive più policy di dimensionamento, ciascuna di esse determina il numero desiderato di attività in modo indipendente, che viene impostato al massimo.
+ È possibile utilizzare il dimensionamento predittivo insieme alle policy di dimensionamento dinamico, come il monitoraggio della destinazione o il dimensionamento graduale, in modo che le applicazioni si scalino in base a modelli storici e in tempo reale. Di per sé, il dimensionamento predittivo non consente di ridurre orizzontalmente le attività. 
+ Se si utilizza un ruolo personalizzato durante la chiamata all'`register-scalable-target`API, si potrebbe ricevere un errore che indica che la policy di dimensionamento predittivo può funzionare solo con SLR abilitata. In questo caso, è necessario chiamare di nuovo `register-scalable-target` ma senza role-arn. Usare SLR per registrare la destinazione scalabile e chiamare l'API `put-scaling-policy`.

### Funzionamento del dimensionamento predittivo
<a name="predictive-auto-scaling-details"></a>

Utilizzate la scalabilità predittiva creando una politica di scalabilità predittiva che specifica la metrica da monitorare e analizzare. CloudWatch Per avviare valori futuri di previsione, il dimensionamento predittivo richiede almeno 24 ore di dati.

Dopo aver creato la policy, il dimensionamento predittivo inizia ad analizzare i dati metrici relativi agli ultimi 14 giorni per identificare i modelli. Questa analisi viene utilizzata per generare previsioni orarie dei requisiti per le prossime 48 ore. I CloudWatch dati più recenti vengono utilizzati per aggiornare la previsione ogni sei ore. Con l'arrivo di nuovi dati, il dimensionamento predittivo migliora continuamente l'accuratezza delle previsioni future.

La prima volta che si abilita il dimensionamento predittivo, questo viene eseguito in modalità di *sola previsione*. Genera previsioni in questa modalità, ma non dimensiona il servizio Amazon ECS in base a tali previsioni. Ciò significa che è possibile valutare l'accuratezza e l'idoneità della previsione. È possibile visualizzare i dati di previsione utilizzando l'operazione API `GetPredictiveScalingForecast` o la Console di gestione AWS.

Quando si decide di iniziare a utilizzare il dimensionamento predittivo, si deve passare dalla policy di dimensionamento alla modalità di *previsione e scalabilità*. In questa modalità si verifica quanto segue.

Per impostazione predefinita, il servizio Amazon ECS viene ridimensionato all'inizio di ogni ora in base alla previsione per quell'ora. È possibile scegliere di iniziare prima utilizzando la proprietà `SchedulingBufferTime` nell'operazione API `PutScalingPolicy`. Ciò consente l'avvio di nuove attività prima della domanda della previsione e si dispone del tempo per l'avvio e la preparazione a gestire il traffico.

### Limite massimo di attività
<a name="predictive-scaling-maximum-tasks-limit"></a>

Quando si registrano i servizi Amazon ECS per il dimensionamento, si definisce un numero massimo di attività che possono essere avviate per ogni servizio. Per impostazione predefinita, quando vengono impostate le policy di dimensionamento, non possono aumentare il numero di attività oltre il limite massimo.

In alternativa, è possibile consentire l'aumento automatico del numero massimo di attività del servizio se la previsione si avvicina o supera il numero massimo di attività del servizio Amazon ECS.

**avvertimento**  
Fare attenzione quando si consente l'aumento automatico del numero massimo di attività. Ciò può comportare l'avvio di più attività del previsto, se l'aumento del numero massimo di attività non viene monitorato e gestito. L'aumento del numero massimo di attività diventa quindi il nuovo normale numero massimo per il servizio Amazon ECS fino a quando non viene aggiornato manualmente. Il numero massimo di attività non torna automaticamente al massimo originale.

### Regioni supportate
<a name="predictive-auto-scaling-supported-regions"></a>
+ Stati Uniti orientali (Virginia settentrionale)
+ Stati Uniti orientali (Ohio)
+ Stati Uniti occidentali (California settentrionale)
+ Stati Uniti occidentali (Oregon)
+ Africa (Città del Capo)
+ Asia Pacifico (Hong Kong)
+ Asia Pacifico (Giacarta)
+ Asia Pacifico (Mumbai)
+ Asia Pacifico (Osaka)
+ Asia Pacifico (Seoul)
+ Asia Pacifico (Singapore)
+ Asia Pacifico (Sydney)
+ Asia Pacifico (Tokyo)
+ Canada (Centrale)
+ Cina (Pechino)
+ Cina (Ningxia)
+ Europa (Francoforte)
+ Europa (Irlanda)
+ Europa (Londra)
+ Europa (Milano)
+ Europa (Parigi)
+ Europa (Stoccolma)
+ Medio Oriente (Bahrein)
+ Sud America (San Paolo)
+ AWS GovCloud (Stati Uniti orientali)
+ AWS GovCloud (Stati Uniti occidentali)

# Creazione di una policy di dimensionamento predittivo per dimensionamento automatico del servizio Amazon ECS
<a name="predictive-scaling-create-policy"></a>

Creare una policy di dimensionamento predittivo per consentire ad Amazon ECS di aumentare o diminuire il numero di attività eseguite dal servizio in base ai dati cronologici. 

**Nota**  
Un nuovo servizio deve fornire almeno 24 ore di dati prima di poter generare una previsione.

## Console
<a name="predictive-scaling-policy-aws-console"></a>

1. Oltre alle autorizzazioni IAM standard per la creazione e l'aggiornamento dei servizi, sono necessarie autorizzazioni aggiuntive. Per ulteriori informazioni, consultare [Autorizzazioni IAM richieste per il dimensionamento automatico dei servizi Amazon ECS](auto-scaling-IAM.md).

1. Determinare le metriche da utilizzare per la policy. Sono disponibili i seguenti parametri:
   +  **ECSServiceMedio CPUUtilization**: l'utilizzo medio della CPU che il servizio dovrebbe utilizzare. 
   + **ECSServiceAverageMemoryUtilization**— Utilizzo medio della memoria che il servizio dovrebbe utilizzare. 
   + **ALBRequestCountPerTarget**— Il numero medio di richieste al minuto che l'attività dovrebbe idealmente ricevere.

   In alternativa, è possibile utilizzare una metrica personalizzata. È necessario definire i seguenti valori:
   + Carico: una metrica che rappresenta con precisione il carico completo dell'applicazione ed è l'aspetto dell'applicazione su cui è più importante basare il dimensionamento.
   + Metrica di dimensionamento: il miglior indicatore del grado di utilizzo ideale per l'applicazione.

1. Apri la console alla [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2).

1. Nella pagina **Cluster**, scegliere il cluster.

1. Nella pagina dei dettagli del cluster, nella sezione **Servizi**, selezionare il servizio.

   Si apre la pagina dei dettagli del servizio.

1. Scegliere **Dimensionamento automatico del servizio**, quindi scegliere **Imposta il numero di attività**.

1. Nella sezione **Conteggio delle attività del servizio di Amazon ECS**, scegliere **Utilizzare il dimensionamento automatico**.

   Si apre la **Sezione dedicata al conteggio delle attività**.

   1. Per **Numero minimo di attività**, inserire il limite inferiore del numero di attività che devono essere utilizzate dal servizio di dimensionamento automatico. Il numero desiderato non scenderà al di sotto di questo conteggio.

   1. Per **Massimo**, inserire il limite superiore del numero di attività che devono essere utilizzate dal servizio di dimensionamento automatico. Il numero desiderato non sarà superiore a questo conteggio.

   1. Scegli **Save** (Salva).

      Si apre la pagina delle policy.

1. Scegliere **Crea una policy di dimensionamento**.

   Si apre la pagina **Crea policy**.

1. Per **Tipo di policy di dimensionamento**, scegliere **Dimensionamento predittivo**.

1. In **Nome policy**, inserire il nome della policy.

1. In **Coppia di parametri**, scegliere i parametri dall'elenco di opzioni.

   Se è stato scelto **Conteggio delle richieste Application Load Balancer per destinazione**, scegliere un gruppo di destinazione in **Gruppo di destinazione**. **Conteggio di richieste Application Load Balancer per destinazione** è supportato solo se è stato allegato un gruppo di destinazione Application Load Balancer per il servizio. 

   Se è stato scelto **Coppia di parametri personalizzati**, scegliere i singoli parametri dagli elenchi per **Parametro del carico** e **Parametro di dimensionamento**. 

1. Per **Utilizzo di destinazione**, inserire il valore della destinazione per la percentuale di attività che Amazon ECS deve mantenere. Il dimensionamento automatico del servizio aumenta orizzontalmente la capacità finché l'utilizzo medio arriva a quello di destinazione o finché non raggiunge il numero massimo di attività specificato.

1. Scegliere **Crea una policy di dimensionamento**.

## AWS CLI
<a name="predictive-scaling-policy-aws-cli"></a>

Utilizza AWS CLI quanto segue per configurare le politiche di scalabilità predittiva per il tuo servizio Amazon ECS. Sostituisci ogni *user input placeholder* con le tue informazioni.

Per ulteriori informazioni sui CloudWatch parametri che puoi specificare, consulta il riferimento alle API [PredictiveScalingMetricSpecification](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_PredictiveScalingMetricSpecification.html)di *Amazon EC2 Auto* Scaling.

### Esempio 1: una policy di dimensionamento predittivo con memoria predefinita.
<a name="predictive-scaling-cli-example-one"></a>

Di seguito è riportato un esempio di policy con una configurazione di memoria predefinita.

```
cat policy.json
{
    "MetricSpecifications": [
        {
            "TargetValue": 40,
            "PredefinedMetricPairSpecification": {
                "PredefinedMetricType": "ECSServiceMemoryUtilization"
            }
        }
    ],
    "SchedulingBufferTime": 3600,
    "MaxCapacityBreachBehavior": "HonorMaxCapacity",
    "Mode": "ForecastOnly"
}
```

L'esempio seguente illustra la creazione della policy eseguendo il [put-scaling-policy](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/put-scaling-policy.html)comando con il file di configurazione specificato.

```
aws application-autoscaling put-scaling-policy \
--service-namespace ecs \
--region us-east-1 \
--policy-name predictive-scaling-policy-example \
--resource-id service/MyCluster/test \
--policy-type PredictiveScaling \
--scalable-dimension ecs:service:DesiredCount \
--predictive-scaling-policy-configuration file://policy.json
```

In caso di esito positivo, questo comando restituisce l'ARN della policy.

```
{
    "PolicyARN": "arn:aws:autoscaling:us-east-1:012345678912:scalingPolicy:d1d72dfe-5fd3-464f-83cf-824f16cb88b7:resource/ecs/service/MyCluster/test:policyName/predictive-scaling-policy-example",
    "Alarms": []
}
```

### Esempio 2: una policy di dimensionamento predittivo con CPU predefinita.
<a name="predictive-scaling-cli-example-two"></a>

Di seguito è riportato un esempio di policy con una configurazione di CPU predefinita.

```
cat policy.json
{
    "MetricSpecifications": [
        {
            "TargetValue": 0.00000004,
            "PredefinedMetricPairSpecification": {
                "PredefinedMetricType": "ECSServiceCPUUtilization"
            }
        }
    ],
    "SchedulingBufferTime": 3600,
    "MaxCapacityBreachBehavior": "HonorMaxCapacity",
    "Mode": "ForecastOnly"
}
```

L'esempio seguente illustra la creazione della politica eseguendo il [put-scaling-policy](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/put-scaling-policy.html)comando con il file di configurazione specificato.

```
aws aas put-scaling-policy \
--service-namespace ecs \
--region us-east-1 \
--policy-name predictive-scaling-policy-example \
--resource-id service/MyCluster/test \
--policy-type PredictiveScaling \
--scalable-dimension ecs:service:DesiredCount \
--predictive-scaling-policy-configuration file://policy.json
```

In caso di esito positivo, questo comando restituisce l'ARN della policy.

```
{
    "PolicyARN": "arn:aws:autoscaling:us-east-1:012345678912:scalingPolicy:d1d72dfe-5fd3-464f-83cf-824f16cb88b7:resource/ecs/service/MyCluster/test:policyName/predictive-scaling-policy-example",
    "Alarms": []
}
```

# Valutazione delle policy di dimensionamento predittivo per Amazon ECS
<a name="predictive-scaling-graphs"></a>

Prima di utilizzare una policy di dimensionamento predittivo per scalare i servizi, esaminare i consigli e gli altri dati per la policy nella console di Amazon ECS. È un'opzione importante per assicurarsi che le previsioni siano accurate prima di applicare una policy di dimensionamento predittivo che dimensioni la capacità effettiva.

Se il servizio è nuovo, attendere 24 ore per creare la prima previsione.

Quando AWS crea una previsione, utilizza dati storici. Se il servizio non dispone ancora di molti dati cronologici recenti, il dimensionamento automatico potrebbe temporaneamente riempire la previsione con aggregati creati dagli aggregati storici attualmente disponibili. Le previsioni vengono popolate per un massimo di due settimane prima della data di creazione di una policy.

## Visualizzazione dei suggerimenti per il dimensionamento predittivo
<a name="view-predictive-scaling-recommendations"></a>

Per un'analisi efficace, il dimensionamento automatico del servizio dovrebbe avere almeno due policy di dimensionamento predittivo da confrontare. Tuttavia, è ancora possibile esaminare i risultati per una singola policy. Quando crei più policy, puoi valutare una policy che utilizza un parametro rispetto a un parametro che ne utilizza uno diverso. Puoi anche valutare l'impatto di diverse combinazioni di valori di destinazione e parametri. Dopo aver creato le policy di dimensionamento predittivo, Amazon ECS inizia immediatamente a valutare quale policy è in grado di dimensionare il gruppo in modo ottimale.

**Per visualizzare i suggerimenti nella console Amazon ECS**

1. Apri la console alla [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2).

1. Nella pagina **Cluster**, scegliere il cluster.

1. Nella pagina dei dettagli del cluster, nella sezione **Servizi**, selezionare il servizio.

   Si apre la pagina dei dettagli del servizio.

1. Scegliere **Dimensionamento automatico del servizio**.

1. Scegliere la policy di dimensionamento predittivo, quindi scegliere **Operazioni**, **dimensionamento predittivo**, **Visualizza consigli**.

   È possibile visualizzare i dettagli di una policy e i relativi suggerimenti. Il suggerimento indica se l'utilizzo della policy di dimensionamento predittivo garantisce risultati migliori rispetto al non utilizzo. 

   Se non sei sicuro che una policy di dimensionamento predittivo sia appropriata per il tuo gruppo, consulta le colonne **Impatto sulla disponibilità** e **Impatto sui costi** per scegliere quella giusta. Le informazioni di ogni colonna indicano l'impatto della policy. 
   + **Impatto sulla disponibilità**: indica se l'utilizzo della policy eviterebbe un impatto negativo sulla disponibilità eseguendo il provisioning di un numero sufficiente di attività per gestire il carico di lavoro, rispetto al mancato utilizzo della policy.
   + **Impatto sui costi**: indica se l'utilizzo della policy eviterebbe un impatto negativo sui costi non eseguendo un provisioning eccessivo delle attività, rispetto al mancato utilizzo della policy. Se il provisioning è eccessivo, i servizi risultano sottoutilizzati o inattivi, comportando un maggiore impatto sui costi.

   Se disponi di più policy, accanto al nome della policy che offre i maggiori vantaggi in termini di disponibilità a un costo inferiore viene visualizzato il tag **Previsione migliore**. Viene attribuito un peso maggiore all'impatto sulla disponibilità. 

1. (Facoltativo) Per selezionare il periodo di tempo desiderato per i risultati dei suggerimenti, scegliere il valore preferito dal menu a discesa **Periodo di valutazione**: **2 giorni**, **1 settimana** o **2 settimane**. Per impostazione predefinita, il periodo di valutazione è rappresentato dalle ultime due settimane. Un periodo di valutazione maggiore fornisce più punti dati per i risultati del suggerimento. Tuttavia, l'aggiunta di più punti dati potrebbe non migliorare i risultati se i modelli di carico sono cambiati, ad esempio dopo un periodo di domanda eccezionalmente elevata. In questo caso, puoi ottenere un suggerimento più mirato esaminando i dati più recenti.

**Nota**  
I suggerimenti vengono generati solo per le policy in modalità **solo previsione**. Questa funzione restituisce i risultati migliori quando una policy è in modalità **solo previsione** per tutto il periodo di valutazione. Se avvii una policy in modalità **Previsione e dimensionamento** e in un secondo momento la modifichi in una modalità **solo previsione**, è probabile che i risultati siano falsati. Questo accade perché la policy ha già contribuito alla capacità effettiva.

## Analisi dei grafici di monitoraggio di dimensionamento predittivo
<a name="review-predictive-scaling-monitoring-graphs"></a>

Nella console, è possibile esaminare le previsioni dei giorni, delle settimane o dei mesi precedenti per visualizzare le prestazioni della policy nel tempo. È inoltre possibile utilizzare queste informazioni per valutare l'accuratezza delle previsioni nel momento in cui si decide di applicare la policy per dimensionare il numero effettivo di attività.

**Per esaminare i grafici di monitoraggio di dimensionamento predittivo nella console Amazon ECS**

1. Apri la console nella [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2).

1. Nella pagina **Cluster**, scegliere il cluster.

1. Nella pagina dei dettagli del cluster, nella sezione **Servizi**, selezionare il servizio.

   Si apre la pagina dei dettagli del servizio.

1. Scegliere **dimensionamento automatico del servizio**.

1. Scegliere la policy di dimensionamento predittivo, quindi scegliere **Operazioni**, **dimensionamento predittivo**, **Visualizza grafico**.

1. Nella sezione **Monitoraggio**, puoi visualizzare le previsioni passate e future della policy in termini di carico e capacità rispetto ai valori effettivi. Il grafico **Carico** mostra la previsione di carico e i valori effettivi per il parametro di carico scelto. Il grafico **Capacità** mostra il numero di attività previste dalla policy e il numero effettivo di attività avviate. La linea verticale separa i valori storici dalle previsioni future. Questi grafici diventano disponibili poco dopo la creazione della policy. 

1. (Facoltativo) Per modificare la quantità di dati cronologici mostrati nel grafico, scegli il valore desiderato dal menu a discesa **Periodo di valutazione**, nella parte superiore della pagina. Il periodo di valutazione non trasforma in alcun modo i dati di questa pagina, ma modifica soltanto la quantità di dati cronologici mostrati.

**Confronto dei dati nel grafico **Carico****  
Ogni riga orizzontale rappresenta un diverso insieme di punti dati riportati a intervalli di un'ora:

1. **Carico effettivo osservato** utilizza la statistica SUM per il parametro di carico scelto per mostrare il carico orario totale in passato.

1. **Carico previsto dalla policy** mostra la previsione del carico orario. Questa previsione si basa sulle due settimane precedenti di osservazioni del carico effettivo.

**Confronto dei dati nel grafico **Capacità****  
Ogni riga orizzontale rappresenta un diverso insieme di punti dati riportati a intervalli di un'ora:

1. **Numero effettivo osservato di attività** mostra la capacità effettiva del servizio Amazon ECS in passato, che dipende dalle altre policy di ridimensionamento e dalla dimensione minima del gruppo in vigore per il periodo di tempo selezionato.

1. **Capacità prevista dalla policy** mostra la capacità di base che si prevede di avere all'inizio di ogni ora, quando la policy è in modalità **Previsione e dimensionamento**.

1. Il **numero dedotto richiesto di attività** mostra il numero ideale di attività nel servizio per mantenere il parametro di dimensionamento al valore target scelto.

1. Il **numero minimo delle attività** indica il numero minimo di attività nel servizio.

1. La **capacità massima** indica il numero massimo di attività nel servizio.

Per calcolare la capacità richiesta differita, partiamo dal presupposto che ogni attività sia utilizzata allo stesso modo a un determinato valore target. In pratica, il numero di attività non viene utilizzato allo stesso modo. Tuttavia, ipotizzando che l'utilizzo sia distribuito uniformemente tra le attività, possiamo fare una stima verosimile della quantità di capacità necessaria. Il requisito per il numero di attività viene quindi calcolato in modo che sia inversamente proporzionale al parametro di dimensionamento utilizzato per la relativa policy. In altre parole, all'aumentare del numero di attività, il parametro di dimensionamento diminuisce alla stessa velocità. Ad esempio, se il numero delle attività raddoppia, il parametro di dimensionamento si dimezza. 

La formula per la capacità richiesta differita è:

 `sum of (actualServiceUnits*scalingMetricValue)/(targetUtilization)`

Ad esempio, prendiamo `actualServiceUnits` (`10`) e `scalingMetricValue` (`30`) per una determinata ora. Prendiamo quindi il valore `targetUtilization` specificato nella policy di dimensionamento predittivo (`60`) e calcoliamo la capacità richiesta differita per la stessa ora. Viene restituito il valore `5`. Ciò significa che cinque è la quantità di capacità richiesta necessaria per mantenere tale capacità in modo direttamente inversamente proporzionale al valore target del parametro di dimensionamento.

**Nota**  
Sono disponibili diversi fattori per regolare e migliorare i risparmi sui costi e la disponibilità dell'applicazione.  
Utilizza il dimensionamento predittivo per la capacità di base e il dimensionamento dinamico per gestire la capacità aggiuntiva. Il dimensionamento dinamico funziona indipendentemente dal dimensionamento predittivo, riducendo e aumentando orizzontalmente in base all'utilizzo corrente. Innanzitutto, Amazon ECS calcola il numero consigliato di attività per ogni policy di dimensionamento non pianificato. Quindi, effettua il dimensionamento in base alla policy che fornisce il maggior numero di attività.
Per consentire la riduzione orizzontale quando il carico diminuisce, il servizio deve sempre disporre di almeno una policy di dimensionamento predittivo con la porzione di riduzione orizzontale abilitata.
Puoi migliorare le prestazioni di dimensionamento assicurandoti che la capacità minima e massima non siano troppo restrittive. Una policy con un numero consigliato di attività che non rientra nell'intervallo di capacità minima e massima non sarà in grado di effettuare l'aumento o la riduzione orizzontale.

# Monitora i parametri di scalabilità predittiva per Amazon ECS con CloudWatch
<a name="predictive-scaling-monitoring"></a>

Puoi usare Amazon CloudWatch per monitorare i tuoi dati per la scalabilità predittiva. Una policy di dimensionamento predittivo raccoglie i dati che vengono utilizzati per prevedere il carico futuro. I dati raccolti vengono archiviati automaticamente CloudWatch a intervalli regolari e possono essere utilizzati per visualizzare le prestazioni della politica nel tempo. Puoi anche creare CloudWatch allarmi per avvisarti quando gli indicatori di performance cambiano oltre i limiti che hai definito.

## Visualizzazione dei dati di previsione storici
<a name="visualize-historical-forecast-data"></a>

I dati di previsione del carico per una politica di scalabilità predittiva possono essere visualizzati CloudWatch e possono essere utili quando si visualizzano le previsioni rispetto ad altre CloudWatch metriche in un unico grafico. Si possono anche vedere le tendenze visualizzando un intervallo di tempo più ampio. Puoi accedere ai parametri cronologici fino a 15 mesi per avere una prospettiva migliore sulle performance di una policy.

**Per visualizzare i dati di previsione storici utilizzando la console CloudWatch**

1. Apri la CloudWatch console all'indirizzo [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).

1. Nel pannello di navigazione, scegli **Metrics (Parametri)**, quindi scegli **All metrics (Tutti i parametri)**.

1. Scegliere il parametro del namespace **Dimensionamento automatico delle applicazioni**.

1. Scegliere **Previsioni del carico di dimensionamento predittivo**.

1. Nel campo di ricerca, immettere il nome della policy di dimensionamento predittivo o il nome del gruppo di servizio Amazon ECS, quindi premere Invio per filtrare i risultati. 

1. Per creare il grafico di un parametro, seleziona la casella di controllo accanto al parametro. Per modificare il nome del grafico, seleziona l'icona a forma di matita. Per modificare l'intervallo di tempo, seleziona uno dei valori predefiniti o scegli **custom** (personalizzato). Per ulteriori informazioni, consulta la sezione [Rappresentazione grafica di una metrica](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/graph_a_metric.html) nella *Amazon CloudWatch User Guide*.

1. Per modificare la statistica, seleziona la scheda **Graphed metrics** (Parametri nel grafico). Scegli l'intestazione di colonna o un valore singolo, quindi scegli un'altra statistica. Sebbene sia possibile scegliere qualsiasi statistica per ogni metrica, non tutte le statistiche sono utili per le metriche. **PredictiveScalingLoadForecast** Ad esempio, le statistiche **media**, **minimo** e **massimo** sono utili, ma la statistica **somma** non lo è.

1. Per aggiungere un altro parametro al grafico, in **Browse** (Sfoglia), scegli **All** (Tutti), trova il parametro specifico, quindi seleziona la casella di controllo accanto a esso. Puoi aggiungere fino a 10 parametri.

1. (Facoltativo) Per aggiungere il grafico a una CloudWatch dashboard, scegli **Azioni**, **Aggiungi alla** dashboard.

## Creazione di parametri di precisione utilizzando la matematica dei parametri
<a name="create-accuracy-metrics"></a>

Con la matematica metrica, puoi interrogare più CloudWatch metriche e utilizzare espressioni matematiche per creare nuove serie temporali basate su queste metriche. Puoi visualizzare le serie temporali risultanti sulla CloudWatch console e aggiungerle ai dashboard. *Per ulteriori informazioni sulla matematica dei parametri, consulta [Using metric Math nella](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/using-metric-math.html) Amazon User Guide. CloudWatch *

Utilizzando la matematica dei parametri, è possibile rappresentare graficamente i dati generati dal dimensionamento automatico del servizio per il dimensionamento predittivo in diversi modi. Questo ti aiuta a monitorare le prestazioni delle policy nel tempo e ti aiuta a capire se la tua combinazione di parametri può essere migliorata.

Ad esempio, è possibile utilizzare un'espressione matematica dei parametri per monitorare il [errore percentuale assoluto medio](https://en.wikipedia.org/wiki/Mean_absolute_percentage_error) (MAPE). Il parametro MAPE aiuta a monitorare la differenza tra i valori previsti e i valori effettivi osservati durante una determinata finestra di previsione. Le modifiche nel valore di MAPE possono indicare se le prestazioni della policy stanno peggiorando nel tempo in quanto la natura della tua applicazione cambia. Un aumento del MAPE segnala un divario più ampio tra i valori previsti e i valori effettivi. 

**Esempio: espressione matematica dei parametri**

Per iniziare a utilizzare questo tipo di grafico, puoi creare un'espressione matematica dei parametri come quella mostrata nell'esempio seguente.



Invece di un singolo parametro, è disponibile una serie di strutture di query di dati dei parametri per `MetricDataQueries`. Ogni articolo in `MetricDataQueries` ottiene un parametro o esegue un'espressione matematica. Il primo articolo, `e1`, è l'espressione matematica. L'espressione designata imposta il parametro `ReturnData` a `true`, che alla fine produce una singola serie temporale. Per tutte le altre parametri, il valore `ReturnData` è `false`. 

Nell'esempio, l'espressione designata utilizza i valori effettivi e previsti come input e restituisce la nuova metrica (MAPE). `m1`è la CloudWatch metrica che contiene i valori di carico effettivi (supponendo che l'utilizzo della CPU sia la metrica di carico originariamente specificata per la policy denominata). `my-predictive-scaling-policy` `m2`è la CloudWatch metrica che contiene i valori di carico previsti. La sintassi matematica per il parametro MAPE è la seguente:

*Media di (abs ((Effettivo - Previsto)/(Effettivo)))*

### Visualizza i parametri di precisione e imposta allarmi
<a name="visualize-accuracy-metrics-set-alarms"></a>

Per visualizzare i dati delle metriche di precisione, seleziona la scheda **Metriche** nella console. CloudWatch È possibile rappresentare graficamente i dati da lì. Per ulteriori informazioni, consulta [Aggiungere un'espressione matematica a un CloudWatch grafico](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/using-metric-math.html#adding-metrics-expression-console) nella *Amazon CloudWatch User Guide*.

Puoi anche impostare un allarme su un parametro che stai monitorando dalla sezione **Metrics** (Parametri). Nella scheda **Graphed metrics** (Parametri nel grafico), seleziona l'icona **Create alarm** (Crea allarme) nella colonna **Actions** (Operazioni). L'icona **Create alarm** (Crea allarme) è rappresentata come una piccola campana. Per ulteriori informazioni e opzioni di notifica, consulta [Creazione di un CloudWatch allarme basato su un'espressione matematica metrica](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Create-alarm-on-metric-math-expression.html) e [Notifica agli utenti delle modifiche agli allarmi](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Notify_Users_Alarm_Changes.html) nella *Amazon CloudWatch * User Guide.

In alternativa, puoi utilizzare [GetMetricData](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricData.html)ed [PutMetricAlarm](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_PutMetricAlarm.html)eseguire calcoli utilizzando la matematica metrica e creare allarmi in base all'output.

# Utilizzare azioni pianificate per sovrascrivere i valori di previsione per Amazon ECS
<a name="predictive-scaling-overriding-forecast-capacity"></a>

Talvolta, potrebbero essere disponibili ulteriori informazioni sui requisiti futuri dell'applicazione che il calcolo del forecast non è in grado di prendere in considerazione. Ad esempio, i calcoli del forecast potrebbero sottovalutare le attività necessarie per un evento di marketing imminente. È possibile utilizzare le operazioni pianificate per sostituire temporaneamente il forecast nei periodi di tempo futuri. Le operazioni pianificate possono essere eseguite su base periodica o in una data e un'ora specifiche in cui si manifestino variazioni della domanda una tantum. 

Ad esempio, è possibile creare un'operazione pianificata con un numero di attività superiore a quello previsto. In fase di runtime, Amazon ECS aggiorna il numero minimo di attività del servizio. Poiché il dimensionamento predittivo ottimizza il numero di attività, viene osservata un'azione pianificata con un numero di attività minimo superiore ai valori previsti. Ciò fa sì che il numero di attività non sia inferiore al previsto. Per interrompere l'override della previsione, utilizza una seconda operazione pianificata per riportare il numero di attività minimo all'impostazione originale.

La procedura seguente descrive le fasi per sostituire il forecast nei periodi di tempo futuri. 

**Topics**
+ [Fase 1: analizza i dati di serie temporali (opzionale)](#analyzing-time-series-data)
+ [Fase 2: creazione di due operazioni pianificate](#scheduling-capacity)

**Importante**  
Questo argomento presuppone che si stia cercando di sostituire la previsione per passare a una capacità superiore a quella prevista. Se è necessario ridurre temporaneamente il numero di attività senza interferenze dovute a una policy di dimensionamento predittivo, utilizzare invece la modalità di *sola previsione*. In modalità di sola previsione, il dimensionamento predittivo continuerà a generare previsioni, ma non aumenterà automaticamente il numero di attività. È quindi possibile monitorare l'utilizzo delle risorse e ridurre manualmente il numero di attività in base alle esigenze. 

## Fase 1: analizza i dati di serie temporali (opzionale)
<a name="analyzing-time-series-data"></a>

Inizia analizzando i dati delle serie temporali dei forecast. Si tratta di un passaggio facoltativo, ma è utile se desideri comprendere i dettagli del forecast.

1. **Recupero del forecast**

   Dopo aver creato il forecast, puoi avviare una query per un periodo di tempo specifico nel forecast. L'obiettivo della query è ottenere lo scenario completo dei dati delle serie temporali per un periodo di tempo specifico. 

   La query può includere fino a due giorni di dati di forecast futuro. Se utilizzi il dimensionamento predittivo per un certo periodo di tempo, puoi anche accedere ai dati dei forecast precedenti. Tuttavia, la durata massima tra l'ora di inizio e di fine è 30 giorni. 

   Per ottenere la previsione utilizzando il [get-predictive-scaling-forecast](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/get-predictive-scaling-forecast.html) AWS CLI comando, fornite i seguenti parametri nel comando: 
   + Inserire il nome del cluster nel parametro `resource-id`. 
   + Inserire il nome della policy nel parametro `--policy-name`. 
   + Inserisci l'ora di inizio nel parametro `--start-time` affinché restituisca solo i dati di forecast per il periodo di tempo o dopo l'intervallo di tempo specificato.
   + Inserisci l'ora di fine nel parametro `--end-time` affinché restituisca solo i dati di forecast per il periodo di tempo precedente all'intervallo di tempo specificato. 

   ```
   aws application-autoscaling get-predictive-scaling-forecast \
       --service-namespace ecs \
       --resource-id service/MyCluster/test \
       --policy-name cpu40-predictive-scaling-policy \
       --scalable-dimension ecs:service:DesiredCount \
       --start-time "2021-05-19T17:00:00Z" \
       --end-time "2021-05-19T23:00:00Z"
   ```

   Se riuscito, il comando restituirà dati simili a quelli dell'esempio seguente: 

   ```
   {
       "LoadForecast": [
           {
               "Timestamps": [
                   "2021-05-19T17:00:00+00:00",
                   "2021-05-19T18:00:00+00:00",
                   "2021-05-19T19:00:00+00:00",
                   "2021-05-19T20:00:00+00:00",
                   "2021-05-19T21:00:00+00:00",
                   "2021-05-19T22:00:00+00:00",
                   "2021-05-19T23:00:00+00:00"
               ],
               "Values": [
                   153.0655799339254,
                   128.8288551285919,
                   107.1179447150675,
                   197.3601844551528,
                   626.4039934516954,
                   596.9441277518481,
                   677.9675713779869
               ],
               "MetricSpecification": {
                   "TargetValue": 40.0,
                   "PredefinedMetricPairSpecification": {
                       "PredefinedMetricType": "ASGCPUUtilization"
                   }
               }
           }
       ],
       "CapacityForecast": {
           "Timestamps": [
               "2021-05-19T17:00:00+00:00",
               "2021-05-19T18:00:00+00:00",
               "2021-05-19T19:00:00+00:00",
               "2021-05-19T20:00:00+00:00",
               "2021-05-19T21:00:00+00:00",
               "2021-05-19T22:00:00+00:00",
               "2021-05-19T23:00:00+00:00"
           ],
           "Values": [
               2.0,
               2.0,
               2.0,
               2.0,
               4.0,
               4.0,
               4.0
           ]
       },
       "UpdateTime": "2021-05-19T01:52:50.118000+00:00"
   }
   ```

   La risposta include due forecast: `LoadForecast` e `CapacityForecast`. `LoadForecast` mostra il forecast del carico orario.`CapacityForecast` mostra i valori di forecast per la capacità necessaria su base oraria per gestire il carico previsto pur mantenendo un `TargetValue` di 40,0 (40% utilizzo medio della CPU).

1. **Identificazione del periodo di tempo di destinazione**

   Identifica l'ora o le ore in cui deve avvenire la variazione della domanda una tantum. Ricorda che le date e le ore mostrate nel forecast sono in UTC.

## Fase 2: creazione di due operazioni pianificate
<a name="scheduling-capacity"></a>

Ora crea quindi due operazioni pianificate per un periodo di tempo specifico in cui l'applicazione avrà un carico superiore a quello previsto. Ad esempio, se è previsto un evento di marketing che genererà traffico nel tuo sito per un periodo di tempo limitato, puoi pianificare un'operazione singola per aggiornare la capacità minima all'ora di inizio prevista. Quindi, pianifica un'altra operazione per riportare la capacità minima all'impostazione originale al termine dell'evento. 

1. Apri la console alla [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2).

1. Nella pagina **Cluster**, scegliere il cluster.

1. Nella pagina dei dettagli del cluster, nella sezione **Servizi**, selezionare il servizio.

   Si apre la pagina dei dettagli del servizio.

1. Scegliere **Dimensionamento automatico del servizio**.

   Si apre la pagina delle policy.

1. Scegliere **Operazioni pianificate** e poi scegliere **Crea**.

   Si apre la pagina **Crea operazione pianificata**.

1. Per **Nome operazione**, inserire un nome univoco.

1. In **Time zone (Fuso orario)**, scegli un fuso orario.

   Tutti i fusi orari elencati provengono dal database del fuso orario IANA. Per ulteriori informazioni, consultare [List of tz database time zones](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones).

1. Per **Ora di inizio**, inserire la **data** e l'**ora** di inizio dell'operazione.

1. Per **Recurrence (Ricorrenza)**, scegliere **Once (Una tantum)**.

1. In **Regolazione delle attività**, per Minimo, inserire un valore inferiore o uguale al numero massimo di attività.

1. Scegli **Crea operazione pianificata**.

   Si apre la pagina delle policy.

1. Configurare una seconda operazione programmata per ripristinare l'impostazione originale del numero di attività minimo alla fine dell'evento. Il dimensionamento predittivo può dimensionare il numero di attività solo quando il valore impostato per **Minimo** è inferiore ai valori di previsione.

**Come creare due operazioni pianificate per eventi singoli (AWS CLI)**  
Per utilizzare il AWS CLI per creare le azioni pianificate, usa il comando [put-scheduled-update-group-action](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/put-scheduled-update-group-action.html). 

Ad esempio, definiamo una pianificazione che mantenga una capacità minima di tre istanze il 19 maggio alle 17:00 per otto ore. I comandi seguenti mostrano come implementare questo scenario.

Il primo comando [put-scheduled-update-group-action](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/put-scheduled-update-group-action.html) indica ad Amazon EC2 Auto Scaling di aggiornare la capacità minima del gruppo Auto Scaling specificato alle 17:00 UTC del 19 maggio 2021. 

```
aws autoscaling put-scheduled-update-group-action --scheduled-action-name my-event-start \
  --auto-scaling-group-name my-asg --start-time "2021-05-19T17:00:00Z" --minimum-capacity 3
```

Il secondo comando indica ad Amazon EC2 Auto Scaling di impostare la capacità minima del gruppo su una alle 1:00 UTC del 20 maggio 2021. 

```
aws autoscaling put-scheduled-update-group-action --scheduled-action-name my-event-end \
  --auto-scaling-group-name my-asg --start-time "2021-05-20T01:00:00Z" --minimum-capacity 1
```

Dopo aver aggiunto queste operazioni pianificate al gruppo Auto Scaling, Amazon EC2 Auto Scaling esegue le seguenti operazioni: 
+ Alle 17:00 UTC del 19 maggio 2021, viene eseguita la prima operazione pianificata. Se il gruppo include meno di tre istanze, il gruppo si dimensiona su tre istanze. Durante questo periodo e per le otto ore successive, Amazon EC2 Auto Scaling può continuare a essere aumentato orizzontalmente, se la capacità prevista è superiore alla capacità effettiva o se è in atto una policy di dimensionamento dinamico. 
+ All' 01:00 UTC del 20 maggio 2021, viene eseguita la seconda operazione pianificata. Questo restituisce la capacità minima all'impostazione originale alla fine dell'evento.

### Dimensionamento in base a pianificazioni ricorrenti
<a name="scheduling-recurring-actions"></a>

Per sostituire il forecast per lo stesso periodo di tempo ogni settimana, crea due operazioni pianificate e fornisci la logica di data e ora utilizzando un'espressione cron. 

Il formato dell'espressione cron è costituito da cinque campi separati da spazi: [Minute] [Hour] [Day\$1of\$1Month] [Month\$1of\$1Year] [Day\$1of\$1Week]. I campi possono contenere tutti i valori consentiti, inclusi i caratteri speciali. 

Ad esempio, la seguente espressione cron campi esegue un'operazione ogni giorno alle 06:30. L'asterisco viene utilizzato come carattere jolly per abbinare tutti i valori di un campo.

```
30 6 * * 2
```

### Consulta anche
<a name="scheduling-scaling-see-also"></a>

Per ulteriori informazioni su come gestire le operazioni pianificate, consultare [Usa azioni pianificate per scalare i servizi Amazon ECS](service-autoscaling-schedulescaling.md).

# Configurazioni avanzate delle policy di dimensionamento predittivo utilizzando parametri personalizzati per Amazon ECS
<a name="predictive-scaling-custom-metrics"></a>

In una policy di dimensionamento predittivo, è possibile utilizzare parametri predefiniti o personalizzati. I parametri personalizzati sono utili quando i parametri predefiniti, ad esempio la CPU, la memoria, ecc.) non sono sufficienti per descrivere sufficientemente il carico dell'applicazione.

Quando crei una politica di scalabilità predittiva con metriche personalizzate, puoi specificare altre metriche fornite da. CloudWatch AWS In alternativa, è possibile specificare le metriche definite e pubblicate autonomamente. Puoi anche utilizzare la matematica metrica per aggregare e trasformare le metriche esistenti in una nuova serie temporale che non viene tracciata automaticamente. AWS Un esempio consiste nel combinare valori nei dati calcolando nuove somme o medie, un processo detto *aggregazione*. I dati risultanti sono chiamati *aggregato*.

La sezione seguente contiene le best practice e alcuni esempi di come costruire la struttura JSON per la policy.

## Prerequisiti
<a name="predictive-scaling-custom-metrics-prerequisites"></a>

Per aggiungere parametri personalizzati alla tua policy di dimensionamento predittivo, devi disporre delle autorizzazioni `cloudwatch:GetMetricData`.

Per specificare le tue metriche anziché le metriche AWS fornite da te, devi prima pubblicarle su. CloudWatch Per ulteriori informazioni, consulta [Pubblicazione di metriche personalizzate](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html) nella *Amazon CloudWatch User Guide*. 

Quando pubblichi i tuoi parametri, assicurati di pubblicare i punti dati con una frequenza minima di cinque minuti. I punti dati vengono recuperati in CloudWatch base alla durata del periodo necessario. Ad esempio, la specifica della metrica di carico utilizza metriche orarie per misurare il carico sull'applicazione. CloudWatch utilizza i dati metrici pubblicati per fornire un unico valore di dati per ogni periodo di un'ora aggregando tutti i punti dati con timestamp che rientrano in ogni periodo di un'ora.

## Best practice
<a name="predictive-scaling-custom-metrics-best-practices"></a>

Le seguenti best practice consentono di utilizzare i parametri personalizzati in modo più efficace:
+ Il parametro più utile per la specifica del parametro di carico è un parametro che rappresenta il carico su un gruppo Auto Scaling nel suo complesso.
+ Il parametro più utile per la specifica del parametro di dimensionamento con cui effettuare la scalabilità è il throughput medio o utilizzo medio per parametro di attività.
+ L'utilizzo di destinazione deve corrispondere al tipo di parametro di dimensionamento. Per una configurazione di policy che usa l'utilizzo della CPU, questa è ad esempio una percentuale di destinazione.
+ Se questi suggerimenti non vengono seguiti, i valori futuri previsti della serie temporale probabilmente non saranno corretti. Per verificare che i dati siano corretti, è possibile visualizzare i valori previsti nella console. In alternativa, dopo aver creato la politica di scalabilità predittiva, ispeziona gli oggetti restituiti da una chiamata all'`LoadForecast`API. [GetPredictiveScalingForecast](https://docs.aws.amazon.com/autoscaling/application/APIReference/API_GetPredictiveScalingForecast.html)
+ Ti suggeriamo vivamente di configurare il dimensionamento predittivo in modalità Solo previsione, in modo da poter valutare il Forecast prima che il dimensionamento predittivo inizi attivamente la capacità.

## Limitazioni
<a name="predicitve-scaling-custom-metrics-limitations"></a>
+ Puoi eseguire query su punti dati con un massimo di 10 parametri in un'unica specifica del parametro.
+ Ai fini di questo limite, un'espressione conta come un parametro.

## Risoluzione dei problemi di una policy di dimensionamento predittivo con parametri personalizzati
<a name="predictive-scaling-custom-metrics-troubleshooting"></a>

Se si verifica un problema durante l'utilizzo di parametri personalizzati, si consiglia di procedere come segue:
+ Se riscontri un problema in una blue/green distribuzione durante l'utilizzo di un'espressione di ricerca, assicurati di aver creato un'espressione di ricerca che cerchi una corrispondenza parziale e non una corrispondenza esatta. È anche necessario verificare che la query trovi solo i gruppi Auto Scaling che eseguono l'applicazione specifica. Per ulteriori informazioni sulla sintassi delle espressioni di ricerca, consulta la sintassi delle [espressioni di CloudWatch ricerca](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/search-expression-syntax.html) nella *Amazon CloudWatch User Guide*.
+ Il [put-scaling-policy](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/put-scaling-policy.html)comando convalida un'espressione quando crei la tua politica di scalabilità. Tuttavia, vi è la possibilità che questo comando non riesca a identificare la causa esatta degli errori rilevati. Per risolvere i problemi, risolvete gli errori che ricevete in risposta a una richiesta al comando. [get-metric-data](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/get-metric-data.html) È inoltre possibile risolvere i problemi relativi all'espressione dalla console. CloudWatch
+ Devi specificare `false` per `ReturnData` se `MetricDataQueries` specifica la funzione SEARCH() da sola senza una funzione matematica come SUM(). Questo perché le espressioni di ricerca possono restituire più serie temporali e una specifica del parametro basata su un'espressione può restituire solo una serie temporale.
+ Tutti i parametri coinvolti in un'espressione di ricerca devono avere la stessa risoluzione.

# Creazione di JSON per il dimensionamento predittivo di metriche personalizzate con Amazon ECS
<a name="predictive-scaling-custom-metrics-example"></a>

La sezione seguente contiene esempi su come configurare la scalabilità predittiva da cui interrogare i dati. CloudWatch Esistono due metodi diversi per configurare questa opzione e il metodo scelto influisce sul formato utilizzato per costruire il JSON per la policy di scalabilità predittiva. Quando si utilizza la formula per i parametri, il formato del JSON varia ulteriormente in base alla formula eseguita.

1. Per creare una policy che ottenga i dati direttamente da altre CloudWatch metriche fornite da AWS o da metriche su cui pubblichi, consulta. CloudWatch [Esempio di politica di scalabilità predittiva con metriche di carico e scalabilità personalizzate utilizzando AWS CLI](#predictive-scaling-custom-metrics-example1)

## Esempio di politica di scalabilità predittiva con metriche di carico e scalabilità personalizzate utilizzando AWS CLI
<a name="predictive-scaling-custom-metrics-example1"></a>

Per creare una politica di scalabilità predittiva con metriche di carico e scalabilità personalizzate con AWS CLI, memorizza gli argomenti per in un file JSON denominato. `--predictive-scaling-configuration` `config.json`

Inizi ad aggiungere parametri personalizzati sostituendo i valori sostituibili nell'esempio seguente con quelli dei tuoi parametri e del tuo obiettivo di destinazione.

```
{
  "MetricSpecifications": [
    {
      "TargetValue": 50,
      "CustomizedScalingMetricSpecification": {
        "MetricDataQueries": [
          {
            "Id": "scaling_metric",
            "MetricStat": {
              "Metric": {
                "MetricName": "MyUtilizationMetric",
                "Namespace": "MyNameSpace",
                "Dimensions": [
                  {
                    "Name": "MyOptionalMetricDimensionName",
                    "Value": "MyOptionalMetricDimensionValue"
                  }
                ]
              },
              "Stat": "Average"
            }
          }
        ]
      },
      "CustomizedLoadMetricSpecification": {
        "MetricDataQueries": [
          {
            "Id": "load_metric",
            "MetricStat": {
              "Metric": {
                "MetricName": "MyLoadMetric",
                "Namespace": "MyNameSpace",
                "Dimensions": [
                  {
                    "Name": "MyOptionalMetricDimensionName",
                    "Value": "MyOptionalMetricDimensionValue"
                  }
                ]
              },
              "Stat": "Sum"
            }
          }
        ]
      }
    }
  ]
}
```

Per ulteriori informazioni, consulta il riferimento [MetricDataQuery](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_MetricDataQuery.html)all'*API Amazon EC2 Auto Scaling*.

**Nota**  
Di seguito sono riportate alcune risorse aggiuntive che possono aiutarti a trovare nomi di metriche, namespace, dimensioni e statistiche per le metriche: CloudWatch   
Per informazioni sui parametri disponibili per AWS i servizi, consulta i [AWS servizi che pubblicano CloudWatch metriche](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/aws-services-cloudwatch-metrics.html) nella *Amazon CloudWatch User* Guide.
[Per ottenere il nome esatto della metrica, lo spazio dei nomi e le dimensioni (se applicabili) di una CloudWatch metrica con, consulta list-metrics. AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/list-metrics.html) 

Per creare questo criterio, esegui il [put-scaling-policy](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/put-scaling-policy.html)comando utilizzando il file JSON come input, come illustrato nell'esempio seguente.

```
aws application-autoscaling put-scaling-policy --policy-name my-predictive-scaling-policy \
  --auto-scaling-group-name my-asg --policy-type PredictiveScaling \
  --predictive-scaling-configuration file://config.json
```

In caso di esito positivo, questo comando restituisce l'Amazon Resource Name (ARN) della policy.

```
{
  "PolicyARN": "arn:aws:autoscaling:region:account-id:scalingPolicy:2f4f5048-d8a8-4d14-b13a-d1905620f345:autoScalingGroupName/my-asg:policyName/my-predictive-scaling-policy",
  "Alarms": []
}
```

# Utilizzare le espressioni matematiche del parametro
<a name="predictive-scaling-math-expression"></a>

La sezione seguente fornisce informazioni sull'utilizzo della matematica delle metriche con policy di dimensionamento predittivo nella policy. 

## Comprendere la matematica dei parametri
<a name="predictive-scaling-custom-metrics-math"></a>

Se tutto ciò che vuoi fare è aggregare i dati metrici esistenti, la matematica metrica ti consente di risparmiare lo sforzo e il costo della pubblicazione di un'altra CloudWatch metrica su. CloudWatch Puoi utilizzare qualsiasi metrica AWS fornita e puoi anche utilizzare le metriche che definisci come parte delle tue applicazioni.

Per ulteriori informazioni, consulta [Using metric Math](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/using-metric-math.html) nella *Amazon CloudWatch User Guide*. 

Se si sceglie di utilizzare un'espressione matematica dei parametri nella policy di dimensionamento predittivo, considerare i seguenti punti:
+ Le operazioni matematiche metriche utilizzano i punti dati della combinazione univoca di nome della metrica, namespace e coppie di metriche dimensionali. keys/value 
+ È possibile utilizzare qualsiasi operatore aritmetico (\$1 - \$1/^), funzione statistica (come AVG o SUM) o altra funzione che supporti. CloudWatch 
+ È possibile utilizzare i parametri e i risultati di altre espressioni matematiche nelle formule dell'espressione matematica. 
+ Le espressioni matematiche dei parametri possono essere costituite da aggregazioni diverse. Tuttavia, per il risultato finale dell'aggregazione è una best practice utilizzare `Average` per il parametro di dimensionamento e `Sum` per il parametro del carico.
+ Qualsiasi espressione utilizzata in una specifica dei parametri deve restituire una singola serie temporale.

Per utilizzare i parametri matematici, procedi come segue:
+ Scegli una o più metriche. CloudWatch Quindi, crea l'espressione. Per ulteriori informazioni, consulta [Using metric Math](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/using-metric-math.html) nella *Amazon CloudWatch User Guide*. 
+ Verifica che l'espressione matematica della metrica sia valida utilizzando la CloudWatch console o l'API. CloudWatch [GetMetricData](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricData.html)

## Esempio di policy di dimensionamento predittivo che combina parametri utilizzando la formula dei parametri (AWS CLI)
<a name="custom-metrics-ex2"></a>

A volte, invece di specificare direttamente il parametro, potrebbe essere necessario prima elaborarne i dati in qualche modo. Ad esempio, potresti avere un'applicazione che estrae il lavoro da una coda Amazon SQS e potresti utilizzare il numero di elementi nella coda come policy di dimensionamento predittivo. Il numero di messaggi nella coda non definisce esclusivamente il numero di istanze necessarie. Pertanto, è necessario più lavoro per creare un parametro che si può utilizzare per calcolare il backlog per istanza.

Di seguito viene illustrato un esempio di policy di dimensionamento predittivo per questo scenario. Specifica i parametri di dimensionamento e del carico basati sul parametro `ApproximateNumberOfMessagesVisible` di Amazon SQS, ovvero il numero di messaggi disponibili per il recupero dalla coda. Utilizza anche il parametro `GroupInServiceInstances`di Amazon EC2 Auto Scaling e un'espressione matematica per calcolare il backlog per istanza del parametro di dimensionamento.

```
aws application-autoscaling put-scaling-policy --policy-name my-sqs-custom-metrics-policy \
  --policy-type PredictiveScaling \
  --predictive-scaling-configuration file://config.json
  --service-namespace ecs \
  --resource-id service/MyCluster/test \
  "MetricSpecifications": [
    {
      "TargetValue": 100,
      "CustomizedScalingMetricSpecification": {
        "MetricDataQueries": [
          {
            "Label": "Get the queue size (the number of messages waiting to be processed)",
            "Id": "queue_size",
            "MetricStat": {
              "Metric": {
                "MetricName": "ApproximateNumberOfMessagesVisible",
                "Namespace": "AWS/SQS",
                "Dimensions": [
                  {
                    "Name": "QueueName",
                    "Value": "my-queue"
                  }
                ]
              },
              "Stat": "Sum"
            },
            "ReturnData": false
          },
          {
            "Label": "Get the group size (the number of running instances)",
            "Id": "running_capacity",
            "MetricStat": {
              "Metric": {
                "MetricName": "GroupInServiceInstances",
                "Namespace": "AWS/AutoScaling",
                "Dimensions": [
                  {
                    "Name": "AutoScalingGroupName",
                    "Value": "my-asg"
                  }
                ]
              },
              "Stat": "Sum"
            },
            "ReturnData": false
          },
          {
            "Label": "Calculate the backlog per instance",
            "Id": "scaling_metric",
            "Expression": "queue_size / running_capacity",
            "ReturnData": true
          }
        ]
      },
      "CustomizedLoadMetricSpecification": {
        "MetricDataQueries": [
          {
            "Id": "load_metric",
            "MetricStat": {
              "Metric": {
                "MetricName": "ApproximateNumberOfMessagesVisible",
                "Namespace": "AWS/SQS",
                "Dimensions": [
                  {
                    "Name": "QueueName",
                    "Value": "my-queue"
                  }
                ],
              },
              "Stat": "Sum"
            },
            "ReturnData": true
          }
        ]
      }
    }
  ]
}
```

L'esempio restituisce l'ARN della policy.

```
{
  "PolicyARN": "arn:aws:autoscaling:region:account-id:scalingPolicy:2f4f5048-d8a8-4d14-b13a-d1905620f345:autoScalingGroupName/my-asg:policyName/my-sqs-custom-metrics-policy",
  "Alarms": []
}
```

# Interconnessione dei servizi Amazon ECS
<a name="interconnecting-services"></a>

Le applicazioni eseguite nelle attività di Amazon ECS spesso devono ricevere connessioni da Internet o connettersi ad altre applicazioni eseguite nei servizi Amazon ECS. Se hai bisogno di connessioni esterne da Internet, consigliamo di utilizzare Elastic Load Balancing. Per ulteriori informazioni sul bilanciamento del carico integrato, consulta [Usa il bilanciamento del carico per distribuire il traffico del servizio Amazon ECS](service-load-balancing.md).

Se hai bisogno di un'applicazione per connetterti ad altre applicazioni eseguite nei servizi Amazon ECS, Amazon ECS offre i modi seguenti per farlo senza un sistema di bilanciamento del carico:
+ *Amazon ECS Service Connect*

  Consigliamo Service Connect, che fornisce la configurazione di Amazon ECS per il rilevamento servizi, la connettività e il monitoraggio del traffico. Con Service Connect, le tue applicazioni possono utilizzare nomi brevi e porte standard per connettersi ai servizi Amazon ECS nello stesso cluster o VPCs in altri cluster, anche all'interno dello stesso. Regione AWS

  Quando si utilizza Service Connect, Amazon ECS gestisce tutte le parti del rilevamento servizi: crea i nomi che possono essere rilevati, gestisce dinamicamente le voci per ogni attività all'inizio e all'interruzione, esegue un agente in ogni attività configurato per rilevare i nomi. L'applicazione può cercare i nomi utilizzando la funzionalità standard per i nomi DNS e stabilendo connessioni. Se l'applicazione lo fa già, non è necessario modificare l'applicazione per utilizzare Service Connect.

  Si fornisce la configurazione completa all'interno di ogni definizione di servizio e attività. Amazon ECS gestisce le modifiche a questa configurazione in ogni implementazione del servizio, per garantire che tutte le attività di un'implementazione si comportino nello stesso modo. Ad esempio, un problema comune relativo al DNS come rilevamento servizi è il controllo di una migrazione. Se si modifica un nome DNS in modo che punti ai nuovi indirizzi IP sostitutivi, potrebbe essere necessario il tempo TTL massimo prima che tutti i client inizino a utilizzare il nuovo servizio. Con Service Connect, l'implementazione del client aggiorna la configurazione sostituendo le attività del client. È possibile configurare l'interruttore automatico di implementazione e altre configurazioni di implementazione per influire sulle modifiche di Service Connect allo stesso modo di qualsiasi altra implementazione.

  Per ulteriori informazioni, consultare [Usa Service Connect per connettere i servizi Amazon ECS con nomi brevi](service-connect.md).
+ *Individuazione dei servizi di Amazon ECS*

  Un altro approccio alla service-to-service comunicazione è la comunicazione diretta tramite service discovery. In questo approccio, si può utilizzare l'integrazione del rilevamento servizi di AWS Cloud Map con Amazon ECS. Utilizzando service discovery, Amazon ECS sincronizza l'elenco delle attività avviate con AWS Cloud Map, che mantiene un nome host DNS che si risolve negli indirizzi IP interni di una o più attività di quel particolare servizio. Altri servizi nel VPC di Amazon possono utilizzare questo nome host DNS per inviare il traffico direttamente a un altro container utilizzando il suo indirizzo IP interno. 

  Questo approccio alla comunicazione offre una bassa latenza. service-to-service Non ci sono componenti aggiuntivi tra i container. Il traffico viaggia direttamente da un container all'altro.

  Questo approccio è adatto quando si utilizza la modalità di rete `awsvpc`, in cui ogni attività ha il proprio indirizzo IP univoco. La maggior parte dei software supporta solo l'uso di record `A` del DNS, che si risolvono direttamente negli indirizzi IP. Quando si utilizza la modalità di rete `awsvpc`, l'indirizzo IP per ogni attività è un record `A`. Tuttavia, se si utilizza la modalità di rete `bridge`, è possibile che più container condividano lo stesso indirizzo IP. Inoltre, le mappature dinamiche delle porte fanno sì che ai container vengano assegnati in modo casuale i numeri di porta su quel singolo indirizzo IP. A questo punto, un record `A` non è più sufficiente per il rilevamento servizi. È inoltre necessario utilizzare un record `SRV`. Questo tipo di record può tenere traccia sia degli indirizzi IP che dei numeri di porta, ma richiede la configurazione appropriata delle applicazioni. Alcune applicazioni predefinite utilizzate potrebbero non supportare i record `SRV`.

  Un altro vantaggio della modalità di rete `awsvpc` è che si dispone di un gruppo di sicurezza unico per ogni servizio. È possibile configurare questo gruppo di sicurezza per consentire le connessioni in entrata solo dai servizi upstream specifici che devono comunicare con quel servizio.

  Il principale svantaggio della service-to-service comunicazione diretta che utilizza il service discovery è che è necessario implementare una logica aggiuntiva per ripetere i tentativi e gestire gli errori di connessione. I record DNS hanno un periodo time-to-live (TTL) che controlla per quanto tempo vengono memorizzati nella cache. L'aggiornamento del record DNS e la scadenza della cache richiedono del tempo per consentire alle applicazioni di recuperare la versione più recente del record DNS. Pertanto, l'applicazione potrebbe finire per risolvere il record DNS in modo tale che punti a un altro container non più presente. L'applicazione deve gestire i nuovi tentativi e disporre di una logica per ignorare i backend non validi.

  Per ulteriori informazioni, consultare [Usare il rilevamento servizi per connettere i servizi Amazon ECS con nomi DNS](service-discovery.md)
+ *Amazon VPC Lattice*

  Amazon VPC Lattice è un servizio di rete di applicazioni gestito che i clienti di Amazon ECS utilizzano per osservare, proteggere e monitorare le applicazioni create su servizi di AWS elaborazione e account senza dover modificare il codice. VPCs

  VPC Lattice utilizza gruppi di destinazione che sono una raccolta di risorse di calcolo. Questi obiettivi eseguono l'applicazione o il servizio e possono essere istanze Amazon EC2, indirizzi IP, funzioni Lambda e Application Load Balancer. Associando i propri servizi Amazon ECS a un gruppo di destinazione di VPC Lattice, i clienti possono ora abilitare le attività Amazon ECS come destinazioni IP in VPC Lattice. Quando vengono avviate le attività per il servizio registrato, Amazon ECS le registra automaticamente nel gruppo di destinazione di VPC Lattice.

  Per ulteriori informazioni, consultare [Usa Amazon VPC Lattice per connettere, osservare e proteggere i tuoi servizi Amazon ECS](ecs-vpc-lattice.md).

## Tabella di compatibilità della modalità di rete
<a name="interconnect-network-mode-compatibility-table"></a>

La tabella seguente illustra la compatibilità tra queste opzioni e le modalità di rete delle attività. Nella tabella, "client" si riferisce all'applicazione che effettua le connessioni dall'interno di un'attività Amazon ECS.


****  

| Opzioni di interconnessione | Collegato | `awsvpc` | Host | 
| --- | --- | --- | --- | 
| Individuazione dei servizi | sì, ma richiede che i clienti conoscano i record SRV nel DNS senza hostPort. | sì | sì, ma richiede che i clienti conoscano i record SRV nel DNS senza hostPort. | 
| Service Connect  | sì | sì | no | 
| Reticolo in VPC | sì | sì | sì | 

# Usa Service Connect per connettere i servizi Amazon ECS con nomi brevi
<a name="service-connect"></a>

Amazon ECS Service Connect fornisce la gestione della service-to-service comunicazione come configurazione Amazon ECS. Crea sia il rilevamento servizi che un mesh di servizi in Amazon ECS. Ciò fornisce la configurazione completa all’interno di ogni servizio gestito in base alle implementazioni dei servizi, un modo unificato per fare riferimento ai servizi all’interno di namespace che non dipendono dalla configurazione DNS del VPC e metriche e log standardizzati per monitorare tutte le applicazioni. Service Connect interconnette solo i servizi.

Il diagramma seguente mostra un esempio di rete Service Connect con 2 sottoreti nel VPC e 2 servizi. Un servizio client che viene eseguito WordPress con 1 attività in ciascuna sottorete. Un servizio server che esegue MySQL con 1 attività in ogni sottorete. Entrambi i servizi sono altamente disponibili e resistenti ai problemi relativi alle attività e alle zone di disponibilità, poiché ogni servizio esegue più attività distribuite su 2 sottoreti. Le frecce piene mostrano una connessione da WordPress a MySQL. Ad esempio, un comando `mysql --host=mysql` CLI che viene eseguito dall'interno del WordPress contenitore nell'operazione con l'indirizzo IP. `172.31.16.1` Il comando utilizza il nome breve `mysql` sulla porta predefinita per MySQL. Questo nome e questa porta si connettono al proxy Service Connect nella stessa attività. Il proxy utilizzato nell' WordPress operazione utilizza il bilanciamento del carico a tutto tondo e tutte le informazioni relative agli errori precedenti nel rilevamento dei valori anomali per scegliere a quale task MySQL connettersi. Come mostrato dalle frecce piene nel diagramma, il proxy si connette al secondo proxy nell'attività MySQL con l'indirizzo IP `172.31.16.2`. Il secondo proxy si connette al server MySQL locale nella stessa attività. Entrambi i proxy riportano le prestazioni di connessione visibili nei grafici nelle console Amazon ECS e CloudWatch Amazon, in modo da poter ottenere i parametri delle prestazioni da tutti i tipi di applicazioni allo stesso modo.

![\[Esempio di rete Service Connect che mostra i servizi HA minimi\]](http://docs.aws.amazon.com/it_it/AmazonECS/latest/developerguide/images/serviceconnect.png)


I seguenti termini sono utilizzati insieme a Service Connect.

**nome porta**  
La configurazione della definizione di attività di Amazon ECS che assegna un nome a una particolare mappatura delle porte. Questa configurazione viene utilizzata solo da Amazon ECS Service Connect.

**alias del cliente**  
La configurazione del servizio Amazon ECS che assegna il numero di porta utilizzato nell'endpoint. Inoltre, l'alias del client può assegnare il nome DNS dell'endpoint, sovrascrivendo il nome del rilevamento. Se nel servizio Amazon ECS non viene fornito un nome di rilevamento, l'alias del client sostituisce il nome della porta come nome dell'endpoint. Per esempi di endpoint, consulta la definizione di *endpoint*. È possibile assegnare più alias client a un servizio Amazon ECS. Questa configurazione viene utilizzata solo da Amazon ECS Service Connect.

**nome del rilevamento**  
Il nome intermedio opzionale che è possibile creare per una porta specificata dalla definizione di attività. Questo nome viene utilizzato per creare un servizio. AWS Cloud Map Se questo nome non viene fornito, viene utilizzato il nome della porta indicato nella definizione di attività. È possibile assegnare più nomi di rilevamento a una porta specifica di un servizio Amazon ECS. Questa configurazione viene utilizzata solo da Amazon ECS Service Connect.  
AWS Cloud Map i nomi dei servizi devono essere univoci all'interno di un namespace. A causa di questa limitazione, è possibile avere una sola configurazione di Service Connect senza un nome di rilevamento per una particolare definizione di attività in ogni namespace.

**endpoint**  
L'URL per connettersi a un'API o a un sito Web. L'URL contiene il protocollo, un nome DNS e la porta. Per ulteriori informazioni sugli endpoint in generale, consulta la sezione [Endpoint](https://docs.aws.amazon.com/glossary/latest/reference/glos-chap.html#endpoint) nel *glossario AWS * all'interno della documentazione Riferimenti generali di Amazon Web Services.  
Service Connect crea endpoint che si connettono ai servizi Amazon ECS e configura le attività nei servizi Amazon ECS per connettersi agli endpoint. L'URL contiene il protocollo, un nome DNS e la porta. Il protocollo e il nome della porta vengono selezionati nella definizione dell'attività, poiché la porta deve corrispondere all'applicazione che si trova all'interno dell'immagine di container. Nel servizio, si seleziona ogni porta in base al nome e si può assegnare il nome DNS. Se non si specifica un nome DNS nella configurazione del servizio Amazon ECS, per impostazione predefinita viene utilizzato il nome della porta indicato nella definizione di attività. Ad esempio, un endpoint Service Connect potrebbe essere `http://blog:80`, `grpc://checkout:8080` o `http://_db.production.internal:99`.

**Servizio Service Connect**  
La configurazione di un singolo endpoint in un servizio Amazon ECS. Questa è una parte della configurazione Service Connect, costituita da una singola riga nella **configurazione di Service Connect e del nome del rilevamento** nella console o da un oggetto nell'elenco `services` nella configurazione JSON di un servizio Amazon ECS. Questa configurazione viene utilizzata solo da Amazon ECS Service Connect.  
Per ulteriori informazioni, consulta il riferimento [ServiceConnectService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ServiceConnectService.html)all'API di Amazon Elastic Container Service.

**namespace**  
Il nome breve o il nome completo Amazon Resource Name (ARN) dello spazio dei AWS Cloud Map nomi da utilizzare con Service Connect. Lo spazio dei nomi deve trovarsi nello stesso spazio del servizio Regione AWS e del cluster Amazon ECS. Il tipo di namespace in AWS Cloud Map non influisce su Service Connect. Lo spazio dei nomi può essere condiviso con Account AWS using AWS Resource Access Manager (AWS RAM) in quanto è disponibile Regioni AWS in AWS RAM . Per ulteriori informazioni sui namespace condivisi, consultare [Cross-account AWS Cloud Map namespace sharing](https://docs.aws.amazon.com/cloud-map/latest/dg/sharing-namespaces.html) nella *Guida per gli sviluppatori di AWS Cloud Map *.  
Service Connect utilizza lo spazio dei AWS Cloud Map nomi come raggruppamento logico di attività Amazon ECS che comunicano tra loro. Ogni servizio Amazon ECS può appartenere a un solo namespace. I servizi all'interno di un namespace possono essere distribuiti su diversi cluster Amazon ECS all'interno della stessa Regione AWS. Se il namespace è un namespace condiviso, i servizi possono essere distribuiti tra il proprietario del namespace e il consumer del namespace Account AWS. Puoi organizzare liberamente i servizi in base a qualsiasi criterio.

**servizi client**  
Un servizio che esegue un'applicazione client di rete. Questo servizio deve avere un namespace configurato. Ogni attività del servizio può rilevare e connettersi a tutti gli endpoint nel namespace tramite un container proxy Service Connect.  
Se uno dei container dell'attività deve connettersi a un endpoint da un servizio in un namespace, scegli un servizio client. Se un'applicazione frontend, un proxy inverso o un bilanciatore del carico riceve traffico esterno tramite altri metodi come Elastic Load Balancing, potrebbe utilizzare questo tipo di configurazione di Service Connect.

**servizio client-server**  
Un servizio Amazon ECS che esegue un'applicazione di rete o del servizio Web. Questo servizio deve avere un namespace e almeno un endpoint configurati. Ogni attività del servizio è raggiungibile utilizzando gli endpoint. Il container proxy Service Connect ascolta il nome e la porta dell'endpoint per indirizzare il traffico verso i container delle app nell'attività.  
Se uno dei container espone e ascolta il traffico di rete su una porta, scegli un servizio client-server. Queste applicazioni non devono connettersi ad altri servizi client-server nel medesimo namespace, ma la configurazione del client è necessaria. Un backend, un middleware (software intermediario), un livello aziendale o la maggior parte dei microservizi possono utilizzare questo tipo di configurazione Service Connect. Se si desidera che un'applicazione frontend, un proxy inverso o un bilanciatore del carico riceva traffico da altri servizi configurati con Service Connect nello stesso namespace, questi servizi devono utilizzare questo tipo di configurazione Service Connect.

La funzionalità Service Connect crea una rete virtuale di servizi correlati. La stessa configurazione del servizio può essere utilizzata su più spazi dei nomi diversi per eseguire set di applicazioni indipendenti ma identici. Service Connect definisce il container del proxy nel servizio Amazon ECS. In questo modo, la stessa definizione di attività può essere utilizzata per eseguire applicazioni identiche in spazi dei nomi diversi con configurazioni Service Connect diverse. Ogni attività eseguita dal servizio esegue un container del proxy nell'attività.

Service Connect è adatto per connessioni tra servizi Amazon ECS all'interno dello stesso namespace. Per le seguenti applicazioni, è necessario utilizzare un metodo di interconnessione aggiuntivo per connettersi a un servizio Amazon ECS configurato con Service Connect:
+ Attività configurate in altri namespace
+ Attività che non sono configurate per Service Connect
+ Altre applicazioni esterne ad Amazon ECS

Queste applicazioni possono connettersi tramite il proxy Service Connect, ma non possono risolvere i nomi degli endpoint Service Connect.

Affinché queste applicazioni risolvano gli indirizzi IP delle attività Amazon ECS, è necessario utilizzare un altro metodo di interconnessione. 

**Topics**
+ [Prezzi](#service-connect-pricing)
+ [Componenti di Amazon ECS Service Connect](service-connect-concepts-deploy.md)
+ [Panoramica della configurazione di Amazon ECS Service Connect](service-connect-concepts.md)
+ [Amazon ECS Service Connect con namespace condivisi AWS Cloud Map](service-connect-shared-namespaces.md)
+ [Log di accesso di Amazon ECS Service Connect](service-connect-envoy-access-logs.md)
+ [Crittografare il traffico di Amazon ECS Service Connect](service-connect-tls.md)
+ [Configurazione di Amazon ECS Service Connect con AWS CLI](create-service-connect.md)

## Prezzi
<a name="service-connect-pricing"></a>
+ I prezzi di Amazon ECS Service Connect dipendono dall'utilizzo AWS Fargate o meno dell'infrastruttura Amazon EC2 per ospitare i carichi di lavoro containerizzati. Se utilizzi Amazon ECS su AWS Outposts, i prezzi seguono lo stesso modello di quando utilizzi direttamente Amazon EC2. Per ulteriori informazioni, consultare [Prezzi di Amazon ECS](https://aws.amazon.com/ecs/pricing).
+ L'utilizzo di Amazon ECS Service Connect non comporta costi supplementari.
+ Non sono previsti costi aggiuntivi per AWS Cloud Map l'utilizzo se utilizzato da Service Connect.
+ I clienti pagano per le risorse di calcolo utilizzate da Amazon ECS Service Connect, tra cui vCPU e memoria. Poiché l'agente Amazon ECS Service Connect viene eseguito all'interno di un'attività del cliente, non sono previsti costi aggiuntivi per eseguirla. Le risorse relative alle attività sono condivise tra il carico di lavoro del cliente e l'agente Service di Amazon ECS.
+ Quando utilizzano la funzionalità di crittografia del traffico di Amazon ECS Service Connect con AWS Private CA, i clienti pagano per l'autorità di certificazione privata che creano e per ogni certificato TLS emesso. Per maggiori dettagli, consultare [Prezzi di AWS Autorità di certificazione privata](https://aws.amazon.com/private-ca/pricing/). Per stimare il costo mensile dei certificati TLS, i clienti devono conoscere il numero di servizi Amazon ECS con TLS abilitato, moltiplicarlo per il costo del certificato e quindi moltiplicarlo per sei. Poiché Amazon ECS Service Connect ruota automaticamente i certificati TLS ogni cinque giorni, vengono emessi in media sei certificati al mese per servizio Amazon ECS.

# Componenti di Amazon ECS Service Connect
<a name="service-connect-concepts-deploy"></a>

Quando si utilizza Amazon ECS Service Connect, viene configurato ogni servizio Amazon ECS per eseguire un'applicazione server che riceve richieste di rete (servizio client-server) o per eseguire un'applicazione client che effettua le richieste (servizio client).

Quando ti prepari a iniziare a usare Service Connect, inizia con un servizio client-server. È possibile aggiungere una configurazione Service Connect a un nuovo servizio o a un servizio esistente. Amazon ECS crea un endpoint di Service Connect nel namespace. Inoltre, Amazon ECS crea una nuova implementazione nel servizio per sostituire le attività attualmente in esecuzione.

Le attività esistenti e altre applicazioni potranno continuare a connettersi agli endpoint esistenti e alle applicazioni esterne. Se un servizio client-server aggiunge attività aumentando orizzontalmente, le nuove connessioni dai client verranno bilanciate tra tutte le attività. Se un servizio client-server viene aggiornato, le nuove connessioni dai client verranno bilanciate tra le attività della nuova versione.

Le attività esistenti non possono essere risolte e connettersi al nuovo endpoint. Solo le nuove attività che hanno una configurazione Service Connect nello stesso namespace e che iniziano a essere eseguite dopo questa implementazione possono essere risolte e connettersi a questo endpoint. 

Ciò significa che l'operatore dell'applicazione client determina quando la configurazione della propria app cambia, anche se l'operatore dell'applicazione server può modificare la configurazione in qualsiasi momento. L'elenco degli endpoint nel namespace può cambiare ogni volta che viene implementato un servizio nel namespace. Le attività esistenti e quelle sostitutive continuano a comportarsi allo stesso modo dopo l'implementazione più recente.

Considera i seguenti esempi:

Innanzitutto, supponi di creare un'applicazione disponibile sulla rete Internet pubblica in un unico AWS CloudFormation modello e in un unico stack. CloudFormation La scoperta pubblica e la raggiungibilità dovrebbero essere create per ultimo CloudFormation, incluso il servizio client frontend. I servizi devono essere creati in questo ordine per evitare un periodo di tempo in cui il servizio client di frontend è attivo e disponibile al pubblico, ma un backend non lo è. Ciò elimina l'invio di messaggi di errore al pubblico durante quel periodo di tempo. Nel AWS CloudFormation, devi utilizzare il `dependsOn` per indicare CloudFormation che non è possibile creare più servizi Amazon ECS in parallelo o contemporaneamente. È necessario aggiungere `dependsOn` al servizio client di frontend per ogni servizio client-server di backend a cui si connettono le attività del client.

In secondo luogo, supponiamo che esista un servizio di frontend senza la configurazione di Service Connect. Le attività si connettono a un servizio di backend esistente. Aggiungi prima una configurazione di Service Connect client-server al servizio di backend utilizzando lo stesso nome nel **DNS** o `clientAlias` utilizzato dal frontend. Questo crea una nuova distribuzione, quindi tutti i metodi di rilevamento del rollback della distribuzione AWS SDKs e altri metodi per ripristinare e ripristinare il servizio di backend alla distribuzione e alla configurazione precedenti. Console di gestione AWS AWS CLI Se sei soddisfatto delle prestazioni e del comportamento del servizio di backend, aggiungi una configurazione di Service Connect client o client-server al servizio di frontend. Solo le attività della nuova implementazione utilizzano il proxy Service Connect aggiunto a quelle nuove attività. In caso di problemi con questa configurazione, è possibile eseguire il rollback e ripristinare la configurazione precedente utilizzando il rilevamento del rollback di distribuzione o Console di gestione AWS altri metodi per ripristinare AWS SDKs e ripristinare il servizio di backend alla distribuzione e alla configurazione precedenti. AWS CLI Se si utilizza un altro sistema di individuazione dei servizi basato sul DNS anziché su Service Connect, qualsiasi applicazione frontend o client inizia a utilizzare nuovi endpoint e modifica la configurazione degli endpoint dopo la scadenza della cache DNS locale, in genere impiegando diverse ore.

## Rete
<a name="service-connect-concepts-network"></a>

Per impostazione predefinita, il proxy Service Connect è in ascolto sulla `containerPort` dalla mappatura della porta di definizione dell'attività. Le regole del gruppo di sicurezza devono consentire il traffico in entrata (in ingresso) dalle sottoreti in cui verranno eseguiti i client.

Anche se si imposta un numero di porta nella configurazione del servizio Service Connect, ciò non cambia la porta per il servizio client-server su cui è in ascolto il proxy Service Connect. Quando imposti questo numero di porta, Amazon ECS modifica la porta dell'endpoint a cui si connettono i servizi client, sul proxy Service Connect all'interno di tali attività. Il proxy nel servizio client si connette al proxy nel servizio client-server utilizzando la `containerPort`.

Se desideri modificare la porta su cui il proxy Service Connect è in ascolto, modifica `ingressPortOverride` nella configurazione di Service Connect del servizio client-server. Se viene modificato questo numero di porta, è necessario consentire il traffico in entrata su questa porta utilizzata dal traffico verso questo servizio.

Il traffico inviato dalle applicazioni ai servizi Amazon ECS configurati per Service Connect richiede che Amazon VPC e le sottoreti dispongano di regole della tabella di instradamento e di regole dell'ACL di rete che consentano i numeri di porta `containerPort` e `ingressPortOverride` che si stanno utilizzando.

 È possibile utilizzare Service Connect per inviare traffico tra VPCs. Gli stessi requisiti per le regole della tabella di routing, la rete ACLs e i gruppi di sicurezza si applicano a entrambi VPCs.

Ad esempio, due cluster creano attività diverse VPCs. Un servizio in ogni cluster è configurato per utilizzare lo stesso namespace. Le applicazioni di questi due servizi possono risolvere ogni endpoint nel namespace senza alcuna configurazione DNS del VPC. Tuttavia, i proxy non possono connettersi a meno che il peering VPC, le tabelle di routing VPC o subnet e la rete VPC non consentano il traffico sui numeri di porta e. ACLs `containerPort` `ingressPortOverride`

Per le attività che utilizzano la modalità di rete `bridge`, è necessario creare un gruppo di sicurezza con una regola in entrata che consenta il traffico sull'intervallo di porte dinamiche superiore. Quindi, assegnare il gruppo di sicurezza a tutte le istanze EC2 nel cluster Service Connect.

## Proxy Service Connect
<a name="service-connect-concepts-proxy"></a>

Se si crea o si aggiorna un servizio con la configurazione di Service Connect, Amazon ECS aggiunge un nuovo container a ogni nuova attività non appena viene avviata. Questo modello di utilizzo di un container separato è denominato `sidecar`. Questo container non è presente nella definizione dell'attività e non è possibile configurarlo. Amazon ECS gestisce la configurazione di container nel servizio. Ciò consente di riutilizzare le stesse definizioni di attività tra più servizi, namespace e attività senza Service Connect.

**Risorse proxy**
+ Per le definizioni delle attività, è necessario impostare i parametri di CPU e memoria. 

  Si consiglia di aggiungere altre 256 unità CPU e almeno 64 MiB di memoria alla CPU e alla memoria dell'attività per il container del proxy Service Connect. Su AWS Fargate, la quantità minima di memoria che è possibile impostare è 512 MiB. Su Amazon EC2, è necessaria la memoria per la definizione delle attività.
+ Per il servizio, si imposta la configurazione di log nella configurazione di Service Connect.
+ Se prevedi che le attività di questo servizio ricevano più di 500 richieste al secondo al massimo del carico, ti consigliamo di aggiungere 512 unità CPU alla CPU dell'attività in questa definizione di attività per il container del proxy Service Connect.
+ Se prevedi di creare più di 100 servizi Service Connect nel namespace o 2.000 attività in totale su tutti i servizi Amazon ECS all'interno del namespace, ti consigliamo di aggiungere 128 MiB di memoria alla memoria dell'attività per il container del proxy Service Connect. È necessario eseguire questa operazione in ogni definizione di attività utilizzata da tutti i servizi Amazon ECS nel namespace.

**Configurazione del proxy**  
Le applicazioni si connettono al proxy nel container sidecar nella stessa attività in cui si trova l'applicazione. Amazon ECS configura l'attività e i container in modo che le applicazioni si connettano al proxy solo quando l'applicazione è connessa ai nomi degli endpoint nello stesso namespace. Tutto il resto del traffico non utilizza il proxy. L'altro traffico include indirizzi IP nello stesso VPC, endpoint di AWS servizio e traffico esterno.

**Sistema di bilanciamento del carico**  
Service Connect configura il proxy per utilizzare la strategia round-robin per il bilanciamento del carico tra le attività in un endpoint Service Connect. Il proxy locale, che si trova nell'attività da cui proviene la connessione, seleziona una delle attività del servizio client-server che fornisce l'endpoint.  
*Ad esempio, si consideri un'attività eseguita WordPress in un servizio configurato come *servizio client* in uno spazio dei nomi chiamato locale.* È presente un altro servizio con 2 attività che eseguono il database MySQL. Questo servizio è configurato per fornire un endpoint denominato `mysql` tramite Service Connect nello stesso namespace. Nell' WordPress operazione, l' WordPress applicazione si connette al database utilizzando il nome dell'endpoint. Le connessioni con questo nome vengono instradate al proxy in esecuzione in un container sidecar per la stessa attività. Quindi, il proxy può connettersi a una delle attività MySQL utilizzando la strategia round-robin.  
Strategie di bilanciamento del carico: round-robin

**Rilevamento di anomalie**  
Questa funzionalità utilizza i dati acquisiti dal proxy sulle connessioni non riuscite precedenti per evitare l'invio di nuove connessioni agli host che le contenevano. Service Connect configura la funzionalità di rilevamento delle anomalie del proxy per fornire controlli dell'integrità passivi.  
Usando l'esempio precedente, il proxy può connettersi a una delle due attività MySQL. Se il proxy ha effettuato più connessioni a un'attività MySQL specifica e negli ultimi 30 secondi 5 di queste, o un numero maggiore, non sono andate a buon fine, il proxy evita di eseguire tale attività MySQL per un periodo compreso tra 30 e 300 secondi.

**Tentativi**  
Service Connect configura il proxy in modo da tentare nuovamente le connessioni che passano attraverso il proxy e falliscono. Il secondo tentativo evita di utilizzare l'host delle connessioni precedenti. In questo modo si garantisce che ogni connessione attraverso Service Connect non si interrompa per motivi isolati.  
Numero di tentativi: 2

**Timeout**  
Service Connect configura il proxy in modo che attenda un tempo massimo per la risposta delle applicazioni client-server. Il valore di timeout predefinito è 15 secondi, ma può essere aggiornato.  
Parametri facoltativi:  
**idleTimeout**: la quantità di tempo in secondi in cui una connessione rimane attiva mentre è inattiva. Un valore di `0` disabilita il `idleTimeout`  
Il valore predefinito `idleTimeout` per `HTTP`/`HTTP2`/`GRPC` è 5 minuti.  
Il valore predefinito `idleTimeout` per `TCP` è 1 ora.  
**perRequestTimeout**‐ Il periodo di attesa che l'upstream risponda con una risposta completa per richiesta. Un valore di `0` si spegne in `perRequestTimeout`. Questo può essere impostato solo quando il `appProtocol` per il container dell'applicazione è `HTTP`/`HTTP2`/`GRPC`. L'impostazione predefinita è 15 secondi.  
Se `idleTimeout` è impostato su un valore inferiore a `perRequestTimeout`, la connessione si chiuderà quando viene raggiunto il `idleTimeout`, non il `perRequestTimeout`.

## Considerazioni
<a name="service-connect-considerations"></a>

Quando si utilizza Service Connect, si consideri quanto segue:
+ Per utilizzare Service Connect, le attività eseguite in Fargate devono utilizzare la piattaforma Fargate Linux versione `1.4.0` o successiva.
+ La versione dell'agente Amazon ECS sull'istanza di container deve essere `1.67.2` o successiva.
+ Per utilizzare Service Connect, le istanze di container devono eseguire la versione `20230428` dell'AMI di Amazon Linux 2023 ottimizzata per Amazon ECS, o versioni successive, o la versione `2.0.20221115` dell'AMI di Amazon Linux 2 ottimizzata per Amazon ECS. Oltre all'agente del container Amazon ECS, queste versioni contengono l'agente Service Connect. Per ulteriori informazioni sull'agente Service Connect, consulta [Amazon ECS Service Connect Agent](https://github.com/aws/amazon-ecs-service-connect-agent) on GitHub.
+ Le istanze di container devono disporre dell'autorizzazione `ecs:Poll` per la risorsa `arn:aws:ecs:region:0123456789012:task-set/cluster/*`. Se utilizzi il `ecsInstanceRole`, non è necessario aggiungere altre autorizzazioni. La policy gestita da `AmazonEC2ContainerServiceforEC2Role` dispone delle autorizzazioni necessarie. Per ulteriori informazioni, consultare [Ruolo IAM delle istanze di container Amazon ECS](instance_IAM_role.md).
+ Le attività che utilizzano la modalità di rete `bridge` e utilizzano Service Connect non supportano il parametro di definizione del container `hostname`.
+ Per utilizzare Service Connect, le definizioni di attività devono impostare il limite di memoria dell'attività. Per ulteriori informazioni, consultare [Proxy Service Connect](#service-connect-concepts-proxy).
+ Le definizioni delle attività che impostano i limiti di memoria del container non sono supportate.

  È possibile impostare i limiti di memoria del container sui container, ma è necessario impostare il limite di memoria delle attività su un numero maggiore della somma dei limiti di memoria del container. La CPU e la memoria aggiuntive nei limiti delle attività che non vengono allocate nei limiti del container negli altri contenitori vengono utilizzate dal container del proxy Service Connect e da altri container che non impostano limiti di container. Per ulteriori informazioni, consulta [Proxy Service Connect](#service-connect-concepts-proxy).
+ È possibile configurare Service Connect per utilizzare qualsiasi spazio dei AWS Cloud Map nomi nella stessa regione che si trova nella stessa area Account AWS o è condiviso con l'utente Account AWS . AWS Resource Access Manager Per ulteriori informazioni sull'uso dei namespace condivisi, consultare [Amazon ECS Service Connect con namespace condivisi AWS Cloud Map](service-connect-shared-namespaces.md).
+ Ogni servizio può appartenere a un solo namespace.
+ Sono supportate solo le attività create dai servizi. 
+ Tutti gli endpoint devono essere univoci all'interno di un namespace.
+ Tutti i nomi di rilevamento devono essere univoci all'interno di un namespace.
+ È necessario implementare nuovamente i servizi esistenti prima che le applicazioni possano risolvere nuovi endpoint. I nuovi endpoint aggiunti al namespace dopo l'implementazione più recente non verranno aggiunti alla configurazione dell'attività. Per ulteriori informazioni, consultare [Componenti di Amazon ECS Service Connect](#service-connect-concepts-deploy).
+ Service Connect non elimina i namespace quando vengono eliminati i cluster. È necessario eliminare i namespace in. AWS Cloud Map
+ Per impostazione predefinita, il traffico di Application Load Balancer viene instradato tramite l'agente Service Connect in modalità nella modalità di rete `awsvpc`. Se si desidera che il traffico non di servizio aggiri l'agente Service Connect, utilizzare il parametro `[ingressPortOverride](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ServiceConnectService.html)` nella configurazione del servizio Service Connect.
+ Service Connect con TLS non supporta la modalità di rete `bridge`. Solo la modalità di rete `awsvpc` è supportata.
+ In `awsvpc` modalità, il proxy Service Connect inoltra il traffico all' IPv4 host locale `127.0.0.1` per i servizi nelle configurazioni IPv4 -only e dualstack. Per i servizi in configurazione IPv6 -only, il proxy inoltra il traffico al localhost. IPv6 `::1` Ti consigliamo di configurare le applicazioni per ascoltare entrambi gli host locali per un'esperienza senza interruzioni quando un servizio viene aggiornato dalla configurazione -only o dualstack a IPv4 -only. IPv6 Per ulteriori informazioni, consultare [Opzioni di rete di attività di Amazon ECS per EC2](task-networking.md) e [Opzioni di rete di attività di Amazon ECS per Fargate](fargate-task-networking.md).

**Service Connect non supporta quanto segue:**
+ Container Windows
+ HTTP 1.0
+ Attività autonome
+ Servizi che utilizzano i tipi di distribuzione powered by ed esterni blue/green CodeDeploy 
+ Le istanze di container `External` per Amazon ECS Anywhere non sono supportate con Service Connect.
+ PPv2
+ modalità FIPS

# Panoramica della configurazione di Amazon ECS Service Connect
<a name="service-connect-concepts"></a>

Quando si utilizza Service Connect, è necessario configurare alcuni parametri nelle risorse. 

Nella tabella seguente vengono descritti i parametri di configurazione per le risorse di Amazon ECS.


| Posizione dei parametri | Tipo di app | Description | Richiesto | 
| --- | --- | --- | --- | 
| Definizione di attività | Client | Non sono disponibili modifiche per Service Connect nelle definizioni delle attività del client. | N/D | 
| Definizione di attività | Client-server | I server devono aggiungere i campi name alle porte nelle portMappings dei container. Per ulteriori informazioni, consultare [portMappings](task_definition_parameters.md#ContainerDefinition-portMappings) | Sì | 
| Definizione di attività | Client-server | I server possono opzionalmente fornire un protocollo applicativo (ad esempio, HTTP) per ricevere parametri specifici del protocollo per le loro applicazioni server (ad esempio, HTTP 5xx). | No | 
| Definizioni di servizi | Client | I servizi client devono aggiungere una serviceConnectConfiguration per configurare il namespace a cui aderire. Questo namespace deve contenere tutti i servizi del server che questo servizio deve individuare. Per ulteriori informazioni, consultare [serviceConnectConfiguration](service_definition_parameters.md#Service-serviceConnectConfiguration). | Sì | 
| Definizione di servizio | Client-server | I servizi server devono aggiungere una serviceConnectConfiguration per configurare i nomi DNS, i numeri di porta e il namespace da cui è disponibile il servizio. Per ulteriori informazioni, consultare [serviceConnectConfiguration](service_definition_parameters.md#Service-serviceConnectConfiguration). | Sì | 
| Cluster | Client | I cluster possono aggiungere un namespace Service Connect predefinito. Quando Service Connect è configurato in un servizio, i nuovi servizi nel cluster ereditano il namespace.  | No | 
| Cluster | Client-server | Non sono disponibili modifiche per Service Connect nei cluster che si applicano ai servizi server. Le definizioni e i servizi delle attività del server devono impostare la rispettiva configurazione. | N/D | 

**Panoramica della procedura per configurare Service Connect**  
Nella procedura seguente viene illustrato come configurare Service Connect.

**Importante**  
 Service Connect crea AWS Cloud Map servizi nel tuo account. La modifica manuale di queste AWS Cloud Map risorse mediante registering/deregistering istanze, la modifica degli attributi dell'istanza o l'eliminazione di un servizio può comportare un comportamento imprevisto del traffico dell'applicazione o delle successive implementazioni.
 Service Connect non supporta i link nella definizione dell'attività.

1. Aggiungi i nomi delle porte alle mappature delle porte nelle definizioni di attività. Per ottenere parametri aggiuntivi, puoi inoltre identificare il protocollo di livello 7 dell'applicazione.

1. Crea un cluster con uno AWS Cloud Map spazio dei nomi, usa uno spazio dei nomi condiviso o crea lo spazio dei nomi separatamente. Per un'organizzazione semplice, crea un cluster con il nome desiderato per il namespace e specifica lo stesso nome per il namespace. In questo caso, Amazon ECS crea un nuovo namespace HTTP con la configurazione necessaria. Service Connect non utilizza né crea zone ospitate DNS in Amazon Route 53.

1. Configurare i servizi per creare endpoint Service Connect all'interno del namespace.

1. Implementa i servizi per creare gli endpoint. Amazon ECS aggiunge un container del proxy Service Connect a ogni attività e crea gli endpoint Service Connect in AWS Cloud Map. Questo container non è configurato nella definizione dell'attività e la definizione dell'attività può essere riutilizzata senza modifiche per creare più servizi nello stesso namespace o in più spazi dei nomi.

1. Implementa le app client come servizi per connetterti agli endpoint. Amazon ECS li connette agli endpoint Service Connect tramite il proxy Service Connect in ogni attività.

   Le applicazioni utilizzano il proxy solo per connettersi agli endpoint Service Connect. Non è disponibile alcuna configurazione aggiuntiva per l'utilizzo del proxy. Il proxy esegue il bilanciamento del carico round-robin, il rilevamento di anomalie ed effettua un nuovo tentativo. Per ulteriori informazioni sul proxy, consulta [Proxy Service Connect](service-connect-concepts-deploy.md#service-connect-concepts-proxy).

1. Monitora il traffico tramite il proxy Service Connect in Amazon CloudWatch.

## Configurazione del cluster
<a name="service-connect-concepts-cluster-defaults"></a>

È possibile impostare un namespace predefinito per Service Connect al momento della creazione o dell'aggiornamento del cluster. Il nome dello spazio dei nomi specificato come predefinito può trovarsi nello stesso account oppure nello stesso Regione AWS Regione AWS e condiviso da un altro Account AWS utente. AWS Resource Access Manager

Se si crea un cluster e si specifica un namespace Service Connect predefinito, il cluster attende lo stato `PROVISIONING` mentre Amazon ECS crea il namespace. È possibile vedere un `attachment` nello stato del cluster che mostra lo stato del namespace. Per impostazione predefinita, gli allegati non vengono visualizzati in. È necessario aggiungerli `--include ATTACHMENTS` per visualizzarli. AWS CLI

Se desideri utilizzare uno spazio dei nomi condiviso con i tuoi utenti AWS RAM, specifica Account AWS l'Amazon Resource Name (ARN) dello spazio dei nomi nella configurazione del cluster. Per ulteriori informazioni sugli spazi dei nomi condivisi, consulta. AWS Cloud Map [Amazon ECS Service Connect con namespace condivisi AWS Cloud Map](service-connect-shared-namespaces.md)

## Configurazione del servizio
<a name="service-connect-concepts-config"></a>

Service Connect è progettato per richiedere la configurazione minima. È necessario impostare un nome per ogni mappatura delle porte che si desidera utilizzare con Service Connect nella definizione di attività. Nel servizio, devi attivare Service Connect e selezionare uno spazio dei nomi nel tuo Account AWS o uno spazio dei nomi condiviso per creare un servizio client. Per creare un servizio client-server, è necessario aggiungere una singola configurazione del servizio Service Connect che corrisponda al nome di una delle mappature delle porte. Amazon ECS riutilizza il numero di porta e il nome della porta dalla definizione dell'attività per definire il servizio e l'endpoint Service Connect. Per sovrascrivere questi valori, puoi utilizzare gli altri parametri **Discovery**, **DNS** e **Port** nella console o `discoveryName` e `clientAliases`, rispettivamente, nell'API Amazon ECS.

## Configurazione iniziale di Health Check
<a name="service-connect-concepts-health-check"></a>

Service Connect garantisce l'integrità delle attività prima di indirizzare il traffico verso di esse. All'avvio di un'attività (durante le distribuzioni, il ridimensionamento o le sostituzioni), Service Connect monitora lo stato dell'attività per garantire che sia pronta ad accettare il traffico. È necessario definire i controlli di integrità per il contenitore essenziale nella definizione dell'attività per abilitare questo comportamento.

Il comportamento del controllo sanitario iniziale tiene conto dei potenziali ritardi nel raggiungere lo stato in cui un'attività è pronta ad accettare traffico:
+ Se un'attività lo è`HEALTHY`, è immediatamente disponibile per il traffico.
+ Se lo stato di salute di un'attività è lo stesso`UNKNOWN`, Service Connect segue la configurazione del controllo dello stato del contenitore (vedi[Controllo dell’integrità](task_definition_parameters.md#container_definition_healthcheck)) dei contenitori essenziali dell'attività per calcolare un timeout, fino a`8 minutes`, prima di renderlo disponibile al traffico, anche se rimane`UNKNOWN`.
+ Se un'attività lo è`UNHEALTHY`, Amazon ECS può avviare attività sostitutive. Se non sono disponibili attività funzionanti, è possibile che la distribuzione venga ripristinata in base alla configurazione del servizio.

Per tutto il traffico in corso, Service Connect utilizza controlli di integrità passivi basati sul rilevamento dei valori anomali per indirizzare il traffico in modo efficiente.

# Amazon ECS Service Connect con namespace condivisi AWS Cloud Map
<a name="service-connect-shared-namespaces"></a>

Amazon ECS Service Connect supporta l'uso di AWS Cloud Map namespace condivisi tra più Account AWS nomi all'interno dello stesso. Regione AWS Questa funzionalità consente di creare applicazioni distribuite in cui servizi eseguiti in aree diverse Account AWS possono rilevarsi e comunicare tra loro tramite Service Connect. I namespace condivisi vengono gestiti utilizzando AWS Resource Access Manager (AWS RAM), che consente la condivisione sicura delle risorse tra account. *Per ulteriori informazioni sugli spazi dei nomi condivisi, consulta Condivisione [AWS Cloud Map dello spazio dei nomi tra account nella Guida per gli sviluppatori](https://docs.aws.amazon.com/cloud-map/latest/dg/sharing-namespaces.html).AWS Cloud Map *

**Importante**  
È necessario utilizzare l'autorizzazione gestita da `AWSRAMPermissionCloudMapECSFullPermission` per condividere il namespace affinché Service Connect funzioni correttamente con il namespace.

Quando si utilizzano AWS Cloud Map namespace condivisi con Service Connect, i servizi di più nomi Account AWS possono partecipare allo stesso spazio dei nomi di servizio. Ciò è particolarmente utile per le organizzazioni con più account Account AWS che devono mantenere la service-to-service comunicazione oltre i confini degli account preservando al contempo la sicurezza e l'isolamento.

**Nota**  
Per comunicare con servizi diversi VPCs, è necessario configurare la connettività inter-VPC. Ciò si può fare utilizzando una connessione peering VPC. Per ulteriori informazioni, consultare [Create or delete a VPC Peering connection](https://docs.aws.amazon.com/vpc/latest/peering/create-vpc-peering-connection.html) nella *Guida al peering VPC di Amazon Virtual Private Cloud*.

# Utilizzo di AWS Cloud Map namespace condivisi con Amazon ECS Service Connect
<a name="service-connect-shared-namespaces-setup"></a>

La configurazione di AWS Cloud Map namespace condivisi per Service Connect prevede i seguenti passaggi: il proprietario del namespace crea lo spazio dei nomi, il proprietario lo condivide tramite AWS Resource Access Manager (AWS RAM), il consumatore accetta la condivisione delle risorse e il consumatore configura Service Connect per l'utilizzo dello spazio dei nomi condiviso.

## AWS Cloud Map Passaggio 1: creare lo spazio dei nomi
<a name="service-connect-shared-namespaces-create"></a>

Il proprietario dello spazio dei nomi crea uno spazio AWS Cloud Map dei nomi che verrà condiviso con altri account.

**Per creare uno spazio dei nomi per la condivisione utilizzando il Console di gestione AWS**

1. Apri la AWS Cloud Map console all'indirizzo. [https://console.aws.amazon.com/cloudmap/](https://console.aws.amazon.com/cloudmap/)

1. Selezionare **Crea namespace**.

1. Inserire un **Nome del namespace**. Questo nome verrà utilizzato dai servizi in tutti gli account partecipanti.

1. Per **Tipo di namespace**, scegliere il tipo appropriato per il caso d'uso:
   + **Chiamate API**: namespace HTTP per il rilevamento servizi senza funzionalità DNS.
   + **Chiamate API e query DNS in VPCs** ‐ Namespace DNS privati per l'individuazione di servizi con query DNS private in un VPC.
   + **Chiamate API e query DNS pubbliche**: namespace DNS pubblici per il rilevamento servizi con query DNS pubbliche.

1.  Selezionare **Crea namespace**.

## Passaggio 2: condividi lo spazio dei nomi utilizzando AWS RAM
<a name="service-connect-shared-namespaces-share"></a>

Il proprietario dello spazio dei nomi utilizza AWS RAM per condividere lo spazio dei nomi con altri. Account AWS

**Per condividere uno spazio dei nomi utilizzando la console AWS RAM**

1. Apri la AWS RAM console all'indirizzo. [https://console.aws.amazon.com/ram/](https://console.aws.amazon.com/ram/)

1. Seleziona **Crea condivisione risorse**.

1. Per **Nome**, inserire un nome descrittivo della risorsa da condividere.

1. Nella sezione **Risorse**:

   1. Per **Tipo di risorsa**, scegliere **Namespace della mappa cloud**.

   1. Selezionare il namespace creato nella fase precedente.

1. Nella sezione **Autorizzazioni gestite**, specifica **AWSRAMPermissionCloudMapECSFullAutorizzazione**.
**Importante**  
È necessario utilizzare l'autorizzazione gestita da `AWSRAMPermissionCloudMapECSFullPermission` per condividere il namespace affinché Service Connect funzioni correttamente con il namespace.

1. Nella sezione **Principali**, specificare gli Account AWS con cui condividere il namespace. Puoi inserire l'account IDs o l'unità IDs organizzativa.

1. Seleziona **Crea condivisione risorse**.

## Fase 3: Accettare la condivisione delle risorse
<a name="service-connect-shared-namespaces-accept"></a>

Gli account consumer del namespace devono accettare l'invito alla condivisione delle risorse per utilizzare il namespace condiviso.

**Per accettare un invito alla condivisione di risorse utilizzando la AWS RAM console**

1. Nell'account consumer, apri la AWS RAM console all'indirizzo [https://console.aws.amazon.com/ram/](https://console.aws.amazon.com/ram/).

1. Nel riquadro di navigazione, scegliere **Condivise con me**, poi scegliere **Condivisioni di risorse**.

1. Selezionare l'invito alla condivisione delle risorse e scegliere **Accetta la condivisione delle risorse**.

1. Dopo aver accettato, annotare l'ARN del namespace condiviso dai dettagli della risorsa. Si utilizzerà questo ARN per configurare i servizi Service Connect.

## Fase 4: Configurare un servizio Amazon ECS con il namespace condiviso
<a name="service-connect-shared-namespaces-configure"></a>

Dopo aver accettato il namespace condiviso, il consumer del namespace può configurare i servizi Amazon ECS per utilizzare il namespace condiviso. La configurazione è simile all'utilizzo di un namespace normale, ma è necessario specificare l'ARN del namespace anziché il nome. Per una procedura dettagliata di creazione del servizio, consultare [Creazione di un'implementazione di aggiornamenti continui di Amazon ECS](create-service-console-v2.md).

**Per creare un servizio con uno spazio dei nomi condiviso utilizzando il Console di gestione AWS**

1. [Aprire la console nella versione 2. https://console.aws.amazon.com/ecs/](https://console.aws.amazon.com/ecs/v2)

1. Sulla pagina **Cluster**, scegliere il cluster in cui creare il servizio.

1. In **Servizi**, scegliere **Crea**.

1. Dopo aver inserito altri dettagli a seconda del carico di lavoro, nella sezione **Service Connect**, scegliere **Usa Service Connect**.

1. Per **Namespace**, inserire l'ARN completo del namespace condiviso.

   Il formato ARN è: `arn:aws:servicediscovery:region:account-id:namespace/namespace-id`

1. Configurare le impostazioni rimanenti di Service Connect in base alle esigenze per il tipo di servizio (client o client-server).

1. Completare il processo di creazione del servizio.

È inoltre possibile configurare i servizi utilizzando AWS CLI o AWS SDKs specificando lo spazio dei nomi condiviso ARN nel `namespace` parametro di. `serviceConnectConfiguration`

```
aws ecs create-service \
    --cluster my-cluster \
    --service-name my-service \
    --task-definition my-task-def \
    --service-connect-configuration '{
        "enabled": true,
        "namespace": "arn:aws:servicediscovery:us-west-2:123456789012:namespace/ns-abcdef1234567890",
        "services": [{
            "portName": "web",
            "discoveryName": "my-service",
            "clientAliases": [{
                "port": 80,
                "dnsName": "my-service"
            }]
        }]
    }'
```

## Considerazioni
<a name="service-connect-shared-namespaces-considerations"></a>

Considerate quanto segue quando utilizzate AWS Cloud Map namespace condivisi con Service Connect:
+ AWS RAM deve essere disponibile nel luogo in Regione AWS cui desideri utilizzare lo spazio dei nomi condiviso.
+ Lo spazio dei nomi condiviso deve trovarsi nello stesso dei servizi Regione AWS e dei cluster Amazon ECS.
+ È necessario utilizzare l'ARN del namespace, non l'ID, quando si configura Service Connect con un namespace condiviso.
+ Sono supportati tutti i tipi di namespace: HTTP, DNS privato e namespace DNS pubblico.
+ Se l'accesso a un namespace condiviso viene revocato, le operazioni di Amazon ECS che richiedono l'interazione con lo il namespace (come `CreateService`, `UpdateService` e `ListServicesByNamespace`) avranno esito negativo. Per ulteriori informazioni sulle autorizzazioni per la risoluzione dei problemi relativi ai namespace condivisi, consultare [Risoluzione dei problemi di Amazon ECS Service Connect con namespace condivisi AWS Cloud Map](service-connect-shared-namespaces-troubleshooting.md).
+ Per il rilevamento servizi tramite query DNS in un namespace DNS privato condiviso:
  + Il proprietario del namespace dovrà chiamare `create-vpc-association-authorization` con l'ID della zona ospitata privata associata al namespace e il VPC del consumer.

    ```
    aws route53 create-vpc-association-authorization --hosted-zone-id Z1234567890ABC --vpc VPCRegion=us-east-1,VPCId=vpc-12345678
    ```
  + Il consumer del namespace dovrà chiamare `associate-vpc-with-hosted-zone` con l'ID della zona ospitata privata.

    ```
    aws route53 associate-vpc-with-hosted-zone --hosted-zone-id Z1234567890ABC --vpc VPCRegion=us-east-1,VPCId=vpc-12345678
    ```
+ Solo il proprietario del namespace può gestire la condivisione delle risorse.
+ I consumer del namespace possono creare e gestire servizi all'interno del namespace condiviso ma non possono modificare il namespace stesso.
+ I nomi Discovery devono essere univoci all'interno del namespace condiviso, indipendentemente dall'account che crea il servizio.
+ I servizi nello spazio dei nomi condiviso possono scoprire e connettersi ai servizi di altri AWS account che hanno accesso allo spazio dei nomi.
+ Quando si abilita TLS per Service Connect e si utilizza un namespace condiviso, l'Autorità di certificazione (CA) AWS Private CA ha l'ambito del namespace. Quando l'accesso al namespace condiviso viene revocato, l'accesso alla CA viene interrotto.
+ Quando si lavora con uno spazio dei nomi condiviso, i proprietari e i consumatori di namespace non hanno accesso ai parametri Amazon tra account diversi per impostazione predefinita. CloudWatch Le metriche di Target vengono pubblicate solo per gli account che possiedono servizi client. Un account proprietario di servizi client non ha accesso alle metriche ricevute da un account che possiede servizi client-server e viceversa. Per consentire l'accesso alle metriche da più account, configura l'osservabilità tra account. CloudWatch *Per ulteriori informazioni sulla configurazione dell'osservabilità tra account, consulta l'osservabilità [CloudWatch tra account nella Amazon User Guide](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Unified-Cross-Account.html). CloudWatch * Per ulteriori informazioni sulle CloudWatch metriche per Service Connect, vedere[Metriche di Amazon ECS CloudWatch](available-metrics.md).

# Risoluzione dei problemi di Amazon ECS Service Connect con namespace condivisi AWS Cloud Map
<a name="service-connect-shared-namespaces-troubleshooting"></a>

Utilizza le seguenti informazioni per risolvere i problemi relativi ai AWS Cloud Map namespace condivisi e Service Connect. Per ulteriori informazioni sull'individuazione dei messaggi di errore, consultare [Risoluzione dei problemi di Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/troubleshooting.html).

I messaggi di errore relativi ai problemi di autorizzazione vengono visualizzati a causa di autorizzazioni mancanti o se l'accesso al namespace viene revocato. 

**Importante**  
È necessario utilizzare l'autorizzazione gestita da `AWSRAMPermissionCloudMapECSFullPermission` per condividere il namespace affinché Service Connect funzioni correttamente con il namespace.

Il messaggio di errore appare in uno dei seguenti formati:

Si è verificato un errore (ClientException) durante la chiamata all'operazione < OperationName >: User: arn:aws:iam: :user/ non è autorizzato a eseguire: < > ActionName on resource: < > perché nessuna politica basata sulle risorse consente l'azione < > ResourceArn ActionName <account-id><user-name>

I seguenti scenari possono generare un messaggio di errore in questo formato:

**Errore di creazione o aggiornamento del cluster**  
Questi problemi si verificano quando le operazioni di Amazon ECS `UpdateCluster` non funzionano `CreateCluster` o falliscono a causa di AWS Cloud Map autorizzazioni mancanti. Le operazioni richiedono le autorizzazioni per le seguenti azioni: AWS Cloud Map   
+ `servicediscovery:GetNamespace`
Assicurarsi che l'invito alla condivisione delle risorse sia stato accettato nell'account consumer e che nella configurazione di Service Connect venga utilizzato l'ARN del namespace corretto.

**Errore di creazione o aggiornamento del servizio**  
Questi problemi si verificano quando le operazioni di Amazon ECS `UpdateService` non funzionano `CreateService` o falliscono a causa di AWS Cloud Map autorizzazioni mancanti. Le operazioni richiedono le autorizzazioni per le seguenti azioni: AWS Cloud Map   
+ `servicediscovery:CreateService`
+ `servicediscovery:GetNamespace`
+ `servicediscovery:GetOperation` (per creare un nuovo servizio AWS Cloud Map )
+ `servicediscovery:GetService` (per quando un servizio AWS Cloud Map esiste già)
Assicurarsi che l'invito alla condivisione delle risorse sia stato accettato nell'account consumer e che nella configurazione di Service Connect venga utilizzato l'ARN del namespace corretto.

**L'operazione `ListServicesByNamespace` ha esito negativo**  
Questo problema si verifica quando l'operazione `ListServicesByNamespace` di Amazon ECS ha esito negativo. Questa operazione richiede autorizzazioni per le seguenti azioni AWS Cloud Map :  
+ `servicediscovery:GetNamespace`
Per risolvere il problema:  
+ Verificare che l'account consumer disponga dell'autorizzazione `servicediscovery:GetNamespace`.
+ Usare l'ARN del namespace quando si chiama l'API, non il nome.
+ Assicurarsi che la condivisione delle risorse sia attiva e che l'invito sia stato accettato.

Utente: non è autorizzato a eseguire: < ActionName > sulla risorsa: < ResourceArn > con un rifiuto esplicito in una politica basata sull'identità. <iam-user>

I seguenti scenari possono generare un messaggio di errore in questo formato:

**L'eliminazione del servizio ha esito negativo e rimane bloccata nello stato `DRAINING`**  
Questo problema si verifica quando le operazioni `DeleteService` di Amazon ECS hanno esito negativo a causa dell'autorizzazione `servicediscovery:DeleteService` mancante quando l'accesso al namespace viene revocato. Inizialmente potrebbe sembrare che il servizio sia stato eliminato correttamente, ma rimarrà bloccato nello stato `DRAINING`. Il messaggio di errore viene visualizzato come un evento del servizio di Amazon ECS.  
Per risolvere questo problema, il proprietario del namespace deve condividere quest'ultimo con l'account consumer per consentire il completamento dell'eliminazione del servizio.

**Le attività in servizio non vengono eseguite**  
Questo problema si verifica quando le attività non vengono avviate a causa della mancanza di autorizzazioni. Il messaggio di errore viene visualizzato come errore di attività interrotta. Per ulteriori informazioni, consulta [Risolvi gli errori relativi alle attività interrotte in Amazon ECS](resolve-stopped-errors.md).  
Le seguenti AWS Cloud Map azioni sono necessarie per eseguire un'attività:  
+ `servicediscovery:GetOperation`
+ `servicediscovery:RegisterInstance`
Assicurarsi che l'account consumer disponga delle autorizzazioni richieste e che il namespace condiviso sia accessibile.

**Le attività non vengono interrotte correttamente o rimangono bloccate nello stato `DEACTIVATING` o `DEPROVISIONING`**  
Questo problema si verifica quando le attività non riescono ad annullare la registrazione dal AWS Cloud Map servizio durante l'arresto a causa della mancanza di autorizzazioni. L'errore viene visualizzato come `statusReason` nell'allegato dell'attività che può essere recuperato utilizzando l'API `DescribeTasks`. Per ulteriori informazioni, consulta il *riferimento [DescribeTasks](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_DescribeTasks.html)all'API di Amazon Elastic Container Service*.  
Per interrompere un'attività sono necessarie le seguenti AWS Cloud Map azioni:  
+ `servicediscovery:DeregisterInstance`
+ `servicediscovery:GetOperation`
Se l'accesso al namespace viene revocato, le attività possono rimanere in uno stato `DEACTIVATING` o `DEPROVISIONING` fino al ripristino dell'accesso al namespace. Richiedere al proprietario del namespace di ripristinare l'accesso al namespace.

# Log di accesso di Amazon ECS Service Connect
<a name="service-connect-envoy-access-logs"></a>

Amazon ECS Service Connect supporta i log di accesso per fornire telemetria dettagliata sulle singole richieste elaborate dal proxy Service Connect. I log di accesso completano i log delle applicazioni esistenti acquisendo metadati sul traffico per richiesta come metodi HTTP, percorsi, codici di risposta, flag e informazioni temporali. Ciò consente una maggiore osservabilità dei modelli di traffico a livello di richiesta e delle interazioni di servizio per una risoluzione e un monitoraggio efficaci.

Per abilitare i log di accesso, specificate sia gli oggetti che `logConfiguration` gli `accessLogConfiguration` oggetti nell'oggetto. `serviceConnectConfiguration` È possibile configurare il formato dei log e se i log devono includere i parametri di interrogazione in. `accessLogConfiguration` I log vengono consegnati al gruppo di log di destinazione dal driver di registro specificato in. `logConfiguration`

```
{
    "serviceConnectConfiguration": {
        "enabled": true,
        "namespace": "myapp.namespace",
        "services": [
            ...
        ],
        "logConfiguration": {
            "logDriver": "awslogs",
            "options": {
                "awslogs-group": "my-envoy-log-group",
                "awslogs-region": "us-west-2",
                "awslogs-stream-prefix": "myapp-envoy-logs"
            }
        },
         "accessLogConfiguration": {
            "format": "TEXT",
            "includeQueryParameters": "ENABLED" 
        }
    }
}
```

## Considerazioni
<a name="service-connect-envoy-access-logs-considerations"></a>

Quando si abilita l'accesso ai log di accesso, si consideri quanto segue
+ I registri di accesso e i registri delle applicazioni vengono entrambi scritti su. `/dev/stdout` Per separare i log di accesso dai log delle applicazioni, si consiglia di utilizzare il driver di `awsfirelens` log con una configurazione OR personalizzata. Fluent Bit Fluentd
+  Si consiglia di utilizzare il driver di `awslogs` registro per inviare i log delle applicazioni e degli accessi alla stessa destinazione. CloudWatch 
+ i registri di accesso sono supportati sui servizi Fargate che utilizzano `1.4.0` versioni della piattaforma o successive.
+ I parametri di interrogazione come gli ID e i token delle richieste sono esclusi dai log di accesso per impostazione predefinita. Per includere i parametri di interrogazione nei log di accesso, impostate su. `includeQueryParameters` `"ENABLED"`

## Formati dei log di accesso
<a name="service-connect-envoy-access-logs-formats"></a>

i registri di accesso possono essere formattati in dizionari in formato JSON o stringhe in formato testo, con differenze negli operatori di comando supportati per i diversi tipi di log di accesso.

### registri di accesso HTTP
<a name="service-connect-envoy-access-logs-formats-http"></a>

I seguenti operatori di comando sono inclusi per impostazione predefinita nei log HTTP:

------
#### [ Text ]

```
[%START_TIME%] "%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%"
%RESPONSE_CODE% %BYTES_RECEIVED% %BYTES_SENT% %DURATION%
%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)% "%REQ(X-FORWARDED-FOR)%" "%REQ(USER-AGENT)%"
"%REQ(X-REQUEST-ID)%" "%REQ(:AUTHORITY)%" "%UPSTREAM_HOST%"\n
```

------
#### [ JSON ]

```
{
  "start_time": "%START_TIME%",
  "method": "%REQ(:METHOD)%",
  "path": "%REQ(X-ENVOY-ORIGINAL-PATH?:PATH)%",
  "protocol": "%PROTOCOL%",
  "response_code": "%RESPONSE_CODE%",
  "bytes_received": "%BYTES_RECEIVED%",
  "bytes_sent": "%BYTES_SENT%",
  "duration_ms": "%DURATION%",
  "upstream_service_time": "%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)%",
  "forwarded_for": "%REQ(X-FORWARDED-FOR)%",
  "user_agent": "%REQ(USER-AGENT)%",
  "request_id": "%REQ(X-REQUEST-ID)%",
  "authority": "%REQ(:AUTHORITY)%",
  "upstream_host": "%UPSTREAM_HOST%"
}
```

------

### HTTP2 registri di accesso
<a name="service-connect-envoy-access-logs-formats-http2"></a>

Oltre agli operatori di comando inclusi per i log HTTP, i HTTP2 log includono l'`%STREAM_ID%`operatore per impostazione predefinita.

------
#### [ Text ]

```
[%START_TIME%] "%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%"
%RESPONSE_CODE% %BYTES_RECEIVED% %BYTES_SENT% %DURATION%
%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)% "%REQ(X-FORWARDED-FOR)%" "%REQ(USER-AGENT)%"
"%REQ(X-REQUEST-ID)%" "%REQ(:AUTHORITY)%" "%UPSTREAM_HOST%" "%STREAM_ID%"\n
```

------
#### [ JSON ]

```
{
  "start_time": "%START_TIME%",
  "method": "%REQ(:METHOD)%",
  "path": "%REQ(X-ENVOY-ORIGINAL-PATH?:PATH)%",
  "protocol": "%PROTOCOL%",
  "response_code": "%RESPONSE_CODE%",
  "bytes_received": "%BYTES_RECEIVED%",
  "bytes_sent": "%BYTES_SENT%",
  "duration": "%DURATION%",
  "upstream_service_time": "%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)%",
  "forwarded_for": "%REQ(X-FORWARDED-FOR)%",
  "user_agent": "%REQ(USER-AGENT)%",
  "request_id": "%REQ(X-REQUEST-ID)%",
  "authority": "%REQ(:AUTHORITY)%",
  "upstream_host": "%UPSTREAM_HOST%",
  "stream_id": "%STREAM_ID%"
}
```

------

### Log di accesso gRPC
<a name="service-connect-envoy-access-logs-formats-grpc"></a>

Oltre agli operatori di comando inclusi per i log HTTP, i log di accesso gRPC includono `%STREAM_ID%` l'operatore `%GRPC_STATUS()%` and per impostazione predefinita.

------
#### [ Text ]

```
[%START_TIME%] "%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%"
%RESPONSE_CODE% %GRPC_STATUS()% %BYTES_RECEIVED% %BYTES_SENT% %DURATION%
%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)% "%REQ(X-FORWARDED-FOR)%" "%REQ(USER-AGENT)%"
"%REQ(X-REQUEST-ID)%" "%REQ(:AUTHORITY)%" "%UPSTREAM_HOST%" "%STREAM_ID%"\n
```

------
#### [ JSON ]

```
{
  "start_time": "%START_TIME%",
  "method": "%REQ(:METHOD)%",
  "path": "%REQ(X-ENVOY-ORIGINAL-PATH?:PATH)%",
  "protocol": "%PROTOCOL%",
  "response_code": "%RESPONSE_CODE%",
  "grpc_status": "%GRPC_STATUS()%",
  "bytes_received": "%BYTES_RECEIVED%",
  "bytes_sent": "%BYTES_SENT%",
  "duration": "%DURATION%",
  "upstream_service_time": "%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)%",
  "forwarded_for": "%REQ(X-FORWARDED-FOR)%",
  "user_agent": "%REQ(USER-AGENT)%",
  "request_id": "%REQ(X-REQUEST-ID)%",
  "authority": "%REQ(:AUTHORITY)%",
  "upstream_host": "%UPSTREAM_HOST%",
  "stream_id": "%STREAM_ID%"
}
```

------

### Registri di accesso TCP
<a name="service-connect-envoy-access-logs-formats-tcp"></a>

I seguenti operatori di comando sono inclusi per impostazione predefinita nei registri di accesso TCP:

------
#### [ Text ]

```
[%START_TIME%] %DOWNSTREAM_REMOTE_ADDRESS% %DOWNSTREAM_REMOTE_PORT% 
%BYTES_RECEIVED% %BYTES_SENT% %DURATION%  
%CONNECTION_TERMINATION_DETAILS% %CONNECTION_ID%\n
```

------
#### [ JSON ]

```
{
  "start_time": "%START_TIME%",
  "downstream_remote_address": "%DOWNSTREAM_REMOTE_ADDRESS%",
  "downstream_remote_port": "%DOWNSTREAM_REMOTE_PORT%",s
  "bytes_received": "%BYTES_RECEIVED%",
  "bytes_sent": "%BYTES_SENT%",
  "duration": "%DURATION%",
  "connection_termination_details": "%CONNECTION_TERMINATION_DETAILS%",
  "connection_id": %CONNECTION_ID%
}
```

------

Per ulteriori informazioni su questi operatori di comando, vedete Operatori di [comando nella documentazione](https://www.envoyproxy.io/docs/envoy/latest/configuration/observability/access_log/usage#command-operators) di Envoy.

# Abilitazione dei log di accesso per Amazon ECS Service Connect
<a name="service-connect-access-logs-configuration"></a>

I log di accesso non sono abilitati per impostazione predefinita per i servizi Amazon ECS che utilizzano Service Connect. Puoi abilitare i log di accesso nei seguenti modi.

## Abilitare i log di accesso utilizzando il AWS CLI
<a name="service-connect-access-logs-configure-cli"></a>

Il comando seguente mostra come abilitare i log di accesso per un servizio Amazon ECS utilizzando AWS CLI specificando un `accessLogConfiguration` quando si crea il servizio:

```
aws ecs create-service \
    --cluster my-cluster \
    --service-name my-service \
    --task-definition my-task-def \
    --service-connect-configuration '{
        "enabled": true,
        "namespace": "arn:aws:servicediscovery:us-west-2:123456789012:namespace/ns-abcdef1234567890",
        "services": [{
            "portName": "web",
            "discoveryName": "my-service",
            "clientAliases": [{
                "port": 80,
                "dnsName": "my-service"
            }]
        }],
        "logConfiguration": {
            "logDriver": "awslogs",
            "options": {
                "awslogs-group": "my-envoy-log-group",
                "awslogs-region": "us-west-2",
                "awslogs-stream-prefix": "myapp-envoy-logs"
            }
        },
         "accessLogConfiguration": {
            "format": "TEXT",
            "includeQueryParameters": "ENABLED" 
        }
    }'
```

## Abilita i log di accesso utilizzando la console
<a name="service-connect-access-logs-configure-console"></a>

Per una procedura dettagliata di creazione del servizio, consultare [Creazione di un'implementazione di aggiornamenti continui di Amazon ECS](create-service-console-v2.md).

**Per creare un servizio con uno spazio dei nomi condiviso utilizzando Console di gestione AWS**

1. [Aprire la console nella versione 2. https://console.aws.amazon.com/ecs/](https://console.aws.amazon.com/ecs/v2)

1. Sulla pagina **Cluster**, scegliere il cluster in cui creare il servizio.

1. In **Servizi**, scegliere **Crea**.

1. Dopo aver inserito altri dettagli a seconda del carico di lavoro, nella sezione **Service Connect**, scegliere **Usa Service Connect**.

1. Configura le impostazioni di Service Connect in base alle esigenze per il tipo di servizio (client o client-server).

1. Espandi la **configurazione del registro di accesso**. Per **Format**, scegli **JSON** o`TEXT`.

1. Per includere i parametri di interrogazione nei log di accesso, selezionate **Includi parametri di interrogazione**.

1. Completare il processo di creazione del servizio.

# Crittografare il traffico di Amazon ECS Service Connect
<a name="service-connect-tls"></a>

Amazon ECS Service Connect supporta la crittografia automatica del traffico con certificati Transport Layer Security (TLS) per i servizi Amazon ECS. Quando si indirizzano i servizi Amazon ECS verso un [AWS Autorità di certificazione privata (AWS Private CA)](https://docs.aws.amazon.com/privateca/latest/userguide/PcaWelcome.html), Amazon ECS fornisce automaticamente certificati TLS per crittografare il traffico tra i servizi Amazon ECS Service Connect. Amazon ECS genera, ruota e distribuisce i certificati TLS utilizzati per la crittografia del traffico.

La crittografia automatica del traffico con Service Connect utilizza funzionalità di crittografia leader del settore per proteggere le comunicazioni tra servizi e soddisfare i requisiti di sicurezza. Supporta certificati AWS Autorità di certificazione privata TLS con crittografia`256-bit ECDSA`. `2048-bit RSA` Si dispone anche del pieno controllo sui certificati privati e sulle chiavi di firma per soddisfare i requisiti di conformità. Per impostazione predefinita, TLS 1.3 è supportato, ma TLS 1.0-1.2 non lo sono. Service Connect supporta TLS 1.3 con i seguenti codici:
+ `TLS_AES_128_GCM_SHA256`
+ `TLS_AES_256_GCM_SHA384`
+ `TLS_CHACHA20_POLY1305_SHA256`

**Nota**  
Per utilizzare TLS 1.3, è necessario abilitarlo sul listener sulla destinazione.  
Solo il traffico in entrata e in uscita che passa attraverso l'agente Amazon ECS è crittografato.

## Controlli dell'integrità di Service Connect e Application Load Balancer
<a name="service-connect-tls-alb-healthchecks"></a>

È possibile utilizzare Service Connect con i controlli dell'integrità di Application Load Balancer e la crittografia TLS 1.3. 

### Configurazione di Application Load Balancer
<a name="service-connect-tls-alb-config"></a>

Configurare l'Application Load Balancer con le impostazioni seguenti:
+ Configura un listener TLS con una politica di sicurezza TLS 1.3 (come `Policy- -1-2-2021-06`ELBSecurity). TLS13 Per ulteriori informazioni, consultare [Security policies for your Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/describe-ssl-policies.html). 
+ Creare un gruppo di destinazione con le seguenti impostazioni:
  + Impostare il protocollo su HTTPS
  + Allegare il gruppo di destinazione al listener TLS
  + Configurare la porta di controllo dell'integrità in modo tale che corrisponda alla porta del container del servizio Service Connect

### Configurazione di Service Connect
<a name="service-connect-tls-sc-config"></a>

Configurare un servizio con le seguenti impostazioni:
+ Configurare il servizio per utilizzare la modalità di rete `awsvpc`, poiché la modalità di rete `bridge` non è supportata.
+ Abilita Service Connect per il servizio.
+ Impostare la configurazione del bilanciatore del carico con le seguenti impostazioni:
  + Specificare il gruppo di destinazione configurato per l'Application Load Balancer
  + Impostare la porta del container in modo che corrisponda a quella del servizio Service Connect TLS
+ Non impostare `ingressPortOverride` per il servizio. Per ulteriori informazioni, consulta il *riferimento [ServiceConnectService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ServiceConnectService.html)all'API di Amazon Elastic Container Service*.

### Considerazioni
<a name="service-connect-tls-alb-considerations"></a>

Considerare quanto segue durante l'utilizzo di Application Load Balancer, TLS e Service Connect:
+ Utilizzare la modalità di rete `awsvpc` anziché la modalità di rete `bridge` per i controlli dell'integrità HTTPS quando si usa Service Connect con crittografia TLS. I controlli dell'integrità HTTP continueranno a funzionare con la modalità `bridge`.
+ Configurare la porta di controllo dell'integrità del gruppo di destinazione in modo che corrisponda alla porta del container del servizio Service Connect, non alla porta HTTPS predefinita (443).

## AWS Autorità di certificazione privata certificati e Service Connect
<a name="service-connect-tls-certificates"></a>

È necessario disporre del ruolo IAM dell'infrastruttura. Per ulteriori informazioni su questo ruolo, consultare [Amazon ECS infrastructure IAM role](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/infrastructure_IAM_role.html                     ).

**AWS Autorità di certificazione privata modalità per Service Connect**

AWS Autorità di certificazione privata può funzionare in due modalità: generica e di breve durata.
+ Generica: certificati che possono essere configurati con qualsiasi data di scadenza.
+ Di breve durata: certificati con una validità massima di sette giorni.

Sebbene Amazon ECS supporti entrambe le modalità, consigliamo di utilizzare certificati di breve durata. Per impostazione predefinita, i certificati ruotano ogni cinque giorni e l'esecuzione in modalità di breve durata offre risparmi significativi sui costi rispetto agli usi generici.

Service Connect non supporta la revoca dei certificati e sfrutta invece certificati di breve durata con rotazione frequente dei certificati. Si dispone dell'autorità per modificare la frequenza di rotazione, disabilitare o eliminare i segreti utilizzando la [rotazione gestita](https://docs.aws.amazon.com/secretsmanager/latest/userguide/rotate-secrets_managed.html) in [Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html), ma ciò può comportare le seguenti possibili conseguenze.
+ Frequenza di rotazione più breve ‐ Una frequenza di rotazione più breve comporta costi più elevati a AWS Private CA causa di Secrets Manager AWS KMS e Auto Scaling che subiscono un maggiore carico di lavoro per la rotazione.
+ Frequenza di rotazione più lunga: le comunicazioni delle applicazioni hanno esito negativo se la frequenza di rotazione supera i **sette** giorni.
+ Eliminazione del segreto: l'eliminazione del segreto comporta un errore di rotazione e influisce sulle comunicazioni con le applicazioni dei clienti.

Se la rotazione dei segreti ha esito negativo, viene pubblicato un evento `RotationFailed` in [AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html). [Puoi anche impostare un CloudWatch allarme per.](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) `RotationFailed`

**Importante**  
Non aggiungere regioni di replica ai segreti. In questo modo si impedisce ad Amazon ECS di eliminare il segreto, poiché Amazon ECS non dispone dell'autorizzazione per rimuovere le regioni dalla replica. Se la replica è stata già aggiunta, eseguire il comando riportato di seguito.  

```
aws secretsmanager remove-regions-from-replication \
 --secret-id SecretId \
 --remove-replica-regions region-name
```

**Autorità di certificazione subordinate**  
È possibile importare qualsiasi certificato AWS Private CA, root o subordinato, a Service Connect TLS per emettere certificati di entità finale per i servizi. L'emittente fornito viene considerato firmatario e radice di attendibilità ovunque. È possibile emettere certificati di entità finale per diverse parti dell'applicazione da diversi subordinati. CAs Quando utilizzi AWS CLI, fornisci l'Amazon Resource Name (ARN) della CA per stabilire la catena di fiducia.

**Autorità di certificazioneon-premises**  
Per utilizzare la CA on-premises, è necessario creare e configurare una CA subordinata in AWS Autorità di certificazione privata. Ciò garantisce che tutti i certificati TLS emessi per i carichi di lavoro di Amazon ECS condividano la catena di attendibilità con i carichi di lavoro eseguiti on-premises e siano in grado di connettersi in modo sicuro.

**Importante**  
Aggiungi il tag **richiesto** `AmazonECSManaged : true` nel tuo AWS Private CA. 

**Infrastructure as code (IaC)**  
Quando si utilizza Service Connect TLS con gli strumenti Infrastructure as Code (IaC), è importante configurare correttamente le dipendenze per evitare problemi, come i servizi bloccati nel drenaggio. La AWS KMS chiave, se fornita, il ruolo IAM e AWS Private CA le dipendenze devono essere eliminati dopo il servizio Amazon ECS.

Se lo spazio dei nomi utilizzato per Service Connect è uno spazio dei nomi condiviso, puoi scegliere di utilizzare una risorsa condivisa. AWS Private CA Per ulteriori informazioni, consultare [Attach a policy for cross-account access](https://docs.aws.amazon.com/privateca/latest/userguide/pca-ram.html) nella *Guida per l'utente di AWS Autorità di certificazione privata *.

## Service Connect e Secrets Manager
<a name="service-connect-asm"></a>

**Quando si utilizza la crittografia Amazon ECS Service Connect with TLS, il servizio interagisce con Secrets Manager nei seguenti modi:**  
Service Connect utilizza il ruolo di infrastruttura fornito per creare segreti all'interno di Secrets Manager. Questi segreti vengono utilizzati per archiviare le chiavi private associate ai certificati TLS per crittografare il traffico tra i servizi di Service Connect.

**avvertimento**  
La creazione e la gestione automatiche di questi segreti da parte di Service Connect semplificano il processo di implementazione della crittografia TLS per i servizi. Tuttavia, è importante essere consapevoli delle potenziali implicazioni per la sicurezza. Altri ruoli IAM con accesso in lettura a Secrets Manager potrebbero essere in grado di accedere a questi segreti creati automaticamente. Ciò potrebbe esporre materiale crittografico sensibile a soggetti non autorizzati, se i controlli di accesso non sono configurati correttamente.  
Per mitigare questo rischio, seguire queste best practice:  
Gestire e limitare con attenzione l'accesso a Secrets Manager, in particolare per i segreti creati da Service Connect.
Verificare regolarmente i ruoli IAM e le relative autorizzazioni per garantire il rispetto del principio del privilegio minimo.

Quando si concede l'accesso in lettura a Secrets Manager, valutare la possibilità di escludere le chiavi private TLS create da Service Connect. Puoi farlo utilizzando una condizione nelle tue policy IAM per escludere i segreti ARNs che corrispondono allo schema:

```
"arn:aws:secretsmanager:::secret:ecs-sc!"
```

Un esempio di policy IAM che nega l'operazione `GetSecretValue` a tutti i segreti con il prefisso `ecs-sc!`:

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Deny",
            "Action": "secretsmanager:GetSecretValue",
            "Resource": "arn:aws:secretsmanager:*:*:secret:ecs-sc!*"
        }
    ]
}
```

------

**Nota**  
Questo è un esempio generale e potrebbe essere necessario modificarlo in base al caso d'uso specifico e alla configurazione AWS dell'account. Testare sempre attentamente le policy IAM per assicurarsi che forniscano l'accesso previsto mantenendo al contempo la sicurezza.

Comprendendo come Service Connect interagisce con Secrets Manager, si può gestire meglio la sicurezza dei servizi Amazon ECS sfruttando al contempo i vantaggi della crittografia TLS automatica.

## Service Connect e AWS Key Management Service
<a name="service-connect-kms"></a>

È possibile utilizzare [AWS Key Management Service](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html)per crittografare e decrittografare le risorse Service Connect. AWS KMS è un servizio gestito AWS in cui è possibile creare e gestire chiavi crittografiche per proteggere i dati.

Quando si utilizza AWS KMS con Service Connect, è possibile scegliere di utilizzare una chiave di AWS proprietà che AWS gestisca per conto proprio oppure scegliere una AWS KMS chiave esistente. Puoi anche [creare una nuova AWS KMS chiave](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html#create-symmetric-cmk) da usare.

**Fornire la propria chiave di crittografia**  
Puoi fornire i tuoi materiali chiave oppure puoi utilizzare un archivio di chiavi esterno tramite AWS Key Management Service Importa la tua chiave in AWS KMS, quindi specificare l'Amazon Resource Name (ARN) di quella chiave in Amazon ECS Service Connect.

Di seguito è riportato un esempio AWS KMS di policy. Sostituisci i *user input* valori con i tuoi.

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Sid": "id",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111122223333:role/role-name"
      },
      "Action": [
        "kms:Encrypt",
        "kms:Decrypt",
        "kms:GenerateDataKey",
        "kms:GenerateDataKeyPair"
      ],
      "Resource": "*"
    }
  ]
}
```

------

Per ulteriori informazioni sulle policy della chiave, consultare [Creating a key policy](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-overview.html) nella *Guida per gli sviluppatori di AWS Key Management Service *.

**Nota**  
Service Connect supporta solo chiavi di crittografia AWS KMS simmetriche. Non è possibile utilizzare nessun altro tipo di AWS KMS chiave per crittografare le risorse Service Connect. Per informazioni su come determinare se una AWS KMS chiave è una chiave di crittografia simmetrica, consulta [Identificare le chiavi KMS asimmetriche](https://docs.aws.amazon.com/kms/latest/developerguide/identify-key-types.html#identify-asymm-keys).

[https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#symmetric-cmks](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#symmetric-cmks)

# Abilitazione di TLS per Amazon ECS Service Connect
<a name="enable-service-connect-tls"></a>

La crittografia del traffico viene abilitata quando si crea o si aggiorna un servizio di Service Connect.

**Per abilitare la crittografia del traffico per un servizio in uno spazio dei nomi esistente utilizzando Console di gestione AWS**

1. È necessario disporre del ruolo IAM dell'infrastruttura. Per ulteriori informazioni su questo ruolo, consultare [Amazon ECS infrastructure IAM role](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/infrastructure_IAM_role.html                     ).

1. [Apri la console nella versione 2. https://console.aws.amazon.com/ecs/](https://console.aws.amazon.com/ecs/v2)

1. Nel riquadro di navigazione, selezionare **Namespaces**.

1. Scegliere il **Namespace** con il **Servizio** per cui si desidera abilitare la crittografia del traffico.

1. Scegliere il **Servizio** per cui si desidera abilitare la crittografia del traffico.

1. Scegliere **Aggiorna servizio** nell'angolo in alto a destra e scorrere in basso fino alla sezione Service Connect.

1. Scegliere **Attiva la crittografia del traffico** tra le informazioni sul servizio per abilitare TLS.

1. Per **Ruolo di Service Connect TLS**, scegliere un ruolo IAM dell'infrastruttura esistente o crearne uno nuovo.

1. Per **Autorità di certificato del firmatario**, scegliere un'autorità del certificato esistente o creane una nuova.

   Per ulteriori informazioni, consultare le [AWS Autorità di certificazione privata certificati e Service Connect](service-connect-tls.md#service-connect-tls-certificates).

1. Per **Scegli una AWS KMS key**, scegli una chiave AWS posseduta e gestita oppure puoi scegliere una chiave diversa. Si può anche scegliere di crearne una nuova.

Per un esempio di utilizzo di TLS AWS CLI per configurare il servizio,[Configurazione di Amazon ECS Service Connect con AWS CLI](create-service-connect.md).

# Verificare che TLS sia abilitato per Amazon ECS Service Connect
<a name="verify-tls-enabled"></a>

Service Connect avvia TLS nell'agente Service Connect e lo termina nell'agente di destinazione. Di conseguenza, il codice dell'applicazione non vede mai le interazioni TLS. Seguire questa procedura per verificare che TLS sia abilitato.

1. Includere la CLI `openssl` nell'immagine dell'applicazione.

1. Abilitare [ECS Exec](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-exec.html) sui servizi per connettersi alle attività tramite SSM. In alternativa, è possibile avviare un'istanza Amazon EC2 nello stesso Amazon VPC del servizio.

1. Recuperare l'IP e la porta di un'attività da un servizio che si desidera verificare. È possibile recuperare l'indirizzo IP dell'attività nella AWS Cloud Map console. Le informazioni si trovano nella pagina dei dettagli del servizio relativa al namespace. 

1. Accedere a una qualsiasi delle attività utilizzando `execute-command` come nell'esempio seguente. In alternativa, accedere all'istanza Amazon EC2 creata nella **Fase 2**.

   ```
   $ aws ecs execute-command --cluster cluster-name \
       --task task-id  \
       --container container-name \
       --interactive \
       --command "/bin/sh"
   ```
**Nota**  
La chiamata diretta al nome DNS non rivela il certificato.

1. Nella shell connessa, utilizzare la CLI `openssl` per verificare e visualizzare il certificato allegato all'attività.

   Esempio:

   ```
   openssl s_client -connect 10.0.147.43:6379 < /dev/null 2> /dev/null \ 
   | openssl x509 -noout -text
   ```

   Risposta di esempio:

   ```
   Certificate:
       Data:
           Version: 3 (0x2)
           Serial Number:
               <serial-number>
           Signature Algorithm: ecdsa-with-SHA256
           Issuer: <issuer>
           Validity
               Not Before: Jan 23 21:38:12 2024 GMT
               Not After : Jan 30 22:38:12 2024 GMT
           Subject: <subject>
           Subject Public Key Info:
               Public Key Algorithm: id-ecPublicKey
                   Public-Key: (256 bit)
                   pub:
                       <pub>
                   ASN1 OID: prime256v1
                   NIST CURVE: P-256
           X509v3 extensions:
               X509v3 Subject Alternative Name:
                   DNS:redis.yelb-cftc
               X509v3 Basic Constraints:
                   CA:FALSE
               X509v3 Authority Key Identifier:
                   keyid:<key-id>
   
               X509v3 Subject Key Identifier:
                   1D:<id>
               X509v3 Key Usage: critical
                   Digital Signature, Key Encipherment
               X509v3 Extended Key Usage:
                   TLS Web Server Authentication, TLS Web Client Authentication
       Signature Algorithm: ecdsa-with-SHA256
           <hash>
   ```

# Configurazione di Amazon ECS Service Connect con AWS CLI
<a name="create-service-connect"></a>

È possibile creare un servizio Amazon ECS per un'attività Fargate che usa Service Connect con la AWS CLI.

**Nota**  
Puoi utilizzare gli endpoint del servizio dual-stack per interagire con Amazon ECS da AWS CLI, SDKs e l'API Amazon ECS su entrambi e. IPv4 IPv6 Per ulteriori informazioni, consulta [Utilizzo degli endpoint dual-stack Amazon ECS](dual-stack-endpoint.md).

## Prerequisiti
<a name="create-service-connect-prereqs"></a>

Di seguito sono riportati i prerequisiti di Service Connect:
+ Verifica che sia installata e configurata la versione più recente di. AWS CLI Per ulteriori informazioni, consultare [Installing or updating to the latest version of the AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html).
+ L'utente IAM dispone delle autorizzazioni necessarie specificate nell'esempio di policy IAM [AmazonECS\$1 FullAccess](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonECS_FullAccess).
+ Sono disponibili un VPC, una sottorete, una tabella di instradamento e un gruppo di sicurezza creati per l'uso. Per ulteriori informazioni, consultare [Crea un cloud privato virtuale](get-set-up-for-amazon-ecs.md#create-a-vpc).
+ Hai un ruolo di esecuzione delle attività con il nome `ecsTaskExecutionRole` e la policy gestita da `AmazonECSTaskExecutionRolePolicy` è associata al ruolo. Questo ruolo consente a Fargate di scrivere i log delle applicazioni NGINX e i log del proxy Service Connect su Amazon Logs. CloudWatch Per ulteriori informazioni, consulta [Creazione del ruolo di esecuzione attività](task_execution_IAM_role.md#create-task-execution-role).

## Fase 1: Creazione del cluster
<a name="create-service-connect-cluster"></a>

Utilizzare la procedura seguente per creare un cluster e un namespace Amazon ECS.

**Per creare il cluster e AWS Cloud Map lo spazio dei nomi Amazon ECS**

1. Crea un cluster Amazon ECS denominato `tutorial` da utilizzare. Il parametro `--service-connect-defaults` imposta il namespace predefinito del cluster. Nell'output di esempio, uno AWS Cloud Map spazio dei nomi con il nome `service-connect` non esiste in questo account e Regione AWS quindi lo spazio dei nomi viene creato da Amazon ECS. Il namespace è creato in AWS Cloud Map nell'account ed è visibile insieme a tutti gli altri spazi dei nomi, quindi utilizza un nome che ne indichi lo scopo.

   ```
   aws ecs create-cluster --cluster-name tutorial --service-connect-defaults namespace=service-connect
   ```

   Output:

   ```
   {
       "cluster": {
           "clusterArn": "arn:aws:ecs:us-west-2:123456789012:cluster/tutorial",
           "clusterName": "tutorial",
           "serviceConnectDefaults": {
               "namespace": "arn:aws:servicediscovery:us-west-2:123456789012:namespace/ns-EXAMPLE"
           },
           "status": "PROVISIONING",
           "registeredContainerInstancesCount": 0,
           "runningTasksCount": 0,
           "pendingTasksCount": 0,
           "activeServicesCount": 0,
           "statistics": [],
           "tags": [],
           "settings": [
               {
                   "name": "containerInsights",
                   "value": "disabled"
               }
           ],
           "capacityProviders": [],
           "defaultCapacityProviderStrategy": [],
           "attachments": [
               {
                   "id": "a1b2c3d4-5678-90ab-cdef-EXAMPLE11111",
                   "type": "sc",
                   "status": "ATTACHING",
                   "details": []
               }
           ],
           "attachmentsStatus": "UPDATE_IN_PROGRESS"
       }
   }
   }
   ```

1. Verifica che il cluster sia stato creato:

   ```
   aws ecs describe-clusters --clusters tutorial
   ```

   Output:

   ```
   {
       "clusters": [
           {
               "clusterArn": "arn:aws:ecs:us-west-2:123456789012:cluster/tutorial",
               "clusterName": "tutorial",
               "serviceConnectDefaults": {
                   "namespace": "arn:aws:servicediscovery:us-west-2:123456789012:namespace/ns-EXAMPLE"
               },
               "status": "ACTIVE",
               "registeredContainerInstancesCount": 0,
               "runningTasksCount": 0,
               "pendingTasksCount": 0,
               "activeServicesCount": 0,
               "statistics": [],
               "tags": [],
               "settings": [],
               "capacityProviders": [],
               "defaultCapacityProviderStrategy": []
           }
       ],
       "failures": []
   }
   ```

1. (Facoltativo) Verifica che lo spazio dei nomi sia stato creato in. AWS Cloud MapÈ possibile utilizzare la configurazione Console di gestione AWS o la AWS CLI configurazione normale così come viene creata in. AWS Cloud Map

   Ad esempio, utilizza la AWS CLI.

   ```
   aws servicediscovery get-namespace --id ns-EXAMPLE
   ```

   Output:

   ```
   {
       "Namespace": {
           "Id": "ns-EXAMPLE",
           "Arn": "arn:aws:servicediscovery:us-west-2:123456789012:namespace/ns-EXAMPLE",
           "Name": "service-connect",
           "Type": "HTTP",
           "Properties": {
               "DnsProperties": {
                   "SOA": {}
               },
               "HttpProperties": {
                   "HttpName": "service-connect"
               }
           },
           "CreateDate": 1661749852.422,
           "CreatorRequestId": "service-connect"
       }
   }
   ```

## Fase 2: Creazione del servizio per il server
<a name="create-service-connect-nginx-server"></a>

La funzionalità Service Connect è progettata per l'interconnessione di più applicazioni su Amazon ECS. Almeno una di queste applicazioni deve fornire un servizio Web a cui connettersi. In questa fase viene creata:
+ La definizione dell'attività che utilizza l'immagine del container NGINX ufficiale non modificata e include la configurazione di Service Connect.
+ La definizione del servizio Amazon ECS che configura Service Connect per fornire il rilevamento servizi e il mesh di servizi che indirizza il traffico verso questo servizio. La configurazione riutilizza il namespace predefinito della configurazione del cluster per ridurre la quantità di operazioni di configurazione del servizio effettuata per ciascun servizio.
+ Il servizio Amazon ECS. Esegue un'attività utilizzando la definizione di attività e inserisce un container aggiuntivo per il proxy Service Connect. Il proxy Service Connect è in ascolto sulla porta dalla mappatura della porta del container nella definizione di attività. In un'applicazione client in esecuzione su Amazon ECS, il proxy nell'attività client ascolta le connessioni in uscita al nome della porta di definizione dell'attività, al nome della porta di individuazione del servizio o al nome alias del client del servizio e al numero di porta dall'alias del client.

**Creazione del servizio Web con Service Connect**

1. Registra una definizione di attività che sia compatibile con Fargate e utilizzi la modalità di rete `awsvpc`. Completare la procedura riportata di seguito.

   1. Crea un file denominato `service-connect-nginx.json` con il contenuto della seguente definizione di attività.

      Questa definizione di attività configura Service Connect aggiungendo i parametri `name` e `appProtocol` alla mappatura delle porte. Il nome della porta rende questa porta più identificabile nella configurazione del servizio quando vengono utilizzate più porte. Il nome della porta viene utilizzato anche per impostazione predefinita come nome individuabile per essere utilizzato da altre applicazioni nel namespace.

      La definizione dell'attività contiene il ruolo IAM dell'attività perché il servizio ha abilitato l'esecuzione ECS.
**Importante**  
Questa definizione di attività utilizza `logConfiguration` a per inviare l'output nginx da `stdout` e `stderr` verso Amazon Logs. CloudWatch Questo ruolo di esecuzione delle attività non dispone delle autorizzazioni aggiuntive necessarie per creare il CloudWatch gruppo di log Logs. Crea il gruppo di log in CloudWatch Logs utilizzando o. Console di gestione AWS AWS CLI Se non desideri inviare i log di nginx a Logs, puoi rimuovere CloudWatch il. `logConfiguration`  
Sostituisci l' Account AWS id nel ruolo di esecuzione dell'attività con il tuo id. Account AWS 

      ```
      {
          "family": "service-connect-nginx",
          "executionRoleArn": "arn:aws:iam::123456789012:role/ecsTaskExecutionRole",
          "taskRoleArn": "arn:aws:iam::123456789012:role/ecsTaskRole",
          "networkMode": "awsvpc",
          "containerDefinitions": [
              {
              "name": "webserver",
              "image": "public.ecr.aws/docker/library/nginx:latest",
              "cpu": 100,
              "portMappings": [
                  {
                      "name": "nginx",
                      "containerPort": 80,
                      "protocol": "tcp", 
                      "appProtocol": "http"
                  }
              ],
              "essential": true,
              "logConfiguration": {
                  "logDriver": "awslogs",
                  "options": {
                      "awslogs-group": "/ecs/service-connect-nginx",
                      "awslogs-region": "region", 
                      "awslogs-stream-prefix": "nginx"
                  }
              }
              }
          ],
          "cpu": "256",
          "memory": "512"
      }
      ```

   1. Registra la definizione di attività usando il file `service-connect-nginx.json`:

      ```
      aws ecs register-task-definition --cli-input-json file://service-connect-nginx.json
      ```

1. Creare un servizio:

   1. Crea un file denominato `service-connect-nginx-service.json` con il contenuto del servizio Amazon ECS che stai per creare. Questo esempio usa la definizione di attività creata nella fase precedente. È obbligatorio l'uso di un parametro `awsvpcConfiguration` perché la definizione di attività di esempio usa la modalità di rete `awsvpc`.

      Quando si crea il servizio ECS, specificare Fargate e la versione della piattaforma `LATEST` che supporta Service Connect. I `securityGroups` e le `subnets` devono appartenere a un cloud VPC che soddisfi i requisiti per l'utilizzo di Amazon ECS. Puoi ottenere il gruppo di sicurezza e la sottorete IDs dalla console Amazon VPC. 

      Questo servizio configura Service Connect aggiungendo il parametro `serviceConnectConfiguration`. Il namespace non è richiesto perché il cluster ha un namespace predefinito configurato. Le applicazioni client in esecuzione in ECS nel namespace si connettono a questo servizio utilizzando il `portName` e la porta negli `clientAliases`. Ad esempio, questo servizio è raggiungibile tramite `http://nginx:80/`, poiché nginx fornisce una pagina di benvenuto nella posizione root `/`. Le applicazioni esterne che non sono in esecuzione in Amazon ECS o che non si trovano nello stesso namespace possono raggiungere questa applicazione tramite il proxy Service Connect utilizzando l'indirizzo IP dell'attività e il numero di porta indicato nella definizione dell'attività. Per la configurazione di `tls`, aggiungere il certificato `arn` per il `awsPcaAuthorityArn`, `kmsKey` e `roleArn` del ruolo IAM.

      Questo servizio utilizza un `logConfiguration` per inviare l'output del proxy Service Connect da `stdout` e `stderr` verso Amazon CloudWatch Logs. Questo ruolo di esecuzione delle attività non dispone delle autorizzazioni aggiuntive necessarie per creare il gruppo di CloudWatch log Logs. Crea il gruppo di log in CloudWatch Logs utilizzando o. Console di gestione AWS AWS CLI Si consiglia di creare questo gruppo di log e di archiviare i log proxy in CloudWatch Logs. Se non desideri inviare i log del proxy a Logs, puoi CloudWatch rimuovere il. `logConfiguration`

      ```
      {
          "cluster": "tutorial",
          "deploymentConfiguration": {
              "maximumPercent": 200,
              "minimumHealthyPercent": 0
          },
          "deploymentController": {
              "type": "ECS"
          },
          "desiredCount": 1,
          "enableECSManagedTags": true,
          "enableExecuteCommand": true,
          "launchType": "FARGATE",
          "networkConfiguration": {
              "awsvpcConfiguration": {
                  "assignPublicIp": "ENABLED",
                  "securityGroups": [
                      "sg-EXAMPLE"
                  ],
                  "subnets": [
                      "subnet-EXAMPLE",
                      "subnet-EXAMPLE",
                      "subnet-EXAMPLE"
                  ]
                 }
          },
          "platformVersion": "LATEST",
          "propagateTags": "SERVICE",
          "serviceName": "service-connect-nginx-service",
          "serviceConnectConfiguration": {
              "enabled": true,
              "services": [
                  {
                      "portName": "nginx",
                      "clientAliases": [
                          {
                              "port": 80
                          }
                      ],
                      "tls": {
                         "issuerCertificateAuthority": {
                            "awsPcaAuthorityArn": "certificateArn"
                         }, 
                         "kmsKey": "kmsKey", 
                         "roleArn": "iamRoleArn"
                      }
                  }
              ],
              "logConfiguration": {
                  "logDriver": "awslogs",
                  "options": {
                      "awslogs-group": "/ecs/service-connect-proxy",
                      "awslogs-region": "region",
                      "awslogs-stream-prefix": "service-connect-proxy"
                  }
              }
          },
          "taskDefinition": "service-connect-nginx"
      }
      ```

   1. Creare un servizio utilizzando il file `service-connect-nginx-service.json`:

      ```
      aws ecs create-service --cluster tutorial --cli-input-json file://service-connect-nginx-service.json
      ```

      Output:

      ```
      {
          "service": {
              "serviceArn": "arn:aws:ecs:us-west-2:123456789012:service/tutorial/service-connect-nginx-service",
              "serviceName": "service-connect-nginx-service",
              "clusterArn": "arn:aws:ecs:us-west-2:123456789012:cluster/tutorial",
              "loadBalancers": [],
              "serviceRegistries": [],
              "status": "ACTIVE",
              "desiredCount": 1,
              "runningCount": 0,
              "pendingCount": 0,
              "launchType": "FARGATE",
              "platformVersion": "LATEST",
              "platformFamily": "Linux",
              "taskDefinition": "arn:aws:ecs:us-west-2:123456789012:task-definition/service-connect-nginx:1",
              "deploymentConfiguration": {
                  "deploymentCircuitBreaker": {
                      "enable": false,
                      "rollback": false
                  },
                  "maximumPercent": 200,
                  "minimumHealthyPercent": 0
              },
              "deployments": [
                  {
                      "id": "ecs-svc/3763308422771520962",
                      "status": "PRIMARY",
                      "taskDefinition": "arn:aws:ecs:us-west-2:123456789012:task-definition/service-connect-nginx:1",
                      "desiredCount": 1,
                      "pendingCount": 0,
                      "runningCount": 0,
                      "failedTasks": 0,
                      "createdAt": 1661210032.602,
                      "updatedAt": 1661210032.602,
                      "launchType": "FARGATE",
                      "platformVersion": "1.4.0",
                      "platformFamily": "Linux",
                      "networkConfiguration": {
                          "awsvpcConfiguration": {
                              "assignPublicIp": "ENABLED",
                              "securityGroups": [
                                  "sg-EXAMPLE"
                              ],
                              "subnets": [
                                  "subnet-EXAMPLEf",
                                  "subnet-EXAMPLE",
                                  "subnet-EXAMPLE"
                              ]
                          }
                      },
                      "rolloutState": "IN_PROGRESS",
                      "rolloutStateReason": "ECS deployment ecs-svc/3763308422771520962 in progress.",
                      "failedLaunchTaskCount": 0,
                      "replacedTaskCount": 0,
                      "serviceConnectConfiguration": {
                          "enabled": true,
                          "namespace": "service-connect",
                          "services": [
                              {
                                  "portName": "nginx",
                                  "clientAliases": [
                                      {
                                          "port": 80
                                      }
                                  ]
                              }
                          ],
                          "logConfiguration": {
                              "logDriver": "awslogs",
                              "options": {
                                  "awslogs-group": "/ecs/service-connect-proxy",
                                  "awslogs-region": "us-west-2",
                                  "awslogs-stream-prefix": "service-connect-proxy"
                              },
                              "secretOptions": []
                          }
                      },
                      "serviceConnectResources": [
                          {
                              "discoveryName": "nginx",
                              "discoveryArn": "arn:aws:servicediscovery:us-west-2:123456789012:service/srv-EXAMPLE"
                          }
                      ]
                  }
              ],
              "roleArn": "arn:aws:iam::123456789012:role/aws-service-role/ecs.amazonaws.com/AWSServiceRoleForECS",
              "version": 0,
              "events": [],
              "createdAt": 1661210032.602,
              "placementConstraints": [],
              "placementStrategy": [],
              "networkConfiguration": {
                  "awsvpcConfiguration": {
                      "assignPublicIp": "ENABLED",
                      "securityGroups": [
                          "sg-EXAMPLE"
                      ],
                      "subnets": [
                          "subnet-EXAMPLE",
                          "subnet-EXAMPLE",
                          "subnet-EXAMPLE"
                      ]
                  }
              },
              "schedulingStrategy": "REPLICA",
              "enableECSManagedTags": true,
              "propagateTags": "SERVICE",
              "enableExecuteCommand": true
          }
      }
      ```

      La `serviceConnectConfiguration` fornita viene visualizzata all'interno della prima *implementazione* dell'output. Quando apporti modifiche al servizio ECS in modi che richiedono modifiche alle attività, Amazon ECS crea una nuova implementazione.

## Fase 3: Verifica della riuscita della connessione
<a name="create-service-connect-verify"></a>

Per verificare che Service Connect sia configurato e funzionante, completa questa procedura per connetterti al servizio Web da un'applicazione esterna. Quindi, guarda le metriche aggiuntive nelle creazioni CloudWatch del proxy Service Connect.

**Connessione al servizio Web da un'applicazione esterna**
+ Connessione all'indirizzo IP dell'attività e alla porta del container utilizzando l'indirizzo IP dell'attività

  Usa il AWS CLI per ottenere l'ID dell'attività, utilizzando. `aws ecs list-tasks --cluster tutorial`

  Se le sottoreti e il gruppo di sicurezza consentono il traffico proveniente dalla rete Internet pubblica sulla porta della definizione dell'attività, sarà possibile connettersi all'IP pubblico dal computer. Tuttavia, l'IP pubblico non è disponibile da `describe-tasks`, quindi la procedura prevede di accedere ad Amazon EC2 Console di gestione AWS o AWS CLI ottenere i dettagli dell'interfaccia di rete elastica.

  In questo esempio, un'istanza Amazon EC2 nello stesso VPC utilizza l'IP privato dell'attività. L'applicazione è nginx, ma l'intestazione `server: envoy` mostra che viene utilizzato il proxy Service Connect. Il proxy Service Connect è in ascolto sulla porta del container a partire dalla definizione dell'attività.

  ```
  $ curl -v 10.0.19.50:80/
  *   Trying 10.0.19.50:80...
  * Connected to 10.0.19.50 (10.0.19.50) port 80 (#0)
  > GET / HTTP/1.1
  > Host: 10.0.19.50
  > User-Agent: curl/7.79.1
  > Accept: */*
  >
  * Mark bundle as not supporting multiuse
  < HTTP/1.1 200 OK
  < server: envoy
  < date: Tue, 23 Aug 2022 03:53:06 GMT
  < content-type: text/html
  < content-length: 612
  < last-modified: Tue, 16 Apr 2019 13:08:19 GMT
  < etag: "5cb5d3c3-264"
  < accept-ranges: bytes
  < x-envoy-upstream-service-time: 0
  <
  <!DOCTYPE html>
  <html>
  <head>
  <title>Welcome to nginx!</title>
  <style>
      body {
          width: 35em;
          margin: 0 auto;
          font-family: Tahoma, Verdana, Arial, sans-serif;
      }
  </style>
  </head>
  <body>
  <h1>Welcome to nginx!</h1>
  <p>If you see this page, the nginx web server is successfully installed and
  working. Further configuration is required.</p>
  
  <p>For online documentation and support please refer to
  <a href="http://nginx.org/">nginx.org</a>.<br/>
  Commercial support is available at
  <a href="http://nginx.com/">nginx.com</a>.</p>
  
  <p><em>Thank you for using nginx.</em></p>
  </body>
  </html>
  ```

**Visualizzazione dei parametri di Service Connect**  
Il proxy Service Connect crea metriche dell'applicazione (connessione HTTP HTTP2, gRPC o TCP) nelle metriche. CloudWatch Quando usi la CloudWatch console, visualizza le dimensioni metriche aggiuntive di **DiscoveryName**, (, **DiscoveryName ServiceName, ClusterName**) e (**TargetDiscoveryName**, **TargetDiscoveryName ServiceName, ClusterName**) nello spazio dei nomi Amazon ECS. Per ulteriori informazioni su questi parametri e sulle dimensioni, consulta [Visualizza i parametri disponibili](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/viewing_metrics_with_cloudwatch.html) nella Amazon CloudWatch Logs User Guide.

# Usare il rilevamento servizi per connettere i servizi Amazon ECS con nomi DNS
<a name="service-discovery"></a>

Il servizio Amazon ECS può facoltativamente essere configurato per l'uso della funzione di individuazione dei servizi di Amazon ECS. Service Discovery utilizza azioni AWS Cloud Map API per gestire i namespace HTTP e DNS per i tuoi servizi Amazon ECS. Per ulteriori informazioni, consultare [What Is AWS Cloud Map](https://docs.aws.amazon.com/cloud-map/latest/dg/Welcome.html) nella *Guida per gli sviluppatori di AWS Cloud Map *.

L'individuazione dei servizi è disponibile nelle seguenti regioni: AWS 


| Nome della regione | Regione | 
| --- | --- | 
|  Stati Uniti orientali (Virginia settentrionale)  |  us-east-1  | 
|  Stati Uniti orientali (Ohio)  |  us-east-2  | 
|  Stati Uniti occidentali (California settentrionale)  |  us-west-1  | 
|  US West (Oregon)  |  us-west-2  | 
|  Africa (Città del Capo)  |  af-south-1  | 
|  Asia Pacific (Hong Kong)  |  ap-east-1  | 
|  Asia Pacifico (Taipei)  |  ap-east-2  | 
|  Asia Pacifico (Mumbai)  |  ap-south-1  | 
|  Asia Pacifico (Hyderabad)  |  ap-south-2  | 
|  Asia Pacifico (Tokyo)  |  ap-northeast-1  | 
|  Asia Pacifico (Seoul)  |  ap-northeast-2  | 
|  Asia Pacifico (Osaka-Locale)  |  ap-northeast-3  | 
|  Asia Pacifico (Singapore)  |  ap-southeast-1  | 
|  Asia Pacific (Sydney)  |  ap-southeast-2  | 
|  Asia Pacifico (Giacarta)  |  ap-southeast-3  | 
|  Asia Pacifico (Melbourne)  |  ap-southeast-4  | 
|  Asia Pacifico (Malesia)  |  ap-southeast-5  | 
|  Asia Pacifico (Nuova Zelanda)  |  ap-southeast-6  | 
|  Asia Pacifico (Thailandia)  |  ap-southeast-7  | 
|  Canada (Centrale)  |  ca-central-1  | 
|  Canada occidentale (Calgary)  |  ca-west-1  | 
|  Cina (Pechino)  |  cn-north-1  | 
|  China (Ningxia)  |  cn-northwest-1  | 
|  Europe (Frankfurt)  |  eu-central-1  | 
|  Europa (Zurigo)  |  eu-central-2  | 
|  Europa (Irlanda)  |  eu-west-1  | 
|  Europe (London)  |  eu-west-2  | 
|  Europe (Paris)  |  eu-west-3  | 
|  Europe (Milan)  |  eu-south-1  | 
|  Europa (Stoccolma)  |  eu-north-1  | 
|  Israele (Tel Aviv)  |  il-central-1  | 
|  Europa (Spagna)  |  eu-south-2  | 
|  Medio Oriente (Emirati Arabi Uniti)  |  me-central-1  | 
|  Messico (Centrale)  |  mx-central-1  | 
|  Medio Oriente (Bahrein)  |  me-south-1  | 
|  Sud America (San Paolo)  |  sa-east-1  | 
|  AWS GovCloud (Stati Uniti orientali)  |  us-gov-east-1  | 
|  AWS GovCloud (Stati Uniti occidentali)  |  us-gov-west-1  | 

## Concetti relativi all'individuazione dei servizi
<a name="service-discovery-concepts"></a>

L'individuazione dei servizi è costituita dai componenti seguenti:
+ **Namespace di rilevamento servizi**: un raggruppamento logico di servizi di rilevamento dei servizi che condividono lo stesso nome di dominio, ad esempio `example.com`, che rappresenta la posizione in cui si vuole instradare il traffico. È possibile creare un namespace con una chiamata al comando `aws servicediscovery create-private-dns-namespace` o nella console classica di Amazon ECS. È possibile utilizzare il comando `aws servicediscovery list-namespaces` per visualizzare le informazioni di riepilogo dei namespace creati dall'account corrente. Per ulteriori informazioni sui comandi di individuazione dei servizi, vedere `[create-private-dns-namespace](https://docs.aws.amazon.com/cli/latest/reference/servicediscovery/create-private-dns-namespace.html)` e `[list-namespaces](https://docs.aws.amazon.com/cli/latest/reference/servicediscovery/list-namespaces.html)` nella *Guida di AWS CLI riferimento AWS Cloud Map (service discovery)*.
+ **Servizio di individuazione dei servizi**: è incluso nel namespace di individuazione dei servizi ed è costituito dal nome del servizio e dalla configurazione DNS per il namespace. Fornisce il componente principale seguente:
  + **Registro dei servizi**: consente di cercare un servizio tramite azioni DNS o AWS Cloud Map API e recuperare uno o più endpoint disponibili che possono essere utilizzati per connettersi al servizio.
+ **Istanza di individuazione dei servizi**: esiste all'interno del servizio di individuazione dei servizi e include gli attributi associati a ogni servizio Amazon ECS nella directory del servizio.
  + **Attributi dell'istanza**: i metadati seguenti vengono aggiunti come attributi personalizzati per ciascun servizio Amazon ECS configurato per l'utilizzo dell'individuazione dei servizi:
    + **`AWS_INSTANCE_IPV4`**— Per un `A` record, l' IPv4 indirizzo che Route 53 restituisce in risposta alle query DNS e AWS Cloud Map restituisce quando rileva i dettagli dell'istanza, ad esempio. `192.0.2.44`
    + **`AWS_INSTANCE_IPV6`**— Per un `AAAA` record, l' IPv6 indirizzo che Route 53 restituisce in risposta alle query DNS e AWS Cloud Map restituisce quando rileva i dettagli dell'istanza, ad esempio,. ` 2001:0db8:85a3:0000:0000:abcd:0001:2345` Sia `AWS_INSTANCE_IPv4` che `AWS_INSTANCE_IPv6` vengono aggiunti per i servizi dualstack di Amazon ECS. `AWS_INSTANCE_IPv6`Viene aggiunto solo per i servizi IPv6 solo di Amazon ECS.
    + **`AWS_INSTANCE_PORT`**: il valore della porta associato al servizio di individuazione dei servizi.
    + **`AVAILABILITY_ZONE`**: la zona di disponibilità in cui il processo è stato avviato. Per i processi che utilizzano EC2, questa è la zona di disponibilità in cui è presente l'istanza di container. Per i processi che utilizzano Fargate, questa è la zona di disponibilità in cui è presente l'interfaccia di rete elastica.
    + **`REGION`**: la regione in cui è presente il processo.
    + **`ECS_SERVICE_NAME`**: il nome del servizio Amazon ECS a cui appartiene il processo.
    + **`ECS_CLUSTER_NAME`**: il nome del cluster Amazon ECS a cui appartiene il processo.
    + **`EC2_INSTANCE_ID`**: l'ID dell'istanza di container in cui è stata posizionato il processo Questo attributo personalizzato non viene aggiunto se l'attività sta utilizzando Fargate.
    + **`ECS_TASK_DEFINITION_FAMILY`**: la famiglia della definizione di attività utilizzata dal processo.
    + **`ECS_TASK_SET_EXTERNAL_ID`**: se viene creato un set di processi per un'implementazione esterna ed è associato a un registro di individuazione dei servizi, l'attributo `ECS_TASK_SET_EXTERNAL_ID` includerà l'ID esterno del set di processi.
+ **Controlli dell'integrità di Amazon ECS**: Amazon ECS esegue periodicamente controlli dell'integrità a livello di container. Se un endpoint non supera il controllo dello stato, viene rimosso dal routing DNS e contrassegnato come non integro.

## Considerazioni relative all'individuazione dei servizi
<a name="service-discovery-considerations"></a>

Quando usi l'individuazione dei servizi, tieni presenti le considerazioni seguenti:
+ L'individuazione dei servizi è supportata per i processi su Fargate che utilizzano la piattaforma versione 1.1.0 o successiva. Per ulteriori informazioni, consultare [Versioni della piattaforma Fargate per Amazon ECS](platform-fargate.md).
+ I servizi configurati per l'utilizzo del rilevamento dei servizi Amazon ECS hanno un limite di 1.000 processi per servizio. Ciò è dovuto a una quota di servizio Route 53.
+ Il flusso di lavoro Crea servizio nella console Amazon ECS supporta solo la registrazione dei servizi in spazi dei nomi DNS privati. Quando viene creato uno spazio dei nomi DNS AWS Cloud Map privato, verrà creata automaticamente una zona ospitata privata di Route 53.
+ Per la corretta risoluzione DNS, gli attributi DNS del VPC devono essere configurati. Per ulteriori informazioni su come configurare gli attributi, consulta [Supporto DNS nel VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#vpc-dns-support) nella *Guida per l'utente di Amazon VPC*.
+ Amazon ECS non supporta la registrazione di servizi in namespace condivisi AWS Cloud Map .
+ I record DNS creati per un servizio DNS si registrano sempre con l'indirizzo IP privato per il processo piuttosto che l'indirizzo IP pubblico, anche quando vengono utilizzati gli spazi di nomi pubblici.
+ L'individuazione dei servizi richiede che i processi specifichino la modalità di rete `awsvpc`, `bridge` o `host` (`none` non è supportata).
+ Se la definizione di attività del servizio usa la modalità di rete `awsvpc`, puoi creare qualsiasi combinazione di record `A` o `SRV` per ciascuna attività di servizio. Se si utilizzano i record `SRV`, è necessaria una porta. Inoltre, è possibile creare record `AAAA` se il servizio utilizza sottoreti dualstack. Se il servizio utilizza IPv6 solo sottoreti, non puoi creare record. `A`
+ Se la definizione di attività di servizio usa la modalità di rete `bridge` o `host`, un record SRV è il solo tipo di record DNS supportato. Crea un record SRV per ciascuna operazione di servizio. Il record SRV deve specificare un nome di container e una combinazione di porte di container dalla definizione di attività.
+ È possibile eseguire query sui record DNS per un servizio di individuazione dei servizi all'interno del VPC. Viene usato questo formato: `<service-discovery-service-name>.<service-discovery-namespace>`.
+ Quando si esegue una query DNS sul nome del servizio, i record `A` e `AAAA` restituiscono un set di indirizzi IP corrispondenti alle attività. I record `SRV` restituiscono un set di indirizzi IP e porte per ciascuna attività.
+ Se dispone di otto o meno record integri, Route 53 risponde alle query DNS con tutti i record integri.
+ Quando tutti i record non sono integri, Route 53 risponde alle query DNS con un massimo di otto record non integri.
+ Puoi configurare il rilevamento dei servizi per un servizio protetto da un load balancer, ma il traffico del rilevamento dei servizi viene sempre instradato verso l'attività e non verso il load balancer.
+ L'individuazione dei servizi non supporta l'utilizzo di Classic Load Balancer.
+ Per il servizio di individuazione dei servizi consigliamo di utilizzare i controlli dell'integrità a livello dei container gestiti da Amazon ECS.
  + **HealthCheckCustomConfig**—Amazon ECS gestisce i controlli sanitari per tuo conto. Amazon ECS usa le informazioni ottenute dal container e dai controlli dell'integrità, insieme allo stato dell'attività, per aggiornare l'integrità con AWS Cloud Map. Questo comportamento viene specificato tramite il parametro `--health-check-custom-config` durante la creazione del servizio di individuazione dei servizi. Per ulteriori informazioni, consulta [HealthCheckCustomConfig](https://docs.aws.amazon.com/cloud-map/latest/api/API_HealthCheckCustomConfig.html) nella *documentazione di riferimento dell’API AWS Cloud Map *.
+ Le AWS Cloud Map risorse create quando viene utilizzato il service discovery devono essere pulite manualmente.
+ Le attività e le istanze vengono registrate come `UNHEALTHY` fino a quando i controlli dell'integrità del container non restituiscono un valore. Se i controlli dell'integrità risultano positivi, lo stato viene aggiornato a `HEALTHY`. Se i controlli dell'integrità del container hanno esito negativo, la registrazione dell'istanza di rilevamento servizi viene annullata.

## Prezzi del servizio di individuazione dei servizi
<a name="service-discovery-pricing"></a>

I clienti che utilizzano l'individuazione dei servizi di Amazon ECS pagano per le risorse Route 53 e le operazioni API di individuazione AWS Cloud Map . Sono inclusi i costi per la creazione delle zone ospitate di Route 53 e per le query nel registro del servizio. Per ulteriori informazioni, consultare [Prezzi di AWS Cloud Map](https://docs.aws.amazon.com/cloud-map/latest/dg/cloud-map-pricing.html) nella *Guida per gli sviluppatori di AWS Cloud Map *.

Amazon ECS esegue controlli di integrità a livello di container e li espone a operazioni API di controllo dello stato AWS Cloud Map personalizzate. Questa opzione al momento viene fornita gratuitamente ai clienti. Se configuri controlli dell'integrità di rete aggiuntivi per le attività esposte pubblicamente, potrebbero esserti addebitati i relativi costi.

# Creazione di un servizio Amazon ECS che utilizza il rilevamento servizi.
<a name="create-service-discovery"></a>

Maggiori informazioni su come creare un servizio contenente un'attività Fargate che usa il rilevamento servizi con la AWS CLI.

Per un elenco delle scoperte di Regioni AWS tali servizi di supporto, consulta. [Usare il rilevamento servizi per connettere i servizi Amazon ECS con nomi DNS](service-discovery.md)

Per informazioni sulle regioni che supportano Fargate, consulta [Regioni supportate per Amazon ECS su Fargate AWS](AWS_Fargate-Regions.md).

**Nota**  
Puoi utilizzare gli endpoint del servizio dual-stack per interagire con Amazon ECS da AWS CLI, SDKs e l'API Amazon ECS su entrambi e. IPv4 IPv6 Per ulteriori informazioni, consulta [Utilizzo degli endpoint dual-stack Amazon ECS](dual-stack-endpoint.md).

## Prerequisiti
<a name="create-service-discovery-prereqs"></a>

Prima di iniziare questo tutorial, verifica che siano soddisfatti i seguenti requisiti preliminari:
+ La versione più recente di è installata e configurata. AWS CLI Per ulteriori informazioni, consultare [Installing or updating to the latest version of the AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html).
+ Le fasi descritte in [Configurazione per l'uso di Amazon ECS](get-set-up-for-amazon-ecs.md) sono complete.
+ L'utente IAM dispone delle autorizzazioni necessarie specificate nell'esempio di policy IAM [AmazonECS\$1 FullAccess](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonECS_FullAccess).
+ Hai creato almeno un VPC e un gruppo di sicurezza. Per ulteriori informazioni, consulta [Crea un cloud privato virtuale](get-set-up-for-amazon-ecs.md#create-a-vpc).

## Passaggio 1: creare le risorse di Service Discovery in AWS Cloud Map
<a name="create-service-discovery-namespace"></a>

Utilizza la procedura seguente per creare il namespace di individuazione dei servizi e il servizio di individuazione dei servizi.

1. Crea un namespace privato di individuazione dei servizi Cloud Map. In questo esempio viene creato un namespace denominato `tutorial`. Sostituisci *vpc-abcd1234* con l'ID di uno dei tuoi esistenti VPCs. 

   ```
   aws servicediscovery create-private-dns-namespace \
         --name tutorial \
         --vpc vpc-abcd1234
   ```

   L'output di questo comando è il seguente:

   ```
   {
       "OperationId": "h2qe3s6dxftvvt7riu6lfy2f6c3jlhf4-je6chs2e"
   }
   ```

1. Usando `OperationId` dall'output della fase precedente, verificare che il namespace privato sia stato creato correttamente. Annotare l'ID del namespace perché verrà utilizzato nei comandi successivi.

   ```
   aws servicediscovery get-operation \
         --operation-id h2qe3s6dxftvvt7riu6lfy2f6c3jlhf4-je6chs2e
   ```

   L'output è il seguente.

   ```
   {
       "Operation": {
           "Id": "h2qe3s6dxftvvt7riu6lfy2f6c3jlhf4-je6chs2e",
           "Type": "CREATE_NAMESPACE",
           "Status": "SUCCESS",
           "CreateDate": 1519777852.502,
           "UpdateDate": 1519777856.086,
           "Targets": {
              "NAMESPACE": "ns-uejictsjen2i4eeg"
           }
       }
   }
   ```

1. Usando l'ID `NAMESPACE` dall'output nella fase precedente, crea un servizio di individuazione dei servizi. Questo esempio crea un servizio denominato `myapplication`. Prendi nota dell'ID del servizio e dell'ARN perché li utilizzerai nei comandi successivi.

   ```
   aws servicediscovery create-service \
         --name myapplication \
         --dns-config "NamespaceId="ns-uejictsjen2i4eeg",DnsRecords=[{Type="A",TTL="300"}]" \
         --health-check-custom-config FailureThreshold=1
   ```

   L'output è il seguente.

   ```
   {
       "Service": {
          "Id": "srv-utcrh6wavdkggqtk",
           "Arn": "arn:aws:servicediscovery:region:aws_account_id:service/srv-utcrh6wavdkggqtk",
           "Name": "myapplication",
           "DnsConfig": {
               "NamespaceId": "ns-uejictsjen2i4eeg",
               "DnsRecords": [
                   {
                       "Type": "A",
                       "TTL": 300
                   }
               ]
           },
           "HealthCheckCustomConfig": {
               "FailureThreshold": 1
           },
           "CreatorRequestId": "e49a8797-b735-481b-a657-b74d1d6734eb"
       }
   }
   ```

## Fase 2: Creazione delle risorse Amazon ECS
<a name="create-service-discovery-cluster"></a>

Utilizza la procedura seguente per creare il cluster Amazon ECS, la definizione di attività e il servizio.

1. Crea un cluster Amazon ECS. In questo esempio viene creato un cluster denominato `tutorial`. 

   ```
   aws ecs create-cluster \
         --cluster-name tutorial
   ```

1. Registra una definizione di attività che sia compatibile con Fargate e utilizzi la modalità di rete `awsvpc`. Completare la procedura riportata di seguito.

   1. Crea un file denominato `fargate-task.json` con il contenuto della seguente definizione di attività.

      ```
      {
          "family": "tutorial-task-def",
              "networkMode": "awsvpc",
              "containerDefinitions": [
                  {
                      "name": "sample-app",
                      "image": "public.ecr.aws/docker/library/httpd:2.4",
                      "portMappings": [
                          {
                              "containerPort": 80,
                              "hostPort": 80,
                              "protocol": "tcp"
                          }
                      ],
                      "essential": true,
                      "entryPoint": [
                          "sh",
                          "-c"
                      ],
                      "command": [
                          "/bin/sh -c \"echo '<html> <head> <title>Amazon ECS Sample App</title> <style>body {margin-top: 40px; background-color: #333;} </style> </head><body> <div style=color:white;text-align:center> <h1>Amazon ECS Sample App</h1> <h2>Congratulations!</h2> <p>Your application is now running on a container in Amazon ECS.</p> </div></body></html>' >  /usr/local/apache2/htdocs/index.html && httpd-foreground\""
                      ]
                  }
              ],
              "requiresCompatibilities": [
                  "FARGATE"
              ],
              "cpu": "256",
              "memory": "512"
      }
      ```

   1. Registrazione della definizione dell'attività tramite `fargate-task.json`.

      ```
      aws ecs register-task-definition \
            --cli-input-json file://fargate-task.json
      ```

1. Crea un servizio ECS completando la seguente procedura:

   1. Creazione di un file denominato `ecs-service-discovery.json` con il contenuto del servizio ECS che stai per creare. Questo esempio usa la definizione di attività creata nella fase precedente. È obbligatorio l'uso di un parametro `awsvpcConfiguration` perché la definizione di attività di esempio usa la modalità di rete `awsvpc`. 

      Quando si crea il servizio ECS, specificare Fargate e la versione della piattaforma `LATEST` che supporta il rilevamento servizi. Quando viene creato il servizio di individuazione dei servizi in AWS Cloud Map , l'ARN restituito è `registryArn`. `securityGroups` e `subnets` devono appartenere al VPC utilizzato per creare il namespace Cloud Map. Puoi ottenere il gruppo di sicurezza e la sottorete IDs dalla console Amazon VPC.

      ```
      {
          "cluster": "tutorial",
          "serviceName": "ecs-service-discovery",
          "taskDefinition": "tutorial-task-def",
          "serviceRegistries": [
             {
                "registryArn": "arn:aws:servicediscovery:region:aws_account_id:service/srv-utcrh6wavdkggqtk"
             }
          ],
          "launchType": "FARGATE",
          "platformVersion": "LATEST",
          "networkConfiguration": {
             "awsvpcConfiguration": {
                "assignPublicIp": "ENABLED",
                "securityGroups": [ "sg-abcd1234" ],
                "subnets": [ "subnet-abcd1234" ]
             }
          },
          "desiredCount": 1
      }
      ```

   1. Crea il tuo servizio ECS utilizzando `ecs-service-discovery.json`.

      ```
      aws ecs create-service \
            --cli-input-json file://ecs-service-discovery.json
      ```

## Fase 3: Verifica Service Discovery in AWS Cloud Map
<a name="create-service-discovery-verify"></a>

Puoi verificare che sia stato creato tutto correttamente eseguendo una query sulle informazioni di individuazione dei servizi. Dopo aver configurato l'individuazione del servizio, puoi utilizzare le operazioni AWS Cloud Map API o effettuare una chiamata `dig` da un'istanza all'interno del tuo VPC. Completare la procedura riportata di seguito.

1. Usando l'ID servizio di individuazione dei servizi, elenca le istanze di individuazione dei servizi. Prendi nota dell'ID istanza (contrassegnato in grassetto) per la pulizia delle risorse. 

   ```
    aws servicediscovery list-instances \
          --service-id srv-utcrh6wavdkggqtk
   ```

   L'output è il seguente.

   ```
   {
       "Instances": [
           {
               "Id": "16becc26-8558-4af1-9fbd-f81be062a266",
               "Attributes": {
                   "AWS_INSTANCE_IPV4": "172.31.87.2"
                   "AWS_INSTANCE_PORT": "80", 
                   "AVAILABILITY_ZONE": "us-east-1a", 
                   "REGION": "us-east-1", 
                   "ECS_SERVICE_NAME": "ecs-service-discovery", 
                   "ECS_CLUSTER_NAME": "tutorial", 
                   "ECS_TASK_DEFINITION_FAMILY": "tutorial-task-def"
               }
           }
       ]
   }
   ```

1. Utilizza il namespace, il servizio di individuazione dei servizi e parametri aggiuntivi quali il nome del cluster ECS per ottenere i dettagli sulle istanze di individuazione dei servizi.

   ```
   aws servicediscovery discover-instances \
         --namespace-name tutorial \
         --service-name myapplication \
         --query-parameters ECS_CLUSTER_NAME=tutorial
   ```

1. Puoi eseguire query sui record DNS creati nella zona ospitata di Route 53 per il servizio di individuazione dei servizi con i seguenti comandi AWS CLI :

   1. Con l'ID del namespace, ottenere le informazioni sul namespace che includono l'ID della zona ospitata di Route 53.

      ```
      aws servicediscovery \
            get-namespace --id ns-uejictsjen2i4eeg
      ```

      L'output è il seguente.

      ```
      {
          "Namespace": {
              "Id": "ns-uejictsjen2i4eeg",
              "Arn": "arn:aws:servicediscovery:region:aws_account_id:namespace/ns-uejictsjen2i4eeg",
              "Name": "tutorial",
              "Type": "DNS_PRIVATE",
              "Properties": {
                   "DnsProperties": {
                      "HostedZoneId": "Z35JQ4ZFDRYPLV"
                  }
              },
              "CreateDate": 1519777852.502,
              "CreatorRequestId": "9049a1d5-25e4-4115-8625-96dbda9a6093"
          }
      }
      ```

   1. Utilizzando l'ID della zona ospitata di Route 53 dalla fase precedente (visualizza il testo in grassetto), ottieni il set di record delle risorse per la zona ospitata. 

      ```
      aws route53 list-resource-record-sets \
            --hosted-zone-id Z35JQ4ZFDRYPLV
      ```

1. Puoi eseguire query sul DNS anche da un'istanza all'interno tramite `dig`.

   ```
   dig +short myapplication.tutorial
   ```

## Fase 4: pulizia
<a name="create-service-discovery-cleanup"></a>

Una volta terminato questo tutorial, elimina le risorse associate in modo da evitare costi aggiuntivi per le risorse non utilizzate. Completare la procedura riportata di seguito.

1. Annulla la registrazione delle istanze del servizio di individuazione dei servizi utilizzando l'ID servizio e l'ID istanza annotati in precedenza.

   ```
   aws servicediscovery deregister-instance \
         --service-id srv-utcrh6wavdkggqtk \
         --instance-id 16becc26-8558-4af1-9fbd-f81be062a266
   ```

   L'output è il seguente.

   ```
   {
       "OperationId": "xhu73bsertlyffhm3faqi7kumsmx274n-jh0zimzv"
   }
   ```

1. Utilizzando l'`OperationId` dall'output della fase precedente, verifica che la registrazione delle istanze del servizio di individuazione dei servizi sia stata annullata correttamente.

   ```
   aws servicediscovery get-operation \ 
         --operation-id xhu73bsertlyffhm3faqi7kumsmx274n-jh0zimzv
   ```

   ```
   {
     "Operation": {
           "Id": "xhu73bsertlyffhm3faqi7kumsmx274n-jh0zimzv",
           "Type": "DEREGISTER_INSTANCE",
           "Status": "SUCCESS",
           "CreateDate": 1525984073.707,
           "UpdateDate": 1525984076.426,
           "Targets": {
               "INSTANCE": "16becc26-8558-4af1-9fbd-f81be062a266",
               "ROUTE_53_CHANGE_ID": "C5NSRG1J4I1FH",
               "SERVICE": "srv-utcrh6wavdkggqtk"
           }
       }
   }
   ```

1. Eliminazione del servizio di individuazione dei servizi utilizzando l'ID servizio.

   ```
   aws servicediscovery delete-service \ 
         --id srv-utcrh6wavdkggqtk
   ```

1. Eliminazione del namespace di rilevamento servizi utilizzando l'ID del namespace.

   ```
   aws servicediscovery delete-namespace \ 
         --id ns-uejictsjen2i4eeg
   ```

   L'output è il seguente.

   ```
   {
       "OperationId": "c3ncqglftesw4ibgj5baz6ktaoh6cg4t-jh0ztysj"
   }
   ```

1. Usando l'`OperationId` dall'output della fase precedente, verificare che il namespace di rilevamento servizi sia stato eliminato correttamente.

   ```
   aws servicediscovery get-operation \ 
         --operation-id c3ncqglftesw4ibgj5baz6ktaoh6cg4t-jh0ztysj
   ```

   L'output è il seguente.

   ```
   {
       "Operation": {
           "Id": "c3ncqglftesw4ibgj5baz6ktaoh6cg4t-jh0ztysj",
           "Type": "DELETE_NAMESPACE",
           "Status": "SUCCESS",
           "CreateDate": 1525984602.211,
           "UpdateDate": 1525984602.558,
           "Targets": {
               "NAMESPACE": "ns-rymlehshst7hhukh",
               "ROUTE_53_CHANGE_ID": "CJP2A2M86XW3O"
           }
       }
   }
   ```

1. Aggiorna il conteggio desiderato per il servizio Amazon ECS a `0`. Questa operazione deve essere eseguita per eliminare il servizio nella fase successiva.

   ```
   aws ecs update-service \
         --cluster tutorial \
         --service ecs-service-discovery \
         --desired-count 0
   ```

1. Elimina il servizio Amazon ECS.

   ```
   aws ecs delete-service \
         --cluster tutorial \
         --service ecs-service-discovery
   ```

1. Elimina il cluster Amazon ECS.

   ```
   aws ecs delete-cluster \
         --cluster tutorial
   ```

# Usa Amazon VPC Lattice per connettere, osservare e proteggere i tuoi servizi Amazon ECS
<a name="ecs-vpc-lattice"></a>

Amazon VPC Lattice è un servizio di rete di applicazioni completamente gestito che consente ai clienti di Amazon ECS di osservare, proteggere e monitorare le applicazioni create su servizi di AWS elaborazione e account VPCs, senza richiedere alcuna modifica al codice.

VPC Lattice utilizza gruppi di destinazione che sono una raccolta di risorse di calcolo. Questi obiettivi eseguono l'applicazione o il servizio e possono essere istanze Amazon EC2, indirizzi IP, funzioni Lambda e Application Load Balancer. Associando i propri servizi Amazon ECS a un gruppo di destinazione di VPC Lattice, i clienti possono ora abilitare le attività Amazon ECS come destinazioni IP in VPC Lattice. Quando vengono avviate le attività per il servizio registrato, Amazon ECS le registra automaticamente nel gruppo di destinazione di VPC Lattice.

**Nota**  
Quando si utilizzano cinque configurazioni di VPC Lattice, il tempo di implementazione potrebbe essere leggermente più lungo rispetto a quando si utilizzano meno configurazioni.

Una regola del listener viene utilizzata per inoltrare il traffico a un gruppo di destinazione specifico quando le condizioni sono soddisfatte. Un listener verifica le richieste di connessione utilizzando il protocollo sulla porta configurata. Un servizio instrada le richieste verso i suoi obiettivi registrati in base alle regole definite al momento della configurazione del listener.

Inoltre, Amazon ECS sostituisce automaticamente un'attività anche se diventa non integra in base ai controlli dell'integrità di VPC Lattice. Una volta associati a VPC Lattice, i clienti Amazon ECS possono anche sfruttare molte altre funzionalità di connettività, sicurezza e osservabilità cross-computing di VPC Lattice, come la connessione a servizi tra cluster e account con integrazione IAM per l'autorizzazione e l' VPCsautenticazione e funzionalità avanzate di AWS Resource Access Manager gestione del traffico.

I clienti di Amazon ECS possono trarre vantaggio da VPC Lattice nei modi seguenti:
+ Maggiore produttività degli sviluppatori: VPC Lattice aumenta la produttività degli sviluppatori consentendo loro di concentrarsi sulla creazione di funzionalità, mentre VPC Lattice gestisce le sfide di rete, sicurezza e osservabilità in modo uniforme su tutte le piattaforme di elaborazione.
+ Migliore livello di sicurezza: VPC Lattice consente agli sviluppatori di autenticare e proteggere facilmente la comunicazione tra applicazioni e piattaforme di calcolo, applicare la crittografia in transito e applicare controlli di accesso granulari con le policy di autenticazione di VPC Lattice. Ciò consente di adottare una postura di sicurezza più solida che soddisfa i principali requisiti normativi e di conformità del settore.
+ Migliore scalabilità e resilienza delle applicazioni: VPC Lattice consente di creare una rete di applicazioni implementate con funzionalità come autorizzazione, autenticazione, monitoraggio e instradamento basati su percorsi, intestazioni e metodi. Questi vantaggi vengono forniti senza sovraccarico di risorse sui carichi di lavoro e possono supportare implementazioni multi-cluster che generano milioni di richieste al secondo senza aggiungere latenza significativa.
+ Flessibilità di implementazione con infrastruttura eterogenea: VPC Lattice offre funzionalità coerenti in tutti i servizi di calcolo come Amazon ECS, Fargate, Amazon EC2, Amazon EKS e Lambda, e consente all'organizzazione la flessibilità di scegliere l'infrastruttura adatta per ogni applicazione.

## Come funziona VPC Lattice con altri servizi Amazon ECS
<a name="ecs-lattice-compatibility"></a>

L'uso di VPC Lattice con Amazon ECS può cambiare la modalità di utilizzo di altri servizi Amazon ECS, mentre altri rimangono invariati.

**Application Load Balancer**  
Non è più necessario creare un Application Load Balancer specifico da utilizzare con il tipo di gruppo di destinazione Application Load Balancer in VPC Lattice che poi si collega al servizio Amazon ECS. È solo necessario configurare il servizio Amazon ECS con un gruppo di destinazione VPC Lattice. È anche possibile scegliere di utilizzare Application Load Balancer con Amazon ECS contemporaneamente.

**Implementazioni in sequenza di Amazon ECS**  
Solo le implementazioni in sequenza di Amazon ECS funzionano con VPC Lattice, e Amazon ECS inserisce le attività in modo sicuro e le rimuove dai servizi durante l'implementazione. La distribuzione e le distribuzioni del codice non sono supportate. Blue/Green 

Per saperne di più su VPC Lattice, consultare [Amazon VPC Lattice User Guide](https://docs.aws.amazon.com/vpc-lattice/latest/ug/what-is-vpc-lattice.html).

# Crea un servizio che utilizza VPC Lattice
<a name="ecs-vpc-lattice-create-service"></a>

È possibile utilizzare Console di gestione AWS o il AWS CLI per creare un servizio con VPC Lattice.

## Prerequisiti
<a name="create-ecs-vpc-lattice-prereqs"></a>

Prima di iniziare questo tutorial, verifica che siano soddisfatti i seguenti requisiti preliminari:
+ La versione più recente di AWS CLI è installata e configurata. Per ulteriori informazioni, consultare [Installing the AWS Command Line Interface](https://docs.aws.amazon.com/cli/latest/userguide/install-cliv2.html).
**Nota**  
Puoi utilizzare gli endpoint del servizio dual-stack per interagire con Amazon ECS da AWS CLI, SDKs e l'API Amazon ECS su entrambi e. IPv4 IPv6 Per ulteriori informazioni, consulta [Utilizzo degli endpoint dual-stack Amazon ECS](dual-stack-endpoint.md).
+ Le fasi descritte in [Configurazione per l'uso di Amazon ECS](get-set-up-for-amazon-ecs.md) sono complete.
+ L'utente IAM dispone delle autorizzazioni necessarie specificate nell'esempio di policy IAM [AmazonECS\$1 FullAccess](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonECS_FullAccess).

## Crea un servizio che utilizza VPC Lattice con Console di gestione AWS
<a name="ecs-lattice-create-console"></a>

Seguire questi passaggi per creare un servizio con VPC Lattice utilizzando Console di gestione AWS.

1. [Apri la console alla v2. https://console.aws.amazon.com/ecs/](https://console.aws.amazon.com/ecs/v2)

1. Nella pagina di navigazione, scegli **Cluster**.

1. Nella pagina **Cluster**, scegliere il cluster in cui creare il servizio.

1. Nella scheda **Servizi**, scegliere **Crea**.

   Se non è mai stato creato un servizio in precedenza, seguire i passaggi riportati in [Creazione di un servizio Amazon ECS utilizzando la console](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/create-service-console-v2.html), poi continuare con questi passaggi quando si raggiunge la sezione relativa a VPC Lattice.

1. Scegliere **Attiva VPC Lattice** selezionando il pulsante.

1. Per utilizzare un ruolo esistente, per **Ruolo di infrastruttura ECS per Amazon ECS**, sceglierne uno già creato da utilizzare durante la creazione del gruppo di destinazione VPC Lattice. Per creare un nuovo ruolo, **Crea ruolo di infrastruttura ECS**.

1. Scegliere il **VPC**.

   Il **VPC** dipende dalla modalità di rete selezionata al momento della registrazione della definizione dell'attività. Se si utilizza la modalità `host` o `network` con EC2, scegliere il VPC. 

   Per la modalità `awsvpc`, il VPC viene selezionato automaticamente in base al VPC scelto in **Rete** e non può essere modificato.

1. In **Gruppi di destinazione**, scegliere il gruppo o i gruppi di destinazione. È necessario scegliere un gruppo di destinazione compreso tra 1 e 5. Scegliere **Aggiungi gruppo di destinazione** per aggiungere altri gruppi di destinazione. Scegliere il **Nome della porta**, il **Protocollo** e la **Porta** per ogni gruppo di destinazione scelto. Per rimuovere un gruppo di destinazione, scegliere **Rimuovi**.
**Nota**  
Se si desidera aggiungere gruppi di destinazione esistenti, è necessario usare la AWS CLI. *Per istruzioni su come aggiungere gruppi target utilizzando il AWS CLI, consulta [register-targets](https://docs.aws.amazon.com/cli/latest/reference/vpc-lattice/register-targets.html) nella Guida di riferimento. AWS Command Line Interface *
Sebbene un servizio VPC Lattice possa essere collegato a più gruppi di destinazione, un gruppo di destinazione può essere aggiunto solo a un singolo servizio.
Per creare un servizio in una configurazione IPv6 -only, scegli i gruppi di destinazione con un tipo di indirizzo IP di. `IPv6`

1. A questo punto, accedere alla console VPC Lattice per continuare la configurazione. È qui che si includono i nuovi gruppi di destinazione nell'azione predefinita del listener o nelle regole di un servizio VPC Lattice esistente. 

   Per ulteriori informazioni, consultare [Listener rules for your VPC Lattice service](https://docs.aws.amazon.com/vpc-lattice/latest/ug/listener-rules.html).

**Importante**  
È necessario consentire il prefisso `vpc-lattice` della regola in entrata per il gruppo o le attività di sicurezza e i controlli di integrità possono avere esito negativo. 

## Crea un servizio che utilizza VPC Lattice con AWS CLI
<a name="ecs-lattice-create-cli"></a>

Usa AWS CLI per creare un servizio con VPC Lattice. Sostituisci ogni *user input placeholder* con le tue informazioni.

1. Creazione di un file di configurazione del gruppo di destinazione. L'esempio seguente è denominato `tg-config.json`

   ```
   {
       "ipAddressType": "IPV4",
       "port": 443,
       "protocol": "HTTPS",
       "protocolVersion": "HTTP1",
       "vpcIdentifier": "vpc-f1663d9868EXAMPLE"
   }
   ```

1. Utilizzare il seguente comando per creare un gruppo di destinazione di VPC Lattice.

   ```
   aws vpc-lattice create-target-group \
       --name my-lattice-target-group-ip \
       --type IP \
       --config file://tg-config.json
   ```
**Nota**  
Per creare un servizio in una configurazione IPv6 solo, crea gruppi target con un tipo di indirizzo IP di. `IPv6` Per ulteriori informazioni, consulta [create-target-group](https://docs.aws.amazon.com/cli/latest/reference/vpc-lattice/create-target-group.html) nella *documentazione di riferimento dei comandi della AWS CLI *.

   Output di esempio:

   ```
   {
       "arn": "arn:aws:vpc-lattice:us-east-2:123456789012:targetgroup/tg-0eaa4b9ab4EXAMPLE",
       "config": {
           "healthCheck": {
               "enabled": true,
               "healthCheckIntervalSeconds": 30,
               "healthCheckTimeoutSeconds": 5,
               "healthyThresholdCount": 5,
               "matcher": {
                   "httpCode": "200"
               },
               "path": "/",
               "protocol": "HTTPS",
               "protocolVersion": "HTTP1",
               "unhealthyThresholdCount": 2
           },
           "ipAddressType": "IPV4",
           "port": 443,
           "protocol": "HTTPS",
           "protocolVersion": "HTTP1",
           "vpcIdentifier": "vpc-f1663d9868EXAMPLE"
       },
       "id": "tg-0eaa4b9ab4EXAMPLE",
       "name": "my-lattice-target-group-ip",
       "status": "CREATE_IN_PROGRESS",
       "type": "IP"
   }
   ```

1. Il seguente file JSON denominato *ecs-service-vpc-lattice.json* è un esempio utilizzato per collegare un servizio Amazon ECS a un gruppo target VPC Lattice. Il `portName` nell'esempio seguente è quello definito nel campo `name` delle proprietà `portMappings` della definizione dell'attività.

   ```
   {
       "serviceName": "ecs-service-vpc-lattice",
       "taskDefinition": "ecs-task-def",
           "vpcLatticeConfigurations": [
           {
               "targetGroupArn": "arn:aws:vpc-lattice:us-west-2:123456789012:targetgroup/tg-0eaa4b9ab4EXAMPLE",
               "portName": "testvpclattice",
               "roleArn": "arn:aws:iam::123456789012:role/ecsInfrastructureRoleVpcLattice"
           }
       ],
       "desiredCount": 5,
       "role": "ecsServiceRole"
   }
   ```

   Utilizzare il seguente comando per creare un servizio Amazon ECS e collegarlo al gruppo di destinazione VPC Lattice utilizzando l'esempio json sopra riportato.

   ```
   aws ecs create-service \
       --cluster clusterName \
       --serviceName ecs-service-vpc-lattice \
       --cli-input-json file://ecs-service-vpc-lattice.json
   ```

**Nota**  
VPC Lattice non è supportato in Amazon ECS Anywhere.

# Proteggere le attività di Amazon ECS dall'interruzione causata da eventi di riduzione orizzontale
<a name="task-scale-in-protection"></a>

La protezione scalabile di Amazon ECS consente di proteggere le attività dall'interruzione da parte di eventi di riduzione orizzontale derivanti da scalabilità automatica del servizio o implementazioni varie.

Alcune applicazioni richiedono un meccanismo per salvaguardare le attività strategiche dall'interruzione dovuta a eventi scalabili nei periodi di scarso utilizzo o durante le implementazioni dei servizi. Esempio:
+ Si tratta di un'applicazione asincrona di elaborazione delle code, ad esempio un processo di transcodifica video in cui alcune attività devono essere eseguite per ore anche quando l'utilizzo cumulativo del servizio è basso.
+ Si dispone di un'applicazione di gioco che esegue i server di gioco come attività di Amazon ECS che devono continuare a funzionare anche se tutti gli utenti si sono disconnessi per ridurre la latenza di avvio di un riavvio del server.
+ Quando si implementa una nuova versione del codice, è necessario che le attività continuino a essere eseguite perché sarebbe costoso rielaborarle.

Per evitare che le attività appartenenti al servizio vengano terminate in caso di un evento di dimensionamento, imposta l'attributo `ProtectionEnabled` su `true`. Quando si imposta `ProtectionEnabled` su true, le attività vengono protette per 2 ore per impostazione predefinita. Poi è possibile personalizzare il periodo di protezione utilizzando l'attributo `ExpiresInMinutes`. Puoi proteggere le tue attività per un minimo di 1 minuto e fino a un massimo di 2.880 minuti (48 ore). Se stai utilizzando AWS CLI, puoi specificare l'opzione. `--protection-enabled`

Dopo che un'attività ha terminato il lavoro richiesto, sarà possibile impostare l'attributo `ProtectionEnabled` su `false`, in modo che l'attività venga terminata da successivi eventi di scalabilità. Se si utilizza il AWS CLI, è possibile specificare l'`--no-protection-enabled`opzione.

## Meccanismi di protezione scalabile delle attività
<a name="task-scale-in-protection-mechanisms"></a>

Puoi impostare e ottenere una protezione scalabile delle attività utilizzando l'endpoint dell'agente container Amazon ECS o l'API Amazon ECS.
+ **Endpoint dell'agente del container Amazon ECS**

  Consigliamo di utilizzare l'endpoint dell'agente container Amazon ECS per attività che possono determinare autonomamente la necessità di essere protette. Utilizza questo approccio per carichi di lavoro basati su code o di elaborazione dei processi

  Quando un container inizia il lavoro di elaborazione, ad esempio consumando un messaggio SQS, è possibile impostare l'attributo `ProtectionEnabled` tramite il percorso dell'endpoint di protezione scalabile dell'attività `$ECS_AGENT_URI/task-protection/v1/state` dall'interno del container. Amazon ECS non terminerà questa attività durante gli eventi di scalabilità. Al termine dell'attività, è possibile annullare l'attributo `ProtectionEnabled` utilizzando lo stesso endpoint, rendendo l'attività idonea all'interruzione durante i successivi eventi di scalabilità.

  Per ulteriori informazioni sull'endpoint dell'agente del container Amazon ECS, consultare [Endpoint di protezione scalabile di Amazon ECS](task-scale-in-protection-endpoint.md).
+ **API Amazon ECS**

  È possibile utilizzare l'API Amazon ECS per impostare e recuperare la protezione scalabile delle attività se l'applicazione dispone di un componente che tiene traccia dello stato delle attività attive. Utilizzare `UpdateTaskProtection` per contrassegnare una o più attività come protette. Utilizzare `GetTaskProtection` per recuperare lo stato di protezione.

  Un esempio di questo approccio potrebbe essere se l'applicazione ospita sessioni del server di gioco come attività Amazon ECS. Quando un utente accede a una sessione sul server (attività), è possibile contrassegnare l'attività come protetta. Dopo la disconnessione dell'utente, puoi annullare la protezione specifica per l'attività o annullare periodicamente la protezione per attività simili che non hanno più sessioni attive, a seconda se è necessario mantenere i server inattivi.

  Per ulteriori informazioni, consulta [UpdateTaskProtection](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateTaskProtection.html)e consulta il *riferimento [GetTaskProtection](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_GetTaskProtection.html)all'API di Amazon Elastic Container Service*.

È possibile combinare entrambi gli approcci. Ad esempio, utilizza l'endpoint dell'agente Amazon ECS per impostare la protezione delle attività dall'interno di un container e utilizza l'API Amazon ECS per rimuovere la protezione delle attività dal servizio di controller esterno.

## Considerazioni
<a name="task-scale-in-protection-considerations"></a>

Considera i seguenti punti prima di utilizzare la protezione scalabile delle attività:
+ La protezione scalabile è supportata solo con le attività implementate da un servizio.
+ La protezione scalabile è supportata con attività implementate da un servizio in esecuzione su istanze gestite da Amazon ECS.
+ Ti consigliamo di utilizzare l'endpoint dell'agente del container Amazon ECS, in quanto l'agente Amazon ECS dispone di meccanismi di ripetizione integrati e di un'interfaccia più semplice.
+ Puoi reimpostare il periodo di scadenza della protezione per il dimensionamento delle attività richiamando `UpdateTaskProtection` su un'attività che ha già la protezione attivata.
+ Determina il tempo necessario a un'attività per completare il lavoro richiesto e imposta la proprietà `expiresInMinutes` di conseguenza. Se imposti la scadenza della protezione più a lungo del necessario, dovrai sostenere costi e ritardi nell'implementazione di nuove attività.
+ La protezione per il dimensionamento delle attività è supportata sull'agente del container Amazon ECS `1.65.0` o versioni successive. Questa caratteristica può essere supportata sulle istanze Amazon EC2 utilizzando versioni precedenti dell'agente di container Amazon ECS aggiornando l'agente alla versione più recente. Per ulteriori informazioni, consultare [Aggiornamento dell'agente del container Amazon ECS](ecs-agent-update.md).
+ Considerazioni sull'implementazione:
  + Se il servizio utilizza un aggiornamento in sequenza, verranno create nuove attività ma le attività che eseguono una versione precedente non verranno interrotte fino a quando `protectionEnabled` non viene annullato o scade. È possibile regolare il parametro `maximumPercentage` nella configurazione di implementazione su un valore che consenta di creare nuove attività quando le vecchie attività sono protette.
  + Se viene applicato un blue/green aggiornamento, la distribuzione blu con attività protette non verrà rimossa se le attività lo hanno fatto`protectionEnabled`. Il traffico verrà deviato verso le nuove attività che si presentano e le attività più vecchie verranno rimosse solo quando la `protectionEnabled` viene eliminata o scade. A seconda del timeout degli CloudFormation aggiornamenti, la CodeDeploy distribuzione potrebbe scadere e le attività Blue precedenti potrebbero essere ancora presenti.
  + Se lo utilizzi CloudFormation, lo update-stack ha un timeout di 3 ore. Pertanto, se imposti la protezione delle attività per più di 3 ore, la CloudFormation distribuzione potrebbe causare errori e ripristini.

    Durante il periodo in cui le vecchie attività sono protette, lo CloudFormation stack viene visualizzato. `UPDATE_IN_PROGRESS` Se la protezione per il dimensionamento delle attività viene rimossa o scade entro la finestra di 3 ore, l'implementazione avrà esito positivo e passerà allo stato `UPDATE_COMPLETE`. Se l'implementazione rimane bloccata in `UPDATE_IN_PROGRESS` per più di 3 ore, non riuscirà e mostrerà lo stato `UPDATE_FAILED`, quindi verrà ripristinato il vecchio set di attività.
  + Amazon ECS invia gli eventi di servizio se le attività protette impediscono a un'implementazione (in sequenza o blu/verde) di raggiungere lo stato stazionario, in modo che sia possibile intraprendere azioni correttive. Durante il tentativo di aggiornare lo stato di protezione di un'attività, se viene ricevuto un messaggio di errore `DEPLOYMENT_BLOCKED`, allora significa che il servizio ha più attività protette rispetto al numero di attività desiderato per il servizio. Per risolvere questo errore, effettuare una delle seguenti operazioni:
    + Attendi la scadenza della protezione dell'attività corrente. Quindi imposta la protezione delle attività.
    + Determina quali attività possono essere arrestate. Quindi, usa `UpdateTaskProtection` con l'opzione `protectionEnabled` impostata su `false` per queste attività.
    + Aumenta il numero di attività desiderate del servizio portandolo a un numero maggiore del numero di attività protette.

## Autorizzazioni IAM richieste per la protezione scalabile delle attività
<a name="task-scale-in-protection-iam"></a>

L'attività deve avere il ruolo di attività Amazon ECS con le seguenti autorizzazioni:
+ `ecs:GetTaskProtection`: consente all'agente del container Amazon ECS di effettuare chiamate `GetTaskProtection`.
+ `ecs:UpdateTaskProtection`: consente all'agente del container Amazon ECS di effettuare chiamate `UpdateTaskProtection`.

# Endpoint di protezione scalabile di Amazon ECS
<a name="task-scale-in-protection-endpoint"></a>

L'agente del container Amazon ECS inserisce automaticamente la variabile di ambiente `ECS_AGENT_URI` nei container delle attività di Amazon ECS per fornire un metodo per interagire con l'endpoint API dell'agente del container.

Consigliamo di utilizzare l'endpoint dell'agente container Amazon ECS per attività che possono determinare autonomamente la necessità di essere protette. 

Quando un container inizia il lavoro di elaborazione, è possibile impostare l'attributo `protectionEnabled` tramite il percorso dell'endpoint di protezione scalabile dell'attività `$ECS_AGENT_URI/task-protection/v1/state` dall'interno del container. 

Usare una richiesta PUT in questo URI dall'interno di un container per impostare la protezione scalabile. Una richiesta GET a questo URI restituisce lo stato di protezione attuale di un'attività.

## Parametri di richiesta di protezione scalabile
<a name="task-scale-in-protection-request"></a>

È possibile impostare la protezione scalabile delle attività utilizzando l'endpoint `${ECS_AGENT_URI}/task-protection/v1/state` con i seguenti parametri di richiesta.

`ProtectionEnabled`  
Specificare `true` per contrassegnare un'attività per la protezione. Specificare `false` per rimuovere la protezione e rendere l'attività idonea per l'interruzione.  
Tipo: Booleano  
Obbligatorio: sì

`ExpiresInMinutes`  
Il numero di minuti in cui l'attività è protetta. È possibile specificare da un minimo di 1 minuto a un massimo di 2.880 minuti (48 ore). Durante questo periodo di tempo, l'attività non verrà terminata da eventi di dimensionamento derivanti dal servizio Dimensionamento automatico o dalle implementazioni. Trascorso questo periodo di tempo, il parametro `protectionEnabled` viene impostato su `false`.  
Se non si specifica l'ora, l'attività viene protetta automaticamente per 120 minuti (2 ore).  
Tipo: Integer  
Obbligatorio: no

Gli esempi seguenti mostrano come impostare la protezione delle attività con durate diverse.

**Esempio di come proteggere un'attività con il periodo di tempo predefinito**

Questo esempio mostra come proteggere un'attività con il periodo di tempo predefinito di 2 ore.

```
curl --request PUT --header 'Content-Type: application/json' ${ECS_AGENT_URI}/task-protection/v1/state --data '{"ProtectionEnabled":true}'
```

**Esempio di protezione di un'attività per 60 minuti**

Questo esempio mostra come proteggere un'attività per 60 minuti utilizzando il parametro `expiresInMinutes`.

```
curl --request PUT --header 'Content-Type: application/json' ${ECS_AGENT_URI}/task-protection/v1/state --data '{"ProtectionEnabled":true,"ExpiresInMinutes":60}'      
```

**Esempio di protezione di un'attività per 24 ore**

Questo esempio mostra come proteggere un'attività per 24 ore utilizzando il parametro `expiresInMinutes`.

```
curl --request PUT --header 'Content-Type: application/json' ${ECS_AGENT_URI}/task-protection/v1/state --data '{"ProtectionEnabled":true,"ExpiresInMinutes":1440}'      
```

**Esempi di container Windows**

Per i contenitori Windows, è possibile utilizzare PowerShell il `Invoke-RestMethod` cmdlet anziché curl. Gli esempi seguenti mostrano gli PowerShell equivalenti dei precedenti comandi curl.

**Esempio di come proteggere un'attività del container di Windows con il periodo di tempo predefinito**

Questo esempio mostra come proteggere un'attività con il periodo di tempo predefinito di 2 ore utilizzando. PowerShell

```
Invoke-RestMethod -Uri $env:ECS_AGENT_URI/task-protection/v1/state -Method Put -Body '{"ProtectionEnabled":true}' -ContentType 'application/json'
```

**Esempio di come proteggere un'attività del container di Windows per 60 minuti**

Questo esempio mostra come proteggere un'attività per 60 minuti utilizzando il `expiresInMinutes` parametro with PowerShell.

```
Invoke-RestMethod -Uri $env:ECS_AGENT_URI/task-protection/v1/state -Method Put -Body '{"ProtectionEnabled":true,"ExpiresInMinutes":60}' -ContentType 'application/json'
```

**Esempio di come proteggere un'attività del container di Windows per 24 ore**

Questo esempio mostra come proteggere un'attività per 24 ore utilizzando il `expiresInMinutes` parametro with PowerShell.

```
Invoke-RestMethod -Uri $env:ECS_AGENT_URI/task-protection/v1/state -Method Put -Body '{"ProtectionEnabled":true,"ExpiresInMinutes":1440}' -ContentType 'application/json'
```

La richiesta PUT restituisce la risposta seguente:

```
{
  "protection": {
    "ExpirationDate": "2023-12-20T21:57:44.837Z",
    "ProtectionEnabled": true,
    "TaskArn": "arn:aws:ecs:us-west-2:111122223333:task/1234567890abcdef0"
  }
}
```

## Parametri di risposta della protezione scalabile
<a name="task-scale-in-protection-response"></a>

La risposta in formato JSON dell'endpoint di protezione per il dimensionamento delle attività `${ECS_AGENT_URI}/task-protection/v1/state` restituisce le seguenti informazioni.

`ExpirationDate`  
L'ora in cui scadrà la protezione per l'attività. Se l'attività non è protetta, questo valore è nullo.

`ProtectionEnabled`  
Lo stato di protezione dell'attività. Se la protezione scalabile è abilitata per un'attività, il valore è `true`. In caso contrario è `false`.

`TaskArn`  
L'Amazon Resource Name (ARN) completo dell'attività a cui appartiene il container.

L'esempio che segue mostra i dettagli restituiti per un'attività protetta.

```
curl --request GET ${ECS_AGENT_URI}/task-protection/v1/state
```

Per i contenitori Windows, utilizzate il seguente PowerShell comando per ottenere lo stato di protezione:

```
Invoke-RestMethod -Uri $env:ECS_AGENT_URI/task-protection/v1/state -Method Get
```

```
{
    "protection":{
        "ExpirationDate":"2023-12-20T21:57:44Z",
        "ProtectionEnabled":true,
        "TaskArn":"arn:aws:ecs:us-west-2:111122223333:task/1234567890abcdef0"
    }
}
```

Le seguenti informazioni vengono restituite quando si verifica un errore.

`Arn`  
Il nome della risorsa Amazon (ARN) completo dell'attività.

`Detail`  
I dettagli relativi all'errore.

`Reason`  
Il motivo dell’errore.

L'esempio che segue mostra i dettagli restituiti per un'attività che non è protetta.

```
{
    "failure":{
        "Arn":"arn:aws:ecs:us-west-2:111122223333:task/1234567890abcdef0",
        "Detail":null,
        "Reason":"TASK_NOT_VALID"
    }
}
```

Le seguenti informazioni vengono restituite quando si verifica un'eccezione.

`requestID`  
L'ID della AWS richiesta per la chiamata API Amazon ECS che genera un'eccezione.

`Arn`  
Il nome della risorsa Amazon (ARN) completo dell'attività o del servizio.

`Code`  
Il codice di errore.

`Message`  
Messaggio di errore.  
Se viene visualizzato un errore `RequestError` o `RequestTimeout`, è probabile che si tratti di un problema di rete. Prova a utilizzare gli endpoint VPC per Amazon ECS.

L'esempio che segue mostra i dettagli restituiti quando si verifica un errore.

```
{
    "requestID":"12345-abc-6789-0123-abc",
    "error":{
        "Arn":"arn:aws:ecs:us-west-2:555555555555:task/my-cluster-name/1234567890abcdef0",
        "Code":"AccessDeniedException",
        "Message":"User: arn:aws:sts::444455556666:assumed-role/my-ecs-task-role/1234567890abcdef0 is not authorized to perform: ecs:GetTaskProtection on resource: arn:aws:ecs:us-west-2:555555555555:task/test/1234567890abcdef0 because no identity-based policy allows the ecs:GetTaskProtection action"
    }    
}
```

L'errore seguente viene visualizzato se l'agente Amazon ECS non è in grado di ottenere una risposta dall'endpoint Amazon ECS per motivi quali problemi di rete o il piano di controllo Amazon ECS inattivo.

```
{
  "error": {
    "Arn": "arn:aws:ecs:us-west-2:555555555555:task/my-cluster-name/1234567890abcdef0",
    "Code": "RequestCanceled",
    "Message": "Timed out calling Amazon ECS Task Protection API"
  }
}
```

Il seguente errore si verifica quando l'agente Amazon ECS riceve un'eccezione di limitazione da Amazon ECS.

```
{
  "requestID": "12345-abc-6789-0123-abc",
  "error": {
    "Arn": "arn:aws:ecs:us-west-2:555555555555:task/my-cluster-name/1234567890abcdef0",
    "Code": "ThrottlingException",
    "Message": "Rate exceeded"
  }
}
```

# Utilizzare l'iniezione di guasti con i carichi di lavoro Amazon ECS e Fargate.
<a name="fault-injection"></a>

I clienti possono utilizzare l'iniezione di guasti con Amazon ECS sia su Amazon EC2 che su Fargate per testare la risposta della loro applicazione a determinati scenari di compromissione. Questi test forniscono informazioni da utilizzare per ottimizzare le prestazioni e la resilienza dell'applicazione.

Quando l'iniezione di guasti è abilitata, l'agente del container Amazon ECS consente alle attività di accedere a nuovi endpoint di iniezione dei guasti. È necessario attivare il consenso per utilizzare l'iniezione di guasti impostando il valore del parametro di definizione dell'attività `enableFaultInjection` su `true`. Il valore predefinito è `false`. 

```
{
    ...
   "enableFaultInjection": true
}
```

**Nota**  
L'iniezione di guasti funziona solo con le attività che utilizzano le modalità di rete `awsvpc` o `host`.  
L'iniezione di guasti non è disponibile in Windows.

Per informazioni su come abilitare l'iniezione di errori in Console di gestione AWS, consulta [Creazione di una definizione di attività Amazon ECS utilizzando la console](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/create-task-definition.html).

Sarà necessario abilitare la funzionalità per il test in AWS Fault Injection Service. Per ulteriori informazioni, consulta [Utilizzare le azioni AWS FIS aws:ecs:task](https://docs.aws.amazon.com/fis/latest/userguide/ecs-task-actions.html).

**Nota**  
Se non usi il nuovo Amazon ECS ottimizzato AMIs o disponi di un'AMI personalizzata, installa le seguenti dipendenze:  
`tc`
Modulo kernel `sch_netem`

# Endpoint di iniezione di guasti di Amazon ECS
<a name="fault-injection-endpoints"></a>

L'agente del container Amazon ECS inserisce automaticamente la variabile di ambiente `ECS_AGENT_URI` nei container delle attività di Amazon ECS per fornire un metodo per interagire con l'endpoint API dell'agente del container. Ogni endpoint include un endpoint `/start`, `/stop` e `/status`. Gli endpoint accettano solo richieste da attività che hanno l'iniezione di guasti abilitata e ogni endpoint ha un limite di frequenza di **1** richiesta ogni **5** secondi per container. Il superamento di questo limite comporta la generazione di un errore.

**Nota**  
L'agente di Amazon ECS `version 1.88.0+` è necessario per utilizzare gli endpoint di iniezione di guasti.

I tre endpoint da utilizzare con l'iniezione di guasti sono:
+ [Endpoint di porta blackhole di rete](#fis-endpoint-blackhole-ports)
+ [Endpoint di perdita di pacchetti di rete](#fis-endpoint-packet-loss)
+ [Endpoint di latenza di rete](#fis-endpoint-latency)

Una richiesta riuscita genera un codice di risposta di `200` con un messaggio di `running` quando si chiama l'endpoint `/start`, `stopped` per l'endpoint `/stop` e `running` o `not-running` per l'endpoint `/status`.

```
{
    "Status": <string>
}
```

Una richiesta non riuscita restituisce uno dei seguenti codici di errore:
+ `400`: richiesta non valida
+ `409`: la richiesta di iniezioni di guasti è in conflitto con un altro guasto in esecuzione
+ `429`: la richiesta è stata sottoposta a limitazione
+ `500`: il server ha riscontrato un errore imprevisto

```
{
	"Error":  <string message> 
}
```

**Nota**  
È possibile iniettare un guasto di latenza di rete o un errore di perdita di pacchetti di rete alla volta. Il tentativo di iniettarne più di uno comporta il rifiuto della richiesta.

## Endpoint di porta blackhole di rete
<a name="fis-endpoint-blackhole-ports"></a>

L'endpoint `{ECS_AGENT_URI}/fault/v1/network-blackhole-port` elimina il traffico in entrata o in uscita per una porta e un protocollo specifici nel namespace di rete di un'attività ed è compatibile con due modalità:
+ **awsvpc**: le modifiche vengono applicate al namespace della rete delle attività
+ **host**: le modifiche vengono applicate all'istanza di container predefinita del namespace di rete

### \$1ECS\$1AGENT\$1URI\$1/fault/v1/network-blackhole-port/start
<a name="fis-endpoint-blackhole-ports-start"></a>

Questo endpoint avvia le iniezioni di guasti nelle porte blackhole di rete e presenta i seguenti parametri:

**Porta**  
La porta specificata da utilizzare per l'iniezione di guasti nelle porte blackhole.

Tipo: numero intero

Obbligatorio: sì

**Protocollo**  
Il protocollo da utilizzare per l'iniezione di guasti nelle porte blackhole.

Tipo: String

Valori validi: `tcp | udp`

Obbligatorio: sì

**TrafficType**  
Il tipo di traffico utilizzato dall'iniezione di guasti.

Tipo: String

Valori validi: `ingress | egress`

Obbligatorio: sì

**SourcesToFilter**  
Un array JSON di IPv4 o IPv6 indirizzi o blocchi CIDR protetti dall'errore.

Tipo: array di stringhe

Obbligatorio: no

Di seguito è riportato un esempio di richiesta per l'utilizzo dell'`start`endpoint (sostituisci *red* i valori con i tuoi):

```
Endpoint: ${ECS_AGENT_URI}/fault/v1/network-blackhole-port/start

Http method:POST

Request payload: 
{
    "Port": 1234,
    "Protocol": "tcp|udp",
    "TrafficType": "ingress|egress"
    "SourcesToFilter": ["${IP1}", "${IP2}", ...],
}
```

### \$1ECS\$1AGENT\$1URI\$1/fault/v1/network-blackhole-port/stop
<a name="fis-endpoint-blackhole-ports-stop"></a>

Questo endpoint arresta il guasto specificato nella richiesta. Questo endpoint dispone dei seguenti parametri:

**Porta**  
La porta interessata dal guasto che deve essere interrotta.

Tipo: numero intero

Obbligatorio: sì

**Protocollo**  
Il protocollo da utilizzare per fermare il guasto.

Tipo: String

Valori validi: `tcp | udp`

Obbligatorio: sì

**TrafficType**  
Il tipo di traffico utilizzato dall'iniezione di guasti.

Tipo: String

Valori validi: `ingress | egress`

Obbligatorio: sì

Di seguito è riportato un esempio di richiesta per l'utilizzo dell'`stop`endpoint (sostituisci i valori con i tuoi): *red*

```
Endpoint: ${ECS_AGENT_URI}/fault/v1/network-blackhole-port/stop

Http method: POST

Request payload: 
{
    "Port": 1234,
    "Protocol": "tcp|udp",
    "TrafficType": "ingress|egress", 
}
```

### \$1ECS\$1AGENT\$1URI\$1/fault/v1/network-blackhole-port/status
<a name="fis-endpoint-blackhole-ports-status"></a>

Questo endpoint viene utilizzato per controllare lo stato dell'iniezione di guasti. Questo endpoint dispone dei seguenti parametri:

**Porta**  
La porta interessata per verificare lo stato del guasto.

Tipo: numero intero

Obbligatorio: sì

**Protocollo**  
Il protocollo da utilizzare per verificare lo stato del guasto.

Tipo: String

Valori validi: `tcp | udp`

Obbligatorio: sì

**TrafficType**  
Il tipo di traffico utilizzato dall'iniezione di guasti.

Tipo: String

Valori validi: `ingress | egress`

Obbligatorio: sì

Di seguito è riportato un esempio di richiesta per l'utilizzo dell'`status`endpoint (sostituisci i valori con i tuoi): *red*

```
Endpoint: ${ECS_AGENT_URI}/fault/v1/network-blackhole-port/status

Http method: POST

Request payload: 
{
   "Port": 1234,
   "Protocol": "tcp|udp",
   "TrafficType": "ingress|egress",
}
```

## Endpoint di latenza di rete
<a name="fis-endpoint-latency"></a>

L'endpoint `{ECS_AGENT_URI}/fault/v1/network-latency` aggiunge ritardo e instabilità all'interfaccia di rete dell'attività per il traffico verso fonti specifiche. L'endpoint è compatibile con due modalità:
+ **awsvpc**: le modifiche vengono applicate all'interfaccia della rete delle attività
+ **host**: le modifiche vengono applicate all'interfaccia della rete predefinita

### \$1ECS\$1AGENT\$1URI\$1/fault/v1/network-latency/start
<a name="fis-endpoint-latency-start"></a>

Questo endpoint `/start` avvia le iniezioni di guasti di latenza di rete e presenta i seguenti parametri:

**DelayMilliseconds**  
Il numero di millisecondi di ritardo da aggiungere all'interfaccia di rete da utilizzare per l'iniezione di guasti.

Tipo: numero intero

Obbligatorio: sì

**JitterMilliseconds**  
Il numero di millisecondi di jitter da aggiungere all'interfaccia di rete da utilizzare per l'iniezione di guasti.

Tipo: numero intero

Obbligatorio: sì

**Origini**  
Un array JSON di IPv4 o IPv6 indirizzi o blocchi CIDR destinati all'uso con l'iniezione di errori.

Tipo: array di stringhe

Obbligatorio: sì

**SourcesToFilter**  
Un array JSON di IPv4 o IPv6 indirizzi o blocchi CIDR protetti dall'errore. `SourcesToFilter`ha la priorità su. `Sources`

Tipo: array di stringhe

Obbligatorio: no

Di seguito è riportato un esempio di richiesta per l'utilizzo dell'`/start`endpoint (sostituisci i *red* valori con i tuoi):

```
Endpoint: ${ECS_AGENT_URI}/fault/v1/network-latency/start

Http method: POST

Request payload: 
{
    "DelayMilliseconds": 123,
    "JitterMilliseconds": 123,
    "Sources": ["${IP1}", "${IP2}", ...],
    "SourcesToFilter": ["${IP1}", "${IP2}", ...],
}
```

### \$1ECS\$1AGENT\$1URI\$1/fault/v1/network-latency/stop and /status
<a name="fis-endpoint-latency-stop-status"></a>

L'endpoint `{ECS_AGENT_URI}/fault/v1/network-latency/stop` blocca il guasto e `{ECS_AGENT_URI}/fault/v1/network-latency/status` verifica lo stato del guasto.

Di seguito sono riportati due esempi di richieste per l'utilizzo degli endpoint `/stop` e degli endpoint `/status`. Entrambi utilizzano il metodo `POST HTTP`.

```
Endpoint: ${ECS_AGENT_URI}/fault/v1/network-latency/stop
```

```
Endpoint: ${ECS_AGENT_URI}/fault/v1/network-latency/status
```

## Endpoint di perdita di pacchetti di rete
<a name="fis-endpoint-packet-loss"></a>

L'endpoint `{ECS_AGENT_URI}/fault/v1/network-packet-loss` aggiunge la perdita di pacchetti all'interfaccia di rete specificata. Questo endpoint è compatibile con due modalità:
+ **awsvpc**: le modifiche vengono applicate all'interfaccia della rete delle attività
+ **host**: le modifiche vengono applicate all'interfaccia della rete predefinita

### \$1ECS\$1AGENT\$1URI\$1/fault/v1/network-packet-loss/start
<a name="fis-endpoint-packet-loss-start"></a>

Questo endpoint `/start` avvia le iniezioni di guasti di perdita di pacchetti di rete e presenta i seguenti parametri:

**LossPercent**  
La percentuale di perdita di pacchetti

Tipo: numero intero

Obbligatorio: sì

**Origini**  
Un array JSON di IPv4 o IPv6 indirizzi o blocchi CIDR da utilizzare per i test di iniezione dei guasti.

Tipo: array di stringhe

Obbligatorio: sì

**SourcesToFilter**  
Un array JSON di IPv6 indirizzi IPv4 o blocchi CIDR protetti dall'errore. `SourcesToFilter`ha la priorità su. `Sources`

Tipo: array di stringhe

Obbligatorio: no

Di seguito è riportato un esempio di richiesta per l'utilizzo dell'`start`endpoint (sostituisci i *red* valori con i tuoi):

```
Endpoint: ${ECS_AGENT_URI}/fault/v1/network-packet-loss/start

Http method: POST

{
    "LossPercent": 6,  
    "Sources": ["${IP1}", "${IP2}", ...],
    "SourcesToFilter": ["${IP1}", "${IP2}", ...],
}
```

### \$1ECS\$1AGENT\$1URI\$1/fault/v1/network-packet-loss/stop and /status
<a name="fis-endpoint-packet-loss-stop-status"></a>

L'endpoint `{ECS_AGENT_URI}/fault/v1/network-packet-loss/stop` blocca il guasto e `{ECS_AGENT_URI}/fault/v1/network-packet-loss/status` verifica lo stato del guasto. È supportato solo un tipo di guasto alla volta.

Di seguito sono riportati due esempi di richieste per l'utilizzo degli endpoint `/stop` e degli endpoint `/status`. Entrambi utilizzano il metodo `POST HTTP`.

```
Endpoint: ${ECS_AGENT_URI}/fault/v1/network-packet-loss/stop
```

```
Endpoint: ${{ECS_AGENT_URI}/fault/v1/network-packet-loss/status
```

# Aggiornare i parametri del servizio Amazon ECS
<a name="update-service-parameters"></a>

Dopo aver creato un servizio, a volte potrebbe essere necessario aggiornare i parametri del servizio, ad esempio il numero di attività.

Quando il pianificatore di servizi avvia nuove attività, determina il posizionamento delle attività nel cluster con la seguente logica.
+ Determinare quale delle istanze di container nel cluster può supportare la definizione di attività del servizio. Ad esempio, dispongono gli attributi richiesti di CPU, memoria, porte e istanza di container.
+ Per impostazione predefinita, il pianificatore di servizi tenta di bilanciare le attività tra le zone di disponibilità in questo modo, anche se è possibile scegliere una strategia di posizionamento diversa.
  + Ordinare le istanze di container valide in base al numero minore di attività in esecuzione per questo servizio nella stessa zona di disponibilità dell'istanza. Ad esempio, se nella zona A è presente un'attività del servizio in esecuzione e nelle zone B e C nessuna, le istanze di container valide nella zona B o C sono considerate ottimali per il posizionamento.
  + Posizionare la nuova attività del servizio in un'istanza di container valida in una zona di disponibilità ottimale (in base alle fasi precedenti), favorendo le istanze di container con il minor numero di attività in esecuzione per questo servizio.

Quando il pianificatore di servizi arresta le attività in esecuzione, prova a mantenere il bilanciamento tra le zone di disponibilità nel cluster usando la seguente logica. 
+ Ordinare le istanze di container in base al numero maggiore di attività in esecuzione per questo servizio nella stessa zona di disponibilità dell'istanza. Ad esempio, se nella zona A è presente un'attività del servizio in esecuzione e nelle zone B e C ne sono presenti due, le istanze di container nella zona B o C sono considerate ottimali per l'arresto.
+ Arrestare l'attività del servizio in un'istanza di container in una zona di disponibilità ottimale (in base alle fasi precedenti), favorendo le istanze di container con il maggior numero di attività in esecuzione per questo servizio.

Utilizzare l'elenco per determinare se è possibile modificare il parametro del servizio.

**Ribilanciamento della zona di disponibilità**  
Indica se utilizzare il ribilanciamento delle zone di disponibilità per il servizio.  
È possibile modificare questo parametro per le implementazioni in sequenza.

**Strategia del provider di capacità**  
I dettagli di una strategia di un provider di capacità. È possibile impostare un provider di capacità quando si crea un cluster, si esegue un'attività o si aggiorna un servizio.  
Quando si utilizza Fargate, i provider di capacità sono `FARGATE` o `FARGATE_SPOT`.  
Quando si utilizza Amazon EC2, i provider di capacità sono gruppi Auto Scaling.  
È possibile cambiare provider di capacità per le implementazioni in sequenza e le implementazioni blu/verdi.  
L'elenco seguente fornisce le transizioni valide:  
+ Aggiornare Fargate a un provider di capacità di un gruppo Auto Scaling.
+ Aggiornare EC2 a un provider di capacità Fargate.
+ Aggiornare il provider di capacità Fargate a un provider di capacità di un gruppo Auto Scaling.
+ Aggiornare il provider di capacità Amazon EC2 a un provider di capacità Fargate. 
+ Aggiornare il gruppo Auto Scaling o il provider di capacità Fargate al tipo di avvio. Quando si utilizza la CLI o l'API, si passa un elenco vuoto nel parametro `capacityProviderStrategy`.

**Cluster**  
Non è possibile cambiare il nome del cluster.

**Configurazione dell’implementazione**  
La configurazione di implementazione include gli CloudWatch allarmi e l'interruttore automatico utilizzati per rilevare i guasti e la configurazione richiesta.  
L'interruttore di implementazione determina se un'implementazione del servizio avrà esito negativo se il servizio non riesce a raggiungere uno stato stazionario. Se si utilizza l'interruttore automatico di implementazione, un'implementazione del servizio passerà a uno stato non riuscito e interromperà l'avvio di nuove attività. Se si usa l'opzione di rollback, quando l'implementazione di un servizio non riesce, viene eseguito il rollback del servizio per ripristinare l'ultima implementazione completata correttamente.  
Quando viene aggiornato un servizio che utilizza l'interruttore automatico Amazon ECS, Amazon ECS crea un'implementazione e una revisione del servizio. Queste risorse consentono di visualizzare informazioni dettagliate sulla cronologia dei servizi. Per ulteriori informazioni, consultare [Visualizza la cronologia dei servizi utilizzando le distribuzioni dei servizi Amazon ECS](service-deployment.md).  
Il pianificatore del servizio utilizza i parametri di percentuale minima di attività integre e di percentuale massima (nella configurazione di implementazione del servizio) per determinare la strategia di implementazione.  
Se il servizio utilizza il tipo di distribuzione aggiornamento in sequenza (`ECS`), la **percentuale minima di attività integre** rappresenta il numero minimo di attività del servizio che devono rimanere nello stato `RUNNING` durante un'implementazione, espresso come percentuale del numero di attività desiderate (arrotondata per eccesso al numero intero più vicino). Il parametro si applica anche in presenza di istanze di container nello stato `DRAINING`, se il servizio contiene processi che utilizzano EC2. Utilizza questo parametro per eseguire l'implementazione senza impiegare capacità aggiuntiva del cluster. Ad esempio, se il servizio ha un numero desiderato di quattro attività e una percentuale minima di attività integre del 50%, lo scheduler può arrestare due attività esistenti per liberare capacità del cluster prima di avviare due nuove attività. Il servizio considera le attività integre per i servizi che non utilizzano un bilanciatore del carico se sono nello stato `RUNNING`. Il servizio considera le attività integre per i servizi che utilizzano un bilanciatore del carico se sono nello stato `RUNNING` e se sono considerate integre mediante il bilanciatore del carico. Il valore predefinito per la percentuale minima di integrità è 100%.  
Se il servizio utilizza il tipo di implementazione aggiornamento in sequenza (`ECS`), il parametro di **percentuale massima** rappresenta il numero massimo di attività del servizio che possono restare in stato `PENDING`, `RUNNING` o `STOPPING` durante un'implementazione, espresso come percentuale del numero di attività desiderato (arrotondata per difetto al numero intero più vicino). Il parametro si applica anche in presenza di istanze di container nello stato `DRAINING`, se il servizio contiene processi che utilizzano EC2. Utilizza questo parametro per definire le dimensioni del batch di implementazione. Ad esempio, se il servizio ha un numero desiderato di quattro attività e un valore percentuale massimo del 200%, lo scheduler può avviare quattro nuove attività prima di arrestare le quattro precedenti, a condizione che le risorse del cluster necessarie per questa operazione siano disponibili. Il valore predefinito per la percentuale massima è 200%.  
Quando il pianificatore del servizio sostituisce un'attività durante un aggiornamento, se il servizio utilizza un load balancer, rimuove prima l'attività da tale sistema e attende la fine delle connessioni. Quindi, viene emesso l'equivalente del comando **docker stop** ai container in esecuzione nell'attività. Questo determina un segnale `SIGTERM` e un timeout della durata di 30 secondi, dopo il quale viene inviato un segnale `SIGKILL` e i container vengono forzatamente arrestati. Se il container gestisce il segnale `SIGTERM` normalmente ed esce entro 30 secondi dalla ricezione, non viene inviato un segnale `SIGKILL`. Il pianificatore del servizio avvia e arresta le attività secondo quanto definito dalle impostazioni di percentuale minima di attività integre e percentuale massima.  
Il pianificatore di servizi sostituisce inoltre le attività ritenute non integre dopo l'esito negativo di un controllo dell'integrità del container o di un sistema di bilanciamento del carico del gruppo di destinazione. Questa sostituzione dipende dai parametri di definizione del servizio `maximumPercent` e `desiredCount`. Se un'attività è contrassegnata come non integra, il pianificatore di servizi avvierà innanzitutto un'attività di sostituzione. Poi, si verificano le seguenti situazioni.  
+ Se lo stato di integrità dell'attività di sostituzione è `HEALTHY`, il pianificatore di servizi interrompe l'attività non integra
+ Se lo stato di integrità dell'attività di sostituzione è `UNHEALTHY`, il pianificatore interromperà l'attività di sostituzione non integra o l'attività esistente non integra per far sì che il numero totale delle attività sia pari a `desiredCount`.
Se il parametro `maximumPercent` impedisce al pianificatore di avviare un'attività di sostituzione, il pianificatore interromperà un'attività non integra alla volta, in modo casuale, per liberare spazio, e poi avvierà un'attività di sostituzione. Il processo di avvio e arresto continua fino a quando tutte le attività non integre vengono sostituite con attività integre. Dopo aver sostituito tutte le attività non integre e aver avviato solo quelle integre, se il numero totale delle attività supera `desiredCount`, le attività integre vengono interrotte casualmente fino a quando il numero totale delle attività è pari a `desiredCount`. Per ulteriori informazioni sui parametri `maximumPercent` e `desiredCount`, consulta [Parametri di definizione del servizio](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service_definition_parameters.html).

**Controller di implementazione**  
Il tipo di controller di implementazione da utilizzare per il servizio. Esistono tre tipi di controller di implementazione:  
+ `ECS`
+ `EXTERNAL`
+ `CODE_DEPLOY`
Quando si aggiorna un servizio, è possibile aggiornare il controller di implementazione utilizzato. L'elenco seguente fornisce le transizioni valide:  
+ Aggiornamento dalle distribuzioni CodeDeploy blu/verdi () alle distribuzioni ECS Rolling o Deployments (`CODE_DEPLOY`). blue/green `ECS`
+ Aggiornamento da distribuzioni CodeDeploy blu/verdi () a distribuzioni esterne (). `CODE_DEPLOY` `EXTERNAL`
+ Aggiornamento da implementazioni sequenziali o blue/green distribuzioni ECS () a distribuzioni esterne (). `ECS` `EXTERNAL`
+ Aggiornamento da distribuzioni esterne () a implementazioni sequenziali o distribuzioni ECS (`EXTERNAL`). blue/green `ECS`
Quando si aggiorna il controller di implementazione di un servizio, tenere presenti le considerazioni seguenti:  
+ Non è possibile aggiornare il controller di implementazione di un servizio dal controller di implementazione `ECS` a nessuno degli altri controller se utilizza VPC Lattice o Amazon ECS Service Connect.
+ Non è possibile aggiornare il controller di implementazione di un servizio durante un'implementazione del servizio in corso.
+ Non è possibile aggiornare il controller di implementazione di un servizio a `CODE_DEPLOY` se sul servizio non sono presenti bilanciatori del carico.
+ Non è possibile aggiornare il controller di implementazione di un servizio da `ECS` a uno qualsiasi degli altri controller se `deploymentConfiguration` include allarmi, un interruttore automatico di implementazione o una strategia di implementazione `BLUE_GREEN`. Per ulteriori informazioni, consultare [Controller e strategie di implementazione dei servizi Amazon ECS](ecs_service-options.md).
+ Il valore specificato per `versionConsistency` nella definizione del container non verrà utilizzato da Amazon ECS se si aggiorna il controller di implementazione del servizio da `ECS` a uno qualsiasi degli altri controller. 
+ Se si aggiorna il controller di implementazione di un servizio da `ECS` a uno qualsiasi degli altri controller, le risposte API `UpdateService` e `DescribeService` continueranno a restituire `deployments` invece di `taskSets`. Per ulteriori informazioni su `UpdateService` e`CreateService`, consulta [UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_Service.html)e [CreateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_Service.html)nell'*Amazon ECS API Reference*.
+ Se un servizio utilizza una strategia di implementazione con aggiornamento in sequenza, l'aggiornamento del controller di implementazione da `ECS` a uno qualsiasi degli altri controller modificherà il modo in cui viene utilizzato il valore `maximumPercent` nel `deploymentConfiguration`. Invece di essere utilizzato solo come limite per il totale delle attività in un'implementazione con aggiornamento in sequenza, `maximumPercent` viene utilizzato per sostituire le attività non integre. Per ulteriori informazioni sul modo in cui il pianificatore sostituisce le attività non integre, consultare [Servizi Amazon ECS](ecs_services.md).
+ Se si aggiorna il controller di implementazione di un servizio da `ECS` a uno qualsiasi degli altri controller di implementazione, qualsiasi `advancedConfiguration` specificato con la configurazione del bilanciatore del carico verrà ignorato. Per ulteriori informazioni, consulta [LoadBalancer](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_LoadBalancer.html)e [AdvancedConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_AdvancedConfiguration.html)nel *riferimento alle API di Amazon ECS*.
Quando aggiorni il controller di distribuzione per un servizio che utilizza CloudFormation, considera quanto segue a seconda del tipo di migrazione che stai eseguendo.  
+ Se disponi di un CloudFormation modello che contiene le informazioni del controller di `EXTERNAL` distribuzione, nonché `PrimaryTaskSet` le risorse `TaskSet` e rimuovi le risorse del task set dal modello durante l'aggiornamento da `EXTERNAL` a`ECS`, le chiamate `DescribeTaskSet` e `DeleteTaskSet` API restituiranno un errore 400 dopo l'aggiornamento del controller di distribuzione`ECS`. Ciò comporta un errore di CloudFormation eliminazione delle risorse del task set, anche se lo CloudFormation stack passa allo `UPDATE_COMPLETE` status. Per ulteriori informazioni, consultare [Resource removed from stack but not deleted](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/troubleshooting.html#troubleshooting-errors-resource-removed-not-deleted) nella Guida per l'utente di AWS CloudFormation . Per risolvere questo problema, eliminare i set di attività utilizzando direttamente l'API `DeleteTaskSet` di Amazon ECS. Per ulteriori informazioni su come eliminare un set di attività, consulta [DeleteTaskSet](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_DeleteTaskSet.html)*Amazon Elastic Container Service* *API Reference*.
+ Se stai migrando da `CODE_DEPLOY` a `ECS` con una nuova definizione di attività ed CloudFormation esegui un'operazione di rollback, la `UpdateService` richiesta Amazon ECS ha esito negativo con il seguente errore:

  ```
  Resource handler returned message: "Invalid request provided: Unable to update 
  task definition on services with a CODE_DEPLOY deployment controller. Use AWS 
  CodeDeploy to trigger a new deployment. (Service: Ecs, Status Code: 400, 
  Request ID: 0abda1e2-f7b3-4e96-b6e9-c8bc585181ac) (SDK Attempt Count: 1)" 
  (RequestToken: ba8767eb-c99e-efed-6ec8-25011d9473f0, HandlerErrorCode: InvalidRequest)
  ```
+ Dopo una migrazione riuscita dal controller di implementazione da `ECS` a `EXTERNAL`, è necessario rimuovere manualmente il set di attività `ACTIVE`, poiché Amazon ECS non gestisce più l'implementazione. Per informazioni su come eliminare un set di attività, consulta il *riferimento [DeleteTaskSet](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_DeleteTaskSet.html)all'API* di Amazon Elastic Container Service.

**Numero di attività desiderato**  
Il numero di istanze dell'attività da posizionare e mantenere in esecuzione nel servizio.  
Se si desidera interrompere temporaneamente il servizio, impostare questo valore su 0. Quindi, quando si desidera avviare il servizio, aggiornarlo con il valore originale.  
È possibile modificare questo parametro per le implementazioni in sequenza e le implementazioni blu/verdi.

**Abilitare i tag gestiti**  
Determina se attivare i tag gestiti da Amazon ECS per le attività all'interno del servizio.  
Solo le attività avviate dopo l'aggiornamento rifletteranno quest'ultimo. Per aggiornare i tag di tutte le attività, utilizzare l'opzione di implementazione forzata.  
È possibile modificare questo parametro per le implementazioni in sequenza e quelle blu/verdi.

**Abilitare ECS Exec**  
Determina se viene utilizzato Amazon ECS Exec.  
Se non si desidera sovrascrivere il valore impostato al momento della creazione del servizio, è possibile impostarlo su null durante l'esecuzione di questa azione.  
È possibile modificare questo parametro per le implementazioni in sequenza.

**Periodo di tolleranza del controllo dell'integrità**  
Il periodo di tempo, in secondi, durante il quale il pianificatore di servizi di Amazon ECS ignora i controlli dell'integrità del bilanciamento del carico elastico, VPC Lattice e del container dopo il primo avvio di un'attività. Se non si specifica un valore per il periodo di tolleranza per il controllo dell’integrità, viene utilizzato il valore predefinito di `0`. Se non si utilizza nessuno dei controlli dell'integrità, allora non viene utilizzato `healthCheckGracePeriodSeconds`.  
Se le attività del servizio tardano ad avviarsi e a rispondere ai controlli dello stato, è possibile specificare un periodo di tolleranza per il controllo dell'integrità fino a un massimo di 2.147.483.647 secondi (circa 69 anni), durante i quali il pianificatore del servizio Amazon ECS ignora lo stato di questi controlli. Questo periodo di tolleranza può evitare che il pianificatore del servizio contrassegni le attività come non integre e le interrompa prima che abbiano il tempo di iniziare.  
È possibile modificare questo parametro per le implementazioni in sequenza e le implementazioni blu/verdi.

**Sistemi di load balancer**  
È necessario utilizzare un ruolo collegato al servizio quando si aggiorna un bilanciatore del carico.  
Un elenco di oggetti del bilanciatore del carico per il bilanciamento del carico elastico. Contiene il nome del bilanciatore del carico, il nome del container e la porta del container per accedere dal bilanciatore del carico. Il nome del container è come appare in una definizione del container.  
Amazon ECS non aggiorna automaticamente i gruppi di sicurezza associati ai sistemi di bilanciamento del carico Elastic Load Balancing o alle istanze di container di Amazon ECS.  
Quando si aggiunge, si aggiorna o si rimuove una configurazione del bilanciatore del carico, Amazon ECS avvia nuove attività con la configurazione aggiornata del bilanciamento del carico elastico, e poi interrompe le attività vecchie quando le nuove sono in esecuzione.  
Per i servizi che utilizzano aggiornamenti continui, è possibile aggiungere, aggiornare o rimuovere i gruppi di destinazione di bilanciamento del carico elastico. È possibile eseguire l'aggiornamento da un singolo gruppo di destinazione a più gruppi di destinazione e da più gruppi di destinazione a un singolo gruppo di destinazione.  
Per i servizi che utilizzano blue/green distribuzioni, puoi aggiornare i gruppi target Elastic Load Balancing utilizzando through. `[CreateDeployment](https://docs.aws.amazon.com/codedeploy/latest/APIReference/API_CreateDeployment.html)` CodeDeploy Tieni presente che non sono supportati più gruppi target per le distribuzioni. blue/green Per ulteriori informazioni, consultare [Register multiple target groups with a service](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/register-multiple-targetgroups.html).   
Per i servizi che utilizzano il controller di distribuzione esterno, è possibile aggiungere, aggiornare o rimuovere i sistemi di bilanciamento del carico utilizzando. [CreateTaskSet](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateTaskSet.html) Per le implementazioni esterne, non sono supportati più gruppi di destinazione. Per ulteriori informazioni, consultare [Register multiple target groups with a service](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/register-multiple-targetgroups.html).   
Passare un elenco vuoto per rimuovere i bilanciatori del carico  
È possibile modificare questo parametro per le implementazioni in sequenza.

**Configurazione della rete**  
La configurazione di rete del servizio.   
È possibile modificare questo parametro per le implementazioni in sequenza.

**Vincoli di posizionamento**  
Una serie di oggetti di vincolo di posizionamento delle attività per aggiornare il servizio da utilizzare. Se non viene specificato alcun valore, i vincoli di posizionamento esistenti per il servizio rimarranno invariati. Se specificato, questo valore sovrascriverà tutti i vincoli di posizionamento esistenti definiti per il servizio. Per rimuovere tutti i vincoli di posizionamento esistenti, specificare una serie vuota.  
Puoi specificare un massimo di 10 vincoli per ogni attività. Questo limite include i vincoli nella definizione di attività e quelli specificati in fase di runtime.  
È possibile modificare questo parametro per le implementazioni in sequenza e quelle blu/verdi.

**Strategia di posizionamento**  
Gli oggetti di strategia di posizionamento delle attività per aggiornare il servizio da utilizzare. Se non viene specificato alcun valore, la strategia di posizionamento esistente per il servizio rimarrà invariata. Se specificato, questo valore sovrascriverà la strategia di posizionamento esistente definita per il servizio. Per rimuovere una strategia di posizionamento esistente, specificare un oggetto vuoto.  
È possibile modificare questo parametro per le implementazioni in sequenza e quelle blu/verdi.

**Versione della piattaforma**  
La versione della piattaforma Fargate su cui viene eseguito il servizio.  
Un servizio che utilizza una versione della piattaforma Linux non può essere aggiornato per utilizzare una versione della piattaforma Windows e viceversa.  
È possibile modificare questo parametro per le implementazioni in sequenza.

**Propaga i tag**  
Determina se propagare i tag dalla definizione dell'attività o dal servizio all'attività. Se non viene specificato alcun valore, i tag non vengono propagati.  
Solo le attività avviate dopo l'aggiornamento rifletteranno quest'ultimo. Per aggiornare i tag su tutte le attività, impostare `forceNewDeployment` su `true`, in modo tale che Amazon ECS avvii nuove attività con i tag aggiornati.  
È possibile modificare questo parametro per le implementazioni in sequenza e le implementazioni blu/verdi.

**Configurazione di Service Connect**  
La configurazione per Amazon ECS Service Connect. Questo parametro determina il modo in cui il servizio si connette ad altri servizi all'interno dell'applicazione.  
È possibile modificare questo parametro per le implementazioni in sequenza.

**Registri del servizio**  
È necessario utilizzare un ruolo collegato ai servizi quando si aggiornano i registri di servizio.  
I dettagli per i registri di rilevamento servizi da assegnare a questo servizio. Per ulteriori informazioni, consultare [Service Discovery](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-discovery.html).  
Quando si aggiunge, si aggiorna o si rimuove la configurazione dei registri del servizio, Amazon ECS avvia nuove attività con la configurazione aggiornata dei registri del servizio, e poi interrompe le attività vecchie quando le nuove attività sono in esecuzione.  
Passare un elenco vuoto per rimuovere i registri di servizio.  
È possibile modificare questo parametro per le implementazioni in sequenza.

**Definizione di attività**  
La definizione di attività e la revisione da utilizzare per il servizio.  
Se si modificano le porte utilizzate dai container in una definizione di attività, potrebbe essere necessario aggiornare i gruppi di sicurezza per le istanze di container in modo che funzionino con le porte aggiornate.  
Se aggiorni la definizione di attività per il servizio, il nome e la porta del container specificati nella configurazione del bilanciatore del carico devono rimanere nella definizione di attività.   
Il comportamento di estrazione delle immagini del container è diverso a seconda delle opzioni di calcolo. Per ulteriori informazioni, consultare uno dei seguenti argomenti:  
+ [Progettazione per AWS Fargate per Amazon ECS](AWS_Fargate.md)
+ [Architetto per la EC2 capacità di Amazon ECS](launch-type-ec2.md)
+ [Esterno (Amazon ECS Anywhere) per Amazon ECS](launch-type-external.md)
È possibile modificare questo parametro per le implementazioni in sequenza.

**Configurazione del volume**  
I dettagli del volume che era `configuredAtLaunch`. Quando `configuredAtLaunch` è impostato su `true` nella definizione dell'attività, questo parametro di servizio configura un volume Amazon EBS per ogni attività nel servizio da creare e allegare durante l'implementazione. [È possibile configurare le dimensioni, il tipo di volume, l'IOPS, la velocità effettiva, l'istantanea e la crittografia in Configuration. ServiceManaged EBSVolume](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ServiceManagedEBSVolumeConfiguration.html) Il `name` del volume deve corrispondere al `name` dalla definizione dell'attività. Se impostato su null, non viene attivata alcuna nuova implementazione. In caso contrario, se questa configurazione è diversa da quella esistente, attiva una nuova implementazione.  
È possibile modificare questo parametro per le implementazioni in sequenza.

**Configurazione di VPC Lattice**  
La configurazione di VPC Lattice per il servizio. Questo definisce il modo in cui il servizio si integra con VPC service-to-service Lattice per la comunicazione.  
È possibile modificare questo parametro per le implementazioni in sequenza.

## AWS CDK considerazioni
<a name="cdk-considerations"></a>

 AWS CDK Non tiene traccia degli stati delle risorse. Non sa se si sta creando o aggiornando un servizio. I clienti devono utilizzare l'escape hatch per accedere direttamente al costrutto L1 `Service` di ECS. 

Per informazioni sugli escape hatch, consulta [Personalizza i costrutti della AWS Construct Library](https://docs.aws.amazon.com/cdk/v2/guide/cfn-layer.html#develop-customize-escape) nella Guida per sviluppatori *AWS Cloud Development Kit (AWS CDK) v2*. 

Per eseguire la migrazione del servizio esistente al costrutto `ecs.Service`, effettuare le seguenti operazioni:

1. Utilizzare l'escape hatch per accedere al costrutto L1 del `Service`. 

1. Impostare manualmente le seguenti proprietà nel costrutto L1 del `Service`. 

   Se il servizio utilizza la capacità di Amazon EC2:
   + `daemon?`
   + `placementConstraints?`
   + `placementStrategies?`
   + Se si utilizza la modalità di rete `awsvpc`, è necessario impostare le `vpcSubnets?` e i costrutti `securityGroups?`.

   Se il servizio utilizza Fargate:
   + `FargatePlatformVersion`
   + Le `vpcSubnets?` e i costrutti `securityGroups?`.

1. Impostare `launchType` nel modo seguente:

   ```
   const cfnEcsService = service.node.findChild('Service') as ecs.CfnService;
   cfnEcsService.launchType = "FARGATE";
   ```

Per eseguire la migrazione da un tipo di avvio a un provider di capacità, procedere come segue:

1. Utilizzare l'escape hatch per accedere al costrutto L1 del `Service`. 

1. Aggiungere il costrutto `capacityProviderStrategies?`.

1. Distribuire il servizio.

# Aggiornamento di un servizio Amazon ECS
<a name="update-service-console-v2"></a>

Dopo aver creato un servizio, a volte potrebbe essere necessario aggiornare i parametri del servizio, ad esempio il numero di attività.

Quando viene aggiornato un servizio che utilizza l'interruttore automatico Amazon ECS, Amazon ECS crea un'implementazione e una revisione del servizio. Queste risorse consentono di visualizzare informazioni dettagliate sulla cronologia dei servizi. Per ulteriori informazioni, consultare [Visualizza la cronologia dei servizi utilizzando le distribuzioni dei servizi Amazon ECS](service-deployment.md).

## Prerequisiti
<a name="update-service-prerequisites"></a>

Prima di aggiornare un servizio, verificare quali parametri del servizio possono essere modificati in base al tipo di implementazione. Per un elenco completo dei parametri modificabili, consultare [Aggiornare i parametri del servizio Amazon ECS](update-service-parameters.md).

## Procedura
<a name="update-service-procedure"></a>

------
#### [ Console ]

1. [Apri la console nella versione 2https://console.aws.amazon.com/ecs/.](https://console.aws.amazon.com/ecs/v2)

1. Nella pagina **Cluster**, scegliere il cluster.

1. Nella pagina dei dettagli del cluster, nella sezione **Servizi**, selezionare la casella di spunta accanto al servizio e poi scegliere **Aggiorna**.

1. Per fare in modo che il tuo servizio inizi una nuova implementazione, seleziona **Force new deployment** (Forza una nuova implementazione).

1. Per **Definizione dell'attività**, scegli la famiglia di definizioni dell'attività e la revisione.
**Importante**  
La console verifica che la famiglia di definizioni di processi e la revisione selezionate siano compatibili con la configurazione di calcolo definita. Se viene visualizzato un avviso, verificare che siano selezionate sia la compatibilità delle definizioni di processo che la configurazione di calcolo.

1. Se hai scelto **Replica**, per **Desired tasks** (Attività desiderate), immetti il numero di attività da avviare e mantenere nel servizio.

1. Se è stato scelto **Replica**, per consentire ad Amazon ECS di monitorare la distribuzione delle attività tra le zone di disponibilità e ridistribuirle in caso di squilibrio, in **Ribilanciamento del servizio delle zone di disponibilità**, selezionare **Ribilanciamento del servizio della zona di disponibilità.**

1. Per **Min running tasks** (Numero minimo di attività in esecuzione), specifica il limite inferiore per il numero di attività nel servizio che devono rimanere nello stato `RUNNING` durante un'implementazione, espresso come percentuale del numero di attività desiderate (arrotondata per eccesso al numero intero più vicino). Per ulteriori informazioni, consultare [Deployment configuration](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service_definition_parameters.html#sd-deploymentconfiguration).

1. Per **Max running tasks** (Numero massimo di attività in esecuzione), specifica il limite superiore per il numero di attività del servizio consentite nello stato `RUNNING` o `PENDING` durante un'implementazione, espresso come percentuale del numero di attività desiderate (arrotondata per difetto al numero intero più vicino).

1. Per configurare il modo in cui le attività vengono implementate per il servizio, espandere le **Opzioni di implementazione** e quindi configurare le opzioni.

   1. Per **Tipo di controller di implementazione**, specificare il controller di implementazione del servizio. La console Amazon ECS supporta i seguenti tipi di controller: `ECS`.

   1. Per **Strategia di implementazione**, scegliere la strategia utilizzata da Amazon ECS per implementare nuove versioni del servizio.

   1. A seconda della scelta della **Strategia di implementazione**, eseguire le seguenti operazioni:    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonECS/latest/developerguide/update-service-console-v2.html)

   1. Per eseguire le funzioni Lambda per una fase del ciclo di vita, in **Hook del ciclo di vita di implementazione**, svolgere le seguenti operazioni per ogni funzione Lambda unica:

      1. Scegliere **Aggiungi**.

         Ripetere l'operazione per ogni funzione unica che si desidera eseguire.

      1. Per **Funzione Lambda**, immettere il nome della funzione.

      1. Per **Ruolo**, scegli il ruolo che hai creato nei prerequisiti con le blue/green autorizzazioni.

         Per ulteriori informazioni, consulta [Autorizzazioni richieste per le funzioni Lambda nelle distribuzioni Amazon ECS blue/green](blue-green-permissions.md).

      1. Per **Fasi del ciclo di vita**, selezionare le fasi eseguite dalla funzione Lambda.

      1.  (Facoltativo) Per **Dettagli dell'hook**, inserire una coppia chiave-valore che fornisca informazioni sull'hook.

1. Per configurare il modo in cui Amazon ECS rileva e gestisce gli errori di implementazione, espandi **Deployment failure detection** (Rilevamento degli errori di implementazione), quindi scegli le tue opzioni. 

   1. Per interrompere un'implementazione quando le attività non possono essere avviate, seleziona **Use the Amazon ECS deployment circuit breaker** (Usa l'interruttore automatico di implementazione di Amazon ECS).

      Per fare in modo che il software ripristini automaticamente l'implementazione all'ultimo stato di implementazione completata quando l'interruttore automatico di implementazione imposta l'implementazione su uno stato di errore, selezionare **Rollback in caso di errore**.

   1. Per interrompere una distribuzione in base alle metriche dell'applicazione, seleziona **Usa CloudWatch allarmi**. Quindi, dal **nome CloudWatch dell'allarme**, scegli gli allarmi. Per creare un nuovo allarme, vai alla CloudWatch console.

      Per fare in modo che il software ripristini automaticamente la distribuzione all'ultimo stato di distribuzione completato quando un CloudWatch allarme imposta la distribuzione **su uno stato fallito, seleziona Rollback in caso** di errori.

1. Per modificare le opzioni di calcolo, espandere **Configurazione di calcolo**, quindi effettuare le seguenti operazioni: 

   1. Per i servizi attivi AWS Fargate, per la **versione della piattaforma**, scegli la nuova versione.

   1. Per i servizi che utilizzano una strategia del provider di capacità, in **Strategia del provider di capacità**, eseguire le operazioni seguenti:
      + Per aggiungere un provider di capacità aggiuntivo, scegli **Aggiungi altro**. Quindi, scegli il provider in **Provider di capacità**.
      + Per rimuovere un provider di capacità, scegli **Rimuovi** a destra del provider.

      Un servizio che utilizza un provider di capacità di un gruppo Auto Scaling non può essere aggiornato per utilizzare un provider di capacità Fargate. Un servizio che utilizza un provider di capacità Fargate che non può essere aggiornato per utilizzare un provider di capacità di un gruppo Auto Scaling.

1. (Facoltativo) Per configurare il servizio di dimensionamento automatico, espandere **Dimensionamento automatico del servizio** e quindi specificare i seguenti parametri. Per utilizzare il dimensionamento automatico predittivo, che esamina i dati di caricamento precedenti provenienti dai flussi di traffico, è necessario configurarlo dopo aver creato il servizio. Per ulteriori informazioni, consultare [Usa modelli storici per scalare i servizi Amazon ECS con scalabilità predittiva](predictive-auto-scaling.md).

   1. Per utilizzare il dimensionamento automatico, selezionare **Dimensionamento automatico del servizio**.

   1. Per **Numero minimo di attività**, inserire il limite inferiore del numero di attività che devono essere utilizzate dal servizio di dimensionamento automatico. Il numero desiderato non scenderà al di sotto di questo conteggio.

   1. In **Numero massimo di processi**, specificare il limite superiore del numero di processi che devono essere utilizzati dal servizio di dimensionamento automatico. Il numero desiderato non sarà superiore a questo conteggio.

   1. Scegli il tipo di policy. In **Tipo di policy di dimensionamento**, scegliere una delle opzioni seguenti.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonECS/latest/developerguide/update-service-console-v2.html)

1. (Facoltativo) Per utilizzare Service Connect, seleziona **Turn on Service Connect** (Attiva Service Connect), quindi specifica quanto segue:

   1. In **Service Connect configuration** (Configurazione Service Connect), specifica la modalità client.
      + Se il servizio esegue un'applicazione client di rete che deve connettersi solo ad altri servizi nel namespace, scegliere **Solo lato client**.
      + Se il servizio esegue un'applicazione di rete o di servizio Web, deve fornire endpoint per questo servizio e si connette ad altri servizi nel namespace, scegliere **Client e server**.

   1. Per utilizzare un namespace differente da quello del cluster predefinito, per **Namespace**, scegliere il namespace del servizio. Può trattarsi di uno spazio dei nomi creato separatamente Regione AWS nello stesso spazio dell'utente Account AWS o di uno spazio dei nomi nella stessa regione condiviso con l'account utilizzando (). AWS Resource Access Manager AWS RAM[https://docs.aws.amazon.com/cloud-map/latest/dg/sharing-namespaces.html](https://docs.aws.amazon.com/cloud-map/latest/dg/sharing-namespaces.html)

   1. (Facoltativo) Specificare una configurazione del log. Selezionare **Usa la raccolta di log**. L'opzione predefinita invia i log dei contenitori a Logs. CloudWatch Le altre opzioni del driver di registro sono configurate utilizzando. AWS FireLens Per ulteriori informazioni, consulta [Inviare i log di Amazon ECS a un servizio o AWS AWS Partner](using_firelens.md).

      Di seguito sono riportate descrizioni più dettagliate per ogni destinazione di log di container.
      + **Amazon CloudWatch**: configura l'attività per inviare i log dei container a CloudWatch Logs. Vengono fornite le opzioni predefinite dei driver di registro, che creano un gruppo di CloudWatch log per tuo conto. Per specificare un nome del gruppo di log diverso, modifica i valori dell'opzione del driver.
      + **Amazon Data Firehose**: configura l'attività per inviare i log del container a Firehose. Vengono fornite le opzioni di driver di log predefinite che inviano i log a un flusso di consegna Firehose. Per specificare un nome del flusso di consegna diverso, modifica i valori dell'opzione del driver.
      + **Flusso di dati Amazon Kinesis**: configura il processo per inviare log di container a Kinesis Data Streams. Vengono fornite le opzioni di driver di log predefinite che inviano i log a un flusso di consegna Kinesis Data Streams. Per specificare un nome del flusso diverso, modifica i valori dell'opzione del driver.
      + **Amazon OpenSearch Service**: configura l'attività per inviare i log dei container a un dominio OpenSearch di servizio. Devono essere fornite le opzioni del driver di log. 
      + **Amazon S3**: configura l'attività per inviare log di container a un bucket Amazon S3. Vengono fornite le opzioni del driver di log predefinito, ma è necessario specificare un nome del bucket Amazon S3 valido.

   1. Per abilitare i log di accesso, segui questi passaggi:

      1. Espandi la **configurazione del registro di accesso**. Per **Format**, scegli **JSON** o`TEXT`.

      1. Per includere i parametri di interrogazione nei log di accesso, selezionate **Includi parametri di interrogazione**.
**Nota**  
**Per disabilitare i log di accesso, in **Formato**, scegli Nessuno.**

1. Se l'attività utilizza un volume di dati compatibile con la configurazione al momento dell'implementazione, è possibile configurare il volume espandendo **Volume**.

   Il nome e il tipo di volume vengono configurati durante la creazione di una revisione della definizione di attività e non possono essere modificati quando si aggiorna un servizio. Per aggiornare il nome e il tipo di volume, è necessario creare una nuova revisione della definizione di attività e aggiornare il servizio utilizzando la nuova revisione.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonECS/latest/developerguide/update-service-console-v2.html)

1. (Facoltativo) Per identificare il tuo servizio, espandi la sezione **Tags** (Tag), quindi configura i tag.
   + [Aggiungere un tag] Scegliere **Aggiungi tag** e procedere come segue:
     + In **Chiave**, immetti il nome della chiave.
     + In **Valore**, immetti il valore della chiave.
   + [Rimuovere un tag] Accanto al tag, scegliere **Remove tag (Rimuovi tag)**.

1. Scegliere **Aggiorna**.

------
#### [ AWS CLI ]
+ Esegui `update-service`. Per informazioni sull'esecuzione del comando, consulta [update-service](https://docs.aws.amazon.com/cli/latest/reference/ecs/update-service.html) nella Guida di riferimento. AWS Command Line Interface 

  L'esempio `update-service` seguente aggiorna il numero di attività desiderato del servizio `my-http-service` su 2.

  Sostituisci il *user-input* con i tuoi valori.

  ```
  aws ecs update-service \
      --cluster MyCluster \
      --service my-http-service \
      --desired-count 2
  ```

------

## Fasi successive
<a name="update-service-next-steps"></a>

Tracciare l'implementazione e visualizzare la cronologia dei servizi dell'interruttore automatico di Amazon ECS. Per ulteriori informazioni, consultare [Visualizza la cronologia dei servizi utilizzando le distribuzioni dei servizi Amazon ECS](service-deployment.md).

# Aggiornamento di un servizio Amazon ECS per utilizzare un provider di capacità
<a name="update-service-managed-instances"></a>

Se si dispone di un servizio esistente che utilizza il tipo di avvio Amazon EC2 o Fargate e si desidera utilizzare le istanze gestite da Amazon ECS, occorre aggiornare il servizio per utilizzare il provider di capacità delle istanze gestite da Amazon ECS.

## Prerequisiti
<a name="update-service-managed-instances-prerequisites"></a>

Creare un provider di capacità per le istanze gestite da Amazon ECS. Per ulteriori informazioni, consultare [Creazione di un provider di capacità per le istanze gestite da Amazon ECS](create-capacity-provider-managed-instances.md).

## Procedura
<a name="update-service-managed-instances-procedure"></a>

------
#### [ Console ]

1. Apri la console alla [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2).

1. Nella pagina **Cluster**, scegliere il cluster.

1. Nella pagina dei dettagli del cluster, nella sezione **Servizi**, selezionare la casella di spunta accanto al servizio e poi scegliere **Aggiorna**.

1. Selezionare **Forza una nuova implementazione**.

1. In **Configurazione di calcolo**, scegliere Strategia del provider di capacità. Poi, scegliere una delle opzioni seguenti:
   + Se il provider di capacità delle istanze gestite da Amazon ECS è il provider di capacità predefinito, scegliere **Usa impostazione predefinita del cluster**.
   + Se il provider di capacità delle istanze gestite da Amazon ECS non è il provider di capacità predefinito, scegliere **Usa personalizzato (avanzate)**. Scegliere il provider di capacità delle istanze gestite da Amazon ECS, quindi per **Peso**, scegliere 1.

1. Scegliere **Aggiorna**.

------
#### [ AWS CLI ]
+ Esegui `update-service`. Per informazioni sull'esecuzione del comando, consulta [update-service](https://docs.aws.amazon.com/cli/latest/reference/ecs/update-service.html) nella Guida di riferimento. AWS Command Line Interface 

  Sostituisci il *user-input* con i tuoi valori.

  ```
  aws ecs update-service \
      --cluster my-cluster \
      --service my-service \
      --capacity-provider-strategy capacityProvider=my-managed-instance-capacity-provider,weight=1 \
      --force-new-deployment
  ```

------

# Eliminazione di un servizio Amazon ECS utilizzando la console
<a name="delete-service-v2"></a>

Di seguito sono riportati alcuni dei motivi per cui eliminare un servizio:
+ L'applicazione non è più necessaria
+ Si sta eseguendo la migrazione del servizio in un nuovo ambiente
+ L'applicazione non viene utilizzata attivamente
+ L'applicazione utilizza più risorse del necessario e si sta cercando di ottimizzare i costi

Prima dell'eliminazione, la capacità del servizio viene automaticamente ridotta a zero. Le risorse del sistema di bilanciamento del carico o le risorse di rilevamento del servizio che sono associate al servizio non sono interessate dall'eliminazione del servizio. Per eliminare le risorse di Elastic Load Balancing, consulta uno dei seguenti argomenti, a seconda del tipo di sistema di bilanciamento del carico: [Eliminazione di un Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-delete.html) o [Eliminazione di Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-delete.html). 

Quando si elimina un servizio, Amazon ECS elimina tutte le implementazioni e le revisioni del servizio.

Quando si elimina un servizio, se vi sono ancora attività in esecuzione che richiedono pulizia, lo stato del servizio passa da `ACTIVE` a `DRAINING` e il servizio non è più visibile nella console o nell'operazione API `ListServices`. Dopo che tutte le attività sono passate allo stato `STOPPING` o `STOPPED`, lo stato del servizio passa da `DRAINING` a `INACTIVE`. I servizi nello stato `DRAINING` o `INACTIVE` possono ancora essere visualizzati con l'operazione API `DescribeServices`. 

**Importante**  
Se si tenta di creare un nuovo servizio con lo stesso nome di un servizio esistente nello stato `ACTIVE` o `DRAINING`, si riceverà un errore.

**Procedura**

1. Apri la console alla [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2).

1. Nella pagina **Clusters** (Cluster), seleziona il cluster per il servizio.

1. Nella pagina **Cluster**, scegliere il cluster.

1. Nella *name* pagina **Cluster:**, scegli la scheda **Servizi**. 

1. Selezionare i servizi e quindi seleziona **Delete** (Elimina).

1. Per eliminare un servizio anche se non è stato ridotto a zero attività, seleziona **Force delete service** (Forza eliminazione servizio).

1. Al prompt di conferma, inserire **elimina**, quindi scegliere **Elimina**. 

# Eseguire la migrazione di un ARN di servizio breve di Amazon ECS in un ARN lungo
<a name="service-arn-migration"></a>

Amazon ECS assegna un nome della risorsa Amazon (ARN) univoco a ciascun servizio. I servizi creati prima del 2021 hanno un formato ARN corto:

 `arn:aws:ecs:region:aws_account_id:service/service-name`

Amazon ECS ha modificato il formato ARN per includere il nome del cluster. Questo è un formato ARN lungo:

`arn:aws:ecs:region:aws_account_id:service/cluster-name/service-name`

Il servizio deve avere il formato ARN lungo per assegnare tag al servizio. 

È possibile migrare un servizio con un formato ARN corto al formato ARN lungo senza dover ricreare il servizio. È possibile usare l'API, la CLI o la console. L'operazione di migrazione non può essere annullata.

Il processo di migrazione è semplice e garantisce zero tempi di inattività per il servizio. Durante la migrazione:
+ **Disponibilità del servizio**: il servizio continua a funzionare normalmente senza interruzioni del traffico o delle funzionalità.
+ **Attività in esecuzione**: le attività esistenti continuano a essere eseguite senza interruzioni. Le nuove attività avviate dopo la migrazione utilizzeranno il formato ARN lungo se l'impostazione dell'account `taskLongArnFormat` è abilitata.
+ **Istanze di container:** le istanze di container non sono interessate dalla migrazione ARN del servizio e continuano a funzionare normalmente.
+ **Configurazione del servizio**: tutte le impostazioni del servizio, tra cui la definizione delle attività, la rete e le configurazioni del bilanciatore del carico, rimangono invariate.

Se desideri utilizzare per CloudFormation etichettare un servizio con un formato ARN breve, devi migrare il servizio utilizzando l'API, la CLI o la console. Una volta completata la migrazione, puoi utilizzare CloudFormation per etichettare il servizio.

Se si desidera utilizzare Terraform per etichettare un servizio con un formato ARN corto, è necessario migrare il servizio utilizzando l'API, la CLI o la console. Una volta completata la migrazione, è possibile utilizzare Terraform per etichettare il servizio.

Al termine della migrazione, il servizio presenta le seguenti modifiche:
+ Il formato ARN lungo

  `arn:aws:ecs:region:aws_account_id:service/cluster-name/service-name`
+ Quando esegui la migrazione utilizzando la console, Amazon ECS aggiunge un tag al servizio con la chiave impostata su «ecs: serviceArnMigrated At» e il valore impostato sul timestamp della migrazione (formato UTC).

  Questo tag viene conteggiato ai fini della quota di tag.
+ Quando `PhysicalResourceId` in uno CloudFormation stack rappresenta un ARN di servizio, il valore non cambia e continuerà a essere l'ARN del servizio breve. 

## Prerequisiti
<a name="migrate-service-arn-prerequisite"></a>

Eseguire le seguenti operazioni prima di migrare l'ARN del servizio.

1. Per verificare se si dispone di un ARN di servizio corto, visualizzare i dettagli del servizio nella console Amazon ECS (appare un avviso quando il servizio ha il formato ARN corto) o il parametro return di `serviceARN` da `describe-services`. Quando l'ARN non include il nome del cluster, si dispone di un ARN corto. Il formato di un ARN corto è il seguente:

    `arn:aws:ecs:region:aws_account_id:service/service-name`

1. Si noti la data di creazione.

1.  Se si dispone di policy IAM che utilizzano il formato ARN corto, aggiornarlo al formato ARN lungo.

   Sostituisci ogni *user input placeholder* con le tue informazioni.

    `arn:aws:ecs:region:aws_account_id:service/cluster-name/service-name`

   *Per ulteriori informazioni, consulta [Modifica delle politiche IAM nella Guida](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-edit.html) per l' AWS Identity and Access Management utente.*

1.  Se si dispone di strumenti che utilizzano il formato ARN corto, aggiornarlo al formato ARN lungo.

   Sostituisci ogni *user input placeholder* con le tue informazioni.

    `arn:aws:ecs:region:aws_account_id:service/cluster-name/service-name`

1. Abilitare il formato ARN lungo del servizio. Esegui `put-account-setting` con l'opzione `serviceLongArnFormat` impostata su `enabled`. Per ulteriori informazioni, [put-account-setting](https://docs.aws.amazon.com/cli/latest/reference/ecs/put-account-setting.html)consulta la sezione *Amazon Elastic Container Service API Reference*.

   Eseguire il comando come utente root quando il servizio ha una data di `createdAt` sconosciuta.

   ```
   aws ecs put-account-setting --name serviceLongArnFormat --value enabled
   ```

   Output di esempio

   ```
   {
       "setting": {
           "name": "serviceLongArnFormat",
           "value": "enabled",
           "principalArn": "arn:aws:iam::123456789012:role/your-role",
           "type": user
       }
   }
   ```

1. Abilitare il formato ARN lungo dell'attività. Questa impostazione dell'account controlla il formato ARN per le nuove attività che vengono avviate dopo il completamento della migrazione del servizio. Esegui `put-account-setting` con l'opzione `taskLongArnFormat` impostata su `enabled`. Per ulteriori informazioni, [put-account-setting](https://docs.aws.amazon.com/cli/latest/reference/ecs/put-account-setting.html)consulta la sezione *Amazon Elastic Container Service API Reference*.

   Eseguire il comando come utente root quando il servizio ha una data di `createdAt` sconosciuta.

   ```
   aws ecs put-account-setting --name taskLongArnFormat --value enabled
   ```

   Output di esempio

   ```
   {
       "setting": {
           "name": "taskLongArnFormat",
           "value": "enabled",
           "principalArn": "arn:aws:iam::123456789012:role/your-role",
           "type": user
       }
   }
   ```
**Nota**  
L'impostazione `taskLongArnFormat` non migra direttamente le attività esistenti. Influisce solo sul formato ARN delle nuove attività create dopo l'attivazione dell'impostazione. Le attività in esecuzione esistenti mantengono il formato dell'ARN attuale fino a quando non vengono sostituite tramite le normali operazioni di servizio (come implementazioni o attività di scalabilità).

## Procedura
<a name="migrate-service-arn-procedure"></a>

Usare quanto segue per eseguire la migrazione dell'ARN del servizio.

### Console
<a name="migrate-service-arn-procedure-console"></a>

1. Apri la console nella [https://console.aws.amazon.com/ecs/versione 2](https://console.aws.amazon.com/ecs/v2).

1. Nella pagina **Cluster**, scegliere il cluster.

1. Nella sezione **Servizi**, scegliere un servizio con un avviso nella colonna ARN.

   Si apre la pagina dei dettagli del servizio.

1. Scegliere **Migra a un ARN lungo.**

   Appare la finestra di dialogo Migra servizio.

1. Scegliere **Migrate (Migrazione)**.

### CLI
<a name="migrate-service-arn-procedure-cli"></a>

Dopo aver sodisfatto tutti i prerequisiti, è possibile etichettare il servizio. Esegui il comando seguente:

Amazon ECS valuta la possibilità di passare il formato ARN lungo in una richiesta API `tag-resource` per un servizio con un ARN corto come segnale per eseguire la migrazione del servizio all'utilizzo del formato ARN lungo.

```
aws ecs tag-resource \
    --resource-arn arn:aws:ecs:region:aws_account_id:service/cluster-name/service-name
    --tags key=key1,value=value1
```

L'esempio seguente contrassegna MyService con un tag con una chiave impostata su "TestService" e un valore impostato su ": WebServers

```
aws ecs tag-resource \
    --resource-arn arn:aws:ecs:us-east-1:123456789012:service/MyCluster/MyService
    --tags key=TestService1,value=WebServers
```

### Terraform
<a name="migrate-service-arn-procedure-terraform"></a>

Dopo aver sodisfatto tutti i prerequisiti, è possibile etichettare il servizio. Creare una risorsa `aws_ecs_service` e impostare il riferimento `tags`. Per ulteriori informazioni, consultare [Resource: aws\$1ecs\$1service](https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/ecs_service) nella documentazione di Terraform.

```
resource "aws_ecs_service" "MyService" {
  name    = "example"
  cluster = aws_ecs_cluster.MyService.id

 tags = {
 "Name"  =  "MyService"
 "Environment"  =  "Production"
 "Department"  =  "QualityAssurance"
  }
}
```

### Fasi successive
<a name="tag-next-steps"></a>

È possibile aggiungere tag al servizio. Per ulteriori informazioni, consultare [Aggiunta di tag alle risorse Amazon ECS](tag-resources-console.md).

Se si desidera che Amazon ECS propaghi i tag dalla definizione dell'attività o dal servizio all'attività, eseguire `update-service` con il parametro `propagateTags`. *Per ulteriori informazioni, vedere [update-service nel Reference](https://docs.aws.amazon.com/cli/latest/reference/ecs/update-service.html). AWS Command Line Interface *

## Risoluzione dei problemi
<a name="troubleshooting-arn-migration"></a>

 Alcuni utenti potrebbero riscontrare il seguente errore durante la migrazione dal formato ARN corto al formato ARN lungo. 

`There was an error while migrating the ARN of service service-name. The specified account does not have serviceLongArnFormat or taskLongArnFormat account settings enabled. Add account settings in order to enable tagging.` 

 Se l'impostazione dell'account `serviceLongArnFormat` è già stata abilitata ma questo errore continua a verificarsi, è possibile che le impostazioni dell'account per il formato ARN lungo non siano state abilitate per il principale IAM specifico che ha originariamente creato il servizio. 

1.  Identificare il principale che ha creato il servizio.

   1. Nella console, le informazioni sono disponibili nel campo **Creato da** nella scheda **Configurazione e rete** nella pagina dei dettagli del servizio nella console Amazon ECS. 

   1. Per la AWS CLI, esegui il seguente comando:

      Sostituisci *user-input* con i tuoi valori.

      ```
      aws ecs describe-services --cluster cluster-name --services service-name --query 'services[0].{createdBy: createdBy}'
      ```

1. Abilitare le impostazioni dell'account richieste per quel principale specifico. Questa operazione può essere eseguita in uno dei seguenti modi: 

   1.  Assumere il ruolo o l'utente IAM per quel principale. Quindi eseguire `put-account-setting`. 

   1.  Usare l'utente root per eseguire il comando specificando il principale di creazione con `principal-arn`. 

      Esempio.

      Sostituisci *principal-arn* con il valore del passaggio 1.

      ```
      aws ecs put-account-setting --name serviceLongArnFormat --value enabled --principal-arn arn:aws:iam::123456789012:role/jdoe
      ```

 Entrambi i metodi abilitano l'impostazione dell'account `serviceLongArnFormat` richiesta sul principale che ha creato il servizio, il che consente di procedere con la migrazione dell'ARN. 

# Logica di limitazione del servizio Amazon ECS
<a name="service-throttle-logic"></a>

Il pianificatore di servizi Amazon ECS include la logica protettiva che limita i lanci delle attività quando queste non riescono ripetutamente a essere avviate. Questo aiuta a prevenire il consumo inutile di risorse e riduce i costi.

Quando le attività di un servizio non riescono a passare da uno stato `PENDING` a `RUNNING` e invece passano direttamente a `STOPPED`, il pianificatore del servizio:
+ Aumenta in modo incrementale il tempo tra i tentativi di riavvio
+ Continua ad aumentare i ritardi fino a un massimo di 27 minuti tra un tentativo e l'altro
+ Genera un messaggio relativo all'evento del servizio per avvisare l'utente del problema

**Nota**  
Il periodo di ritardo massimo di 27 minuti potrebbe cambiare nei futuri aggiornamenti.

Quando la limitazione è attivata, si riceve questo messaggio relativo all'evento di servizio:

```
(service service-name) is unable to consistently start tasks successfully.
```

Caratteristiche importanti della logica di limitazione:
+ I servizi continuano a ripetere i tentativi a tempo indeterminato
+ L'unica modifica è l'aumento del tempo tra i riavvii
+ Non ci sono parametri configurabili dall'utente

## Risoluzione dei problemi di limitazione della larghezza di banda della rete
<a name="resolving-throttling"></a>

Per risolvere il problema della limitazione, è possibile:
+ Aggiornare il servizio per usare una nuova definizione di attività, che riporta immediatamente il servizio a un funzionamento normale e non limitato. Per ulteriori informazioni, consultare [Aggiornamento di un servizio Amazon ECS](update-service-console-v2.md).
+ Affrontare la causa alla base degli errori delle attività.

Le cause più comuni degli errori delle attività che innescano la limitazione includono:
+ Risorse del cluster (porte, memoria o CPU) insufficienti
  + Indicato da un [messaggio di evento relativo al servizio di risorse insufficiente](service-event-messages-list.md#service-event-messages-1)
+ Errori di estrazione dell'immagine del container
  + Possono essere causati da nomi di immagini non validi, tag o autorizzazioni insufficienti
  + Determina `CannotPullContainerError` in [Visualizza gli errori relativi alle attività interrotte in Amazon ECS](stopped-task-errors.md)
+ Spazio su disco insufficiente
  + Determina `CannotCreateContainerError` in [errori di attività interrotte](stopped-task-errors.md)
  + Per le fasi di risoluzione, consultare [Risolvi i problemi relativi a `API error (500): devmapper` di Docker in Amazon ECS](CannotCreateContainerError.md)

**Importante**  
I seguenti scenari NON attivano la logica di limitazione:  
Attività che si interrompono dopo aver raggiunto lo stato `RUNNING`
Attività interrotte a causa di controlli dell'integrità non riusciti del bilanciamento del carico elastico
Attività in cui il comando del container termina con un codice diverso da zero dopo aver raggiunto lo stato `RUNNING`

# Parametri di definizione del servizio di Amazon ECS
<a name="service_definition_parameters"></a>

Una definizione di servizio stabilisce come eseguire il servizio Amazon ECS. I seguenti parametri possono essere specificati in una definizione di servizio.

## Tipo di lancio
<a name="sd-launchtype"></a>

`launchType`  
Tipo: String  
Valori validi: `EC2` \$1 `FARGATE` \$1 `EXTERNAL`  
Obbligatorio: no  
Il tipo di avvio con cui eseguire il servizio. Se non viene specificato un tipo di avvio, per impostazione predefinita viene utilizzato il `capacityProviderStrategy` di default.  
Quando si aggiorna un servizio, questo parametro innesca una nuova implementazione del servizio.  
Se viene specificato un `launchType`, il parametro `capacityProviderStrategy` deve essere omesso.

## Strategia del fornitore di capacità
<a name="sd-capacityproviderstrategy"></a>

`capacityProviderStrategy`  
Tipo: matrice di oggetti   
Obbligatorio: no  
La strategia del fornitore di capacità da utilizzare per il servizio.  
Quando si aggiorna un servizio, questo parametro non innesca una nuova implementazione del servizio.  
Una strategia del fornitore di capacità consiste di uno o più fornitori di capacità e dei valori `base` e `weight` da assegnare a essi. Un provider di capacità deve essere associato al cluster da utilizzare in una strategia del provider di capacità. L' PutClusterCapacityProviders API viene utilizzata per associare un provider di capacità a un cluster. È possibile utilizzare solo i provider di capacità con uno stato `ACTIVE` o uno stato `UPDATING`.  
Se viene specificato un `capacityProviderStrategy`, il parametro `launchType` deve essere omesso. Se non viene specificato `capacityProviderStrategy` o `launchType`, viene utilizzato `defaultCapacityProviderStrategy` per il cluster.  
Se desideri specificare un provider di capacità che utilizzi un gruppo con scalabilità automatica, il provider di capacità deve essere già stato creato. È possibile creare nuovi fornitori di capacità con l'operazione CreateCapacityProvider API.  
Per utilizzare un provider di capacità AWS Fargate, specificare `FARGATE` o i provider di `FARGATE_SPOT` capacità. I provider di capacità AWS Fargate sono disponibili per tutti gli account e devono essere associati solo a un cluster per essere utilizzati.  
L'operazione PutClusterCapacityProviders API viene utilizzata per aggiornare l'elenco dei fornitori di capacità disponibili per un cluster dopo la creazione del cluster.    
`capacityProvider`  <a name="capacityProvider"></a>
Tipo: stringa  
Obbligatorio: sì  
Il nome breve o il nome della risorsa Amazon (ARN) del provider di capacità.  
`weight`  <a name="weight"></a>
Tipo: numero intero  
Intervallo valido: numeri interi compresi tra 0 e 1.000.  
Obbligatorio: no  
Il valore del peso indica la percentuale relativa del numero totale di attività avviate che devono utilizzare il provider di capacità specificato.  
Ad esempio, supponiamo di avere una strategia che contiene due provider di capacità, ognuno con un peso pari a uno. Una volta soddisfatta la base, le attività si dividono equamente tra i due provider di capacità. Usando la stessa logica, assumiamo di specificare un peso di 1 per *capacityProviderA* e un peso di 4 per *capacityProviderB*. Quindi, per ogni attività che viene eseguita utilizzando *capacityProviderA*, quattro attività utilizzano *capacityProviderB*.  
`base`  <a name="base"></a>
Tipo: numero intero  
Intervallo valido: numeri interi compresi tra 0 e 100.000.  
Obbligatorio: no  
Il valore di base indica il numero minimo di attività da eseguire nel provider di capacità specificato. Solo un provider di capacità in una strategia di provider di capacità può avere una base definita.

## Definizione di attività
<a name="sd-taskdefinition"></a>

`taskDefinition`  
▬Tipo: stringa  
Obbligatorio: no  
I valori `family` e `revision` (`family:revision`) o il nome della risorsa Amazon (ARN) completo della definizione di attività da eseguire nel servizio. Se non viene specificato un `revision`, viene utilizzata l'ultima revisione `ACTIVE` della famiglia specificata.  
Quando si aggiorna un servizio, questo parametro innesca una nuova implementazione del servizio.  
Una definizione di attività deve essere specificata quando si utilizza il controller di implementazione dell'aggiornamento in sequenza (`ECS`).

## Sistema operativo della piattaforma
<a name="platform-os"></a>

`platformFamily`  
Tipo: stringa  
Obbligatorio: condizionale  
Di default: Linux  
Questo parametro è richiesto per i servizi Amazon ECS ospitati su Fargate.  
Questo parametro viene ignorato per i servizi Amazon ECS ospitati su Amazon EC2.  
Il sistema operativo sui container che esegue il servizio. I valori validi sono `LINUX`, `WINDOWS_SERVER_2019_FULL`, `WINDOWS_SERVER_2019_CORE`, `WINDOWS_SERVER_2022_FULL` e `WINDOWS_SERVER_2022_CORE`.  
Il valore `platformFamily` per ogni processo specificato per il servizio deve corrispondere al valore `platformFamily` del servizio. Ad esempio, se hai impostato `platformFamily` su `WINDOWS_SERVER_2019_FULL`, il valore `platformFamily` per tutte le attività deve essere `WINDOWS_SERVER_2019_FULL`.

## Versione della piattaforma
<a name="sd-platformversion"></a>

`platformVersion`  
▬Tipo: stringa  
Obbligatorio: no  
La versione della piattaforma su cui sono in esecuzione le attività nel servizio. Viene specificata una versione della piattaforma solo per le attività con tipo di avvio Fargate. Se non è specificata, la versione più recente (`LATEST`) viene utilizzata di default.  
Quando si aggiorna un servizio, questo parametro innesca una nuova implementazione del servizio.  
AWS Le versioni della piattaforma Fargate vengono utilizzate per fare riferimento a un ambiente di runtime specifico per l'infrastruttura di attività Fargate. Quando specifichi la versione della piattaforma `LATEST` durante l'esecuzione di un'attività o la creazione di un servizio, ottieni la versione di piattaforma più aggiornata disponibile per le tue attività. Quando incrementi il servizio, tali attività riceveranno la versione della piattaforma specificata nell'implementazione corrente del servizio. Per ulteriori informazioni, consultare [Versioni della piattaforma Fargate per Amazon ECS](platform-fargate.md).  
Le versioni della piattaforma non sono specificate per i processi che utilizzano il tipo di avvio EC2.

## Cluster
<a name="sd-cluster"></a>

`cluster`  
▬Tipo: stringa  
Obbligatorio: no  
Il nome breve o il nome della risorsa Amazon (ARN) completo del cluster in cui eseguire il servizio. Se non specifichi un cluster, viene utilizzato il cluster di `default`.

## Nome del servizio
<a name="sd-servicename"></a>

`serviceName`  
Tipo: stringa  
Obbligatorio: sì  
Il nome del servizio. Sono consentite fino a 255 lettere (maiuscole e minuscole), numeri, trattini e caratteri di sottolineatura. I nomi dei servizi devono essere univoci all'interno di un cluster, ma puoi avere servizi dai nomi simili in più cluster all'interno di una Regione o in più Regioni.

## Strategia di pianificazione
<a name="sd-schedulingstrategy"></a>

`schedulingStrategy`  
Tipo: String  
Valori validi: `REPLICA` \$1 `DAEMON`  
Obbligatorio: no  
La strategia di pianificazione da utilizzare. Se non viene specificata alcuna strategia di pianificazione, viene utilizzata la strategia `REPLICA`. Per ulteriori informazioni, consultare [Servizi Amazon ECS](ecs_services.md).  
Sono disponibili due strategie del pianificatore del servizio:  
+ `REPLICA`: la strategia di pianificazione delle repliche colloca e gestisce il numero desiderato di attività nel cluster. Di default, il pianificatore del servizio distribuisce le attività tra le zone di disponibilità. Puoi utilizzare vincoli e strategie di posizionamento delle attività per personalizzare le decisione riguardo al posizionamento delle attività. Per ulteriori informazioni, consultare [Strategia di pianificazione delle repliche](ecs_service-options.md#service_scheduler_replica).
+ `DAEMON`: la strategia di pianificazione del daemon distribuisce esattamente un'attività in ciascuna istanza di container attiva, che soddisfa tutti i vincoli di posizionamento delle attività specificati nel cluster. Quando si utilizza questa strategia, non è necessario specificare un numero di attività desiderato o una strategia di posizionamento delle attività, né utilizzare le policy di Auto Scaling del servizio. Per ulteriori informazioni, consultare [Strategia di pianificazione dei daemon](ecs_service-options.md#service_scheduler_daemon).
**Nota**  
I processi Fargate non supportano la strategia di pianificazione `DAEMON`

## Conteggio desiderato
<a name="sd-desiredcount"></a>

`desiredCount`  
Tipo: Integer  
Obbligatorio: no  
Il numero di istanze della definizione di attività specificata da posizionare e mantenere in esecuzione nel servizio.  
Quando si aggiorna un servizio, questo parametro non innesca una nuova implementazione del servizio.  
Questo parametro è obbligatorio se si utilizza la strategia di pianificazione `REPLICA`. Se il servizio utilizza la strategia di pianificazione `DAEMON`, questo parametro è facoltativo.  
Quando si utilizza il dimensionamento automatico dei servizi, quando si aggiorna un servizio attualmente in esecuzione con un `desiredCount` inferiore al numero di attività attualmente in esecuzione, il servizio viene ridotto verticalmente fino al `desiredCount` specificato. 

## Configurazione dell'implementazione
<a name="sd-deploymentconfiguration"></a>

`deploymentConfiguration`  
Tipo: oggetto  
Obbligatorio: no  
I parametri di implementazione opzionali determinano quante attività vengono eseguite durante l'implementazione e l'ordine di arresto e di avvio delle attività.  
Quando si aggiorna un servizio, questo parametro non innesca una nuova implementazione del servizio.    
`maximumPercent`  <a name="maximumPercent"></a>
Tipo: Integer  
Obbligatorio: no  
Se il servizio utilizza il tipo di implementazione con aggiornamento in sequenza (`ECS`), il parametro `maximumPercent` rappresenta un limite superiore sul numero di attività del servizio che sono consentite nello stato `RUNNING`, `STOPPING` o `PENDING` durante un'implementazione. Viene espresso come percentuale del `desiredCount`arrotondato per difetto al valore intero più vicino. Questo parametro può essere utilizzato per definire le dimensioni del batch di implementazione. Ad esempio, se il servizio utilizza il pianificatore di servizi `REPLICA` e ha un `desiredCount` di quattro attività e un valore `maximumPercent` pari al 200%, il pianificatore avvia quattro nuove attività prima di arrestare le quattro attività più vecchie. a condizione che le risorse del cluster necessarie per questa operazione siano disponibili. Il valore predefinito `maximumPercent` per un servizio che utilizza il pianificatore di servizi `REPLICA` è del 200%.  
Il pianificatore di Amazon ECS utilizza questo parametro per sostituire le attività non integre avviando prima le attività sostitutive e poi interrompendo quelle non integre, purché siano disponibili risorse del cluster per avviare attività sostitutive. Per ulteriori informazioni sul modo in cui il pianificatore sostituisce le attività non integre, consultare [Servizi Amazon ECS](ecs_services.md).  
Se il servizio sta utilizzando il tipo di pianificatore di servizi `DAEMON`, il parametro `maximumPercent` deve rimanere al 100%. Si tratta del valore di default.  
Il numero massimo di attività durante un'implementazione è uguale a `desiredCount` moltiplicato per `maximumPercent`/100, arrotondato per difetto al numero intero più vicino.  
Se un servizio utilizza il tipo di implementazione blu/verde (`CODE_DEPLOY`) o attività e tipi di implementazione `EXTERNAL` che utilizzano il tipo di lancio EC2, il valore di **percentuale massima** è impostato sul valore predefinito. Il valore viene utilizzato solo per definire il limite superiore sul numero di attività nel servizio che rimangono nello stato `RUNNING` mentre le istanze di container sono nello stato `DRAINING`.  
Non è possibile specificare un valore `maximumPercent` personalizzato per un servizio che utilizza i tipi di implementazione blu/verde (`CODE_DEPLOY`) o `EXTERNAL` e dispone di attività che utilizzano EC2.
Se il servizio utilizza i tipi di implementazione blu/verde (`CODE_DEPLOY`) o `EXTERNAL`, e le attività del servizio utilizzano Fargate, il valore percentuale massimo non viene utilizzato. Il valore viene comunque restituito quando si descrive il servizio.  
`minimumHealthyPercent`  <a name="minimumHealthyPercent"></a>
Tipo: Integer  
Obbligatorio: no  
Se il servizio utilizza il tipo di implementazione aggiornamento in sequenza (`ECS`), il parametro `minimumHealthyPercent` rappresenta un limite inferiore sul numero di attività del servizio che devono restare nello stato `RUNNING` durante un'implementazione. Viene espresso come percentuale del `desiredCount`arrotondato per eccesso al valore intero più vicino. Questo parametro può essere utilizzato per eseguire l'implementazione senza utilizzare capacità aggiuntiva del cluster.  
Ad esempio, se il servizio ha un `desiredCount` di quattro attività, un `minimumHealthyPercent` del 50% e un `maximumPercent` del 100%, il pianificatore di servizi arresta due attività esistenti per liberare capacità del cluster prima di avviare due nuove attività.   
 Se alcune attività non sono integre e `maximumPercent` non consente allo scheduler di Amazon ECS di avviare attività sostitutive, lo scheduler interrompe le attività non integre, utilizzando il vincolo `minimumHealthyPercent` come vincolo, per liberare la capacità necessaria per avviare attività one-by-one sostitutive. Per ulteriori informazioni sul modo in cui il pianificatore sostituisce le attività non integre, consultare [Servizi Amazon ECS](ecs_services.md).  
Per i servizi che *non utilizzano* un load balancer, considera quanto riportato di seguito:  
+ Un servizio è considerato integro se tutti i container essenziali all'interno delle attività del servizio superano i controlli dello stato.
+ Se un'attività non dispone di container essenziali con un controllo dell'integrità definito, il pianificatore del servizio attenderà 40 secondi dopo che un'attività raggiunge uno stato `RUNNING` prima di contarla per la percentuale minima di integrità totale.
+ Se un'attività ha uno o più container essenziali con un controllo dell'integrità definito, il pianificatore del servizio attenderà che l'attività raggiunga uno stato integro prima di contarla per la percentuale minima di integrità totale. Un'attività è considerata sana quando tutti i container essenziali al suo interno hanno superato i controlli dello stato. La quantità di tempo che il pianificatore del servizio può attendere è determinata dalle impostazioni di controllo dello stato del container. Per ulteriori informazioni, consultare [Controllo dell’integrità](task_definition_parameters.md#container_definition_healthcheck). 
Per i servizi che *utilizzano* un load balancer, considera quanto riportato di seguito:  
+ Se un'attività non dispone di container essenziali con un controllo dell'integrità definito, il pianificatore del servizio attenderà che il controllo dell'integrità del gruppo di destinazione del load balancer restituisca uno stato integro prima di contarla nella percentuale minima di integrità totale.
+ Se un'attività dispone di un container essenziale con un controllo dell'integrità definito, il pianificatore del servizio attenderà che l'attività raggiunga uno stato integro e il controllo dell'integrità del gruppo di destinazione del load balancer restituisca uno stato integro prima di contare l'attività nella percentuale minima di integrità totale.
Il valore predefinito di un servizio di replica per `minimumHealthyPercent` è 100%. Il `minimumHealthyPercent` valore predefinito per un servizio che utilizza la pianificazione del `DAEMON` servizio è 0% per AWS CLI AWS SDKs, il e e 50% per. APIs Console di gestione AWS  
Il numero minimo di attività integre durante un'implementazione è uguale a `desiredCount` moltiplicato per `minimumHealthyPercent`/100, arrotondato per eccesso al numero intero più vicino.  
Se un servizio utilizza il tipo di implementazione blu/verde (`CODE_DEPLOY`) o `EXTERNAL` ed esegue attività che utilizzano EC2, il valore di **percentuale integra massima** è impostato sul valore predefinito. Il valore viene utilizzato solo per definire il limite inferiore sul numero di attività nel servizio che rimangono nello stato `RUNNING` mentre le istanze di container sono nello stato `DRAINING`.  
Non è possibile specificare un valore `maximumPercent` personalizzato per un servizio che utilizza i tipi di implementazione blu/verde (`CODE_DEPLOY`) o `EXTERNAL` e dispone di attività che utilizzano EC2.
Se un servizio utilizza i tipi di implementazione blu/verde (`CODE_DEPLOY`) o `EXTERNAL` ed esegue processi che utilizzano Fargate, il valore della percentuale minima di integrità non viene utilizzato, anche se viene restituito nella descrizione del servizio.

## Controller di implementazione
<a name="sd-deploymentcontroller"></a>

`deploymentController`  
Tipo: oggetto  
Obbligatorio: no  
Il tipo di controller di implementazione da utilizzare per il servizio. Se non viene specificato alcun controller di implementazione, viene utilizzato il controller `ECS`. Per ulteriori informazioni, consultare [Servizi Amazon ECS](ecs_services.md).  
Quando si aggiorna un servizio, questo parametro non innesca una nuova implementazione del servizio.    
`type`  
Tipo: String  
Valori validi: `ECS` \$1 `CODE_DEPLOY` \$1 `EXTERNAL`  
Obbligatorio: sì  
Il tipo di controller di implementazione da utilizzare. Esistono tre tipi di controller di implementazione:    
`ECS`  
Il controller di distribuzione Amazon ECS supporta diverse strategie di implementazione: aggiornamento progressivo, blue/green, linear, and canary. The rolling update deployment type involves replacing the current running version of the container with the latest version. Blue/green implementazioni che creano un nuovo ambiente e spostano il traffico contemporaneamente. Le implementazioni lineari spostano gradualmente il traffico con incrementi percentuali uguali. Le implementazioni Canary spostano prima una piccola percentuale del traffico, quindi spostano il traffico rimanente. Il numero di container che Amazon ECS aggiunge o rimuove dal servizio durante un aggiornamento in sequenza è controllato regolando il numero minimo e massimo di integrità consentite durante l'implementazione di un servizio, come specificato in [deploymentConfiguration](#deploymentConfiguration).  
`CODE_DEPLOY`  
Il tipo di implementazione blue/green (`CODE_DEPLOY`) utilizza il modello di blue/green implementazione fornito da CodeDeploy, che consente di verificare una nuova implementazione di un servizio prima di inviargli traffico di produzione.  
`EXTERNAL`  
Utilizza il tipo di implementazione esterna quando desideri usare qualsiasi controller di implementazione di terze parti per il controllo completo sul processo di implementazione per un servizio Amazon ECS.

## Posizionamento dei processi
<a name="sd-taskplacement"></a>

`placementConstraints`  
Tipo: matrice di oggetti   
Obbligatorio: no  
Serie di oggetti vincolo di posizionamento da utilizzare per le attività del servizio. Puoi specificare un massimo di 10 vincoli per attività. Questo limite include i vincoli nella definizione dell'attività e quelli specificati in fase di runtime. Se si utilizza Fargate, i vincoli di posizionamento dei processi non sono supportati.  
Quando si aggiorna un servizio, questo parametro non innesca una nuova implementazione del servizio.    
`type`  
▬Tipo: stringa  
Obbligatorio: no  
Il tipo di vincolo. Utilizza `distinctInstance` per accertarti che ogni attività in un determinato gruppo sia in esecuzione su un'istanza di container diversa. Utilizza `memberOf` per limitare la selezione a un gruppo di candidati validi. Il valore `distinctInstance` non è supportato nelle definizioni di attività.  
`expression`  
▬Tipo: stringa  
Obbligatorio: no  
Un'espressione del linguaggio di query del cluster da applicare al vincolo. Non puoi specificare un'espressione se il tipo di vincolo è `distinctInstance`. Per ulteriori informazioni, consultare [Creare espressioni per definire istanze di container per le attività di Amazon ECS](cluster-query-language.md).

`placementStrategy`  
Tipo: matrice di oggetti   
Obbligatorio: no  
Gli oggetti strategia di posizionamento da utilizzare per le attività del servizio. Puoi specificare un massimo di quattro regole di strategia per ogni servizio.  
Quando si aggiorna un servizio, questo parametro non innesca una nuova implementazione del servizio.    
`type`  
Tipo: String  
Valori validi: `random` \$1 `spread` \$1 `binpack`  
Obbligatorio: no  
Il tipo di strategia di posizionamento. La strategia di posizionamento `random` posiziona in modo casuale le attività sui candidati disponibili. La strategia di posizionamento `spread` distribuisce le attività in modo uniforme tra i candidati disponibili in base al parametro `field`. La strategia `binpack` posiziona le attività sui candidati disponibili che dispongono della quantità minima di risorsa specificata con il parametro `field`. Ad esempio, se adotti il binpacking della memoria, un'attività verrà posizionata sull'istanza con la quantità minima di memoria residua (ma ancora sufficiente a eseguire l'attività).  
`field`  
▬Tipo: stringa  
Obbligatorio: no  
Il campo a cui applicare la strategia di posizionamento. Per la strategia di posizionamento `spread`, i valori validi sono `instanceId` (o `host`, che ha lo stesso effetto) oppure qualsiasi attributo personalizzato o di piattaforma applicato a un'istanza di container, come `attribute:ecs.availability-zone`. Per la strategia di posizionamento `binpack`, i valori validi sono `cpu` e `memory`. Per la strategia di posizionamento `random` questo campo non viene utilizzato.

## Tag
<a name="sd-tags"></a>

`tags`  
Tipo: matrice di oggetti   
Obbligatorio: no  
I metadati applicati al servizio per aiutarti a catalogarli e organizzarli. Ogni tag è composto da una chiave e da un valore opzionale, entrambi personalizzabili. Quando un servizio viene eliminato, vengono eliminati anche i tag. Al servizio è possibile applicare un massimo di 50 tag. Per ulteriori informazioni, consultare [Aggiunta di tag alle risorse Amazon ECS](ecs-using-tags.md).  
Quando si aggiorna un servizio, questo parametro non innesca una nuova implementazione del servizio.    
`key`  
Tipo: String  
Limitazioni di lunghezza: lunghezza minima pari a 1. La lunghezza massima è 128 caratteri.  
Obbligatorio: no  
Una parte di una coppia chiave-valore che costituisce un tag. Una chiave è un'etichetta generale che funge da categoria per più valori di tag specifici.  
`value`  
Tipo: String  
Limitazioni di lunghezza: lunghezza minima di 0. La lunghezza massima è 256 caratteri.  
Obbligatorio: no  
La parte facoltativa di una coppia chiave-valore che costituisce un tag. Un valore agisce come descrittore all'interno di una categoria di tag (chiave).

`enableECSManagedTags`  
Tipo: Booleano  
Valori validi: `true` \$1 `false`  
Obbligatorio: no  
Specifica se usare i tag gestiti di Amazon ECS per i processi nel servizio. Se non viene specificato alcun valore, il valore predefinito è `false`. Per ulteriori informazioni, consultare [Uso dei tag per la risoluzione dei problemi](ecs-using-tags.md#tag-resources-for-billing).  
Quando si aggiorna un servizio, questo parametro non innesca una nuova implementazione del servizio.

`propagateTags`  
Tipo: String  
Valori validi: `TASK_DEFINITION` \$1 `SERVICE`  
Obbligatorio: no  
Specifica se copiare i tag dalla definizione di attività o dal servizio nelle attività del servizio. Se non viene specificato alcun valore, i tag non vengono copiati. I tag possono essere copiati solo nelle attività all'interno del servizio durante la creazione del servizio. Per aggiungere tag a un processo dopo la creazione di un servizio o di un processo, utilizza l'operazione API `TagResource`.  
Quando si aggiorna un servizio, questo parametro non innesca una nuova implementazione del servizio.

## Configurazione della rete
<a name="sd-networkconfiguration"></a>

`networkConfiguration`  
Tipo: oggetto  
Obbligatorio: no  
La configurazione di rete per il servizio. Questo parametro è obbligatorio per le definizioni di attività che utilizzano la modalità di rete `awsvpc` per ricevere la propria interfaccia di rete elastica e non è supportato per altre modalità. Se si utilizza Fargate, la modalità di rete `awsvpc` è obbligatoria. Per ulteriori informazioni sulle reti per EC2, consultare [Opzioni di rete di attività di Amazon ECS per EC2](task-networking.md). Per maggiori informazioni sulla rete per Fargate, consultare [Amazon ECS task networking options for Fargate](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/fargate-task-networking.html).  
Quando si aggiorna un servizio, questo parametro innesca una nuova implementazione del servizio.    
`awsvpcConfiguration`  
Tipo: oggetto  
Obbligatorio: no  
Un oggetto che rappresenta le sottoreti e i gruppi di sicurezza per un'attività o un servizio.    
`subnets`  
Tipo: array di stringhe  
Obbligatorio: sì  
Le sottoreti associate all'attività o al servizio. Esiste un limite di 16 sottoreti che possono essere specificate in base a `awsvpcConfiguration`.  
`securityGroups`  
Tipo: array di stringhe  
Obbligatorio: no  
I gruppi di sicurezza associati all'attività o al servizio. Se non specifichi un gruppo di sicurezza, viene utilizzato il gruppo di sicurezza predefinito dell'ambiente VPC. Esiste un limite di cinque gruppi di sicurezza che possono essere specificati in base a `awsvpcConfiguration`.  
`assignPublicIP`  
Tipo: String  
Valori validi: `ENABLED` \$1 `DISABLED`  
Obbligatorio: no  
Se l'interfaccia di rete elastica dell'attività riceve un indirizzo IP pubblico. Se non viene specificato alcun valore, viene utilizzato il valore predefinito `DISABLED`.

`healthCheckGracePeriodSeconds`  
Tipo: Integer  
Obbligatorio: no  
Il periodo di tempo, in secondi, durante il quale il pianificatore di servizi di Amazon ECS ignora i controlli dell'integrità del bilanciamento del carico elastico, VPC Lattice e del container dopo il primo avvio di un'attività. Se non si specifica un valore per il periodo di tolleranza per il controllo dell’integrità, viene utilizzato il valore predefinito di 0. Se non si utilizza nessuno dei controlli dell’integrità, allora non viene utilizzato `healthCheckGracePeriodSeconds`.  
Se le attività del servizio tardano ad avviarsi e a rispondere, puoi specificare un periodo di tolleranza per il controllo dell’integrità fino a un massimo di 2.147.483.647 secondi (circa 69 anni), durante i quali il pianificatore del servizio Amazon ECS ignora lo stato di questi controlli. Questo periodo di tolleranza può evitare che il pianificatore del servizio contrassegni le attività come non integre e le interrompa prima che abbiano il tempo di iniziare.  
Quando si aggiorna un servizio, questo parametro non innesca una nuova implementazione del servizio.

`loadBalancers`  
Tipo: matrice di oggetti   
Obbligatorio: no  
Un oggetto che rappresenta il load balancer da utilizzare con il tuo servizio. Per i servizi che utilizzano un Application Load Balancer o un Network Load Balancer, esiste un limite di cinque gruppi di destinazione che puoi collegare a un servizio.  
Quando si aggiorna un servizio, questo parametro innesca una nuova implementazione del servizio.  
Dopo aver creato un servizio, la configurazione del load balancer non può essere modificata dalla Console di gestione AWS. È possibile utilizzare AWS Copilot AWS CLI o SDK per modificare la configurazione del bilanciamento del carico solo per il controller di distribuzione `ECS` mobile, non AWS CodeDeploy blu/verde o esterno. AWS CloudFormation Quando aggiungi, aggiorni o rimuovi una configurazione del load balancer, Amazon ECS avvia una nuova implementazione con la configurazione aggiornata di Elastic Load Balancing. Questo causa la registrazione e l'annullamento della registrazione dai load balancer. Si consiglia di verificarlo in un ambiente di test prima di aggiornare la configurazione di Elastic Load Balancing. Per informazioni su come modificare la configurazione, consulta il *riferimento [UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html)all'API di Amazon Elastic Container Service*.  
Per gli Application Load Balancer e i Network Load Balancer, questo oggetto deve contenere l'ARN del gruppo di destinazione del load balancer, il nome del container (così come appare nella definizione di quest'ultimo) e la porta del container per accedere dal load balancer. Quando un'attività di questo servizio è posizionata su un'istanza di container, l'unione dell'istanza e della porta del container viene registrata come destinazione nel gruppo di destinazione specificato qui.    
`targetGroupArn`  
▬Tipo: stringa  
Obbligatorio: no  
Il nome della risorsa Amazon (ARN) completo del gruppo o dei gruppi di destinazione dell'Elastic Load Balancer associati a un servizio.  
L'ARN del gruppo di destinazione viene specificato solo quando di utilizza un Application Load Balancer o un Network Load Balancer.  
`loadBalancerName`  
▬Tipo: stringa  
Obbligatorio: no  
Il nome del load balancer da associare al servizio.  
Se utilizzi un Application Load Balancer o un Network Load Balancer, il parametro relativo al nome del load balancer deve essere omesso.  
`containerName`  
▬Tipo: stringa  
Obbligatorio: no  
Il nome del container (così come appare nella definizione di quest'ultimo) da associare al load balancer.  
`containerPort`  
Tipo: Integer  
Obbligatorio: no  
La porta del container da associare al load balancer. Questa porta deve corrispondere a un `containerPort` nella definizione di attività utilizzata dalle attività nel servizio. Per le attività che utilizzano EC2, l'istanza di container deve consentire il traffico in ingresso sulla `hostPort` della mappatura delle porte.

`role`  
▬Tipo: stringa  
Obbligatorio: no  
Il nome breve o l'ARN completo del ruolo IAM che consente ad Amazon ECS di effettuare chiamate al load balancer per tuo conto. Questo parametro è consentito solo se utilizzi un load balancer con un singolo gruppo di destinazione e se la definizione di attività non utilizza la modalità di rete `awsvpc`. Se specifichi il parametro `role`, devi anche specificare un oggetto load balancer con il parametro `loadBalancers`.  
Quando si aggiorna un servizio, questo parametro non innesca una nuova implementazione del servizio.  
Se il ruolo specificato ha un percorso diverso da `/`, devi specificare l'ARN del ruolo completo (scelta consigliata) o anteporre il percorso al nome del ruolo come prefisso. Ad esempio, se un ruolo con il nome `bar` ha il percorso `/foo/`, devi specificare `/foo/bar` come nome del ruolo. Per ulteriori informazioni, consultare [Friendly Names and Paths](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers.html#identifiers-friendly-names) nella *Guida per l'utente IAM*.  
Se il tuo account ha già creato il ruolo collegato al servizio Amazon ECS, tale ruolo viene utilizzato di default per il tuo servizio, a meno che tu non specifichi un ruolo qui. Il ruolo collegato al servizio è obbligatorio se la definizione di attività utilizza la modalità di rete awsvpc; in tal caso, non è necessario specificare un ruolo qui. Per ulteriori informazioni, consultare [Uso di ruoli collegati ai servizi per Amazon ECS](using-service-linked-roles.md).

`serviceConnectConfiguration`  
Tipo: oggetto  
Obbligatorio: no  
La configurazione di questo servizio per rilevare e connettersi ai servizi, ed essere rilevati e connessi da altri servizi all'interno di uno spazio nomi.  
Quando si aggiorna un servizio, questo parametro innesca una nuova implementazione del servizio.  
Per ulteriori informazioni, consultare [Usa Service Connect per connettere i servizi Amazon ECS con nomi brevi](service-connect.md).    
`enabled`  
Tipo: Booleano  
Obbligatorio: sì  
Specifica se utilizzare Service Connect con questo servizio.   
`namespace`  
▬Tipo: stringa  
Obbligatorio: no  
Il nome breve o il nome completo Amazon Resource Name (ARN) dello spazio dei AWS Cloud Map nomi da utilizzare con Service Connect. Il namespace deve trovarsi nella stessa Regione AWS del cluster e del servizio Amazon ECS. Il tipo di namespace non influisce su Service Connect. *Per ulteriori informazioni AWS Cloud Map, consulta [Working with Services](https://docs.aws.amazon.com/cloud-map/latest/dg/working-with-services.html) nella Developer Guide.AWS Cloud Map *  
`services`  
Tipo: matrice di oggetti   
Obbligatorio: no  
Un array degli oggetti del servizio Service Connect. Questi sono nomi e alias (detti anche endpoint) utilizzati da altri servizi Amazon ECS per connettersi a questo servizio.  
Questo campo non è obbligatorio per un servizio Amazon ECS "client" che un membro di un namespace utilizza solo per connettersi ad altri servizi nel namespace. Un esempio può essere un'applicazione frontend che accetta richieste in arrivo da un bilanciatore del carico collegato al servizio o con altri mezzi.  
Un oggetto seleziona una porta dalla definizione dell'attività, assegna un nome al AWS Cloud Map servizio e una serie di alias (noti anche come endpoint) e porte alle applicazioni client per fare riferimento a questo servizio.    
`portName`  
Tipo: stringa  
Obbligatorio: sì  
`portName` deve corrispondere al `name` di una delle `portMappings` da tutti i container nella definizione di attività di questo servizio Amazon ECS.  
`discoveryName`  
▬Tipo: stringa  
Obbligatorio: no  
`discoveryName`È il nome del nuovo AWS Cloud Map servizio creato da Amazon ECS per questo servizio Amazon ECS. Deve essere univoco nel namespace AWS Cloud Map .  
Se questo campo non è specificato, viene utilizzato `portName`.  
`clientAliases`  
Tipo: matrice di oggetti   
Obbligatorio: no  
L'elenco degli alias client per questo servizio Service Connect. Si usano per assegnare nomi che possono essere utilizzati da applicazioni client. Il numero massimo di alias client che si può avere in questo elenco è 1.  
Ogni alias ("endpoint") è un nome DNS completo e un numero di porta che altre attività Amazon ECS ("client") possono utilizzare per connettersi a questo servizio.  
Ogni combinazione di nome e porta deve essere univoca nel namespace.  
Questi nomi sono configurati all'interno di ogni attività del servizio client, non in AWS Cloud Map. Le richieste DNS per risolvere questi nomi non lasciano l'attività e non vengono conteggiate ai fini della quota di richieste DNS al secondo per interfaccia di rete elastica.    
`port`  
Tipo: numero intero  
Obbligatorio: sì  
Il numero della porta di ascolto per il proxy Service Connect. Questa porta è disponibile all'interno di tutte le attività nello stesso namespace.  
Per evitare di modificare le applicazioni nei servizi client Amazon ECS, imposta la stessa porta utilizzata dall'applicazione client per impostazione predefinita.  
`dnsName`  
▬Tipo: stringa  
Obbligatorio: no  
Il `dnsName` è il nome utilizzato nelle applicazioni di attività client per connettersi a questo servizio. Il nome deve essere un'etichetta DNS valida.  
Se questo campo non viene specificato, il valore predefinito sarà `discoveryName.namespace`. Se il valore `discoveryName` non viene specificato, viene utilizzato il valore `portName` della definizione dell'attività.  
Per evitare di modificare le applicazioni nei servizi client Amazon ECS, imposta lo stesso nome utilizzato dall'applicazione client per impostazione predefinita. Ad esempio, alcuni nomi comuni sono `database`, `db` o il nome minuscolo di un database, ad esempio `mysql` o `redis`.  
`ingressPortOverride`  
Tipo: Integer  
Obbligatorio: no  
(Facoltativo) Il numero della porta di ascolto per il proxy Service Connect.  
Utilizza il valore di questo campo per ignorare il proxy per il traffico sul numero di porta specificato nella `portMapping` denominata nella definizione di attività di questa applicazione, quindi utilizzalo nei tuoi gruppi di sicurezza Amazon VPC per consentire il traffico nel proxy per questo servizio Amazon ECS.  
In modalità `awsvpc`, il valore predefinito è il numero di porta del container specificato nella `portMapping` nella definizione di attività di questa applicazione. In modalità `bridge`, il valore predefinito è la porta temporanea dinamica del proxy Service Connect.  
`logConfiguration`  
Tipo: oggetto [LogConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_LogConfiguration.html)  
Obbligatorio: no  
Questo definisce dove vengono pubblicati i log del proxy di Service Connect. Usa i log per il debug durante eventi imprevisti. Questa configurazione imposta il parametro `logConfiguration` nel container del proxy Service Connect in ogni attività di questo servizio Amazon ECS. Il container del proxy non è specificato nella definizione di attività.  
Ti consigliamo di utilizzare la stessa configurazione di log dei container delle applicazioni della definizione di attività per questo servizio Amazon ECS. Infatti FireLens, questa è la configurazione del registro del contenitore dell'applicazione. Non è il contenitore del FireLens log router che utilizza l'immagine del `fluentd ` contenitore `fluent-bit` or.  
`accessLogConfiguration`  
Tipo: [ServiceConnectAccessLogConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_LogConfiguration.html)oggetto  
Obbligatorio: no  
La configurazione per la registrazione degli accessi di Service Connect, incluso il formato del registro e se i registri devono includere stringhe di query. I registri di accesso raccolgono informazioni dettagliate sulle richieste effettuate al servizio, inclusi i modelli di richiesta, il codice di risposta e i dati temporali. Per abilitare i registri di accesso, è inoltre necessario specificare un in`logConfiguration`. `serviceConnectConfiguration`

`serviceRegistries`  
Tipo: matrice di oggetti   
Obbligatorio: no  
I dettagli della configurazione dell'individuazione per il tuo servizio. Per ulteriori informazioni, consultare [Usare il rilevamento servizi per connettere i servizi Amazon ECS con nomi DNS](service-discovery.md).  
Quando si aggiorna un servizio, questo parametro innesca una nuova implementazione del servizio.    
`registryArn`  
▬Tipo: stringa  
Obbligatorio: no  
Il nome della risorsa Amazon (ARN) del registro del servizio. Il registro dei servizi attualmente supportato è AWS Cloud Map. Per ulteriori informazioni, consultare [Working with Services](https://docs.aws.amazon.com/cloud-map/latest/dg/working-with-services.html) nella *Guida per gli sviluppatori di AWS Cloud Map *.  
`port`  
Tipo: Integer  
Obbligatorio: no  
Il valore della porta utilizzato se l'individuazione dei servizi ha specificato un record SRV. Questo campo è obbligatorio se vengono utilizzati entrambi la modalità di rete `awsvpc` e i record SRV.  
`containerName`  
▬Tipo: stringa  
Obbligatorio: no  
Il valore che indica il nome del container da utilizzare per l'individuazione del servizio. Questo valore è specificato nella definizione dell'attività. Se la definizione di attività specificata dall'attività del servizio utilizza le modalità di rete `bridge` o `host`, devi specificare una combinazione di `containerName` e `containerPort` nella definizione di attività. Se la definizione di attività specificata dall'attività del servizio utilizza la modalità di rete `awsvpc` e utilizzi un record tipo DNS SRV, devi specificare una combinazione di `containerName` e `containerPort` o un valore `port`, ma non entrambi.  
`containerPort`  
Tipo: Integer  
Obbligatorio: no  
Il valore della porta da utilizzare per l'individuazione del servizio. Questo valore è specificato nella definizione dell'attività. Se la definizione di attività specificata dall'attività del servizio utilizza le modalità di rete `bridge` o `host`, devi specificare una combinazione di `containerName` e `containerPort` nella definizione di attività. Se la definizione di attività specificata dall'attività del servizio utilizza la modalità di rete `awsvpc` e utilizzi un record tipo DNS SRV, devi specificare una combinazione di `containerName` e `containerPort` o un valore `port`, ma non entrambi.

## Token client
<a name="sd-clienttoken"></a>

`clientToken`  
▬Tipo: stringa  
Obbligatorio: no  
L'identificatore univoco (con distinzione tra maiuscole e minuscole) che fornisci per assicurare l'idempotenza della richiesta. Può contenere fino a 32 caratteri ASCII.

## Ribilanciamento della zona di disponibilità
<a name="sd-availability-zone-rebalancing"></a>

`availabilityZoneRebalancing`  
▬Tipo: stringa  
Obbligatorio: no  
Indica se il servizio utilizza il ribilanciamento della zona di disponibilità. I valori validi sono `ENABLED` e `DISABLED`.  
Quando si aggiorna un servizio, questo parametro non innesca una nuova implementazione del servizio.  
Comportamento predefinito:  
+ Per i nuovi servizi: se non viene specificato alcun valore, il valore predefinito è `DISABLED`.
+ Per i servizi esistenti: se non viene specificato alcun valore, Amazon ECS imposta il valore predefinito sul valore esistente. Se in precedenza non è stato impostato alcun valore, Amazon ECS lo imposta su `DISABLED`.
Per ulteriori informazioni sul ribilanciamento delle zone di disponibilità, consultare [Bilanciamento di un servizio Amazon ECS tra zone di disponibilità](service-rebalancing.md).

## Configurazioni del volume
<a name="sd-volumeConfigurations"></a>

`volumeConfigurations`  
Tipo: oggetto  
Obbligatorio: no  
La configurazione che verrà utilizzata per creare volumi per le attività gestite dal servizio. Solo i volumi contrassegnati come `configuredAtLaunch` nella definizione dell'attività possono essere configurati utilizzando questo oggetto.  
Quando si aggiorna un servizio, questo parametro innesca una nuova implementazione del servizio.  
Questo oggetto è necessario per collegare i volumi Amazon EBS alle attività gestite da un servizio. Per ulteriori informazioni, consultare [Usare i volumi Amazon EBS con Amazon ECS](ebs-volumes.md).    
`name`  
Tipo: stringa  
Obbligatorio: sì  
Il nome di un volume configurato durante la creazione o l'aggiornamento di un servizio. Il nome può contenere un massimo di 255 lettere (maiuscole e minuscole), numeri, trattini (`_`) e caratteri di sottolineatura (`-`). Questo valore deve corrispondere al nome di volume specificato nella definizione dell'attività.  
`managedEBSVolume`  
Tipo: oggetto  
Obbligatorio: no  
La configurazione del volume utilizzata per creare volumi Amazon EBS collegati alle attività mantenute da un servizio al momento della creazione o dell'aggiornamento del servizio. Viene allegato un volume per ogni attività.    
`encrypted`  
Tipo: Booleano  
Obbligatorio: no  
Valori validi: `true`\$1`false`  
Specifica se crittografare ciascun volume Amazon EBS creato. Se hai attivato la crittografia Amazon EBS per impostazione predefinita per un determinato Regione AWS prodotto Account AWS ma hai impostato questo parametro su`false`, questo parametro verrà sovrascritto e i volumi verranno crittografati con la chiave KMS specificata per la crittografia per impostazione predefinita. Per ulteriori informazioni sulla crittografia di Amazon EBS per impostazione predefinita, consultare [Enable Amazon EBS encryption by default](https://docs.aws.amazon.com/ebs/latest/userguide/encryption-by-default.html) nella *Guida per l'utente di Amazon EBS*. Per ulteriori informazioni sulla crittografia dei volumi Amazon EBS collegati alle attività di Amazon ECS, consultare [Crittografia dei dati archiviati nei volumi Amazon EBS allegati alle attività Amazon ECS](ebs-kms-encryption.md).  
`kmsKeyId`  
▬Tipo: stringa  
Obbligatorio: no  
L'identificatore della chiave AWS Key Management Service (AWS KMS) da utilizzare per la crittografia Amazon EBS. Se `kmsKeyId` viene specificata, lo stato crittografato deve essere `true`.  
 La chiave specificata utilizzando questo parametro sostituisce la chiave KMS predefinita di Amazon EBS o qualsiasi chiave KMS a livello di cluster per la crittografia dell'archiviazione gestita di Amazon ECS che potrebbe essere stata specificata. Per ulteriori informazioni, consultare [Crittografia dei dati archiviati nei volumi Amazon EBS allegati alle attività Amazon ECS](ebs-kms-encryption.md).   
È possibile specificare la chiave KMS utilizzando una delle opzioni seguenti:  
+ **ID della chiave**: ad esempio, `1234abcd-12ab-34cd-56ef-1234567890ab`. 
+ **Alias della chiave**: ad esempio, `alias/ExampleAlias`.
+ **ARN della chiave**: ad esempio, `arn:aws:kms:us-east-1:012345678910:key/1234abcd-12ab-34cd-56ef-1234567890ab`.
+ **ARN dell'alias**: ad esempio, `arn:aws:kms:us-east-1:012345678910:alias/ExampleAlias`.
AWS autentica la chiave KMS in modo asincrono. Pertanto, se si specifica un ID, alias o ARN non valido, l'azione sembra essere completata, ma alla fine ha esito negativo. Per ulteriori informazioni, consultare [Troubleshooting Amazon EBS volume attachment issues](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/troubleshoot-ebs-volumes.html).  
`volumeType`  
▬Tipo: stringa  
Obbligatorio: no  
Valori validi: \$1 \$1 \$1 \$1 \$1 `gp2` `gp3` `io1` `io2` `sc1` `st1` `standard`  
Il tipo di volume di Amazon EBS. Per ulteriori informazioni sui tipi di volume, consultare [Amazon EBS volume types](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-volume-types.html) nella *Guida per l'utente di Amazon EBS*. Il tipo di volume di default è `gp3`.  
Il tipo di volume `standard` non è supportato per le attività Fargate.  
`sizeInGiB`  
Tipo: Integer  
Obbligatorio: no  
Intervallo valido: numeri interi compresi tra 1 e 16.384.   
La dimensione del volume EBS in gibibyte (GiB). Se non viene fornito un ID di snapshot per configurare un volume per l'allegato, è necessario fornire un valore di dimensione. Se viene configurato un volume per l'allegato utilizzando uno snapshot, il valore predefinito è la dimensione dello snapshot. È possibile specificare una dimensione maggiore o uguale a quella dello snapshot.  
Per i tipi di volume `gp2` e `gp3`, l'intervallo valido è 1-16.384.  
Per i tipi di volume `io1` e `io2`, l'intervallo valido è 4-16.384.  
Per i tipi di volume `st1` e `sc1`, l'intervallo valido è 125-16.384.  
Per il tipo di volume `standard`, l'intervallo valido è 1-1.024.  
`snapshotId`  
▬Tipo: stringa  
Obbligatorio: no  
L'ID di snapshot di un volume Amazon EBS esistente che Amazon ECS utilizza per creare nuovi volumi per il collegamento. È necessario specificare `snapshotId` o `sizeInGiB`.  
`volumeInitializationRate`  
Tipo: Integer  
Obbligatorio: no  
La velocità, in MiB/s, con cui i dati vengono recuperati da uno snapshot di un volume Amazon EBS esistente per creare nuovi volumi per il collegamento. Questa proprietà può essere specificata solo se si indica un `snapshotId`. Per ulteriori informazioni su questa velocità di inizializzazione dei volumi, compreso l'intervallo di velocità supportate, consultare [Initialize Amazon EBS volumes](https://docs.aws.amazon.com/ebs/latest/userguide/initalize-volume.html) nella *Guida per l'utente di Amazon EBS*.  
`iops`  
Tipo: Integer  
Obbligatorio: no  
Il numero di I/O operazioni al secondo (IOPS). Per volumi `gp3`, `io1` e `io2`, questo rappresenta il numero di IOPS che sono assegnate al volume. Per `gp2` i volumi, questo valore rappresenta la performance di base del volume e la velocità con cui il volume accumula I/O crediti per il bursting. Questo parametro è obbligatorio per i volumi `io1` e `io2`. Questo parametro non è supportato per volumi `gp2`, `st1`, `sc1` o `standard`.   
Per i volumi `gp3`, l'intervallo di valori valido è compreso tra 3.000 e 16.000.  
Per i volumi `io1`, l'intervallo di valori valido è compreso tra 100 e 64.000.  
Per i volumi `io2`, l'intervallo di valori valido è compreso tra 100 e 64.000.  
`throughput`  
Tipo: Integer  
Obbligatorio: no  
Il throughput per il provisioning dei volumi collegati alle attività mantenute da un servizio.  
Questo parametro è supportato solo per i volumi `gp3`.  
`roleArn`  
Tipo: stringa  
Obbligatorio: sì  
Il ruolo Amazon Resource ARN (ARN) dell'infrastruttura AWS Identity and Access Management (IAM) che fornisce le autorizzazioni Amazon ECS per gestire le risorse Amazon EBS per le tue attività. Per ulteriori informazioni, consulta [Ruolo IAM dell’infrastruttura Amazon ECS](infrastructure_IAM_role.md).  
`tagSpecifications`  
Tipo: oggetto  
Obbligatorio: no  
La specifica per i tag da applicare a ciascun volume di Amazon EBS.    
`resourceType`  
Tipo: stringa  
Obbligatorio: sì  
Valori validi: `volume`  
Il tipo di risorsa cui applicare tag al momento della creazione.  
`tags`  
Tipo: matrice di oggetti   
Obbligatorio: no  
I metadati applicati ai volumi per aiutare a categorizzarli e organizzarli. Ogni tag è composto da una chiave e da un valore opzionale, entrambi personalizzabili. `AmazonECSCreated` e `AmazonECSManaged` sono tag riservati che vengono aggiunti da Amazon ECS, quindi è possibile specificare un massimo di 48 tag personalizzati. Quando un volume viene eliminato, vengono eliminati anche i tag. Per ulteriori informazioni, consultare [Aggiunta di tag alle risorse Amazon ECS](ecs-using-tags.md).    
`key`  
Tipo: String  
Limitazioni di lunghezza: lunghezza minima pari a 1. La lunghezza massima è 128 caratteri.  
Obbligatorio: no  
Una parte di una coppia chiave-valore che costituisce un tag. Una chiave è un'etichetta generale che funge da categoria per più valori di tag specifici.  
`value`  
Tipo: String  
Limitazioni di lunghezza: lunghezza minima di 0. La lunghezza massima è 256 caratteri.  
Obbligatorio: no  
La parte facoltativa di una coppia chiave-valore che costituisce un tag. Un valore agisce come descrittore all'interno di una categoria di tag (chiave).  
`propagateTags`  
Tipo: String  
Valori validi: `TASK_DEFINITION` \$1 `SERVICE` \$1 `NONE`  
Obbligatorio: no  
Specificare se copiare i tag dalla definizione di attività o dal servizio in un volume. Se `NONE` è specificato o non viene specificato alcun valore, i tag non vengono copiati.  
`fileSystemType`  
▬Tipo: stringa  
Obbligatorio: no  
Valori validi: \$1 \$1 \$1 `xfs` `ext3` `ext4` `NTFS`  
Il tipo di file system su un volume. Il tipo di file system del volume determina il modo in cui i dati vengono archiviati e recuperati nel volume. Per i volumi creati da una snapshot, è necessario specificare lo stesso tipo di file system utilizzato dal volume al momento della creazione della snapshot. Se c’è una mancata corrispondenza del tipo di file system, l’attività non verrà avviata.   
I valori validi per Linux sono `xfs`, ext3`, and ext4`. L'impostazione predefinita per i volumi collegati alle attività di Linux è `XFS`.  
I valori validi per Windows sono `NTFS`. L'impostazione predefinita per i volumi collegati alle attività di Windows è `NTFS`.

# Modello di definizione del servizio
<a name="sd-template"></a>

Di seguito viene illustrata la rappresentazione JSON di una definizione di servizio Amazon ECS.

EC2

```
{
    "cluster": "", 
    "serviceName": "", 
    "taskDefinition": "", 
    "loadBalancers": [
        {
            "targetGroupArn": "", 
            "loadBalancerName": "", 
            "containerName": "", 
            "containerPort": 0
        }
    ], 
    "serviceRegistries": [
        {
            "registryArn": "", 
            "port": 0, 
            "containerName": "", 
            "containerPort": 0
        }
    ], 
    "desiredCount": 0, 
    "clientToken": "", 
    "launchType": "EC2", 
    "capacityProviderStrategy": [
        {
            "capacityProvider": "", 
            "weight": 0, 
            "base": 0
        }
    ], 
    "platformVersion": "", 
    "role": "", 
    "deploymentConfiguration": {
        "deploymentCircuitBreaker": {
            "enable": true, 
            "rollback": true
        }, 
        "maximumPercent": 0, 
        "minimumHealthyPercent": 0, 
        "alarms": {
            "alarmNames": [
                ""
            ], 
            "enable": true, 
            "rollback": true
        }
    }, 
    "placementConstraints": [
        {
            "type": "distinctInstance", 
            "expression": ""
        }
    ], 
    "placementStrategy": [
        {
            "type": "binpack", 
            "field": ""
        }
    ], 
    "networkConfiguration": {
        "awsvpcConfiguration": {
            "subnets": [
                ""
            ], 
            "securityGroups": [
                ""
            ], 
            "assignPublicIp": "DISABLED"
        }
    }, 
    "healthCheckGracePeriodSeconds": 0, 
    "schedulingStrategy": "REPLICA", 
    "deploymentController": {
        "type": "EXTERNAL"
    }, 
    "tags": [
        {
            "key": "", 
            "value": ""
        }
    ], 
    "enableECSManagedTags": true, 
    "propagateTags": "TASK_DEFINITION", 
    "enableExecuteCommand": true, 
    "availabilityZoneRebalancing": "ENABLED",
    "serviceConnectConfiguration": {
        "enabled": true, 
        "namespace": "", 
        "services": [
            {
                "portName": "", 
                "discoveryName": "", 
                "clientAliases": [
                    {
                        "port": 0, 
                        "dnsName": ""
                    }
                ], 
                "ingressPortOverride": 0
            }
        ], 
        "logConfiguration": {
            "logDriver": "journald", 
            "options": {
                "KeyName": ""
            }, 
            "secretOptions": [
                {
                    "name": "", 
                    "valueFrom": ""
                }
            ]
        }
    }, 
    "volumeConfigurations": [
        {
            "name": "", 
            "managedEBSVolume": {
                "encrypted": true, 
                "kmsKeyId": "", 
                "volumeType": "", 
                "sizeInGiB": 0, 
                "snapshotId": "", 
                "volumeInitializationRate": 0,
                "iops": 0, 
                "throughput": 0, 
                "tagSpecifications": [
                    {
                        "resourceType": "volume", 
                        "tags": [
                            {
                                "key": "", 
                                "value": ""
                            }
                        ], 
                        "propagateTags": "NONE"
                    }
                ], 
                "roleArn": "", 
                "filesystemType": ""
            }
        }
    ]
}
```

Fargate

```
{
    "cluster": "", 
    "serviceName": "", 
    "taskDefinition": "", 
    "loadBalancers": [
        {
            "targetGroupArn": "", 
            "loadBalancerName": "", 
            "containerName": "", 
            "containerPort": 0
        }
    ], 
    "serviceRegistries": [
        {
            "registryArn": "", 
            "port": 0, 
            "containerName": "", 
            "containerPort": 0
        }
    ], 
    "desiredCount": 0, 
    "clientToken": "", 
    "launchType": "FARGATE", 
    "capacityProviderStrategy": [
        {
            "capacityProvider": "", 
            "weight": 0, 
            "base": 0
        }
    ], 
    "platformVersion": "", 
    "platformFamily": "",
    "role": "", 
    "deploymentConfiguration": {
        "deploymentCircuitBreaker": {
            "enable": true, 
            "rollback": true
        }, 
        "maximumPercent": 0, 
        "minimumHealthyPercent": 0, 
        "alarms": {
            "alarmNames": [
                ""
            ], 
            "enable": true, 
            "rollback": true
        }
    }, 
    "placementStrategy": [
        {
            "type": "binpack", 
            "field": ""
        }
    ], 
    "networkConfiguration": {
        "awsvpcConfiguration": {
            "subnets": [
                ""
            ], 
            "securityGroups": [
                ""
            ], 
            "assignPublicIp": "DISABLED"
        }
    }, 
    "healthCheckGracePeriodSeconds": 0, 
    "schedulingStrategy": "REPLICA", 
    "deploymentController": {
        "type": "EXTERNAL"
    }, 
    "tags": [
        {
            "key": "", 
            "value": ""
        }
    ], 
    "enableECSManagedTags": true, 
    "propagateTags": "TASK_DEFINITION", 
    "enableExecuteCommand": true, 
    "availabilityZoneRebalancing": "ENABLED",
    "serviceConnectConfiguration": {
        "enabled": true, 
        "namespace": "", 
        "services": [
            {
                "portName": "", 
                "discoveryName": "", 
                "clientAliases": [
                    {
                        "port": 0, 
                        "dnsName": ""
                    }
                ], 
                "ingressPortOverride": 0   
            }
        ], 
        "logConfiguration": {
            "logDriver": "journald", 
            "options": {
                "KeyName": ""
            }, 
            "secretOptions": [
                {
                    "name": "", 
                    "valueFrom": ""
                }
            ]
        }
    }, 
    "volumeConfigurations": [
        {
            "name": "", 
            "managedEBSVolume": {
                "encrypted": true, 
                "kmsKeyId": "", 
                "volumeType": "", 
                "sizeInGiB": 0, 
                "snapshotId": "", 
                "volumeInitializationRate": 0, 
                "iops": 0, 
                "throughput": 0, 
                "tagSpecifications": [
                    {
                        "resourceType": "volume", 
                        "tags": [
                            {
                                "key": "", 
                                "value": ""
                            }
                        ], 
                        "propagateTags": "NONE"
                    }
                ], 
                "roleArn": "", 
                "filesystemType": ""
            }
        }
    ]
}
```

È possibile creare questo modello di definizione del servizio utilizzando il comando AWS CLI seguente.

```
aws ecs create-service --generate-cli-skeleton
```