Infraestrutura como Código

A Infraestrutura como Código (IaC) é uma prática chave do DevOps que envolve a gestão da infraestrutura, como redes, serviços de computação, bases de dados, armazenamentos e topologia de ligação, num modelo descritivo. A IaC permite que as equipas desenvolvam e libertem alterações mais rapidamente e com maior confiança. Os benefícios da IaC incluem:

  • Maior confiança nas implementações
  • Capacidade de gerir vários ambientes
  • Melhor compreensão do estado da infraestrutura

Para obter mais informações sobre as vantagens de utilizar a Infraestrutura como Código, veja Infraestrutura repetível.

Ferramentas

Existem duas abordagens que pode seguir ao implementar a Infraestrutura como Código.

  • A Infraestrutura Imperativa como Código envolve escrever scripts em idiomas como o Bash ou o PowerShell. Indica explicitamente os comandos que são executados para produzir um resultado desejado. Quando utiliza implementações imperativas, cabe-lhe a si gerir a sequência de dependências, controlo de erros e atualizações de recursos.
  • A Infraestrutura Declarativa como Código envolve escrever uma definição que defina o aspeto que pretende que o seu ambiente tenha. Nesta definição, especifique um resultado pretendido em vez de como pretende que seja realizado. A ferramenta descobre como fazer com que o resultado aconteça ao inspecionar o estado atual, compará-lo com o estado de destino e, em seguida, aplicar as diferenças.

Modelos de ARM

Reveja as informações sobre os modelos de Resource Manager do Azure (modelos do ARM).

Bicep

O Bicep é uma linguagem específica do domínio que utiliza sintaxe declarativa para implementar recursos do Azure. Nos ficheiros bicep, define a infraestrutura que pretende implementar e as respetivas propriedades. Em comparação com os modelos do ARM, os ficheiros Bicep são mais fáceis de ler e escrever para uma audiência não programador porque utilizam uma sintaxe concisa.

param location string = resourceGroup().location
param storageAccountName string = 'toylaunch${uniqueString(resourceGroup().id)}'
resource storageAccount 'Microsoft.Storage/storageAccounts@2021-06-01' = {
  name: storageAccountName
  location: location
  sku: {
    name: 'Standard_LRS'
  }
  kind: 'StorageV2'
  properties: {
    accessTier: 'Hot'
  }
}

Terraform

Reveja as informações sobre o Terraform.

CLI do Azure

Veja as informações sobre a CLI do Azure.

Infraestrutura como módulos de Código

Um dos objetivos da utilização de código para implementar a infraestrutura é evitar duplicar o trabalho ou criar vários modelos para os mesmos fins ou semelhantes. Os módulos de infraestrutura devem ser reutilizáveis e flexíveis e devem ter um objetivo claro.

Os módulos são ficheiros independentes, normalmente contendo um conjunto de recursos destinado a serem implementados em conjunto. Os módulos permitem-lhe dividir modelos complexos em conjuntos de código mais pequenos e geríveis. Pode garantir que cada módulo se concentra numa tarefa específica e que todos os módulos são reutilizáveis para várias implementações e cargas de trabalho.

Módulos bicep

O Bicep permite-lhe criar e chamar módulos. Assim que os módulos forem criados, podem ser consumidos a partir de qualquer outro modelo do Bicep. Um módulo bicep de alta qualidade deve definir vários recursos relacionados. Por exemplo, quando define uma função do Azure, normalmente implementa uma determinada aplicação, um plano de alojamento para essa aplicação e uma conta de armazenamento para os metadados dessa aplicação. Estes componentes são definidos separadamente, mas formam um agrupamento lógico de recursos, pelo que deve considerar defini-los em conjunto como um módulo.

Os módulos bicep utilizam frequentemente:

  • Parâmetros para aceitar valores de um módulo de chamadas.
  • Valores de saída para devolver resultados a um módulo de chamadas.
  • Recursos para definir um ou mais objetos de infraestrutura para um módulo gerir.

Publicar módulos do Bicep

Tem várias opções para publicar e partilhar módulos bicep.

  • Registo público: O registo do módulo público está alojado num registo de contentor da Microsoft (MCR). O código fonte e os módulos que contém são armazenados no GitHub.
  • Registo privado: Pode utilizar o Azure Container Registry para publicar módulos num registo privado. Para obter informações sobre a publicação de módulos num registo num pipeline ci/CD, consulte Bicep e GitHub Actions ou, se preferir, Bicep e Pipelines do Azure.
  • Especificação do Modelo: Pode utilizar especificações de modelo para publicar módulos do Bicep. As especificações de modelo devem ser modelos completos, mas o Bicep permite-lhe utilizar especificações de modelo para implementar módulos.
  • Sistema de controlo de versões: Pode carregar módulos diretamente a partir de ferramentas de controlo de versões, como o GitHub ou o Azure DevOps.

Módulos do Terraform

O Terraform permite-lhe criar e chamar módulos. Cada configuração do Terraform tem, pelo menos, um módulo, conhecido como módulo de raiz, que consiste em recursos definidos em .tf ficheiros no seu diretório de trabalho principal. Cada módulo pode chamar outros módulos, o que lhe permite incluir módulos subordinados no ficheiro de configuração principal. Os módulos também podem ser chamados várias vezes na mesma configuração ou a partir de diferentes configurações.

Os módulos são definidos com todos os mesmos conceitos de linguagem de configuração. Utilizam mais frequentemente:

  • Variáveis de entrada para aceitar valores de um módulo de chamadas.
  • Valores de saída para devolver resultados a um módulo de chamadas.
  • Recursos para definir um ou mais objetos de infraestrutura para um módulo gerir.

Publicar módulos do Terraform

Tem várias opções para publicar e partilhar módulos do Terraform:

  • Registo público: A HashiCorp tem o seu próprio Registo de Módulos do Terraform que permite aos utilizadores gerar módulos Terraform sharable. Atualmente, existem vários módulos do Azure publicados no Registo de Módulos do Terraform.
  • Registo privado: Pode publicar facilmente módulos do Terraform num repositório privado, como o Registo Privado do Terraform Cloud ou Azure Container Registry.
  • Sistema de controlo de versões: Pode carregar módulos privados diretamente a partir de ferramentas de controlo de versões, como o GitHub. Para obter informações sobre origens suportadas, veja Origens de módulos do Terraform.

Considerações de design

  • Considere utilizar IaC ao implementar recursos de zona de destino no Azure. A IaC realiza totalmente a otimização da implementação, reduz o esforço de configuração e automatiza as implementações de todo o ambiente.

  • Determine se deve adotar uma abordagem IaC imperativa ou declarativa.

    • Se tomar uma abordagem imperativa, indique explicitamente os comandos a executar que produzem o resultado pretendido.

    • Se tiver uma abordagem declarativa, especifique o resultado pretendido em vez de como pretende fazê-lo.

  • Considere os âmbitos de implementação. Tenha uma boa compreensão dos níveis de gestão e hierarquia do Azure. Cada implementação iaC tem de saber o âmbito no qual os recursos do Azure são implementados.

  • Determine se deve utilizar uma ferramenta IaC nativa do Azure ou do Azure não nativa. Alguns pontos a considerar:

    • As ferramentas nativas do Azure, como a CLI do Azure, Os Modelos do ARM e o Bicep são totalmente suportadas pela Microsoft, o que permite que as novas funcionalidades sejam integradas mais rapidamente.

    • Ferramentas não nativas, como o Terraform, permitem-lhe gerir a infraestrutura como código em vários fornecedores de cloud, como o AWS ou o GCP. No entanto, as novas funcionalidades do Azure podem demorar algum tempo a ser incluídas em não nativos. Se a sua organização for multicloud ou a sua organização já estiver a utilizar e bem versada no Terraform, considere utilizar o Terraform para implementar zonas de destino do Azure.

  • Uma vez que os módulos lhe permitem dividir modelos complexos em conjuntos de código mais pequenos, considere utilizar módulos IaC para recursos que são normalmente implementados em conjunto. Pode garantir que cada módulo se concentra numa tarefa específica e é reutilizável para várias implementações e cargas de trabalho.

  • Considere adotar uma estratégia de publicação para módulos IaC ao escolher entre registos públicos, registos privados ou um sistema de controlo de versões, como um repositório Git.

  • Considere utilizar um pipeline CI/CD para implementações IaC. Um pipeline impõe o processo reutilizável que definiu para garantir a qualidade das implementações e do ambiente do Azure.

Recomendações de conceção

  • Adote uma abordagem IaC para implementar, gerir, governar e suportar implementações de zonas de destino do Azure.

  • Utilize as ferramentas nativas do Azure para IaC nos seguintes cenários:

    • Quer utilizar apenas ferramentas nativas do Azure. A sua organização pode ter experiência de implementação de modelos ARM ou Bicep anterior.

    • A sua organização quer ter suporte imediato para todas as versões de pré-visualização e GA dos serviços do Azure.

  • Utilize ferramentas não nativas para IaC nos seguintes cenários:

    • Atualmente, a sua organização utiliza o Terraform para implementar a infraestrutura noutras clouds, como o AWS ou o GCP.

    • A sua organização não precisa de ter suporte imediato para todas as versões de pré-visualização e DISPONIBILIDADE dos serviços do Azure.

  • Utilize módulos IaC reutilizáveis para evitar trabalho repetitivo. Pode partilhar módulos em toda a sua organização para implementar vários projetos ou cargas de trabalho e gerir códigos menos complexos.

  • Publique e utilize módulos IaC a partir de registos públicos nos seguintes cenários:

    • Quer utilizar módulos para a Zona de Destino do Azure já publicados nos registos públicos. Para obter mais informações, veja Módulo Terraform das zonas de destino do Azure.

    • Quer utilizar módulos que são mantidos, atualizados e suportados pela Microsoft, Terraform ou outros fornecedores de módulos.

      • Certifique-se de que verifica a instrução de suporte de qualquer fornecedor de módulos que avalie.
  • Publique e utilize módulos IaC a partir de registos privados ou sistemas de controlo de versões nos seguintes cenários:

    • Quer criar os seus próprios módulos com base nos seus requisitos organizacionais.

    • Quer ter controlo total de todas as funcionalidades e manter, atualizar e publicar novas versões de módulos.

  • Utilize um pipeline CI/CD para implementar artefactos IaC e garantir a qualidade da sua implementação e dos ambientes do Azure.