Modularizar o gerenciamento de modelos do ARM (Azure Resource Manager) permite que você reduza a repetição, modele as melhores práticas no desenvolvimento de infraestrutura e tenha implantações padrão consistentes.
Um exemplo de caso de uso para implementar esse tipo de modularização é a implantação de VMs (máquinas virtuais) usando a metáfora de tamanhos de camiseta. 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. Fazer 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ê poderá 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 terão uma boa configuração conhecida para depender durante a atualização para a nova versão conforme tiverem tempo.
O bolo de camadas de repositórios: um exemplo para empresas
Quando se trata de por quê você pode querer ter uma preferência forte para onde seus modelos vão, como eles são atualizados e assim por diante, há duas considerações principais: ramificação e interioridade.
Ramificação. Este cenário de exemplo facilita modelos de ramificação git que dão suporte ao Gitflow e fluxo do GitHub. Para obter mais informações sobre o Gitflow, confira Como usar o git-flow para automatizar seu fluxo de trabalho de ramificação git, uma postagem no blog de Jeff Kreeftmeijer. Para obter mais informações sobre o fluxo do GitHub, confira Fluxo do GitHub na documentação do GitHub.
Innersourcing. O segundo é o innersourcing, que traz as práticas colaborativas do 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 de innersource, confira Uma introdução ao innersource no GitHub,
Bicep é uma linguagem declarativa usada para implantar recursos do Azure. O código reutilizável do Bicep pode usar o Registro de Contêiner do Azure como um registro privado para hospedar modelos do ARM com controle de versão. Usando o Registro de Contêiner dessa forma, sua empresa pode ter um processo de CI/CD (integração contínua/entrega contínua) para infraestrutura. Você pode executar testes de integração e unidade como parte do processo de CI, e o registro de contêiner poderão receber módulos depois que eles forem criados com êxito. As equipes de aplicativos poderão continuar a usar versões mais antigas até estarem prontas para atualizar ou poderão atualizar para aproveitar os recursos nas 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, preferencialmente, monitorar os repositórios públicos e efetuar pull de alterações em seu registro privado para uso adicional. Fazer pull de alterações em seu 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 é aquele que é empilhado. Camadas mais próximas da parte superior da pilha têm implantações mais frequentes e implantações que são mais personalizadas. O código Bicep fornece implantações consistentes. As equipes de desenvolvimento, trabalhando nas camadas para suas contribuições, se baseiam nos serviços e na infraestrutura que são fornecidos nas camadas abaixo. Nada em uma camada inferior deve depender de recursos em uma camada acima. Da camada 0 a 3 estão biblioteca global, infraestrutura global (serviços compartilhados globalmente), plataforma de produto (serviços compartilhados) e aplicativos.
Esse 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 GitHub Actions para CI/CD. No entanto, não superamos. Por exemplo, não determinamos que todas as equipes usem o Bicep. Elas podem usar o Terraform, modelos do ARM e outras ferramentas.
A capacidade de compartilhar melhores práticas. Pode assumir a forma de modelos do ARM, imagens douradas ou snippets de código. As melhores práticas também podem ser documentação de técnicas específicas. Por exemplo, como girar chaves em seu ambiente e como testar o código.
Alguns serviços se movem para baixo na pilha. Por exemplo, uma equipe de aplicativos pode desenvolver inicialmente um modelo para implantar um cluster do Kubernetes, que posteriormente é puxado para a plataforma do produto como um serviço compartilhado. Este modelo se torna tão útil que ele é puxado para a biblioteca de exemplos.
Camada 0 – Biblioteca global
A camada inferior é a biblioteca global, que é um repositório de tidbits úteis que não são implantados em 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 outros, seu CCoE (Cloud Center of Excellence) aprova PRs e gerencia uma lista de pendências como se fosse qualquer outro produto.
A camada 0 não deve conter:
- Modelos implantados em produção.
- Segredos ou configurações específicas do ambiente.
A camada 0 deve conter:
- Snippets de código (em Python, C#e assim por diante).
- Amostras do Azure Policy.
- Modelos do ARM, modelos Bicep ou arquivos Terraform que podem ser usados como exemplos.
Um exemplo disso é uma arquitetura de amostra 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 amostra 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, pois nem tudo pode ser ou precisa ser colocado em um módulo. Tentar fazer isso pode resultar em excesso de parametrização.
Além disso, a Camada 0 pode se vincular a outras boas fontes conhecidas de código de amostra, como o Registro do Terraform ou os Módulos de Recursos do Azure). Se a sua organização adotar código ou padrão de qualquer uma dessas fontes, recomendamos puxar o código ou padrão para sua Camada 0 em vez de extrair diretamente das fontes públicas. Dependendo da 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ê reduzirá o risco de depender de algo que possa ser excluído inesperadamente.
Para ser considerado um bom código de amostra, 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ê deverá adicionar políticas à ramificação principal para exigir PRs (solicitações de pull) e revisões de código para alterações propostas que resultariam em alterações que fluem para o registro de contêiner principal se mescladas.
A Camada 0 se alimenta do Azure Pipelines ou GitHub Actions para criar artefatos com versão automaticamente no Registro de Contêiner do Azure. Você pode criar automação para mensagens de confirmação git para implementar o controle de versão 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 um pré-requisito para revisões de código. Você pode instrumentar usando ferramentas como o 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!
Camada 1 – Infraestrutura global: serviços compartilhados globalmente
A Camada 1 é o repositório para suas as construções da zona de destino do Azure. Embora a Microsoft forneça modelos para a implantação de zonas de destino do Azure, você desejará modificar determinados componentes e fornecer um arquivo de parâmetros. Isso é análogo à maneira como você efetua pull de repositórios de módulo e registro público 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 sucesso no controle de versão de modelos Bicep. O Registro de Contêiner permite flexibilidade e reutilização significativas para seus módulos, fornecendo controle de segurança e acesso de nível empresarial.
A Camada 1 deve conter:
- Atribuições de política e definições que são aplicadas no nível do grupo de gerenciamento ou da assinatura. Essas políticas devem corresponder aos requisitos de governança corporativa.
- Modelos para infraestrutura de rede principal, como ExpressRoute, VPNs, WAN virtual e redes virtuais (compartilhado ou hub).
- DNS.
- Monitoramento principal (análise de logs).
- Registro de contêiner corporativo.
Você deve configurar a proteção de branch para restringir a capacidade de enviar alterações por push para esse repositório. Restringir a aprovação de PRs de outros desenvolvedores para membros do CCoE ou da Governança de Nuvem. Os colaboradores dessa camada são principalmente membros de grupos historicamente associados aos componentes nessa 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 solicitam, 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 teste.
Esses arquivos devem consumir os módulos no 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 destino do Azure ou uma estrutura de governança semelhante.
Camada 2 – Plataforma do produto: serviços compartilhados
Você pode considerar a Camada 2, plataforma do produto, como os serviços compartilhados para uma determinada linha de produto ou unidade de negócios. Esses componentes não são universais em toda a organização, mas servem para atender a uma necessidade comercial específica. Essa 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 um banco de dados compartilhado pelos diferentes aplicativos nessa plataforma.
A Camada 2 deve conter:
- Atribuições de política aplicadas em uma assinatura ou grupo de recursos para corresponder aos requisitos específicos do produto.
- Modelos do ARM para cofres de chaves, análise de log, um banco de dados SQL (se vários aplicativos dentro do produto usam o banco de dados) e Serviço de Kubernetes do Azure.
Você deve implementar permissões que restrinjam a capacidade de enviar alterações por push para esse repositório. Assim como as outras camadas, você deve usar a proteção de branch para garantir que um cliente potencial ou proprietário do produto possa aprovar PRs 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 ter 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, você precisará garantir que a criação de um processo de coleta de boas práticas e snippets desse repositório para compartilhar com a biblioteca global, Camada 0.
Camada 3 – Aplicativo
A Camada 3, a camada do aplicativo, inclui os componentes criados sobre a plataforma do produto. Esses componentes fornecem os recursos que a empresa solicita. Por exemplo, para uma plataforma de streaming, um aplicativo pode fornecer a função de pesquisa enquanto um aplicativo diferente 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, usados somente 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 esse repositório. Você deve usar a proteção de branch para permitir que um membro da equipe desse aplicativo aprove uma PR 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ê precisará também criar um processo de coleta de boas práticas e snippets dessa camada para compartilhar com a biblioteca global, Camada 0.
Commonalities 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 considerar.
Sua infraestrutura deve operar como se fosse um aplicativo. Isso significa que você deve ter um processo de CI (integração contínua) no qual os novos recursos são totalmente testados, com testes de unidade, testes de fumaça e testes de integração. Você deve mesclar apenas o código que passa esses testes no branch de lançamento principal.
Você também deverá ter políticas de branch em vigor para impedir que indivíduos contornem o processo, mesmo para conveniência. Se o processo de CI for visto como um impedimento, isso significa que você incorreu em uma dívida técnica que deverá ser tratada. Isso não significa que você precisa remover as políticas e proteções.
Por fim, embora você não tenha um índice de todos os repositórios e o código dentro deles, sua organização deve desenvolver um processo para que indivíduos solicitem acesso a repositórios. Determinadas regras podem 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 sob esse 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.
Colaboradores
Esse artigo é mantido pela Microsoft. Ele foi originalmente escrito pelos colaboradores a seguir.
Principais autores:
- Tim Sullivan | Arquiteto sênior de soluções de nuvem
Outros colaboradores:
- Gary Moore | Programador/escritor
Próximas etapas
- Área de design: automação de plataforma e DevOps
- Amadurecer as estruturas da equipe
- O que é a infraestrutura como código?
- Azure/ResourceModules: este repositório inclui uma plataforma de CI e uma coleção de módulos Bicep maduros e coletados. A plataforma dá suporte ao Azure Resource Manager e ao Bicep, e você pode usar seus recursos com as ações do GitHub e o Azure Pipelines.
- Criar um registro privado para o módulo Bicep