Rendere il progetto compatibile con l'interfaccia della riga di comando per sviluppatori di Azure

L'interfaccia della riga di comando per sviluppatori di Azure (azd) consente agli sviluppatori di eseguire lo scaffolding delle applicazioni per il cloud usando modelli ospitati in GitHub. Microsoft offre diversi modelli per iniziare. Questo articolo illustra come rendere compatibile l'applicazione azd personalizzata.

Informazioni sull'architettura del modello

Il diagramma seguente offre una rapida panoramica del processo per creare un azd modello:

Tutti i azd modelli hanno la stessa struttura di file, in base alle azd convenzioni. La gerarchia seguente illustra la struttura di directory che verrà compilata in questa esercitazione.

├── .azdo                                        [ Configures an Azure Pipeline ]
├── .devcontainer                                [ For DevContainer ]
├── .github                                      [ Configures a GitHub workflow ]
├── .vscode                                      [ VS Code workspace configurations ]
├── .azure                                       [ Stores Azure configurations and environment variables ]
├── infra                                        [ Contains infrastructure as code files ]
│   ├── main.bicep/main.tf                       [ Main infrastructure file ]
│   ├── main.parameters.json/main.tfvars.json    [ Parameters file ]
│   └── core/modules                             [ Contains reusable Bicep/Terraform modules ]
└── azure.yaml                                   [ Describes the app and type of Azure resources]

Inizializzare il modello

Il azd init comando viene usato per inizializzare l'applicazione per il provisioning e la distribuzione delle risorse dell'app in Azure. Questo comando richiede di scegliere tra due flussi di lavoro diversi per inizializzare un modello descritto nelle sezioni seguenti.

• Usare il codice nella directory corrente: selezionare questa opzione per indicare azd di analizzare il codice nella directory per identificare le tecnologie usate, ad esempio il linguaggio di programmazione, il framework e il sistema di database. azd genererà automaticamente gli asset del modello, ad esempio il file di definizione del azure.yaml servizio e la infra cartella con file di infrastruttura come codice.

• Selezionare un modello: selezionare questa opzione per usare un modello esistente come punto di partenza. Per impostazione predefinita, azd consente di esplorare i modelli dalla raccolta Awesome AZD , ma è anche possibile configurare raccolte di modelli personalizzate. Quando si seleziona un modello, gli asset di tale modello verranno aggiunti alla directory del progetto esistente.

I dettagli di ognuno di questi flussi di lavoro sono descritti nelle sezioni seguenti.

Usare il codice nella directory

1. È possibile seguire i passaggi successivi usando il proprio progetto. Tuttavia, se si preferisce seguire l'uso di un'applicazione di esempio, clonare il repository di avvio seguente in una directory vuota nel computer:

   git clone https://github.com/Azure-Samples/msdocs-python-flask-webapp-quickstart
   

2. Aprire lo strumento da riga di comando scelto per la directory radice del progetto.

3. Eseguire il azd init comando per inizializzare il modello.

   azd init
   

4. Quando richiesto, selezionare l'opzione Usa codice nella directory corrente. azd analizza il progetto e fornisce un riepilogo dei servizi rilevati e delle risorse di hosting di Azure consigliate.

5. Selezionare Conferma e continuare l'inizializzazione dell'app. azd genera gli asset seguenti nella directory radice del progetto:

   • File azure.yaml con definizioni di servizio appropriate.
   • infra Cartella con file di infrastruttura come codice per effettuare il provisioning e distribuire il progetto in Azure.
   • .azure Cartella con variabili di ambiente impostate in un .env file.

   Altre informazioni su questo processo di rilevamento e generazione sono disponibili più avanti nell'articolo.

6. I file generati funzionano così come sono per l'app di esempio fornita e possono anche essere per le tue app. Se necessario, i file generati possono essere modificati in base alle proprie esigenze. Ad esempio, potrebbe essere necessario modificare ulteriormente i file di infrastruttura come codice nella cartella se l'app infra si basa su risorse di Azure oltre a quelle identificate da azd.

7. Eseguire il comando per effettuare il provisioning e distribuire l'app azd up in Azure.

   azd up
   

8. Quando richiesto, selezionare la sottoscrizione e il percorso desiderati per avviare il processo di provisioning e distribuzione.

9. Al termine del processo, fare clic sul collegamento nell'output azd per aprire l'app nel browser.

Esplorare i passaggi di inizializzazione

Quando si seleziona Il codice nel flusso di lavoro della directory corrente, il azd init comando analizza il progetto e genera automaticamente il codice in base a ciò che individua. Le sezioni seguenti illustrano i dettagli del funzionamento di questo processo e delle tecnologie attualmente supportate.

Rilevamento

Il azd init comando rileva i file di progetto per le lingue supportate che si trovano nella directory del progetto e nelle sottodirectory. azd analizzerà anche le dipendenze dei pacchetti per raccogliere informazioni sui framework Web o sui database usati dall'app. Se necessario, è possibile aggiungere o modificare manualmente i componenti rilevati come presentato nella richiesta di riepilogo della conferma.

La logica di rilevamento corrente è la seguente:

• Lingue supportate:
  • Python
  • JavaScript/TypeScript
  • .NET
  • Java
• Database supportati:
  • MongoDB
  • PostgreSQL
• Per Python e JavaScript/TypeScript, vengono rilevati automaticamente framework Web e database.
• Quando un progetto JavaScript/TypeScript usa un framework Web front-end (o lato client), viene classificato come servizio front-end. Se il servizio usa un framework Web front-end attualmente non rilevato, è possibile selezionare JQuery per fornire la classificazione e il comportamento del servizio front-end equivalenti.

Generazione

Dopo aver verificato i componenti rilevati, azd init genera i file di infrastruttura come codice necessari per distribuire l'applicazione in Azure.

La logica di generazione è la seguente:

• Host supportati:
  • App contenitore di Azure.
• Per i database, il mapping supportato tra tecnologia di database e servizio usato:
  • MongoDB: API Azure CosmosDB per MongoDB
  • PostgreSQL: server flessibile Database di Azure per PostgreSQL
  • Redis: componente aggiuntivo Redis per App Azure Container
• I servizi che usano i database avranno variabili di ambiente che forniscono la connessione al database preconfigurato per impostazione predefinita.
• Quando vengono rilevati entrambi i servizi front-end e back-end, la configurazione CORS nell'host di Azure per i servizi back-end verrà aggiornata per consentire il dominio di hosting predefinito dei servizi front-end. Questa operazione può essere modificata o rimossa in base alle esigenze nell'infrastruttura come file di configurazione del codice.

Aggiunta del supporto per i contenitori di sviluppo

È anche possibile rendere il modello compatibile con i contenitori di sviluppo e Codespaces. Un contenitore di sviluppo consente di usare un contenitore come ambiente di sviluppo completo. Può essere usato per eseguire un'applicazione, per separare strumenti, librerie o runtime necessari per lavorare con una codebase e per facilitare l'integrazione e il test continui. I contenitori di sviluppo possono essere eseguiti in locale o in remoto, in un cloud privato o pubblico. (Origine: https://containers.dev/)

Per aggiungere il supporto per i contenitori di sviluppo:

1. Creare una cartella .devcontainer nella radice del progetto.

2. Creare un devcontainer.json file all'interno della .devcontainer cartella con le configurazioni desiderate. Il azd modello iniziale fornisce un file di esempio devcontainer.json che è possibile copiare nel progetto e modificare in base alle esigenze.

Altre informazioni sull'uso dei contenitori di sviluppo sono disponibili nella documentazione di Visual Studio Code.

Aggiungere il supporto per una pipeline CI/CD

È anche possibile aggiungere il supporto per CI/CD nel modello usando GitHub actions o Azure DevOps seguendo questa procedura:

1. Aggiungere una .github cartella per GitHub actions o una .ado cartella per Azure DevOps alla radice del progetto.

2. Aggiungere un file del flusso di lavoro nella nuova cartella. Il azd modello iniziale fornisce un file del flusso di lavoro di GitHub Actions di esempio e i file di esempio delle pipeline di Azure DevOps per ogni piattaforma che è possibile copiare nel progetto e modificare in base alle esigenze.

3. Potrebbe anche essere necessario aggiornare il main.parameters.json file nella infra cartella con le variabili di ambiente necessarie per l'esecuzione del flusso di lavoro.

Usare un modello

Il flusso di lavoro Selezionare un modello consente di scegliere un modello esistente azd da usare come punto di partenza. Il contenuto del modello selezionato viene aggiunto alla directory radice del progetto. La maggior parte dei modelli fornisce il set necessario di file e cartelle e alcuni modelli includono file di infrastruttura come codice completi per effettuare il provisioning delle risorse di Azure per uno stack di azd applicazioni scelto.

In questo esempio si userà il modello Starter - Bicep , che include la struttura essenziale di un azd modello e un codice boilerplate utile per iniziare.

1. Per seguire i passaggi successivi usando un'applicazione di esempio esistente, clonare il progetto di avvio seguente in una directory vuota nel computer:

   git clone https://github.com/Azure-Samples/msdocs-python-flask-webapp-quickstart
   

2. Nello strumento da riga di comando preferito passare alla directory radice del progetto clonato.

3. Eseguire il azd init comando per inizializzare un azd modello.

   azd init
   

4. Quando richiesto, scegliere l'opzione Selezionare un modello.

5. Nell'elenco dei modelli selezionare Starter - Bicep. Potrebbe essere necessario scorrere l'elenco usando i tasti di direzione della tastiera per trovare il modello.

6. Quando richiesto, immettere un nome di ambiente breve, ad esempio testenv.

7. Dopo aver eseguito azd init, gli asset seguenti vengono aggiunti al progetto:

   ├── .azdo                                        [ Configures an Azure Pipeline ]
   ├── .devcontainer                                [ For DevContainer ]
   ├── .github                                      [ Configures a GitHub workflow ]
   ├── .vscode                                      [ VS Code workspace configurations ]
   ├── .azure                                       [ Stores Azure configurations and environment variables ]
   ├── infra                                        [ Contains infrastructure as code files ]
   │   ├── main.bicep/main.tf                       [ Main infrastructure file ]
   │   ├── main.parameters.json/main.tfvars.json    [ Parameters file ]
   │   └── core/modules                             [ Contains reusable Bicep/Terraform modules ]
   └── azure.yaml                                   [ Describes the app and type of Azure resources]
   

Aggiornare i file Bicep

Il progetto contiene ora la struttura principale e gli asset di un azd modello. Tuttavia, per effettuare il provisioning delle risorse di Azure per il progetto specifico, è necessario aggiornare i file Bicep nella infra cartella . Per ospitare l'applicazione di esempio, sono necessarie le risorse seguenti:

• Un piano di servizio app Azure
• Un servizio app Azure in esecuzione in Linux

1. Aprire la directory di progetto di primo livello nell'editor preferito, ad esempio Visual Studio Code.

2. Aprire il file nell'editor main.bicep . Questo file contiene codice boilerplate utile per configurare variabili, parametri e convenzioni di denominazione essenziali. Sotto il blocco di commenti intorno alla riga 50 che legge Add resources to be provisioned below, aggiungere il bicep seguente:

   // Creates an app service instance to host the app
   module web './core/host/appservice.bicep' = {
     name: 'web'
     scope: rg
     params: {
       name: '${abbrs.webSitesAppService}web-${resourceToken}'
       location: location
       tags: union(tags, { 'azd-service-name': 'web' })
       appServicePlanId: appServicePlan.outputs.id
       runtimeName: 'python'
       runtimeVersion: '3.8'
       scmDoBuildDuringDeployment: true
     }
   }
   
   // Create an App Service Plan to group applications under the same payment plan and SKU
   module appServicePlan './core/host/appserviceplan.bicep' = {
     name: 'appserviceplan'
     scope: rg
     params: {
       name: '${abbrs.webServerFarms}${resourceToken}'
       location: location
       tags: tags
       sku: {
         name: 'B1'
       }
     }
   }
   

   Nota

   • Una stringa univoca viene generata in base all'ID sottoscrizione e usata come ${resourceToken} variabile. Questo token viene aggiunto al nome di tutte le risorse di Azure create da azd. azd usa i tag per identificare le risorse in modo da poter modificare i nomi in base alla convenzione di denominazione dell'organizzazione.
   • Il 'azd-service-name': 'web' tag nel servizio app è il valore azd usato per identificare l'host di distribuzione. Il valore deve essere uguale a quello definito per il servizio nel file azure.yaml .

Aggiornare il file azure.yaml

Per distribuire l'app, azd è necessario saperne di più sull'app. Il azure.yaml file viene usato per definire il percorso del codice sorgente, la lingua e il servizio di hosting di Azure per ogni servizio nell'app. Per informazioni dettagliate, vedere lo schema azure.yaml.

1. Aprire nella azure.yaml radice del progetto.

2. Aggiungere le righe seguenti alla fine del file:

   name: msdocs-python-flask-webapp-quickstart
   services:
     web:
       project: .
       language: py
       host: appservice
   

Effettuare il provisioning e distribuire il modello

1. Salvare tutte le modifiche ed eseguire il comando seguente per effettuare il provisioning e distribuire le risorse dell'app in Azure:

   azd up
   

2. Al termine del comando, fare clic sul collegamento nell'output del comando per passare al sito distribuito.

Il progetto è ora compatibile con l'interfaccia della riga di comando per sviluppatori di Azure e può essere usato come modello.

Nota

azd supporta anche l'uso di Buildpack per la containerizzazione delle app per impostazione predefinita. Se il azd modello è destinato ad App Azure Container o servizio Azure Kubernetes ma non include un file Docker, azd genera automaticamente un'immagine usando Buildpack.

Configurare la pipeline CI/CD

Se il modello include il supporto per GitHub Actions o Azure Pipelines, è possibile configurare una pipeline CI/CD seguendo questa procedura:

1. Eseguire il comando seguente per eseguire il push degli aggiornamenti nel repository. Il flusso di lavoro di GitHub Actions viene attivato a causa dell'aggiornamento.

   azd pipeline config    
   

2. Usando il browser, passare al repository GitHub per il progetto.

3. Selezionare Azioni per visualizzare il flusso di lavoro in esecuzione.

Pulire le risorse

Quando non sono più necessarie le risorse create in questo articolo, eseguire il comando seguente:

azd down

Vedi anche

• Creare file Bicep con Visual Studio Code per un'introduzione all'uso dei file Bicep.
• Esempi bicep
• Come decompilare i modelli di Azure Resource Manager (modelli arm) in Bicep
• Schema azure.yaml dell'interfaccia della riga di comando per sviluppatori di Azure

Richiedere assistenza

Per informazioni su come inviare un bug, richiedere assistenza o proporre una nuova funzionalità per l'interfaccia della riga di comando per sviluppatori di Azure, visitare la pagina relativa alla risoluzione dei problemi e al supporto tecnico.

Passaggi successivi

Domande frequenti su Azure Developer CLI