Progetti in AWS

Crea un'applicazione Web moderna

Distribuisci un'applicazione Web, collegala a un database e analizza le attività degli utenti

Modulo 2: Effettua l'hosting della tua applicazione su un server Web

Con questo modulo, potrai creare un nuovo microservizio utilizzando AWS Fargate.  

Panoramica

Con questo modulo, potrai creare un nuovo microservizio utilizzando AWS Fargate in modo che il tuo sito Web Mythical Mysfits possa essere integrato con un backend di applicazione.

AWS Fargate è un’opzione di distribuzione di Amazon Elastic Container Service (ECS) che permette di eseguire container senza dover gestire server o cluster. Per il nostro backend Mythical Mysfits, utilizzeremo Python e creeremo un’app Flask in un container Docker dietro un Network Load Balancer, ovvero un sistema di bilanciamento del carico di rete. In questo modo sarà creato il backend del microservizio per il sito Web frontend.

Perché abbiamo scelto Fargate?

Abbiamo scelto Fargate perché rappresenta la soluzione ottimale per la creazione di processi di lunga durata come i backend dei microservizi per piattaforme Web, mobile e PaaS. Con Fargate, i container sono controllati e si ha la possibilità di scegliere quando eseguirli, senza dover considerare il provisioning o i server di dimensionamento. Offre il pieno controllo della rete, della sicurezza e della comunicazione tra servizi ed è integrato con i servizi AWS per la sicurezza, il networking, il controllo accessi, gli strumenti per gli sviluppatori, il monitoraggio e la registrazione.

Oltre a Fargate, i clienti possono decidere di utilizzare anche AWS Lambda per le proprie necessità di elaborazione. Lambda gli stessi vantaggi senza server di Fargate, ma è più indicato per le applicazioni basate sui dati che devono rispondere in tempo reale ai cambiamenti dei dati stessi, ai cambiamenti dello stato del sistema o alle azioni degli utenti. Lambda è descritto più dettagliatamente nel Modulo 5, dove sarà utilizzato per analizzare il comportamento dei clienti sul sito.

Istruzioni per l'implementazione

Segui le istruzioni dettagliate riportate di seguito per creare il tuo servizio AWS Fargate. Poiché si tratta di un modulo di grandi dimensioni, lo abbiamo suddiviso in 3 sottomoduli. Nel modulo 2a, configurerai l'infrastruttura core in preparazione per la distribuzione del servizio. Nel modulo 2b, distribuirai il servizio tramite AWS Fargate. Infine, nel modulo 2c imposterai la distribuzione automatica tramite AWS Code Services.

Modulo 2a: Configurazione dell’infrastruttura core

Prima di poter creare il nostro servizio, dobbiamo creare l'ambiente dell'infrastruttura core che sarà utilizzato dal servizio, inclusa l'infrastruttura di rete in Amazon VPC e i ruoli di AWS Identity and Access Management che definiranno le autorizzazioni di ECS e dei container rispetto a AWS.

Per far ciò, sarà utilizzato AWS CloudFormation. AWS CloudFormation è un servizio in grado di eseguire il provisioning programmatico delle risorse AWS dichiarate all'interno dei file JSON o YAML chiamati modelli CloudFormation, consentendo la best practice comune dell'infrastruttura come codice.  

  • Un modello CloudFormation per creare tutte le risorse di rete e sicurezza è disponibile in /module-2/cfn/core.yml. Questo modello consente di creare le seguenti risorse:

    • Un VPC Amazon, un ambiente di rete che contiene quattro sottoreti (due pubbliche e due private) nello spazio IP privato 10.0.0.0/16 e tutte le configurazioni di tabelle di routing necessarie. Le sottoreti di questa rete sono create in zone di disponibilità AWS separate per consentire l’alta disponibilità su più strutture fisiche in una zona AWS. Leggi come le zone di disponibilità ti consentono di ottenere l’alta disponibilità.
    • Due gateway NAT (uno per ogni sottorete pubblica), che consentono ai container che saranno eventualmente distribuiti nelle sottoreti private di comunicare su Internet per scaricare i pacchetti necessari e così via.
    • Un endpoint del VPC DynamoDB: il nostro backend del microservizio sarà eventualmente integrato con Amazon DynamoDB in modo da avere una maggiore durata (come riportato nel modulo 3).
    • Un gruppo di sicurezza, che consente ai container Docker di ricevere il traffico sulla porta 8080 da Internet tramite il Network Load Balancer.
    • Ruoli IAM: vengono creati i ruoli di Identity and Access Management. Tali ruoli saranno utilizzati durante tutto il workshop per fornire alle risorse o ai servizi AWS creati l’accesso ad altri servizi AWS come DynamoDB, S3 e altri.

    Per creare queste risorse, emetti il seguente comando nel terminal Cloud9 (la creazione dello stack richiederà circa 10 minuti):

    aws cloudformation create-stack --stack-name MythicalMysfitsCoreStack --capabilities CAPABILITY_NAMED_IAM --template-body file://~/environment/aws-modern-application-workshop/module-2/cfn/core.yml

    Potrai controllare lo stato del processo di creazione dello stack sia tramite la console AWS che eseguendo il comando:

    aws cloudformation describe-stacks --stack-name MythicalMysfitsCoreStack

    Eseguire il comando describe-stacks fino a visualizzare lo stato di "StackStatus" uguale a "CREATE_COMPLETE"

    describe stacks

    (fai clic per ingrandire l'immagine)

    Una volta ottenuta questa risposta, CloudFormation avrà terminato il provisioning di tutte le risorse principali di networking e sicurezza descritte in precedenza e sarà possibile continuare. Prima di procedere, attendere che lo stack visualizzi CREATE_COMPLETE.

    I valori dall’output di questo comando saranno utilizzati per tutto il resto del workshop. Per spostare direttamente l’output del comando describe-stacks precedente in un nuovo file nell’IDE che sarà memorizzato come cloudformation-core-output.json, emettere il comando:

    aws cloudformation describe-stacks --stack-name MythicalMysfitsCoreStack > ~/environment/cloudformation-core-output.json

Modulo 2B: Distribuzione di un servizio con AWS Fargate

A questo punto, viene creata un’immagine del container Docker che conterrà tutto il codice e la configurazione richiesta per eseguire il backend Mythical Mysfits come API del microservizio creato con Flask. L’immagine del container Docker viene creata in Cloud9 e viene quindi inserita in Amazon Elastic Container Registry, da dove potrà essere richiamata durante la creazione del servizio mediante Fargate.

Diagramma dell'architettura

browser - sistema di bilanciamento del carico - Fargate
  • A: Creazione di un’immagine Docker

    Tutto il codice richiesto per eseguire il nostro backend di servizi è memorizzato nella directory /module-2/app/ del repository clonato nell’IDE Cloud9. Per rivedere il codice Python che utilizza Flask per creare l’API del servizio, consulta il file /module-2/app/service/mythicalMysfitsService.py.

    Docker è già installato nell’IDE Cloud9 creato pertanto per poter creare l’immagine Docker in locale, sarà sufficiente emettere i seguenti due comandi nel terminale di Cloud9:  

    Per prima cosa, cambiare directory e passare a ~/environment/module-2/app

    cd ~/environment/aws-modern-application-workshop/module-2/app

    Puoi ottenere l’ID account e la zona predefinita dall’output del precedente comando **describe-stacks di CloudFormation

    Sostituisci REPLACE_ME_ACCOUNT_ID con il tuo ID e REPLACE_ME_REGION con la zona predefinita nel comando riportato di seguito in modo da creare l’immagine Docker utilizzando il file Dockerfile, che contiene le istruzioni per il Docker. Il comando tagga l’immagine Docker, tramite l’opzione -t, con un formato di tag specifico in modo che l’immagine possa successivamente essere inserita nel servizio Amazon Elastic Container Registry.

    Una volta ottenuto l’ID account, sarai pronto per la creazione dell’immagine Docker:

    docker build . -t REPLACE_ME_AWS_ACCOUNT_ID.dkr.ecr.REPLACE_ME_REGION.amazonaws.com/mythicalmysfits/service:latest

    Sarà visualizzato il download e l’installazione di tutti i pacchetti di dipendenze necessari richiesti dall’applicazione e sarà restituito il tag per l’immagine creata. Copia il tag dell’immagine per un eventuale riferimento futuro. Di seguito è riportato il tag di esempio: 111111111111.dkr.ecr.us-east-1.amazonaws.com/mythicalmysfits/service:latest

    Successfully built 8bxxxxxxxxab
    Successfully tagged 111111111111.dkr.ecr.us-east-1.amazonaws.com/mythicalmysfits/service:latest
    B: Test del servizio in locale

    A questo punto, effettuiamo il test della nostra immagine in locale all’interno di Cloud9 per essere certi che tutto funzioni come previsto. Copia il tag dell’immagine restituito dal comando precedente ed esegui il comando riportato di seguito per distribuire il container “in locale” (ovvero all’interno dell’IDE Cloud9 in AWS!):

    docker run -p 8080:8080 REPLACE_ME_WITH_DOCKER_IMAGE_TAG

    Come risultato, il Docker riporterà che il container è attivo e in esecuzione in locale:

     * Running on http://0.0.0.0:8080/ (Press CTRL+C to quit)

    Per effettuare il test del nostro servizio con una richiesta locale, utilizzeremo il browser Web integrato nell’IDE Cloud9 in modo da visualizzare in anteprima le applicazioni in esecuzione con l’istanza IDE.

    Per aprire il browser Web di anteprima, seleziona Anteprima > Anteprima applicazione in esecuzione dalla barra dei menu di Cloud9:

    preview-menu

     

    Verrà visualizzato un altro pannello nell’IDE in cui sarà disponibile il browser Web. Aggiungi /mysfits alla fine dell’URI nella barra degli indirizzi del browser e premi INVIO:

    address-bar

    Se l’operazione riesce, sarà visualizzata una risposta dal servizio che restituisce il documento JSON memorizzato in `/aws-modern-application-workshop/module-2/app/service/mysfits-response.json`

    Una volta terminato il test del servizio, potrai arrestarlo utilizzando CTRL-c, sia su PC che su Mac.

    C: Spostamento dell’immagine Docker in Amazon ECR

    Una volta riuscito il test del nostro servizio in locale, saremo pronti a creare un repository di immagini del container in Amazon Elastic Container Registry (Amazon ECR) e inserirvi la nostra immagine. Per poter creare il registro, emetti il comando riportato di seguito in modo da creare un nuovo repository nel registro AWS ECR creato per il tuo account.

    aws ecr create-repository --repository-name mythicalmysfits/service

    La risposta di questo comando conterrà altri metadati relativi al repository creato. Per inserire le immagini del container nel nuovo repository, sarà necessario ottenere per prima cosa le credenziali di autenticazione al repository per il client Docker.

    Il comando riportato di seguito restituirà un comando di login per richiamare le credenziali per il client Docker e lo esegue automaticamente (includi il comando completo, anche il simbolo $). Se il comando ha esito positivo, viene visualizzato 'Login riuscito'.

    $(aws ecr get-login --no-include-email)

    Quindi, inserisci l’immagine creata nel repository ECR utilizzando il tag copiato delle operazioni precedenti. Grazie a questo comando, Docker inserirà la tua immagine e tutte le immagini da essa dipendenti in Amazon ECR:

    docker push REPLACE_ME_WITH_DOCKER_IMAGE_TAG

    Per visualizzare l’immagine Docker appena inserita memorizzata nel repository ECR, emetti il seguente comando:

    aws ecr describe-images --repository-name mythicalmysfits/service
  • A: Creazione di un cluster di AWS Fargate

    A questo punto, in ECR è disponibile un’immagine che può essere distribuita su un servizio in Amazon ECS tramite AWS Fargate. Lo stesso servizio testato in locale tramite il terminale in Cloud9 nell’ultimo modulo sarà adesso distribuito nel cloud e sarà disponibile pubblicamente tramite un Network Load Balancer.

    Per prima cosa, verrà creato un cluster in Amazon Elastic Container Service (ECS). Tale cluster sarà il cluster di “server” su cui verranno distribuiti i container del servizio. La parola server è tra virgolette perché in realtà viene utilizzato AWS Fargate. Fargate consente di specificare che i container vengono distribuiti in un cluster senza fornire o gestire da soli eventuali server.

    Per creare un nuovo cluster in ECS, emetti il seguente comando:

    aws ecs create-cluster --cluster-name MythicalMysfits-Cluster
    B: Creazione di un gruppo di AWS CloudWatch Logs

    A questo punto, verrà creato un nuovo gruppo di log in AWS CloudWatch Logs. AWS CloudWatch Logs è un servizio per la raccolta e l’analisi di log. I log generati dal container saranno inseriti automaticamente in AWS CloudWatch Logs come parte di questo gruppo specifico. Questa operazione è particolarmente importante quando si utilizza AWS Fargate in quanto non si ha accesso all’infrastruttura di server in cui sono in esecuzione i container.

    Per creare il nuovo gruppo di log in CloudWatch Logs, emetti il seguente comando:

    aws logs create-log-group --log-group-name mythicalmysfits-logs
    C: Registrazione di una definizione di attività per ECS

    A questo punto, con il cluster pronto e un gruppo di log definito in cui verranno inseriti il log del container, è possibile registrare una definizione di attività per ECS. Un’attività in ECS è un insieme di immagini del container che devono essere pianificate insieme. Una definizione di attività dichiara quella serie di container e le risorse e la configurazione richieste da tali container. Utilizzeremo l’interfaccia a riga di comando di AWS per creare una nuova definizione di attività e regolare il modo in cui l’immagine del nuovo container deve essere pianificata nel cluster ECS appena creato.

    Viene fornito un file JSON che servirà come input per il comando dell’interfaccia CLI.

    Apri ~/environment/aws-modern-application-workshop/module-2/aws-cli/task-definition.json nell’IDE.

    Sostituisci i valori indicati con quelli appropriati dalle risorse create.

    Questi valori saranno richiamati dalla risposta CloudFormation copiata in precedenza e dal tag dell’immagine Docker inserita in ECR, ad esempio: REPLACE_ME_ACCOUNT_ID.dkr.ecr.us-east-1.amazonaws.com/mythicalmysfits/service:latest

    Dopo aver salvato in valori in task-defintion.json, salva il file. Per registrare una nuova definizione di attività, emetti il seguente comando in ECS:

    aws ecs register-task-definition --cli-input-json file://~/environment/aws-modern-application-workshop/module-2/aws-cli/task-definition.json
  • A: Creazione di un Network Load Balancer

    A questo punto, con la nuova definizione di attività registrata, siamo pronti a fornire l’infrastruttura necessaria nel nostro stack di servizi. Piuttosto che utilizzare il nostro servizio su Internet, provvederemo a fornire un Network Load Balancer (NLB), ovvero un sistema di bilanciamento del carico di rete, prima del livello di servizi. Ciò consente al codice del nostro sito Web frontend di comunicare con un unico nome DNS, mentre il nostro servizio di backend sarebbe libero di ridimensionarsi in maniera flessibile in base alla domanda o se si verificano guasti ed è necessario eseguire il provisioning di nuovi container.

    Per il provisioning di un nuovo NLB, esegui il comando dell’interfaccia a riga di comando riportato di seguito nel terminale Cloud9 (recupera gli ID delle sottoreti dall’output di CloudFormation salvato):

    aws elbv2 create-load-balancer --name mysfits-nlb --scheme internet-facing --type network --subnets REPLACE_ME_PUBLIC_SUBNET_ONE REPLACE_ME_PUBLIC_SUBNET_TWO > ~/environment/nlb-output.json

    Una volta completato il comando, nell’IDE sarà creato un nuovo file denominato nlb-output.json. DNSName, VpcId e LoadBalancerArn saranno utilizzati nelle fasi successive.

    B: Creazione di un gruppo di destinazione del sistema di bilanciamento del carico

    A questo punto, utilizza l’interfaccia a riga di comando per creare un gruppo di destinazione del NLB. Un gruppo di destinazione consente la registrazione delle risorse AWS come destinazioni per le richieste ricevute per l’inoltro dal sistema di bilanciamento del carico. I nostri container di servizio si registreranno automaticamente su questa destinazione in modo da poter ricevere il traffico dal sistema NLB una volta eseguito il provisioning. Questo comando include un valore che dovrà essere sostituito, il tuo vpc-id che è il valore all’interno dell’output di MythicalMysfitsCoreStack salvato in precedenza e restituito da CloudFormation.

    aws elbv2 create-target-group --name MythicalMysfits-TargetGroup --port 8080 --protocol TCP --target-type ip --vpc-id REPLACE_ME_VPC_ID --health-check-interval-seconds 10 --health-check-path / --health-check-protocol HTTP --healthy-threshold-count 3 --unhealthy-threshold-count 3 > ~/environment/target-group-output.json

    Una volta completato il comando, il relativo output sarà salvato nel file target-group-output.json nell’IDE. Al valore di TargetGroupArn si farà riferimento in una fase successiva.

    C: Creazione di un listener per il sistema di bilanciamento del carico

    A questo punto, utilizza l’interfaccia a riga di comando per creare un listener del sistema di bilanciamento del carico per il sistema NLB. L’interfaccia indica al sistema di bilanciamento del carico che le richieste ricevute su una porta specifica devono essere inoltrate a destinazioni che sono state registrate con il gruppo di destinazioni precedente. Assicurati di sostituire i due valori indicati con l’ARN appropriato dal gruppo di destinazione e il sistema NLB salvati nelle fasi precedenti:

    aws elbv2 create-listener --default-actions TargetGroupArn=REPLACE_ME_NLB_TARGET_GROUP_ARN,Type=forward --load-balancer-arn REPLACE_ME_NLB_ARN --port 80 --protocol TCP
  • A: Creazione di un ruolo collegato al servizio per ECS

    Se ECS è già stato utilizzato in passato, puoi ignorare questa fase e passare a quella successiva. Se invece non hai mai utilizzato prima ECS, avremo bisogno di un **ruolo collegato al servizio** in IAM che conceda al servizio ECS stesso le autorizzazioni per effettuare le richieste all’API ECS all’interno del tuo account. Ciò è necessario perché quando si crea un servizio in ECS, questo richiamerà le API all’interno del tuo account per eseguire azioni quali il recupero delle immagini Docker, la creazione di nuove attività e così via.

    Senza creare questo ruolo, il servizio ECS non avrebbe le autorizzazioni necessarie per eseguire le azioni richieste. Per creare il ruolo, digita il seguente comando nel terminale:  

    aws iam create-service-linked-role --aws-service-name ecs.amazonaws.com

    Se il comando restituisce un errore relativo al ruolo già esistente, potrai ignorarlo, perché significa che il ruolo è stato creato automaticamente nel tuo account in passato.

    B: Creazione del servizio

    Con l’NLB creato e configurato e il servizio ECS con le autorizzazioni necessarie concesse, a questo punto è possibile creare il **servizio** ECS effettivo in cui i container saranno eseguiti e si registreranno con il sistema di bilanciamento del carico per ricevere il traffico. In `~/environment/aws-modern-application-workshop/module-2/aws-cli/service-definition.json`è disponibile un file JSON per l’input dell’interfaccia a riga di comando. Questo file include tutti i dettagli di configurazione per il servizio da creare, compresa l’istruzione che riporta che il servizio deve essere avviato con **AWS Fargate**, il che significa che non è necessario specificare alcun server all’interno del cluster di destinazione. I container che sono pianificati come parte dell’attività utilizzata in questo servizio saranno eseguiti in un cluster completamente gestito da AWS.

    Apri il file ~/environment/aws-modern-application-workshop/module-2/aws-cli/service-definition.json nell’IDE e sostituisci i valori indicati di REPLACE_ME. Salva il file, quindi emetti il comando riportato di seguito per creare il servizio:

    aws ecs create-service --cli-input-json file://~/environment/aws-modern-application-workshop/module-2/aws-cli/service-definition.json
    C: Test del servizio

    Copia il nome DNS salvato durante la creazione del sistema NLB e invia una richiesta utilizzando il browser di anteprima in Cloud9 (o semplicemente da qualsiasi altro browser Web, visto che il nostro servizio stavolta è disponibile su Internet). Prova a inviare una richiesta alla risorsa mysfits:

    http://mysfits-nlb-123456789-abc123456.elb.us-east-1.amazonaws.com/mysfits

    Una risposta che mostra la stessa risposta JSON che abbiamo ricevuto in precedenza durante il test locale del contenitore Docker in Cloud9 indica che l'API Flask è attiva e in esecuzione su AWS Fargate.

    Nota: questo Network Load Balancer supporta solo richieste HTTP (http://) in quanto non è installato alcun certificato SSL/TLS. Per questo tutorial, assicurati di inoltrare le richieste solo tramite http://, Le richieste https:// non funzioneranno correttamente.

  • A: Sostituzione dell’endpoint dell’API

    A questo punto è necessario integrare il nostro sito Web con il tuo nuovo backend dell’API e non utilizzare i dati codificati precedentemente caricati in S3. Dovrai quindi aggiornare il file riportato di seguito in modo che utilizzi lo stesso URL del sistema NLB per le chiamate all’API (non includere il percorso /mysfits): /module-2/web/index.html

    Apri il file in Cloud9 e sostituisci l’area evidenziata sotto tra virgolette con l’URL del sistema NLB:

    before-replace

    Dopo aver incollato la parte corretta, la riga dovrebbe avere il seguente aspetto:

    after-replace
    B: Caricamento in S3

    Per caricare questo file sul tuo sito Web ospitato su S3, utilizza di nuovo il nome del bucket creato nel Modulo1 ed emetti il seguente comando:

    aws s3 cp ~/environment/aws-modern-application-workshop/module-2/web/index.html s3://INSERT-YOUR-BUCKET-NAME/index.html

    Apri il tuo sito Web utilizzando lo stesso URL utilizzato alla fine del Modulo 1 in modo da visualizzare il nuovo sito Mythical Mysfits, che richiama i dati JSON dall’API Flask in esecuzione in un container Docker distribuito su AWS Fargate!

Modulo 2C: Automatizzazione delle distribuzioni tramite Servizi di codice AWS

Ora che hai un servizio attivo e funzionante, puoi pensare alle modifiche al codice che desideri apportare al tuo servizio Flask. Se dovessi completare tutti gli stessi passaggi ogni volta che desideri distribuire una nuova funzionalità al tuo servizio, per la tua velocità di sviluppo sarebbe un collo di bottiglia. Ed è qui che entra in scena Continuous Integration and Continuous Delivery (o CI/CD), ovvero integrazione e distribuzione continua.

In questo modulo, potrai creare uno stack CI/CD completamente gestito che fornirà automaticamente tutte le modifiche al codice apportate alla tua base di codice al servizio creato durante l'ultimo modulo.

Diagramma dell'architettura

creazione di un’architettura del sito Web dinamico - cloud9, strumenti di codice, fargate
  • A: Creazione di un bucket S3 per gli artefatti della pipeline

    Sarà necessario creare un altro bucket S3 che sarà utilizzato per memorizzare gli artefatti temporanei creati durante le esecuzioni della pipeline CI/CD. Scegliere un nuovo nome di bucket per questi artefatti e crearne uno utilizzando il seguente comando della CLI:

    aws s3 mb s3://REPLACE_ME_CHOOSE_ARTIFACTS_BUCKET_NAME

    Successivamente, per questo bucket sarà necessaria una policy di bucket per definire le autorizzazioni per i dati in esso memorizzati. A differenza però del bucket del nostro sito Web che consentiva l’accesso a chiunque, a questo bucket deve aver accesso solo la nostra pipeline CI/CD. Il file JSON necessario per questa policy è disponibile in ~/environment/aws-modern-application-workshop/module-2/aws-cli/artifacts-bucket-policy.json.

    Apri il file e sostituisci diverse stringhe in modo da includere gli ARN che sono stati creati come parte del MythicalMysfitsCoreStack in precedenza, quindi aggiungi il nome bucket appena scelto per gli artefatti CI/CD.

    Una volta modificato e salvato il file, esegui il comando riportato per concedere alla tua pipeline CI/CD l’accesso a questo bucket:

    aws s3api put-bucket-policy --bucket REPLACE_ME_ARTIFACTS_BUCKET_NAME --policy file://~/environment/aws-modern-application-workshop/module-2/aws-cli/artifacts-bucket-policy.json
    B: Creazione di un repository CodeCommit

    A questo punto è necessario un contenitore in cui inserire e memorizzare tutto il tuo codice. Dalla CLI, crea un **repository AWS CodeCommit **:

    aws codecommit create-repository --repository-name MythicalMysfitsService-Repository
    C: Creazione di un progetto CodeBuild

    Con un repository in cui archiviare il codice e un bucket S3 che sarà utilizzato per gli artefatti CI/CD, aggiungiamo allo stack CI/CD un metodo perché venga eseguita la build del servizio. Ciò è possibile creando prima un progetto AWS CodeBuild. Ogni volta che viene avviata l’esecuzione di una build, AWS CodeBuild eseguirà automaticamente il provisioning di un server di build con la nostra configurazione ed eseguirà le fasi necessarie per la creazione dell’immagine Docker, quindi inserirà una nuova versione di tale immagine nel repository ECR creato (quindi disattiverà il server una volta completata la build).

    La procedura per la nostra build (che integra il codice Python e genera/inserisce il container Docker) è inclusa nel file ~/environment/aws-modern-application-workshop/module-2/app/buildspec.yml. Il file buildspec.yml viene creato per indicare a CodeBuild le operazioni necessarie per l’esecuzione di una build all’interno di un progetto CodeBuild.

    Per creare il progetto CodeBuild, è necessario che un altro file di input della CLI venga aggiornato con i parametri specifici delle tue risorse. Tale file si trova in ~/environment/aws-modern-application-workshop/module-2/aws-cli/code-build-project.json. Sostituisci i valori all’interno di questo file come già fatto in precedenza da MythicalMysfitsCoreStackOutput. Una volta salvato, emetti il seguente comando dalla CLI e creare il progetto:

    aws codebuild create-project --cli-input-json file://~/environment/aws-modern-application-workshop/module-2/aws-cli/code-build-project.json
    D: Creazione di una pipeline CodePipeline

    Infine, abbiamo bisogno di un modo per integrare continuamente il nostro repository CodeCommit con il progetto CodeBuild in modo che le build vengano eseguite automaticamente ogni volta che una modifica al codice viene inviata al repository. Quindi, abbiamo bisogno di un modo per fornire in maniera continua questi artefatti appena creati al nostro servizio in ECS. AWS CodePipeline è il servizio che mette in relazione queste azioni in una pipeline che sarà creata successivamente.

    La pipeline in CodePipeline esegue esattamente quanto descritto sopra. Ogni volta che una modifica al codice viene inserita nel repository CodeCommit, CodePipeline invierà il codice più recente al progetto AWS CodeBuild in modo che venga eseguita una build. Se correttamente generato da CodeBuild, CodePipeline eseguirà una distribuzione in ECS mediante l’immagine del container più recente inserita dall’esecuzione di CodeBuild in ECR.

    Tutte queste operazioni sono definite in un file JSON che sarà utilizzato come input nella CLI di AWS per creare la pipeline. Questo file si trova in~/environment/aws-modern-application-workshop/module-2/aws-cli/code-pipeline.json, aprilo e sostituisci gli attributi richiesti, quindi salva.

    Una volta salvato, crea una pipeline in CodePipeline con il seguente comando:

    aws codepipeline create-pipeline --cli-input-json file://~/environment/aws-modern-application-workshop/module-2/aws-cli/code-pipeline.json
    E: Abilitazione dell’accesso automatizzato al repository di immagini ECR

    Prima che la pipeline CI/CD possa essere eseguita correttamente, è necessario eseguire un’altra operazione. Con una pipeline CI/CD, non sarà più necessario inserire manualmente le immagini del container in ECR. Le nuove immagini vengono adesso inserite da CodeBuild.

    È necessario autorizzare CodeBuild per eseguire le azioni sul tuo repository di immagini con una policy* del repository ECR. Il documento della policy deve essere aggiornato con l'ARN specifico per il ruolo e si trova in ~/environment/aws-modern-application-workshop/module-2/aws-cli/ecr-policy.json.

    Aggiorna e salva questo file quindi emetti il seguente comando per creare la policy:

    aws ecr set-repository-policy --repository-name mythicalmysfits/service --policy-text file://~/environment/aws-modern-application-workshop/module-2/aws-cli/ecr-policy.json

    Una volta creata la policy, avrai una pipeline CI/CD end-to-end funzionante che fornisce automaticamente le modifiche al codice al servizio in ECS.

  • A: Uso di Git con AWS CodeCommit

    Per eseguire il test della nuova pipeline, è necessario configurare git nell’IDE di Cloud9 e integrarlo con il repository CodeCommit.

    AWS CodeCommit fornisce un helper di credenziali per git che sarà utilizzato per facilitare l’integrazione.

    Emettere dal terminale i seguenti comandi nella sequenza riportata per configurare git in modo che sia utilizzato con AWS CodeCommit (se il comando ha esito positivo non viene restituita alcuna risposta):

    git config --global user.name "REPLACE_ME_WITH_YOUR_NAME"
    git config --global user.email REPLACE_ME_WITH_YOUR_EMAIL@example.com
    git config --global credential.helper '!aws codecommit credential-helper $@'
    git config --global credential.UseHttpPath true

    Successivamente passa alla directory del tuo ambiente nell’IDE:

    cd ~/environment/

    A questo punto, sei pronto per la clonazione del repository mediante il seguente comando del terminale:

    git clone https://git-codecommit.REPLACE_REGION.amazonaws.com/v1/repos/MythicalMysfitsService-Repository

    Verrà restituito che il nostro repository è vuoto. Sistemiamo il problema copiando i file dell’applicazionenella directory del nostro repository utilizzando il seguente comando:

    cp -r ~/environment/aws-modern-application-workshop/module-2/app/* ~/environment/MythicalMysfitsService-Repository/
    B: Inserimento di una modifica al codice

    A questo punto il codice di servizio completo utilizzato per creare il nostro servizio Fargate nel Modulo 2 è stato archiviato nel repository locale che abbiamo appena clonato da AWS CodeCommit. Apportiamo una modifica al servizio Flask prima di confermare le nostre modifiche per dimostrare che la pipeline CI/CD appena creata funziona correttamente. In Cloud9, apri il file memorizzato in ~/environment/MythicalMysfitsService-Repository/service/mysfits-response.json e cambia la data di uno dei mysfits con un altro valore, quindi salva il file.

    Successivamente, passa alla directory del nuovo repository:

    cd ~/environment/MythicalMysfitsService-Repository/

    Quindi emetti i comandi git riportati di seguito per inserire le modifiche al codice.

    git add .
    git commit -m "I changed the age of one of the mysfits."
    git push

    Dopo aver inserito la modifica nel repository, potrai aprire il servizio CodePipeline in AWS Console per visualizzare le modifiche man mano che avanzano nella pipeline CI/CD. Dopo aver effettuato il commit della modifica al codice, la distribuzione delle modifiche al servizio in tempo reale in esecuzione in Fargate richiederà da 5 a 10 minuti.

    Durante questo periodo, AWS CodePipeline orchestrerà l'attivazione di un'esecuzione della pipeline una volta inserite le modifiche nel repository CodeCommit, attiverà il progetto CodeBuild per avviare una nuova build e recupererà l'immagine Docker che è stata trasferita in ECR da CodeBuild quindi eseguirà un servizio di aggiornamento ECS automatizzato per collegare i container esistenti in esecuzione nel servizio e li sostituirà con l’immagine appena generata. Aggiorna il tuo sito Web Mythical Mysfits nel browser per visualizzare che le modifiche sono state implementate.

    Potrai visualizzare l’avanzamento della modifica al codice tramite la console CodePipeline (non è necessaria alcuna azione, è sufficiente guardare il processo di automazione in tempo reale): AWS CodePipeline

    Hai concluso il Modulo 2.

Successivamente, archivia i dati mysfit.