Compartilhar via


Comparar o Terraform e o Bicep

Para alcançar escala, as equipes de DevOps estão sempre procurando maneiras de implantar código rapidamente com um processo confiável e repetível. Quando se trata de nuvem e infraestrutura, esse processo é cada vez mais realizado com infraestrutura como código (IaC). As ferramentas IaC variam de ferramentas de uso geral a ferramentas destinadas a ambientes específicos. O Terraform é um exemplo do primeiro, enquanto o Bicep foi projetado para lidar com tarefas relacionadas ao Azure.

Neste artigo, comparamos nove recursos de infraestrutura e integração do Bicep e do Terraform. Entender essas diferenças ajuda você a decidir qual ferramenta oferece melhor suporte à sua infraestrutura e processos.

Estado e back-end

Tanto o Terraform quanto o Bicep são configurações de estado desejado (DSC), o que facilita o gerenciamento da infraestrutura de TI e desenvolvimento como código. O Terraform armazena o estado sobre sua infraestrutura gerenciada e configuração. O Terraform usa essas informações para mapear recursos do mundo real para sua configuração, rastrear metadados e melhorar o desempenho de infraestruturas maiores. O estado é armazenado em um arquivo local chamado terraform.tfstate, mas também pode ser armazenado remotamente. É fundamental fazer backup e proteger seus arquivos de estado. Assim como o Terraform, o Bíceps é declarativo e busca de objetivos. No entanto, o Bicep não armazena estado. Em vez disso, o Bicep depende da implantação incremental.

Metas de infraestrutura

Ao comparar o Bicep com o Terraform para gerenciar a infraestrutura de nuvem, é importante considerar seu ambiente de nuvem de destino:

  • Somente Azure
  • Nuvens múltiplas ou híbridas

O Bicep é específico do Azure e não foi projetado para funcionar com outros serviços de nuvem.

Se o seu objetivo é automatizar implantações em qualquer um dos seguintes ambientes, o Terraform é provavelmente a melhor opção:

  • Ambientes de virtualização
  • Cenários de várias nuvens - como o Azure e outra(s) nuvem(s)
  • Cargas de trabalho locais

O Terraform interage com outros provedores de nuvem ou APIs usando plugins chamados provedores. Há vários provedores Terraform Azure que permitem o gerenciamento da infraestrutura do Azure. Ao codificar uma configuração do Terraform, você especifica os provedores necessários que está usando. Quando você executa o terraform init, o provedor especificado é instalado e utilizável a partir do seu código.

Ferramentas da CLI

As ferramentas de Interface de Linha de Comando (CLI) desempenham um papel fundamental na orquestração por meio da implementação e gerenciamento de tecnologia de automação. Tanto o Bicep quanto o Terraform oferecem ferramentas CLI.

O Bicep se integra à CLI do Azure, permitindo que os desenvolvedores usem az comandos como:

A CLI do Terraform permite que você execute tarefas como validar e formatar seu código Terraform e criar e aplicar um plano de execução.

O Bicep também fornece um recurso que facilita a integração do Bicep com o Azure Pipelines. Há um recurso semelhante disponível para o Terraform, mas você deve baixar e instalar a extensão Tarefas do Terraform do Azure Pipelines para Visual Studio. Depois de instalado, você pode executar comandos da CLI do Terraform a partir do Azure Pipelines. Além disso, tanto o Terraform quanto o Bicep oferecem suporte a ações do GitHub para automatizar compilações, testes e implantações de software.

Processamento

Existem algumas diferenças importantes entre o Bicep e o Terraform em termos de eficiência e otimizações das implantações. Com o Bicep, o processamento ocorre no lado principal do serviço de infraestrutura do Azure. Esse recurso oferece vantagens, como o processamento de comprovação para verificar a política ou a disponibilidade para implantar várias instâncias em uma região. Com o Terraform, o processamento é feito dentro do cliente Terraform. Assim, o pré-processamento não envolve chamadas para o Azure, pois ele usa estado e HCL (HashiCorp Language) para determinar as alterações necessárias.

Autenticação

Os recursos de autenticação do Azure variam entre o Bicep e o Terraform. Com o Bicep, um token de autorização é fornecido durante a solicitação para enviar um arquivo Bicep e um modelo ARM. O ARM garante que você tenha permissão para criar a implantação e implantar recursos dentro do modelo especificado. O Terraform autentica cada API com base nas credenciais do provedor, como CLI do Azure, entidade de serviço ou identidades gerenciadas para recursos do Azure. Além disso, várias credenciais de provedor podem ser utilizadas em uma única configuração.

Integrações do Azure

Você também deve considerar o uso de recursos do Azure, como a Política do Azure, e como cada um interage com outras ferramentas e idiomas. A validação de comprovação do Bicep determina se um recurso não está em conformidade com uma política para que ele falhe antes de uma implantação. Assim, os desenvolvedores podem corrigir recursos com políticas usando modelos ARM fornecidos. O modelo ARM pode ser usado para criar uma atribuição de política a outro recurso para correção automatizada. O Terraform, no entanto, falha quando um recurso é implantado que não é permitido devido à política.

Integração do portal

Uma grande vantagem que o Bicep tem sobre o Terraform é a capacidade de automatizar as ações do portal. Com o Bicep, você pode usar o portal do Azure para exportar modelos. A exportação de um modelo ajuda você a entender a sintaxe e as propriedades que implantam seus recursos. Você pode automatizar implantações futuras começando com o modelo exportado e modificando-o para atender às suas necessidades. Até que os modelos Terraform sejam suportados, você precisa traduzir o modelo exportado manualmente.

Embora o Terraform não forneça as mesmas integrações de portal que o Bicep, a infraestrutura existente do Azure pode ser usada sob o gerenciamento do Terraform usando o Azure Export for Terraform. (O Azure Export for Terraform é uma ferramenta de código aberto de propriedade e mantida pela Microsoft no Azure/aztfexport GitHub repo.)

Mudanças fora de banda

Alterações de configuração fora de banda são alterações feitas em uma configuração de dispositivo fora do contexto da ferramenta. Por exemplo, digamos que você implante um Conjunto de Dimensionamento de Máquina Virtual usando Bicep ou Terraform. Se você alterar esse Conjunto de Dimensionamento de Máquina Virtual usando o portal, a alteração será "fora de banda" e desconhecida para sua ferramenta IaC.

Se você estiver usando o Bicep, as alterações fora de banda devem ser reconciliadas com o Bicep e o código do Modelo ARM para evitar que essas alterações sejam substituídas na próxima implantação. Essas alterações não bloqueiam a implantação.

Se você estiver usando o Terraform, precisará importar as alterações fora de banda para o estado Terraform e atualizar a HCL.

Assim, se um ambiente envolve mudanças frequentes fora de banda, o Bicep é mais fácil de usar. Ao usar o Terraform, você deve minimizar as alterações fora de banda.

Estruturas de nuvem

O Cloud Adoption Framework (CAF) é uma coleção de documentação, práticas recomendadas e ferramentas para acelerar a adoção da nuvem em toda a sua jornada para a nuvem. O Azure fornece serviços nativos para implantar zonas de aterrissagem. O Bicep simplifica esse processo com uma experiência de portal baseada em modelos ARM e implementação de zonas de pouso. O Terraform utiliza um módulo de zonas de aterrissagem em escala empresarial para implantar, gerenciar e operacionalizar com o Azure.

Resumo

Bicep e Terraform oferecem muitos recursos de integração e infraestrutura fáceis de usar. Esses recursos facilitam a implementação e o gerenciamento da tecnologia de automação. Ao decidir qual é o melhor para seu ambiente, é importante considerar se você está implantando em mais de uma nuvem ou se sua infraestrutura consiste em um ambiente de nuvem híbrida ou múltipla. Além disso, certifique-se de considerar os nove recursos discutidos neste artigo para fazer a melhor escolha para sua organização.