Resursorganisationsöverväganden för Azure Red Hat OpenShift (valfritt)

Resursorganisationen hanteras främst av plattformsfundamentet. Här är några sätt som plattformsfundamentet kan påverka din Azure Red Hat OpenShift-accelerator för landningszoner.

Prenumerations- och resursgruppsdesign är viktiga överväganden i allmänna rekommendationer för Azure-landningszoner. De spelar en grundläggande roll i hur du hanterar din Azure Red Hat OpenShift-resursorganisation. Prenumerationer är hanteringsgränsen för resursstyrning och isolering. Enligt beskrivningen i Hanteringsgrupp och prenumerationsorganisation använder du prenumerationer och hanteringsgrupper för att tilldela principer till resurserna inom gränserna.

Om du till exempel har offentliga och privata program separerar du dem i olika prenumerationer och placerar dem i lämpliga hanteringsgrupper med namnet Corp och Online, eller andra hanteringsgrupper under landningszonerna. De prenumerationer som finns i Corp hanteringsgruppen har principer som förhindrar att offentliga IP-adresser skapas. De prenumerationer som finns under Online hanteringsgrupperna tillåter internetanslutning och offentlig åtkomst direkt. Mer information om vilka principer som tillämpas på olika nivåer i en Azure-landningszonsdesign, inklusive ARO-specifika principer, finns i Principer som ingår i Referensimplementeringar för Azure-landningszoner.

Designöverväganden

  • Bestäm vem som ska hantera containervärdar:

    • Om värdarna hanteras centralt kan du minska antalet instanser i landningszonen. Kräv att utvecklare följer definierade processer för att distribuera värdar och använda delade instrumentpaneler och aviseringar för åtgärder på arbetsbelastningsnivå.

    • Om arbetsbelastningsteam hanterar värdarna behöver du fler landningszonsinstanser för att segmentera värdmiljöer. Arbetsbelastningsteam kan styra sina distributioner.

    • Oavsett om värdar hanteras centralt av arbetsbelastningsteam, utökar du det här övervägandet till angränsande och relaterade resurser som brandväggar för webbprogram, nyckelvalv, pipeline build-agenter och potentiellt hopprutor.

  • Välj en innehavarmodell för kluster:

    • Teamdriven, enskild klientorganisation för arbetsbelastning: En enskild klustervärd som stöder en enskild arbetsbelastning kräver troligen en dedikerad landningszon för segmentering och kontroll av arbetsbelastningsteamet.

    • Teknikplattformar, värdar för flera klientorganisationer: När värdar hanteras centralt kommer drifteffektiviteten från att konsolidera flera värdar och flera arbetsbelastningar i prenumerationer på delade landningszoner. Konsolidering minskar antalet landningszoner och värdar som är dedikerade för att stödja ett enskilt kluster eller en enda arbetsbelastning.

      Du kan behöva lägga till prenumerationer för landningszoner om segmentering krävs för att separera arbetsbelastningar baserat på region, affärsenhet, miljö, allvarlighetsgrad eller andra externa begränsningar.

      Tips

      Granska arkitekturen För att anpassa Azure-landningszonen så att den uppfyller kraven innan du skapar ytterligare hanteringsgrupper.

    • Centralt drivna, enskild klientorganisation: För fientliga eller reglerade arbetsbelastningar som fortfarande drivs centralt är det vanligt att ha dedikerade värdar för arbetsbelastningarna. Du kan fortfarande uppleva driftseffektivitet genom att konsolidera stödande landningszoner.

  • Välj en hanteringsgruppshierarki baserat på den allmänna skalan och justeringen av miljöer och värdar som krävs för att stödja övergripande portföljkrav:

    • Använd en platt struktur för att stödja många dedikerade värdar i dedikerade miljöer för decentraliserade åtgärder som körs av varje arbetsbelastningsteam.
    • Använd en segmenterad struktur för att skapa en hanteringsgrupp för centralt hanterade värdar och en separat hanteringsgrupp för decentraliserade åtgärder.
    • Använd en hierarkisk struktur för att ytterligare segmentera miljöer för att återspegla fakturerings-, styrnings- eller driftskrav.
  • Bestäm vilket containerregister som ska användas:

  • Bestäm vilken containerregistertopologi som ska användas för OCI-artefaktdistribution (Open Container Initiative):

    • Ett register per arbetsbelastning.
    • Ett register per kluster, med flera arbetsbelastningar i registret.
    • Ett register för alla kluster i landningszonen, med flera arbetsbelastningar och kluster i samma register.
    • Ett register för alla kluster i flera landningszoner, med flera arbetsbelastningar och kluster i samma register.
  • Bestäm omfånget för containerregisterprinciper i Azure Policy:

    • Ange en princip på prenumerationsnivå för att kräva att alla värdar i landningszonen använder det definierade registret.
    • Ange en mer detaljerad princip på resursgruppsnivå.
    • Ange en bredare princip på hanteringsgruppsnivå.

Designrekommendationer

  • Definiera en namngivnings- och taggningsstandard som ska tillämpas på alla containerresurser som distribueras till Azure. Standarden bör minst innehålla:
    • Arbetsbelastningsnamn: Den arbetsbelastning eller de arbetsbelastningar som varje kluster stöder.
    • Klusterresurser: Höjningen av klusterresursjusteringen från föregående överväganden.
    • Värdoperator: Vilket team ansvarar för värdåtgärder.
  • Implementera en princip för att kräva ett specifikt OCI-artefaktregister som baseras på organisationens containerregistertopologi.

Nästa steg