Considerazioni sull'organizzazione delle risorse per Azure Red Hat OpenShift (facoltativo)

  • Articolo

L'organizzazione delle risorse è gestita principalmente dalle basi della piattaforma. Ecco alcuni modi in cui le basi della piattaforma potrebbero influire sull'acceleratore di zona di destinazione di Azure Red Hat OpenShift.

La progettazione di sottoscrizioni e gruppi di risorse è una considerazione fondamentale nelle raccomandazioni generiche della zona di destinazione di Azure. Svolgono un ruolo fondamentale nella gestione dell'organizzazione delle risorse di Azure Red Hat OpenShift. Le sottoscrizioni rappresentano il limite di gestione per la governance e l'isolamento delle risorse. Come descritto in Gruppo di gestione e organizzazione della sottoscrizione, usare sottoscrizioni e gruppi di gestione per assegnare criteri alle risorse all'interno dei limiti.

Ad esempio, se sono presenti applicazioni pubbliche e private, separarle in sottoscrizioni diverse e inserirle nei gruppi di gestione appropriati denominati Corp e Onlineo in altri gruppi di gestione sotto le zone di destinazione. Le sottoscrizioni presenti all'interno del Corp gruppo di gestione hanno criteri che impediscono la creazione di indirizzi IP pubblici. Le sottoscrizioni in tempo reale sotto i Online gruppi di gestione consentono la connettività Internet e l'accesso pubblico direttamente. Per altre informazioni sui criteri applicati ai diversi livelli di progettazione di una zona di destinazione di Azure, inclusi i criteri specifici di ARO, vedere Criteri inclusi nelle implementazioni di riferimento delle zone di destinazione di Azure.

Considerazioni relative alla progettazione

  • Decidere chi gestirà gli host contenitore:

    • Se gli host sono gestiti centralmente, è possibile ridurre il numero di istanze della zona di destinazione. Richiedere agli sviluppatori di seguire i processi definiti per distribuire gli host e usare dashboard e avvisi condivisi per le operazioni a livello di carico di lavoro.

    • Se i team del carico di lavoro gestiscono gli host, sono necessarie più istanze della zona di destinazione per segmentare gli ambienti host. I team del carico di lavoro possono controllare le distribuzioni.

    • Indipendentemente dal fatto che gli host vengano gestiti centralmente dai team del carico di lavoro, estendere questa considerazione alle risorse adiacenti e correlate, ad esempio web application firewall, insiemi di credenziali delle chiavi, agenti di compilazione della pipeline e potenzialmente jumpbox.

  • Scegliere un modello di tenancy per i cluster:

    • Carico di lavoro gestito dal team, tenant singolo: Un singolo host cluster che supporta un singolo carico di lavoro richiede probabilmente una zona di destinazione dedicata per la segmentazione e il controllo del team del carico di lavoro.

    • Piattaforme tecnologiche, host multi-tenant: Quando gli host sono gestiti centralmente, l'efficienza operativa deriva dal consolidamento di più host e più carichi di lavoro nelle sottoscrizioni di zone di destinazione condivise. Il consolidamento riduce il numero di zone di destinazione e host dedicati al supporto di un singolo cluster o carico di lavoro.

      Potrebbe essere necessario aggiungere sottoscrizioni di zona di destinazione se è necessaria la segmentazione per separare i carichi di lavoro in base all'area, all'unità business, all'ambiente, alla criticità o ad altri vincoli esterni.

      Suggerimento

      Esaminare l'architettura adattare l'architettura della zona di destinazione di Azure per soddisfare i requisiti prima di creare altri gruppi di gestione.

    • Gestito centralmente, tenant singolo: Per carichi di lavoro ostili o regolamentati ancora gestiti centralmente, è comune avere host dedicati per i carichi di lavoro. Per migliorare l'efficienza operativa, è anche possibile consolidare le zone di destinazione di supporto.

  • Scegliere una gerarchia del gruppo di gestione in base alla scalabilità generale e all'allineamento degli ambienti e degli host necessari per supportare i requisiti complessivi del portfolio:

    • Usare una struttura piatta per supportare molti host dedicati in ambienti dedicati per le operazioni decentralizzate eseguite da ogni team del carico di lavoro.
    • Usare una struttura segmentata per creare un gruppo di gestione per gli host gestiti centralmente e un gruppo di gestione separato per le operazioni decentralizzate.
    • Usare una struttura gerarchica per segmentare ulteriormente gli ambienti per riflettere i requisiti di fatturazione, governance o operativi.

  • Decidere quale registro contenitori usare:

  • Decidere quale topologia del registro contenitori usare per la distribuzione degli artefatti OCI (Open Container Initiative):

    • Un registro per ogni carico di lavoro.
    • Un registro per cluster, con più carichi di lavoro nel Registro di sistema.
    • Un registro per tutti i cluster nella zona di destinazione, con più carichi di lavoro e cluster nello stesso registro.
    • Un registro per tutti i cluster in più zone di destinazione, con più carichi di lavoro e cluster nello stesso registro.

  • Decidere l'ambito per i criteri del registro contenitori in Criteri di Azure:

    • Impostare un criterio a livello di sottoscrizione per richiedere a tutti gli host nella zona di destinazione di usare il Registro di sistema definito.
    • Impostare un criterio più granulare a livello di gruppo di risorse.
    • Impostare un criterio più ampio a livello di gruppo di gestione.

Suggerimenti per la progettazione

  • Definire uno standard di denominazione e assegnazione di tag da applicare a tutte le risorse del contenitore distribuite in Azure. Come minimo, lo standard deve includere:
    • Nomi del carico di lavoro: Il carico di lavoro o i carichi di lavoro supportati da ogni cluster.
    • Risorse del cluster: Elevazione dell'allineamento delle risorse del cluster rispetto alle considerazioni precedenti.
    • Operatore host: Quale team è responsabile delle operazioni host.
  • Implementare un criterio per richiedere un registro degli artefatti OCI specifico basato sulla topologia del registro contenitori dell'organizzazione.

Passaggi successivi