Como decido que tipo de componente criar?
Como você decide se deve criar um módulo, uma arquitetura implementável ou empilhar arquiteturas implementáveis? Vamos comparar as diferenças e avaliar os casos de uso nas seções a seguir para ajudá-lo a decidir.
Comparação de arquiteturas e módulos implementáveis
A tabela a seguir fornece uma comparação e um resumo rápido das principais diferenças entre módulos e tipos de arquiteturas implementáveis.
| Método | Scope | acoplamento | Implementável | Autor |
|---|---|---|---|---|
| Criar um módulo | Limitado | apertado | Não | Desenvolvedor |
| Criar uma arquitetura implementável | Médio a amplo | apertado | True | Desenvolvedor |
| Arquiteturas implementáveis de pilha | Amplo | Solto | True | Qualquer um |
A tabela a seguir pode ajudá-lo a decidir se deve usar um módulo, uma arquitetura implementável ou empilhar arquiteturas implementáveis juntas, dependendo do seu caso de uso.
| Propósito | Método recomendado | Notas |
|---|---|---|
| Acelerar a automação de codificação | Usar módulos | Os módulos fornecem automação reutilizável e curada para obter desenvolvedores de arquiteturas implementáveis que codificam mais rapidamente. Módulos são para desenvolvedores, não consumidores. |
| Assegure-se de que a nuvem esteja segura e em conformidade | Use uma arquitetura implementável | As arquiteturas implementáveis impõem a segurança e a conformidade para uma arquitetura. Se uma arquitetura implementável for muito pequena no escopo, ela não poderá forçar a conformidade. Por exemplo, uma arquitetura implementável que implementa apenas uma instância de servidor virtual não pode garantir a segurança de rede |
| Dê aos usuários uma escolha com guardrails | Empilhar arquiteturas implementáveis em conjunto | Ao empilhar arquiteturas implementáveis, é possível trocar arquiteturas implementáveis ou adicionar arquiteturas implementáveis e oferecer mais opções aos usuários. Como as arquiteturas implementáveis impõem a segurança e a conformidade, o empilhamento ajuda a garantir que a solução geral permaneça compatível. O empilhamento de arquiteturas implementáveis é uma excelente abordagem para coisas como a seleção do banco de dados a ser usado. |
| Soluções ou arquiteturas criadas pelo usuário | Empilhar arquiteturas implementáveis em conjunto | O empilhamento de arquiteturas implementáveis permite que os usuários criem e publiquem seus próprios padrões repetíveis que ainda são seguros, pois são compostos de arquiteturas implementáveis seguras e compatíveis. |
| Componentes de arquitetura dissociados | Empilhar arquiteturas implementáveis em conjunto | As arquiteturas implantáveis podem ser desenvolvidas e versionadas de forma independente, mas depois empilhadas para implantação. |
| Experiência do usuário simplificada | Use uma arquitetura implementável | As arquiteturas implementáveis podem fornecer uma lista pequena ou simples de entradas para o usuário, mesmo para arquiteturas grandes ou complexas. Arquiteturas implementáveis são simples de entender e implementar. Em comparação, o empilhamento de arquiteturas implementáveis é um pouco mais complexo à medida que as arquiteturas implementáveis são expostas. |
IBM Cloud projetos asseguram que os recursos sejam implementados por meio de arquiteturas implementáveis a partir do catálogo e operem dentro dos guardas de segurança e conformidade da organização. Eles também garantem que esses recursos sejam mantidos atualizados e não se afastem.
Dependências para arquiteturas implantáveis
As dependências surgem quando os recursos provisionados por uma arquitetura implantável são exigidos por outra. Ou seja, os recursos que uma arquitetura implantável provisiona são usados durante a implantação de outra arquitetura, conforme ilustrado na imagem a seguir.
Uma maneira de trabalhar com dependências é empilhar arquiteturas implantáveis e adicionar referências entre elas em um projeto. Por exemplo, a arquitetura VSI on VPC landing zone arquitetura implementável inclui uma variação que amplia a arquitetura implementável da Plataforma de Contêineres Red Hat OpenShift em VPC landing zone. Considere empilhar essas arquiteturas em um projeto. Esta abordagem funciona bem se a arquitetura de pré-requisitos ainda não estiver implementada. Você também não precisa editar o código para empilhar arquiteturas implantáveis.
Muitas arquiteturas implementáveis são independentes e não são extensões de outras arquiteturas, mas você pode optar por estender algumas arquiteturas implementáveis no Arquitetura seção da página de detalhes do catálogo. Selecione uma opção do Como você deseja construir essa arquitetura? cardápio.
No entanto, se você já implantou Red Hat OpenShift Container Platform e você precisar implantar o VSI, os recursos necessários para o VSI já estarão provisionados. Você não precisa implantar o Red Hat OpenShift Arquitetura da Container Platform novamente. Como a arquitetura VSI é uma extensão do Red Hat OpenShift Container Platform, você pode implantar VSI e a arquitetura usa os recursos do Red Hat OpenShift Plataforma de contêineres conforme necessário.
Arquiteturas implementáveis opcionais e intercambiáveis
Quando você integra uma arquitetura implementável a um catálogo privado, pode estendê-la empilhando-a com outras arquiteturas. Ao fazer isso, você pode criar uma solução mais personalizável para seus usuários.
- Por que empilhar durante a integração?
- O empilhamento de arquiteturas durante a integração é semelhante ao empilhamento de arquiteturas em um projeto. Ao integrar uma arquitetura, você pode incluir dependências empilhando as arquiteturas necessárias junto com ela. No entanto,
diferentemente do empilhamento de arquiteturas em um projeto, o empilhamento de arquiteturas durante a integração inclui os seguintes recursos:
- Você pode adicionar arquiteturas opcionais que são adaptadas para diferentes casos de uso.
- Você pode adicionar arquiteturas intercambiáveis que os usuários podem escolher.
- Arquiteturas opcionais
- Talvez sua arquitetura funcione bem com outra arquitetura implementável, mas não seja necessária para atender a uma dependência ou satisfazer a conformidade. Você pode adicionar a arquitetura implementável como opcional, e os usuários podem optar por incluí-la quando adicionarem sua arquitetura implementável a um projeto. Por exemplo, uma arquitetura de monitoramento pode ser útil, mas não necessária.
- Arquiteturas intercambiáveis
- Qualquer arquitetura que você empilhe com a sua própria durante a integração pode ser trocada por outras arquiteturas. As arquiteturas intercambiáveis oferecem aos usuários uma escolha entre várias opções que proporcionam a mesma funcionalidade. Por exemplo, você pode incluir duas arquiteturas implementáveis que criam bancos de dados diferentes, e o usuário pode decidir qual opção de banco de dados deseja usar com a sua arquitetura.
Para obter mais informações, consulte Extensão de uma arquitetura implementável durante a integração.
Arquiteturas opcionais e intercambiáveis podem ser adicionadas à medida que você integra uma arquitetura implementável a um catálogo privado. Atualmente, o empilhamento de arquiteturas implementáveis em um projeto não oferece suporte a arquiteturas opcionais ou intercambiáveis.
Terraform versus Ansible
No IBM Cloud, uma arquitetura implementável deve usar o Terraform para declarar as entradas e saídas da arquitetura implementável (a interface), pois o Ansible não possui uma definição de interface legível por máquina. Caso contrário, o autor de uma arquitetura implementável poderá usar qualquer combinação de pré ou pós-scripts do Ansible e do Terraform para executar o trabalho da arquitetura implementável. Então, como um desenvolvedor decide qual tecnologia usar e para quê?
| Terraform | Ansible | |
|---|---|---|
| Idioma | Declarativo | Procedimento |
| Sintaxe | HCL (semelhante a JSON). | YAML (e callouts para outros scripts) |
| Abordagem padrão | Infraestrutura mutável | Infraestrutura imutável |
| Foco | Infraestrutura | Configuração |
| Desvio | Comparação com o estado desejado | Tarefas idempotentes |
O Terraform é excelente na criação e no gerenciamento de infraestrutura, enquanto o Ansible é excelente na configuração do software e dos sistemas operacionais que estão em execução nessa infraestrutura. Como Ansible é processual, também é possível criar um script de operações únicas. As tarefas de manutenção, como a restauração do backup, são fáceis no Ansible.
| Propósito | Linguagem de configuração recomendada | Notas |
|---|---|---|
| Implementar infraestrutura ou serviços de nuvem | Terraform | O Terraform tem como destino esse caso de uso e é melhor na manipulação da infraestrutura em mudança. O IBM Cloud fornece módulos Terraform e arquiteturas implementáveis suportadas para acelerar padrões de infraestrutura seguros e compatíveis. O modelo de estado do Terraform permite que os desenvolvedores visualizem as mudanças Essas mudanças podem ser varridas para conformidade. |
| Instalar ou configurar software | Ansible | Se uma imagem de contêiner ou de máquina virtual pré-construída não for adequada para o caso de uso, o Ansible será melhor para manipular a instalação e a configuração do software O Ansible tem amplo suporte para operações automatizadas, como edições de configuração, gerenciamento de pacotes e reinicializações de processos. Uma grande biblioteca de módulos e playbooks Ansible está disponível para facilitar a configuração de vários pacotes de software comumente usados. |
| Integração CCDB | Ansible | Fazer uma chamada dinâmica para um serviço no local como um CCDB pode ser feito no Terraform ou no Ansible, mas é mais fácil de realizar em uma linguagem processual ou de script. |
| Validação de entrada | Terraform ou Ansible | O Terraform tem capacidade limitada para fazer a validação de entrada, mas ele é declarativo e pode ser usado por interfaces com o usuário O Ansible inclui a capacidade de executar a validação de entrada dinâmica em que as entradas para uma arquitetura implementável são verificadas com relação a um serviço remoto |
| Ações de manutenção do dia 2 | Ansible | A manutenção do dia 2 é geralmente de natureza processual e melhor concluída no Ansible. Os exemplos incluem backup manual, restauração ou rotações de chave |
| Gerenciamento de desvio. |
|
|
Para obter mais informações sobre como incluir pré ou pós scripts com suas arquiteturas implementáveis, consulte Criando scripts para arquitetura implementável.
Próximas etapas: Decidindo onde publicar
Depois de ter planejado sua arquitetura e decidido qual tipo de componente criar, você deve considerar onde planeja compartilhar ou publicar sua solução, para que outros usuários possam aproveitar a solução criada. Dependendo de onde você planeja compartilhar ou publicar, você pode ter diferentes níveis de requisitos ou aprovações para concluir.