Compartilhar via

Considerações da organização de recursos para o Red Hat OpenShift no Azure (opcional)

  • Artigo

A organização de recursos é gerenciada principalmente pela base da plataforma. Aqui estão algumas maneiras pelas quais a base da plataforma pode afetar o acelerador de zona de destino do Red Hat OpenShift no Azure.

Design de assinatura e grupo de recursos são considerações importantes em recomendações genéricas de zona de destino do Azure. Eles desempenham um papel fundamental na forma como você gerencia sua organização de recursos do Red Hat OpenShift no Azure. As assinaturas são o limite de gerenciamento para governança e isolamento de recursos. Conforme descrito em Grupo de gerenciamento e organização de assinatura, use assinaturas e grupos de gerenciamento para atribuir políticas aos recursos dentro dos limites.

Por exemplo, se você tiver aplicativos públicos e privados, separe-os em assinaturas diferentes e coloque-os nos Grupos de Gerenciamento apropriados chamados Corp e Onlineou em outros Grupos de Gerenciamento abaixo das Zonas de Destino. As assinaturas que residem no Corp Grupo de Gerenciamento têm políticas que impedem a criação de endereços IP públicos. As assinaturas que residem abaixo dos Online Grupos de Gerenciamento permitem a conectividade com a Internet e o acesso público diretamente. Para obter mais informações sobre quais políticas são aplicadas nos diferentes níveis de um design de zona de destino do Azure, incluindo políticas específicas do ARO, consulte Políticas incluídas nas implementações de referência de zonas de destino do Azure.

Considerações sobre o design

  • Decida quem gerenciará os hosts de contêiner:

    • Se os hosts forem gerenciados centralmente, você poderá reduzir o número de instâncias da zona de destino. Exigir que os desenvolvedores sigam processos definidos para implantar hosts e usar dashboards e alertas compartilhados para operações no nível da carga de trabalho.

    • Se as equipes de carga de trabalho gerenciarem os hosts, você precisará de mais instâncias de zona de destino para segmentar ambientes de host. As equipes de carga de trabalho podem controlar suas implantações.

    • Se os hosts são gerenciados centralmente por equipes de carga de trabalho, estenda essa consideração para recursos adjacentes e relacionados, como firewalls de aplicativo Web, cofres de chaves, agentes de build de pipeline e potencialmente para jump boxes.

  • Escolha um modelo de locação para os clusters:

    • Locatário único operado pela equipe de carga de trabalho: Um único host de cluster que dá suporte a uma única carga de trabalho provavelmente requer uma zona de destino dedicada para segmentação e controle da equipe de carga de trabalho.

    • Plataformas de tecnologia, hosts multilocatários: Quando os hosts são gerenciados centralmente, a eficiência operacional vem da consolidação de vários hosts e várias cargas de trabalho em assinaturas de zona de destino compartilhada. A consolidação reduz o número de zonas de destino e hosts dedicados a dar suporte a um único cluster ou carga de trabalho.

      Talvez seja necessário adicionar assinaturas de zona de destino se a segmentação for necessária para separar cargas de trabalho com base em região, unidade de negócios, ambiente, criticalidade ou outras restrições externas.

      Dica

      Examine Personalizar a arquitetura da zona de destino do Azure para atender aos requisitos antes de criar grupos de gerenciamento adicionais.

    • Locatário único operado centralmente: Para cargas de trabalho hostis ou regulamentadas que ainda são operadas centralmente, é comum ter hosts dedicados para as cargas de trabalho. Você ainda pode ter eficiência operacional consolidando as zonas de destino de suporte.

  • Escolha uma hierarquia de grupo de gerenciamento baseada na escala geral e no alinhamento dos ambientes e hosts necessários para dar suporte aos requisitos de portfólio geral:

    • Use uma estrutura simples para dar suporte a muitos hosts dedicados em ambientes dedicados para operações descentralizadas executadas por cada equipe de carga de trabalho.
    • Use uma estrutura segmentada para criar um grupo de gerenciamento para hosts gerenciados centralmente e um grupo de gerenciamento separado para operações descentralizadas.
    • Use uma estrutura hierárquica para segmentar ambientes adicionais para refletir a cobrança, a governança ou os requisitos operacionais.

  • Decida qual registro de contêiner usar:

  • Decida qual topologia de registro de contêiner usar para distribuição de artefatos OCI (Open Container Initiative):

    • Um registro por carga de trabalho.
    • Um registro por cluster, com várias cargas de trabalho no registro.
    • Um registro para todos os clusters na zona de destino, com várias cargas de trabalho e clusters no mesmo registro.
    • Um registro para todos os clusters em várias zonas de destino, com várias cargas de trabalho e clusters no mesmo registro.

  • Decida o escopo das políticas de registro de contêiner no Azure Policy:

    • Defina uma política no nível da assinatura para exigir que todos os hosts na zona de destino usem o registro definido.
    • Defina uma política mais granular no nível do grupo de recursos.
    • Defina uma política mais ampla no nível do grupo de gerenciamento.

Recomendações sobre design

  • Defina um padrão de nomenclatura e marcação a ser aplicado a todos os recursos de contêiner implantados no Azure. No mínimo, o padrão deve incluir:
    • Nomes de carga de trabalho: A carga de trabalho ou as cargas de trabalho compatíveis com cada cluster.
    • Recursos de cluster: A elevação do alinhamento de recursos de cluster das considerações anteriores.
    • Operador de host: Qual equipe é responsável pelas operações de host.
  • Implemente uma política para exigir um registro de artefato OCI específico baseado na topologia do registro de contêiner da sua organização.

Próximas etapas