Partilhar via

Implantar na infraestrutura do Azure com as Ações do GitHub

Neste guia, abordaremos como utilizar CI/CD e Infraestrutura como Código (IaC) para implantar no Azure com Ações do GitHub 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 escalável, seguro, resiliente e altamente disponível. Para ver mais exemplos reais de arquiteturas de nuvem e ideias de solução, navegue por 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 automação de IaC e CI/CD. Os benefícios dessa abordagem incluem:

  • Declarativo: Quando você define sua infraestrutura e o processo de implantação em código, ele pode ser versionado e revisado usando o ciclo de vida de desenvolvimento de software padrão. O IaC também ajuda a evitar qualquer desvio 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 protegidos 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 melhorada: Ao utilizar 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 na Central de Arquitetura do Azure ou o que é infraestrutura como código na Central 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 ramificação e verifique as modificações de código IaC necessárias.
  2. Crie uma solicitação pull (PR) no GitHub assim que estiver pronto para mesclar suas alterações em seu ambiente.
  3. Um fluxo de trabalho de Ações do GitHub será acionado para garantir que seu código seja bem formatado, internamente consistente e produza uma infraestrutura segura. Além disso, um Plano Terraform ou uma análise 'what-if' do Bicep será executado para gerar uma visualização das alterações que acontecerão no seu ambiente do Azure.
  4. Uma vez devidamente revisado, o PR pode ser fundido no seu ramo principal.
  5. Outro workflow do GitHub Actions será acionado a partir da branch principal e executará as alterações usando o seu provedor de IaC.
  6. (exclusivo para Terraform) Um fluxo de trabalho de Ação do GitHub agendado regularmente também deve ser executado para procurar qualquer desvio de configuração em seu ambiente e criar um novo problema se forem detetadas alterações.

Pré-requisitos

Utilizar Bicep

  1. Criar os ambientes do 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 nomeado production seguindo estas instruções. No ambiente production, configure uma regra de proteção e adicione os aprovadores necessários que precisam aprovar implantações de produção. Você também pode limitar o ambiente ao seu ramo principal. Pode encontrar instruções detalhadas aqui.

  2. Configurar a Identidade do Azure:

    É necessário um aplicativo do Azure Ative Directory 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 nome do production ambiente.
    • Defina Tipo de entidade como Pull Request.
    • Defina Tipo de entidade como Branch e use o nome da main filial.

  3. Adicionar segredos do GitHub

    Observação

    Embora nenhum dos dados sobre as identidades do Azure contenha segredos ou credenciais, ainda utilizamos os segredos do GitHub como um meio conveniente para 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 locatário do Azure Active Directory onde o registo da aplicação está definido.
    • AZURE_SUBSCRIPTION_ID : O ID da subscrição onde o registo da aplicação está definido.

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

Utilize 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á ser persistido entre diferentes execuções do fluxo de trabalho. A abordagem recomendada é armazenar esse arquivo em uma Conta de Armazenamento do Azure ou 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 Terraform deve ser atualizado com o local de armazenamento selecionado (consulte a documentação aqui).

  2. Criar ambiente 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 nomeado production seguindo estas instruções. No ambiente production definido, configure uma regra de proteção e adicione os aprovadores necessários que precisam aprovar as implementações de produção. Você também pode limitar o ambiente ao seu ramo principal. Pode encontrar instruções detalhadas aqui.

  3. Configurar a Identidade do Azure:

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

    • Defina Entity Type para Environment e use o ambiente production.

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

    • Defina Entity Type como Pull Request.
    • Defina Entity Type para Branch e use o nome da ramificação main.

  4. Adicionar segredos do GitHub

    Observação

    Embora nenhum dos dados sobre as identidades do Azure contenha segredos ou credenciais, ainda utilizamos os segredos do GitHub como um meio conveniente para 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 locatário do Azure Active Directory onde o registo da aplicação está definido.
    • AZURE_SUBSCRIPTION_ID : O ID da subscrição onde o registo da aplicação está definido.

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

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

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

    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 elevadas de leitura/gravação.

Implantar com ações do GitHub

Utilizar Bicep

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

  1. Testes Unitários de Bíceps

    Este workflow é executado em cada commit e é composto por um conjunto de testes de unidade no código de infraestrutura. Ele executa bicep build para compilar o bicep num 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 código aberto para IaC, será executado para detetar 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. Bicep What-If / Deploy

    Esse fluxo de trabalho é executado em cada solicitação pull e em cada confirmação para a ramificação principal. A fase "e se" do fluxo de trabalho é usada para entender o impacto das alterações do IaC no ambiente do Azure executando what-if. Este relatório é então anexado ao PR para fácil 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 ramificação principal. Esta etapa implantará o modelo no Azure após a aprovação de uma revisão manual.

Utilize Terraform

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

  1. Testes Unitários Terraform

    Este fluxo de trabalho é 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 analisado e siga as melhores práticas do Terraform. Em seguida, ele executa a validação de terraforma 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 código aberto para IaC, será executado para detetar 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. Terraform Planejamento / Aplicar

    Esse fluxo de trabalho é executado em cada solicitação pull e em cada confirmação para a ramificação principal. O estágio de plano do fluxo de trabalho é usado para entender o impacto das alterações do IaC no ambiente do Azure executando o terraform plan. Este relatório é então anexado ao PR para fácil revisão. A etapa de aplicação é executada após o plano quando o fluxo de trabalho é acionado por um push na ramificação principal. Esta etapa levará 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. Deteção de deriva Terraform

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

  • Last updated on