Domande frequenti dell'interfaccia della riga di comando per sviluppatori 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 .

dell'interfaccia della riga di comando per sviluppatori di Azure (azd) e dell'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.

L'interfaccia della riga di comando per sviluppatori di Azure usa un nome di ambiente per impostare la variabile di ambiente AZURE_ENV_NAME usata dai modelli dell'interfaccia della riga di comando per sviluppatori di Azure. AZURE_ENV_NAME viene usato anche per anteporre il nome del gruppo di risorse di Azure. Poiché ogni ambiente ha un proprio set di configurazioni, l'interfaccia della riga di comando per sviluppatori di Azure 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 comandi azd fanno riferimento al file con estensione env per la configurazione dell'ambiente. Comandi come azd deploy anche aggiornare il file con estensione env con, ad esempio, la stringa di connessione del database 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 funzione secretOrRandomPassword recupera un segreto da Azure Key Vault se vengono forniti 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 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 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)"
  } 

Anche l'output di secretOrRandomPassword deve essere salvato 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 funzione secretOrRandomPassword.
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 metodo secretOrRandomPassword 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 al main.parameters.json nella cartella infra. Per 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, durante azd provision verrà visualizzato un errore arm quando tenta 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, che è 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, 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 Risolvere gli errori comuni di distribuzione di Azure - Azure Resource Manager.

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

Sì.

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 proprietà resourceName in azure.yaml per specificare un nome di risorsa esplicito. In tal caso, la logica precedente non viene eseguita.

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.

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

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

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 Connettere GitHub e Azure | Microsoft Docs.

No. Il comando azd pipeline config 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, la chiamata esplicita di --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.

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. Per 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ì. Sostituire 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 l'AzureDeveloperCliCredential. In alternativa, è possibile configurare l'applicazione in modo da usare un'entità servizio anziché l'AzureDeveloperCliCredential.