Dela via

Vanliga frågor och svar om cli-verktyg och miljö för Azure utvecklare

Den här artikeln innehåller svar på vanliga frågor om verktyg, kommandon och miljöer för Azure Developer CLI (azd).

Allmänna frågor

Följande avsnitt fokuserar på allmänna azd verktyg och miljöfrågor.

Hur avinstallerar jag Azure Developer CLI?

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

Vad är skillnaden mellan Azure Developer CLI och Azure CLI?

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 att etablera/hantera 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 som virtuella datorer, virtuella nätverk och lagring. Azure CLI är utformad kring detaljerade kommandon för specifika administrativa uppgifter.

Mer information finns i Azure Developer CLI jämfört med Azure CLI.

Vad är ett miljönamn?

Azure Developer CLI använder ett miljönamn för att ange miljövariabeln AZURE_ENV_NAME som används av Azure CLI-mallar för utvecklare. AZURE_ENV_NAME används också för att prefixa namnet på Azure resursgrupp. 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 `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

Mer information om arbetsflöden finns i azd init och azd up.

Kan jag konfigurera fler än en miljö?

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.

Var lagras miljökonfigurationsfilen (.env)?

Filsökvägen .env är <your-project-directory-name>\.azure\<your-environment-name>\.env. Mer information finns i Hantera miljövariabler.

Hur används .env-filen?

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

Jag har kört azd up i Codespaces. Kan jag fortsätta mitt arbete i en lokal utvecklingsmiljö?

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.

Hur autentiserar jag i Codespaces om enhetsinloggning har ett problem?

Om du har problem med autentisering av enhetskod i Codespaces (till exempel återkommande 2FA-begäranden eller fel) kan du prova följande lösning med VS Code Desktop:

  1. Öppna ditt Codespace i VS Code Desktop med någon av följande metoder:
    • Använd kommandopaletten (Ctrl+Skift+P på Windows eller Cmd+Skift+P på MacOs) och välj Kodutrymmen: Öppna i VS Code Desktop.
    • Klicka på det nedre vänstra hörnet i Codespace i webbläsaren och välj Öppna i VS Code Desktop).
  2. I VS Code Desktop-terminalen kör du azd auth-inloggningen och slutför den webbläsarbaserade autentiseringen.
  3. När du har autentiserats stänger du VS Code Desktop och återgår till ditt Codespace i webbläsaren. Autentiseringstillståndet bör bevaras.

Hur används filen azure.yaml?

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

Vad är funktionens secretOrRandomPassword beteende?

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å Key Vault 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 till Key Vault med hjälp av 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 en Key Vault och lagra den genererade hemligheten i den använder du koden Bicep nedan. Du kan visa den fullständiga exempelkoden för dessa moduler i 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 konfigurationen 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 en Key Vault 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. Nyckelvalvet skapas inte på nytt om det redan finns, men samma hemliga värde lagras igen för nästa körning.

Kan jag använda Azure kostnadsfri prenumeration?

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.

Min app som är värd hos Azure App Service utlöser en varning om "Bedräglig webbplats upptäckt". Hur kan jag åtgärda det?

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 inmatningen 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 provisionerar 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.

Kan jag arbeta med flera Azure klienter?

Ja. För att autentisera med en specifik klient, använd parameter --tenant-id med kommandot azd auth login.

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

Om du vill azd ha åtkomst till alla dina klienter kan du också hantera MFA-utmaningarna (Multi-Factor Authentication) i webbläsaren först:

  1. Öppna Azure Portal i webbläsaren.
  2. Växla till var och en av dina klienter en i taget. Den här åtgärden utlöser alla nödvändiga MFA-utmaningar och uppdaterar dina token.
  3. Kör azd auth login i terminalen. azd använder webbläsarens befintliga sessions- och åtkomsttoken, som nu är giltiga för alla klienter som du har besökt.

Kan jag köra azd up flera gånger?

Ja. Vi använder inkrementellt distributionsläge. Mer information finns i azd up.

Provisioning

Följande avsnitt fokuserar på azd provisioneringsprocessen.

Kan jag köra azd provision flera gånger?

Ja. Vi använder inkrementellt distributionsläge. Mer information finns i azd provision.

Hur vet azd provision kommandot vilka resurser som ska tilldelas?

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

Var kan jag hitta information om vilka resurser som tillhandahålls i Azure?

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

Hur hittar jag mer information om Azure fel?

Vi använder Bicep-mallar, som finns under <your-project-directory-name>/infra, för att etablera Azure-resurserna. 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ök vanliga Azure distributionsfel – Azure Resource Manager.

Finns det en loggfil för azd provision?

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

Deployment

Följande avsnitt fokuserar på azd distributionsprocessen.

Kan jag köra azd deploy flera gånger?

Ja. Mer information finns i azd deploy .

Hur hittar azd den Azure resurs som jag vill distribuera min kod till?

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 resourceName egenskapen i azure.yaml för att ange ett explicit resursnamn. I så fall körs inte logiken ovan.

Hur distribuerar jag specifika tjänster i mitt projekt medan jag hoppar över andra?

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.

Konfiguration för pipeline

I följande avsnitt fokuseras CI/CD-pipelinekonfigurationen.

Vad är en Azure-tjänst-principal?

En Azure-principidentitet är en identitet som skapas för användning med appar, värdtjänster och automatiserade verktyg för att få å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 hur du autentiserar från Azure till GitHub finns i Anslut GitHub och Azure | Microsoft Docs.

Behöver jag skapa ett Azure tjänstens huvudnamn innan jag kör azd pipeline config?

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 i din GitHub lagringsplats.

Vilka är alla hemligheter som lagras i GitHub?

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.

Vad är OpenID Connect (OIDC) och stöds det?

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

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

  • För Azure DevOps kommer det att resultera i ett fel om man uttryckligen anger --auth-type som federated.
  • 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.

Hur återställer jag Azure tjänstens huvudnamn som lagras i GitHub Actions?

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>",
(...)
}

Var lagras GitHub Actions filen?

Sökvägen för GitHub Actions-filen är <your-project-directory-name>\.github\workflows\azure-dev.yml. Mer information finns i Quickstart: Skapa ett huvudnamn för tjänsten och kör en GitHub-åtgärd.

Kan jag i byggsteget distribuera endast koden i filen azure-dev.yml?

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

Var hittar jag loggen för det GitHub Actions jobb som jag utlöste när jag körde azd pipeline config?

Gå till https://github.com/<your-github-account>/<your-repo>/actions, och konsultera sedan loggfilen i arbetsflödeskörningen.

Skapa ett containerprogram lokalt

Varför kan jag inte köra containerappen som jag skapar lokalt?

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.

  • Last updated on