Informazioni su Azure Resource Manager

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, vedere Panoramica dei modelli di ARM. Per informazioni su Bicep, vedere Panoramica di Bicep.

Il video seguente illustra i concetti di base di Azure Resource Manager.

Livello di gestione coerente

Quando si invia una richiesta tramite qualsiasi API, strumento o SDK di Azure, Resource Manager riceve la richiesta. Autentica 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.

Diagramma che mostra il ruolo di Azure Resource Manager nella gestione delle richieste di Azure.

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 entro l'autunno 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 da gestire come gruppo. Si decide quali risorse appartengono a un gruppo di risorse in base alle esigenze dell'organizzazione. Vedere Che cos'è un gruppo di risorse?
  • Provider di risorse: un servizio che offre 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: sintassi che consente di indicare l'oggetto da creare senza dover scrivere la sequenza di comandi di programmazione per crearlo. I modelli di ARM e i file Bicep sono esempi di sintassi dichiarativa. In questi file si definiscono le proprietà dell'infrastruttura da distribuire in Azure.
  • modello di 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.
  • risorsa di estensione: risorsa che aggiunge alle funzionalità di un'altra risorsa. Ad esempio, un'assegnazione di ruolo è una risorsa di estensione. Si applica un'assegnazione di ruolo a qualsiasi altra risorsa per specificare l'accesso. Vedere Risorse di estensione

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 di gestione: gruppi di gestione, sottoscrizioni, gruppi di risorse e risorse. La figura seguente illustra un esempio di questi livelli.

Diagramma che illustra i quattro livelli di ambito in Azure: gruppi di gestione, sottoscrizioni, gruppi di risorse e risorse.

Le impostazioni di gestione vengono applicate a uno qualsiasi di questi livelli di ambito. Il livello selezionato determina la portata dell'applicazione dell'impostazione. I livelli inferiori ereditano le impostazioni da quelli 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. Il criterio non viene invece applicato a un altro gruppo di risorse.

Per informazioni sulla gestione delle identità e dell'accesso, vedere Microsoft Entra ID.

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

Che cos'è un gruppo di risorse?

Un gruppo di risorse è un contenitore che consente di gestire le risorse correlate per una soluzione di Azure. Usando il gruppo di risorse, è possibile coordinare le modifiche alle risorse correlate. Ad esempio, è possibile distribuire un aggiornamento al gruppo di risorse e assicurare che le risorse vengano aggiornate in un'operazione coordinata. Oppure, una volta terminato l'uso della soluzione, è possibile eliminare il gruppo di risorse e assicurare che tutte le risorse vengano eliminate.

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 rispetto al gruppo di risorse, ma è consigliabile usare la stessa posizione. Vedere Quale località usare per il gruppo di risorse?

  • 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 relativi ai gruppi 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.

Quale località è consigliabile usare per il gruppo di risorse?

Quando si crea un gruppo di risorse è necessario specificarne il percorso.

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à può essere necessario garantire che i dati vengano 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. Quando si seleziona una posizione per il gruppo di risorse, è consigliabile selezionare una località vicina alla posizione in cui hanno origine le operazioni di controllo. In genere, questa località è 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 è temporaneamente non disponibile, potrebbe non essere possibile aggiornare le risorse nel gruppo perché i metadati non sono disponibili. Le risorse in altre aree funzionano ancora come previsto, ma potrebbe non essere possibile aggiornarle. Questa condizione può anche essere applicabile alle risorse globali, ad esempio DNS di Azure, Zone private di DNS di Azure, Gestione traffico di Azure e Frontdoor di Azure. È possibile visualizzare i tipi con i relativi metadati gestiti da Azure Resource Manager tramite l'elenco di tipi per la tabella delle risorse di Azure Resource Graph.

Per ridurre l'impatto delle interruzioni a livello di area, è consigliabile individuare le risorse nella stessa area del gruppo di risorse. Quando l'area del gruppo di risorse non è disponibile, Azure Resource Manager non è in grado di aggiornare i metadati della risorsa e blocca le chiamate di scrittura. Usando la stessa posizione per risorsa e gruppo di risorse, si riduce il rischio di indisponibilità dell'area perché le risorse e i metadati esistono in un'unica area anziché in più aree.

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

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. Azure Resource Manager ha un'istanza separata in ogni area di Azure, quindi un errore dell'istanza di Azure Resource Manager in un'area non influisce sulla disponibilità di Azure Resource Manager o di altri servizi di Azure in un'altra area. Anche se Azure Resource Manager è distribuito tra aree, alcuni servizi sono a livello di singola 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 viene inoltrata al servizio.

  • Sono distribuite tra le zone di disponibilità (e tra le aree) in località con più zone di disponibilità. Questa distribuzione assicura che quando un'area perde una o più zone, Azure Resource Manager può eseguire il failover in un'altra zona o in un'altra area per continuare a fornire funzionalità del piano di controllo per le risorse.

  • 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.

Risolvere le operazioni simultanee

Quando due o più operazioni tentano di aggiornare contemporaneamente la stessa risorsa, Azure Resource Manager rileva il conflitto e consente di completare correttamente una sola operazione. Azure Resource Manager blocca le altre operazioni e restituisce un errore.

Gli aggiornamenti simultanei delle risorse possono causare risultati imprevisti. Questa risoluzione assicura che gli aggiornamenti siano deterministici e affidabili. Si conosce lo stato delle risorse e si evitano eventuali incoerenze o perdite di dati.

Si supponga di avere due richieste (A e B) che tentano di aggiornare contemporaneamente la stessa risorsa. Se la richiesta A viene completata prima della richiesta B, la richiesta A ha esito positivo e la richiesta B ha esito negativo. La richiesta B restituisce l'errore 409. Dopo aver ottenuto il codice di errore, è possibile ottenere lo stato aggiornato della risorsa e determinare se si vuole inviare nuovamente la richiesta B.

Passaggi successivi