Udostępnij za pośrednictwem


Zagadnienia dotyczące organizacji zasobów dotyczące usługi Azure Red Hat OpenShift (opcjonalnie)

Organizacja zasobów jest głównie zarządzana przez podstawę platformy. Oto kilka sposobów, w jaki podstawa platformy może mieć wpływ na akcelerator strefy docelowej usługi Azure Red Hat OpenShift.

Projekt subskrypcji i grupy zasobów to kluczowe zagadnienia dotyczące ogólnych zaleceń dotyczących strefy docelowej platformy Azure. Odgrywają one podstawową rolę w zarządzaniu organizacją zasobów usługi Azure Red Hat OpenShift. Subskrypcje są granicą zarządzania pod kątem ładu i izolacji zasobów. Zgodnie z opisem w sekcji Zarządzanie grupą i organizacją subskrypcji użyj subskrypcji i grup zarządzania, aby przypisać zasady do zasobów w granicach.

Jeśli na przykład masz aplikacje publiczne i prywatne, rozdziel je na różne subskrypcje i umieść je w odpowiednich grupach zarządzania o nazwie Corp i Onlinelub innych grupach zarządzania poniżej stref docelowych. Subskrypcje działające w grupie Corp zarządzania mają zasady, które uniemożliwiają tworzenie publicznych adresów IP. Subskrypcje, które działają poniżej Online grup zarządzania, zezwalają bezpośrednio na łączność z Internetem i dostęp publiczny. Aby uzyskać więcej informacji na temat zasad stosowanych na różnych poziomach projektowania strefy docelowej platformy Azure, w tym zasad specyficznych dla usługi ARO, zobacz Zasady uwzględnione w implementacjach referencyjnych stref docelowych platformy Azure.

Zagadnienia dotyczące projektowania

  • Zdecyduj, kto będzie zarządzać hostami kontenerów:

    • Jeśli hosty są zarządzane centralnie, można zmniejszyć liczbę wystąpień strefy docelowej. Wymagaj od deweloperów wykonywania zdefiniowanych procesów wdrażania hostów i używania udostępnionych pulpitów nawigacyjnych i alertów dotyczących operacji na poziomie obciążenia.

    • Jeśli zespoły obciążeń zarządzają hostami, potrzebujesz więcej wystąpień strefy docelowej do segmentowania środowisk hostów. Zespoły obciążeń mogą kontrolować swoje wdrożenia.

    • Niezależnie od tego, czy hosty są zarządzane centralnie przez zespoły obciążeń, należy rozszerzyć tę uwagę na sąsiadujące i powiązane zasoby, takie jak zapory aplikacji internetowej, magazyny kluczy, agenci kompilacji potoku i potencjalnie w celu przeskoczenia pól.

  • Wybierz model dzierżawy dla klastrów:

    • Obciążenie obsługiwane przez zespół, pojedyncza dzierżawa: Pojedynczy host klastra, który obsługuje pojedyncze obciążenie, prawdopodobnie wymaga dedykowanej strefy docelowej dla segmentacji i kontroli zespołu obciążeń.

    • Platformy technologiczne, hosty wielodostępne: Gdy hosty są zarządzane centralnie, wydajność operacyjna pochodzi z konsolidowania wielu hostów i wielu obciążeń w udostępnionych subskrypcjach strefy docelowej. Konsolidacja zmniejsza liczbę stref docelowych i hostów przeznaczonych do obsługi pojedynczego klastra lub obciążenia.

      Może być konieczne dodanie subskrypcji strefy docelowej, jeśli segmentacja jest wymagana do oddzielenia obciążeń na podstawie regionu, jednostki biznesowej, środowiska, krytycznych lub innych ograniczeń zewnętrznych.

      Porada

      Zapoznaj się z artykułem Dostosowywanie architektury strefy docelowej platformy Azure, aby spełnić wymagania przed utworzeniem dodatkowych grup zarządzania.

    • Centralnie obsługiwana, pojedyncza dzierżawa: W przypadku wrogich lub regulowanych obciążeń, które są nadal obsługiwane centralnie, często mają dedykowane hosty dla obciążeń. Nadal może wystąpić wydajność operacyjna, konsolidując strefy docelowe obsługujące.

  • Wybierz hierarchię grupy zarządzania na podstawie ogólnej skali i wyrównania środowisk i hostów wymaganych do obsługi ogólnych wymagań portfela:

    • Użyj płaskiej struktury, aby obsługiwać wiele dedykowanych hostów w dedykowanych środowiskach na potrzeby operacji zdecentralizowanych uruchamianych przez każdy zespół obciążeń.
    • Użyj podzielonej struktury, aby utworzyć grupę zarządzania dla hostów zarządzanych centralnie i oddzielną grupę zarządzania na potrzeby operacji zdecentralizowanych.
    • Użyj struktury hierarchicznej do dalszego segmentowania środowisk w celu odzwierciedlenia wymagań dotyczących rozliczeń, ładu lub operacyjnych.
  • Zdecyduj, który rejestr kontenerów ma być używany:

  • Zdecyduj, która topologia rejestru kontenerów ma być używana do dystrybucji artefaktów Open Container Initiative (OCI):

    • Jeden rejestr na obciążenie.
    • Jeden rejestr na klaster z wieloma obciążeniami w rejestrze.
    • Jeden rejestr dla wszystkich klastrów w strefie docelowej z wieloma obciążeniami i klastrami w tym samym rejestrze.
    • Jeden rejestr dla wszystkich klastrów w wielu strefach docelowych z wieloma obciążeniami i klastrami w tym samym rejestrze.
  • Zdecyduj zakres zasad rejestru kontenerów w Azure Policy:

    • Ustaw zasady na poziomie subskrypcji, aby wymagać, aby wszystkie hosty w strefie docelowej używały zdefiniowanego rejestru.
    • Ustaw bardziej szczegółowe zasady na poziomie grupy zasobów.
    • Ustaw szersze zasady na poziomie grupy zarządzania.

Zalecenia dotyczące projektowania

  • Zdefiniuj standard nazewnictwa i tagowania , który ma być stosowany do wszystkich zasobów kontenera wdrożonych na platformie Azure. Co najmniej standard powinien obejmować następujące elementy:
    • Nazwy obciążeń: Obciążenia lub obciążenia obsługiwane przez każdy klaster.
    • Zasoby klastra: Podniesienie poziomu zasobów klastra z powyższych zagadnień.
    • Operator hosta: Który zespół jest odpowiedzialny za operacje hosta.
  • Zaimplementuj zasady, aby wymagać określonego rejestru artefaktów OCI opartego na topologii rejestru kontenerów w organizacji.

Następne kroki