Projetos na AWS

Crie um aplicativo web moderno

Implante um aplicativo web, estabeleça uma conexão a um banco de dados e analise o comportamento dos usuários

Módulo 2: Hospedar seu aplicativo em um servidor web

Neste módulo, você criará um novo microsserviço hospedado com o AWS Fargate.  

Visão geral

Neste módulo, você criará um novo microsserviço hospedado usando o AWS Fargate para que seu site Mythical Mysfits possa ser integrado a um back-end de aplicativo.

O AWS Fargate é uma opção de implantação no Amazon Elastic Container Service (ECS) que permite implantar contêineres sem precisar gerenciar clusters ou servidores. Para nosso back-end Mythical Mysfits, usaremos o Python e criaremos um aplicativo Flask em um contêiner do Docker subjacente a um Network Load Balancer. Eles formarão o back-end de microsserviço do site front-end.

Por que escolhemos o Fargate?

Escolhemos o Fargate aqui porque é uma ótima opção para criar processos de longa execução como back-ends de microsserviços para a web, além de plataformas móveis e de PaaS. Com o Fargate, você obtém o controle de contêineres e a flexibilidade para escolher quando eles são executados sem se preocupar com o provisionamento ou a escalabilidade de servidores. Ele oferece total controle de rede, segurança e comunicação serviço a serviço. Também está integrado de forma nativa a serviços da AWS para segurança, redes, controle de acesso, ferramentas do desenvolvedor, monitoramento e registro em log.

Além do Fargate, os clientes também têm a opção de usar o AWS Lambda para atender às necessidades de computação deles. Apesar de o Lambda oferecer os mesmos benefícios sem servidor que o Fargate, o Lambda é ideal para aplicativos impulsionados por dados que precisam responder em tempo real a alterações em dados, mudanças no estado do sistema ou ações dos usuários. Abordaremos o Lambda em mais detalhes no Módulo 5 ao utilizá-lo para analisar o comportamento do cliente no site.

Instruções de implementação

Siga as instruções detalhadas abaixo para criar seu serviço do AWS Fargate. Como este módulo é grande, ele foi dividido em três submódulos. No módulo 2a, você configurará a infraestrutura principal como preparo para a implantação do serviço. No módulo 2b, você implantará o serviço usando o AWS Fargate. Finalmente, no módulo 2c, você configurará a implantação automática usando os serviços de código da AWS.

Módulo 2A: Configuração da infraestrutura principal

Antes de criar nosso serviço, precisamos criar o ambiente de infraestrutura principal que o serviço usará, incluindo a infraestrutura de redes no Amazon VPC e as funções do AWS Identity and Access Management que definirão as permissões que o ECS e nossos contêineres terão sobre a AWS.

Usaremos o AWS CloudFormation para isso. O AWS CloudFormation é um serviço que pode provisionar programaticamente recursos da AWS que você declara nos campos JSON ou YAML chamados de modelos do CloudFormation, habilitando a melhor prática comum da infraestrutura como código.  

  • Fornecemos um modelo do CloudFormation para criar todos os recursos de rede e segurança necessários em /module-2/cfn/core.yml. Este modelo criará os seguintes recursos:

    • Um Amazon VPC: um ambiente de rede que contém quatro sub-redes (duas públicas e duas privadas) no espaço de IP privado 10.0.0.0/16, bem como todas as configurações de tabela de rotas necessárias. As sub-redes dessa rede são criadas em Availability Zones (AZ – zonas de disponibilidade) da AWS separadas para habilitar a alta disponibilidade em várias instalações físicas em uma região da AWS. Saiba mais sobre como as zonas de disponibilidade podem ajudar você a alcançar a alta disponibilidade.
    • Dois gateways NAT (um para cada sub-rede pública): permite que os contêineres que forem implantados em nossas sub-redes privadas se comuniquem com a Internet para fazer download dos pacotes necessários etc.
    • Um VPC endpoint do DynamoDB: nosso back-end de microsserviço será integrado ao Amazon DynamoDB para fins de persistência (como parte do Módulo 3).
    • Um grupo de segurança: permite que os contêineres do Docker recebam tráfego na porta 8080 da Internet por meio do Network Load Balancer.
    • Funções do IAM: são criadas funções do Identity and Access Management. Elas serão usadas no workshop para que os serviços ou recursos da AWS criados por você possam ter acesso a outros serviços da AWS, como DynamoDB, S3 e outros.

    Para criar esses recursos, execute o comando a seguir no terminal Cloud9 (a criação da pilha levará em torno de 10 minutos):

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

    Você pode verificar o status de criação da pilha no Console AWS ou executando o comando:

    aws cloudformation describe-stacks --stack-name MythicalMysfitsCoreStack

    Execute o comando describe-stacks, até encontrar um status “StackStatus”: “CREATE_COMPLETE”

    descrever pilhas

    (clique para ampliar)

    Quando obtiver esta resposta, significa que o CloudFormation terminou o provisionamento de todos os principais recursos de rede e segurança descritos acima, e você poderá prosseguir. Aguarde até a pilha acima mostrar CREATE_COMPLETE antes de prosseguir.

    Você utilizará os valores da saída deste comando no restante do workshop. Você pode executar o seguinte comando para gerar diretamente o comando describe-stacks acima em um novo arquivo no IDE que será armazenado como cloudformation-core-output.json:

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

Módulo 2B: Implantar um serviço com o AWS Fargate

Depois, você criará uma imagem de contêiner do Docker contendo todo o código e a configuração necessários para executar o back-end do Mythical Mysfits como uma API de microsserviço criada com o Flask. Criaremos uma imagem de contêiner do Docker no Cloud9 e a enviaremos por push ao Amazon Elastic Container Registry, onde ela será disponibilizada para pull quando criarmos nosso serviço com o Fargate.

Diagrama da arquitetura

navegador para load balancer para o Fargate
  • A: Crie uma imagem do Docker

    Todo o código necessário para executar o back-end de serviço está armazenado no diretório /module-2/app/ do repositório que você clonou no IDE do Cloud9. Se quiser revisar o código Python que utiliza o Flask para criar a API do serviço, visualize o arquivo /module-2/app/service/mythicalMysfitsService.py.

    O docker já vem instalado no IDE do Cloud9 que você criou. Então, para criar a imagem do Docker localmente, basta executar os dois seguintes comandos no terminal do Cloud9:  

    Primeiro altere o diretório para ~/environment/module-2/app

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

    Você pode obter o ID de conta e a região padrão a partir da saída do CloudFormation anterior **describe-stacks

    Substitua REPLACE_ME_ACCOUNT_ID pelo ID da sua conta e REPLACE_ME_REGION pela sua região padrão no seguinte comando para criar a imagem do Docker usando o arquivo Dockerfile, que contém instruções do Docker. O comando identifica a imagem do Docker, usando a opção -t, com um formato de tag específico para que a imagem possa ser enviada por push ao serviço Amazon Elastic Container Registry.

    Quando tiver seu ID de conta, você estará pronto para criar a imagem do Docker:

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

    Você verá o download do Docker e instalará todos os pacotes de dependência de que nosso aplicativo precisa e gerará a tag para a imagem criada. Copie a tag da imagem para referência posterior. Abaixo da tag de exemplo mostrada, você verá o seguinte: 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: Teste o serviço localmente

    Vamos testar nossa imagem localmente no Cloud9 para verificar se tudo está funcionando conforme o esperado. Copie a tag da imagem resultante do comando anterior e execute o seguinte comando para implantar o contêiner “localmente” (que, na verdade, está no IDE do Cloud9 dentro da AWS!):

    docker run -p 8080:8080 REPLACE_ME_WITH_DOCKER_IMAGE_TAG

    Como resultado, o Docker informará que seu contêiner está funcionando localmente:

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

    Para testar nosso serviço com uma solicitação local, abriremos o navegador incorporado no IDE do Cloud9 que pode ser usado para demonstração de aplicativos executados na instância do IDE.

    Para abrir a demonstração do navegador web, selecione Preview > Preview Running Application (Demonstração > Demonstração de aplicativos em execução) na barra de menus do Cloud9:

    preview-menu

     

    Isso abrirá outro painel no IDE, no qual o navegador será disponibilizado. Anexe /mysfits ao final da URI na barra de endereço do navegador de demonstração e pressione ENTER:

    address-bar

    Em caso de êxito, você verá uma resposta do serviço que retorna o documento JSON armazenado em `/aws-modern-application-workshop/module-2/app/service/mysfits-response.json`

    Depois de testar o serviço, você poderá interrompê-lo pressionando CTRL-c no PC ou no Mac.

    C: Envie por push a imagem do Docker para o Amazon ECR

    Após o teste bem-sucedido do nosso serviço localmente, estamos prontos para criar um repositório de imagens de contêiner no Amazon Elastic Container Registry (Amazon ECR) e para enviar por push nossa imagem a ele. Para criar o registro, execute o comando a seguir. Ele criará um novo repositório no registro AWS ECR padrão criado para sua conta.

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

    A resposta a esse comando conterá metadados adicionais sobre o repositório criado. Para enviar por push imagens do contêiner ao novo repositório, precisaremos obter credenciais de autenticação de nosso cliente do Docker para o repositório.

    Execute o comando a seguir, que retornará um comando de login para recuperar as credenciais do nosso cliente do Docker. Depois, execute-o automaticamente (inclua o comando inteiro, inclusive o $ a seguir). A mensagem “Login Succeeded” (Login bem-sucedido) aparecerá se o comando for bem-sucedido.

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

    Depois, envie por push a imagem criada no repositório ECR usando a tag copiada acima. Com esse comando, o Docker enviará por push para o Amazon ECR sua imagem e todas as imagens das quais ela depende:

    docker push REPLACE_ME_WITH_DOCKER_IMAGE_TAG

    Execute o seguinte comando para ver a imagem do Docker recém-enviada por push armazenada no repositório do ECR:

    aws ecr describe-images --repository-name mythicalmysfits/service
  • A: Crie um cluster do AWS Fargate

    Agora temos uma imagem disponível no ECR que pode ser implantada para um serviço hospedado no Amazon ECS usando o AWS Fargate. O mesmo serviço testado localmente via o terminal no Cloud9 como parte do último módulo será implantado na nuvem e publicamente subjacente a um Network Load Balancer.

    Primeiro, criaremos um cluster no Amazon Elastic Container Service (ECS). Isso representa o cluster de “servidores” no qual os contêineres do seu serviço serão implantados. A palavra servidores está entre aspas porque você usará o AWS Fargate. O Fargate permite especificar quais contêineres serão implantados para um cluster sem a necessidade de provisionar ou gerenciar servidores.

    Para criar um novo cluster no ECS, execute o seguinte comando:

    aws ecs create-cluster --cluster-name MythicalMysfits-Cluster
    B: Crie um grupo do AWS CloudWatch Logs

    Depois, criaremos um novo grupo de logs no AWS CloudWatch Logs. O AWS CloudWatch Logs é um serviço para coleta e análise de logs. Os logs que o contêiner gera serão enviados por push automaticamente para os logs do AWS CloudWatch como parte desse grupo específico. Isso é extremamente importante ao usar o AWS Fargate, pois você não terá acesso à infraestrutura do servidor na qual os contêineres estarão em execução.

    Para criar o novo grupo de logs no CloudWatch Logs, execute o seguinte comando:

    aws logs create-log-group --log-group-name mythicalmysfits-logs
    C: Registre uma definição de tarefa do ECS

    Agora que já criamos um cluster e definimos um grupo de logs para o qual nossos logs de contêiner serão enviados por push, estamos prontos para registrar uma definição de tarefa do ECS. Uma tarefa no ECS é um conjunto de imagens de contêiner que devem ser programadas juntas. Uma definição de tarefa declara esse conjunto de contêineres e os recursos, além da configuração exigida por esses contêineres. Você usará a CLI da AWS para criar uma nova definição de tarefa que determinará como a nova imagem de contêiner deve ser programada para o cluster de ECS recém-criado.

    Foi fornecido um arquivo JSON, que servirá de entrada para o comando da CLI.

    Abra ~/environment/aws-modern-application-workshop/module-2/aws-cli/task-definition.json no IDE.

    Substitua os valores indicados pelos apropriados com base nos recursos criados.

    Esses valores serão tirados da resposta do CloudFormation copiada antes, bem como da tag de imagem do Docker que você enviou por push antes no ECR. Por exemplo, REPLACE_ME_ACCOUNT_ID.dkr.ecr.us-east-1.amazonaws.com/mythicalmysfits/service:latest

    Depois de substituir os valores em task-defintion.json e salvá-los. Execute o seguinte comando para registrar uma nova definição de tarefa no ECS:

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

    Com uma nova definição de tarefa registrada, estamos prontos para provisionar a infraestrutura necessária em nossa pilha de serviço. Em vez de expor diretamente nosso serviço para a Internet, provisionaremos um Network Load Balancer (NLB) para posicioná-lo na frente da nossa camada de serviço. Isso permitiria que o código de site front-end se comunicasse com um único nome DNS, enquanto o serviço back-end ficaria livre para escalar de maneira elástica a entrada e a saída com base na demanda ou em caso de falhas e da necessidade de provisão de novos contêineres.

    Para provisionar um novo NLB, execute o seguinte comando da CLI no terminal do Cloud9 (consulte as subnetIds da saída de CloudFormation que você salvou):

    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

    Quando este comando for concluído com êxito, um novo arquivo será criado no seu IDE chamado nlb-output.json. Você utilizará DNSName, VpcId e LoadBalancerArn em etapas posteriores.

    B: Crie um grupo de destino do Load Balancer

    Depois, use a CLI para criar um grupo de destino do NLB. Um grupo de destino permite que recursos da AWS sejam registrados como destinos para solicitações recebidas pelo load balancer para encaminhamento. Nossos contêineres de serviços serão registrados automaticamente neste destino para que possam receber tráfego do NLB quando forem provisionados. Este comando inclui um valor que precisará ser substituído, o seu vpc-id que se encontra como um valor na saída MythicalMysfitsCoreStack salva anteriormente, retornada pelo 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

    Quando esse comando for concluído, sua saída será salva no target-group-output.json em seu IDE. Você fará referência ao valor TargetGroupArn em uma etapa subsequente.

    C: Crie um listener do load balancer

    Depois, use a CLI para criar um listener do load balancer para o NLB. Isso informa ao load balancer que as solicitações recebidas em uma porta específica devem ser encaminhadas a destinos que foram registrados no grupo de destino acima. Substitua os dois valores indicados pelo ARN apropriado do TargetGroup e o NLB que você salvou nas etapas anteriores:

    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: Crie uma função vinculada a serviços para o ECS

    Se você já usou o ECS antes, pule esta etapa e passe para a etapa seguinte. Se você nunca usou o ECS antes, precisaremos criar uma **função vinculada a serviços** no IAM que conceda ao próprio serviço ECS permissões para fazer solicitações de API do ECS dentro da sua conta. Isso é necessário porque, quando você criar um serviço no ECS, o serviço chamará APIs da sua conta para executar ações como extrair imagens do Docker, criar novas tarefas etc.

    Sem criar essa função, o serviço ECS não teria permissões para executar as ações necessárias. Para criar a função, execute o seguinte comando no terminal:  

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

    Se o item anterior retornar um erro sobre a função já existente, ignore-o, pois isso indicaria que a função foi criada automaticamente na sua conta no passado.

    B: Crie o serviço

    Com o NLB criado e configurado e com as permissões apropriadas concedidas ao serviço ECS, estamos prontos para criar o **serviço** ECS em que nossos contêineres executarão e se registrarão no load balancer para receber tráfego. Incluímos um arquivo JSON para a entrada CLI que está localizada em: `~/environment/aws-modern-application-workshop/module-2/aws-cli/service-definition.json`. Este arquivo inclui todos os detalhes de configuração do serviço a ser criado, inclusive indica se esse serviço deve ser iniciado com o **AWS Fargate**, o que significa que você não precisa provisionar servidores no cluster direcionado. Os contêineres programados como parte da tarefa usados nesse serviço serão executados em um cluster totalmente gerenciado pela AWS.

    Abra ~/environment/aws-modern-application-workshop/module-2/aws-cli/service-definition.json no IDE e substitua os valores indicados de REPLACE_ME. Salve e execute o seguinte comando para criar o serviço:

    aws ecs create-service --cli-input-json file://~/environment/aws-modern-application-workshop/module-2/aws-cli/service-definition.json
    C: Teste o serviço

    Copie o nome DNS salvo ao criar o NLB e envie uma solicitação para usar o navegador de demonstração no Cloud9 (ou simplesmente qualquer navegador, pois dessa vez nosso serviço está disponível na Internet). Tente enviar uma solicitação ao recurso mysfits:

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

    Se aparecer a mesma resposta JSON que recebemos anteriormente ao testar o contêiner do Docker localmente no Cloud9, significa que a API do Flask API está em execução no AWS Fargate.

    Nota: este Network Load Balancer dá suporte a solicitações HTTP (http://), pois nenhum certificado SSL/TLS está instalado nele. Para este tutorial, envie solicitações usando somente http://. As solicitações https:// não funcionarão adequadamente.

  • A: Substitua o endpoint da API

    Em seguida, precisamos integrar nosso site com o novo back-end da API em vez de usar os dados embutidos em código do upload anterior para o S3. É necessário atualizar o seguinte arquivo para usar o mesmo URL do NLB para chamadas de API (não inclua o caminho /mysfits): /module-2/web/index.html

    Abra o arquivo no Cloud9 e substitua a área destacada a seguir entre aspas no URL do NLB:

    before-replace

    Após a colagem, a linha deverá ter a seguinte aparência:

    after-replace
    B: Faça upload no S3

    Para fazer upload desse arquivo no site hospedado do S3, use novamente o nome do bucket que foi criado no Módulo 1, e execute o seguinte comando:

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

    Abra o site usando o mesmo URL usado no final do Módulo 1 para ver seu novo site do Mythical Mysfits, que recupera dados de JSON da API do Flask executada em um contêiner do Docker implantado no AWS Fargate!

Módulo 2C: Automatize implantações usando os serviços de código da AWS

Agora que você tem um serviço em uso, talvez queira fazer alterações no serviço Flask. Seria um gargalo para a velocidade de desenvolvimento se você precisasse passar por todas as etapas anteriores sempre que quisesse implantar um novo recurso para o serviço. É aí que a Continuous Integration e a Continuous Delivery (CI/CD – Integração contínua/entrega contínua) entram em cena!

Neste módulo, você criará uma pilha CI/CD totalmente gerenciada que oferecerá automaticamente todas as alterações de código que você fez na sua base de código para o serviço criado no último módulo.

Diagrama da arquitetura

criar uma arquitetura de site dinâmico – cloud9, ferramentas de código, fargate
  • A: Crie um bucket do S3 para artefatos do pipeline

    Precisaremos criar outro bucket do S3 que será usado para armazenar os artefatos temporários que forem criados em meio a execuções do pipeline CI/CD. Escolha um novo nome de bucket para esses artefatos e crie um bucket usando o seguinte comando CLI:

    aws s3 mb s3://REPLACE_ME_CHOOSE_ARTIFACTS_BUCKET_NAME

    Em seguida, este bucket precisa de uma política de bucket para definir permissões para os dados armazenados nele. Diferente do bucket do nosso site que permitia o acesso a qualquer pessoa, apenas o pipeline CI/CD deve ter acesso a esse bucket. Fornecemos o arquivo JSON necessário para esta política em ~/environment/aws-modern-application-workshop/module-2/aws-cli/artifacts-bucket-policy.json.

    Abra este arquivo. Dentro dele, você precisará substituir várias strings para incluir os ARNs criados como parte do MythicalMysfitsCoreStack anteriormente, bem como o nome de bucket recém-escolhido para os seus artefatos CI/CD.

    Depois de modificar e salvar este arquivo, execute o seguinte comando para conceder acesso desse bucket ao pipeline CI/CD:

    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: Crie um repositório do CodeCommit

    Você precisará de um local para colocar e armazenar seu código. Crie um **repositório do AWS CodeCommit** usando a CLI com este objetivo:

    aws codecommit create-repository --repository-name MythicalMysfitsService-Repository
    C: Crie um projeto CodeBuild

    Com um repositório para armazenar nosso código, e um bucket do S3 que será usado em nosso artefatos CI/CD, vamos adicionar a pilha CI/CD com uma forma de viabilizar a criação de um serviço. Faremos isso com a criação de um projeto AWS CodeBuild. A qualquer momento que uma execução de build for acionada, o AWS CodeBuild provisionará automaticamente um servidor de build para a nossa configuração e executará as etapas necessárias para criar a imagem do Docker e incluir uma nova versão dele no repositório ECR que criamos (e depois desativar o servidor quando a compilação for concluída).

    As etapas da nossa compilação (no pacote de nosso código Python e com build/push do contêiner do Docker) estão incluídas no arquivo ~/environment/aws-modern-application-workshop/module-2/app/buildspec.yml. Você cria o arquivo buildspec.yml para instruir o CodeBuild sobre as etapas necessárias para a execução de uma compilação em um projeto CodeBuild.

    Para criar o projeto CodeBuild, é preciso atualizar outro arquivo de entrada de CLI com parâmetros específicos aos seus recursos. Ele está localizado em ~/environment/aws-modern-application-workshop/module-2/aws-cli/code-build-project.json. Da mesma forma, substitua os valores neste arquivo como fez antes no MythicalMysfitsCoreStackOutput. Depois de salvar, execute o seguinte na CLI para criar o projeto:

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

    Finalmente, precisamos encontrar uma forma de integrar continuamente nosso repositório CodeCommit com nosso projeto CodeBuild para que as compilações ocorram automaticamente sempre que uma alteração de código for enviada para o repositório. Precisamos conseguir oferecer continuamente esses artefatos recém-criados ao nosso serviço em ECS. AWS CodePipeline é o serviço que une essas ações em um pipeline que você criará em seguida.

    O seu pipeline no CodePipeline fará apenas o que descrevi antes. Sempre que uma alteração de código for enviada ao repositório CodeCommit, o CodePipeline entregará o último código ao projeto AWS CodeBuild para que seja feita uma compilação. Ao ser criado com êxito pelo CodeBuild, o CodePipeline fará uma implantação para o ECS usando a imagem mais recente do contêiner que a execução do CodeBuild enviou para o ECR.

    Todas essas etapas são definidas em um arquivo JSON fornecido que usará como a entrada na CLI da AWS para criar o pipeline. Este arquivo está localizado em ~/environment/aws-modern-application-workshop/module-2/aws-cli/code-pipeline.json. Abra-o, substitua os atributos obrigatórios e salve o arquivo.

    Após o salvamento, crie um pipeline em CodePipeline com o seguinte comando:

    aws codepipeline create-pipeline --cli-input-json file://~/environment/aws-modern-application-workshop/module-2/aws-cli/code-pipeline.json
    E: Habilite o acesso automatizado ao repositório de imagem do ECR

    Há uma etapa final antes que a execução completa do pipeline CI/CD possa ser bem-sucedida. Com o pipeline CI/CD no local, você não enviará mais imagens de contêiner manualmente para o ECR. Agora, o CodeBuild enviará novas imagens.

    Precisamos conceder permissão ao CodeBuild para executar ações no repositório de imagem com uma política de repositório do ECR*. O documento de política precisa ser atualizado com o ARN específico da função CodeBuild criada pelo MythicalMysfitsCoreStack. O documento da política está localizado em ~/environment/aws-modern-application-workshop/module-2/aws-cli/ecr-policy.json.

    Atualize e salve este arquivo e, depois, execute o seguinte comando para criar a política:

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

    Após a criação bem-sucedida, você terá o pipeline CI/CD completo de trabalho para entregar as alterações de código automaticamente ao serviço no ECS.

  • A: Use o Git com o AWS CodeCommit

    Para testar o novo pipeline, precisamos configurar o Git no IDE do Cloud9 e integrá-lo com o repositório CodeCommit.

    O AWS CodeCommit oferece uma ajuda de credencial para Git que usaremos para facilitar a integração.

    Execute os seguintes comandos em sequência no terminal para configurar o Git a ser usado com o AWS CodeCommit (nenhum deles reportará uma resposta caso tenha êxito):

    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

    Depois, altere os diretórios no IDE para o diretório de ambiente usando o terminal:

    cd ~/environment/

    Estamos prontos para clonar o repositório usando o seguinte comando de terminal:

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

    Isso indicará que nosso repositório está vazio! Vamos corrigir isso copiando os arquivos de aplicativo no diretório de repositório usando o seguinte comando:

    cp -r ~/environment/aws-modern-application-workshop/module-2/app/* ~/environment/MythicalMysfitsService-Repository/
    B: Enviar por push uma mudança de código

    O código de serviço completo que usamos para criar o serviço Fargate no Módulo 2 é armazenado no repositório local que acabamos de clonar do AWS CodeCommit. Vamos fazer uma alteração no serviço Flask antes de confirmar as alterações para demonstrar que o pipeline CI/CD que criamos está funcionando. No Cloud9, abra o arquivo armazenado em ~/environment/MythicalMysfitsService-Repository/service/mysfits-response.json, altere a idade de um dos mysfits para outro valor e salve o arquivo.

    Depois de salvar o arquivo, altere os diretórios para o novo diretório do repositório:

    cd ~/environment/MythicalMysfitsService-Repository/

    Depois, execute os seguintes comandos Git para enviar por push as alterações de código.

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

    Após o envio por push da alteração ao repositório, você poderá abrir o serviço CodePipeline no Console AWS para visualizar as alterações à medida que elas ocorrerem no pipeline CI/CD. Depois de confirmar a alteração de código, levará de 5 a 10 minutos para as alterações serem implantadas no serviço em linha executado no Fargate.

    Nesse período, o AWS CodePipeline coordenará o acionamento da execução de um pipeline quando as alterações tiverem sido verificadas no repositório CodeCommit, acionará o projeto CodeBuild para iniciar uma nova compilação, recuperará a imagem do Docker enviada por push ao ECR pelo CodeBuild e executará uma ação ECS Update Service automatizada para esgotar a os contêineres existentes em operação no seu serviço e substituí-los por uma imagem recém-criada. Atualize o site do Mythical Mysfits no navegador para ver se as alterações estão em vigor.

    Você pode exibir o andamento das alterações de código por meio do console CodePipeline aqui (nenhuma ação necessária, apenas assista à automação em ação!): AWS CodePipeline

    Isso conclui o Módulo 2.

Em seguida, armazene dados do mysfit.