Introdução

  • 8 minutos

A IaC (Infraestrutura como Código) é a prática de definir e gerenciar recursos de nuvem por meio de arquivos de configuração legíveis por máquina, em vez de por meio de scripts selecionados ou não planejados pelo portal manual. Em vez de fazer logon no portal Azure para criar uma rede virtual, você escreve um arquivo que descreve a rede. Em seguida, uma ferramenta lê esse arquivo e cria o recurso para você.

Essa abordagem traz uma mudança fundamental na forma como a infraestrutura é gerenciada. As alterações são controladas no controle de versão, as implantações são repetíveis e os ambientes podem ser recriados do zero a qualquer momento. Se algo quebrar, você poderá reverter para um estado anterior. Se você precisar de um ambiente de preparo que espelha a produção, aplique os mesmos arquivos com parâmetros diferentes.

A IaC também integra a infraestrutura à mesma disciplina de engenharia que o código do aplicativo. Os mesmos fluxos de trabalho de solicitação de pull, revisões de código e práticas de teste automatizadas que se aplicam ao seu aplicativo agora podem se aplicar aos sistemas em que seu aplicativo é executado.

Sem a assistência de IA, o ciclo de criação de IaC (Infraestrutura como Código) tem esta aparência:

  1. Modelo de escrita
  2. Pesquisar documentação
  3. Corrigir sintaxe
  4. Valide localmente
  5. Executar o teste de hipóteses
  6. Implantar no preparo
  7. Revisar alterações
  8. Implantar em produção

E repita o mesmo para cada implantação, seja nova ou atualizada.

Objetivos de aprendizagem

Ao final deste módulo, você será capaz de:

  • Explicar o que é infraestrutura como código e por que ela é importante em operações de nuvem modernas
  • Descrever a diferença entre abordagens declarativas e imperativas para IaC
  • Identificar o fluxo de trabalho de criação de IaC tradicional e seus pontos de atrito
  • Explicar como GitHub Copilot altera o loop interno de IaC
  • Descrever os recursos de GitHub Copilot mais relevantes para o trabalho de infraestrutura

Desafios da Infraestrutura como Código

Cada etapa tem atrito. Escrever um modelo de Bicep do zero requer conhecimento de tipos de recursos, versões de API, propriedades necessárias e convenções de nomenclatura específicas de Azure. Pesquisar a versão correta da API para Microsoft.Network/virtualNetworks significa navegar na documentação ou copiar de projetos anteriores. Erros de sintaxe são capturados após a execução de um comando de compilação. E manter os modelos atualizados à medida que as APIs de Azure evoluem é uma carga de manutenção contínua.

O resultado é que a IaC é frequentemente tratada como uma habilidade especializada. Engenheiros que não escrevem modelos regularmente recorrem à seleção por portal, quebrando a consistência que a IaC deveria proporcionar.

Abordagem declarativa vs. imperativa

Há dois estilos fundamentais de IaC. Entender a diferença ajuda você a escolher a ferramenta certa e criar melhores prompts para GitHub Copilot.

IaC declarativa

Em uma abordagem declarativa, você descreve o estado final desejado de sua infraestrutura. A ferramenta descobre como chegar lá.

"Quero uma VNet com espaço de endereço 10.0.0.0/16 e duas sub-redes."

Azure Bicep e modelos do ARM são declarativos. Você define quais recursos devem existir e Azure Resource Manager manipula o sequenciamento e a criação. Se o recurso já existir no estado correto, nenhuma alteração será aplicada. Se ele não existir, ele será criado. Se estiver diferente, ele será atualizado.

IaC imperativa

Em uma abordagem imperativa, você descreve as etapas necessárias para alcançar o estado desejado. Você está escrevendo um procedimento, não uma declaração.

"Verifique se a VNet existe. Caso contrário, execute az network vnet create...."

scripts do CLI do Azure e do Azure PowerShell são normalmente imperativos. Você controla o fluxo, manipula erros e gerencia a ordenação por conta própria. Dando-lhe mais controle, mas também mais responsabilidade. Isso inclui lidar com a idempotência, o que significa que o script deve ser seguro para ser executado várias vezes.

Qual você deve usar?

A escolha certa depende do cenário. Ferramentas declarativas como Bicep são melhores para gerenciar recursos de infraestrutura de longa duração porque lidam com o estado e desvios automaticamente. Ferramentas imperativas, como scripts da CLI, são melhores para tarefas operacionais, etapas de instalação única ou automação que envolve lógica, condições e loops.

Na prática, a maioria dos engenheiros de nuvem usa ambos. E GitHub Copilot ajuda com ambos também.

Como GitHub Copilot altera o processo de criação de modelo

GitHub Copilot reduz e simplifica cada etapa do ciclo de criação de IaC.

Na fase de redação, Copilot gera definições completas de recursos a partir de descrições de linguagem natural. Em vez de pesquisar a sintaxe Bicep para um recurso de Azure, você descreve o que precisa e Copilot produz um ponto de partida em segundos.

A fase de revisão, Copilot pode analisar um modelo existente e identificar lacunas de segurança, propriedades ausentes ou padrões desatualizados. Ele atua como um segundo conjunto de olhos antes de o template ser implantado.

Na fase de transformação, o Copilot pode converter entre CLI do Azure e PowerShell, entre Azure Resource Manager JSON e Bicep ou entre Azure Pipelines e GitHub Actions. Reduzindo o custo de trocar de ferramentas ou adaptar exemplos das documentações.

Na etapa de documentação, o Copilot pode ler um modelo concluído e gerar explicações compreensíveis, referências de parâmetros e descrições de arquitetura. Trabalho que geralmente é totalmente ignorado porque é entediante fazer manualmente.

A mudança não é apenas sobre velocidade. Trata-se de reduzir a barreira à entrada. Os engenheiros que não são especialistas em Bicep agora podem produzir templates corretos e bem estruturados descrevendo sua intenção em linguagem comum.

Capacidades do GitHub Copilot para trabalho com infraestrutura

GitHub Copilot se apresenta de várias formas no VS Code, cada uma adequada para diferentes partes do fluxo de trabalho de IaC.

Sugestões embutidas

Ao digitar um arquivo .bicep, .yaml, .ps1 ou .sh, o Copilot oferece sugestões em tempo real. Se você digitar o início de uma definição de recurso, Copilot preverá o restante. Incluindo propriedades necessárias, valores padrão e padrões comuns. Você aceita com Tab ou descarta com Escape.

As sugestões embutidas funcionam melhor para padrões contínuos, já estabelecidos no arquivo. Se você definir um recurso corretamente, Copilot pegará na estrutura e sugerirá recursos semelhantes no mesmo estilo.

Copilot Chat

Copilot chat (Ctrl+Alt+I) é uma interface de conversa em que você pode fazer perguntas, descrever o que deseja criar, colar o código existente para revisão ou solicitar explicações.

O chat é melhor do que sugestões embutidas para tarefas que exigem mais contexto. Exemplos como gerar um modelo inteiro do zero, refatorar um arquivo complexo ou solicitar uma explicação de como um recurso funciona.

Copilot com MCP (Protocolo de Contexto do Modelo)

O MCP permite que Copilot se conectem a ferramentas externas e fontes de dados. O servidor Bicep MCP oferece ao Copilot acesso às definições de tipos dinâmicas do Bicep, às versões de API atuais e às regras de validação. Tornando sua saída do Bicep mais precisa do que a que pode produzir apenas com dados de treinamento.

Por que a IaC é adequada para assistência de IA

As definições de infraestrutura têm qualidades que os tornam bons candidatos à geração assistida por IA:

  • Eles são altamente estruturados: as definições de recursos seguem esquemas. As propriedades são baseadas em tipos conhecidos, valores válidos e designações obrigatórias/opcionais. Essa natureza estruturada torna mais fácil para um modelo produzir uma saída sintaticamente correta.
  • Elas são ricas em padrões: a maioria das implantações no Azure usa um conjunto relativamente pequeno de tipos de recursos comuns: redes virtuais, contas de armazenamento, recursos de computação e identidade. Esses padrões aparecem com frequência em dados de treinamento, o que significa que Copilot depende de muitos exemplos.
  • Eles são caros para pesquisar manualmente: encontrar a combinação correta de versão da API, propriedades necessárias e SKUs válidas para um tipo de recurso desconhecido pode levar um tempo significativo. Copilot comprime a pesquisa em um prompt.
  • Eles são seguros para iteração: você valida antes de implementar. Uma sugestão incorreta do Copilot é detectada em az bicep build ou what-if antes de atingir qualquer recurso real. Essa rede de segurança incentiva a experimentação.

Principais conclusões

  • A IaC trata a infraestrutura como código: controlada por versão, repetível e revisável.
  • Ferramentas declarativas como Bicep descrevem o estado final desejado; ferramentas imperativas como a CLI descrevem as etapas para chegar lá.
  • O fluxo de trabalho tradicional de IaC enfrenta obstáculos significativos em cada etapa. Copilot reduz esse atrito.
  • GitHub Copilot ajuda com sugestões embutidas, Copilot Chat e contexto melhorado pelo recurso MCP.
  • O IaC é adequado para assistência de inteligência artificial porque é estruturado, rico em padrões e seguro para iterar.

Note

Reconhecemos que pessoas diferentes gostam de aprender de maneiras diferentes. Você pode optar por concluir este módulo em formato baseado em vídeo ou ler o conteúdo como texto e imagens. O texto contém mais detalhes do que os vídeos, portanto, em alguns casos, talvez você queira se referir a ele como material complementar à apresentação de vídeo.