Che cos'è Azure Blueprints (anteprima)?

Importante

Azure Blueprints (anteprima) verrà ritirata il 31 gennaio 2027, con un ritiro graduale a partire dal 31 luglio 2026. Esegui la migrazione delle definizioni e assegnazioni dei blueprint esistenti a stack di distribuzione (consigliato) e Specifiche modello. Gli artefatti del progetto vengono convertiti in modelli JSON ARM o Bicep file usati per definire gli stack di distribuzione. Per le tempistiche complete, l'impatto e le domande frequenti, vedi ritiro di Azure Blueprints o https://aka.ms/AzureBlueprintsRetirement. Per informazioni su come creare un artefatto come risorsa ARM, vedere:

Così come un progetto consente a un ingegnere o un architetto di tracciare i parametri di progettazione, Azure Blueprints consente agli architetti cloud e ai gruppi centrali del reparto IT di definire un set ripetibile di risorse di Azure che implementa ed è conforme a standard, criteri e requisiti di un'organizzazione. Azure Blueprints consente ai team di sviluppo di creare e avviare rapidamente nuovi ambienti sapendo che vengono creati in conformità con l'organizzazione con un set di componenti integrati, ad esempio reti, per velocizzare lo sviluppo e il recapito.

I progetti costituiscono un metodo dichiarativo per orchestrare la distribuzione di vari modelli di risorse e altri artefatti, ad esempio:

  • Assegnazioni di ruolo
  • Assegnazioni di criteri
  • Modelli di Azure Resource Manager (modelli ARM)
  • Gruppi di risorse

Il servizio Azure Blueprints è supportato da Azure Cosmos DB distribuito a livello globale. Gli oggetti di Blueprints vengono replicati in più aree di Azure. Questa replica fornisce bassa latenza, disponibilità elevata e accesso ininterrotto agli oggetti del progetto, indipendentemente dall'area in cui Azure Blueprints distribuisce le risorse.

Differenze rispetto ai modelli ARM

Il servizio è progettato per facilitare la configurazione dell'ambiente. Questa configurazione spesso comprende una serie di gruppi di risorse, criteri, assegnazioni di ruolo e distribuzioni di modelli ARM. Un progetto è un pacchetto che raggruppa tutti questi tipi di artefatti e consente di comporre e controllare la versione di tale pacchetto, anche tramite una pipeline di integrazione continua e distribuzione continua (CI/CD). In definitiva, ognuno viene assegnato a una sottoscrizione in una singola operazione che può essere controllata e monitorata.

Quasi tutto ciò che si desidera includere per la distribuzione in Azure Blueprints può essere realizzato con un modello ARM. Tuttavia, un modello ARM è un documento che non esiste in modo nativo in Azure: ognuno viene archiviato localmente, in un sistema di controllo del codice sorgente oppure in Templates (preview). Il modello viene usato per le distribuzioni di una o più risorse di Azure ma, al completamento delle distribuzioni, non rimane una connessione o una relazione attiva con il modello.

Con Azure Blueprints viene mantenuta la relazione tra la definizione del progetto (cosa distribuire) e l'assegnazione del progetto (cosa è stato distribuito). Questa connessione supporta un migliore monitoraggio e controllo delle distribuzioni. Azure Blueprints può anche aggiornare più sottoscrizioni contemporaneamente regolate dallo stesso progetto.

Non è necessario scegliere tra un modello ARM e un blueprint. Ogni blueprint può essere composto da zero o più artefatti del modello ARM. Questo supporto significa che i precedenti sforzi per sviluppare e mantenere una libreria di modelli ARM possono essere riutilizzati in Azure Blueprints.

In che cosa si differenzia da Criteri di Azure

Un progetto è un pacchetto o un contenitore per la composizione di specifici set di standard, criteri e requisiti correlati all'implementazione dei servizi cloud, della sicurezza e della progettazione di Azure, che può essere riutilizzato per garantire coerenza e conformità.

I criteri costituiscono un sistema predefinito di autorizzazione e negazione esplicita che mira alle proprietà delle risorse durante la distribuzione e viene usato per le risorse già esistenti. Supporta la governance del cloud verificando che le risorse in una sottoscrizione siano conformi a requisiti e standard.

L'inclusione di criteri in un progetto consente di creare il modello o il motivo corretto durante l'assegnazione del progetto stesso L'inclusione del criterio garantisce che nell'ambiente possano essere apportate solo le modifiche approvate o previste, in modo da proteggere la conformità continua all'intento del blueprint.

Un criterio può essere incluso come uno dei numerosi artefatti in una definizione di blueprint. Blueprints supporta anche l'uso di parametri con criteri e iniziative.

Definizione di progetto

Un blueprint è composto da artefatti. Azure Blueprints supporta attualmente le risorse seguenti come artefatti:

Conto risorse Opzioni della gerarchia Descrizione
Gruppi di risorse Abbonamento Creare un nuovo gruppo di risorse per l'uso da parte di altri artefatti nel progetto. Questi gruppi di risorse segnaposto consentono di organizzare le risorse esattamente come desiderato e forniscono un limite di ambito per i criteri inclusi, gli artefatti di assegnazione dei ruoli e i modelli ARM.
Modello ARM Sottoscrizione, gruppo di risorse Vengono usati modelli, inclusi quelli annidati e collegati, per comporre ambienti complessi. Esempi di ambienti: una farm di SharePoint, Automazione di Azure State Configuration o un'area di lavoro di Log Analytics.
Assegnazione dei criteri Sottoscrizione, gruppo di risorse Consente di assegnare criteri o iniziative alla sottoscrizione a cui è assegnato il progetto. I criteri o le iniziative devono trovarsi nell'ambito della posizione della definizione di progetto. Se i criteri o le iniziative includono dei parametri, questi vengono assegnati al momento della creazione del progetto o durante l'assegnazione dello stesso.
Assegnazione di ruolo Sottoscrizione, gruppo di risorse Aggiungere un utente o gruppo esistente a un ruolo predefinito per assicurarsi che gli utenti corretti possano sempre accedere correttamente alle risorse. Le assegnazioni di ruolo possono essere definite per l'intera sottoscrizione o annidate in un gruppo di risorse specifiche incluso nel progetto.

Nota

Ogni artefatto deve essere di 2 MB o meno. Se l'artefatto supera 2 MB, verrà visualizzato un errore HTTP 500 (errore interno del server).

Posizioni delle definizioni di progetto

Durante la creazione di una definizione di blueprint, definirai dove viene salvato il blueprint. I progetti possono essere salvati in un gruppo di gestione o una sottoscrizione a cui si ha accesso come collaboratore. Se l'ambito è un gruppo di gestione, il blueprint può essere assegnato a qualsiasi sottoscrizione figlia di tale gruppo di gestione.

Parametri di progetto

I blueprint possono passare parametri a una policy/iniziativa oppure a un modello ARM. Quando si aggiunge un artefatto a un progetto, l'autore decide se fornire un valore definito per ogni assegnazione di progetto o se consentire a ogni assegnazione di progetto di fornire un valore in fase di assegnazione. Questa flessibilità consente di definire un valore predeterminato per tutti gli usi del progetto o per consentire che tale decisione venga presa al momento dell'assegnazione.

Nota

Un progetto può avere i propri parametri, ma al momento questi possono essere creati solo se un progetto è generato dall'API REST anziché tramite il portale.

Per altre informazioni, vedere Parametri di progetto.

Pubblicazione dei blueprint

Quando si crea un progetto per la prima volta, questo viene considerato in modalità bozza. Quando è pronto per l'assegnazione, deve essere pubblicato. La pubblicazione richiede la definizione di una stringa versione (lettere, numeri e trattini con una lunghezza massima di 20 caratteri) insieme a note di modifica facoltative. La stringa versione consente di distinguere il progetto dalle modifiche future apportate allo stesso e di assegnare ciascuna versione. Questo controllo delle versioni significa anche che è possibile assegnare diverse versioni dello stesso progetto alla stessa sottoscrizione. Quando al progetto vengono apportate altre modifiche, la versionepubblicata è ancora presente, così come le modifiche non pubblicate. Una volta ultimate le modifiche, il progetto aggiornato viene pubblicato con una nuova versione univoca e può essere ora assegnato.

Assegnazione progetto

Ogni versionepubblicata di un progetto può essere assegnata (con un nome contenente al massimo 90 caratteri) a un gruppo di gestione o a una sottoscrizione esistente. Nel portale il progetto imposta la versionepubblicata più di recente come predefinita. Se sono presenti parametri di artefatto o parametri di progetto, questi vengono definiti durante il processo di assegnazione.

Nota

L'assegnazione di una definizione di progetto a un gruppo di gestione indica l'esistenza dell'oggetto di assegnazione nel gruppo di gestione. La distribuzione degli artefatti ha ancora come destinazione una sottoscrizione. Per eseguire un'assegnazione di un gruppo di gestione, è necessario usare l'API REST Create o Update e il corpo della richiesta deve includere un valore per properties.scope per definire la sottoscrizione di destinazione.

Autorizzazioni in Azure Blueprint

Gestisci le autorizzazioni di Blueprint tramite il controllo degli accessi in base al ruolo di Azure (Azure RBAC).

Per leggere o visualizzare una definizione di blueprint, non è necessaria un'autorizzazione dedicata di Azure RBAC. Le definizioni di blueprint sono concepite per essere individuabili dalle entità di sicurezza a cui si applicano, in modo che qualsiasi entità di sicurezza autenticata nel tenant possa elencare e leggere le definizioni di blueprint con ambito del gruppo di gestione, le relative versioni e i relativi artefatti, anche tramite l'API REST, persino senza un'assegnazione di ruolo a tale gruppo di gestione. La lettura di una definizione di progetto archiviata in una sottoscrizione richiede l'accesso in lettura a tale sottoscrizione. La creazione, la pubblicazione, l'assegnazione, l'aggiornamento e l'eliminazione di progetti richiedono sempre le autorizzazioni descritte in questo articolo.

Importante

Poiché qualsiasi entità autenticata nel tenant può leggere le definizioni di progetto, non archiviare segreti o altre informazioni riservate direttamente in una definizione di progetto o nel relativo parametro defaultValue. Per i segreti, usare secureString o secureObject parametri supportati da riferimenti Azure Key Vault, che mantengono il valore del segreto in Key Vault anziché nel progetto.

Per creare i progetti l'account necessita delle seguenti autorizzazioni:

  • Microsoft.Blueprint/blueprints/write - Creare una definizione di progetto
  • Microsoft.Blueprint/blueprints/artifacts/write - Creare artefatti su una definizione di progetto
  • Microsoft.Blueprint/blueprints/versions/write - Pubblicare un progetto

Per eliminare i blueprint, il tuo account deve disporre delle seguenti autorizzazioni:

  • Microsoft.Blueprint/blueprints/delete
  • Microsoft.Blueprint/blueprints/artifacts/delete
  • Microsoft.Blueprint/blueprints/versions/delete

Nota

Le autorizzazioni per la definizione del blueprint devono essere concesse o ereditate a livello del gruppo di gestione o della sottoscrizione in cui la definizione viene salvata.

Per assegnare o annullare l'assegnazione di un progetto l'account necessita delle seguenti autorizzazioni:

  • Microsoft.Blueprint/blueprintAssignments/write - Assegna un progetto di base
  • Microsoft.Blueprint/blueprintAssignments/delete - Annullare l'assegnazione di un progetto

Nota

Poiché le assegnazioni del blueprint vengono create nell'ambito di una sottoscrizione, le autorizzazioni di assegnazione e rimozione dell'assegnazione del blueprint devono essere concesse nell'ambito della sottoscrizione o essere ereditate a tale ambito.

Sono disponibili i ruoli predefiniti seguenti:

Ruolo di Azure Descrizione
Proprietario Oltre ad altre autorizzazioni, include tutte le autorizzazioni correlate ad Azure Blueprints.
Collaboratore Oltre ad altre autorizzazioni, può creare ed eliminare definizioni di progetto, ma non ha le autorizzazioni per l'assegnazione di progetti.
Collaboratore di progetto Può gestire le definizioni di progetto, ma non assegnarle.
Operatore di progetto Può assegnare i progetti pubblicati esistenti, ma non può creare nuove definizioni di progetto. L'assegnazione di progetti funziona solo se viene eseguita con un'identità gestita assegnata dall'utente.

Se questi ruoli predefiniti non soddisfano specifiche esigenze di sicurezza, provare a creare un ruolo personalizzato.

Nota

Se si utilizza un'identità gestita assegnata al sistema, per poter abilitare la distribuzione l'entità servizio per Azure Blueprint richiede il ruolo proprietario nella sottoscrizione assegnata. Se si usa il portale, questo ruolo viene automaticamente concesso e revocato per la distribuzione. Se si usa l'API REST, questo ruolo deve essere concesso manualmente, ma viene comunque revocato automaticamente al termine della distribuzione. Se si usa un'identità gestita assegnata dall'utente, solo l'utente che crea l'assegnazione del progetto necessita dell'autorizzazione Microsoft.Blueprint/blueprintAssignments/write, inclusa nei ruoli predefiniti Proprietario e Operatore di progetto.

Limiti di denominazione

Per determinati campi, esistono le limitazioni seguenti:

Oggetto Campo Caratteri consentiti Massimo. Durata
Progetto Nome lettere, numeri, trattini e caratteri di sottolineatura 48
Progetto Versione lettere, numeri, trattini e punti 20
Assegnazione progetto Nome lettere, numeri, trattini e caratteri di sottolineatura 90
Artefatto del progetto Nome lettere, numeri, trattini e punti 48

Video introduttivo

La panoramica seguente di Azure Blueprints deriva da Azure Fridays. Per il download del video, visitare Azure Fridays - Panoramica di Azure Blueprints su Channel 9.

Dismissione di Azure Blueprints

Azure Blueprints (anteprima) è in fase di ritiro il 31 gennaio 2027, con un ritiro graduale a partire dal 31 luglio 2026. Esegui la migrazione delle definizioni e delle assegnazioni dei blueprint a Azure Deployment Stacks (consigliato) e template specs prima della data di ritiro. Per indicazioni sulla sequenza temporale, sull'impatto e sulla migrazione in più fasi, vedere:

Passaggi successivi

  • Last updated on