Conhecendo o AWS CDK — Parte 1 de N

Se você interessa por infraestrutura como código e ainda não teve a chance de conferir o AWS CDK, me acompanhe nessa série de posts, na qual vamos definir infraestrutura utilizando o AWS CDK com Python!

O que você vai encontrar aqui?

• Uma pequena introdução a infraestrutura como código
• Pontos no CloudFormation que me motivaram a considerar o AWS CDK para IaC
• Um pequena introdução ao AWS CDK
• Algumas comparações entre códigos escritos em AWS CDK e CloudFormation
• Como montar o ambiente e criar o primeiro projeto com AWS CDK

Infraestrutura como código (Infrastructure as Code — IaC) permite que pessoas de desenvolvimento e operação possam declarar e provisionar recursos de infraestrutura de TI através de código, ao invés de executar procedimentos manuais com cliques no console da AWS (por exemplo), código este que pode ser versionado, testado e revisado em pares.

Dado que o código é reproduzível, o provisionamento da infraestrutura se dá de forma mais consistente e rápida.

Apesar do console ser mais intuitivo no início, utilizá-lo em regime pode tornar impossível controlar as versões dos recursos e fazer a gestão das mudanças. Além disso, abre a possibilidade de erros humanos, especialmente quando há a necessidade de implantar serviços e infraestrutura em mais de um ambiente (desenvolvimento, homologação e produção, etc).

A AWS lançou o AWS CloudFormation em 2011, sua ferramenta de infraestrutura como código.

Com o AWS CloudFormation você declara a infraestrutura utilizando-se de templates (JSON ou YAML) e o submete para provisionar os recursos descritos no template.

Abaixo temos um exemplo de template CloudFormation para criação de um bucket no S3.

Ao longo dos últimos 5 anos e meio, tenho utilizado o AWS CloudFormation para provisionar serviços e infraestrutura na AWS e tenho resolvido muitos problemas do mundo real utilizando mappings, export/import, custom resources, conditions e outros recursos do CloudFormation.

Com base nessa experiência, tenho algumas impressões pessoais e pontos de atenção que me levaram a considerar o AWS CDK:

• A curva de aprendizado do CloudFormation é alta. É comum ver desenvolvedores experientes em outras linguagens terem dificuldade no início.
• É difícil modularizar e aproveitar “padrões” sem ser via “copiar/colar”. Muitas e muitas vezes já ví padrões adotados em um template serem repetidos em outros na base do “copiar/colar”, dada a dificuldade em “modularizar”.
• Não há estruturas para controle de fluxo embutidas como loops, if-else, dentre outros, o que, no melhor dos casos, leva ao uso de funções (customizadas ou não), que tornam os templates ainda mais complicados.

• É difícil de realizar algum tipo de teste automatizado.
• Há uma grande discussão na comunidade sobre a “cobertura do CloudFormation” e o próprio Jeff Barr escreveu sobre isso, explicando como a AWS escolheu concentrar esforços em escalabilidade, ao invés de garantir que todos os serviços fossem cobertos pelo CloudFormation. Para falar de algo recente (06/2020), o lançamento do AWS CodeArtifact foi feito sem que o produto fosse suportado pelo CloudFormation. Na thread do twitter abaixo você pode acompanhar uma excelente discussão que dá uma idéia do tamanho da “encrenca”.

Em uma conversa com o Fabio Balancin, decidimos escrever uma aplicação inteira utilizando CDK para colocar alguns pontos à prova. Temos feito isso desde então e vamos compartilhá-la muito em breve. Por hora, este post é a parte 1 de uma série que abordar o AWS CDK com base no que tenho utilizado e pesquisado para realização deste projeto.

Conhecendo o AWS CDK

Em 2019 a AWS lançou o AWS Cloud Development Kit (CDK). Na verdade, se não me falha a memória, o anúncio do lançamento foi feito durante o re:Invent de 2018 e o lançamento para o público geral em 2019.

Com o CDK é possível utilizar umas das linguagens suportadas para definir código de infraestrutura utilizando componentes conhecidos como “Constructs”, que fazem parte da AWS Construct Library.

As linguagens suportadas são TypeScript, JavaScript, Python, Java e C#, o que logo de cara já é uma vantagem para quem utiliza alguma dessas linguagens. Não é necessário aprender um novo esquema de marcação para definir infraestrutura como código.

Ainda é CloudFormation por baixo do capô

Por mais que você esteja escrevendo código em uma das linguagens suportadas, no final das contas o AWS CDK irá gerar os templates de CloudFormation e utilizar toda sua infraestrutura. Logo, seus projetos CDK estão sujeitos aos limites impostos ao CloudFormation (número de recursos por stack, número de parâmetros por stack e etc).

Cobertura do CDK em relação ao CloudFormation

Um detalhe que precisa ser entendido bem cedo ao se adotar o CDK. Há muitos serviços do CloudFormation que são cobertos no CDK por “high-level constructs”, que são estruturas ricas, escritas por pessoas e que abstraem o CloudFormation, conforme nós veremos a seguir. Estes “Constructs” estão sujeitos a um tempo indeterminado para serem atualizados.

Por outro lado, há cobertura de 100% das características do CloudFormation através de “lower-level CloudFormation resources”, que são API’s autogeradas pela AWS em nível de recurso. Vamos voltar a este tema em posts futuros.

Agora vou dar uma parada com a teoria e mostrar alguns códigos utilizando “Constructs” do CDK e compará-los com o Cloudformation gerado pelo CDK.

Daqui para frente vou utilizar Python, mas os conceitos e métodos utilizados se aplicam 100% a qualquer uma das linguagens suportadas.

Criando um Bucket no S3

Tirando o código que está “em volta” de um projeto CDK (voltaremos a isso nos próximos posts), esta é a instrução para definir um bucket no S3. Aqui estou usando o módulo aws-cdk.aws-s3 e o “Construct” Bucket.

Esta instrução é responsável por gerar o seguinte fragmento de código no CloudFormation (removendo-se coisas específicas do CDK):

Note que o código em Python não configurou as propriedades “UpdateReplacePolicy” ou “DeletionPolicy”. Esta é uma característica dos Constructs. Há uma clara orientação em oferecer padrões e métodos que simplificam sua utilização e reduzem a necessidade de conhecer tudo sobre o recurso para usar um padrão considerado a “melhor prática”. Veja um exemplo para adicionar uma regra de ciclo de vida para objetos no S3:

Adicionando uma política de ciclo de vida ao Bucket

CloudFormation:

Fazendo o Bucket notificar uma função lambda

A coisa fica mais bonita e o valor realmente aparece quando começamos a utilizar mais de um construct em conjunto. Digamos que quiséssemos adicionar um evento ao Bucket para notificar uma função lambda toda vez que um novo objeto fosse criado.

• 1-Cria o bucket e define o ciclo de vida dos objetos
• 2-Cria a função lambda que será notificada
• 3-Adiciona a notificação para objetos criados

Agora veja o CloudFormation gerado (ainda excluindo detalhes específicos do CDK) e perceba como o como o “Construct” entendeu a composição e lidou com as permissões seguindo o princípio do menor privilégio.

Criando o ambiente para o primeiro projeto com o AWS CDK

Mesmo utilizando Python, você vai precisar instalar o Node.js >=10.3.0, pois tanto o CDK quanto a biblioteca de “Constructs” são desenvolvidos em TypeScript e rodam sob o Node.js.

Você também vai precisar do Python, pelo menos na versão 3.6 ou superior.

Com as dependências devidamente instaladas, basta instalar o próprio CDK.

npm install -g aws-cdk

Tente verificar a versão do CDK para certificar se o ambiente está pronto.

cdk --version

Especificando suas credenciais e região para o primeiro projeto com o AWS CDK

O CDK vai procurar suas credenciais na seguinte ordem:

• Pelo profile definido na opção “ profile” do CDK

cdk deploy --profile nomeDoMeuPerfil

• Pelas variáveis de ambiente (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY e AWS_DEFAULT_REGION)
• Pelo profile default configurado pelo AWS CLI

Para saber mais sobre como utilizar o AWS Command Line Interface (AWS CLI) para configurar suas credenciais e regiões, utilize este link.

O primeiro projeto com o AWS CDK

Passo 1: Utilize a opção “init” para criar um novo projeto. Vamos utilizar um template e escolher a linguagem através da opção “language”.

cdk init sample-app --language python

Passo 2 (no diretório do projeto que você criou): Vamos criar um ambiente virtual no Python, que é uma árvore de diretórios independente que contém uma instalação do Python para uma versão específica para esta aplicação, além dos pacotes adicionais. Isso é importante!

Execute o script “source.bat”, se você estiver no MS-Windows ou “.env/bin/activate” se você estiver no Linux.

Passo 3 (no diretório do projeto que você criou): Instale as dependências.

pip install -r requirements.txt

Passo 4 (no diretório do projeto que você criou): Visualize o template de CloudFormation gerado pela aplicação de exemplo.

cdk synth

Passo 5 (no diretório do projeto que você criou): Faça o deploy.

cdk deploy

Passo 6 (no diretório do projeto que você criou): E não esqueça de excluir tudo depois. :)

cdk destroy

Conclusão

O grande Luciano Ramalho tem uma palestra maravilhosa sobre a beleza do Python, que vale a pena ser assistida tanto pelo assunto quanto pela oportunidade de ouvi-lo, que é sempre uma aula.

Logo no início da apresentação há uma citação de parte do The Zen of Python, que vou reproduzir aqui e pegar emprestado:

• Bonito é melhor que feio
• Simples é melhor do que complexo
• Complexo é melhor do complicado

Por mais que beleza seja um conceito subjetivo, ao comparar os últimos dois códigos neste post (CDK vs CloudFormation), dá para afirmar que o primeiro é “mais bonito” e “mais simples” que o segundo.

Ao gastar um tempo lendo a documentação da AWS Construct Library, não dá afirmar que ela é “simples”. Por outro lado, especialmente utilizando os “high-level constructs”, dá para afirmar que, apesar de complexa, a AWS Construct Library nem de longe é tão complicada quanto o CloudFormation, apesar de ser uma “caixa preta”.

Por fim, como uma impressão totalmente pessoal, eu definitivamente me senti mais produtivo escrevendo código para definir infraestrutura com o CDK, ao mesmo tempo que o resultado obtido com mais de uma stack foi sem dúvida mais consistente do que eu faria utilizando CloudFormation com a mesma quantidade de tempo.