Implantação de código em várias contas da AWS usando o Octopus

Haptik Blocked Unblock Seguir Seguindo 8 de maio

Toda a infraestrutura de back-end do Haptik é executada em um ambiente containerizado. À medida que a jornada progrediu, tomamos algumas decisões cruciais que nos ajudaram a chegar onde estamos hoje, em termos de implantações e vários outros oleodutos. Isso será abordado em outro post no CI / CD.

Estamos totalmente hospedados na AWS e, dada a natureza dos clientes que temos, às vezes temos que oferecer suporte a uma configuração de multilocação, na qual precisamos criar um novo ambiente na conta da AWS de nossos clientes. Para a implementação de código nessas contas, desejamos possibilitar diferentes fluxos de releases, com diferentes etapas, variáveis, ciclos de vida e lançamentos de código.

Estávamos tentando encontrar uma maneira eficiente de implantar código em várias contas da AWS. Claro, existem alguns serviços para implantações de código que a AWS oferece a partir de sua linha de serviços de implantação. Mas nós queríamos manter a solução um pouco agnóstica para começar.
A maioria dos nossos aplicativos é implantada no AWS ECS como containers / tasks e o ECS nos ajuda a orquestrar os contêineres de aplicativos. O Spotinst também entra para ajudar a manter baixos os custos de implantação.

Ao pesquisar, nos deparamos com uma ferramenta conhecida como Octopus Deploy .

O que é polvo?

O Octopus é o servidor de automação de implementação, projetado para facilitar a orquestração de releases e a implementação de aplicativos, seja no local ou na nuvem.

Alguns recursos importantes:

  1. Implantações de aplicativos multilocatários
  2. Múltiplos fluxos ativos de lançamentos: Use canais para manter múltiplos fluxos de lançamentos ativos – por exemplo, um fluxo "estável" 1.x enquanto você mantém o que está em produção hoje, e um fluxo "beta" 2.x enquanto trabalha no próximo grande coisa para amanhã.
  3. Implantação automatizada de Jenkins
  4. Implantações automatizadas para a AWS

Porquê Polvo?

Precisávamos de algo que não sobrecarregasse nem sobrecarregasse os desenvolvedores e que pudesse se encaixar em nosso pipeline existente de Implantação Contínua. É aqui que pensamos que o polvo poderia entrar em cena. Um dos principais motivos para escolher o Octopus foi: Manter o controle de quais versões de lançamento foram implantadas no serviço de um cluster do ECS.

A solução para o problema é discutida em nosso blog anterior – Empowering Developers at Haptik . Por favor, dê uma lida, se ainda não o fez.

No Haptik, a prática do DevOps é trazida de tal forma que os desenvolvedores são responsáveis pelo lançamento do código, precisamos de algo que se encaixe no pipeline como uma peça do quebra-cabeça. Seguindo em frente, a solução tinha que ser algo que se integrasse ao nosso pipeline Jenkins existente com a ajuda de um simples plugin, construindo em cima do atual pipeline de CD.

Implantando código no ECS usando Octopus

Uma implantação interna típica para nós se parece com o seguinte:

Para nossa implantação de conta interna da AWS, criamos uma imagem de contêiner do Docker com o código mais recente e as atualizações de pacote e fazemos o upload do mesmo para o ECR. Agora, para novas implantações de contas da AWS para os aplicativos Haptik, não queremos construir as imagens novamente. Queremos implantar a imagem ECR apropriada junto com as configurações precisas de definição de tarefa .

O Octopus atualmente não possui uma etapa de implantação específica do ECS, mas ainda podemos usar uma etapa de script de vários pacotes para atualizar nossa definição de tarefa do ECS e o Serviço do ECS. Isso nos permitirá usar o Octopus para controlar a versão de lançamento da imagem do Docker implementada em todo o nosso pipeline de distribuição, bem como gerenciar as diferentes variáveis, configurações e variáveis de ambiente que são necessárias para serem fornecidas à Definição da Tarefa do ECS.

Acima é o aspecto de um pipeline de implementação de código Octopus no Haptik. Mais ou menos tudo isso significa que o código pode ser implantado simplesmente disparando alguns trabalhos do Jenkins. Vamos discutir brevemente o processo de como ele funciona nos bastidores.

Começando

Inscreva-se aqui: https://octopus.com/

Crie um novo projeto e adicione uma etapa Executar um script AWS CLI ao seu projeto:

Usamos as imagens do Docker enviadas para o ** AWS ECR ** durante o pipeline de entrega contínua e as imagens são marcadas com a versão de lançamento, o que facilita a identificação de qual versão empurrar para nossos clientes e fazemos uma implantação azul-verde com a ajuda do Amazon ECS.

Adicione o feed ECR ao Octopus Deploy

Em seguida, você precisará fornecer suas credenciais e região da AWS nas quais o AWS Elastic Container Registry está. Dê os privilégios necessários ao repositório da conta secundária / cliente para acessar o Elastic Container Registry.

Implantando imagem no AWS ECS

Digite a região da AWS na qual os serviços ECR estão localizados e selecione a conta da AWS que possui as permissões necessárias para criar tarefas ECR e atualizar os serviços ECR:

Ignore a seção Pacotes referenciados e adicione a imagem do Docker que adicionamos ao nosso feed ECR. Para esta imagem, não precisamos fazer nenhuma aquisição de pacotes, pois ela será tratada pela própria AWS. Então, selecionando o pacote não será necessária opção.

Nós estaremos dividindo o script AWS CLI em 3 partes:

Temos que definir explicitamente as variáveis de ambiente na definição do contêiner para essa tarefa. Observe que, ao fornecer os detalhes da imagem, estamos usando a variável Octopus.Action.Package [web] .Image descrita acima. Este valor será derivado da versão da imagem selecionada durante o lançamento.

Ao carregar o nome da tarefa a partir de uma variável de ambiente, isso significa que podemos variar a tarefa por ambiente (e inquilino, se relevante), o que nos permite ter várias definições de tarefa para nossos diferentes contextos de implantação.

Colocando tudo junto
O processo Octopus parece algo assim:

Em seguida, adicionamos as seguintes variáveis que fornecerão a configuração para a própria infraestrutura do ECS e os detalhes que queremos inserir no contêiner:

Implantação com Jenkins

Jenkins constrói o código e executa testes, enquanto o Octopus cuida de:

  • Distribuindo aplicativos para todas as máquinas remotas, com segurança
  • Configuração específica do ambiente, como cadeias de conexão e variáveis de ambiente

Iniciando uma implantação, você também deve observar que, embora estejamos usando um pacote (a imagem), não há aquisição que ocorra. Isso porque o Octopus está apenas fornecendo os valores que descrevem o pacote para uso em nossos scripts. Quando a implementação executar o serviço do ECS, as novas tarefas serão executadas e, com base na configuração DesiredCount, DeploymentConfiguration_MaximumPercent e DeploymentConfiguration_MinimumHealthyPercent, o número correto de tarefas estará ativo em um determinado ponto. Isso resulta em uma implantação de estilo azul-verde.

1. Obtenha a chave da API do Octopus.
2. Adicione a chave para o plugin do octopus para Jenkins

3. Em Configuração do sistema, adicione as credenciais do Octopus:

4.Configure o Jenkins para receber a versão de lançamento e a configuração do pacote Octopus:

Você está tudo pronto. Um end to end pipeline está pronto para implantar uma imagem ECR com uma tag específica em qualquer serviço ECS da conta da AWS.

Tudo o que está na placa do desenvolvedor é acionar o trabalho do Jenkin com a tag de lançamento correta do GitHub. Espero que este blog ajude você a configurar um pipeline de implantação do ECS. Em breve, apareceremos mais blogs desse tipo.

Estamos contratando para nossa equipe de DevOps de arquitetura no Haptik. Confira nossa página de carreiras.