Criando um pipeline de implantação multi-nuvem dinâmico e escalável com o GitLab

A equipe de soluções da Volterra projeta e mantém muitos casos de uso potenciais da plataforma Volterra para demonstrar seu valor potencial. Esses casos de uso são frequentemente transformados em guias de instruções que os clientes usam para obter a primeira experiência prática com o Volterra.

A equipe de soluções queria um método mais rápido e automatizado de implantar nossos casos de uso sob demanda internamente, com o mínimo de intervenção humana possível. Nossas implantações cobriram um ambiente híbrido de multinuvem usando plataformas IaaS (AWS, Azure e GCP) e ambientes de data center privados (VMware vSphere e Vagrant KVM). Queríamos simplificar o gerenciamento desses ambientes fornecendo uma única ferramenta que pudesse criar implantações em qualquer ambiente sem a necessidade de usuários individuais criarem contas de acesso adicionais ou gerenciarem credenciais de usuário adicionais para cada plataforma de virtualização ou provedor de IaaS. Essa ferramenta também precisava ser dimensionada para oferecer suporte a vários usuários e implantações simultâneas.

Em resumo, o problema central que queríamos resolver era criar uma ferramenta de implantação de casos de uso de soluções automatizadas, capaz de dimensionar e lidar com implantações simultâneas em ambientes híbridos de multinuvem com o mínimo de entrada do usuário possível.

O Projeto Carbono Alterado (AC)

Para esse fim, criamos um projeto chamado Altered-Carbon, frequentemente abreviado para AC. O projeto AC é um pipeline dinâmico do GitLab capaz de criar mais de 20 casos de uso de soluções Volterra diferentes. Por meio da automação de pipeline, criamos “implantações de botão de pressão” de comando único, permitindo que os usuários implantem facilmente vários clusters de casos de uso sob demanda ou por meio de tarefas cron diárias agendadas.

Para referência, no AC nos referimos a cada implantação como uma PILHA e a cada caso de uso exclusivo como uma SLEEVE .

Desenvolvimento de Projetos

Começamos o desenvolvimento do projeto AC automatizando o caso de uso hello-cloud no primeiro SLEEVE. O caso de uso hello-cloud cria um site Volterra na AWS e no Azure, depois combina esses sites em um cluster Volterra VK8s (Kubernetes virtual) e implanta um aplicativo de 10 pods em ambos os sites usando o VK8s. Começamos o processo criando modelos Terraform e scripts de shell adicionais utilizando a API Volterra para criar um fluxo de trabalho totalmente automatizado no GitLab que os pipelines de CI/CD pudessem gerenciar. Então, começamos a trabalhar para tornar essa metodologia de implantação reutilizável e escalável.

Adicionar convenções de nomenclatura exclusivas foi o próximo problema que abordamos em nosso design. Para permitir múltiplas implantações do caso de uso em um único ambiente de locatário do Volterra, precisávamos garantir que nossos recursos criados em cada STACK tivessem nomes exclusivos e não tentaríamos criar recursos com nomes duplicando outros STACKs no mesmo ambiente de locatário do Volterra. Para resolver possíveis conflitos de convenções de nomenclatura, começamos a incorporar a ideia de variáveis ambientais exclusivas fornecidas pelo usuário em gatilhos de pipeline que se tornariam essenciais para o projeto. A variável ambiental STACK_NAME foi introduzida e usada pelo Terraform para incluir uma string definida pelo usuário nos nomes de todos os recursos associados a um STACK específico. Em vez de disparar na confirmação, as condições de disparo dos trabalhos dos pipelines do AC foram definidas para serem executadas somente quando disparadas por uma chamada de API de usuários do GitLab usando um token de disparo do CI do projeto do GitLab, permitindo que o pipeline seja controlado por entrada humana ou chamadas de API externas. Ao usar chamadas de API semelhantes ao exemplo a seguir, foi possível aos usuários atingir nosso objetivo de criar várias implantações sem conflitos de recursos com um único comando.

Então nos esforçamos para criar opções de implantação adicionais a partir deste modelo. As implantações de site AWS e Azure do hello-cloud também eram casos de uso individuais que queríamos implantar independentemente com o AC. Isso nos fez encontrar nosso primeiro grande problema com o GitLab. Nos pipelines de CI/CD do GitLab, todos os trabalhos em um pipeline de projetos são conectados. Isso era contraintuitivo, pois muitos trabalhos necessários em nossa implantação hello-cloud não seriam necessários em nossas implantações de site AWS ou Azure. Queríamos essencialmente que um pipeline de CI do Projeto GitLab contivesse vários pipelines independentes que pudessem ser acionados sob demanda com conjuntos separados de trabalhos de CI quando necessário.

Para resolver esse problema, introduzimos a variável de ambiente SLEEVE na estrutura do pipeline que incorporou as opções somente/exceto CI/CD do GitLab. Isso permitiu que os trabalhos de CI acionados em qualquer pipeline fossem limitados com base no valor do SLEEVE fornecido no acionador do pipeline. Por fim, tínhamos nossas 3 opções iniciais de SLEEVE: simple-aws, simple-azure e hello-cloud. Cada SLEEVE definiria qual caso de uso um usuário desejaria implantar (controlando assim os trabalhos de CI em um pipeline acionado) e um STACK_NAME para nomear os recursos criados por qualquer pipeline acionado. A seguinte estrutura de comando, incorporando ambas as variáveis ambientais, serviu como o comando AC mais básico que ainda é usado hoje:

A imagem a seguir mostra uma visualização de como a alteração da variável de ambiente SLEEVE alterará os trabalhos acionados em cada execução do pipeline do AC.

Pipeline SLEEVE “simple-aws”:

Pipeline SLEEVE “hello-cloud”:

Também introduzimos trabalhos adicionais que seriam acionados se a variável ambiental DESTROY fosse fornecida em qualquer gatilho de pipeline. Isso forneceria uma opção reversa para remover os recursos criados pelo AC. O seguinte é um exemplo do que removeria os recursos de um STACK existente:

Outras variáveis ambientais foram armazenadas no GitLab com valores padrão que podiam ser substituídos adicionando valores ao comando de gatilho. Por exemplo, a URL da API dos nossos ambientes de locatário Volterra foi armazenada na variável de ambiente VOLTERRA TENANT. Se um usuário adicionasse a variável de ambiente VOLTERRA TENANT ao seu comando de API, isso substituiria o valor padrão e redirecionaria a implantação para o local desejado. Isso provou ser muito importante para nossa capacidade de testes internos, pois a equipe de soluções gerencia dezenas de ambientes de locatários do Volterra e precisa alternar entre eles com base na tarefa em questão:

Essas variáveis de ambiente opcionais podem ser usadas para adicionar um nível maior de controle às implantações quando necessário, mas permitem uma opção de implantação padrão mais simplista para usuários que não desejam gerenciar essa sobrecarga adicional. Também nos permitiu alternar facilmente entre implantações em ambientes de preparação e produção, o que seria essencial para nosso maior consumidor de CA.

Caso de uso de soluções: Teste de regressão noturna

Como mencionado anteriormente, cada SLEEVE no AC representava um caso de uso Volterra que frequentemente seria a primeira interação dos clientes com o produto. Garantir que esses casos de uso fossem funcionais e livres de bugs foi essencial para fornecer uma boa primeira impressão do produto. Antes da criação do AC, testar os casos de uso para confirmar se eles eram funcionais e atualizados com as versões mais recentes do software e da API da Volterra era uma tarefa demorada. As partes manuais exigidas de cada caso de uso criaram uma limitação nos testes de regressão, que não eram realizados com frequência suficiente e eram propensos a erros humanos.

No entanto, com a automação de CA, os trabalhos agendados diariamente podem ser usados para acionar uma implantação de qualquer caso de uso específico com um SLEEVE e, em seguida, remover os recursos criados após a implantação ter sido concluída ou ter falhado na implantação. Isso foi usado em ambientes de preparação e produção para testar se mudanças recentes em qualquer um deles afetaram a implantação do caso de uso ou causaram bugs no software Volterra. Poderíamos então atualizar bugs encontrados em nossos guias de casos de uso ou detectar bugs de software Volterra rapidamente e enviar tickets de resolução.

Criamos um repositório e um pipeline separados com trabalhos agendados que usariam os comandos de gatilho da API do GitLab para gerar simultaneamente várias pilhas usando diferentes SLEEVEs. Cada trabalho de teste de fumaça começaria acionando a criação de uma chaminé com uma tubulação de CA independente. O trabalho de teste de fumaça obteria então o ID do pipeline do stdout da chamada do gatilho do pipeline e a API do GitLab para monitorar o status do pipeline que ele disparou. Quando o pipeline fosse concluído (com sucesso ou falha), ele executaria o pipeline de destruição na mesma PILHA criada para remover os recursos após o teste.

A imagem a seguir detalha esse processo e mostra os trabalhos que ele aciona no AC para seus comandos de criação e destruição:

Quando um teste de fumaça falhou, conseguimos fornecer as variáveis ambientais que poderiam ser usadas em um gatilho de CA para reproduzir o problema. Isso pode ser fornecido em nossos tickets de problemas técnicos, permitindo que nossos desenvolvedores recriem facilmente as implantações com falha. Então, à medida que mais SLEEVES foram concluídos, adicionamos mais e mais trabalhos aos pipelines de CI, permitindo maior cobertura de testes. Para melhorar ainda mais a visibilidade desses testes, adicionamos uma integração com o Slack e fizemos com que os trabalhos de teste de fumaça enviassem a mensagem de sucesso ou falha de cada execução de pipeline com links e detalhes para as páginas da web de CI correspondentes nos projetos Altered-Carbon e Smoke-Test.

Manutenção de registros de pilha e navegação de URL da Web do pipeline

A complexidade do projeto aumentou conforme o AC evoluiu, adicionou usuários adicionais da equipe de soluções e criou mais e mais pilhas. Isso começou a criar problemas fundamentais ao navegar na interface de usuário da web do GitLab Pipeline. Estávamos usando pipelines do GitLab de uma forma nada tradicional, o que tornava a interface de usuário da web do pipeline do GitLab difícil de usar para rastrear execuções de pipeline individuais relacionadas aos STACKs que estávamos criando.

Os pipelines do GitLab que gerenciam implantações por meio de fluxos de trabalho do GitOps parecem mais adequados quando usados em um conjunto estático definido de clusters. Nesse caso, cada execução de um pipeline do GitLab afetaria os mesmos clusters e recursos todas as vezes. O histórico de implantação desses clusters neste caso é o histórico do pipeline visualizado na interface de usuário da web do GitLab. No entanto, o AC é dinâmico e manipula um conjunto de recursos em constante mudança, onde cada execução de pipeline pode utilizar um conjunto totalmente diferente de trabalhos, gerenciando diferentes STACKs de recursos, em diferentes provedores de virtualização. Essa diferenciação criada pelas convenções SLEEVE e STACK significa que é muito difícil determinar qual pipeline corresponde a qual pilha. Por exemplo, podemos dar uma olhada na interface de usuário da web do pipeline de CI/CD do GitLab para AC:

Dessa visão, não podemos determinar qual PILHA ou SLEEVE cada pipeline está alterando sem visualizar cada pipeline individualmente. Quando isso executa centenas de pipelines por dia, pode ser tedioso encontrar a execução de pipeline específica que criou ou destruiu qualquer STACK em particular ou localizar detalhes específicos sobre o referido STACK. Para resolver esse problema logo no início do desenvolvimento do AC, adicionamos um sistema simples de manutenção de registros. Um trabalho seria executado antes de qualquer pipeline chamado stack-records. Esse trabalho coletaria detalhes na pilha durante a criação e geraria um arquivo json que seria carregado em nosso bucket de armazenamento S3 usado para armazenar nossos backups tfstate. Abaixo vemos um exemplo de um registro de pilha:

Os arquivos stack-record.json incluem detalhes de cada pilha, como:

• Qual ambiente de locatário Volterra foi usado.
• Qual MANGA foi usada.
• Se o STACK estava em execução no estado “aplicar” ou se seus recursos foram removidos com o estado “destruir”.
• Qual usuário do GitLab criou a pilha.
• Um grupo de trabalho listando outros usuários com acesso para alterar uma PILHA.
• E o mais importante, uma matriz de pipelines que incluiria a URL da web de cada execução de pipeline realizada na pilha, quem acionou o pipeline, se o pipeline aplicou ou destruiu uma pilha e quando o pipeline foi acionado.

Isso forneceu um histórico registrado de todos os URLs de pipeline associados a qualquer pilha e um script CLI simples que pode acessar esses arquivos por meio de chamadas de API do S3 foi criado para simplificar ainda mais o processo. Nossos usuários que consomem AC podem usar esses documentos para rastrear o histórico de pilhas e visualizar quando essas pilhas foram alteradas visualizando os registros das pilhas.

Os registros de pilha também nos permitiram implementar certos níveis de controle do usuário e detecção de erros nos pipelines que implantamos. Por exemplo, uma alteração feita no software Volterra após a criação do AC nos forçou a começar a limitar os nomes de clusters de sites (um valor derivado do valor STACK NAME) usados na criação de sites Volterra a um limite de 17 caracteres. Então, adicionamos uma verificação ao trabalho de registros de pilha que faria com que os pipelines falhassem antes de executar qualquer etapa de implantação se o NOME DA PILHA violasse o limite de caracteres. Outros controles personalizados foram adicionados, como a inclusão de níveis de permissão de usuário no AC que limitam quais usuários têm acesso para alterar pilhas específicas controladas pelo AC.

• Permissões de nível de administrador, nas quais os dois principais desenvolvedores do AC têm a capacidade de criar ou destruir qualquer pilha para fins de depuração. - O nível de proprietário ou criador é para um usuário do GitLab que cria inicialmente uma PILHA. O valor do e-mail do GitLab é registrado nos registros da pilha como o criador e tem a capacidade de criar ou destruir uma pilha.
• Em seguida, temos permissões de nível de grupo de trabalho, o e-mail do usuário do GitLab pode ser adicionado à matriz de grupo de trabalho do registro de pilha, concedendo a usuários diferentes do criador a capacidade de aplicar ou destruir uma PILHA.
• Um usuário sem nenhum desses níveis de permissão não poderá alterar uma pilha. Se um usuário tentar alterar uma pilha sobre a qual não tem permissão, a tarefa de registros de pilha falhará antes que qualquer recurso seja implantado.

Uso interno e cobertura de teste atual

Hoje, o AC se tornou essencial para a equipe de soluções, fornecendo a maior parte dos nossos testes de regressão e automação. Descobrimos que seus principais usos são testes de fumaça de regressão, testes de escala, testes de faturamento de produtos e implantações simplificadas usadas em demonstrações de produtos.

As implantações automatizadas encontraram seu maior consumidor em nossos testes de regressão noturnos. Todas as noites testamos cada um dos nossos SLEEVES em um ambiente de produção e preparação, acionando uma implantação e, em seguida, desmontando os recursos criados. Quando ocorrem alterações, conseguimos detectá-las rapidamente e enviar relatórios de bugs para atualizar nossos guias. Nossa cobertura de teste atual inclui:

• Gateway seguro do Kubernetes.
• Segurança de aplicativos da Web.
• Aplicativos de ponta de rede que implantam nosso aplicativo padrão “hipster-co” de 10 pods e um aplicativo de pod único mais leve.
• Olá-Cloud.
• Interface de rede única de nó único CE volterra sites em AWS, GCP, Azure, VSphere e KVM/Vagrant.
• Interface de rede dupla de nó único CE volterra sites em AWS, GCP, Azure, VSphere e KVM/Vagrant.
• Implantações de sites Volterra de interface de rede única de nó único CE em escala (usando GCP, VSphere e KVM), criando vários sites de NIC única de nó único CE para testar as capacidades de dimensionamento do Volterra.
• Interface de rede múltipla de nó único CE volterra sites em AWS, GCP, Azure, VSphere e KVM/Vagrant.
• Interface de rede única de vários nós CE volterra sites em AWS, GCP, Azure, VSphere e KVM/Vagrant.
• Interface de rede multinó CE volterra sites em AWS, GCP, Azure, VSphere e KVM/Vagrant.

Também temos mangas de teste de escala especializadas que automatizam o processo de implantação de até 400 sites de uma só vez para testar os recursos de escalabilidade do software Volterra e foram testadas usando GCP, vSphere e KVM.

A rápida implantação automatizada de casos de uso permite que os membros da equipe de soluções se concentrem em outras tarefas, melhorando a eficiência interna. A equipe de soluções geralmente usa o AC para implantar dezenas de sites KVM, GCP e vSphere para gravar demonstrações de vídeo, economizando tempo na criação de sites Volterra para uso na criação de infraestrutura mais complexa, com base na automação que temos em vigor. Isso também é usado para tarefas cron diárias que testam os recursos de cobrança da plataforma Volterra, automatizando a implantação da AWS, segurança de aplicativos da web, gateway seguro do Kubernetes e casos de uso de aplicativos de borda de rede em um locatário Volterra especializado que registra informações de cobrança.

Planos futuros e roteiro

Nosso uso de CA já está produzindo resultados muito positivos e ainda há muitos outros recursos e melhorias para adicionar ao projeto em um futuro próximo.

A maior adição ao projeto é a adição constante de novas opções de SLEEVE para cobrir implantações de casos de uso adicionais. Para cada novo SLEEVE adicionado, adicionamos uma nova tarefa aos nossos testes de fumaça de regressão noturnos, fornecendo mais cobertura para projetos de implantação de soluções. A maioria dos sleeves anteriores se concentrava em casos de uso de nó único e interface de rede única, mas recentemente expandimos nossa cobertura do SLEEVE para clusters de sites Volterra de vários nós e casos de uso de interface de várias redes nas plataformas AWS, Azure, GCP, VMWare e KVM/Vagrant.

Também buscamos melhorar nosso sistema de registro de pilha. Aumentaremos o nível de detalhes em nossos registros de CA e adicionaremos funcionalidades de pesquisa aprimoradas com a incorporação de armazenamentos de banco de dados RDS para nossos registros. O objetivo é que possamos fornecer pesquisas mais rápidas em nosso ambiente de CA e funcionalidades de pesquisa mais seletivas, como pesquisas de pilha com base no estado da pilha, criadores de pilha, etc. Usar esses registros para construir uma interface de usuário personalizada para visualizar com mais eficiência as implantações criadas com o AC também está em nosso roteiro.