Modularizar o gerenciamento de seus modelos do Azure Resource Manager (modelos ARM) permite reduzir a repetição, modelar práticas recomendadas no desenvolvimento de infraestrutura e ter implantações padrão consistentes.
Um exemplo de caso de uso para implementar esse tipo de modularização é a implantação de máquinas virtuais (VMs) usando a metáfora dos tamanhos de camisetas. Suponha que você tenha implantado dezenas ou centenas de VMs. Essas implantações usam a versão 1.0.0 de seus modelos e têm um tamanho médio padrão de uma série mais antiga. A transição para uma nova série pode exigir uma breve interrupção do serviço se você simplesmente implantou novos modelos. No entanto, criando a versão 1.5.0 e usando a modularização, você pode implantar uma nova infraestrutura com o padrão atualizado, mantendo a infraestrutura antiga em um estado implantável. Ao ter versões antigas da infraestrutura disponíveis, suas equipes de produtos e aplicativos têm uma boa configuração em que confiar durante a atualização para a nova versão à medida que têm tempo.
O bolo de camadas dos repositórios: um exemplo para as empresas
Quando se trata de por que você pode querer ter uma forte preferência por onde seus modelos vão, como eles são atualizados e assim por diante, há duas considerações principais: ramificação e internalsourcing.
Ramificação. Este cenário de exemplo facilita modelos de ramificação git que suportam o fluxo Gitflow e GitHub. Para obter mais informações sobre o Gitflow, consulte Usando o git-flow para automatizar seu fluxo de trabalho de ramificação do git, uma postagem de blog de Jeff Kreeftmeijer. Para obter mais informações sobre o fluxo do GitHub, consulte Fluxo do GitHub na documentação do GitHub.
Innersourcing. O segundo é o innersourcing, que traz as práticas colaborativas de desenvolvimento de software de código aberto para o desenvolvimento interno. Nesse cenário, você pode compartilhar com mais confiança diferentes modelos e código-fonte do módulo sem necessariamente precisar se preocupar com permissões para os próprios modelos de implantação. Para obter mais informações sobre o desenvolvimento innersource, consulte Uma introdução ao innersource no GitHub,
O Bicep é uma linguagem declarativa para implantar recursos do Azure. O código reutilizável do Bíceps pode usar o Registro de Contêiner do Azure como um registro privado para hospedar modelos ARM versionados. Ao usar o Registro de Contêiner dessa forma, sua empresa pode ter um processo de integração contínua e entrega contínua (CI/CD) para infraestrutura. Você pode executar testes de integração e de unidade como parte do processo de CI, e o registro de contêiner pode receber módulos depois que eles forem criados com êxito. As equipas de aplicações podem continuar a utilizar versões mais antigas até estarem prontas para atualizar ou podem atualizar para tirar partido das funcionalidades das versões mais recentes dos modelos.
Além desse uso do Registro de Contêiner, você pode combinar esse modelo com algo como os Módulos Verificados do Azure. Sua implementação pode consumir do registro público ou, de preferência, monitorar os repositórios públicos e extrair alterações para seu registro privado para uso posterior. Puxar alterações para seu próprio registro de contêiner permite que você execute testes em módulos públicos, garantindo que eles não sejam usados na produção até que as práticas de qualidade e segurança sejam incorporadas.
Camadas
O modelo proposto neste cenário de exemplo é um modelo que empilha. As camadas mais próximas do topo da pilha têm implantações mais frequentes e implantações mais personalizadas. O código Bicep fornece implantações consistentes. As equipes de desenvolvimento, trabalhando nas camadas para suas contribuições, constroem a partir dos serviços e infraestrutura que são fornecidos nas camadas abaixo. Nada em uma camada inferior deve depender de recursos em uma camada acima. Da camada 0 à 3 estão a biblioteca global, a infraestrutura global (serviços compartilhados globalmente), a plataforma de produtos (serviços compartilhados) e os aplicativos.
Este modelo cria autonomia com alinhamento, o que significa ter:
Ferramentas comuns para facilitar a empresa. Por exemplo, todos usam o git para controle do código-fonte e todos usam as Ações do GitHub para CI/CD. No entanto, não exageramos. Por exemplo, não exigimos que todas as equipes usem o Bicep; eles podem usar Terraform, modelos ARM e outras ferramentas.
A capacidade de partilhar as melhores práticas. Eles podem assumir a forma de modelos ARM, imagens douradas ou trechos de código. As melhores práticas também podem ser a documentação de técnicas específicas. Por exemplo, como girar chaves em seu ambiente e como testar código.
Alguns serviços se movem para baixo na pilha. Por exemplo, uma equipe de aplicativo pode inicialmente desenvolver um modelo para implantar um cluster do Kubernetes, que depois é puxado para a plataforma do produto como um serviço compartilhado. Este modelo torna-se tão útil que é puxado para a biblioteca de amostras.
Camada 0 - Biblioteca global
A camada inferior é a biblioteca global, que é um repositório de tidbits úteis que não são implantados na produção. Do ponto de vista do controle de acesso, o acesso de leitura deve ser fornecido a qualquer pessoa na empresa que o solicite. Para alterações, sugestões e assim por diante, seu Centro de Excelência em Nuvem (CCoE) aprova RPs e gerencia uma lista de pendências como se fosse qualquer outro produto.
A camada 0 não deve conter:
- Modelos que são implantados na produção.
- Segredos ou configurações específicas do ambiente.
A camada 0 deve conter:
- Trechos de código (em Python, C# e assim por diante).
- Exemplos de Política do Azure.
- Modelos ARM, modelos Bicep ou arquivos Terraform que podem ser usados como amostras.
Um exemplo disso é uma arquitetura de exemplo de como sua empresa escreveria uma implantação para um aplicativo de três camadas sem nenhuma informação específica do ambiente. Essa arquitetura de exemplo pode incluir tags, redes, grupos de segurança de rede e assim por diante. Deixar de fora informações específicas para o ambiente é útil, porque nem tudo pode ser ou precisa ser colocado em um módulo. Tentar fazer isso pode resultar em parametrização excessiva.
Além disso, a Camada 0 pode ser vinculada a outras fontes válidas conhecidas de código de exemplo, como o Registro Terraform ou os Módulos de Recursos do Azure). Se sua organização adotar código ou um padrão de qualquer uma dessas fontes, recomendamos puxar o código ou padrão para sua própria Camada 0 em vez de extrair diretamente das fontes públicas. Confiando na Camada 0, você pode escrever seus próprios testes, ajustes e configurações de segurança. Ao não depender de fontes públicas, você reduz o risco de confiar em algo que pode ser excluído inesperadamente.
Para serem considerados bons exemplos de código, seus modelos e módulos devem seguir boas práticas de desenvolvimento, incluindo validação de entrada para segurança e para requisitos organizacionais. Para manter esse nível de rigor, você deve adicionar políticas à ramificação principal para exigir solicitações pull (PRs) e revisões de código para alterações propostas que resultariam em alterações fluindo para o registro de contêiner principal se mescladas.
A Camada 0 alimenta os Pipelines do Azure ou as Ações do GitHub para criar automaticamente artefatos versionados no Registro de Contêiner do Azure. Você pode criar automação para mensagens de confirmação do git para implementar o versionamento semântico dos artefatos. Para que isso funcione corretamente, você precisa ter um padrão de nomenclatura determinístico, como <service.bicep>, para tornar a automação sustentável ao longo do tempo. Com políticas de ramificação adequadas, você também pode adicionar testes de integração como pré-requisito para revisões de código. Você pode instrumentar isso usando ferramentas como Pester.
Com essas políticas e proteções em vigor, o registro de contêiner pode ser a fonte da verdade para todos os módulos de infraestrutura na empresa que estão prontos para uso. Você deve considerar a padronização de logs de alterações, bem como índices de exemplos de código disponíveis, para permitir a descoberta desse código. Código desconhecido é código não utilizado!
Nível 1 - Infraestrutura global: serviços globalmente compartilhados
A camada 1 é o repositório para suas construções de zona de aterrissagem do Azure. Embora a Microsoft forneça modelos para a implantação de zonas de aterrissagem do Azure, você desejará modificar determinados componentes e fornecer um arquivo de parâmetros. Isso é análogo à maneira como você puxa o registro público e os repositórios de módulo para a Camada 0, conforme descrito anteriormente.
O Registro de Contêiner do Azure é uma parte crítica dessa arquitetura. Mesmo que sua empresa não tenha planos de usar contêineres, você deve implantar o Registro de Contêiner para ter êxito no controle de versão de modelos do Bicep. O Registro de Contêiner permite flexibilidade e reutilização significativas para seus módulos, ao mesmo tempo em que fornece segurança e controle de acesso de nível empresarial.
A camada 1 deve conter:
- Atribuições e definições de política que são aplicadas no nível de grupo de gerenciamento ou assinatura. Essas políticas devem corresponder aos seus requisitos de governança corporativa.
- Modelos para infraestrutura de rede principal, como Rota Expressa, VPNs, WAN virtual e redes virtuais (compartilhadas ou hub).
- DNS.
- Monitoramento central (log analytics).
- Registro de contêiner corporativo.
Você deve configurar a proteção de ramificação para restringir a capacidade de enviar alterações por push para esse repositório. Restrinja a aprovação de RPs de outros desenvolvedores a membros do CCoE ou Cloud Governance. Os contribuidores para esta camada são principalmente membros de grupos que são historicamente associados com os componentes nesta camada. Por exemplo, a equipe de rede cria os modelos para a rede, a equipe de operações configura o monitoramento e assim por diante. No entanto, você deve conceder acesso somente leitura a indivíduos que o solicitarem, pois deseja permitir que desenvolvedores de outros grupos sugiram alterações nas infraestruturas principais. Eles podem contribuir com melhorias, embora você não permita que suas alterações sejam mescladas sem aprovação e testes.
Esses arquivos devem consumir os módulos em seu registro de contêiner para componentes padrão. No entanto, você também terá um arquivo Bicep, ou uma série de arquivos Bicep, que são personalizados para a implementação da sua empresa de zonas de aterrissagem do Azure ou uma estrutura de governança semelhante.
Camada 2 - Plataforma do produto: Serviços partilhados
Você pode considerar a Camada 2, plataforma de produtos, como os serviços compartilhados para uma determinada linha de produtos ou unidade de negócios. Esses componentes não são universais em toda a organização, mas destinam-se a atender a uma necessidade comercial específica. Esta seria uma camada apropriada para uma rede virtual que é um par com o hub na Camada 1, infraestrutura global. Um cofre de chaves é outro componente de exemplo para essa camada. O cofre de chaves pode armazenar segredos compartilhados em uma conta de armazenamento ou em um banco de dados compartilhado pelos diferentes aplicativos dentro dessa plataforma.
A camada 2 deve conter:
- Atribuições de política que são aplicadas em uma assinatura ou grupo de recursos para corresponder aos requisitos específicos do produto.
- Modelos ARM para cofres de chaves, análise de log, um banco de dados SQL (se vários aplicativos dentro do produto usarem o banco de dados) e Serviço Kubernetes do Azure.
Você deve implementar permissões que restrinjam a capacidade de enviar alterações por push para este repositório. Como as outras camadas, você deve usar a proteção de ramificação para garantir que um líder ou proprietário de produto possa aprovar RPs de outros desenvolvedores. Não há regras fixas sobre o acesso de leitura à plataforma do produto, mas, no mínimo, os desenvolvedores de qualquer uma das equipes de aplicativos devem receber acesso de leitura para poder sugerir alterações. Como a Camada 2 pode conter alguma arquitetura proprietária ou informações semelhantes, você pode optar por restringir o acesso àqueles na organização que usam a plataforma. No entanto, se esse for o caso, convém garantir que você crie um processo de coleta de boas práticas e trechos desse repositório para compartilhar com a biblioteca global, a Camada 0.
Camada 3 - Aplicação
A camada 3, a camada de aplicação, inclui os componentes que são construídos sobre a plataforma do produto. Esses componentes fornecem os recursos solicitados pela empresa. Por exemplo, para uma plataforma de streaming, um aplicativo pode fornecer a função de pesquisa, enquanto outro aplicativo fornece recomendações.
A camada 3 deve conter:
- Código do aplicativo em C#, Python e assim por diante.
- Infraestrutura para componentes individuais (ou seja, usada apenas neste aplicativo): funções, Instâncias de Contêiner do Azure, Hubs de Eventos.
As permissões são restritas para a capacidade de enviar alterações por push para este repositório. Você deve usar a proteção de ramificação para permitir que um membro da equipe deste aplicativo aprove uma RP feita por outro membro da equipe. Os membros da equipe não devem ter permissão para aprovar suas próprias alterações. Como essa camada pode conter arquitetura proprietária, lógica de negócios ou informações semelhantes, você pode optar por restringir o acesso àqueles na organização que criam esse aplicativo. No entanto, se esse for o caso, você também deve criar um processo de coleta de boas práticas e trechos dessa camada para compartilhar com a biblioteca global, a Camada 0.
Semelhanças entre camadas
Embora este artigo descreva alguns detalhes específicos para cada camada, também há algumas qualidades para todas as camadas que você deve ter certeza de considerar.
Sua infraestrutura deve operar como se fosse um aplicativo. Isso significa que você deve ter um processo de integração contínua (CI) no qual novos recursos são testados totalmente, com testes de unidade, testes de fumaça e testes de integração. Você deve mesclar apenas o código que passa esses testes na ramificação da versão principal.
Você também deve garantir que tenha políticas de filial em vigor para evitar que indivíduos contornem o processo, mesmo por conveniência. Se o seu processo de IC é visto como um impedimento, isso significa que você incorreu em dívida técnica que deve ser tratada. Isso não significa que você precisa remover as políticas e proteções.
Finalmente, embora você possa não ter um índice de todos os repositórios e o código dentro deles, sua organização deve desenvolver um processo para que os indivíduos solicitem acesso aos repositórios. Certas regras poderiam ser totalmente automatizadas. Por exemplo, você pode implementar uma regra que conceda acesso de leitura, sem revisão, a um colaborador que esteja na equipe do produto para qualquer aplicativo desse produto. Essas regras geralmente podem ser implementadas com associação baseada em grupo e atribuições de função baseadas em grupo em seus ambientes. Configurar esse tipo de acesso deve ajudar a facilitar o fornecimento interno e o conhecimento organizacional.
Contribuidores
Este artigo é mantido pela Microsoft. Foi originalmente escrito pelos seguintes contribuidores.
Principais autores:
- Tim Sullivan - Brasil | Especialista Técnico Sénior
Outros contribuidores:
- Gary Moore - Brasil | Programador/Redator
Próximos passos
- Área de design: Automação de plataformas e DevOps
- Estruturas de equipa maduras
- O que é Infraestrutura como Código?
- Azure/ResourceModules: Este repositório inclui uma plataforma de CI para e uma coleção de módulos Bicep maduros e com curadoria. A plataforma dá suporte ao Azure Resource Manager e ao Bicep, e você pode usar seus recursos com ações do GitHub e Azure Pipelines.
- Criar registro privado para o módulo Bicep