Infraestrutura como código

Dica

Esse conteúdo é um trecho do eBook, Architecting Cloud Native .NET Applications for Azure, disponível no .NET Docs ou como um PDF para download gratuito que pode ser lido offline.

Baixar PDF

Os sistemas nativos de nuvem adotam microsserviços, contêineres e design moderno do sistema para obter velocidade e agilidade. Eles fornecem estágios automatizados de build e versão para garantir o código consistente e de qualidade. Mas isso é apenas parte da história. Como você provisiona os ambientes de nuvem nos quais esses sistemas são executados?

Aplicativos nativos de nuvem modernos adotam a prática amplamente aceita de Infraestrutura como Código ou IaC. Com a IaC, você automatiza o provisionamento de plataforma. Você essencialmente aplica práticas de engenharia de software, como teste e controle de versão às práticas de DevOps. Sua infraestrutura e implantações são automatizadas, consistentes e repetíveis. Assim como a entrega contínua automatiza o modelo tradicional de implantações manuais, a IaC (Infraestrutura como Código) está evoluindo como os ambientes de aplicativo são gerenciados.

Ferramentas como o ARM (Azure Resource Manager), o Terraform e a CLI (Interface de Linha de Comando) do Azure permitem que você crie um script declarativo da infraestrutura de nuvem necessária.

Modelos do Azure Resource Manager

ARM significa Azure Resource Manager. É um mecanismo de provisionamento de API que é integrado ao Azure e exposto como um serviço de API. O ARM permite que você implante, atualize, exclua e gerencie os recursos contidos no grupo de recursos do Azure em uma única operação coordenada. Você fornece ao mecanismo um modelo baseado em JSON que especifica os recursos necessários e sua configuração. O ARM orquestra automaticamente a implantação na ordem correta respeitando as dependências. O mecanismo garante a idempotência. Se já existir um recurso desejado com a mesma configuração, o provisionamento será ignorado.

Os modelos do Azure Resource Manager são uma linguagem baseada em JSON para definir vários recursos no Azure. O esquema básico se parece com a Figura 10-14.

{
  "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
  "contentVersion": "",
  "apiProfile": "",
  "parameters": {  },
  "variables": {  },
  "functions": [  ],
  "resources": [  ],
  "outputs": {  }
}

Figura 10-14 – O esquema de um modelo do Resource Manager

Nesse modelo, pode-se definir um contêiner de armazenamento dentro da seção de recursos da seguinte maneira:

"resources": [
    {
      "type": "Microsoft.Storage/storageAccounts",
      "name": "[variables('storageAccountName')]",
      "location": "[parameters('location')]",
      "apiVersion": "2018-07-01",
      "sku": {
        "name": "[parameters('storageAccountType')]"
      },
      "kind": "StorageV2",
      "properties": {}
    }
  ],

Figura 10-15 – Um exemplo de uma conta de armazenamento definida em um modelo do Resource Manager

Um modelo do ARM pode ser parametrizado com informações dinâmicas de ambiente e configuração. Isso permite que ele seja reutilizado para definir diferentes ambientes, como desenvolvimento, QA ou produção. Normalmente, o modelo cria todos os recursos em um único grupo de recursos do Azure. É possível definir vários grupos de recursos em um único modelo do Resource Manager, se necessário. Você pode excluir todos os recursos em um ambiente excluindo o próprio grupo de recursos. A análise de custo também pode ser executada no nível do grupo de recursos, permitindo uma contabilidade rápida de quanto cada ambiente está custando.

Há muitos exemplos de modelos do ARM disponíveis no projeto modelos de início rápido do Azure no GitHub. Eles podem ajudar a acelerar a criação de um novo modelo ou a modificação de um existente.

Os modelos do Resource Manager podem ser executados de várias maneiras. Talvez a maneira mais simples seja simplesmente colá-los no portal do Azure. Para implantações experimentais, esse método pode ser rápido. Eles também podem ser executados como parte de um processo de build ou lançamento no Azure DevOps. Há tarefas que aproveitarão as conexões no Azure para executar os modelos. As alterações nos modelos do Resource Manager são aplicadas incrementalmente, o que significa que adicionar um novo recurso requer apenas adicioná-lo ao modelo. As ferramentas reconciliarão as diferenças entre os recursos atuais e os definidos no modelo. Em seguida, os recursos serão criados ou alterados para que correspondam ao que é definido no modelo.

Terraformação

Aplicativos nativos de nuvem geralmente são construídos para serem cloud agnostic. Isso significa que o aplicativo não está firmemente acoplado a um fornecedor de nuvem específico e pode ser implantado em qualquer nuvem pública.

O Terraform é uma ferramenta de modelagem comercial que pode provisionar aplicativos nativos de nuvem em todos os principais players de nuvem: Azure, Google Cloud Platform, AWS e AliCloud. Em vez de usar JSON como a linguagem de definição de modelo, ele utiliza a HCL (Linguagem de Configuração HashiCorp), que é um pouco mais concisa.

Um arquivo Terraform de exemplo que faz o mesmo que o modelo anterior do Resource Manager (Figura 10-15) é mostrado na Figura 10-16:

provider "azurerm" {
  version = "=1.28.0"
}

resource "azurerm_resource_group" "testrg" {
  name     = "production"
  location = "West US"
}

resource "azurerm_storage_account" "testsa" {
  name                     = "${var.storageAccountName}"
  resource_group_name      = "${azurerm_resource_group.testrg.name}"
  location                 = "${var.region}"
  account_tier             = "${var.tier}"
  account_replication_type = "${var.replicationType}"

}

Figura 10-16 – Um exemplo de um modelo do Resource Manager

O Terraform também fornece mensagens de erro intuitivas para modelos de problema. Há também uma tarefa de validação útil que pode ser usada na fase de build para detectar erros de modelo antecipadamente.

Assim como acontece com os modelos do Resource Manager, as ferramentas de linha de comando estão disponíveis para implantar modelos do Terraform. Também há tarefas criadas pela comunidade no Azure Pipelines que podem validar e aplicar modelos do Terraform.

Às vezes, os modelos terraform e ARM geram valores significativos, como uma cadeia de conexão para um banco de dados recém-criado. Essas informações podem ser capturadas no pipeline de build e usadas em tarefas subsequentes.

Scripts e tarefas da CLI do Azure

Por fim, você pode aproveitar a CLI do Azure para criar um script declarativo de sua infraestrutura de nuvem. Os scripts da CLI do Azure podem ser criados, encontrados e compartilhados para provisionar e configurar quase qualquer recurso do Azure. A CLI é simples de usar com uma curva de aprendizado suave. Os scripts são executados no PowerShell ou no Bash. Eles também são simples de depurar, especialmente quando comparados com modelos do ARM.

Os scripts da CLI do Azure funcionam bem quando você precisa derrubar e reimplantar sua infraestrutura. Atualizar um ambiente existente pode ser complicado. Muitos comandos da CLI não são idempotentes. Isso significa que eles recriarão o recurso sempre que eles forem executados, mesmo que o recurso já exista. É sempre possível adicionar código que verifica a existência de cada recurso antes de criá-lo. Mas, fazendo isso, seu script pode ficar inchado e difícil de gerenciar.

Esses scripts também podem ser inseridos em pipelines do Azure DevOps como Azure CLI tasks. A execução do pipeline invoca o script.

A Figura 10-17 mostra um snippet yaml que lista a versão da CLI do Azure e os detalhes da assinatura. Observe como os comandos da CLI do Azure são incluídos em um script embutido.

- task: AzureCLI@2
  displayName: Azure CLI
  inputs:
    azureSubscription: <Name of the Azure Resource Manager service connection>
    scriptType: ps
    scriptLocation: inlineScript
    inlineScript: |
      az --version
      az account show

Figura 10-17 – Script da CLI do Azure

No artigo, O que é infraestrutura como código, o autor Sam Guckenheimer descreve como"As equipes que implementam IaC podem fornecer ambientes estáveis rapidamente e em escala. As equipes evitam a configuração manual de ambientes e impõem consistência, representando o estado desejado de seus ambientes por meio do código. As implantações de infraestrutura com IaC são repetíveis e evitam problemas de runtime causados por descompasso de configuração ou dependências ausentes. As equipes do DevOps podem trabalhar em conjunto com um conjunto unificado de práticas e ferramentas para fornecer aplicativos e sua infraestrutura de suporte rapidamente, de forma confiável e em escala.".

AnteriorPróximo