Vanliga frågor och svar om Azure Developer CLI

Det finns olika alternativ för att avinstallera azd beroende på hur du ursprungligen installerade den. Mer information finns på installationssidan för .

Azure Developer CLI (azd) och Azure CLI (az) är båda kommandoradsverktyg, men de hjälper dig att utföra olika uppgifter.

azd fokuserar på arbetsflödet för utvecklare på hög nivå. Förutom etablering/hantering av Azure-resurser hjälper azd till att sammanfoga molnkomponenter, lokal utvecklingskonfiguration och pipelineautomatisering till en komplett lösning.

Azure CLI är ett kontrollplansverktyg för att skapa och administrera Azure-infrastruktur, till exempel virtuella datorer, virtuella nätverk och lagring. Azure CLI är utformat för detaljerade kommandon för specifika administrativa uppgifter.

Azure Developer CLI använder ett miljönamn för att ange den AZURE_ENV_NAME miljövariabel som används av Azure Developer CLI-mallar. AZURE_ENV_NAME används också för att prefixa Namnet på Azure-resursgruppen. Eftersom varje miljö har en egen uppsättning konfigurationer lagrar Azure Developer CLI alla konfigurationsfiler i miljökataloger.

├── .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 

Ja. Du kan konfigurera olika miljöer (till exempel dev, test, produktion). Du kan använda azd env för att hantera dessa miljöer.

Filsökvägen .env är <your-project-directory-name>\.azure\<your-environment-name>\.env.

I Azure Developer CLI refererar azd-kommandona till .env-filen för miljökonfiguration. Kommandon som azd deploy även uppdatera .env-filen med till exempel db-anslutningssträngen och Azure Key Vault-slutpunkten.

Ja. Du kan fortsätta utvecklingsarbetet lokalt.

1. Kör azd init -t <template repo> för att klona mallprojektet till den lokala datorn.
2. Kör azd env refreshför att hämta den befintliga env som skapats med hjälp av Codespaces. Se till att du anger samma miljönamn, prenumeration och plats som tidigare.

Filen azure.yaml beskriver de appar och typer av Azure-resurser som ingår i mallen.

Funktionen secretOrRandomPassword hämtar en hemlighet från Azure Key Vault om parametrar för nyckelvalvets namn och hemlighet anges. Om dessa parametrar inte anges eller om en hemlighet inte kan hämtas returnerar funktionen ett slumpmässigt genererat lösenord som ska användas i stället.

I följande exempel visas ett vanligt användningsfall för secretOrRandomPassword i en main.parameters.json fil. Variablerna ${AZURE_KEY_VAULT_NAME} och sqlAdminPassword skickas som parametrar för namnen på Nyckelvalvet och hemligheten. Om värdet inte kan hämtas genereras ett slumpmässigt lösenord i stället.

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

Utdata från secretOrRandomPassword bör också sparas i Key Vault med Bicep för framtida körningar. Om du hämtar och återanvänder samma hemligheter mellan distributioner kan du förhindra fel eller oavsiktliga beteenden som kan uppstå när nya värden genereras upprepade gånger. Om du vill skapa ett Key Vault och lagra den genererade hemligheten i det använder du Bicep-koden nedan. Du kan visa den fullständiga exempelkoden för dessa moduler på Azure Developer CLI GitHub-lagringsplatsen.

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
  }
}]

Den här Bicep-installationen aktiverar följande arbetsflöde för att hantera dina hemligheter:

1. Om den angivna hemligheten finns hämtas den från Key Vault med hjälp av funktionen secretOrRandomPassword.
2. Om hemligheten inte finns skapas ett Nyckelvalv och den slumpmässigt genererade hemligheten lagras i den.
3. Vid framtida distributioner hämtar metoden secretOrRandomPassword den lagrade hemligheten nu när den finns i Key Vault. Key Vault återskapas inte om det redan finns, men samma hemliga värde lagras igen för nästa körning.

Ja, men varje Azure-plats kan bara ha en distribution. Om du redan har använt den valda Azure-platsen visas distributionsfelet:

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.

Du kan välja en annan Azure-plats för att åtgärda problemet.

Detta kan inträffa på grund av vår metod för att namnge resurser.

Våra "Azure Dev"-skapade mallar gör det möjligt att konfigurera namnet på resursen. Om du vill göra det kan du lägga till en post i main.parameters.json i mappen infra. Till exempel:

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

Den här posten skapar en ny resurs med namnet "my-unique-name" i stället för ett slumpmässigt värde, till exempel "app-web-aj84u2adj" nästa gång du etablerar ditt program. Du kan antingen ta bort den gamla resursgruppen manuellt med hjälp av Azure-portalen eller köra azd down för att ta bort alla tidigare distributioner. När du har tagit bort resurserna kör du azd provision för att skapa dem igen med det nya namnet.

Det här namnet måste vara globalt unikt, annars får du ett ARM-fel under azd provision när den försöker skapa resursen.

Kommandot använder Bicep-mallar som finns under <your-project-directory-name>/infra för att etablera Azure-resurser.

Gå till https://portal.azure.com och leta sedan efter resursgruppen, som är rg-<your-environment-name>.

Vi använder Bicep-mallar som finns under <your-project-directory-name>/infraför att etablera Azure-resurser. Om det finns problem tar vi med felmeddelandet i CLI-utdata.

Du kan också gå till https://portal.azure.com och sedan leta efter resursgruppen, som är rg-<your-environment-name>. Om någon av distributionerna misslyckas väljer du fellänken för att få mer information.

Andra resurser finns i Felsöka vanliga Azure-distributionsfel – Azure Resource Manager-.

Kommer snart. Den här funktionen planeras för en framtida version.

Ja.

Under distributionen identifierar azd först alla resursgrupper som utgör ditt program genom att leta efter grupper taggade med azd-env-name och med ett värde som matchar namnet på din miljö. Sedan räknas alla resurser upp i var och en av dessa resursgrupper och letar efter en resurs taggad med azd-service-name med ett värde som matchar namnet på din tjänst från azure.yaml.

Vi rekommenderar att du använder taggar för resurser, men du kan också använda egenskapen resourceName i azure.yaml för att ange ett explicit resursnamn. I så fall körs inte logiken ovan.

När du distribuerar projektet kan du välja att distribuera specifika tjänster antingen genom att ange tjänstnamnet i kommandot (d.v.s. azd deploy api) eller genom att navigera till en undermapp som bara innehåller de tjänster som du vill distribuera. När du gör det visas alla andra tjänster som - Skipped.

Om du inte vill hoppa över några tjänster måste du antingen köra kommandot från rotmappen eller lägga till flaggan --all i kommandot.

Ja. Vi använder inkrementell distributionsläge.

Kommer snart. Den här funktionen planeras för en framtida version.

Ett Huvudnamn för Azure-tjänsten är en identitet som skapas för användning med appar, värdbaserade tjänster och automatiserade verktyg för åtkomst till Azure-resurser. Den här åtkomsten begränsas av de roller som tilldelas tjänstens huvudnamn, vilket ger dig kontroll över vilka resurser som kan nås och på vilken nivå. Mer information om autentisering från Azure till GitHub finns i Ansluta GitHub och Azure | Microsoft Docs.

Nej. Kommandot azd pipeline config tar hand om att skapa Azure-tjänstens huvudnamn och utföra de steg som krävs för att lagra hemligheterna på din GitHub-lagringsplats.

Kommandot lagrar fyra hemligheter i GitHub: AZURE_CREDENTIALS, AZURE_ENV_NAME, AZURE_LOCATION och AZURE_SUBSCRIPTION_ID. Du kan åsidosätta värdet för varje hemlighet genom att gå till https://github.com/<your-github-account>/<your-repo>/secrets/actions.

Med OpenID Connectkan dina arbetsflöden utbyta kortlivade token direkt från Azure.

OIDC stöds som standard för GitHub Actions och Azure Pipeline (anges som federerade), men stöds inte för Azure DevOps eller Terraform.

• För Azure DevOps resulterar det uttryckligen i att --auth-type som federated resulterar i ett fel.
• För Terraform:
  • Om --auth-type inte har definierats återgår det till clientcredentials och resulterar i en varning.
  • Om --auth-type uttryckligen anges till federatedresulterar det i ett fel.

Gå till https://github.com/<your-github-account>/<your-repo>settings/secrets/actionsoch uppdatera sedan AZURE_CREDENTIALS genom att kopiera och klistra in hela JSON-objektet för det nya tjänstens huvudnamn. Till exempel:

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

GitHub Actions-filsökvägen är <your-project-directory-name>\.github\workflows\azure-dev.yml.

Ja. Ersätt run: azd up --no-prompt med run: azd deploy --no-prompt.

Gå till https://github.com/<your-github-account>/<your-repo>/actionsoch referera sedan till loggfilen i arbetsflödeskörningen.

När du skapar containerprogram lokalt måste du köra azd auth login i containern för att programmet ska fungera med AzureDeveloperCliCredential. Du kan också konfigurera programmet så att det använder tjänstens huvudnamn i stället för AzureDeveloperCliCredential.