Häufig gestellte Fragen zur Azure Developer CLI

Es gibt verschiedene Optionen für die Deinstallation von azd, je nach der ursprünglichen Art und Weise der Installation. Details 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 azd können Cloudkomponenten, lokale Entwicklungskonfiguration und Pipelineautomatisierung damit zu einer vollständigen Lösung zusammengefasst werden.

Azure CLI ist ein Tool auf Steuerungsebene zum Erstellen und Verwalten von Azure-Infrastruktur wie virtuelle Computer, virtuelle Netzwerke und Speicher. Azure CLI ist für präzise Befehle für bestimmte Verwaltungsaufgaben konzipiert.

Azure Developer CLI verwendet einen Umgebungsnamen, um die von Azure Developer CLI-Vorlagen verwendete AZURE_ENV_NAMEUmgebungsvariable festzulegen. AZURE_ENV_NAME wird auch als Präfix für den Namen der Azure-Ressourcengruppe verwendet. Da jede Umgebung ihre eigene Zusammenstellung von Konfigurationen besitzt, speichert 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. dev, test, production). Sie können azd env verwenden, um diese Umgebungen zu verwalten.

Der Pfad der ENV-Datei 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 aktualisieren die env-Datei auch mit der db-Verbindungszeichenfolge und dem Azure Key Vault-Endpunkt.

Ja. Sie können die Entwicklungsarbeit lokal fortsetzen.

1. Führen Sie den Befehl azd init -t <template repo> aus, um das Vorlagenprojekt auf Ihrem lokalen Computer zu klonen.
2. Führen Sie azd env refresh aus, um die mit Codespaces erstellte env nach unten zu ziehen. Stellen Sie sicher, dass Sie denselben Umgebungsnamen, das Abonnement und den Standort wie zuvor angeben.

Die azure.yaml-Datei 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, das verwendet werden soll.

Im folgenden Beispiel wird ein gängiger Anwendungsfall für 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 in Key Vault gespeichert werden, indem Bicep für zukünftige Ausführungen verwendet wird. Durch das Abrufen und Erneutes Verwenden derselben geheimen Schlüssels 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 GitHub-Repository von Azure Developer CLI anzeigen.

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 Key Vault 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, da er nun 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 folgende 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 vorkommen.

Unsere erstellten Azure Dev-Vorlagen ermöglichen das Konfigurieren des Ressourcennamens. Dazu können Sie einen Eintrag zu main.parameters.json im Ordner infra 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 mithilfe des Azure-Portals entfernen oder azd down ausführen, um alle vorherigen Bereitstellungen zu entfernen. Nachdem Sie die Ressourcen entfernt haben, führen Sie azd provision aus, um sie erneut mit dem neuen Namen zu erstellen.

Dieser Name muss global eindeutig sein, andernfalls erhalten Sie einen ARM-Fehler, wenn azd provision versucht, die Ressource zu erstellen.

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

Wechseln Sie zu https://portal.azure.com und suchen Sie dann nach Ihrer Ressourcengruppe mit dem Namenrg-<your-environment-name>.

Zur Bereitstellung von Azure-Ressourcen verwenden wir Bicep-Vorlagen, die unter <your-project-directory-name>/infra zur Verfügung stehen. 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 mit dem Namen rg-<your-environment-name> suchen. Wenn eine der Bereitstellungen fehlschlägt, wählen Sie den Fehlerlink aus, um weitere Informationen zu erhalten.

Weitere Ressourcen finden Sie unter Beheben gängiger Azure-Bereitstellungsfehler – Azure Resource Manager.

Bald verfügbar. Diese Funktion ist für zukünftige Versionen geplant.

Ja.

Bei der Bereitstellung werden von azd zunächst alle Ressourcengruppen ermittelt, aus denen Ihre Anwendung besteht, indem nach Gruppen gesucht wird, die mit azd-env-name und mit einem Wert gekennzeichnet sind, der dem Namen Ihrer Umgebung entspricht. Anschließend werden alle Ressourcen in jeder dieser Ressourcengruppen aufgelistet und es wird nach einer Ressource gesucht, die mit azd-service-name und einem Wert gekennzeichnet ist, der dem Namen Ihres Diensts aus azure.yaml entspricht.

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.

Ja. Wir verwenden den inkrementellen Bereitstellungsmodus.

Bald verfügbar. Diese Funktion ist für zukünftige Versionen geplant.

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

Nein Der azd pipeline config-Befehl kümmert sich um das Erstellen des Azure-Dienstprinzipals und das Ausführen der erforderlichen Schritte zum Speichern der geheimen Schlüssel in Ihrem GitHub-Repository.

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/actions wechseln.

Mit OpenID Connect können Ihre Workflows kurzlebige Token direkt über Azure austauschen.

OIDC wird zwar als Standard für GitHub Actions und Azure Pipeline (als Verbund festgelegt) unterstützt, für Azure DevOps oder Terraform jedoch nicht.

• Bei Azure DevOps wird --auth-type explizit aufgerufen, da federated fehlschlagen wird.
• Für Terraform:
  • Wenn --auth-type nicht definiert ist, fällt es zurück auf clientcredentials, was in einer Warnung resultiert.
  • Wenn --auth-type explizit auf federated festgelegt ist, führt dies zu einem Fehler.

Wechseln Sie zu https://github.com/<your-GH-account>/<your-repo>settings/secrets/actions, und aktualisieren Sie 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 lautet <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 auf die Protokolldatei in der Workflowausführung.

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