Condividi tramite

Distribuire le zone di destinazione di Azure.

Questo articolo descrive le opzioni disponibili per distribuire le zone di destinazione della piattaforma e dell'applicazione. Le zone di destinazione della piattaforma forniscono servizi centralizzati usati dai carichi di lavoro. Le zone di destinazione delle applicazioni sono ambienti distribuiti per i carichi di lavoro stessi.

Importante

Per altre informazioni sulle definizioni e sulle implementazioni per le zone di destinazione della piattaforma rispetto alle zone di destinazione dell'applicazione, vedere Che cos'è una zona di destinazione di Azure?.

Scegliere un approccio alla zona di destinazione della piattaforma

Le opzioni di distribuzione della piattaforma seguenti forniscono un approccio basato su opinioni per distribuire e gestire l'architettura concettuale della zona di destinazione di Azure , come descritto in Cloud Adoption Framework per Azure. L'architettura risultante può variare in base alle personalizzazioni, pertanto potrebbe non essere la stessa per tutte le opzioni di distribuzione elencate in questo articolo. Le differenze tra le opzioni di distribuzione della piattaforma si basano sull'uso di tecnologie, approcci e personalizzazioni diverse.

Opzioni di distribuzione standard

Le opzioni di distribuzione standard consentono di gestire un utilizzo tipico di Azure aziendale.

Opzione di distribuzione della zona di destinazione della piattaforma Azure Descrizione Cloud pubblici di Azure Cloud sovrani di Azure (Governo degli Stati Uniti, 21Vianet e così via).
Distribuzione del portale di Azure La distribuzione basata sul portale di Azure offre un'implementazione completa dell'architettura concettuale della zona di destinazione di Azure e configurazioni con parere per i componenti chiave, ad esempio i gruppi di gestione e i criteri. Sostenuto Non supportato.

Le singole risorse possono essere distribuite con il portale di Azure, ma non come un'esperienza unificata e guidata del portale.
Distribuzione Bicep Una distribuzione modulare basata sull'infrastruttura come codice (IaC), in cui ogni modulo Bicep incapsula una funzionalità di base dell'architettura concettuale della zona di destinazione di Azure. Questi moduli possono essere distribuiti singolarmente, ma la progettazione consiglia di usare i moduli dell'agente di orchestrazione per incapsulare la complessità della distribuzione di topologie diverse con i moduli. Sostenuto Supportato ma richiede modifiche. Consultare la sezione Distribuzioni cloud sovrane di Azure
Distribuzione di Terraform Una distribuzione basata su IaC che usa moduli verificati da Azure per le zone di destinazione della piattaforma e offre un modo personalizzabile per distribuire le zone di destinazione di Azure con Terraform. Sostenuto Supportato ma richiede modifiche. Consultare la sezione Distribuzioni cloud sovrane di Azure

Distribuzioni di cloud sovrani di Azure

Le tre opzioni di distribuzione sono supportate per le offerte di cloud pubblico, globale e commerciale di Azure. Se è necessario eseguire la distribuzione in altri cloud di Azure, ad esempio Azure per enti pubblici o Microsoft Azure gestito da 21Vianet, gli asset di distribuzione richiederanno modifiche di configurazione manuali dal team della piattaforma. Solo le opzioni di distribuzione Bicep & Terraform possono essere modificate per gestire queste modifiche necessarie.

  • Definizioni di Criteri di Azure, iniziative e assegnazioni: non tutti i criteri di Azure sono disponibili in tutti i cloud, quindi è necessario rimuovere i criteri non supportati prima della distribuzione.
  • Versioni api per alcune risorse: alcune versioni api potrebbero non esistere in alcuni cloud, quindi sarà necessario modificare le versioni dell'API delle risorse prima della distribuzione
  • Disponibilità delle risorse: alcune risorse potrebbero non esistere in alcuni cloud, ad esempio i piani di protezione DDoS non sono disponibili in Azure in Cina. Sarà necessario rimuoverli prima della distribuzione.

L'architettura della zona di destinazione di Azure è ancora valida e supportata in tutti i cloud di Azure. Tuttavia, la distribuzione per tale architettura non viene fornita in una soluzione automatizzata che funziona in tutti i cloud. Se si vuole visualizzare il supporto per la distribuzione automatica per questi cloud, richiedere la funzionalità.

Varianti e specializzazioni

Le opzioni di distribuzione della piattaforma standard riguardano l'utilizzo tipico di Azure aziendale, ma alcune opzioni di distribuzione sono incentrate su specializzazioni specifiche. Ad esempio, una zona di destinazione sovrana è una variante della zona di destinazione di Azure progettata per le organizzazioni che richiedono controlli sovrani avanzati.

Implementazioni dei partner

I programmi partner, ad esempio Azure Migrate e Modernize , consentono di progettare e implementare una zona di destinazione della piattaforma specifica per le esigenze dell'organizzazione. Queste implementazioni iniziano con l'architettura concettuale della zona di destinazione di Azure e le configurazioni di progettazione specifiche per la strategia di adozione del cloud, la topologia organizzativa e i risultati desiderati.

Criteri aziendali come codice per la gestione dei criteri

I criteri aziendali come codice (EPAC) sono un metodo alternativo per distribuire, gestire e gestire Criteri di Azure nell'ambiente Azure dell'organizzazione. È possibile usare EPAC anziché le opzioni della piattaforma standard per gestire i criteri in un ambiente di zona di destinazione di Azure. Per altre informazioni sull'approccio di integrazione, vedere Integrare EPAC con le zone di destinazione di Azure.

L'EPAC è più adatto per i clienti di DevOps e IaC più avanzati. Tuttavia, le organizzazioni di qualsiasi scala possono usare EPAC dopo averla valutata. Per altre informazioni, vedere Chi deve usare EPAC?.

Nota

Confrontare il ciclo di vita e la flessibilità dei due approcci prima di decidere quale approccio usare a lungo termine. Per iniziare, valutare la gestione dei criteri nativa nell'implementazione predefinita. Se tale implementazione non soddisfa le esigenze di governance, eseguire un MVP o un modello di verifica usando EPAC. È importante confrontare le opzioni, convalidare i risultati e confermare la scelta prima di implementare un approccio perché è difficile modificare i metodi di governance dei criteri dopo averli stabiliti.

Eseguire le zone di destinazione di Azure

Dopo aver distribuito la zona di atterraggio della piattaforma, è necessario operarla e mantenerla. Per altre informazioni, vedere Mantenere aggiornata la zona di destinazione di Azure.

Visualizzatore di governance di Azure

Il visualizzatore di governance di Azure consente di ottenere una panoramica olistica dell'implementazione della governance tecnica di Azure connettendo i puntini e fornendo report sofisticati.

Vendita di abbonamenti

Dopo che la zona di atterraggio della piattaforma e la strategia di governance sono state stabilite, il passaggio successivo consiste nello stabilire la coerenza nel modo in cui vengono create e gestite operativamente le sottoscrizioni per i proprietari dei carichi di lavoro. La democratizzazione delle sottoscrizioni è un principio di progettazione delle zone di destinazione di Azure che usa le sottoscrizioni come unità di gestione e scalabilità. Questo approccio accelera le migrazioni delle applicazioni e lo sviluppo di nuove applicazioni.

La vendita di sottoscrizioni standardizza il processo che i team della piattaforma utilizzano affinché i team operativi richiedano sottoscrizioni, permettendo ai team della piattaforma di distribuire e gestire tali sottoscrizioni. Consente ai team dell'applicazione di accedere ad Azure in modo coerente e regolamentato, assicurandosi che la raccolta dei requisiti sia completa.

Le organizzazioni spesso hanno vari tipi di abbonamenti che possono essere forniti all'interno del tenant, comunemente definiti linee di prodotto. Per ulteriori informazioni, vedere Stabilire linee di prodotto comuni per la gestione automatica delle sottoscrizioni.

Per iniziare, seguire le linee guida per l'implementazione della distribuzione automatica delle sottoscrizioni. Esaminare quindi i moduli IaC seguenti, che offrono flessibilità per soddisfare le esigenze di implementazione.

Opzioni di distribuzione Descrizione
Vendita di abbonamenti Bicep I moduli Bicep di gestione delle sottoscrizioni sono progettati per orchestrare la distribuzione delle singole zone di atterraggio dell'applicazione basate sulla configurazione di ciascun carico di lavoro. Possono essere eseguite manualmente o come parte del processo di automazione.
Vendita di abbonamenti Terraform I moduli usano Terraform per orchestrare la distribuzione delle singole zone di destinazione dell'applicazione.

Architetture della zona di destinazione delle applicazioni

Le zone di destinazione dell'applicazione sono aree designate all'interno di una o più sottoscrizioni, configurate in modo specifico come destinazioni approvate per le risorse gestite dai team dell'applicazione per un carico di lavoro specifico. Un carico di lavoro può sfruttare i servizi nelle aree di atterraggio della piattaforma o rimanere isolato da quelle risorse centralizzate. Usare le zone di destinazione delle applicazioni per applicazioni gestite centralmente, carichi di lavoro decentralizzati di proprietà dei team delle applicazioni e piattaforme di hosting gestite centralmente, ad esempio il servizio Azure Kubernetes che potrebbe ospitare applicazioni per più business unit. A meno che non siano vincolate da circostanze insolite, le sottoscrizioni della zona di atterraggio dell'applicazione in genere includono risorse provenienti da un solo carico di lavoro o confine logico dell'applicazione, come il suo ciclo di vita o la classificazione della criticità.

I team del carico di lavoro comunicano i requisiti del carico di lavoro tramite un processo formale stabilito dal team della piattaforma. Il team della piattaforma distribuisce in genere una sottoscrizione vuota che include tutte le regole di gestione richieste. Un progettista del carico di lavoro progetta quindi una soluzione che funziona entro i vincoli della zona di destinazione dell'applicazione e sfrutta le funzionalità della piattaforma condivisa, ad esempio firewall e routing cross-premise, quando pratico.

È possibile che un architetto adatti un'architettura di riferimento non progettata in modo specifico con una zona di atterraggio dell'applicazione in mente. Tuttavia, Microsoft Learn contiene anche linee guida sulle applicazioni e sulla piattaforma dati per i team di lavoro che indicano in modo specifico i contesti della zona di destinazione dell'applicazione. Rendere i team della piattaforma consapevoli delle indicazioni disponibili per i team del carico di lavoro in modo che il team della piattaforma possa prevedere i tipi di carico di lavoro e le caratteristiche che potrebbero trovarsi nell'organizzazione.

Architettura della zona di destinazione dell'applicazione Descrizione
Ambiente del servizio app di Azure Raccomandazioni e considerazioni comprovate sia nei casi d'uso multi-tenant che nell'ambiente del servizio app con un'implementazione di riferimento.
Gestione API di Azure Raccomandazioni e considerazioni comprovate per la distribuzione di un'istanza di Gestione API interna come parte di un'implementazione di riferimento. Lo scenario utilizza Azure Application Gateway per fornire un controllo di accesso sicuro e utilizza le Funzioni di Azure come back-end.
Azure Arc per scenari ibridi e multicloud Linee guida per server, Kubernetes e Istanza gestita di SQL di Azure abilitata da Azure Arc.
App azure Container Linee guida che delineano il percorso di progettazione strategico e definiscono lo stato tecnico desiderato per l'implementazione di applicazioni container. Un team dedicato alla gestione del carico di lavoro possiede e gestisce questa piattaforma.
Azure Data Factory Indicazioni su come ospitare un medallion lakehouse all'interno di una zona di atterraggio dell'applicazione.
Chat workload di Azure AI Foundry Linee guida su come integrare un'architettura tipica di chat di Azure AI Foundry all'interno delle zone di destinazione di Azure per usare risorse condivise centralizzate rispettando al contempo la governance e l'efficienza dei costi. Fornisce indicazioni per i team del carico di lavoro sulla distribuzione e la gestione.
AKS (Servizio Azure Kubernetes) Linee guida e modelli IaC correlati che rappresentano il percorso di progettazione strategico e lo stato tecnico desiderato per una distribuzione del servizio Azure Kubernetes eseguita all'interno di una zona di sbarco dell'applicazione.
Azure Red Hat OpenShift Raccolta open source di modelli Terraform che rappresentano una distribuzione ottimale di Azure Red Hat OpenShift che include risorse di Azure e Red Hat.
Azure Synapse Analytics Approccio architetturale per preparare le zone di destinazione delle applicazioni per una distribuzione aziendale tipica di Azure Synapse Analytics.
Azure Desktop virtuale Modelli di Azure Resource Manager (ARM), Bicep e Terraform a cui è consigliabile fare riferimento quando si progettano distribuzioni di Desktop virtuale Azure, che include la creazione di pool di host, rete, archiviazione, monitoraggio e componenti aggiuntivi.
Macchine virtuali di Azure Architettura che estende le linee guida dall'architettura di base delle macchine virtuali a una zona di destinazione dell'applicazione. Fornisce indicazioni sulla configurazione della sottoscrizione, sulla conformità delle patch e su altri problemi di governance dell'organizzazione.
Soluzione Azure VMware Modelli ARM, Bicep e Terraform che è possibile usare per progettare distribuzioni di soluzioni Azure VMware. Queste distribuzioni includono il cloud privato della soluzione Azure VMware, il jump box, la rete, il monitoraggio e i componenti aggiuntivi.
Citrix in Azure Linee guida di progettazione per il "Cloud Adoption Framework" per Citrix Cloud in un'area di atterraggio di Azure su scala aziendale che include molte aree di progettazione.
Red Hat Enterprise Linux (RHEL) in Azure Raccolta open source di indicazioni sull'architettura e consigli di implementazione di riferimento che è possibile usare per progettare carichi di lavoro basati su RHEL in Microsoft Azure.
Carichi di lavoro HPC (High Performance Compute) Soluzione cluster HPC end-to-end in Azure che usa strumenti come Terraform, Ansible e Packer. Risolve le procedure consigliate per la zona di atterraggio di Azure, che includono la gestione delle identità, l'accesso tramite jump box e la scalabilità automatica.
Carichi di lavoro cruciali Descrive come progettare un carico di lavoro cruciale per l'esecuzione all'interno di una zona di destinazione dell'applicazione.
Carichi di lavoro SAP Fornisce indicazioni e consigli per i carichi di lavoro SAP allineati alle procedure consigliate per la zona di destinazione di Azure. Fornisce consigli su come creare componenti dell'infrastruttura come calcolo, rete, archiviazione, monitoraggio e compilazione di sistemi SAP.

I carichi di lavoro sono spesso costituiti da varie tecnologie e classificazioni. È consigliabile esaminare i materiali di riferimento correlati per tutte le tecnologie nel carico di lavoro. Ad esempio, comprendere le indicazioni della chat e di Gestione API di Azure OpenAI è fondamentale per determinare se lo scenario di intelligenza artificiale generativa può trarre vantaggio dall'incorporamento di un gateway API.

Passo successivo