Häufig gestellte Fragen zur Azure Developer CLI

Es gibt verschiedene Optionen für die azd Deinstallation, je nachdem, wie Sie es ursprünglich installiert haben. Weitere Informationen finden Sie auf der Installationsseite .

Azure Developer CLI () und Azure CLI (azazd) 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 in einer vollständigen Lösung zusammengeführt werden.

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 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. Entwickler, Test, Produktion). 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 z. B. aktualisieren die env-Datei auch mit dem db-Verbindungszeichenfolge und dem Azure Key Vault-Endpunkt.

Ja. Sie können die Entwicklungsarbeit lokal fortsetzen.

1. Führen Sie den Befehl aus azd init -t <template repo> , um das Vorlagenprojekt auf Ihrem lokalen Computer zu klonen.
2. Führen Sie aus azd env refresh, um den vorhandenen env, der mit Codespaces erstellt wurde, nach unten zu ziehen. 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, das verwendet werden soll.

Im folgenden Beispiel wird ein gängiger Anwendungsfall der secretOrRandomPassword Datei main.parameters.json veranschaulicht. Die ${AZURE_KEY_VAULT_NAME} Variablen sqlAdminPassword und Variablen 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ü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 GitHub-Repository der 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 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 er 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 Ordner infra einen Eintrag hinzufügen. 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 ausführen azd down , um alle vorherigen Bereitstellungen zu entfernen. Nachdem Sie die Ressourcen entfernt haben, führen Sie die Schritte azd provision aus, um sie erneut mit dem neuen Namen zu erstellen.

Dieser Name muss global eindeutig sein, andernfalls erhalten Sie während des azd provision Versuchs, die Ressource zu erstellen, einen ARM-Fehler.

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

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

Wir verwenden Bicep-Vorlagen, die unter <your-project-directory-name>/infra"Azure-Ressourcen" 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 Ihrer Ressourcengruppe wechseln und dann nach Ihrer Ressourcengruppe suchen, was heißt rg-<your-environment-name>. 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.

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

Ja.

Bei der Bereitstellung werden zunächst alle Ressourcengruppen ermittelt, aus denen Ihre Anwendung besteht, azd indem nach Gruppen gesucht wird, die mit azd-env-name und mit einem Wert gekennzeichnet sind, 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 einem Wert markiert ist, der dem Namen Ihres Diensts azure.yamlentspricht.

Obwohl die Verwendung von Tags für Ressourcen empfohlen wird, können Sie die resourceName Eigenschaft azure.yaml auch 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 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 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.

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

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

• Bei Azure DevOps wird explizit aufgerufen --auth-type , da federated ein Fehler auftritt.
• Für Terraform:
  • Wenn --auth-type sie nicht definiert ist, wird sie wieder auf clientcredentials sie zurückfallen und führt zu einer Warnung.
  • Wenn --auth-type dieser 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 AZURE_CREDENTIALS Sie dann, indem Sie das gesamte JSON-Objekt für den neuen Dienstprinzipal kopieren und einfügen. 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 auf die Protokolldatei in der Workflowausführung.

Beim lokalen Erstellen von Containeranwendungen müssen Sie im Container ausgeführt werden azd auth login , damit die Anwendung mit der AzureDeveloperCliCredentialAnwendung arbeitet. Alternativ können Sie Ihre Anwendung so konfigurieren, dass anstelle des AzureDeveloperCliCredentialDienstprinzipals ein Dienstprinzipal verwendet wird.