Overwegingen voor resourceorganisatie voor Azure Red Hat OpenShift (optioneel)

  • Artikel

Resource-organisatie wordt meestal beheerd door de platformbasis. Hier volgen enkele manieren waarop de platformbasis van invloed kan zijn op uw Azure Red Hat OpenShift-landingszoneversneller.

Het ontwerp van abonnementen en resourcegroepen zijn belangrijke overwegingen in algemene aanbevelingen voor Azure-landingszones. Ze spelen een fundamentele rol bij het beheren van uw Azure Red Hat OpenShift-resourceorganisatie. Abonnementen vormen de beheergrens voor resourcebeheer en isolatie. Zoals beschreven in Beheergroep en abonnementsorganisatie, gebruikt u abonnementen en beheergroepen om beleidsregels toe te wijzen aan de resources binnen de grenzen.

Als u bijvoorbeeld openbare en persoonlijke toepassingen hebt, scheidt u deze in verschillende abonnementen en plaatst u ze in de juiste beheergroepen met de naam Corp en Online, of andere beheergroepen onder Landingszones. De abonnementen die zich in de Corp beheergroep bevinden, hebben beleidsregels die het maken van openbare IP-adressen verhinderen. De abonnementen die zich onder de Online beheergroepen bevinden, bieden rechtstreeks internetverbinding en openbare toegang. Voor meer informatie over welke beleidsregels worden toegepast op de verschillende niveaus van het ontwerp van een Azure-landingszone, met inbegrip van ARO-specifieke beleidsregels, raadpleegt u Beleidsregels die zijn opgenomen in azure-landingszones naslag implementaties.

Overwegingen bij het ontwerpen

  • Bepaal wie containerhosts gaat beheren:

    • Als de hosts centraal worden beheerd, kunt u het aantal exemplaren van de landingszone verminderen. Vereisen dat ontwikkelaars gedefinieerde processen volgen om hosts te implementeren en gedeelde dashboards en waarschuwingen te gebruiken voor bewerkingen op workloadniveau.

    • Als workloadteams de hosts beheren, hebt u meer landingszone-exemplaren nodig om hostomgevingen te segmenteren. Workloadteams kunnen hun implementaties beheren.

    • Of hosts nu centraal worden beheerd door workloadteams, breid deze overweging uit naar aangrenzende en gerelateerde resources, zoals webtoepassingsfirewalls, sleutelkluizen, pijplijnbuildagents en mogelijk naar jumpboxs.

  • Kies een tenancymodel voor clusters:

    • Door een workloadteam beheerd, één tenant: Voor één clusterhost die ondersteuning biedt voor één workload, is waarschijnlijk een speciale landingszone vereist voor segmentatie en beheer van workloadteams.

    • Technologieplatforms, multitenanthosts: Wanneer hosts centraal worden beheerd, wordt operationele efficiëntie verkregen door het consolideren van meerdere hosts en meerdere workloads in abonnementen voor gedeelde landingszones. Consolidatie vermindert het aantal landingszones en hosts die zijn toegewezen aan de ondersteuning van één cluster of workload.

      Mogelijk moet u abonnementen voor landingszones toevoegen als segmentatie is vereist om workloads te scheiden op basis van regio, bedrijfseenheid, omgeving, ernst of andere externe beperkingen.

      Tip

      Bekijk de architectuur van de Azure-landingszone aanpassen om te voldoen aan de vereisten voordat u extra beheergroepen maakt.

    • Centraal beheerd, één tenant: Voor vijandige of gereguleerde workloads die nog steeds centraal worden uitgevoerd, is het gebruikelijk om toegewezen hosts voor de workloads te hebben. U kunt nog steeds operationele efficiëntie ervaren door ondersteunende landingszones te consolideren.

  • Kies een beheergroephiërarchie op basis van de algemene schaal en uitlijning van omgevingen en hosts die nodig zijn om de algemene portfoliovereisten te ondersteunen:

    • Gebruik een platte structuur ter ondersteuning van veel toegewezen hosts in toegewezen omgevingen voor gedecentraliseerde bewerkingen die door elk workloadteam worden uitgevoerd.
    • Gebruik een gesegmenteerde structuur om een beheergroep te maken voor centraal beheerde hosts en een afzonderlijke beheergroep voor gedecentraliseerde bewerkingen.
    • Gebruik een hiërarchische structuur om omgevingen verder te segmenteren om rekening te houden met facturerings-, governance- of operationele vereisten.

  • Bepaal welk containerregister u wilt gebruiken:

  • Bepaal welke containerregistertopologie moet worden gebruikt voor de distributie van OCI-artefacten (Open Container Initiative):

    • Eén register per workload.
    • Eén register per cluster, met meerdere workloads in het register.
    • Eén register voor alle clusters in de landingszone, met meerdere workloads en clusters in hetzelfde register.
    • Eén register voor alle clusters in meerdere landingszones, met meerdere workloads en clusters in hetzelfde register.

  • Bepaal het bereik voor containerregisterbeleidsregels in Azure Policy:

    • Stel een beleid in op abonnementsniveau om te vereisen dat alle hosts in de landingszone het gedefinieerde register gebruiken.
    • Stel een gedetailleerder beleid in op het niveau van de resourcegroep.
    • Stel een breder beleid in op het niveau van de beheergroep.

Ontwerpaanbeveling

  • Definieer een naamgevings- en tagstandaard die moet worden toegepast op alle containerresources die in Azure zijn geïmplementeerd. De standaard moet minimaal het volgende omvatten:
    • Workloadnamen: De workload of workloads die elk cluster ondersteunt.
    • Clusterresources: De uitbreiding van de uitlijning van clusterresources ten opzichte van de voorgaande overwegingen.
    • Hostoperator: Welk team is verantwoordelijk voor hostbewerkingen.
  • Implementeer een beleid om een specifiek OCI-artefactregister te vereisen dat is gebaseerd op de containerregistertopologie van uw organisatie.

Volgende stappen