Häufig gestellte Fragen zur Azure Developer CLI

Je nachdem, wie Sie es ursprünglich installiert haben, gibt es verschiedene Optionen zum Deinstallieren azd. Weitere Informationen finden Sie auf der Installationsseite.

Azure Developer CLI (azd) und Azure CLI (az) sind beide Befehlszeilentools, aber sie helfen Ihnen bei der Ausführung verschiedener Aufgaben.

azd konzentriert sich auf den allgemeinen Entwicklerworkflow. Neben der Bereitstellung/Verwaltung von Azure-Ressourcen hilft azd, Cloudkomponenten, lokale Entwicklungskonfiguration und Pipelineautomatisierung zusammen in einer vollständigen Lösung zu verknüpfen.

Azure CLI ist ein Steuerungsebenentool zum Erstellen und Verwalten von Azure-Infrastruktur wie virtuellen Computern, virtuellen Netzwerken und Speicher. Die Azure CLI ist für präzise Befehle für bestimmte Administrative Aufgaben konzipiert.

Azure Developer CLI verwendet einen Umgebungsnamen, um die umgebungsvariable AZURE_ENV_NAME festzulegen, die von Azure Developer CLI-Vorlagen verwendet wird. AZURE_ENV_NAME wird auch zum Präfix des Azure-Ressourcengruppennamens verwendet. Da jede Umgebung über einen eigenen Satz von Konfigurationen verfügt, speichert die Azure Developer CLI alle Konfigurationsdateien in Umgebungsverzeichnissen.

├── .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. Sie können verschiedene Umgebungen einrichten (z. B. Entwickler, Test, Produktion). Sie können azd env verwenden, um diese Umgebungen zu verwalten.

Der env-Dateipfad ist <your-project-directory-name>\.azure\<your-environment-name>\.env.

In Azure Developer CLI beziehen sich die azd Befehle auf die env-Datei für die Umgebungskonfiguration. Befehle wie azd deploy auch die env-Datei mit der DB-Verbindungszeichenfolge und dem Azure Key Vault-Endpunkt aktualisieren.

Ja. Sie können die Entwicklungsarbeit lokal fortsetzen.

1. Führen Sie azd init -t <template repo> aus, um das Vorlagenprojekt auf Ihren lokalen Computer zu klonen.
2. Führen Sie azd env refreshaus, um den vorhandenen env nach unten zu ziehen, der mit Codespaces erstellt wurde. Stellen Sie sicher, dass Sie denselben Umgebungsnamen, abonnement und standort wie zuvor angeben.

Die Datei "azure.yaml" beschreibt die Apps und Typen von Azure-Ressourcen, die in der Vorlage enthalten sind.

Die secretOrRandomPassword-Funktion ruft einen geheimen Schlüssel aus Azure Key Vault ab, wenn Parameter für den Schlüsseltresornamen und den geheimen Schlüssel bereitgestellt werden. Wenn diese Parameter nicht bereitgestellt werden oder kein geheimer Schlüssel abgerufen werden kann, gibt die Funktion stattdessen ein zufällig generiertes Kennwort zurück.

Im folgenden Beispiel wird ein gängiger Anwendungsfall der secretOrRandomPassword in einer main.parameters.json Datei veranschaulicht. Die variablen ${AZURE_KEY_VAULT_NAME} und sqlAdminPassword werden als Parameter für die Namen des Key Vault und des geheimen Schlüssels übergeben. Wenn der Wert nicht abgerufen werden kann, wird stattdessen ein zufälliges Kennwort generiert.

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

Die Ausgabe von secretOrRandomPassword sollte auch mithilfe von Bicep für zukünftige Ausführungen im Key Vault gespeichert werden. Durch das Abrufen und Erneutes Verwenden derselben geheimen Schlüssel in bereitstellungsübergreifenden Bereitstellungen können Fehler oder unbeabsichtigte Verhaltensweisen verhindert werden, die beim wiederholten Generieren neuer Werte angezeigt werden können. Um einen Key Vault zu erstellen und den generierten Geheimschlüssel darin zu speichern, verwenden Sie den folgenden Bicep-Code. Sie können den vollständigen Beispielcode für diese Module im Azure Developer CLI GitHub-Repositoryanzeigen.

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

Diese Bicep-Einrichtung ermöglicht den folgenden Workflow zum Verwalten Ihrer geheimen Schlüssel:

1. Wenn der angegebene geheime Schlüssel vorhanden ist, wird er mithilfe der secretOrRandomPassword-Funktion aus dem Key Vault abgerufen.
2. Wenn der geheime Schlüssel nicht vorhanden ist, wird ein Schlüsseltresor erstellt, und der zufällig generierte Geheimschlüssel wird darin gespeichert.
3. Bei zukünftigen Bereitstellungen ruft die secretOrRandomPassword-Methode den gespeicherten geheimen Schlüssel ab, nachdem es im Key Vault vorhanden ist. Der Schlüsseltresor wird nicht neu erstellt, wenn er bereits vorhanden ist, aber derselbe geheime Wert wird für die nächste Ausführung erneut gespeichert.

Ja, aber jeder Azure-Standort kann nur eine Bereitstellung haben. Wenn Sie den ausgewählten Azure-Speicherort bereits verwendet haben, wird der Bereitstellungsfehler angezeigt:

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.

Sie können einen anderen Azure-Speicherort auswählen, um das Problem zu beheben.

Dies kann aufgrund unserer Methode zum Benennen von Ressourcen passieren.

Unsere erstellten Azure Dev-Vorlagen ermöglichen das Konfigurieren des Namens der Ressource. Dazu können Sie dem main.parameters.json im Ordner infra einen Eintrag hinzufügen. Zum Beispiel:

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

Dieser Eintrag erstellt eine neue Ressource namens "my-unique-name" anstelle eines zufälligen Werts wie "app-web-aj84u2adj" beim nächsten Bereitstellen der Anwendung. Sie können die alte Ressourcengruppe entweder manuell über das Azure-Portal entfernen oder azd down ausführen, um alle vorherigen Bereitstellungen zu entfernen. Führen Sie nach dem Entfernen der Ressourcen azd provision aus, um sie erneut mit dem neuen Namen zu erstellen.

Dieser Name muss global eindeutig sein, andernfalls wird während azd provision beim Erstellen der Ressource ein ARM-Fehler angezeigt.

Der Befehl verwendet Bicep-Vorlagen, die unter <your-project-directory-name>/infra zur Bereitstellung von Azure-Ressourcen gefunden werden.

Wechseln Sie zu https://portal.azure.com, und suchen Sie dann nach Ihrer Ressourcengruppe, die rg-<your-environment-name>ist.

Wir verwenden Bicep-Vorlagen, die unter <your-project-directory-name>/infrazu finden sind, um Azure-Ressourcen bereitzustellen. Wenn Probleme auftreten, schließen wir die Fehlermeldung in die CLI-Ausgabe ein.

Sie können auch zu https://portal.azure.com wechseln und dann nach Ihrer Ressourcengruppe suchen, die rg-<your-environment-name>ist. Wenn eine der Bereitstellungen fehlschlägt, wählen Sie den Fehlerlink aus, um weitere Informationen zu erhalten.

Weitere Ressourcen finden Sie unter Problembehandlung allgemeiner Azure-Bereitstellungsfehler – Azure Resource Manager.

Demnächst. Dieses Feature ist für eine zukünftige Version geplant.

Ja.

Während der Bereitstellung ermittelt azd zunächst alle Ressourcengruppen, aus denen Ihre Anwendung besteht, indem nach Gruppen gesucht wird, die mit azd-env-name gekennzeichnet sind, und mit einem Wert, der dem Namen Ihrer Umgebung entspricht. Anschließend listet er alle Ressourcen in jeder dieser Ressourcengruppen auf und sucht nach einer Ressource, die mit azd-service-name mit einem Wert markiert ist, der dem Namen Ihres Diensts aus azure.yamlentspricht.

Obwohl die Verwendung von Tags für Ressourcen empfohlen wird, können Sie auch die resourceName-Eigenschaft in azure.yaml verwenden, um einen expliziten Ressourcennamen anzugeben. In diesem Fall wird die oben genannte Logik nicht ausgeführt.

Bei der Bereitstellung Ihres Projekts können Sie bestimmte Dienste entweder durch Angeben des Dienstnamens im Befehl (d. h. azd deploy api) oder durch Navigieren zu einem Unterordner auswählen, der nur die Dienste enthält, die Sie bereitstellen möchten. Dabei werden alle anderen Dienste als - Skippedaufgeführt.

Wenn Sie keine Dienste überspringen möchten, müssen Sie entweder den Befehl aus dem Stammordner ausführen oder dem Befehl das --all Flag hinzufügen.

Ja. Wir verwenden den inkrementellen Bereitstellungsmodus.

Demnächst. Dieses Feature ist für eine zukünftige Version geplant.

Ein Azure-Dienstprinzipal ist eine Identität, die für die Verwendung mit Apps, gehosteten Diensten und automatisierten Tools für den Zugriff auf Azure-Ressourcen erstellt wird. Dieser Zugriff ist durch die Rollen eingeschränkt, die dem Dienstprinzipal zugewiesen sind, wodurch Sie steuern können, auf welche Ressourcen zugegriffen werden kann und auf welcher Ebene. Weitere Informationen zur Authentifizierung von Azure auf GitHub finden Sie unter Verbinden von GitHub und Azure | Microsoft Docs.

Nein. Der Befehl azd pipeline config übernimmt die Erstellung des Azure-Dienstprinzipals und führt die erforderlichen Schritte aus, um die geheimen Schlüssel in Ihrem GitHub-Repository zu speichern.

Der Befehl speichert vier geheime Schlüssel in GitHub: AZURE_CREDENTIALS, AZURE_ENV_NAME, AZURE_LOCATION und AZURE_SUBSCRIPTION_ID. Sie können den Wert jedes geheimen Schlüssels überschreiben, indem Sie zu https://github.com/<your-GH-account>/<your-repo>/secrets/actionswechseln.

Mit OpenID Connectkönnen Ihre Workflows kurzlebige Token direkt aus Azure austauschen.

Während OIDC als Standard für GitHub-Aktionen und Azure-Pipeline unterstützt wird (als Verbund-festgelegt), wird es für Azure DevOps oder Terraform nicht unterstützt.

• Bei Azure DevOps führt das explizite Aufrufen --auth-type als federated zu einem Fehler.
• Für Terraform:
  • Wenn --auth-type nicht definiert ist, wird sie auf clientcredentials zurückfallen und führt zu einer Warnung.
  • Wenn --auth-type explizit auf federatedfestgelegt ist, führt dies zu einem Fehler.

Wechseln Sie zu https://github.com/<your-GH-account>/<your-repo>settings/secrets/actions, und aktualisieren Sie dann AZURE_CREDENTIALS, indem Sie das gesamte JSON-Objekt für den neuen Dienstprinzipal kopieren und einfügen. Zum Beispiel:

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

Der GitHub Actions-Dateipfad ist <your-project-directory-name>\.github\workflows\azure-dev.yml.

Ja. Ersetzen Sie run: azd up --no-prompt durch run: azd deploy --no-prompt.

Wechseln Sie zu https://github.com/<your-GH-account>/<your-repo>/actions, und verweisen Sie dann in der Workflowausführung auf die Protokolldatei.

Beim lokalen Erstellen von Containeranwendungen müssen Sie azd auth login im Container ausführen, damit die Anwendung mit dem AzureDeveloperCliCredentialarbeitet. Alternativ können Sie Ihre Anwendung so konfigurieren, dass anstelle der AzureDeveloperCliCredentialein Dienstprinzipal verwendet wird.