{"id":1881,"date":"2020-10-30T10:53:58","date_gmt":"2020-10-30T09:53:58","guid":{"rendered":"https:\/\/blog.besharp.it\/?p=1881"},"modified":"2021-03-17T15:28:41","modified_gmt":"2021-03-17T14:28:41","slug":"come-creare-una-pipeline-di-continuous-deployment-su-aws-per-il-deploy-blue-green-su-ecs","status":"publish","type":"post","link":"https:\/\/blog.besharp.it\/it\/come-creare-una-pipeline-di-continuous-deployment-su-aws-per-il-deploy-blue-green-su-ecs\/","title":{"rendered":"Come creare una Pipeline di Continuous Deployment su AWS per il Deploy Blue\/Green su ECS."},"content":{"rendered":"\n
La Continuous Delivery<\/strong> \u00e8 oggi una delle pi\u00f9 note metodologie di rilascio del software. Grazie ad essa, qualsiasi commit che abbia superato la fase di test, potr\u00e0 essere rilasciato e distribuito in produzione in modo automatico.<\/p>\n\n\n\n Automatizzare le fasi di rilascio permette, tra gli altri vantaggi, di ottenere un flusso di lavoro impeccabile negli ambienti di sviluppo, test e produzione rendendo le distribuzioni semplici e sicure.<\/p>\n\n\n\n Nel nostro ultimo articolo<\/a> abbiamo parlato dei microservizi, dei loro vantaggi e di come configurare una distribuzione di tipo blue\/green su AWS<\/strong> per un servizio ECS.<\/p>\n\n\n\n Riassumendo, con la tecnica del blue\/green deployment la vecchia infrastruttura (blue) coesiste temporaneamente con la nuova infrastruttura (green). Dopo aver effettuato i test di integrazione\/validazione, l\u2019infrastruttura aggiornata verr\u00e0 promossa a produzione, il traffico verr\u00e0 reindirizzato con un processo totalmente seamless e la vecchia infrastruttura sar\u00e0 eliminata definitivamente.<\/p>\n\n\n\n Come promesso, con questo articolo faremo un passo avanti: vi mostreremo come automatizzare il processo definendo una pipeline di Continuous Deployment<\/strong> che, da un semplice git push, sar\u00e0 in grado di gestire in autonomia l’intero flusso di rilascio di un nuovo pacchetto software in modalit\u00e0 blue\/green su ECS.<\/p>\n\n\n\n Infine, come bonus, mostreremo come automatizzare i test<\/strong> sugli ambienti \u201cgreen\u201d e come semplificare la creazione di un boilerplate<\/strong> complesso di infrastruttura sfruttando il servizio AWS CloudFormation. Presto capiremo come potrebbe esserci utile. <\/p>\n\n\n\n Siete pronti? Si comincia! <\/p>\n\n\n\n Prima di entrare nel vivo della creazione della pipeline, occorre assicurarsi che tutti questi requisiti siano soddisfatti:<\/p>\n\n\n\n Per quest’ultimo prerequisito riassumiamo di seguito gli step che abbiamo descritto pi\u00f9 dettagliatamente nell\u2019articolo precedente. Se volete seguire la guida completa, leggete qui<\/a> prima di proseguire.<\/p>\n\n\n\n Spostiamoci sull\u2019account AWS e cerchiamo ECS utilizzando la barra di ricerca disponibile. Selezioniamo \u201cClusters\u201d nel pannello di sinistra e, nella finestra successiva, clicchiamo su \u201cCreate Cluster\u201d. Siccome utilizzeremo Fargate, manteniamo \u201cNetworking only\u201d come opzione e clicchiamo su \u201cnext\u201d.<\/p>\n\n\n\n Inseriamo un nome per il cluster che stiamo creando lasciando invariate le altre opzioni e, se vogliamo, aggiungiamo alcuni tag significativi. Clicchiamo su \u201cCreate\u201d per generare il nuovo cluster.<\/p>\n\n\n\n Occupiamoci ora della Task Definition che ospiter\u00e0 i nostri container Docker.<\/p>\n\n\n\n Andiamo su \u201cTask Definitions\u201d sotto al menu \u201cAmazon ECS\u201d, clicchiamo su \u201cCreate new Task Definition\u201d e selezioniamo \u201cFargate\u201d come mostrato nell\u2019immagine. Clicchiamo poi su \u201cNext Step\u201d.<\/p>\n\n\n\n Per il momento possiamo assegnare i ruoli di default sia al Task Role, che al Task Execution Role. Per le operazioni che andremo ad eseguire saranno sufficienti. Selezioniamo i valori minimi per Memoria e CPU (per questo esempio, 0.5GB e 0.25vCPU).<\/p>\n\n\n\n Creiamo ora un Container e associamolo all\u2019immagine Docker che abbiamo salvato su ECR (lo abbiamo spiegato qui<\/a>) configurando vCPU e memoria con gli stessi valori che abbiamo indicato nella Task Definition.<\/p>\n\n\n\n Selezioniamo \u201cAdd Container\u201d. <\/p>\n\n\n\n Nella sidebar impostiamo un nome per il container e per l\u2019Image Uri<\/strong>, apriamo una nuova Tab a spostiamoci sulla dashboard di ECR. Selezioniamo l’immagine creata in precedenza e copiamone l\u2019URL per inserirlo nel campo \u201cImage URI\u201d.<\/p>\n\n\n\n A questo punto, aggiungiamo 3000 <\/strong>per tpc protocol <\/strong>in <\/strong>\u201cPort mapping\u201d e lasciamo le altre opzioni invariate prima di cliccare su \u201cAdd\u201d.<\/p>\n\n\n\n Muoviamoci nel Cluster creato nel servizio ECS, clicchiamo sul suo nome e, sul fondo della dashboard, clicchiamo su \u201cCreate\u201d sotto la tab \u201cServices\u201d.<\/p>\n\n\n\n Configuriamo le opzioni cos\u00ec come mostrato:<\/p>\n\n\n\n 1. Launch Type: FARGATE<\/strong><\/p>\n\n\n\n 2. Task Definition: <YOUR_TASK_DEFINITION><\/strong><\/p>\n\n\n\n 3. Cluster: <YOUR_CLUSTER><\/strong><\/p>\n\n\n\n 4. Service Name: <A_NAME_FOR_THE_SERVICE><\/strong><\/p>\n\n\n\n 5. Number of Tasks: 1<\/strong><\/p>\n\n\n\n 6. Deployment Type: Blue\/Green<\/strong><\/p>\n\n\n\n 7. Deployment Configuration: CodeDeployDefault.ECSAllAtOnce<\/strong><\/p>\n\n\n\n 8. Service Role for CodeDeploy: <A_SUITABLE_ROLE_WITH_ECS_PERMISSIONS><\/strong><\/p>\n\n\n\n Lasciamo invariate le altre opzioni e clicchiamo su \u201cNext Step\u201d. Nella sezione successiva selezioniamo una VPC appropriata, una o pi\u00f9 subnet e abilitiamo \u201cauto-assign IP\u201d.<\/p>\n\n\n\n Occorre ora configurare un Application LoadBalancer per il nostro Cluster. Selezioniamone uno esistente oppure creiamone uno nuovo dalla console di EC2. Scegliamo poi il nostro Container assicurandoci che mostri la porta mappata. <\/p>\n\n\n\n Dopo aver selezionato il Container, clicchiamo su \u201cAdd to load balancer\u201d.<\/p>\n\n\n\n Indichiamo 8080 per \u201cProduction Listener Port\u201d e 8090 per \u201cTest Listener Port\u201d. Selezioniamo il nostro LoadBalancer target group come mostrato in figura (se non lo avete configurato prima, potete farlo ora in una nuova tab seguendo questa guida<\/a>).<\/p>\n\n\n\n Proseguiamo lasciando spento l\u2019autoscaling, per questo esempio non ci servir\u00e0. Dopo la revisione, il servizio \u00e8 creato!<\/p>\n\n\n\n Ora che abbiamo finalmente tutti i blocchi fondamentali per la nostra Pipeline, procediamo con la creazione!<\/p>\n\n\n\n Cominciamo con il \u201cpushare\u201d la nostra applicazione di prova sul nostro repository GitHub.<\/p>\n\n\n\n Andiamo poi sul nostro account AWS, selezionando AWS CodePipeline dalla lista dei servizi. Dalla dashboard clicchiamo su \u201cCreate pipeline\u201d.<\/p>\n\n\n\n Nella schermata seguente diamo un nome alla pipeline e, se non abbiamo gi\u00e0 un ruolo adeguato alle operazioni, lasciamo \u201cNew service role\u201d selezionato e le altre opzioni come default; clicchiamo su \u201cnext\u201d.<\/p>\n\n\n\n Nel source<\/strong> stage selezioniamo \u201cGitHub version 2\u201d e quindi connettiamoci al nostro repository GitHub. Seguiamo le istruzioni che ci verranno presentate dopo aver selezionato \u201cConnect to GitHub\u201d. Ricordiamoci di autorizzare solo il repository della nostra soluzione <\/strong>e di eseguire le operazioni come owner di quel repository,<\/strong> altrimenti non saremo in grado di completare il processo.<\/p>\n\n\n\n Dopo esserci connessi a GitHub, potremo completare i passaggi come mostrato di seguito, selezionando repository e branch:<\/p>\n\n\n\n Clicchiamo \u201cnext\u201d e potremo proseguire con lo stage di build dove creeremo il nostro progetto CodeDeploy da aggiungere alla pipeline.<\/p>\n\n\n\n Per mantenere il codice sempre aggiornato nella nostra pipeline, abbiamo bisogno di questo step per generare un\u2019immagine sempre aggiornata di Docker. <\/p>\n\n\n\n Cominciamo col dare un nome al nostro stage di<\/strong> Build<\/strong>, selezioniamo CodeBuild<\/strong> come \u201cAction provider\u201d, la region e SourceArtifact <\/strong>come \u201cInput Artifact\u201d.<\/p>\n\n\n\n Dobbiamo ora creare un nuovo progetto di build. Diamo un nome al progetto, quindi lasciamo Managed Image<\/strong> con tutte le propriet\u00e0 del container come suggerito. Proseguiamo cliccando <\/strong>(questo \u00e8 estremamente importante) su \u201cPrivileged option\u201d per permettere alla pipeline di generare le immagini Docker per noi. Verificate i vostri settaggi con l\u2019immagine sottostante:<\/p>\n\n\n\n Per l\u2019opzione di buildspec<\/strong>, selezioniamo l\u2019editor inline e copiamo questi comandi:<\/p>\n\n\n\n <\/p>\n\n\n\n Nota: in grassetto abbiamo evidenziato le variabili che dovete adeguare al vostro progetto.<\/p>\n\n\n\n Dopo aver copiato i comandi, cliccate \u201cok\u201d, quindi aggiungete il vostro progetto di Build allo stage.<\/p>\n\n\n\n Cominciamo selezionando \u201cAmazon ECS (Blue\/Green)\u201d alla voce \u201cDeploy Provider\u201d, la region voluta per il progetto, quindi clicchiamo su \u201cCreate application\u201d.<\/p>\n\n\n\n Diamo un nuovo nome al progetto e selezioniamo \u201cAmazon ECS\u201d come Compute Provider. Comparir\u00e0 la schermata di creazione di un nuovo Development Group.<\/p>\n\n\n\n Nominiamolo, dopodich\u00e9 selezioniamo, nell\u2019ordine:<\/p>\n\n\n\n – Un service role con permessi appropriati<\/p>\n\n\n\n – Il cluster ECS creato in precedenza<\/p>\n\n\n\n – Il servizio ECS creato in precedenza<\/p>\n\n\n\n – L\u2019Application Load Balancer creato prima con, rispettivamente, 8080 e TargetGroup 1 per produzione e 8090 e TargetGroup 2 per l\u2019ambiente di test<\/p>\n\n\n\n – Una strategia per il traffico; per il nostro esempio useremo \u201cSpecify when to reroute traffic\u201d e selezioneremo 5 minuti.<\/strong><\/p>\n\n\n\n Clicchiamo su \u201cCreate\u201d e torniamo a CodePipeline. Selezioniamo l\u2019applicazione CodeDeploy<\/strong> e il CodeDeploy deployment group<\/strong> appena creati.<\/p>\n\n\n\n Per \u201cInput Artifacts\u201d aggiungiamo BuildArtifact<\/strong> affianco a \u201cSourceArtifact\u201d.<\/p>\n\n\n\n Per Amazon ECS Task Definition<\/strong> e AWS CodeDeploy AppSpec file <\/strong>selezioniamo \u201cSource Artifact\u201d, dopodich\u00e9 aggiungiamo BuildArtifact e IMAGE come ultime opzioni. Clicchiamo su \u201cNext\u201d, facciamo la review e clicchiamo infine su \u201cCreate pipeline\u201d.<\/p>\n\n\n\n Ci siamo quasi: per completare la nostra pipeline abbiamo bisogno di aggiungere una task definition<\/strong> e un appspec.yml<\/strong> alla nostra applicazione.<\/p>\n\n\n\n Creiamo dunque un nuovo file appspec.yml <\/strong>nella root del progetto e aggiungiamo al suo interno questo codice:<\/p>\n\n\n\n Passiamo ora al file task definition.<\/p>\n\n\n\n Per questo useremo un trucco per semplificarne la creazione. Come ricorderete, abbiamo gi\u00e0 creato una task definition in fase di preparazione dei prerequisiti all\u2019inizio di questo articolo. Andiamo a recuperare quest’ultima da AWS e clicchiamo su \u201cEdit\u201d. Arriveremo all\u2019editor JSON. Copiamo il testo e incolliamolo in un nuovo file taskdef.json <\/strong>all’interno della root del nostro progetto. Fatto ci\u00f2, andiamo a modificare cos\u00ec le seguenti righe:3.”image”: “<IMAGE>” (rimuovere URL e mettere <Image>)<\/strong><\/p>\n\n\n\n Carichiamo la nuova versione del codice sul nostro repo.<\/p>\n\n\n\n Testiamo l\u2019applicazione prima di promuoverla a Produzione<\/p>\n\n\n\n Per verificare che tutto funzioni correttamente, apportiamo una piccola modifica al testo contenuto nella root principale dell\u2019applicazione, facciamo un commit e aspettiamo che la Pipeline esaurisca tutti i task. A questo punto, verifichiamo che solo l\u2019URL sulla porta 8090 riporti la modifica di test. Sulla porta 8080 dovremmo invece continuare a vedere la vecchia versione dell\u2019infrastruttura. Dopo 5-6 minuti (il tempo impostato per il routing del traffico), anche l\u2019ambiente di produzione dovrebbe aggiornarsi mostrando la versione corretta.<\/p>\n\n\n\n La nostra Pipeline funziona!<\/p>\n\n\n\n Bonus 1: automatizzare i test sull\u2019infrastruttura green<\/em> con AWS Lambda<\/p>\n\n\n\n Nella fase di rilascio \u00e8 possibile associare una o pi\u00f9 Lambda function col compito di verificare il buon funzionamento della nostra applicazione prima di promuovere la nuova versione in un ambiente di produzione. Questo procedimento lo si svolge durante la configurazione del Deployment lifecycle hooks. Occorrer\u00e0 solo aggiungere un Lambda hook a AfterAllowTraffic.<\/p>\n\n\n\n Seguite queste guide per un esempio di configurazione:<\/p>\n\n\n\n Uno dei prerequisiti necessari consisteva nella creazione di un cluster ECS e dei suoi componenti. Di tutta la configurazione, questo \u00e8 sicuramente uno dei passaggi pi\u00f9 complessi\u2026 ma che possiamo semplificare e addirittura rendere ripetibile! Come?<\/p>\n\n\n\n Creando un CloudFormation template!<\/p>\n\n\n\n Ecco un semplice snippet di esempio che vi aiuter\u00e0 ad impostarlo:<\/p>\n\n\n\n Questo snippet di codice \u00e8 puramente informativo; dovrete adattare da voi la parte di gestione dei parametri facendo riferimento alle specifiche del vostro progetto. In caso di necessit\u00e0 si pu\u00f2 fare riferimento a questi due link:<\/p>\n\n\n\n In questo articolo abbiamo visto come creare una Pipeline completamente automatica di Deploy in modalit\u00e0 Blue\/Green di un servizio su ECS.<\/p>\n\n\n\n Abbiamo anche capito come le Lambda function possono essere utilizzate per automatizzare le fasi di test sull\u2019infrastruttura \u201cgreen\u201d.<\/p>\n\n\n\n Per completezza del tutorial, vi abbiamo anche mostrato come utilizzare un AWS CloudFormation template per semplificare la creazione di una infrastruttura standard complessa minimizzando i tempi e rendendola facilmente replicabile.<\/p>\n\n\n\n Il nostro intento era creare una traccia per far comprendere utilizzi e potenzialit\u00e0 di questa modalit\u00e0 automatica di rilascio del software lasciando comunque spazio per tutte le personalizzazioni necessarie a seconda dello specifico caso in cui si andr\u00e0 ad applicarla.<\/p>\n\n\n\n Cosa ne pensate? Avete realizzato particolari configurazioni per le vostre Pipeline?<\/p>\n\n\n\n Siamo curiosi di scoprirlo!<\/p>\n\n\n\n Per oggi \u00e8 tutto. #Proud2beCloud<\/strong> vi d\u00e0 appuntamento come sempre a tra 14 giorni!<\/p>\n","protected":false},"excerpt":{"rendered":" La Continuous Delivery \u00e8 oggi una delle pi\u00f9 note metodologie di rilascio del software. Grazie ad essa, qualsiasi commit che […]<\/p>\n","protected":false},"author":14,"featured_media":1922,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[241],"tags":[377,291,293,285,408,360],"class_list":["post-1881","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-devops","tag-amazon-ecs","tag-aws-codebuild","tag-aws-codedeploy","tag-aws-codepipeline","tag-blue-green-deployment","tag-continuous-delivery"],"yoast_head":"\nPrerequisiti<\/h1>\n\n\n\n
Creare un nuovo Cluster ECS<\/h2>\n\n\n\n
<\/figure><\/div>\n\n\n\n
Creare una nuova Task Definition<\/h2>\n\n\n\n
<\/figure><\/div>\n\n\n\n
<\/figure><\/div>\n\n\n\n
<\/figure><\/div>\n\n\n\n
Creare un nuovo Service<\/h2>\n\n\n\n
<\/figure><\/div>\n\n\n\n
<\/figure><\/div>\n\n\n\n
<\/figure><\/div>\n\n\n\n
Creare la Pipeline di Deploy<\/h1>\n\n\n\n
<\/figure><\/div>\n\n\n\n
<\/figure><\/div>\n\n\n\n
<\/figure><\/div>\n\n\n\n
Creare un nuovo progetto di CodeBuild<\/h2>\n\n\n\n
Cliccando su \u201cAdd project\u201d, ci troveremo davanti ad una schermata simile a questa:<\/p>\n\n\n\n<\/figure><\/div>\n\n\n\n
<\/figure><\/div>\n\n\n\n
version: 0.2\nphases:\n pre_build:\n commands:\n - REPOSITORY_URI=YOUR_ECR_URI<\/b>\n - echo $CODEBUILD_RESOLVED_SOURCE_VERSION \n - COMMIT_HASH=$(echo $CODEBUILD_RESOLVED_SOURCE_VERSION)\n - IMAGE_TAG=${COMMIT_HASH}:latest\n - $(aws ecr get-login --no-include-email --region YOUR_REGION<\/b>)\n install:\n runtime-versions:\n java: corretto11\n build:\n commands:\n - printf '{\"ImageURI\":\"%s\"}' $REPOSITORY_URI:latest > imageDetail.json\n - docker build -t YOUR_ECR_URI<\/b>:latest .\n - docker push YOUR_ECR_URI<\/b>:latest\nartifacts:\nfiles: imageDetail.json\n<\/pre>\n\n\n\n
<\/figure><\/div>\n\n\n\n
Creare un nuovo progetto di CodeDeploy<\/h2>\n\n\n\n
<\/figure>\n\n\n\n
<\/figure>\n\n\n\n
version: 0.0\nResources:\n - TargetService:\n Type: AWS::ECS::Service\n Properties:\n TaskDefinition: \"<TASK_DEFINITION>\"\n LoadBalancerInfo:\n ContainerName: \"YOUR_ECS_CLUSTER_NAME<\/b>\"\n ContainerPort: 3000\n\n<\/pre>\n\n\n\n
\"image\": \"<IMAGE>\"\n\"taskDefinitionArn\": \"<TASK_DEFINITION>\"<\/pre>\n\n\n\n
<\/figure><\/div>\n\n\n\n
<\/figure><\/div>\n\n\n\n
Bonus 2: creiamo un template AWS CloudFormation per automatizzare la predisposizione dei prerequisiti.<\/h1>\n\n\n\n
LoadBalancer:\n Type: AWS::ElasticLoadBalancingV2::LoadBalancer\n Properties:\n Name: !Ref ProjectName\n LoadBalancerAttributes:\n - Key: 'idle_timeout.timeout_seconds'\n Value: '60'\n - Key: 'routing.http2.enabled'\n Value: 'true'\n - Key: 'access_logs.s3.enabled'\n Value: 'true'\n - Key: 'access_logs.s3.prefix'\n Value: loadbalancers\n - Key: 'access_logs.s3.bucket'\n Value: !Ref S3LogsBucketName\n - Key: 'deletion_protection.enabled'\n Value: 'true'\n - Key: 'routing.http.drop_invalid_header_fields.enabled'\n Value: 'true'\n Scheme: internet-facing\n SecurityGroups:\n - !Ref LoadBalancerSecurityGroup\n Subnets:\n - !Ref SubnetPublicAId\n - !Ref SubnetPublicBId\n - !Ref SubnetPublicCId\n Type: application\n HttpListener:\n Type: AWS::ElasticLoadBalancingV2::Listener\n Properties:\n DefaultActions:\n - RedirectConfig:\n Port: '443'\n Protocol: HTTPS\n StatusCode: 'HTTP_301'\n Type: redirect\n LoadBalancerArn: !Ref LoadBalancer\n Port: 80\n Protocol: HTTP\n HttpsListener:\n Type: AWS::ElasticLoadBalancingV2::Listener\n Properties:\n Certificates:\n - CertificateArn: !Ref LoadBalancerCertificateArn\n DefaultActions:\n - Type: forward\n TargetGroupArn: !Ref TargetGroup\n LoadBalancerArn: !Ref LoadBalancer\n Port: 443\n Protocol: HTTPS\n TargetGroup:\n Type: AWS::ElasticLoadBalancingV2::TargetGroup\n Properties:\n Name: !Ref ProjectName\n HealthCheckIntervalSeconds: 30\n HealthCheckPath: !Ref HealthCheckPath\n HealthCheckProtocol: HTTP\n HealthCheckPort: !Ref NginxContainerPort\n HealthCheckTimeoutSeconds: 10\n HealthyThresholdCount: 2\n UnhealthyThresholdCount: 2\n Matcher:\n HttpCode: '200-299'\n Port: 8080\n Protocol: HTTP\n TargetType: ip\n TargetGroupAttributes:\n - Key: deregistration_delay.timeout_seconds\n Value: '30'\n VpcId: !Ref VpcId\n Cluster:\n Type: AWS::ECS::Cluster\n Properties:\n ClusterName: !Ref ProjectName\n Service:\n Type: AWS::ECS::Service\n Properties:\n Cluster: !Ref Cluster\n DeploymentConfiguration:\n MaximumPercent: 200\n MinimumHealthyPercent: 100\n DesiredCount: 3\n HealthCheckGracePeriodSeconds: 60\n LaunchType: FARGATE\n LoadBalancers:\n - ContainerName: ContainerOne\n ContainerPort: !Ref ContainerPort\n TargetGroupArn: !Ref TargetGroup\n NetworkConfiguration:\n AwsvpcConfiguration:\n AssignPublicIp: DISABLED\n SecurityGroups:\n - !Ref ContainerSecurityGroupId\n Subnets:\n - !Ref SubnetPrivateNatAId\n - !Ref SubnetPrivateNatBId\n - !Ref SubnetPrivateNatCId\n ServiceName: !Ref ProjectName\n TaskDefinition: !Ref TaskDefinition\n DependsOn: HttpsListener\n TaskDefinition:\n Type: AWS::ECS::TaskDefinition\n Properties:\n Family: !Ref ProjectName\n ContainerDefinitions:\n - Cpu: 2048\n Image: !Ref ContainerImageUri\n Memory: 4096\n MemoryReservation: 4096\n PortMappings:\n - ContainerPort: !Ref ContainerPort\n Protocol: tcp\n Name: ContainerOne\n LogConfiguration:\n LogDriver: awslogs\n Options:\n awslogs-group: !Ref ContainerLogGroup\n awslogs-region: !Ref AWS::Region\n awslogs-stream-prefix: ContainerOne\n Cpu: '2048'\n Memory: '4096'\n ExecutionRoleArn: !GetAtt ExecutionContainerRole.Arn\n TaskRoleArn: !GetAtt TaskContainerRole.Arn\n NetworkMode: awsvpc\n RequiresCompatibilities:\n - FARGATE\n<\/pre>\n\n\n\n
Conclusioni<\/h2>\n\n\n\n