Documentando sua arquitetura de ambiente

Como uma melhor prática, crie diagramas de arquitetura para seus aplicativos. Esses diagramas podem ser usados como parte do trabalho de design inicial, treinando novos membros da equipe ou educando membros da equipe novos e existentes. Manter diagramas como este atualizados economiza tempo quando os problemas precisam ser investigados rapidamente

Ao documentar a arquitetura do seu aplicativo, você pode garantir que você e sua equipe compreendam completamente todos os componentes da configuração da arquitetura.

É possível criar um diagrama de arquitetura como parte de seu planejamento de ambiente inicial ou depois que seu ambiente estiver ativo e em execução Revise as seguintes etapas para documentar seu ambiente. Os exemplos fornecidos são baseados em aplicativos do mundo real.

Etapa 1: Entendendo seu app e sua arquitetura

A resolução de problemas de apps em clusters IBM Cloud Kubernetes Service pode ser complicada, especialmente se o problema envolver um fluxo de rede que abranja diferentes clusters, componentes, pods ou serviços. Documentar a arquitetura de seu aplicativo pode ajudar sua equipe a entender completamente todos os componentes em sua configuração

Para um aplicativo com um fluxo de rede simples, a arquitectura pode ser descrita em texto. Para cenários mais complicados, um diagrama de arquitetura detalhado é útil para que várias equipes envolvidas com a resolução de problemas possam entender o fluxo Também é importante assegurar que sua documentação de arquitetura permaneça atualizada se sua configuração for alterada.

A resolução de problemas de apps em clusters IBM Cloud Kubernetes Service pode ser difícil, especialmente se um ou mais dos itens a seguir forem verdadeiros.

  1. O aplicativo não é bem compreendido ou não tem boa criação de log.
  2. O problema é intermitente ou não ocorre com frequência.
  3. O problema envolve um fluxo de rede que abrange diferentes clusters, componentes, pods ou serviços.

Os diagramas de arquitetura de exemplo a seguir são obtidos de cenários do mundo real. É possível usar esses exemplos como um guia ao criar seus próprios diagramas de arquitetura

Exemplo 1: um app básico em execução em um único cluster do OpenShift

Neste exemplo, o app inteiro está em execução dentro de um único cluster do OpenShift É um app simples no qual um único pod do cliente faz uma solicitação para um serviço em cluster, que, então, se conecta a uma instância etcd manipulada por três pods.

Client                Application Service             Etcd Instance
                                             |------> [Etcd Pod 1]
                |---> [Application Pod 1] ---|
                |                            |
[Client pod] ---|                            |------> [Etcd Pod 2]
                |                            |
                |---> [Application Pod 2] ---|
                                             |------> [Etcd Pod 3]

Exemplo 2: uma arquitetura de vários clusters com um balanceador de carga global e serviço Cloudant

No diagrama a seguir, a conexão é iniciada por um dos três pods do cliente em um cluster na região do eu-de Os pods do cliente se conectam a um balanceador de carga global (GLB) que, em seguida, balanceia a carga da conexão com um dos dois balanceadores de carga do aplicativo (ALBs) públicos do VPC no eu-de e no eu-gb.

Cada um desses VPC ALBs faz parte de um cluster separado em suas regiões. Esses ALBs roteiam o tráfego para os pods do roteador do OpenShift, que então encaminham esse tráfego para os pods de backend no cluster. Esses pods de backend se conectam a um banco de dados Cloudant para manipular a solicitação.

Observe que algumas dessas conexões estão na rede pública. Alguns estão sobre uma rede privada no mesmo VPC e alguns usam a rede privada no IBM Cloud entre os componentes em um VPC e um serviço no IBM Cloud.

de vários
de vários clusters*

Exemplo 3: um cliente VSI entrando em contato com um balanceador de carga de rede VPC com um back-end de serviço externo

No exemplo a seguir, o cliente é uma VSI clássica no IBM Cloud. A VSI se conecta por meio da rede privada a um balanceador de carga de rede VPC privado (NLB) criado para um cluster VPC. Esse NLB equilibra o tráfego para um dos três nós do trabalhador do VPC por meio do NodePort para o serviço Load Balancer do cluster. O serviço Load Balancer do cluster então envia o tráfego para um dos pods de app que se conectam a um serviço de nuvem externo fora do IBM Cloud pela rede pública.

NLB com um serviço
com serviço

Passo 2: Escolha uma ferramenta

É possível usar qualquer uma das ferramentas a seguir para criar seu diagrama de arquitetura

Há muitas ferramentas de diagramação disponíveis. Escolha a ferramenta que funciona melhor para você.

Etapa 3: Criar o diagrama

É possível usar um dos exemplos mencionados anteriormente como uma referência ou criar um diagrama do zero.

Para obter mais informações e arquiteturas de referência, consulte IBM Architectures..

Próximas etapas

Prepare sua conta para criar clusters.