Definizione delle risorse

• 5 minuti

I modelli Bicep sono i file creati che definiscono le risorse di Azure da distribuire.

L'azienda di giocattoli deve creare un modello Bicep riutilizzabile nei successivi lanci di prodotti. Il modello deve distribuire un account di archiviazione di Azure e risorse del Servizio app di Azure, che verranno usate per il marketing di ogni nuovo prodotto durante la relativa fase di lancio.

In questa unità si apprenderà come definire una risorsa in un modello Bicep, come funzionano i nomi delle risorse e come creare risorse correlate tra loro.

Definire una risorsa

Il principale utilizzo dei modelli Bicep è quello di definire le risorse di Azure. Di seguito è riportato un esempio di una tipica definizione di risorsa in Bicep. Nell'esempio viene creato un nuovo account di archiviazione denominato toylaunchstorage.

resource storageAccount 'Microsoft.Storage/storageAccounts@2022-09-01' = {
  name: 'toylaunchstorage'
  location: 'westus3'
  sku: {
    name: 'Standard_LRS'
  }
  kind: 'StorageV2'
  properties: {
    accessTier: 'Hot'
  }
}

Nell'elenco seguente vengono esaminati gli elementi chiave di questa definizione di risorsa:

• La parola chiave resource all'inizio indica a Bicep che si sta per definire una risorsa.

• Successivamente, si assegna alla risorsa un nome simbolico. Nell'esempio, il nome simbolico della risorsa è storageAccount. I nomi simbolici vengono usati in Bicep per fare riferimento alla risorsa, ma non verranno mai visualizzati in Azure.

• Microsoft.Storage/storageAccounts@2022-09-01 è il tipo di risorsa e la versione API della risorsa. Microsoft.Storage/storageAccounts indica a Bicep che si sta dichiarando un account di archiviazione di Azure. La data 2022-09-01 è la versione dell'API Archiviazione di Azure che Bicep usa durante la creazione della risorsa.

  Suggerimento

  L’estensione Bicep per Visual Studio Code consente di trovare i tipi di risorse e le versioni API per le risorse create. Se si ha familiarità con i modelli di Azure Resource Manager, osservare come la versione dell'API corrisponda alla stessa versione che si userebbe con quei modelli.

• È necessario dichiarare un nome di risorsa, ovvero il nome che verrà assegnato all'account di archiviazione in Azure. Per impostare un nome di risorsa, usare la parola chiave name.

  Importante

  I nomi simbolici vengono usati solo nel modello Bicep e non vengono visualizzati in Azure. mentre i nomi delle risorse appaiono in Azure.

• Si impostano quindi altri dettagli della risorsa, tra cui la posizione, lo SKU (piano tariffario) e il tipo. È anche possibile definire alcune proprietà, diverse per ogni tipo di risorsa. Le proprietà possono anche cambiare in base alla versione dell'API. In questo esempio si imposterà il livello di accesso dell'account di archiviazione su Hot.

Cosa accade quando le risorse dipendono l'una dall'altra?

In un modello Bicep, in genere, sono incluse varie risorse. In molti casi, è necessario che una risorsa dipenda da un'altra. Potrebbe essere inoltre necessario estrarre alcune informazioni da una risorsa per poter definirne un'altra. Oppure, se si distribuisce un'applicazione Web, è necessario creare l'infrastruttura server prima di potervi aggiungere un'applicazione. Queste relazioni prendono il nome di dipendenze.

Sarà necessario distribuire un'app del Servizio app di Azure per il modello che verrà usato per lanciare il giocattolo, ma per creare un'app del Servizio app di Azure occorre prima creare un piano di servizio app. Il piano di servizio app rappresenta le risorse che ospitano il server e viene dichiarato come illustrato nell'esempio di seguito:

resource appServicePlan 'Microsoft.Web/serverFarms@2022-03-01' = {
  name: 'toy-product-launch-plan'
  location: 'westus3'
  sku: {
    name: 'F1'
  }
}

Questa definizione di risorsa indica a Bicep che si vuole distribuire un piano di servizio app con il tipo di risorsa Microsoft.Web/serverFarms. La risorsa del piano è denominata toy-product-launch-plane viene distribuita nell'area Stati Uniti occidentali 3. Viene usato uno SKU di prezzo F1, ovvero il livello gratuito del Servizio app.

Dopo aver dichiarato il piano di servizio app, è ora necessario dichiarare l'app:

resource appServiceApp 'Microsoft.Web/sites@2022-03-01' = {
  name: 'toy-product-launch-1'
  location: 'westus3'
  properties: {
    serverFarmId: appServicePlan.id
    httpsOnly: true
  }
}

In questo modello si chiede ad Azure di ospitare l'app nel piano appena creato. Si noti che la definizione del piano include il nome simbolico del piano di servizio app in questa riga: serverFarmId: appServicePlan.id. Questa riga indica che Bicep otterrà l'ID della risorsa del piano di servizio app usando la proprietà id. In pratica significa che l'ID della server farm dell'app corrisponde all'ID del piano di servizio app definito in precedenza.

Dichiarando la risorsa dell'app con una proprietà che fa riferimento al nome simbolico del piano, Azure capisce la dipendenza implicita tra l'app del servizio App di Azure e il piano. Durante la distribuzione delle risorse, Azure si assicurerà quindi di completare la distribuzione del piano prima di iniziare a distribuire l'app.