Compartilhar via

Implantar na infraestrutura do Azure com o GitHub Actions

Neste guia, abordaremos como utilizar CI/CD e IaC (Infraestrutura como Código) 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 criar um aplicativo no Azure escalonável, seguro, resiliente e altamente disponível. Para ver mais exemplos reais de arquiteturas de nuvem e ideias de solução, navegue pelas arquiteturas do Azure.

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

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

  • Declarativo: quando você define sua infraestrutura e processo de implantação em 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 em 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 protegida 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: modelos gerenciados centralmente podem ser protegidos e aprovados por uma equipe de segurança ou operações de nuvem para atender aos padrões internos.

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

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

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

Architecture

Visão geral da arquitetura do uso de CI/CD para implantar o Azure

Fluxo de dados

  1. Crie uma nova branch e faça o check-in das modificações de código IaC necessárias.
  2. Crie uma PR (Solicitação de Pull) no GitHub quando estiver pronto para mesclar as alterações no seu ambiente.
  3. Um fluxo de trabalho do GitHub Actions será disparado para garantir que seu código esteja bem formatado, internamente consistente e produza uma infraestrutura segura. Além disso, uma análise de hipóteses do Plano Terraform ou do Bicep será executada para gerar uma visualização das alterações que ocorrerão em seu ambiente do Azure.
  4. Depois de revisado adequadamente, a PR pode ser mesclada em seu branch principal.
  5. Outro fluxo de trabalho do GitHub Actions será disparado do branch principal e executará as alterações usando seu provedor de IaC.
  6. (exclusivo do Terraform) Um fluxo de trabalho do GitHub Action agendado regularmente também deve ser executado para procurar qualquer descompasso de configuração em seu ambiente e criar um novo problema se forem detectadas alterações.

Pré-requisitos

Usar o Bicep

  1. Criar ambientes do GitHub

    Os fluxos de trabalho utilizam os 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 nomeado production seguindo estas instruções. No ambiente production, configure uma regra de proteção e adicione os aprovadores necessários que devem autorizar as implantações em produção. Você também pode restringir o ambiente ao seu branch principal. Pode encontrar instruções detalhadas aqui.

  2. Configurar a Identidade do Azure:

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

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

  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 parametrizar as informações de identidade por ambiente.

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

    • AZURE_CLIENT_ID : A ID do aplicativo (cliente) do registro do aplicativo no Azure
    • AZURE_TENANT_ID : o ID do tenant do Azure Active Directory onde o registro do aplicativo é definido.
    • AZURE_SUBSCRIPTION_ID : a ID da assinatura em que 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 de Estado do Terraform

    O Terraform utiliza um arquivo de estado para armazenar informações sobre o estado atual da sua infraestrutura gerenciada e a configuração associada. Esse arquivo precisará ser mantido 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 (confira aqui a documentação).

  2. Criar ambiente do GitHub

    Os fluxos de trabalho utilizam os 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 nomeado production seguindo estas instruções. No ambiente production, configure uma regra de proteção e adicione os aprovadores necessários que você deseja que precisem aprovar as implantações de produção. Você também pode limitar o ambiente ao ramo principal. Pode encontrar instruções detalhadas aqui.

  3. Configurar a Identidade do Azure:

    É necessário um aplicativo do Azure Active Directory que tenha permissões para implantar na sua assinatura do Azure. Crie um aplicativo separado para as contas read-only e read/write e atribua 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 em que reside o estado 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 read/write identidade, crie uma credencial federada da seguinte maneira:

    • Defina Entity Type como Environment e utilize o nome de ambiente production.

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

    • Definir Entity Type para Pull Request.
    • Defina Entity Type para Branch e use o nome do branch main.

  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 parametrizar as informações de identidade por ambiente.

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

    • AZURE_CLIENT_ID : A ID do aplicativo (cliente) do registro do aplicativo no Azure
    • AZURE_TENANT_ID : o ID do inquilino do Azure Active Directory em que o registro do aplicativo está definido.
    • AZURE_SUBSCRIPTION_ID : a ID da assinatura em que o registro do aplicativo é definido.

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

    Crie um novo segredo no ambiente production utilizando a identidade read-write

    • AZURE_CLIENT_ID : A ID do aplicativo (cliente) do registro do 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 production ambiente quando forem necessárias permissões de leitura/gravação elevadas.

Implante com o GitHub Actions

Usar o Bicep

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

  1. Testes de unidade 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 bicep build para compilar o bicep em um modelo 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 software livre para IaC, será executado para detectar problemas de segurança e conformidade. Se o repositório estiver utilizando o GHAS (GitHub Advanced Security), os resultados serão carregados no GitHub.

  2. Bicep What-If/Deploy

    Esse fluxo de trabalho é executado em cada pull request e em cada commit no branch principal. O estágio de hipóteses do fluxo de trabalho é usado para entender o impacto das alterações de IaC no ambiente do Azure executando what-if. Em seguida, este relatório é anexado à PR para uma revisão fácil. O estágio de implantação é executado após a análise de hipóteses quando o fluxo de trabalho é disparado por um push para o branch principal. Esse estágio implantará o modelo no Azure após a aprovação de uma revisão manual.

Usar o Terraform

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

  1. Testes de unidade do Terraform

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

  2. Terraform Plan / Apply

    Esse fluxo de trabalho é executado em cada pull request e em cada commit no branch principal. O estágio de planejamento do fluxo de trabalho é usado para entender o impacto das alterações de IaC no ambiente do Azure executando o terraform plan. Em seguida, este relatório é anexado à PR para uma revisão fácil. A fase de aplicação é executada após a fase de planejamento quando o fluxo de trabalho é impulsionado por um push no branch principal. Esse estágio pegará o documento do plano e aplicará as alterações depois que uma revisão manual for assinada se houver alterações pendentes no ambiente.

  3. Detecção de desvio do Terraform

    Esse fluxo de trabalho é executado periodicamente para verificar seu ambiente quanto a qualquer descompasso de configuração ou alterações feitas fora do Terraform. Se algum descompasso for detectado, uma issue do GitHub será criada para alertar os mantenedores do projeto.

  • Last updated on