Le migliori pratiche per le immagini dei container Amazon ECS

Un'immagine del container è un insieme di istruzioni su come creare il container. Un'immagine del container contiene il codice dell'applicazione e tutte le dipendenze necessarie per l'esecuzione di tale codice. Le dipendenze dell'applicazione includono i pacchetti di codice sorgente su cui si basa il codice dell'applicazione, un runtime del linguaggio per i linguaggi interpretati e i pacchetti binari su cui si basa il codice collegato dinamicamente.

Utilizza le linee guida seguenti per progettare e creare le immagini dei container:

• Rendi complete le immagini del container, archiviando tutte le dipendenze dell'applicazione come file statici all'interno dell'immagine del container.

  Se modifichi qualcosa nell'immagine del contenitore, crea una nuova immagine del contenitore con le modifiche.

• Esegui un singolo processo di applicazione all'interno di un container.

  La durata del container è pari a quella del processo di applicazione. Amazon ECS sostituisce i processi bloccati e determina dove avviare il processo di sostituzione. Un'immagine completa rende l'implementazione complessiva più resiliente.

• Fai in modo che sia la tua applicazione a gestire. SIGTERM

  Quando Amazon ECS interrompe un'attività, invia innanzitutto un segnale SIGTERM all'attività per notificare all'applicazione che deve essere completata e chiusa. Amazon ECS invia quindi un SIGKILL messaggio. Quando le applicazioni lo ignoranoSIGTERM, il servizio Amazon ECS deve attendere l'invio del SIGKILL segnale per terminare il processo.

  Devi identificare il tempo impiegato dall'applicazione per completare il suo lavoro e assicurarti che le applicazioni gestiscano il segnale. SIGTERM La gestione del segnale dell'applicazione deve impedire all'applicazione di eseguire nuovi lavori e completare il lavoro in corso, oppure salvare il lavoro incompiuto in un archivio esterno all'attività quando il completamento del lavoro richiede troppo tempo.

• Configura le applicazioni containerizzate per la scrittura di log su stdout e stderr.

  Il disaccoppiamento della gestione dei log dal codice dell'applicazione offre la flessibilità necessaria per adattare la gestione dei log a livello di infrastruttura. Un esempio di ciò è la modifica del sistema di registrazione. Invece di modificare i servizi e creare e distribuire una nuova immagine del contenitore, puoi modificare le impostazioni.

• Usa i tag per controllare le versioni delle immagini dei container.

  Le immagini dei container vengono archiviate in un registro dei container. Ogni immagine all'interno del registro è identificata da un tag. È presente un tag denominato latest. Questo tag funge da puntatore verso la versione più recente dell'immagine del container dell'applicazione, simile al comando HEAD in un repository git. Ti consigliamo di utilizzare il tag latest solo a scopo di test. Come best practice, assegna alle immagini del container un tag univoco per ogni build. Ti consigliamo di assegnare i tag alle immagini tramite SHA git per il commit git usato per creare l'immagine.

  Non è necessario creare un'immagine di container per ogni commit. Tuttavia, ti consigliamo di creare una nuova immagine del container ogni volta che rilasci un particolare commit di codice nell'ambiente di produzione. Ti consigliamo inoltre di assegnare all'immagine un tag che corrisponda al commit git del codice presente nell'immagine. Se hai assegnato all'immagine un commit git, puoi trovare più rapidamente la versione del codice in esecuzione sull'immagine.

  Ti consigliamo inoltre di attivare i tag di immagine immutabili in Amazon Elastic Container Registry. Con questa impostazione, non puoi modificare l'immagine del container a cui punta un tag. Amazon ECR impone invece che una nuova immagine debba essere caricata su un nuovo tag. Per ulteriori informazioni, consulta Mutabilità del tag immagine nella Guida per l'utente di Amazon ECR.

Quando si progetta l'applicazione in modo che venga eseguita AWS Fargate, è necessario decidere se distribuire più contenitori nella stessa definizione di attività e distribuire contenitori separatamente in più definizioni di attività. Quando sono necessarie le seguenti condizioni, si consiglia di implementare più container nella stessa definizione di attività:

• I container condividono un ciclo di vita comune (ovvero vengono avviati e terminati contemporaneamente).

• I container devono essere eseguiti sullo stesso host sottostante (ovvero, un container che fa riferimento all'altro su una porta localhost).

• I container condividono le risorse.

• I tuoi container condividono volumi di dati.

Se queste condizioni non sono richieste, si consiglia di implementare i container separatamente in più definizioni di attività. Ciò consente di scalare, effettuare il provisioning e il deprovisioning dei contenitori separatamente.