Partilhar via

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

  • Artigo

A organização de recursos é maioritariamente gerida pela base da plataforma. Eis algumas formas de a base da plataforma afetar o acelerador de zonas de destino do Azure Red Hat OpenShift.

A conceção da subscrição e do grupo de recursos são considerações fundamentais nas recomendações genéricas da zona de destino do Azure. Desempenham um papel fundamental na forma como gere a sua organização de recursos do Azure Red Hat OpenShift. As subscrições são o limite de gestão para governação e isolamento de recursos. Conforme descrito em Grupo de gestão e organização de subscrições, utilize subscrições e grupos de gestão para atribuir políticas aos recursos dentro dos limites.

Por exemplo, se tiver aplicações públicas e privadas, separe-as em subscrições diferentes e coloque-as nos Grupos de Gestão adequados com o nome Corp e Online, ou outros Grupos de Gestão abaixo das Zonas de Destino. As subscrições que se encontram no Corp Grupo de Gestão têm políticas que impedem a criação de endereços IP públicos. As subscrições que se encontram abaixo dos Online Grupos de Gestão permitem a conectividade à Internet e o acesso público diretamente. Para obter mais informações sobre que políticas são aplicadas nos diferentes níveis de uma estrutura de zona de destino do Azure, incluindo políticas específicas da ARO, veja Políticas incluídas nas implementações de referência de zonas de destino do Azure.

Considerações de design

  • Decida quem irá gerir os anfitriões de contentores:

    • Se os anfitriões forem geridos centralmente, pode reduzir o número de instâncias de zona de destino. Exigir que os programadores sigam os processos definidos para implementar anfitriões e utilizar dashboards e alertas partilhados para operações ao nível da carga de trabalho.

    • Se as equipas de carga de trabalho gerirem os anfitriões, precisará de mais instâncias de zona de destino para segmentar ambientes anfitriões. As equipas de cargas de trabalho podem controlar as implementações.

    • Quer os anfitriões sejam geridos centralmente pelas equipas de carga de trabalho, expanda esta consideração para recursos adjacentes e relacionados, como firewalls de aplicações Web, cofres de chaves, agentes de compilação de pipelines e potencialmente para saltar caixas.

  • Escolha um modelo de inquilino para clusters:

    • Inquilino único, operado pela equipa de carga de trabalho: Um único anfitrião de cluster que suporte uma única carga de trabalho provavelmente requer uma zona de destino dedicada para segmentação e controlo da equipa de carga de trabalho.

    • Plataformas tecnológicas, anfitriões multi-inquilinos: Quando os anfitriões são geridos centralmente, a eficiência operacional provém da consolidação de vários anfitriões e de várias cargas de trabalho em subscrições de zona de destino partilhadas. A consolidação reduz o número de zonas de destino e anfitriões dedicados ao suporte de um único cluster ou carga de trabalho.

      Poderá ter de adicionar subscrições de zona de destino se for necessária segmentação para separar cargas de trabalho com base na região, unidade de negócio, ambiente, crítica ou outras restrições externas.

      Dica

      Veja Personalizar a arquitetura da zona de destino do Azure para cumprir os requisitos antes de criar quaisquer Grupos de Gestão adicionais.

    • Inquilino único operado centralmente: Para cargas de trabalho hostis ou reguladas que ainda são operadas centralmente, é comum ter anfitriões dedicados para as cargas de trabalho. Poderá continuar a ter eficiência operacional ao consolidar as zonas de destino de suporte.

  • Escolha uma hierarquia de grupo de gestão com base na escala geral e no alinhamento dos ambientes e anfitriões necessários para suportar os requisitos gerais de portefólio:

    • Utilize uma estrutura plana para suportar muitos anfitriões dedicados em ambientes dedicados para operações descentralizadas executadas por cada equipa de carga de trabalho.
    • Utilize uma estrutura segmentada para criar um grupo de gestão para anfitriões geridos centralmente e um grupo de gestão separado para operações descentralizadas.
    • Utilize uma estrutura hierárquica para segmentar ainda mais ambientes para refletir a faturação, governação ou requisitos operacionais.

  • Decida que registo de contentor deve utilizar:

  • Decida que topologia do registo de contentor utilizar para a distribuição de artefactos open container initiative (OCI):

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

  • Decida o âmbito das políticas de registo de contentores no Azure Policy:

    • Defina uma política ao nível da subscrição para exigir que todos os anfitriões na zona de destino utilizem o registo definido.
    • Defina uma política mais granular ao nível do grupo de recursos.
    • Defina uma política mais ampla ao nível do grupo de gestão.

Recomendações de conceção

  • Defina uma norma de nomenclatura e etiquetagem para aplicar a todos os recursos de contentor implementados no Azure. No mínimo, a norma deve incluir:
    • Nomes das cargas de trabalho: A carga de trabalho ou cargas de trabalho suportadas por cada cluster.
    • Recursos do cluster: A elevação do alinhamento de recursos do cluster das considerações anteriores.
    • Operador anfitrião: Que equipa é responsável pelas operações de anfitrião.
  • Implemente uma política para exigir um registo de artefactos OCI específico baseado na topologia do registo de contentor da sua organização.

Passos seguintes