Domande frequenti su Azure Developer CLI

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

L'interfaccia della riga di comando per sviluppatori di Azure (azd) e l'interfaccia della riga di comando di Azure (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 o alla gestione delle risorse di Azure, azd consente di unire i componenti cloud, la configurazione di sviluppo locale e l'automazione della pipeline in una soluzione completa.

L'interfaccia della riga di comando di Azure è uno strumento del piano di controllo per la creazione e l'amministrazione dell'infrastruttura di Azure, ad esempio macchine virtuali, reti virtuali e archiviazione. L'interfaccia della riga di comando di Azure è progettata per comandi granulari per attività amministrative specifiche.

Azure Developer CLI usa un nome di ambiente per impostare la variabile di ambiente AZURE_ENV_NAME usata dai modelli di Azure Developer CLI. Anche AZURE_ENV_NAME viene usato come prefisso per il nome del gruppo di risorse di Azure. Poiché ogni ambiente ha un proprio set di configurazioni, Azure Developer CLI archivia tutti i file di configurazione nelle directory dell'ambiente.

├── .Azure                          [This directory displays after you run add 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 

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

Il percorso del file con estensione env è <your-project-directory-name>\.azure\<your-environment-name>\.env.

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

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, sottoscrizione e posizione di prima.

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

La secretOrRandomPassword funzione recupera un segreto da Azure Key Vault se vengono forniti i parametri per il nome e il segreto dell'insieme di credenziali delle chiavi. Se questi parametri non vengono forniti o non è possibile recuperare un segreto, la funzione restituirà invece una password generata in modo casuale da usare.

Nell'esempio seguente viene illustrato un caso d'uso secretOrRandomPassword comune di in un main.parameters.json file. Le ${AZURE_KEY_VAULT_NAME} variabili e sqlAdminPassword vengono passate come parametri per i nomi dell'insieme di credenziali delle chiavi 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 insieme di credenziali delle chiavi e archiviare il segreto generato, usare il codice Bicep seguente. È possibile visualizzare il codice di esempio completo per questi moduli nel repository GitHub dell'interfaccia della riga di comando per sviluppatori di 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 flusso di lavoro seguente per la gestione dei segreti:

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

Sì, ma ogni località di 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.

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. A tale scopo, è possibile aggiungere una voce a main.parameters.json nella infra cartella . Ad esempio:

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

Questa voce crea una nuova risorsa denominata "my-unique-name" anziché un valore casuale, ad esempio "app-web-aj84u2adj" al successivo provisioning 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, si riceverà un errore arm durante azd provision il tentativo di creare la risorsa.

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

Passare a https://portal.azure.com e quindi cercare il gruppo di risorse, ovvero rg-<your-environment-name>.

Per effettuare il provisioning delle risorse di Azure si usano i modelli Bicep, disponibili in <your-project-directory-name>/infra. In caso di problemi, viene incluso il messaggio di errore nell'output dell'interfaccia della riga di comando.

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

Per altre risorse, vedere Risolvere gli errori comuni di distribuzione di Azure - Azure Resource Manager.

Presto disponibili. Questa funzionalità è stata pianificata per una versione successiva.

Sì.

Durante la distribuzione, azd individua innanzitutto 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 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.

Sì. Viene usata la modalità di distribuzione incrementale.

Presto disponibili. Questa funzionalità è stata pianificata per una versione successiva.

Un'entità servizio di Azure è un'identità creata per l'uso 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 Connessione GitHub e Azure | Microsoft Docs.

No. Il azd pipeline config comando si occupa della creazione dell'entità servizio di Azure e dell'esecuzione dei passaggi necessari per archiviare i segreti nel repository 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-GH-account>/<your-repo>/secrets/actions.

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

Anche se OIDC è supportato come predefinito per GitHub Actions e Azure Pipeline (impostato come federato), non è supportato per Azure DevOps o Terraform.

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

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

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

Il percorso del file GitHub Actions è <your-project-directory-name>\.github\workflows\azure-dev.yml.

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

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

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