Vanliga frågor om Azure Developer CLI

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

Både Azure Developer CLI (azd) och Azure CLI (az) är 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 att etablera/hantera Azure-resurser hjälper azd det 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 miljövariabeln AZURE_ENV_NAME som används i Azure Developer CLI-mallar. AZURE_ENV_NAME används också som prefix i 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 till att hantera dessa miljöer.

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

I Azure Developer CLI azd refererar kommandona till .env-filen för miljökonfiguration. Kommandon som azd deploy även uppdaterar .env-filen med till exempel db-anslutningssträng 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. Om du vill hämta den befintliga env som skapats med hjälp av Codespaces kör du azd env refresh. 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 i stället 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 för 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 secretOrRandomPassword funktionen .
2. Om hemligheten inte finns skapas ett Nyckelvalv och den slumpmässigt genererade hemligheten lagras i den.
3. Vid framtida distributioner secretOrRandomPassword hämtar metoden 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 main.parameters.json en post i mappen i 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 när azd provision det 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>/infra, fö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 azd identifierar du 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 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 resourceName egenskapen i azure.yaml för att ange ett explicit resursnamn. I så fall körs inte logiken ovan.

Ja. Vi använder det inkrementella distributionsläget.

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 Anslut 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-GH-account>/<your-repo>/secrets/actions.

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

Även om OIDC stöds som standard för GitHub Actions och Azure Pipeline (anges som federerade) stöds det inte för Azure DevOps eller Terraform.

• För Azure DevOps resulterar det uttryckligen --auth-typefederated 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 anges uttryckligen till federatedresulterar det i ett fel.

Gå till https://github.com/<your-GH-account>/<your-repo>settings/secrets/actionsoch uppdatera AZURE_CREDENTIALS sedan 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-GH-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.