Aggiornare i parametri del servizio Amazon ECS - Amazon Elastic Container Service
Considerazioni su AWS CDK

Aggiornare i parametri del servizio Amazon ECS

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 dell'implementazione include gli allarmi CloudWatch e l'interruttore automatico utilizzato 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 implementazioni dei servizi Amazon ECS.

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.

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 da implementazioni blu/verdi CodeDeploy (CODE_DEPLOY) a blu/verdi o in sequenza ECS (ECS).

  • Aggiornamento da implementazioni blu/verdi CodeDeploy (CODE_DEPLOY) a implementazioni esterne (EXTERNAL).

  • Aggiornamento da implementazioni blu/verdi o in sequenza ECS (ECS) a implementazioni esterne (EXTERNAL).

  • Aggiornamento da implementazioni esterne (EXTERNAL) a implementazioni blu/verdi o in sequenza ECS (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.

  • 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, consultare UpdateService e CreateService nella Documentazione di riferimento API di Amazon ECS.

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

  • 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, consultare LoadBalancer e AdvancedConfiguration nella Documentazione di riferimento dell'API Amazon ECS.

Quando si aggiorna il controller di implementazione per un servizio utilizzando CloudFormation, considerare quanto segue a seconda del tipo di migrazione in esecuzione.

  • Se si dispone di modello CloudFormation che contiene le informazioni del controller di implementazione EXTERNAL, nonché le risorse TaskSet e PrimaryTaskSet, e si rimuovono le risorse del set di attività dal modello durante l'aggiornamento da EXTERNAL a ECS, le chiamate API DescribeTaskSet e DeleteTaskSet restituiranno un errore 400 dopo che il controller di implementazione è stato aggiornato a ECS. Ciò determina un errore di eliminazione di CloudFormation sulle risorse del set di attività, anche se lo stack di CloudFormation passa allo stato UPDATE_COMPLETE. Per ulteriori informazioni, consultare Resource removed from stack but 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à, consultare DeleteTaskSet nella Documentazione di riferimento API di Amazon Elastic Container Service.

  • Se si sta effettuando una migrazione da CODE_DEPLOY a ECS con una nuova definizione di attività e CloudFormation esegue un'operazione di rollback, la richiesta di Amazon ECS UpdateService 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à, consultare DeleteTaskSet nella Documentazione di riferimento API di Amazon Elastic Container Service.

Conteggio 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 implementazioni blu/verdi, è possibile aggiornare i gruppi di destinazione di bilanciamento del carico elastico utilizzando CreateDeployment tramite CodeDeploy. Per le implementazioni blu/verdi, non sono supportati più gruppi di destinazione. Per ulteriori informazioni, consultare Register multiple target groups with a service.

Per i servizi che utilizzano il controller di implementazione esterno, è possibile aggiungere, aggiornare o rimuovere i bilanciatori del carico utilizzando CreateTaskSet. Per le implementazioni esterne, non sono supportati più gruppi di destinazione. Per ulteriori informazioni, consultare Register multiple target groups with a service.

Passare un elenco vuoto per rimuovere i bilanciatori del carico

È possibile modificare questo parametro per le implementazioni in sequenza.

Configurazione di 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.

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 sistema di bilanciamento 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:

È 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 dimensione, tipo di volume, IOPS, throughput, snapshot e crittografia in ServiceManagedEBSVolumeConfiguration. 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. Ciò definisce il modo in cui il servizio si integra con VPC Lattice per la comunicazione da servizio a servizio.

È possibile modificare questo parametro per le implementazioni in sequenza.

Considerazioni su AWS CDK

Il 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, consultare Customize constructs from the AWS Construct Library nella Guida per sviluppatori di 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.

  2. 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?.

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

  2. Aggiungere il costrutto capacityProviderStrategies?.

  3. Distribuire il servizio.