Melhores práticas de CI/CD na construção de aplicações modernas

© 2020, Amazon Web Services, Inc. or its Affiliates.
Fernando Sapata
LatAm Business Development Manager,
Serverless
Melhores práticas de CI/CD para
construir aplicações modernas
Bruno Emer
Sr. Container Specialist SA

CI/CD para aplicações modernas
IntegraçãoContínua (Continuous Integration)
Deploy contínuo (Continuous Deployment)
Infraestrutura como código
Agenda

CI/CD para aplicações modernas

• Aceleração da entrega de novos serviços com alta qualidade
• Simplificação no manuseio de ambientes
• Redução do impacto na alteração de código
• Automação de operações
• Ganho de insights
• Proteja o cliente e o negócio
Abordagens para o desenvolvimento de aplicações
modernas

• Aceleração da entrega de novos serviços com alta qualidade CI/CD
• Simplificação no manuseio de ambientesTecnologias serverless
• Redução do impacto na alteração de código Arquitetura de microserviços
• Automação de operações Infraestrutura como código
• Ganho de insights Observação
• Proteja o cliente e o negócio Segurança fim-a-fim e conformidade
Abordagens para o desenvolvimento de aplicações
modernas

Source: 2018 DORA State of DevOps report
Deploy mais frequente Semana – Mês Hora – Dia
Melhora o tempo de entrega 1–6 meses 1–7 dias
Diminui a taxa de erro 46–60% 0–15%
Efeitos do CI/CD

Infraestrutura
como código
Deploy
contínuo
Integração
contínua
Pilares para entregar um aplicação moderna

Integração Contínua

Integração contínua
Código Build Teste Produção
Objetivos da integração contínua

Integração contínua
1. Automaticamente inicia um novo build quando o código é inserido
2. Realiza o build e testa o código em um ambiente consistente e replicável
3. Continuamente gera um artefato pronto para deploy
4. Continuamente finaliza o ciclo de feedback quando um build falha
Objetivos da integração contínua

• Entrega continuamente serviços para uma rápida e confiável
atualização das aplicações
• Modele e visualize os processos de release da sua aplicação
• Faça build, testes e deploy do seu código toda vez que ocorrer
uma mudança
• Se integra com ferramentas terceiras e com a AWS
AWS CodePipeline

Amazon EC2
AWS CodeDeploy
AWS Elastic Beanstalk
AWS OpsWorks stacks
Containers
AWS CodeDeploy
Amazon ECS
Amazon ECS (blue/green)
AWS Fargate
Serverless
AWS CodeDeploy
AWS CloudFormation
(AWS SAM)
AWS Lambda
AWS CodePipeline: serviços suportados

• Serviço de build totalmente gerenciado que compila o
código-fonte, executa testes e cria pacotes de software
• Escala continuamente e processa vários builds
simultaneamente
• Nenhum servidor de build para você gerenciar
• Pague por minuto, apenas pelos recursos de computação que
você utiliza
• É possível monitorar os builds através de eventos do Amazon
CloudWatch
AWS CodeBuild

• Cada compilação é executada em um novo container Docker
para um ambiente consistente e imutável
• O Docker e o AWS CLI são instalados em todas as imagens
oficiais do CodeBuild
• Forneça ambientes de construção personalizados adequados
às suas necessidades por meio do uso de imagens
customizadas
AWS CodeBuild

version: 0.2
phases:
build:
commands:
- npm ci
- npm test
- aws cloudformation package
--template-file template.yml
--output-template template-output.yml
--s3_bucket $BUCKET
artifacts:
type: zip
files:
- template-output.yml
AWS CodeBuild: especificação de build do Lambda

version: 0.2
phases:
build:
commands:
- $(aws ecr get-login --no-include-email)
- docker build -t $IMAGE_REPO_NAME:$IMAGE_TAG .
- docker tag $IMAGE_REPO_NAME:$IMAGE_TAG $ECR_REPO:$IMAGE_TAG
- docker push $ECR_REPO:$IMAGE_TAG
AWS CodeBuild: especificação do Docker build

Deploy contínuo

Deploy contínuo
Objetivos do deploy contínuo

Deploy contínuo
1. Implante automaticamente novas versões em ambientes de teste
2. Implante em produção com segurança e sem impacto aos clientes
3. Realize entregas mais frequentes
Objetivos do deploy contínuo

• Lida com a complexidade de atualizar suas aplicações
• Evite o tempo de inatividade durante o deploy das
aplicações
• Faça rollback automaticamente em caso de falhas
• Faça o deploy em instâncias EC2, AWS Lambda ou
servidores locais
AWS CodeDeploy

version: 0.0
os: linux
files:
- source: /
destination: /var/www/html
permissions:
- object: /var/www/html
pattern: “*.html”
owner: root
group: root
mode: 755
hooks:
ApplicationStop:
- location: scripts/deregister_from_elb.sh
BeforeInstall:
- location: scripts/install_dependencies.sh
ApplicationStart:
- location: scripts/start_httpd.sh
ValidateService:
- location: scripts/test_site.sh
- location: scripts/register_with_elb.sh
CodeDeploy-EC2 deployments

v2 v2 v2 v2 v2 v2
Um por vez
Metade por vez
Todos de uma vez só
v2 v2 v2 v1 v1 v1
v2 v1 v1 v1 v1 v1 Agent
Grupo de implantação de desenvolvimento
Ou
Grupo de implantação de produção
Agent
Agent Agent Agent
Agent Agent Agent
Escolha a velocidade de implantação e o grupo

• Altere o tráfego usando alias ponderados
• Canary (“envie 10% do tráfego por 10 minutos, depois envie o restante”) ou linear
(“envie 10% a mais de tráfego a cada 10 minutos”)
• Os “hooks” de validação permitem testes em cada estágio da implantação
• Rollback em segundos, caso haja falha nos “hooks” de validação ou alarmes do
CloudWatch
• Monitore o status e o histórico da implantação pela console, API, notificações do
Amazon SNS e eventos do CloudWatch
CodeDeploy-Lambda deployments

Selecione a estratégia de deploy no template da aplicação
Resources:
GetFunction:
Type: AWS::Serverless::Function
Properties:
DeploymentPreference:
Type: Canary10Percent10Minutes
Alarms:
- !Ref ErrorsAlarm
Hooks:
PreTraffic: !Ref PreTrafficHook
CodeDeploy-Lambda deployments

CodeDeploy agora automatiza implantações
blue / green para o AWS Fargate e o Amazon ECS
AWS CodeDeploy

• Provisiona tarefas “green”, em seguida, redireciona o tráfego no balanceador de carga
• Os “hooks” de validação permitem testes em cada estágio da implantação
• Rollback rápido para tarefas "blue" em segundos
• Monitore o status e o histórico da implantação pela console, API, notificações do
Amazon SNS e eventos do CloudWatch
• Você pode utilizar a ação "CodeDeploy-ECS" no CodePipeline ou o comando "aws ecs
deploy" no Jenkins
Implantações CodeDeploy-ECS blue/green deployment

version: 1.0
Resources:
- TargetService:
Type: AWS::ECS::Service
Properties:
- TaskDefinition: "my_task_definition:8"
LoadBalancerInfos:
- ContainerName: "SampleApp"
ContainerPort: 80
Hooks:
- BeforeInstall: "LambdaFunctionToExecuteAnythingBeforeNewRevisionInstalltion"
- AfterInstall: "LambdaFunctionToExecuteAnythingAfterNewRevisionInstallation"
- AfterAllowTestTraffic: "LambdaFunctionToValidateAfterTestTrafficShift"
- BeforeAllowTraffic: "LambdaFunctionToValidateBeforeTrafficShift"
- AfterAllowTraffic: "LambdaFunctionToValidateAfterTrafficShift"
CodeDeploy-ECS AppSpec

Balanceador
de Carga
Tráfego em
produção
(porta 80)
Target Group
1
Tarefa blue:
código v1
100% do
tráfego
em
produção
Serviço
Fargate
CodeDeploy-ECS blue/green deployment

Balanceador
de Carga
Tráfego em
teste (porta
9000)
Tráfego em
produção
(porta 80)
Target Group
2
Target Group
1
Tarefa blue:
código v1
Serviço
Fargate
100% do
tráfego
em
produção

Balanceador
de Carga
Tráfego em
teste (porta
9000)
Tráfego em
produção
(porta 80)
Target Group
2
Target Group
1
Tarefa blue:
código v1
Tarefa green:
código v2
Provisonamento da terefa green
Serviço
Fargate
100% do
tráfego
em
produção

Balanceador
de Carga
Tráfego em
teste (porta
9000)
Tráfego em
produção
(porta 80)
Target Group
2
Target Group
1
Tarefa blue:
código v1
Tarefa green:
código v2
100%
Tráfego
de teste
Executa os testes antes da tarefa green receber tráfego de produção
Serviço
Fargate
100% do
tráfego
em
produção

Balanceador
de Carga
Tráfego em
teste (porta
9000)
Tráfego em
produção
(porta 80)
Target Group
2
Target Group
1
Tarefa blue:
código v1
Tarefa green:
código v2
100%
Tráfego
em
produção
Altera o tráfego para tarefas green, rollback em caso de alarme
Serviço
Fargate
0% do
tráfego
em
produção

Balanceador
de Carga
Tráfego em
teste (porta
9000)
Tráfego em
produção
(porta 80)
Target Group
2
Target Group
1
Tarefa green:
código v2
Finalizar a tarefa blue
Serviço
Fargate
100%
Tráfego
em
produção

• As tags do Docker são resolvidas quando cada container é iniciado, não apenas durante
os deploys
• Realizar o deploy da tag “latest” ou “prod” pode resultar em código não testado na
produção após um evento de scale-out
• Use tags "imutáveis" exclusivas para deploys
Tag nas imagens de container para deploy

Imagem: tag “latest”
Serviço
Fargate
Repositório
ECR
Imagem: sha256@11111... (“latest”)

Build utiliza a imagem “latest”
Imagem: sha256@11111...
Serviço
Fargate
Repositório
ECR

Aplicação escala, lançando novas tarefas
Imagem: sha256@11111...
Serviço
Fargate
Repositório
ECR

Implantar usando tags imutáveis
{
"name": ”sample-app",
"image": "amazon/amazon-ecs-
sample@sha256:3e39d933b1d948c92309bb583b5a1f3d28f0119e1551ca1fe538ba414a41af48d"
}
{
"name": ”sample-app",
"image": "amazon/amazon-ecs-sample:build-b2085490-359f-4eaf-8970-6d1e26c354f0"
}
SHA256 Digest
Build ID

Utilize tags imutáveis durante o build
SHA256 Digest
export IMAGE_URI=`docker inspect --format='{{index .RepoDigests 0}}' my_image:$IMAGE_TAG
Exemplo:
amazon/amazon-ecs-sample@sha256:3e39d933b...
Build ID
export IMAGE_TAG=build-`echo $CODEBUILD_BUILD_ID | awk –F":" ‘{print $2}’`
Exemplo:
build-b2085490-359f-4eaf-8970-6d1e26c354f0

Imagem: “build-11111” tag
Imagem: sha256@11111... (“build-11111”)
Serviço
Fargate
Repositório
ECR

Imagem: tag “build-11111”
O processo de build gera nova imagem e um novo ID de compilação
Imagem: sha256@11111... (“build-11111”)
Imagem: sha256@22222... (“build-22222”)
Serviço
Fargate
Repositório
ECR

Aplicação escala, lançando novas tarefas
Imagem: sha256@11111... (“build-11111”)
Imagem: sha256@22222... (“build-22222”)
Serviço
Fargate
Repositório
ECR

O deploy atualiza a definição da tarefa, substituindo as tarefas
Imagem: sha256@11111... (“build-11111”)
Imagem: sha256@22222... (“build-22222”)
Serviço
Fargate
Repositório
ECR

Infraestrutura como código

Infrastrutura como código
Objetivos de infraestrutura como código

Infrastrutura como código
1. Tornar as alterações de infraestrutura replicáveis e previsíveis
2. Liberar alterações de infraestrutura usando as mesmas ferramentas que utilizamos nas
alterações de código
3. Replicar o ambiente de produção em outros ambientes permitindo testes contínuos
Objetivos de infraestrutura como código

“Master”
branch
Código Fonte Build Teste Produção
Criar template Criar e executar as
alterações
Criar e executar as
alterações
Entregando infraestrutura como código

https://aws.amazon.com/serverless/sam/
• Framework open source para build de aplicações serverless
na AWS
• Sintaxe abreviada para declarar funções, APIs, bancos de
dados e mapeamentos de origem de eventos
• Transforma a sintaxe do AWS SAM na sintaxe do AWS
CloudFormation no deploy
• Suporta todos os tipos de recursos do AWS CloudFormation
AWS Serverless Application Model (AWS SAM)

Sintaxe abreviada
para declarar
funções, tabelas e
eventos
AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
Resources:
GetFunction:
Properties:
Handler: index.get
Runtime: nodejs6.10
CodeUri: src/
Policies: AmazonDynamoDBReadOnlyAccess
Events:
GetResource:
Type: Api
Properties:
Path: /resource/{resourceId}
Method: get
Table:
Type: AWS::Serverless::SimpleTable
AWS SAM template

AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
Resources:
GetFunction:
Properties:
Handler: index.get
Runtime: nodejs6.10
CodeUri: src/
Policies: AmazonDynamoDBReadOnlyAccess
Events:
GetResource:
Type: Api
Properties:
Path: /resource/{resourceId}
Method: get
Table:
Type: AWS::Serverless::SimpleTable
Apenas 18 linhas criam muitos recursos:
• Função AWS Lambda
• Amazon API Gateway
• Tabela do Amazon DynamoDB
• Roles do IAM
AWS SAM template

pip install --user aws-sam-cli
sam init
sam build
sam package
sam deploy
Use a CLI do SAM para empacotar e realizar deploys

• Framework open source para definir infraestrutura com
TypeScript
• Fornece bibliotecas de tipos de recursos (construtores) com
práticas recomendadas pela AWS, incorporadas por padrão,
distribuídas como módulos npm
• Provisiona recursos utilizando o AWS CloudFormation
• Suporta todos os tipos de recursos do AWS CloudFormation
AWS
CDK
https://awslabs.github.io/aws-cdk
AWS Cloud Development Kit (AWS CDK)

import ec2 = require('@aws-cdk/aws-ec2');
import ecs = require('@aws-cdk/aws-ecs');
import cdk = require('@aws-cdk/cdk');
class BonjourFargate extends cdk.Stack {
constructor(parent: cdk.App, name: string, props?: cdk.StackProps) {
super(parent, name, props);
const vpc = new ec2.VpcNetwork(this, 'MyVpc', { maxAZs: 2 });
const cluster = new ecs.Cluster(this, 'Cluster', { vpc });
new ecs.LoadBalancedFargateService(
this, "FargateService", {
cluster,
image: ecs.DockerHub.image("amazon/amazon-ecs-sample"),
});
}
}
const app = new cdk.App();
new BonjourFargate(app, 'Bonjour');
app.run();
A classeVPC inclui
VPC, sub-redes,
grupos de segurança,
gateway de internet,
gateways NAT e
tabelas de
roteamento
Template AWS CDK

cluster,
});
}
}
app.run();
A classe Fargate inclui o
serviço ECS, definição de
tarefa do ECS, balanceador
de carga, grupos de destino
e, opcionalmente, registro
de alias no Amazon Route
53
Template AWS CDK

22 linhas de código
TypeScript geram
mais de 400 linhas do
CloudFormation
cluster,
});
}
}
app.run();
Template AWS CDK

• Minimize “copia e cola” usando linguagem orientada a objeto
• Defina o pipeline de microserviços em uma classe e em seguida reutilize em
vários pipelines
• O AWS CDK inclui muitos construtores para modelar um pipeline utilizando
o CodePipeline, incluindo a configuração automática de políticas do IAM
Pipelines com AWS CDK

export class MyMicroservicePipeline extends cdk.Construct {
constructor(parent: cdk.Construct, name: string, props: MyMicroservicePipelineProps) {
super(parent, name);
const pipeline = new codepipeline.Pipeline(this, 'Pipeline', {
pipelineName: props.serviceName,
});
const githubAccessToken = new cdk.SecretParameter(this, 'GitHubToken',
{ ssmParameter: 'GitHubToken' });
new codepipeline.GitHubSourceAction(this, 'GitHubSource', {
stage: pipeline.addStage('Source'),
owner: 'myorg',
repo: props.serviceName,
oauthToken: githubAccessToken.value
});
…
AWS CDK pipelines: Definição

import { MyMicroservicePipeline } from './pipeline';
class MyMicroservicePipelinesStack extends cdk.Stack {
new MyMicroservicePipeline(this, 'Pipeline1', { 'serviceName': 'Microservice1' });
}
}
new MyMicroservicePipelinesStack(app, 'MyMicroservicePipelines');
app.run();
AWS CDK pipelines: Utilização

Obrigado!
Fernando Sapata
LatAm Business Development Manager,
Serverless
Bruno Emer
Sr. Container Specialist SA

Melhores práticas de CI/CD na construção de aplicações modernas

Mais conteúdo relacionado

Mais procurados

Semelhante a Melhores práticas de CI/CD na construção de aplicações modernas

Mais de Amazon Web Services LATAM

Melhores práticas de CI/CD na construção de aplicações modernas