Implantar na infraestrutura do Azure com o GitHub Actions

  • Artigo

Neste guia, abordaremos como utilizar CI/CD e Infraestrutura como Código (IaC) para implantar no Azure com o GitHub Actions de forma automatizada e repetível.

Este artigo é uma visão geral da arquitetura e apresenta uma solução estruturada para projetar um aplicativo no Azure que seja escalonável, seguro, resiliente e altamente disponível. Para ver mais exemplos reais de arquiteturas de nuvem e ideias de soluções, navegue pelas arquiteturas do Azure.

Benefícios do uso de IaC e automação para implantações

Há muitas maneiras de implantar no Azure, incluindo o portal do Azure, CLI, API e muito mais. Para este guia, usaremos a automação de IaC e CI/CD. Entre os benefícios dessa abordagem estão:

  • Declarativo: quando você define sua infraestrutura e processo de implantação no código, ele pode ser versionado e revisado usando o ciclo de vida de desenvolvimento de software padrão. A IaC também ajuda a evitar qualquer descompasso na sua configuração.

  • Consistência: seguir um processo de IaC garante que toda a organização siga um método padrão e bem estabelecido para implantar uma infraestrutura que incorpore as práticas recomendadas e seja reforçada para atender às suas necessidades de segurança. Quaisquer melhorias feitas nos modelos centrais podem ser facilmente aplicadas em toda a organização.

  • Segurança: os modelos gerenciados centralmente podem ser reforçados e aprovados por uma equipe de operações ou segurança na nuvem para atender aos padrões internos.

  • Autoatendimento: as equipes podem ser capacitadas para implantar sua própria infraestrutura utilizando modelos gerenciados centralmente.

  • Produtividade aprimorada: ao utilizar modelos padrão, as equipes podem provisionar rapidamente novos ambientes sem precisar se preocupar com todos os detalhes da implementação.

Mais informações podem ser encontradas em infraestrutura repetível no Centro de Arquitetura do Azure ou em o que é infraestrutura como código na Central de Recursos de DevOps.

Arquitetura

Architecture overview of using CI/CD to deploy Azure

Fluxo de dados

  1. Crie uma nova filial e verifique as modificações de código da IaC necessárias.
  2. Crie uma solicitação de transferência (PR) no GitHub quando estiver tudo pronto para mesclar suas alterações em seu ambiente.
  3. Um fluxo de trabalho do GitHub Actions será acionado para garantir que seu código esteja bem formatado, internamente consistente e produza uma infraestrutura segura. Além disso, uma análise hipotética do Plano do Terraform ou do Bicep será executada para gerar uma visualização das alterações que acontecerão em seu ambiente do Azure.
  4. Uma vez devidamente revisada, a PR pode ser mesclada em sua filial principal.
  5. Outro fluxo de trabalho do GitHub Actions será acionado a partir da filial principal e executará as alterações usando seu provedor de IaC.
  6. (exclusivo para Terraform) Um fluxo de trabalho do GitHub Actions agendado regularmente também deve ser executado para procurar qualquer descompasso na configuração em seu ambiente e criar um novo problema se forem detectadas alterações.

Pré-requisitos

Usar o Bicep

  1. Criar ambientes no GitHub

    Os fluxos de trabalho utilizam ambientes e segredos do GitHub para armazenar as informações de identidade do Azure e configurar um processo de aprovação para implantações. Crie um ambiente denominado production seguindo estas instruções. No production ambiente, configure uma regra de proteção e adicione os aprovadores necessários desejados que precisam aprovar implantações de produção. Você também pode limitar o ambiente à sua filial principal. As instruções detalhadas são encontradas aqui.

  2. Configurar a Identidade do Azure:

    É necessário um aplicativo do Active Directory do Azure que tenha permissões para implantar em sua assinatura do Azure. Crie um único aplicativo e conceda a ele as permissões de leitura/gravação apropriadas em sua assinatura do Azure. Em seguida, configure as credenciais federadas para permitir que o GitHub utilize a identidade usando o OpenID Connect (OIDC). Consulte a documentação do Azure para obter instruções detalhadas. Três credenciais federadas precisarão ser adicionadas:

    • Defina Tipo de Entidade como Environment e use o production nome do ambiente.
    • Defina Tipo de Entidade como Pull Request.
    • Defina Tipo de Entidade como Branch e use o main nome da filial.

  3. Adicionar segredos do GitHub

    Observação

    Embora nenhum dos dados sobre as identidades do Azure contenha segredos ou credenciais, ainda utilizamos segredos do GitHub como um meio conveniente de parametrizar as informações de identidade por ambiente.

    Crie os seguintes segredos no repositório usando a identidade do Azure:

    • AZURE_CLIENT_ID : ID do aplicativo (cliente) do registro de aplicativo no Azure
    • AZURE_TENANT_ID : ID do locatário do Active Directory do Azure onde o registro do aplicativo é definido.
    • AZURE_SUBSCRIPTION_ID : ID da assinatura onde o registro do aplicativo é definido.

    As instruções para adicionar os segredos ao repositório podem ser encontradas aqui.

Usar o Terraform

  1. Configurar o Local do Estado do Terraform

    O Terraform utiliza um arquivo de estado para armazenar informações sobre o estado atual da infraestrutura gerenciada e a configuração associada. Esse arquivo precisará de persistência entre diferentes execuções do fluxo de trabalho. A abordagem recomendada é armazenar esse arquivo em uma Conta de Armazenamento do Azure ou em outro back-end remoto semelhante. Normalmente, esse armazenamento seria provisionado manualmente ou por meio de um fluxo de trabalho separado. O bloco de back-end do Terraform precisará ser atualizado com o local de armazenamento selecionado (consulte aqui a documentação).

  2. Criar um ambiente no GitHub

    Os fluxos de trabalho utilizam ambientes e segredos do GitHub para armazenar as informações de identidade do Azure e configurar um processo de aprovação para implantações. Crie um ambiente denominado production seguindo estas instruções. No production ambiente, configure uma regra de proteção e adicione os aprovadores necessários desejados que precisam aprovar implantações de produção. Você também pode limitar o ambiente à sua filial principal. As instruções detalhadas são encontradas aqui.

  3. Configurar a Identidade do Azure:

    É necessário um aplicativo do Active Directory do Azure que tenha permissões para implantar em sua assinatura do Azure. Crie um aplicativo separado para as contas read-only e read/write e dê a elas as permissões apropriadas em sua assinatura do Azure. Além disso, ambas as funções também precisarão de pelo menos Reader and Data Access permissões para a conta de armazenamento onde reside o estado do Terraform da etapa 1. Em seguida, configure as credenciais federadas para permitir que o GitHub utilize a identidade usando o OpenID Connect (OIDC). Consulte a documentação do Azure para obter instruções detalhadas.

    Para a identidaderead/write, crie uma credencial federada da seguinte maneira:

    • Defina Entity Type e Environment e use o production nome do ambiente.

    Para a identidaderead-only, crie duas credenciais federadas da seguinte maneira:

    • Definir Entity Type para Pull Request.
    • Defina Entity Type e Branch e use o main nome da filial.

  4. Adicionar segredos do GitHub

    Observação

    Embora nenhum dos dados sobre as identidades do Azure contenha segredos ou credenciais, ainda utilizamos segredos do GitHub como um meio conveniente de parametrizar as informações de identidade por ambiente.

    Crie os seguintes segredos no repositório usando a identidade read-only:

    • AZURE_CLIENT_ID : ID do aplicativo (cliente) do registro de aplicativo no Azure
    • AZURE_TENANT_ID : ID do locatário do Active Directory do Azure onde o registro do aplicativo é definido.
    • AZURE_SUBSCRIPTION_ID : ID da assinatura onde o registro do aplicativo é definido.

    As instruções para adicionar os segredos ao repositório podem ser encontradas aqui.

    Crie outro segredo no ambiente production usando a identidade read-write:

    • AZURE_CLIENT_ID : ID do aplicativo (cliente) do registro de aplicativo no Azure

    As instruções para adicionar os segredos ao ambiente podem ser encontradas aqui. O segredo do ambiente substituirá o segredo do repositório ao executar a etapa de implantação no ambiente production quando permissões elevadas de leitura/gravação forem necessárias.

Implantar com ações do GitHub

Usar o Bicep

Há dois fluxos de trabalho principais incluídos na arquitetura de referência:

  1. Testes de Unidades do Bicep

    Esse fluxo de trabalho é executado em cada confirmação e é composto por um conjunto de testes de unidade no código de infraestrutura. Ele executa a compilação do bicep para compilar o bicep em um modelo de ARM. Isso garante que não haja erros de formatação. Em seguida, ele executa uma validação para garantir que o modelo seja implantável. Por fim, o checkov, uma ferramenta de análise de código estático de código aberto para IaC, será executado para detectar problemas de segurança e conformidade. Se o repositório estiver utilizando o GitHub Advanced Security (GHAS), os resultados serão carregados no GitHub.

  2. Implantação / Hipóteses do Bicep

    Esse fluxo de trabalho é executado em cada solicitação de pull e em cada confirmação na filial principal. O estágio hipotético do fluxo de trabalho é usado para entender o impacto das alterações da IaC no ambiente do Azure executando hipóteses. Este relatório é então anexado à PR para facilitar a revisão. O estágio de implantação é executado após a análise hipotética quando o fluxo de trabalho é acionado por um push para a filial principal. Este estágio implantará o modelo no Azure depois que uma revisão manual for aprovada.

Usar o Terraform

Há três fluxos de trabalho principais incluídos na arquitetura de referência:

  1. Testes de Unidades do Terraform

    Esse fluxo de trabalho é executado em cada confirmação e é composto por um conjunto de testes de unidade no código de infraestrutura. Ele executa o fmt do terraform para garantir que o código seja devidamente revisado e siga as melhores práticas do terraform. Em seguida, ele executa a validação do terraform para verificar se o código é sintaticamente correto e internamente consistente. Por fim, o checkov, uma ferramenta de análise de código estático de código aberto para IaC, será executado para detectar problemas de segurança e conformidade. Se o repositório estiver utilizando o GitHub Advanced Security (GHAS), os resultados serão carregados no GitHub.

  2. Plano do Terraform / Aplicar

    Esse fluxo de trabalho é executado em cada solicitação de pull e em cada confirmação na filial principal. O estágio do plano do fluxo de trabalho é usado para entender o impacto das alterações da IaC no ambiente do Azure executando o plano do terraform. Este relatório é então anexado à PR para facilitar a revisão. O estágio de aplicação é executado após o plano quando o fluxo de trabalho é acionado por um push para a filial principal. Este estágio usará o documento do plano e aplicará as alterações após a aprovação de uma revisão manual se houver alterações pendentes no ambiente.

  3. Detecção de Descompasso do Terraform

    Esse fluxo de trabalho é executado periodicamente para verificar seu ambiente em busca de qualquer descompasso na configuração ou alterações feitas fora do Terraform. Se algum descompasso for detectado, um problema do GitHub será gerado para alertar os mantenedores do projeto.