Creare e usare i moduli Bicep

Completato

I moduli sono file Bicep indipendenti. In genere contengono set di risorse distribuite insieme. I moduli possono essere utilizzati da qualsiasi altro modello Bicep.

Usando i moduli, è possibile riutilizzare il codice Bicep e rendere i file Bicep più leggibili e comprensibili perché incentrati su un processo specifico. I modelli principali compongono quindi più moduli insieme.

Vantaggi dei moduli

Nell'azienda di giocattoli è stato effettuato il provisioning delle risorse cloud usando numerosi singoli file Bicep. Nel corso del tempo, questi modelli aumentano significativamente. Alla fine, si avrà un codice monolitico che è difficile da leggere ed esplorare, e persino più difficile da mantenere.

Questo approccio impone anche di duplicare parti del codice quando si vuole riutilizzarlo in altri modelli. Quando si apportano modifiche, è necessario cercare in più file e aggiornarli.

I moduli Bicep consentono di risolvere questi problemi suddividendo il codice in file più piccoli e gestibili a cui più modelli possono fare riferimento. I moduli offrono alcuni vantaggi chiave.

Riusabilità

Dopo aver creato un modulo, è possibile riutilizzarlo in più file Bicep, anche se i file sono destinati a progetti o carichi di lavoro diversi. Ad esempio, quando si compila una soluzione, è possibile creare moduli separati per i componenti dell'app, il database e le risorse correlate alla rete. Quando si inizia a lavorare su un altro progetto con requisiti di rete simili, è possibile riutilizzare il modulo pertinente.

Diagram that shows a template referencing three modules: application, database, and networking. The networking module is then reused in another template.

È anche possibile condividere i moduli all'interno del team, all'interno dell'organizzazione o con la community di Azure. Altre informazioni sulla condivisione dei moduli Bicep sono disponibili in un modulo di Microsoft Learn successivo.

Incapsulamento

I moduli consentono di mantenere insieme le definizioni di risorse correlate. Ad esempio, quando si definisce un'app di Funzioni di Azure, si distribuisce in genere l'app, un piano di hosting per l'app e un account di archiviazione per i metadati dell'app. Questi tre componenti sono definiti separatamente, ma rappresentano un raggruppamento logico di risorse, quindi potrebbe essere opportuno definirli come modulo.

In tal modo, il modello principale non deve conoscere i dettagli della modalità di distribuzione di un'app per le funzioni. Questa è una responsabilità del modulo.

Componibilità

Dopo aver creato un set di moduli, è possibile comporli insieme. Ad esempio, è possibile creare un modulo che distribuisce una rete virtuale e un altro modulo che distribuisce una macchina virtuale. Si definiscono i parametri e gli output per ogni modulo in modo che sia possibile usare le informazioni importanti di un modulo e inviarle a un altro modulo.

Diagram that shows a template referencing two modules and passing the output from one to the parameter of another.

Suggerimento

È utile considerare i moduli Bicep come blocchi predefiniti che è possibile combinare in modi diversi per supportare le distribuzioni.

Funzionalità

In alcuni casi, potrebbe essere necessario usare i moduli per accedere a determinate funzionalità. Ad esempio, è possibile usare moduli e cicli insieme per distribuire più set di risorse. I moduli possono anche essere usati per definire le risorse in ambiti diversi in una singola distribuzione.

Creare un modulo

Un modulo è un normale file Bicep. Verrà creato esattamente come si fa con qualsiasi altro file Bicep.

In genere, non è consigliabile creare un modulo per ogni risorsa distribuita. Un modulo Bicep valido definisce in genere più risorse correlate. Tuttavia, se una risorsa è complessa e prevede una grande quantità di configurazione, potrebbe essere opportuno creare un singolo modulo per incapsulare la complessità. Questo approccio consente di avere modelli principali semplici e in ordine.

Dividere un modello Bicep esistente in moduli

È possibile compilare un modello Bicep di grandi dimensioni e quindi decidere di dividerlo in moduli. A volte è ovvio come dividere un file Bicep di grandi dimensioni. Potrebbe essere disponibile un set di risorse che appartiene chiaramente a un modulo. Altre volte, non è semplice determinare le risorse che devono essere raggruppate in un modulo.

Il visualizzatore Bicep consente di mettere tutto il file Bicep in prospettiva. Il visualizzatore è incluso nell'estensione Bicep per Visual Studio Code.

Per vedere il visualizzatore, aprire Visual Studio Code Explorer, selezionare e tenere premuto oppure fare clic con il pulsante destro del mouse sul file Bicep, quindi scegliere Open Bicep Visualizer. Il visualizzatore mostra una rappresentazione grafica delle risorse nel file Bicep. Include righe tra risorse per mostrare le dipendenze rilevate da Bicep.

È possibile usare il visualizzatore per semplificare la suddivisione dei file. Valutare se la visualizzazione illustra eventuali cluster di risorse. Potrebbe essere opportuno spostare questi cluster insieme in un modulo.

Si consideri ad esempio la visualizzazione seguente per un file Bicep. Vengono definiti due set distinti di risorse. Potrebbe essere opportuno raggrupparli in moduli di database e rete separati.

Annidare i moduli

I moduli possono includere altri moduli. Usando questa tecnica di annidamento, è possibile creare moduli che distribuiscono piccoli set di risorse, quindi comporli in moduli più grandi che definiscono topologie complesse di risorse. Un modello combina queste parti in un artefatto distribuibile.

Suggerimento

Sebbene sia possibile annidare più livelli di moduli, questi possono diventare complessi. Se si verifica un errore o un altro problema, è più difficile capire quale correzione apportare quando si hanno molti livelli di annidamento.

Per le distribuzioni complesse, a volte è opportuno usare le pipeline di distribuzione per distribuire più modelli anziché creare un singolo modello che fa tutto con l'annidamento. Altre informazioni sulle pipeline di distribuzione sono disponibili in un modulo Microsoft Learn successivo.

Scegliere nomi di file validi

Assicurarsi di usare un nome file descrittivo per ogni modulo. Il nome file diventa effettivamente l'identificatore del modulo. È importante che i colleghi possano comprendere lo scopo del modulo semplicemente esaminando il nome file.

Usare il modulo in un modello Bicep

Sarà possibile usare un modulo in un modello Bicep usando la parola chiave module, come illustrato sotto:

module appModule 'modules/app.bicep' = {
  name: 'myApp'
  params: {
    location: location
    appServiceAppName: appServiceAppName
    environmentType: environmentType
  }
}

Una definizione di modulo include i componenti seguenti:

  • La parola chiave module.
  • Un nome simbolico, ad esempio appModule. Questo nome viene usato all'interno del file Bicep ogni volta che si vuole fare riferimento al modulo. Il nome simbolico non viene mai visualizzato in Azure.
  • Percorso del modulo, ad esempio modules/app.bicep. Questo è in genere il percorso di un file Bicep nel file system locale. In un modulo di Microsoft Learn successivo si apprenderà come condividere i moduli usando registri e specifiche di modello, che hanno i propri formati di percorso del modulo.

    Suggerimento

    È anche possibile usare un modello di Azure Resource Manager (modello di ARM) JSON come modulo. Questa capacità può essere utile se si dispone di un set di modelli non ancora migrati a Bicep.

  • La proprietà name, che specifica il nome della distribuzione. Altre informazioni sulle distribuzioni saranno disponibili nella sezione successiva.
  • La proprietà params, in cui è possibile specificare i valori per i parametri previsti dal modulo. Altre informazioni sui parametri dei moduli saranno disponibili nell'unità successiva.

Funzionamento dei moduli

Le informazioni sul funzionamento dei moduli non sono necessarie per poterli usare, ma consentono di analizzare i problemi con le distribuzioni o spiegare un comportamento imprevisto.

Deployments

In Azure una distribuzione è una risorsa speciale che rappresenta un'operazione di distribuzione. Le distribuzioni sono risorse di Azure con il tipo di risorsa Microsoft.Resources/deployments. Quando si invia una distribuzione Bicep, si crea o si aggiorna una risorsa di distribuzione. Analogamente, quando si creano risorse nel portale di Azure, il portale crea una risorsa di distribuzione per conto dell'utente.

Tuttavia, non tutte le modifiche apportate alle risorse di Azure creano o usano distribuzioni. Ad esempio, quando si usa il portale di Azure per modificare una risorsa esistente, questo in genere non crea una distribuzione per apportare la modifica. Quando si usano strumenti di terze parti come Terraform per distribuire o configurare le risorse, questi potrebbero non creare distribuzioni.

Quando si distribuisce un file Bicep usando l'interfaccia della riga di comando di Azure o Azure PowerShell, è possibile specificare facoltativamente il nome della distribuzione. Se non si specifica un nome, l'interfaccia della riga di comando di Azure o Azure PowerShell crea automaticamente un nome di distribuzione dal nome file del modello. Ad esempio, se si distribuisce un file denominato main.bicep, il nome della distribuzione predefinito è main.

Quando si usano i moduli, Bicep crea una distribuzione separata per ogni modulo. La proprietà name specificata per il modulo diventa il nome della distribuzione. Quando si distribuisce un file Bicep che contiene un modulo, vengono create più risorse di distribuzione: una per il modello padre e una per ogni modulo.

Si supponga, ad esempio, di creare un file Bicep denominato main.bicep. Questo definisce un modulo denominato myApp. Quando si distribuisce il file main.bicep, vengono create due distribuzioni. La prima si chiama main e crea un'altra distribuzione denominata myApp che contiene le risorse dell'applicazione.

Diagram that shows two Bicep files, each of which has a separate deployment name.

È possibile elencare e visualizzare i dettagli delle risorse di distribuzione per monitorare lo stato delle distribuzioni di Bicep o per visualizzare la cronologia delle distribuzioni. Tuttavia, quando si riutilizza lo stesso nome per una distribuzione, Azure sovrascrive l'ultima distribuzione con lo stesso nome. Se è necessario mantenere la cronologia della distribuzione, assicurarsi di usare un nome univoco per ogni distribuzione. È possibile includere la data e l'ora della distribuzione nel nome per renderla univoca.

Modelli di ARM JSON generati

Quando si distribuisce un file Bicep, Bicep lo converte in un modello di ARM JSON. Questa conversione è detta anche transpilazione. I moduli usati dal modello sono incorporati nel file JSON. Indipendentemente dal numero di moduli inclusi nel modello, verrà creato solo un singolo file JSON.

Nell'esempio illustrato nella sezione precedente Bicep genera un singolo file JSON anche se in origine c'erano due file Bicep.

Diagram that shows two Bicep files, which are transpiled into a single JSON file.