Melhores práticas para criar arquiteturas implementáveis

Uma arquitetura implementável é uma unidade modular independente de automação de nuvem que combina um ou mais recursos de nuvem para fornecer um padrão de arquitetura comum. Ele permite implementação, escalabilidade e modularidade simplificadas, permitindo que os usuários provisionem e gerenciem recursos de infraestrutura facilmente.

Este guia descreve as melhores práticas para construir arquiteturas implementáveis bem-projetadas e sustentáveis que são gravadas no Terraform. O foco em atributos-chave como escopo, capacidade de composição, consumabilidade e verificações de qualidade ajudam a garantir soluções robustas e confiáveis. A seção final deste guia fornece referências a ferramentas e modelos que ajudam a implementar essas práticas

Essas melhores práticas se aplicam à criação de arquiteturas implementáveis com o Terraform Para obter mais informações, consulte Criando uma arquitetura implementável

Assista e aprenda

Prefere vê-lo em ação? Assista ao vídeo a seguir para saber mais sobre arquiteturas implantáveis.

Transcrição de vídeo

Uma arquitetura implantável é um padrão de arquitetura com automação para a implantação de infraestrutura e software na nuvem. Ele permite que as organizações promovam a consistência na forma como a infraestrutura e o software são implementados e configurados. Ele impõe uma arquitetura e segurança opinativas que reduzem o suporte geral e aumentam a confiabilidade a longo prazo.

Esse padrão ganha vida com a automação que instancia a arquitetura implementável. A automação do IBM Cloud é conduzida com o Terraform para automação de infraestrutura como serviço e com o Ansible para configuração de software.

Compreender os custos é fundamental - você pode estimar o custo antes da implementação e acompanhar as alterações nos gastos à medida que atualiza ou personaliza a arquitetura. E lembre-se: você nunca é cobrado por nada até a implantação.

As políticas organizacionais e de segurança são essenciais para as implementações corporativas. É por isso que as arquiteturas implementáveis são examinadas e pré-analisadas para aderir a um conjunto de requisitos de política, o que pode ajudar sua organização a permanecer segura. As implementações padronizadas também simplificam a coleta de evidências para auditorias.

As arquiteturas implementáveis fornecem informações sobre como obter suporte, bem como a permissão necessária para implementar a arquitetura.

Por fim, você pode compartilhar arquiteturas implementáveis de um catálogo privado com outras contas da sua organização. Além disso, o catálogo pode restringir os usuários a versões específicas de uma arquitetura implementável. Isso garante consistência e padronização para todos.

Os padrões de arquitetura são criados por especialistas em domínios específicos. As arquiteturas entre domínios são construídas por meio da vinculação de arquiteturas para criar uma arquitetura implementável mais complexa.

IBM Cloud Você pode criar suas próprias arquiteturas implementáveis ou economizar tempo personalizando as arquiteturas prontas do catálogo IBM Cloud ou do registro da comunidade.

uma arquitetura implantável é definida por um manifesto como código, que descreve a arquitetura, o local do código, as permissões e os custos, o suporte, a descrição, o ícone e outros detalhes. Ele é definido com JSON e está localizado na raiz do repositório.

É possível inserir ou modificar uma arquitetura implementável no console e exportar o manifesto. Você pode criar uma arquitetura implantável pela primeira vez a partir de um snapshot de versão do git. Use a url.tgz da versão como sua fonte.

Em seguida, edite os detalhes da entrada do catálogo para sua arquitetura implementável, como o ícone e o nome. Você pode adicionar dependências e arquiteturas opcionais que funcionem bem com a sua, mas que não sejam necessárias.

Você também pode gerenciar reivindicações de conformidade para a arquitetura implementável. Essas afirmações são verificadas quando você valida a arquitetura implementável no catálogo antes de publicá-la.

Por fim, depois de integrar uma versão de sua arquitetura implantável, você pode exportar o arquivo de manifesto do catálogo e salvá-lo em seu repositório de origem. Usar o console é normalmente a melhor abordagem para integrar uma arquitetura implantável net-new, pois é possível exportar facilmente o manifesto do catálogo e editá-lo posteriormente, se necessário. Dessa forma, você não precisa criar o arquivo de manifesto do catálogo do zero.

No catálogo IBM Cloud, abra a guia Deployable architectures (Arquiteturas implementáveis ) para encontrar arquiteturas compatíveis com o IBM.

As arquiteturas implementáveis em nosso registro da Comunidade podem mudar com frequência ou ser descontinuadas em curto prazo, mas ainda são um bom ponto de partida para você usar e personalizar.

Considere a arquitetura implementável VPC landing zone, que está disponível no catálogo IBM Cloud. É uma arquitetura implementável geralmente útil, pois você precisa de uma VPC se pretende executar uma carga de trabalho na nuvem.

VPC landing zone foi projetado para estar em conformidade com o perfil IBM Cloud Framework for Financial Services. Ele separa as cargas de trabalho de gerenciamento das cargas de trabalho do trabalhador, usa o gerenciamento de chaves para criptografar o armazenamento de objetos na nuvem e usa pontos de extremidade privados para comunicações. Você pode usá-lo como está ou personalizá-lo para atender às suas necessidades de zona de aterrissagem.

Para uma arquitetura implementável mais complexa, considere a base de nuvem para segurança e observabilidade. Essa arquitetura implementável foi criada vinculando várias arquiteturas do catálogo IBM Cloud. Com ele, você pode aproveitar toda a gama de serviços de segurança do site IBM Cloud. Ele é personalizável, portanto, você pode optar por incluir apenas os serviços de que precisa e deixar de fora os que não precisa.

Agora que você sabe onde encontrar arquiteturas implementáveis, como implementá-las e mantê-las em todas as contas? Você usa um projeto IBM Cloud.

No projeto, você configura as variáveis de entrada para a arquitetura implementável. Você pode monitorar o custo, o desvio de seus recursos, as verificações de conformidade e atualizar para a versão mais recente de uma arquitetura implementável quando ela estiver disponível no catálogo. Em geral, um projeto está localizado em uma conta de hub e implementa recursos em várias contas de spoke, também conhecidas como contas de destino.

Consulte nossos documentos para saber mais sobre como executar cargas de trabalho seguras em IBM Cloud. Ou mergulhe no catálogo IBM Cloud para descobrir quais arquiteturas implantáveis podem funcionar para sua empresa.

Princípios de design

Escopo, capacidade de composição e consumabilidade são os três princípios de design principais que você precisa considerar quando estiver criando uma arquitetura implementável

Na fase de planejamento e de pesquisa, é necessário avaliar o ecossistema atual de ofertas e avaliar o caso de uso de negócios e os requisitos de. Use o Well-Architected Framework e o Architecture Design Framework para planejar e projetar os componentes necessários para a arquitetura.

Scope

Um escopo bem definido para a arquitetura implementável é crucial, pois deve ser abrangente o suficiente para incluir todos os recursos necessários, mas focado o suficiente para evitar complexidade desnecessária.

Uma prática recomendada é incluir recursos de infraestrutura que normalmente são implantados juntos como uma unidade, exigem acesso e permissões semelhantes e têm o mesmo ciclo de vida. Por exemplo, vamos considerar a VPC landing zone arquitetura implementável. Essa arquitetura implementável tem um escopo bem definido que inclui os seguintes recursos de infraestrutura:

Recursos na zona de aterrissagem VPC DA
Recurso Descrição
VPCs Cria uma topologia VPC segura
Otimização da infraestrutura Inclui sub-redes, gateways públicos, ACLs, gateways de trânsito e grupos de segurança
Rede de borda Isola o tráfego para a Internet pública.
Monitorando e criando logs Integra logs de fluxo para observabilidade e auditoria do tráfego de VPC

Esses recursos são normalmente implantados juntos como uma unidade, exigem permissões administrativas de rede semelhantes e têm o mesmo ciclo de vida, o que significa que eles:

  • São criados juntos, como quando uma nova VPC é provisionada com suas sub-redes associadas, gateways públicos e grupos de segurança.
  • São atualizados juntos, como quando uma mudança é feita na configuração de rede da VPC, que requer atualizações para as sub-redes, gateways públicos e grupos de segurança.
  • São excluídos juntos, como quando uma VPC é desatribuída e todos os seus recursos associados, incluindo sub-redes, gateways públicos e grupos de segurança, são removidos.

Capacidade de composição

Um princípio fundamental de uma arquitetura implementável é a capacidade de composição, que permite a criação de uma arquitetura implementável mais ampla ao empilhar várias arquiteturas implementáveis. Essa abordagem modular permite a máxima flexibilidade e a reutilização de recursos de automação.

Para obter capacidade de composição, uma arquitetura implementável deve ser projetada para:

  • Maximize a quantidade de informações exibidas através dos valores de saída, mas mantenha os tipos de saída simples. Essa prática permite que a automação de arquitetura implementável seja reutilizada em uma ampla variedade de cenários e o torna um bloco de construção versátil para várias soluções automatizadas..

  • Permitir referências opcionais a recursos implementados existentes, como instâncias de grupo de recursos, IBM® Key Protect for IBM Cloud® ou Hyper Protect Crypto Services e instâncias de IBM Cloud Secrets Manager, entre outras. Os usuários podem então configurar instâncias existentes ou implementar em grupos de recursos existentes, aumentando a versatilidade de sua automação. O Arquitetura implementável do Secrets Manager é um grande exemplo deste princípio em ação Ao permitir que os usuários reutilizem instâncias existentes do Secrets Manager, grupos de recursos e chave de criptografia do KMS, essa automação fornece um alto grau de flexibilidade e adaptabilidade. Por exemplo, é possível:

    • Configure uma instância existente do Secrets Manager passando seu ID e crie grupos de segredos na instância existente.
    • Integre com um sistema de gerenciamento de chaves existente como Key Protect ou Hyper Protect Crypto Services.
    • Implementar em um grupo de recursos existente ou criar um novo com convenções de nomenclatura customizáveis.

Como alternativa, essa arquitetura implementável também permite criar uma nova instância do Secrets Manager, um novo grupo de recursos e outros recursos do zero, fornecendo uma solução independente.

Ao adotar a capacidade de composição, uma arquitetura implementável pode ser facilmente integrada a uma arquitetura de solução mais complexa, empilhando-a com outras arquiteturas implementáveis. Por exemplo, o Retrieval Augmented Generation Pattern demonstra como várias arquiteturas implementáveis, incluindo a arquitetura implementável Secrets Manager, podem ser combinadas para criar uma solução complexa. As arquiteturas implementáveis projetadas com a capacidade de composição em mente fornecem a base para essas soluções complexas.

Quando as arquiteturas implantáveis são empilhadas juntas, cada arquitetura implantável membro mantém seu estado de configuração independente, permitindo a implantação, atualização ou cancelamento de implantação individual. Essa abordagem modular permite que as garantias de custo, conformidade, suporte e qualidade sejam derivadas das arquiteturas implementáveis incluídas, enquanto a solução geral permanece com uma versão exclusiva, com suas próprias descrições e arquitetura de referência. Para obter mais informações, acesse O que significa empilhar arquiteturas implementáveis?

Consumabilidade

Uma arquitetura implementável deve ser projetada com consumabilidade em mente, tornando fácil para os usuários entenderem e implementarem. Para isso, a arquitetura implementável deve fornecer uma documentação abrangente que inclua o seguinte:

Pré-requisitos
Dependências de software e requisitos de infraestrutura necessários para implementação.
Variáveis de entrada detalhadas e descrições de valores de saída
Incluindo propósito, tipo de dados e valores padrão.
Permissões mínimas necessárias
Permissões necessárias para executar a automação de arquitetura implementável..
Diagramas e mapas de arquitetura
Representações visuais dos componentes e relacionamentos da arquitetura implementável..
Configuração simplificada
Fácil de implementar e gerenciar.
Requisitos de recurso reduzidos
Otimize a arquitetura implementável para minimizar os requisitos de hardware e de recursos, como menores requisitos de CPU e memória, tornando-a mais acessível e eficiente.
Implementação simplificada
Mais rápido e fácil de começar.

Outra faceta de garantir que a arquitetura implementável seja facilmente consumível é fornecer várias variações, incluindo uma variação de início rápido. Uma versão de iniciação rápida da arquitetura implementável deve ser fornecida, que é mais barata e mais rápida de executar. Por exemplo, a variação do QuickStart da arquitetura implementável do Red Hat OpenShift Container Platform on VPC landing zone cria um ambiente de nuvem privada virtual (VPC) totalmente customizável em uma única região, fornecendo um único cluster do Red Hat OpenShift em um VPC seguro para cargas de trabalho. Essa variação de iniciação rápida é projetada para propósitos de demonstração e desenvolvimento e custa menos de $400 por mês para ser executada

Em contraste, a versão padrão da arquitetura implementável do Red Hat OpenShift Container Platform em VPC landing zone, baseada na arquitetura de referência do IBM Cloud Framework for Financial Services, cria clusters de carga de trabalho do Red Hat OpenShift Container Platform seguros e em conformidade em uma rede Virtual Private Cloud (VPC), mas custa mais de US$ 4.000 por mês para execução. Além disso, ele inclui recursos avançados, como serviço de VPC de gerenciamento, serviço de VPC de carga de trabalho, isolamento de VPC de gerenciamento e VPC de carga e decisões avançadas de arquitetura de segurança de rede.

Variáveis de entrada

Torne mais fácil para os usuários configurar as variáveis de entrada da arquitetura implementável usando as melhores práticas a seguir:

Expor apenas argumentos comumente modificados
Exponha apenas as variáveis que a maioria dos usuários precisará alterar, evitando arquiteturas implantáveis com um grande número de variáveis de entrada que sobrecarregariam os usuários. Para usuários avançados, considere fornecer um único campo de entrada JSON para customização adicional. Como um exemplo, a arquitetura implementável da zona de entrada do VPC apresenta um único campo denominado override_json_string que fornece controle total para usuários avançados na topologia implementada. Para obter mais informações, consulte o guia de implementação da zona de entrada do VPC
Usar nomenclatura clara e descritiva para recursos existentes
Ao referir-se a recursos existentes, use nomes que indiquem claramente a que eles se referem, como existing_cluster_name em vez de cluster_name, para evitar ambiguidade
Preferir nomes a IDs.
Ao se referir a recursos existentes, use nomes em vez de IDs para melhor consumabilidade do usuário.
Evitar acrónimos
Em vez de usar acrônimos, use nomes completos de produtos para facilitar que as pessoas não familiarizadas com os produtos ou serviços entendam a que se referem. Por exemplo, secrets_manager em vez de sm ou key_management em vez de kms.
Usar recursos avançados de digitação
Para ativar o serviço de Projetos IBM Cloud para renderizar widgets de entrada apropriados para variáveis, o que facilita a configuração de valores para os usuários. Por exemplo:
  • Região VPC: uma lista suspensa de todas as regiões VPC disponíveis no IBM Cloud.
  • Chave SSH do VPC: um campo de entrada seguro para gerenciamento de chave SSH.
  • Cluster: uma lista suspensa de clusters disponíveis no IBM Cloud

Para obter mais informações, consulte Editando localmente os valores de manifesto do catálogo.

Seguindo essas diretrizes, a arquitetura implementável pode se tornar mais consumível, permitindo que os usuários entendam e implementem rapidamente.

Qualidade

Para garantir que a arquitetura implementável seja confiável e consistente, é essencial implementar e automatizar verificações de qualidade. Essas verificações devem cobrir vários aspectos da arquitetura implementável, incluindo qualidade de código, validação de configuração, teste e integração contínua.

qualidade do código

Utilize linting e formatação de código. Aplique estilos de codificação e formatação consistentes para tornar o código fácil de ler e manter. Detecte erros e avisos no código para evitar problemas durante a implementação Considere ir além do código do Terraform, mas incorpore quaisquer ferramentas relevantes para todos os recursos em sua arquitetura implantável, como scripts Bash, scripts Python, arquivos YAML e JSON e Golang.

Exemplos:

  • terraform_fmt para formatar o código do Terraform
  • go-fmt para formatar o código Go.
  • black para formatar código Python.
  • isort para classificar importações Python.
  • flake8 para verificar o código Python para erros e avisos.
  • shellcheck para verificar shell scripts para erros e avisos.
  • golangci-lint para verificar o código Go para erros e avisos.

Validação de configuração

Use a validação estática para verificar a sintaxe e configuração da arquitetura implementável para assegurar que ela esteja correta e consistente. Valide a configuração da arquitetura implementável para evitar erros durante a implementação.. Novamente, considere ir além do código do Terraform e incorpore quaisquer ferramentas relevantes para todos os recursos em sua arquitetura implantável, como scripts Bash, scripts Python, arquivos YAML e JSON e Golang.

Exemplos:

  • terraform_validate para validar a configuração do Terraform..
  • checkov para verificar problemas de segurança e conformidade no código do Terraform.
  • tflint para verificar erros e avisos.
  • detect-secrets para detectar segredos no código..
  • hadolint para verificar Docker arquivos para erros e avisos.
  • helmlint para verificar Helm gráficos para erros e avisos.

Teste

Quando se trata de testar o código de infraestrutura, não há nenhum teste de unidade pura na maneira que você pode pensar nele para o código do aplicativo Em vez disso, a estratégia de teste envolve implementar a infraestrutura em um ambiente real, validando que ela funciona e, em seguida, removendo a implementação.

Conjunto de testes de validação automatizado

A recomendação é ter um suíte de testes automatizado básico que cubra os fundamentos a seguir:

Testes de implementação.
Verifique se o código de infraestrutura pode ser implementado com sucesso em um ambiente real Crie todos os recursos necessários, como máquinas virtuais, bancos de dados e redes. Esses testes ajudam a assegurar que o código de infraestrutura esteja correto e que possa ser aplicado com sucesso a um ambiente real Recomenda-se variar os parâmetros de entrada da arquitetura implementável nesses testes para assegurar uma ampla cobertura alinhada com o uso comum
Ensaios de destruição
Verifique se o código de infraestrutura pode ser removido ou destruído com sucesso, removendo todos os recursos criados. Esses testes asseguram que o código de infraestrutura possa ser removido com segurança de um ambiente real, sem deixar recursos órfãos ou causar consequências indesejadas.
Testes de idempotência
Verifique se o código de infraestrutura pode ser reaplicado várias vezes sem causar mudanças ou erros indesejados. Em outras palavras, o código deve produzir o mesmo resultado independentemente de quantas vezes é aplicado. Esses testes são críticos em ambientes como o IBM Cloud, em que a plataforma verifica periodicamente mudanças para detectar desvio entre a infraestrutura implementada e a origem da verdade, que é o código de automação. Os testes de idempotência ajudam a assegurar que o código de infraestrutura possa manipular implementações ou atualizações repetidas sem causar problemas Esses testes também ajudam a assegurar que os recursos de detecção de desvio possam identificar e corrigir com precisão quaisquer discrepâncias entre o estado desejado e o estado real da infraestrutura.. Para obter mais informações, consulte Gerenciando o desvio
Testes de upgrade da versão
Verifique se o código de infraestrutura pode ser atualizado com sucesso de uma versão para outra, sem causar erros ou mudanças indesejadas Esses testes asseguram que o código de infraestrutura possa ser atualizado com segurança sem interromper ou destruir recursos existentes ou causar consequências indesejadas.

Casos de teste avançados

Os casos de teste avançados incluem cenários como:

Implementando a arquitetura implementável várias vezes na mesma conta
Verifique se o código de infraestrutura pode manipular diversas implementações na mesma conta, sem causar conflitos de nome de recurso ou outros problemas
Implementando a arquitetura implementável com um perfil confiável
Verifique se o código de infraestrutura pode ser implementado com um perfil confiável Cloud Identity and Access Management. Para obter mais informações, consulte Definindo um método de autenticação

Ao incluir esses testes em seu suíte de testes automatizado, é possível assegurar que seu código de infraestrutura seja confiável, robusto e seguro para implementar na produção

Integração contínua

Para assegurar a confiabilidade, a consistência e a sustentabilidade da arquitetura implementável, recomenda-se uma abordagem shift-left, em que as verificações de qualidade e os testes são integrados no início do ciclo de desenvolvimento. Essa abordagem ajuda a capturar erros e defeitos antecipadamente, reduzindo a probabilidade de problemas de recebimento de dados e melhorando a qualidade geral.

Como parte dessa abordagem, são recomendadas as seguintes verificações de qualidade:

Controle de qualidade do lado do cliente
Os ganchos de confirmação do Git do lado do cliente devem ser usados para executar verificações na máquina do desenvolvedor antes de confirmar o código Isso inclui a verificação de padrões de codificação, erros de sintaxe e dados confidenciais Ferramentas como Pré-Confirmação podem ser utilizadas para automatizar esse processo
Práticas de IC.
As melhores práticas para a integração contínua (CI) devem ser seguidas. As práticas gerais para qualquer produto de engenharia de software se aplicam ao desenvolvimento de arquitetura implementável, incluindo:
  • Trabalhar com solicitações pull (PRs) pequenas e focadas para facilitar revisões oportunas e reduzir conflitos de mesclagem.
  • Integrar mudanças de código na ramificação principal regularmente para evitar ramificações de recursos de longa duração e reduzir a complexidade da mesclagem.
  • Implementar testes automatizados e revisões de código para assegurar a qualidade e consistência do código.
  • Validar continuamente a configuração e a sintaxe da arquitetura implementável para assegurar a correção e a consistência.
Pipeline de CI
Um pipeline de CI deve ser configurado para automatizar essas práticas, assegurando que cada alteração de código na arquitetura implementável seja sistematicamente testada e validada Esse pipeline assegura que a arquitetura implementável funcione corretamente e consistentemente e que quaisquer erros ou defeitos sejam capturados antecipadamente.

Ferramentas e recursos

Um conjunto abrangente de ferramentas e recursos é fornecido para facilitar a criação de arquiteturas implementáveis de alta qualidade. Os módulos Terraform curados são uma peça chave, com mais de 60 módulos reutilizáveis, seguros e validados que cobrem uma ampla gama de necessidades de infraestrutura. Esses módulos estão disponíveis no GitHub e são suportados e mantidos atuais por meio de um modelo de contribuição de software livre e apoiados por contribuições da organização de desenvolvimento do IBM Cloud

Além dos módulos do Terraform curados, as melhores práticas e modelos também são fornecidos para ajudar com a arquitetura implementável e a autoria do módulo. Isso inclui documentação, um GitHub modelo de repositório de arquitetura implementável que está alinhado com as melhores práticas de autoria e diretrizes de autoria de módulo que se aplicam aos módulos Terraform e às arquiteturas implementáveis baseadas no Terraform. Esses recursos podem ser usados para iniciar rapidamente em uma nova arquitetura implementável

Uma estrutura de teste automatizada também é fornecida e baseada na biblioteca Terratest, com testes escritos em Go. A estrutura abrange testes de idempotência, testes de atualização e GitHub, e usa funções auxiliares de teste da biblioteca https://github.com/terraform-ibm-modules/ibmcloud-terratest-wrapper. Para obter mais informações, consulte a nossa documentação de teste

Para suportar o desenvolvimento de pipeline de CI, uma variedade de ferramentas e recursos estão disponíveis, incluindo::

  • Reutilizáveis GitHub.
  • Geração automatizada de documentação..
  • Integração automatizada para IBM Cloud.
  • Atualizações de dependência automatizadas usando renovação customizada.
  • Conjunto de ferramentas de configuração de desenvolvimento local e configuração de ganchos pré-confirmados, consulte nossa documentação de configuração de desenvolvimento local para obter mais informações.

Essas ferramentas e recursos são projetadas para acelerar e facilitar a criação de arquiteturas implementáveis de alta qualidade...

Próximas etapas

Agora que você entende as melhores práticas para construir uma arquitetura implementável, é possível usar as ferramentas e os recursos e revisar a documentação do IBM Cloud a seguir antes de desenvolver seu código de automação. Isso ajuda a assegurar que você planejou e projetou completamente sua solução para compartilhar no IBM Cloud: