Informazioni su Azure Resource Manager

  • Articolo

Azure Resource Manager è il servizio di distribuzione e gestione di Azure. Fornisce un livello di gestione che consente di creare, aggiornate ed eliminare risorse nell'account Azure. È possibile usare funzionalità di gestione, come il controllo di accesso, i blocchi e i tag, per proteggere e organizzare le risorse dopo la distribuzione.

Per informazioni sui modelli di Azure Resource Manager (modelli di Resource Manager), vedere panoramica del modello di Resource Manager. Per informazioni su Bicep, vedere Panoramica di Bicep.

Livello di gestione coerente

Quando si invia una richiesta tramite una delle API, degli strumenti o degli SDK di Azure, Resource Manager riceve la richiesta. Esegue l'autenticazione e autorizza la richiesta prima di inoltrarla al servizio di Azure appropriato. Poiché tutte le richieste vengono gestite tramite la stessa API, i risultati e le funzionalità risultano coerenti in tutti i vari strumenti.

La figura seguente illustra il ruolo di Azure Resource Manager nella gestione delle richieste di Azure.

Modello di richiesta di Resource Manager

Tutte le funzionalità disponibili nel portale sono disponibili anche tramite PowerShell, l'interfaccia della riga di comando di Azure, le API REST e gli SDK client. Le funzionalità inizialmente rilasciate tramite API vengono rappresentate nel portale entro 180 giorni dal rilascio iniziale.

Importante

Azure Resource Manager supporterà solo Transport Layer Security (TLS) 1.2 o versione successiva per fall 2023. Per altre informazioni, vedere Migrazione a TLS 1.2 per Azure Resource Manager.

Terminologia

Se non si ha esperienza con Azure Resource Manager, ecco alcuni termini con cui acquisire familiarità.

  • risorsa : elemento gestibile disponibile tramite Azure. Sono ad esempio risorse le macchine virtuali, gli account di archiviazione, le app Web, i database e le reti virtuali. Anche i gruppi di risorse, le sottoscrizioni, i gruppi di gestione e i tag sono esempi di risorse.
  • gruppo di risorse : contenitore con risorse correlate per una soluzione Azure. Il gruppo di risorse include le risorse che si vogliono gestire come gruppo. L'utente decide quali risorse appartengono a un gruppo in base alle esigenze specifiche dell'organizzazione. Vedere Gruppi di risorse.
  • provider di risorse: servizio che fornisce le risorse di Azure. Un provider di risorse comune è ad esempio Microsoft.Compute, che fornisce la risorsa macchina virtuale. Microsoft.Storage è un altro provider di risorse comune. Vedere Provider e tipi di risorse.
  • sintassi dichiarativa: la sintassi che consente di stato "Ecco cosa intendo creare" senza dover scrivere la sequenza di comandi di programmazione per crearla. I modelli di Resource Manager e i file Bicep sono esempi di sintassi dichiarativa. In questi file vengono definite le proprietà per l'infrastruttura da distribuire in Azure.
  • Modello arm : file JSON (JavaScript Object Notation) che definisce una o più risorse da distribuire in un gruppo di risorse, una sottoscrizione, un gruppo di gestione o un tenant. Il modello può essere usato per distribuire le risorse in modo coerente e ripetuto. Vedere Panoramica della distribuzione di modelli.
  • File Bicep: file per la distribuzione dichiarativa delle risorse di Azure. Bicep è un linguaggio progettato per offrire la migliore esperienza di creazione per l'infrastruttura come soluzioni di codice in Azure. Vedere Panoramica di Bicep.

Per altre definizioni della terminologia di Azure, vedere Concetti fondamentali di Azure.

Vantaggi dell'utilizzo di Gestione risorse

Con Resource Manager è possibile:

  • Gestire l'infrastruttura tramite modelli dichiarativi, invece che con script.

  • Distribuire, gestire e monitorare tutte le risorse per la soluzione come un gruppo, invece di gestire singolarmente tali risorse.

  • Distribuire ripetutamente la soluzione nel corso del ciclo di vita dello sviluppo con la certezza che le risorse vengano distribuite in uno stato coerente.

  • Definire le dipendenze tra risorse in modo che vengano distribuite nell'ordine corretto.

  • Applicare il controllo di accesso a tutti i servizi, perché il controllo degli accessi in base al ruolo di Azure è integrato in modo nativo nella piattaforma di gestione.

  • Applicare tag a tutte risorse per organizzarle in modo logico nella sottoscrizione.

  • Ottenere informazioni dettagliate sulla fatturazione per l'organizzazione visualizzando i costi di un gruppo di risorse che condividono lo stesso tag.

Informazioni sull'ambito

Azure offre quattro livelli relativi all'ambito: gruppi di gestione, sottoscrizioni, gruppi di risorse e risorse. Nella figura seguente viene illustrato un esempio di questi livelli.

Livelli di gestione

Le impostazioni di gestione possono essere applicate a qualsiasi di questi livelli di ambito. Il livello selezionato determina l'estensione con cui viene applicata l'impostazione. I livelli inferiori ereditano le impostazioni dai livelli superiori. Ad esempio, quando si applicano criteri alla sottoscrizione, tali criteri vengono applicati a tutti i gruppi di risorse e le risorse nella sottoscrizione. Quando si applicano criteri al gruppo di risorse, questi criteri vengono applicati al gruppo di risorse e a tutte le risorse che contiene. Tuttavia, un altro gruppo di risorse non disporrà di tale assegnazione di criteri.

Per informazioni sulla gestione delle identità e dell'accesso, vedere Azure Active Directory.

È possibile distribuire i modelli in tenant, gruppi di gestione, sottoscrizioni o gruppi di risorse.

Gruppi di risorse

Esistono alcuni fattori importanti da considerare quando si definisce il gruppo di risorse:

  • Tutte le risorse del gruppo di risorse devono condividere lo stesso ciclo di vita. Le risorse vengono distribuite, aggiornate ed eliminate insieme. Se una risorsa, ad esempio un server, deve esistere in un ciclo di distribuzione diverso, deve essere inclusa in un altro gruppo di risorse.

  • Ogni risorsa può appartenere a un solo gruppo di risorse.

  • È possibile aggiungere o rimuovere una risorsa in un gruppo di risorse in qualsiasi momento.

  • È possibile spostare una risorsa da un gruppo di risorse a un altro. Per altre informazioni, vedere Spostare le risorse in un gruppo di risorse o una sottoscrizione nuovi.

  • Le risorse in un gruppo di risorse possono trovarsi in aree diverse del gruppo.

  • Quando si crea un gruppo di risorse, è necessario fornire una posizione per tale gruppo di risorse.

    Perché un gruppo di risorse necessita di un percorso? E se le risorse possono avere percorsi diversi rispetto al gruppo di risorse, perché il percorso del gruppo di risorse è importante?

    Il gruppo di risorse archivia i metadati delle risorse. Quando si specifica una posizione per il gruppo di risorse, si specifica dove vengono archiviati tali metadati. Per motivi di conformità potrebbe essere necessario assicurarsi che i dati siano archiviati in una determinata area.

    Per garantire la coerenza dello stato per il gruppo di risorse, tutte le operazioni del piano di controllo vengono instradate attraverso la posizione del gruppo di risorse. Quando si seleziona una posizione del gruppo di risorse, è consigliabile selezionare una posizione vicina alla posizione in cui originano le operazioni di controllo. In genere, questa posizione è quella più vicina alla posizione corrente. Questo requisito di routing si applica solo alle operazioni del piano di controllo per il gruppo di risorse. Non influisce sulle richieste inviate alle applicazioni.

    Se l'area di un gruppo di risorse non è temporaneamente disponibile, non è possibile aggiornare le risorse nel gruppo di risorse perché i metadati non sono disponibili. Le risorse in altre aree continueranno a funzionare come previsto, ma non è possibile aggiornarle. Questa condizione non si applica alle risorse globali, ad esempio Rete distribuzione contenuto di Azure, DNS di Azure, Zone private DNS di Azure, Gestione traffico di Azure e Frontdoor di Azure.

    Per altre informazioni su come creare applicazioni affidabili, vedere Progettazione di applicazioni Azure affidabili.

  • Un gruppo di risorse consente di definire l'ambito di controllo di accesso per operazioni amministrative. Per gestire un gruppo di risorse, è possibile assegnare Criteri di Azure, ruoli di Azure o blocchi delle risorse.

  • È possibile applicare tag a un gruppo di risorse. Le risorse nel gruppo di risorse non ereditano tali tag.

  • Una risorsa può connettersi a risorse in altri gruppi di risorse. Questo scenario è comune quando le due risorse sono correlate ma non condividono lo stesso ciclo di vita. Ad esempio, è possibile avere un'app Web che si connette a un database in un gruppo di risorse diverso.

  • Quando si elimina un gruppo di risorse, verranno eliminate anche tutte le risorse presenti nel gruppo. Per informazioni sul modo in cui Azure Resource Manager orchestra tali eliminazioni, vedere Eliminazione di risorse e gruppi di risorse di Azure Resource Manager.

  • In ogni gruppo di risorse è possibile distribuire fino a 800 istanze di un tipo di risorsa. Alcuni tipi di risorse non sono soggetti al limite di 800 istanze. Per altre informazioni, vedere Limiti del gruppo di risorse.

  • Alcune risorse possono esistere all'esterno di un gruppo di risorse. Queste risorse vengono distribuite nella sottoscrizione, nel gruppo di gestione o nel tenant. In questi ambiti sono supportati solo tipi di risorse specifici.

  • Per creare un gruppo di risorse, è possibile usare il portale, PowerShell, l'interfaccia della riga di comando di Azure o un modello di Resource Manager.

Resilienza di Azure Resource Manager

Il servizio Azure Resource Manager è progettato per la resilienza e la disponibilità continua. Le operazioni a livello di Resource Manager e di piano di controllo (richieste inviate a management.azure.com) nell'API REST presentano le caratteristiche seguenti:

  • Sono distribuite tra le aree. Sebbene l'Resource Manager di Azure sia distribuito tra aree, alcuni servizi sono a livello di area. Questa distinzione significa che, mentre la gestione iniziale dell'operazione del piano di controllo è resiliente, la richiesta può essere soggetta a interruzioni a livello di area quando inoltrata al servizio.

  • Distribuito in zone di disponibilità (e aree) in posizioni con più zone di disponibilità.

  • Non dipendono da un singolo data center logico.

  • Non vengono mai disattivate per attività di manutenzione.

Questa resilienza si applica ai servizi che ricevono le richieste tramite Resource Manager. Key Vault, ad esempio, usufruisce di questa resilienza.

Passaggi successivi