AWS CodeDeploy — Deploy descomplicado
Um resumo sobre os principais conceitos e finalidades.
Atualmente existem muitas ferramentas para automatizar — parcialmente ou totalmente — o processo de deploy de sua aplicação. Nas empresas, a maioria das aplicações de larga escala já possuem algum grau de automatização, permitindo os desenvolvedores enviarem atualizações para produção várias vezes por semana ou até várias vezes ao dia. O AWS CodeDeploy é uma destas ferramentas. Este post não é um tutorial, o objetivo dele é descrever o que é o CodeDeploy, mostrar os principais conceitos por trás da ferramenta e os cenários que podemos ou não utilizar ela.
O que é?
O AWS CodeDeploy é uma ferramenta especialmente projetada para a AWS. Os principais objetivos dela são: automatizar o processo de deploy, minimizar o tempo de inatividade, permitir um controle centralizado e ser de fácil adoção.
Quando comparado com os seus concorrentes diretos, uma das principais diferenças é que o CodeDeploy é focado somente nas soluções AWS. Isso quer dizer que a ferramenta simplifica o deploy de aplicações rodando em Lambda functions ou instâncias EC2/locais.
Quando devo utilizar e quando não devo?
Um dos principais benefícios que esta ferramenta nos proporciona é a automatização. Atualmente está cada vez mais comum possuirmos aplicações no qual estão espalhadas em diferentes instâncias EC2 e existem outras no qual utilizam a arquitetura serverless — no caso da AWS, o Lambda functions. Estes tipos de aplicações tendem a possuir um processo de deploy complexo e trabalhoso. E quando este é realizado manualmente — além de demorado — as chances de erros ocorrerem são grandes. Somando tudo isso, ainda temos os casos de quando achamos um bug em produção ou o deploy não ocorre com sucesso e precisamos fazer o aterrorizador rollback.
A automatização que o CodeDeploy proporciona permite que o deploy ocorra em diferentes maneiras — logo mais vamos falar sobre os tipos de deployment — , além do mais, quando ocorre algum problema, ele mesmo se encarrega de fazer o rollback( tudo conforme configurado previamente). E pra finalizar, tudo que ocorre durante o deploy pode ser acompanhado por interfaces no console da AWS.
Então, respondendo a pergunta, quando devo utilizar o CodeDeploy? Quando possuirmos aplicações complexas que estão rodando em serviços AWS, como por exemplo instancias EC2, instancias locais ou Lambda functions. O CodeDeploy é de fácil adoção, então para aqueles que ainda não possuem automatização no seu processo de deploy, ele é uma ótima escolha para dar o primeiro passo.
*abre parênteses*
É interessante abrir um parênteses aqui para falar que existem muitas outras ferramentas que automatizam o processo de deploy de aplicações rodando na AWS — como por exemplo o Jenkins. Porém, o processo de configuração destas ferramentas é geralmente custoso e complexo quando comparado ao CodeDeploy que é Ready-to-go.
*fecha parênteses*
Agora restou a questão. Quando não utilizar o CodeDeploy? Para esta pergunta existem algumas possibilidades listadas abaixo:
Aplicação não está rodando na AWS. Não devemos utilizar esta solução caso a aplicação não rodar na AWS ou — mesmo que esteja rodando atualmente — tenha planos futuros de migrar para outra solução em nuvem.
Deploy único. Outra possível razão seria que sua aplicação possui deploy único, por exemplo, bibliotecas, aplicações windows, aplicações iOS, aplicaçoes Android,etc. Estes tipos de aplicações normalmente não rodam em instâncias EC2 ou Lambda functions, sendo assim, o deploy delas não será gerenciado pelo CodeDeploy.
Closed Source. Apesar de não tão comum, acho que é valido destacar. Existem empresas que possuem politica do open source — muitas vezes por questões de segurança — , só utilizam as ferramentas no qual o código é aberto ao público. Este não é o caso do AWS CodeDeploy.
Tipos de Deployment
Agora que já entendemos o que é e como pode nos ajudar, vamos entender os tipos de deployment que o CodeDeploy nos proporciona. São dois tipos:
In-place deployment. Também chamado de rolling deployment, este tipo de deployment é compatível somente para aplicações rodando em instâncias EC2/instâncias locais. Conforme é possível notar na Figura 1, o processo de atualização funciona da seguinte maneira: para ser atualizada, a instância deve ser parada, após atualizada ela volta a rodar e a próxima instância segue o mesmo processo de atualização. O processo de atualização pode ser feito em pares ou um numero maior. Tudo depende da quantidade total de instâncias que sua aplicação possui. O efeito colateral deste tipo de deployment é que durante o deploy a sua aplicação estará rodando em capacidade reduzida.
Blue-green deployment. Este é o único tipo de deployment para Lambda functions. Porém ele também é compatível para aplicações rodando em instâncias EC2/locais. O comportamento do processo de atualização depende de qual é a plataforma destinada — instâncias ou Lambda functions. Conforme ilustrado na Figura 2, para os casos de instâncias, funciona da seguinte maneira: existem dois ambientes, o Blue e o Green. O ambiente Blue é o ambiente atual, rodando os fontes antes da atualização, é o ambiente cujo o Load Balander conhece e distribui o tráfego. Quando o deployment inicia, o ambiente Green é criado do zero, com novas instâncias e os fontes atualizados. Após o novo cluster ser finalizado com sucesso, o Load Balancer passa a apontar para o Green e o trafego é direcionado para as instâncias atualizadas. Ao final, todas as instâncias de Blue são finalizadas. O principal ponto de atenção deste tipo de deployment é o aumento do custo, visto que em determinado momento a quantidade de instâncias estará duplicada.
Para os casos de Lambda functions, é um pouco mais simples, funciona da seguinte maneira: é criado uma nova Lambda function atualizada, após concluído, o tráfego passa a ser deslocado para ela. Existem três configurações que permitem escolher o modo como o tráfego deve ser deslocado: Canary, o tráfego é deslocado em dois incrementos, podendo escolher a opções predefinidas que especificam a porcentagem e o intervalo dos incrementos. Linear, é semelhante ao Canary, a diferença é que o trafego é deslocado em incrementos iguais e com um número igual de minutos como intervalo. All-at-once, todo o tráfego é deslocado ao mesmo tempo da Lambda function original para a atualizada.
E o tal arquivo AppSpec?
O AppSpec(application specification file), é um arquivo que é escrito em formato YAML ou JSON e que é obrigatório para o funcionamento do CodeDeploy. Resumidamente falando, ele é o arquivo que possui todos os passos que são necessários para o deploy ser efetuado com sucesso. Como este post não é um tutorial, não vou explicar cada linha de um AppSpec. Ao invés disso eu deixo abaixo um exemplo de configuração para EC2 e outro para Lambda functions.
Conclusão
Em um mundo onde os Containers são cada vez mais realidade, podemos pensar que ferramentas como a AWS CodeDeploy tendem a ficar obsoletas. Contudo, esta ferramenta mostra o seu potencial no quesito de facilidade de adoção. Diferente da maioria dos concorrentes, o CodeDeploy exige pouco conhecimento para dar os primeiros passos na automatização do seu deploy. Outro ponto de destaque desta ferramenta, é a fácil integração com Lambda functions, que são as Serverless applications da AWS — no futuro pretendo fazer um post sobre :).
Sendo assim, o CodeDeploy é um bom começo para aqueles que não possuem um processo de deploy automatizado e querem uma ferramenta que abstrai boa parte dos conceitos.
Se quiser trocar uma ideia ou entrar em contato comigo, pode me achar no Twitter (@e_ferreirasouza) ou Linked in.
Grande abraço e até a próxima!
