Partager via

Considérations relatives à l’organisation des ressources pour Azure Red Hat OpenShift (facultatif)

  • Article

L’organisation des ressources est principalement gérée par la base de la plateforme. Voici quelques façons dont la base de la plateforme peut affecter votre accélérateur de zone d’atterrissage Azure Red Hat OpenShift.

La conception de l’abonnement et du groupe de ressources sont des points clés des recommandations de zones d’atterrissage génériques Azure. Ils jouent un rôle fondamental dans la façon dont vous gérez l’organisation de vos ressources Azure Red Hat OpenShift. Les abonnements sont la limite de gestion pour la gouvernance et l’isolation des ressources. Comme décrit dans le Groupe d’administration et organisation des abonnements, utilisez des abonnements et des groupes d’administration pour affecter des stratégies aux ressources dans les limites.

Par exemple, si vous avez des applications publiques et privées, séparez-les dans différents abonnements et placez-les dans les groupes d’administration appropriés nommés Corp et Online, ou d’autres groupes d’administration sous des zones d’atterrissage. Les abonnements qui se trouvent dans le groupe d’administration Corp comportent des stratégies qui empêchent la création d’adresses IP publiques. Les abonnements qui se trouvent sous les groupes d’administration Online autorisent la connectivité Internet et l’accès public directement. Pour plus d’informations sur les stratégies appliquées aux différents niveaux d’une conception de zone d’atterrissage Azure, y compris des stratégies spécifiques à ARO, consultez Stratégies incluses dans les implémentations de référence de zones d’atterrissage Azure.

Remarques relatives à la conception

  • Déterminez qui doit gérer les hôtes de conteneur :

    • Si les hôtes sont gérés de manière centralisée, vous pouvez réduire le nombre d’instances de zone d’atterrissage. Exigez des développeurs qu’ils suivent des processus définis pour déployer des hôtes, et utilisent des tableaux de bord et des alertes partagés pour les opérations au niveau de la charge de travail.

    • Si les hôtes sont gérés par les équipes de charge de travail, vous avez besoin de davantage d’instances de zone d’atterrissage pour segmenter les environnements hôtes. Les équipes de charge de travail peuvent contrôler leurs déploiements.

    • Si les hôtes sont gérés de manière centralisée par des équipes de charge de travail, étendez cette considération à des ressources adjacentes et connexes telles que des pare-feu d’applications web, des coffres de clés, des agents de build de pipeline, voire des serveurs de rebond.

  • Choisir un modèle de location pour les clusters :

    • Client unique exploité par une équipe charge de travail  : un hôte de cluster unique prenant en charge une charge de travail unique nécessite probablement une zone d’atterrissage dédiée pour la segmentation et le contrôle de l’équipe de charge de travail.

    • Plateformes technologiques, hôtes multilocataires : lorsque les hôtes sont gérés de manière centralisée, l’efficacité opérationnelle provient de la consolidation de plusieurs hôtes et charges de travail dans des abonnements de zone d’atterrissage partagés. La consolidation réduit le nombre de zones d’atterrissage et d’hôtes dédiés à la prise en charge d’un cluster ou d’une charge de travail uniques.

      Il se peut que vous deviez ajouter des abonnements de zone d’atterrissage si une segmentation est requise, afin de séparer les charges de travail en fonction de la région, de l’unité commerciale, de l’environnement, de la criticité ou d’autres contraintes externes.

      Conseil

      Passez en revue Personnaliser l’architecture d’une zone d’atterrissage Azure pour répondre aux besoins avant de créer des groupes d’administration supplémentaires.

    • Locataire unique piloté de manière centralisée : pour des charges de travail hostiles ou réglementées qui sont encore centralisées, il est courant d’avoir des hôtes dédiés. Vous pouvez continuer à bénéficier d’une efficacité opérationnelle en consolidant les zones d’atterrissage associées.

  • Choisissez une hiérarchie de groupes d’administration en fonction de l’échelle générale et de l’alignement des environnements et hôtes requis pour prendre en charge les besoins globaux du portefeuille :

    • Utilisez une structure plate pour prendre en charge de nombreux hôtes dédiés dans des environnements dédiés pour les opérations décentralisées exécutées par chaque équipe de charge de travail.
    • Utilisez une structure segmentée pour créer un groupe d’administration pour les hôtes gérés de manière centralisée et un groupe d’administration distinct pour les opérations décentralisées.
    • Utilisez une structure hiérarchique segmentant davantage les environnements afin de refléter la facturation, la gouvernance ou les exigences opérationnelles.

  • Décidez du registre de conteneurs à utiliser :

  • Choisissez la topologie de registre de conteneurs à utiliser pour la distribution d’artefacts Open Container Initiative (OCI) :

    • un registre par charge de travail ;
    • un registre par cluster avec plusieurs charges de travail dans le registre ;
    • un registre pour tous les clusters de la zone d’atterrissage avec plusieurs charges de travail et clusters dans le même registre ;
    • un registre pour tous les clusters de plusieurs zones d’atterrissage avec plusieurs charges de travail et clusters dans le même registre.

  • Déterminez l’étendue des stratégies de registre de conteneurs dans Azure Policy :

    • Définissez une stratégie au niveau de l’abonnement pour exiger que tous les ordinateurs hôtes dans la zone de destination utilisent le registre défini.
    • Définissez une stratégie plus granulaire au niveau du groupe de ressources.
    • Définissez une stratégie plus large au niveau du groupe d’administration.

Recommandations de conception

  • Définissez une norme de nommage et de balisage à appliquer à toutes les ressources de conteneur déployées sur Azure. La norme devrait inclure au minimum les éléments suivants :
    • Noms des charges de travail : la ou les charges de travail que chaque cluster prend en charge.
    • Ressources de cluster : élévation de l’alignement des ressources de cluster dans les considérations précédentes.
    • Opérateur de l’hôte : équipe responsable des opérations de l’hôte.
  • Implémentez une stratégie pour exiger un registre d’artefacts OCI spécifique basé sur la topologie du registre de conteneurs de votre organisation.

Étapes suivantes