Contenitori CI / CD semplici in AWS

Sto usando AWS Code Pipeline, Code Build per creare un nuovo contenitore Docker e trasferirlo in ECR.

La mia applicazione è un semplice contenitore semplice basato su semplice. Quale sarebbe l'approccio meno attrito per abbattere l'attuale contenitore in esecuzione e rilanciare un nuovo contenitore dal registro ECS (output di Code Build tramite Code Pipeline).

Ho provato CloudFormation con dati utente EC2, script personalizzati su un lato e CloudFormation con ECS con la definizione delle attività sull'altro lato (non ancora riuscita). Sono fermamente convinto che ci debba essere un approccio più ovvio e più semplice.

Terrei le istanze del contenitore ECS (sto parlando degli host Docker - non mi piace la terminologia AWS qui) e la distribuzione come due cose separate.

Ottieni il tuo stack ECS attivo e funzionante. Puoi gestirlo tramite i gruppi CloudFormation e Auto-scaling, va bene. Basti pensare a cluster come una piattaforma in cui verrà distribuito a , non è qualcosa che è necessario ridistribuire .

Quindi, per i CD, il metodo più semplice è di gran lunga aggiornare la definizione del servizio per utilizzare una nuova definizione di attività e consentire a ECS rolling di aggiornare i contenitori.

Ogni volta che avvia un'attività, ECS eseguirà la finestra mobile pull image: tag anche se ha l'immagine localmente per assicurarsi che abbia l'ultima versione di quell'immagine: tag. Quindi il tag immagine che usi davvero non ha importanza (non è necessario cambiare il tag su ogni build).

Ciò significa che puoi creare myimage: le ultime novità più volte per distribuirle facilmente.

Ciò di cui hai bisogno è una definizione di attività in cui image = myimage: latest. Crea un servizio con quella definizione di attività e ogni volta che ECS avvia un'attività (un'istanza del tuo servizio) sarà il "myimage: latest" più recente che hai creato.

Da lì, ti manca solo un pezzo del puzzle, da CodeDeploy, puoi chiamare qualcosa, forse una funzione lambda, per creare una nuova revisione della definizione dell'attività e aggiornare il tuo servizio e ECS creerà automaticamente nuove attività per quella revisione e rimuovere i vecchi compiti.

Un esempio:

Supponiamo che tu abbia creato un servizio chiamato MyService. Che il servizio è stato configurato per l'esecuzione di 2 attività per la definizione dell'attività MyTaskDefinition: 1 (revisione 1). In quella definizione di attività, hai una definizione di contenitore quale immagine è impostata su "myimage: latest".

1. Ieri hai creato myimage: ultimo che aveva l'ID (SHA) 365d8f7bf565.
2. L'istanza del contenitore ABC sta eseguendo un'attività denominata MyTaskDefinition- 1 -containerName-someLongId. quando si ispeziona quel contenitore, viene eseguita l'immagine "sha256: 365d8f7bf565 .........."
3. L'altra istanza del contenitore DEF sta eseguendo un'altra attività. Ha un nome simile (solo l'ID differisce), ma esegue la stessa immagine.
4. Spingi una modifica al tuo repository.
5. CodePipeline rileva tale modifica, crea e pubblica l'immagine in ECR.
6. Quella nuova immagine Docker è anche myimage: ultima, ma il suo ID (SHA) è f7ec5e54ac96
7. Ora è necessario aggiungere un passaggio alla pipeline per utilizzare le funzioni Lambda e l'SDK AWS NodeJS per effettuare alcune chiamate al cluster:
   1. Crea una nuova definizione di attività (che sarà esattamente la stessa di prima). Questa sarà MyTaskDefinition: 2
   2. Aggiorna il tuo MyService per utilizzare MyTaskDefinition: 2 (anziché 1)
8. ECS creerà nuove attività. I nomi dei contenitori saranno MyTaskDefinition- 2 -containerName-someLongId. Quando ispezionerai quei contenitori, vedrai che eseguiranno "sha256: f7ec5e54ac96 .......". Forse avrai 2 compiti sull'istanza del contenitore ABC, forse saranno spruzzati (dipende dalla configurazione del tuo servizio)
9. Dopo qualche tempo ECS rimuoverà la vecchia attività MyTaskDefinition-1-containerName-someLongId da ABC e DEF.

Nota: in realtà non è necessario creare una nuova definizione di attività. Se lo desideri, puoi invece recuperare l'elenco delle attività del servizio e interromperle manualmente una ad una. È necessario attendere che ECS riavvii un'attività prima di interrompere una nuova (ovvero: arrestare il primo contenitore, attendere che ECS lo sostituisca, arrestare il secondo contenitore). Quando ECS riavvia il contenitore, afferrerà il myimage più recente: l'ultimo costruito, come spiegato in precedenza. Penso solo che la creazione di una nuova definizione di attività sia più semplice e meno soggetta a errori (nessuna logica richiesta per attendere e controllare, ECS gestirà l'aggiornamento a rotazione per te se hai una nuova definizione di attività).

Per un semplice caso d'uso descritto, suggerirei di controllare Elastic Beanstalk per Docker, non è la soluzione minima come l'utilizzo ECS nudo, ma puoi beneficiare di servizi autogestiti e configurati come ELB, EC2 AutoScale, monitoraggio dello stato e molto altro.

Riepilogo di alto livello:

1. Configura Elastic Beanstalk per utilizzare il tag myimage specifico: testato
2. Utilizza Code Pipeline / Build per creare, testare e promuovere il tag "testato"
3. Attiva la distribuzione di Elastic Beanstalk, che attirerà il myimage dell'immagine promossa: testato per tutte le istanze, disponibili diverse strategie di distribuzione.

Questo approccio basato sul riutilizzo dello stesso tag, un approccio alternativo sarebbe la generazione di tag con ID build, ad esempio myimage: test-42, ciò richiederà l'aggiornamento di Elastic Beanstalk ogni volta con un nuovo tag, ma fornisce un controllo più granulare sulla revisione distribuita.

In secondo luogo elastico beanstalk per la sua semplicità; è molto facile da installare e distribuire.

Se hai familiarità con docker-compose, un altro approccio potrebbe essere quello di definire docker-compose.yml e distribuirlo direttamente su ECS con ecs-cli.