{"id":1839,"date":"2020-10-16T12:00:00","date_gmt":"2020-10-16T10:00:00","guid":{"rendered":"https:\/\/blog.besharp.it\/?p=1839"},"modified":"2021-03-17T15:28:04","modified_gmt":"2021-03-17T14:28:04","slug":"strategie-di-rilascio-con-amazon-ecs-il-blue-green-deployment","status":"publish","type":"post","link":"https:\/\/blog.besharp.it\/it\/strategie-di-rilascio-con-amazon-ecs-il-blue-green-deployment\/","title":{"rendered":"Strategie di rilascio con Amazon ECS: il blue\/green deployment."},"content":{"rendered":"\n
L’architettura a microservizi<\/strong> \u00e8 diventata ormai predominante in molti progetti software. Grazie ai suoi enormi vantaggi in termini di velocit\u00e0 di sviluppo e di deploy, agevola i task quotidiani dei DevOps e non solo.<\/p>\n\n\n\n Per sfruttare questo pattern architetturale su AWS possiamo utilizzare Amazon Elastic Container Service (Amazon ECS)<\/strong>, un servizio di orchestrazione dei container completamente gestito.<\/p>\n\n\n\n ECS \u00e8 una grande scelta per l’esecuzione dei container per diverse ragioni. Per prima cosa, permette di scegliere di eseguire i cluster ECS utilizzando AWS Fargate, un\u2019infrastruttura serverless per container. Fargate rimuove la necessit\u00e0 di effettuare il provisioning e la gestione dei server, permettendoci di pagare solo per le risorse utilizzate per ciascuna applicazione.<\/p>\n\n\n\n Inoltre, ECS pu\u00f2 essere integrato in modo nativo con altri servizi come Amazon Route 53, Secrets Manager, AWS Identity and Access Management (IAM) e Amazon CloudWatch.<\/p>\n\n\n\n Gestire architetture a microservizi su ECS non \u00e8 sempre banale. Sul nostro blog abbiamo gi\u00e0 parlato di come creare e gestire cluster e implementare pipeline di CI\/CD per ECS.<\/p>\n\n\n\n In questo articolo andremo invece a vedere un aspetto fondamentale per la continuous integration<\/strong> del software, ovvero le diverse modalit\u00e0 di rilascio dei nuovi pacchetti software. In particolare, ci focalizzeremo sulla metodologia blue\/green<\/strong>, una tecnica relativamente nuova che risolve molti dei problemi presenti con altre modalit\u00e0 di deployment pi\u00f9 semplici.<\/p>\n\n\n\n Ad oggi esistono numerose strategie di deployment. Vediamo insieme quelle pi\u00f9 diffuse e supportate da ECS:<\/p>\n\n\n\n Ovviamente sta a noi decidere quale tipologia scegliere in base alle nostre esigenze. Sfruttando i vantaggi del Cloud pu\u00f2 convenire prediligere una tipologia blue\/green o canary rispetto ad una rolling update per evitare downtime e avere rapidi time di rollback nel caso ce ne fosse la necessit\u00e0. Ad oggi, implementare queste nuove tipologie di deployment \u00e8 relativamente semplice e a costo bassissimo, soprattutto se si usano tecnologie serverless come ECS in modalit\u00e0 Fargate!<\/p>\n\n\n\n Lo scopo di questo articolo \u00e8 analizzare step-by-step come realizzare una gestione di blue\/green deployment su ECS<\/strong>. Prima di iniziare, per\u00f2, \u00e8 necessario soddisfare i alcuni requisiti:<\/p>\n\n\n\n Iniziamo descrivendo il building-block<\/em> fondamentale per la nostra architettura a micro-servizi: un’immagine Docker. In questo step potete utilizzare una vostra immagine di preferenza, o una su cui state gi\u00e0 lavorando per il vostro progetto. Nel nostro caso, al fine del tutorial, abbiamo realizzato una semplice applicazione Node.js per servire un web server (utilizzando Express) in ascolto sulla porta 3000 che serve 2 API.<\/p>\n\n\n\n Come potete notare, abbiamo esposto un API di health check sotto la route health.<\/em> Se state usando una vostra immagine Docker, \u00e8 necessario che inseriate questa, o un\u2019altra rotta di health check, in quanto sar\u00e0 uno step fondamentale in fase di deployment per valutare se la nostra nuova versione software sia \u201chealthy\u201d o meno.<\/p>\n\n\n\n Come tutte le applicazioni Node.js, non pu\u00f2 mancare il file package.json:<\/p>\n\n\n\n Perfetto, il nostro micro-servizio \u00e8 pronto! Non ci resta che fare la build dell\u2019immagine Docker e salvarla su AWS. Anche qui, per scopo puramente dimostrativo, utilizziamo un Dockerfile molto semplice (esatto, i pi\u00f9 esperti sanno bene che l\u2019immagine creata potrebbe essere notevolmente snellita!):<\/p>\n\n\n\n Creiamo un repository su Elastic Container Registry (ECR) per ospitare le nostre immagini Docker. Attraverso la Console l\u2019operazione \u00e8 molto semplice. Aprendo il repository appena creato possiamo accedere alla sezione \u201cView push commands\u201d per ottenere i comandi necessari a buildare e pushare la nostra immagine Docker su ECS.<\/p>\n\n\n\n Ad operazione conclusa, dovreste vedere questo in Console:<\/p>\n\n\n\n A questo punto dobbiamo configurare la Task Definition, l\u2019unit\u00e0 di calcolo fondamentale di ECS che ospiter\u00e0 i nostri container Docker.<\/p>\n\n\n\n Per ora possiamo assegnare i ruoli di default sia al Task Role<\/em> che al Task Execution Role<\/em> dal momento che sono sufficienti per le operazioni che dobbiamo svolgere. Successivamente creiamo un container e lo associamo all\u2019immagine Docker, precedentemente salvata su ECR, configurando opportunamente la vCPU e la memoria da riservare. Non dimenticate di esporre la porta 3000 dal container!<\/p>\n\n\n\n Il risultato finale della Task Definition appena creata sar\u00e0 come segue:<\/p>\n\n\n\n Concludiamo questa fase con la creazione del Service.<\/p>\n\n\n\n Procedendo tramite Console, nella prima pagina \u00e8 necessario selezionare \u201cblue\/green deployment\u201d. Fate attenzione a questo passaggio, nel caso in cui doveste selezionare \u201cRolling update\u201d dovrete cancellare e ricreare il Service siccome l\u2019opzione non sar\u00e0 pi\u00f9 modificabile:<\/p>\n\n\n\n Nelle sezioni successive potete inserite i dati delle vostre VPC, subnet e security group.<\/p>\n\n\n\n \u00e8 il momento di utilizzare l’Application Load Balancer creato in fase di definizione dei prerequisiti. CodeDeploy ci richiede infatti di indicare l’Application Load Balancer, i Listener e i Target Group da utilizzare per la gestione del blue\/green deployment.<\/p>\n\n\n\n Bene, non ci resta che provare un deploy!<\/p>\n\n\n\n Aprendo la pagina di CodeDeploy notiamo che \u00e8 stata creata un\u2019Applicazione insieme ad un Deployment Configuration Group. Questi componenti sono gi\u00e0 stati configurati per noi in fase di creazione del service ECS. Per poter avviare un deployment \u00e8 necessario fornire un file yaml con una sintassi ben precisa, consultabile sulla documentazione di AWS(https:\/\/docs.aws.amazon.com\/codedeploy\/latest\/userguide\/reference-appspec-file.html<\/a>).Nel nostro caso, andiamo a definire nel file appspec.yaml <\/em>l\u2019entry point del Service ECS insieme alla versione della task definition<\/em> da utilizzare:<\/p>\n\n\n\n Ricordatevi di sostituire <TASK_DEFINITION> con l\u2019arn del task definition che volete deployare. <\/p>\n\n\n\n Completata la configurazione, si atterra sulla pagina del deployment. Qui potete monitorare il suo andamento. Una volta che il nuovo task sar\u00e0 installato, vedrete una schermata simile a questa:<\/p>\n\n\n\n Su CodeDeploy potete monitorare l\u2019andamento del vostro deployment, capire se ci sono problemi durante l\u2019installazione del nuovo pacchetto software, analizzare la quantit\u00e0 di traffico sulla vecchia e sulla nuova infrastruttura, oltre ad avere la possibilit\u00e0 di effettuare un rollback qualora lo riteneste opportuno.<\/p>\n\n\n\n A questo punto il blue\/green deployment \u00e8 terminato. Potete decidere se effettuare rollback (se magari vi siete accorti che il nuovo applicativo non performa in modo corretto) o approvare direttamente la nuova versione del software.<\/p>\n\n\n\n Potete anche affidarvi totalmente al vostro sistema di rilascio senza dover promuovere o fare rollback manualmente. In questo caso, l\u2019infrastruttura \u201cblue\u201d verr\u00e0 automaticamente promossa, in caso di installazione andata a buon fine, dopo il tempo che avete configurato voi.<\/p>\n\n\n\n In questo articolo abbiamo visto come creare un Service ECS in grado di gestire rilasci in modalit\u00e0 blue\/green. La configurazione presentata pu\u00f2 essere agevolmente sostituita da una pipeline triggerata direttamente dal nostro sistema di versionamento GIT. In poche parole, da un semplice git push<\/em> possiamo rilasciare in modalit\u00e0 blue\/green il nuovo pacchetto software.<\/p>\n\n\n\n Volete scoprire come si fa? Seguiteci: prossimamente vedremo insieme come configurare una pipeline per gestire l’intero flusso di rilascio.<\/p>\n\n\n\n #Proud2beCloud<\/strong> vi da appuntamento a tra 14 giorni. <\/p>\n\n\n\n Arrivederci al prossimo deploy!<\/p>\n","protected":false},"excerpt":{"rendered":" L’architettura a microservizi \u00e8 diventata ormai predominante in molti progetti software. Grazie ai suoi enormi vantaggi in termini di velocit\u00e0 […]<\/p>\n","protected":false},"author":6,"featured_media":1866,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[241],"tags":[377,408,364,295],"class_list":["post-1839","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-devops","tag-amazon-ecs","tag-blue-green-deployment","tag-ci-cd","tag-continuous-integration"],"yoast_head":"\nStrategie di deployment<\/h2>\n\n\n\n
<\/figure><\/div>\n\n\n\n
<\/figure><\/div>\n\n\n\n
<\/figure>\n\n\n\n
<\/figure><\/div>\n\n\n\n
<\/figure><\/div>\n\n\n\n
Prerequisiti<\/h2>\n\n\n\n
Altrimenti, se volete utilizzare l\u2019approccio utilizzato in questo articolo, potete creare il vostro cluster ECS in modalit\u00e0 Fargate da console. Ecco come farlo<\/a>.<\/a><\/li><\/ul>\n\n\n\n<\/figure><\/div>\n\n\n\n
Immagine Docker<\/h2>\n\n\n\n
const express = require('express')\nconst app = express()\nconst port = 3000\n\napp.get('\/', (req, res) => res.send('Hello World!'))\napp.get('\/health', (req, res) => res.send('Health check status: ok'))\n\napp.listen(3000, () => console.log(`Example app listening at http:\/\/localhost:${port}`))\n<\/pre>\n\n\n\n
{\n \"name\": \"ecs-blue-green\",\n \"version\": \"1.0.0\",\n \"description\": \"\",\n \"main\": \"app.js\",\n \"scripts\": {\n \"test\": \"echo \\\"Error: no test specified\\\" && exit 1\"\n },\n \"author\": \"\",\n \"license\": \"ISC\",\n \"dependencies\": {\n \"express\": \"^4.17.1\"\n }\n}\n<\/pre>\n\n\n\n
FROM node:10\n\nCOPY . .\nRUN npm install\n\nEXPOSE 3000\nCMD [ \"node\", \"app.js\" ]\n<\/pre>\n\n\n\n
Push immagine Docker su ECR<\/h2>\n\n\n\n
<\/figure><\/div>\n\n\n\n
Configurazione ECS – Fargate<\/h2>\n\n\n\n
<\/figure><\/div>\n\n\n\n
<\/figure><\/div>\n\n\n\n
<\/figure>\n\n\n\n
Deploy<\/h2>\n\n\n\n
\nversion: 0.0\nResources:\n - TargetService:\n Type: AWS::ECS::Service\n Properties:\n TaskDefinition:
<\/figure>\n\n\n\n
<\/figure>\n\n\n\n
Conclusioni<\/h2>\n\n\n\n