Fluxos de trabalho de GitOps com o GitHub Actions na Vonage

Recentemente, redesenhamos um pipeline essencial de compilação e implantação que dá suporte à nossa plataforma Vonage Contact Center. Aproveitamos a oportunidade para migrar esse pipeline para um modelo de GitOps em conformidade com as normas de segurança. Nesta postagem do blog, explicarei o que se entende por GitOps e como nosso pipeline foi redesenhado para aproveitar os benefícios desse conceito.

Concepts de GitOps: Afinal, o que é GitOps?

Em linhas gerais, o GitOps é uma combinação das melhores práticas do DevOps e da segurança. A principal diferença entre o DevOps e o GitOps é a incorporação da IaC (Infraestrutura como Código), que é armazenada junto com o código do projeto no SCM (Gerenciamento de Código-Fonte), geralmente o Git.

O GitOps é uma estrutura, e não um pacote de software ou ferramenta específica. Na minha opinião, esse é um dos seus pontos fortes. Com o GitOps, você tem a liberdade e a flexibilidade para adaptar a implementação de forma que melhor atenda à sua organização e aprimore seus processos.

O GitOps é composto por três Concepts distintos:

1. Infraestrutura como Código (IaC)

As ferramentas de IaC permitem que a infraestrutura seja projetada e configurada uma única vez e implantada de forma repetitiva, com recursos de gerenciamento de estado que impedem que os recursos em produção se desviem de sua configuração original. Uma vez definidos, esses dados de configuração podem ser mantidos sob controle de código-fonte, permitindo que seja mantida uma única fonte de verdade para a infraestrutura (bem como para as permissões e políticas de segurança associadas).

Além disso, com uma estrutura de repositório bem projetada, os Concepts de segurança de “privilégio mínimo” e “separação de funções” são facilmente alcançados para esses dados.

2. Solicitações de pull (PRs)

Todas as alterações no código devem ser controladas por PRs. Essa proteção se aplica tanto ao código da aplicação quanto ao código de IaC que descreve a infraestrutura de suporte.

Os desenvolvedores devem ter permissão para integrar código por meio de PRs no repositório da aplicação, mas não devem ter permissões diretas para realizar atualizações no pipeline do GitOps ou nos repositórios de infraestrutura.

3. Integração Contínua / Entrega Contínua (CI/CD)

O GitOps automatiza os processos de CI/CD por meio da integração e entrega contínuas. A CI é acionada por um push no branch principal. A implantação é acionada manualmente ou automaticamente após a conclusão bem-sucedida das verificações de qualidade.

Os testes de segurança podem ser integrados ao SDLC (Ciclo de Vida do Desenvolvimento de Software) com muito mais facilidade por meio do GitOps. Além disso, como o ciclo de iteração é muito mais rápido, isso significa mais facilidade e menos obstáculos na adoção de medidas de segurança. Isso incentiva um foco na prevenção, em vez da detecção, o que é comumente chamado de “shifting left”.

Como implementamos o GitOps

Contexto

Nosso objetivo era construir um pipeline de CI/CD baseado em GitOps para a entrega de componentes Micro-FrontEnd nos ambientes hospedados na nuvem do Vonage Contact Centre. O pipeline substitui uma versão anterior e, por isso, era necessário um projeto que reduzisse significativamente os atritos no desenvolvimento e os tempos de implantação, melhorasse a segurança e, consequentemente, aprimorasse a DevEx (Experiência do Desenvolvedor).

Pesquisa e Requisitos

Como essa foi nossa primeira experiência prática com GitOps, realizamos algumas pesquisas iniciais sobre a estrutura do GitOps e fizemos um teste rápido para experimentar algumas abordagens diferentes. Dada a natureza de nossos requisitos e as inevitáveis restrições no ambiente de trabalho, optamos por adotar o modelo orientado a eventos do GitHub Actions, combinado com ferramentas CLI nativas da nuvem, para nos permitir controlar as atualizações na infraestrutura hospedada na nuvem (neste caso, CDNs, funções de código sem servidor e um banco de dados NoSQL). Em nossa arquitetura GitOps, precisamos apenas de um evento. A implantação da aplicação é acionada por um evento do GitHub repository_dispatch originário do repositório das Applications e direcionado ao repositório do GitOps, onde aciona a implantação automaticamente.

Assim que tivemos certeza de que o GitOps era uma solução viável, refinamos nossos requisitos:

• Melhore a postura de segurança seguindo os princípios do privilégio mínimo e da separação de funções

• Fornecer feedback oportuno sobre a implantação aos desenvolvedores

• Reduzir os obstáculos à implantação e, com isso, melhorar os tempos de implantação e a experiência do desenvolvedor (DevEx)

• Métricas de implantação de suporte

• Utilize pipelines de CI/CD do GitOps que sejam fáceis de manter

• Escalabilidade horizontal (integração perfeita de novas aplicações no pipeline de GitOps)

• Aproveitar e aprimorar as ferramentas internas sempre que for adequado

Arquitetura GitOps

Repositórios de infraestrutura

O Terraform foi a ferramenta que escolhemos para a implantação e o gerenciamento da infraestrutura em nuvem na qual os componentes do MFE seriam hospedados. Essa abordagem de “Infraestrutura como Código” (IaC) é útil para controlar infraestruturas que não sofrem alterações frequentes.

Cada um dos recursos necessários para hospedar os componentes do MFE foi registrado em módulos do Terraform, juntamente com os objetos de segurança e permissões necessários. Um pipeline de CI/CD do Terraform já existente é utilizado para manter esses componentes.

Repositórios de aplicativos

Os desenvolvedores (e o próprio repositório de aplicativos do MFE) têm permissões restritas para acessar ferramentas e sistemas de desenvolvimento. Portanto, um fluxo de trabalho de CI definido por meio do GitHub Actions assume essas responsabilidades, oferecendo recursos clássicos de compilação e controle de qualidade em um processo automatizado e baseado em modelos. Os artefatos de compilação produzidos por esse processo são enviados para um repositório de pacotes (jFrog Artifactory).

Application CI Workflow

Um fluxo de trabalho de CD no mesmo repositório permite que o desenvolvedor faça a implantação do aplicativo. Em termos concretos, trata-se de um evento do GitHub repository_dispatch enviado ao repositório GitOps de destino, seguido por uma etapa de espera pela conclusão.

Exemplo de ação do GitHub que aciona a implantação de um aplicativo:

- name: Deploy MFE ${{ env.MFE_NAME }} version ${{ env.MFE_VERSION }} to ${{ env.MFE_ENVIRONMENT }}
  uses: peter-evans/repository-dispatch@11ba7d3f32dc7cc919d1c43f1fec1c05260c26b5 # v2.0.0
  with:
    token: ${{ secrets.GITOPS_GITHUB_TOKEN }}
    repository: ${{ env.GITOPS_REPOSITORY }}
    event-type: deploy-mfe-trigger
    client-payload: '{
                        "type": "deploy-mfe-trigger",
                        "timestamp": "${{ env.DATEANDTIME }}",
                        "user": "${{ github.actor }}",
                        "mfe": "${{ env.MFE_NAME }}",
                        "version": "${{ env.MFE_VERSION }}",
                        "environment": "${{ env.ENVIRONMENT }}",
                        "cache_invalidation_keys": "${{ env.CACHE_INVALIDATION_KEYS }}",
                        "repository": "${{ github.repository }}",
                        "ref": "${{ github.ref }}",
                        "sha": "${{ github.sha }}"
                    }'

Application CD GitOps Workflow

Repositório de IaC do GitOps

Este repositório constitui a base de nossa estrutura de GitOps. Ele possui as permissões necessárias para realizar implantações em um determinado provedor de nuvem. Observe que ele está separado dos repositórios de aplicativos do MFE, respeitando assim os princípios de segurança do Privilégio Mínimo e da Separação de Funções (além de adotar a abordagem de “segurança desde o início”).

Os eventos de implantação são recebidos do fluxo de trabalho de CD do aplicativo e processados automaticamente. Essencialmente, há três etapas distintas no processo de GitOps:

1. Processar GitHub repository_dispatch eventos

   1. aceitar/rejeitar

   2. Atualizar a configuração de IaC com base nos metadados do evento

   3. abrir um PR

2. Mesclar PRs automaticamente

   1. realizar verificações de qualidade

   2. fazer a fusão do PR caso as verificações de qualidade sejam aprovadas

3. Implantar aplicativo

   1. copiar o artefato de compilação para o armazenamento na nuvem

   2. Atualizar tabela do banco de dados

   3. invalidar o cache do CDN

GitOps Operations Deployment Workflow

Ferramenta de implantação de infraestrutura em nuvem

Criamos uma ferramenta de linha de comando (CLI) que se integra ao nosso provedor de nuvem e permite implantações de aplicativos sem interrupções.

A abstração da lógica de implantação nesse novo projeto de CLI nos permitiu gerenciar os detalhes mais específicos dessa lógica, ao mesmo tempo em que garantimos que os novos recursos fossem testados antes de serem liberados para o pipeline de produção.

Interface de linha de comando (CLI) da estrutura do projeto Micro-FrontEnd

Esta é uma ferramenta interna que oferece uma estrutura de CI/CD para o desenvolvimento em várias linguagens de programação. Utilizamos essa ferramenta para agilizar a parte mais trabalhosa da criação e atualização de nossos projetos de software — ela fornece, por exemplo, esboços de código de componentes, opções de configuração comuns e modelos de pipeline de CI/CD. Ela é compatível com diversos ambientes de execução de linguagens e tipos de componentes.

Decidimos desde o início aprimorar a ferramenta para oferecer suporte à nova estrutura de GitOps para MFEs, a fim de melhorar a experiência do desenvolvedor na criação de novos MFEs e também auxiliar na migração dos componentes de MFE existentes para o novo pipeline de CI/CD. Nossas alterações nessa ferramenta significam que ela criará automaticamente os fluxos de trabalho de CI/CD do GitOps necessários para projetos de Micro-FrontEnd.

Para adotar o pipeline do GitOps em um projeto novo ou já existente, você deve gerar o projeto usando a ferramenta CLI.

Para onde iríamos em seguida?

Este projeto nos proporcionou uma excelente oportunidade de nos familiarizarmos com os Concepts do GitOps e nos permitiu identificar áreas em que poderíamos melhorar ainda mais. Aqui estão algumas das iniciativas que poderíamos adotar a seguir:

• Trabalhe em estreita colaboração com as equipes de segurança da Vonage para definir os requisitos de conformidade de segurança por meio de configurações (YAML, Terraform, etc.). Quando isso faz parte do SDLC (e integra-se aos ciclos contínuos de revisão e aprimoramento), você tem a certeza de atender aos requisitos de conformidade e de poder comprovar essa conformidade.

• Considere utilizar os runners auto-hospedados do GitHub Actions para nos proporcionar maior controle sobre o dimensionamento, a configuração e os custos. Essa medida deve ser avaliada com cuidado, pois envolve um equilíbrio entre a segurança dos runners, o custo e a facilidade de manutenção.

• Criar/adotar um aplicativo do GitHub para GitOps semelhante às operações disponíveis para o K8s.

Considerações finais

Espero que este blog tenha sido informativo e tenha demonstrado alguns dos benefícios de adotar o GitOps em seu pipeline de desenvolvimento.

Não deixe de nos seguir no Twitter e participe do nosso canal no Slack para obter mais informações.

Obrigado pela leitura!