Condividi tramite

Domande frequenti sugli strumenti e l'ambiente dell'interfaccia della riga di comando per sviluppatori di Azure

Questo articolo fornisce risposte alle domande frequenti sugli strumenti, i comandi e gli ambienti Azure Developer CLI (azd).

Domande generali

La sezione seguente è incentrata sulle domande generali azd sugli strumenti e sull'ambiente.

Come si disinstalla la CLI per sviluppo di Azure?

Sono disponibili diverse opzioni per la disinstallazione di azd a seconda della modalità di installazione originale. Per informazioni dettagliate, visitare la pagina di installazione .

Qual è la differenza tra l'interfaccia della riga di comando di Azure Developer e il Azure CLI?

Azure Developer CLI (azd) e Azure CLI (az) sono entrambi strumenti da riga di comando, ma consentono di eseguire attività diverse.

azd è incentrato sul flusso di lavoro di sviluppo di alto livello. Oltre al provisioning/gestione delle risorse Azure, azd consente di unire i componenti cloud, la configurazione di sviluppo locale e l'automazione della pipeline in una soluzione completa.

Azure CLI è uno strumento del piano di controllo per creare e amministrare l'infrastruttura di Azure, ad esempio macchine virtuali, reti virtuali e archiviazione. Il Azure CLI è progettato per i comandi granulari per attività amministrative specifiche.

Per altre informazioni, vedere Azure Developer CLI vs Azure CLI.

Che cos'è un nome di ambiente?

L'Azure Developer CLI utilizza un nome di ambiente per impostare la variabile di ambiente AZURE_ENV_NAME utilizzata dai modelli di Azure Developer CLI. AZURE_ENV_NAME viene usato anche per anteporre il nome del gruppo di risorse Azure. Poiché ogni ambiente ha un proprio set di configurazioni, Azure l'interfaccia della riga di comando per sviluppatori archivia tutti i file di configurazione nelle directory dell'ambiente.

├── .Azure                          [This directory displays after you run `azd init` or `azd up`]
│   ├── <your environment1>         [A directory to store all environment-related configurations]
│   │   ├── .env                    [Contains environment variables]
│   │   └── main.parameters.json    [A parameter file]
│   └── <your environment2>         [A directory to store all environment-related configurations]
│   │   ├── .env                    [Contains environment variables]
│   │   └── main.parameters.json    [A parameter file]
│   └──config.json

Per altre informazioni sui flussi di lavoro, vedere azd init e azd up.

È possibile configurare più di un ambiente?

Sì. È possibile configurare diversi ambienti, ad esempio sviluppo, test, produzione. È possibile usare azd env per gestire questi ambienti.

Dove è archiviato il file di configurazione dell'ambiente (con estensione env)?

Il percorso del file con estensione env è <your-project-directory-name>\.azure\<your-environment-name>\.env. Per altre informazioni, vedere Gestire le variabili di ambiente.

Come viene usato il file con estensione env?

Nell'interfaccia della riga di comando di Azure Developer i comandi azd fanno riferimento al file con estensione env per la configurazione dell'ambiente. Comandi come azd deploy aggiornano anche il file .env con, ad esempio, la stringa di connessione del database e l'endpoint di Azure Key Vault.

Ho eseguito azd up in Codespaces. È possibile continuare il lavoro in un ambiente di sviluppo locale?

Sì. È possibile continuare il lavoro di sviluppo in locale.

  1. Eseguire azd init -t <template repo> per clonare il progetto modello nel computer locale.
  2. Per eseguire il pull verso il basso dell'env esistente creato usando Codespaces, eseguire azd env refresh. Assicurarsi di specificare lo stesso nome di ambiente, abbonamento e posizione come prima.

Come si esegue l'autenticazione in Codespaces se l'accesso del dispositivo presenta un problema?

Se si verificano problemi con l'autenticazione del codice del dispositivo in Codespaces (ad esempio, richieste o errori 2FA ricorrenti), provare la soluzione alternativa seguente usando VS Code Desktop:

  1. Aprire Codespace in VS Code Desktop usando uno dei metodi seguenti:
    • Usare il riquadro comandi (CTRL+MAIUSC+P in Windows o Cmd+MAIUSC+P in MacOs) e selezionare Codespaces: Open in VS Code Desktop.
    • Fare clic sull'angolo inferiore sinistro di Codespace nel browser e selezionare Apri in VS Code Desktop.
  2. Nel terminale di VS Code Desktop eseguire azd auth login e completare l'autenticazione basata su browser.
  3. Dopo l'autenticazione, chiudere VS Code Desktop e tornare al codespace nel browser. Lo stato di autenticazione deve essere persistente.

Come viene usato il file azure.yaml?

Il file azure.yaml descrive le app e i tipi di risorse Azure incluse nel modello.

Qual è il comportamento della secretOrRandomPassword funzione?

La funzione secretOrRandomPassword recupera un segreto da Azure Key Vault se vengono forniti i parametri per il Nome del Key Vault e il segreto. Se questi parametri non vengono forniti o non è possibile recuperare un segreto, la funzione restituisce invece una password generata in modo casuale da usare.

Nell'esempio seguente viene illustrato un caso d'uso comune del secretOrRandomPassword in un file di main.parameters.json. Le variabili ${AZURE_KEY_VAULT_NAME} e sqlAdminPassword vengono passate come parametri per i nomi della Key Vault e del segreto. Se il valore non può essere recuperato, viene invece generata una password casuale.

"sqlAdminPassword": {
    "value": "$(secretOrRandomPassword ${AZURE_KEY_VAULT_NAME} sqlAdminPassword)"
}

L'output di secretOrRandomPassword deve essere salvato anche in Key Vault usando Bicep per le esecuzioni future. Il recupero e il riutilizzo degli stessi segreti tra le distribuzioni possono impedire errori o comportamenti imprevisti che possono emergere durante la generazione ripetuta di nuovi valori. Per creare un Key Vault e archiviare il segreto generato, usare il codice Bicep riportato di seguito. È possibile visualizzare il codice di esempio completo per questi moduli nel repository dell'interfaccia della riga di comando per sviluppatori GitHub<>Azure.

module keyVault './core/security/keyvault.bicep' = {
name: 'keyvault'
scope: resourceGroup
params: {
    name: '${take(prefix, 17)}-vault'
    location: location
    tags: tags
    principalId: principalId
}
}

module keyVaultSecrets './core/security/keyvault-secret.bicep' = {
name: 'keyvault-secret-sqlAdminPassword'
scope: resourceGroup
params: {
    keyVaultName: keyVault.outputs.name
    name: 'sqlAdminPassword'
    secretValue: sqlAdminPassword
}
}]

Questa configurazione di Bicep abilita il seguente flusso di lavoro per la gestione dei segreti:

  1. Se il segreto specificato esiste, viene recuperato da Key Vault usando la funzione secretOrRandomPassword.
  2. Se il segreto non esiste, viene creato un Key Vault e il segreto generato in modo casuale viene archiviato all'interno di esso.
  3. Nelle distribuzioni future, il metodo secretOrRandomPassword recupera il segreto archiviato ora che esiste in Key Vault. Il Key Vault non verrà ricreato se esiste già, ma lo stesso valore del segreto verrà archiviato di nuovo per l'esecuzione successiva.

È possibile usare Azure sottoscrizione gratuita?

Sì, tuttavia ogni posizione Azure può avere una sola distribuzione. Se è già stato usato il percorso di Azure selezionato, verrà visualizzato l'errore di distribuzione:

InvalidTemplateDeployment: The template deployment '<env_name>' isn't valid according to the validation procedure. The tracking ID is '<tracking_id>'. See inner errors for details.

È possibile selezionare un percorso di Azure diverso per risolvere il problema.

L'app ospitata su Azure App Service sta generando un avviso "Sito ingannevole". Come posso risolverlo?

Questo problema può verificarsi a causa del metodo per la denominazione delle risorse.

I modelli creati da 'Azure Dev' consentono di configurare il nome della risorsa. Per farlo, è possibile aggiungere una voce al main.parameters.json nella cartella infra. Per esempio:

"webServiceName": {
    "value": "my-unique-name"
}

Questa voce crea una nuova risorsa denominata "my-unique-name" al posto di un valore casuale, come "app-web-aj84u2adj", alla successiva creazione dell'applicazione. È possibile rimuovere manualmente il gruppo di risorse precedente usando il portale di Azure oppure eseguire azd down per rimuovere tutte le distribuzioni precedenti. Dopo aver rimosso le risorse, eseguire azd provision per crearle di nuovo con il nuovo nome.

Questo nome dovrà essere univoco a livello globale. In caso contrario, durante azd provision verrà visualizzato un errore arm quando tenta di creare la risorsa.

È possibile lavorare con più tenant Azure?

Sì. Per eseguire l'autenticazione con un tenant specifico, usare il --tenant-id parametro con il azd auth login comando .

azd auth login --tenant-id <tenant-id>

In alternativa, se si vuole permettere a azd di accedere a tutti i tenant, è possibile gestire prima, nel browser, le sfide di autenticazione a più fattori (MFA):

  1. Aprire il Azure Portal nel browser.
  2. Passare a ciascuno dei tenant, uno alla volta. Questa azione attiva eventuali sfide di autenticazione multi-fattore necessarie e aggiorna i token.
  3. Eseguire azd auth login nel terminale. azd userà la sessione e i token di accesso esistenti del browser, che sono ora validi per tutti i tenant visitati.

È possibile eseguire azd up più volte?

Sì. Viene usata la modalità di distribuzione incrementale . Per altre informazioni, vedere azd up.

Provisioning

La sezione seguente è incentrata sul azd processo di provisioning.

È possibile eseguire azd provision più volte?

Sì. Viene usata la modalità di distribuzione incrementale . Per altre informazioni, vedere azd provision.

In che modo il comando sa quali risorse approvvigionare?

Il comando usa Bicep templates, disponibili in <your-project-directory-name>/infra per effettuare il provisioning delle risorse Azure.

Dove è possibile trovare le risorse di cui viene effettuato il provisioning in Azure?

Vai a https://portal.azure.com e quindi cerca il tuo gruppo di risorse, che è rg-<your-environment-name>.

Come è possibile trovare altre informazioni sugli errori di Azure?

Si utilizzano modelli Bicep, disponibili in <your-project-directory-name>/infra, per fornire le risorse Azure. In caso di problemi, viene incluso il messaggio di errore nell'output della CLI.

È anche possibile passare a https://portal.azure.com e quindi cercare il gruppo di risorse, che è rg-<your-environment-name>. Se una delle distribuzioni ha esito negativo, selezionare il collegamento di errore per ottenere altre informazioni.

Per altre risorse, vedere Risoluzione dei problemi comuni di distribuzione Azure - Azure Resource Manager.

Esiste un file di log per azd provision?

Prossimamente. Questa funzionalità è pianificata per una versione futura.

Distribuzione

La sezione seguente è incentrata sul azd processo di distribuzione.

È possibile eseguire azd deploy più volte?

Sì. Per altre informazioni, vedere azd deploy .

In che modo azd trova la risorsa Azure in cui distribuire il codice?

Durante la distribuzione, azd individua prima tutti i gruppi di risorse che costituiscono l'applicazione cercando gruppi contrassegnati con azd-env-name e con un valore corrispondente al nome dell'ambiente. Enumera quindi tutte le risorse in ognuno di questi gruppi di risorse, cercando una risorsa contrassegnata con azd-service-name con un valore corrispondente al nome del servizio da azure.yaml.

Sebbene sia consigliabile usare tag per le risorse, è anche possibile usare la resourceName proprietà in azure.yaml per specificare un nome di risorsa esplicito. In tal caso, la logica precedente non viene eseguita.

Come posso distribuire servizi specifici nel mio progetto saltando gli altri?

Quando si distribuisce il progetto, è possibile scegliere di distribuire servizi specifici specificando il nome del servizio nel comando (ad esempio azd deploy api) oppure passando a una sottocartella che contiene solo i servizi da distribuire. In questo caso, tutti gli altri servizi verranno elencati come - Skipped.

Se non si vuole ignorare alcun servizio, assicurarsi di eseguire il comando dalla cartella radice o aggiungere il flag --all al comando.

Configurazione della pipeline

La sezione seguente è incentrata sulla configurazione della pipeline CI/CD.

Che cos'è un servizio principale di Azure?

Un principale del servizio Azure è un'identità creata per essere utilizzata con app, servizi ospitati e strumenti automatizzati per accedere alle risorse di Azure. Questo accesso è limitato dai ruoli assegnati all'entità servizio, che consente di controllare le risorse a cui è possibile accedere e a quale livello. Per altre informazioni sull'autenticazione da Azure a GitHub, vedere Connect GitHub e Azure | Microsoft Docs.

È necessario creare un service principal di Azure prima di eseguire azd pipeline config?

No. Il comando azd pipeline config gestisce la creazione dell'entità servizio Azure ed esegue i passaggi necessari per archiviare i segreti nel repository GitHub.

Quali sono tutti i segreti archiviati in GitHub?

Il comando archivia quattro segreti in GitHub: AZURE_CREDENTIALS, AZURE_ENV_NAME, AZURE_LOCATION e AZURE_SUBSCRIPTION_ID. È possibile eseguire l'override del valore di ogni segreto passando a https://github.com/<your-github-account>/<your-repo>/secrets/actions.

Che cos'è OpenID Connect (OIDC) ed è supportato?

Con OpenID Connect, i flussi di lavoro possono scambiare token di breve durata direttamente da Azure.

Anche se OIDC è supportato come impostazione predefinita per GitHub Actions e pipeline di Azure (impostata come federated), non è supportata per Azure DevOps o Terraform.

  • Per Azure DevOps, la chiamata esplicita a --auth-type come federated genererà un errore.
  • Per Terraform:
    • Se --auth-type non è definito, eseguirà il fallback a clientcredentials e genererà un avviso.
    • Se --auth-type è impostato in modo esplicito su federated, verrà generato un errore.

Come si reimposta il principale servizio di Azure memorizzato in GitHub Actions?

Passare a https://github.com/<your-github-account>/<your-repo>settings/secrets/actionse quindi aggiornare AZURE_CREDENTIALS copiando e incollando l'intero oggetto JSON per la nuova entità servizio. Per esempio:

{
"clientId": "<GUID>",
"clientSecret": "<GUID>",
"subscriptionId": "<GUID>",
"tenantId": "<GUID>",
(...)
}

Dove è archiviato il file GitHub Actions?

Il percorso del file GitHub Actions è <your-project-directory-name>\.github\workflows\azure-dev.yml. Per altre informazioni, vedere Quickstart: Creare un'entità servizio ed eseguire un'azione GitHub.

Nel file azure-dev.yml è possibile distribuire solo il codice nel passaggio di compilazione?

Sì. Sostituisci run: azd up --no-prompt con run: azd deploy --no-prompt.

Dove è possibile trovare il log per il processo di GitHub Actions attivato durante l'esecuzione di azd pipeline config?

Passare a https://github.com/<your-github-account>/<your-repo>/actions, e quindi fare riferimento al file di log nell'esecuzione del flusso di lavoro.

Compilazione di un'applicazione contenitore in locale

Perché non è possibile eseguire localmente l'app contenitore che si sta compilando?

Quando si compilano applicazioni contenitore in locale, è necessario eseguire azd auth login nel contenitore affinché l'applicazione funzioni con l'AzureDeveloperCliCredential. In alternativa, è possibile configurare l'applicazione in modo da usare un'entità servizio anziché l'AzureDeveloperCliCredential.

  • Last updated on