Nejčastější dotazy k Azure Developer CLI

Existují různé možnosti odinstalace azd v závislosti na tom, jak jste ho původně nainstalovali. Podrobnosti najdete na stránce instalace.

Azure Developer CLI () i Azure CLI (azazd) jsou nástroje příkazového řádku, ale pomáhají provádět různé úlohy.

azd zaměřuje se na pracovní postup vývojáře vysoké úrovně. Kromě zřizování a správy prostředků azd Azure pomáhá spojit cloudové komponenty, místní konfiguraci vývoje a automatizaci kanálů společně do kompletního řešení.

Azure CLI je nástroj řídicí roviny pro vytváření a správu infrastruktury Azure, jako jsou virtuální počítače, virtuální sítě a úložiště. Rozhraní příkazového řádku Azure je navržené podle podrobných příkazů pro konkrétní úlohy správy.

Azure Developer CLI používá název prostředí k nastavení proměnné prostředí AZURE_ENV_NAME, kterou používají šablony Azure Developer CLI. AZURE_ENV_NAME se používá také jako předpona názvu skupiny prostředků Azure. Vzhledem k tomu, že každé prostředí má vlastní sadu konfigurací, Azure Developer CLI ukládá všechny konfigurační soubory do adresářů prostředí.

├── .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 

Ano. Můžete nastavit různá prostředí (například vývoj, testování, produkční prostředí). Ke správě těchto prostředí můžete použít azd env.

Cesta k souboru .env je: <your-project-directory-name>\.azure\<your-environment-name>\.env.

V Azure Developer CLI azd příkazy odkazují na soubor .env pro konfiguraci prostředí. Příkazy, jako azd deploy je například aktualizace souboru .env, například db připojovací řetězec a koncového bodu služby Azure Key Vault.

Ano. Místně můžete pokračovat ve vývoji.

1. Spusťte azd init -t <template repo> klonování projektu šablony do místního počítače.
2. Pokud chcete stáhnout existující env vytvořený pomocí Codespaces, spusťte azd env refresh. Ujistěte se, že jste zadali stejný název prostředí, předplatné a umístění jako předtím.

Soubor azure.yaml popisuje aplikace a typy prostředků Azure, které jsou součástí šablony.

Funkce secretOrRandomPassword načte tajný klíč ze služby Azure Key Vault, pokud jsou k dispozici parametry pro název trezoru klíčů a tajný klíč. Pokud tyto parametry nejsou zadané nebo tajný kód nelze načíst, funkce místo toho vrátí náhodně vygenerované heslo, které se má použít.

Následující příklad ukazuje běžný případ secretOrRandomPassword použití v main.parameters.json souboru. Proměnné ${AZURE_KEY_VAULT_NAME} se sqlAdminPassword předávají jako parametry pro názvy služby Key Vault a tajný klíč. Pokud hodnotu nelze načíst, vygeneruje se místo toho náhodné heslo.

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

Výstup secretOrRandomPassword by se měl také uložit do služby Key Vault pomocí Bicep pro budoucí spuštění. Načítání a opakované použití stejných tajných kódů napříč nasazeními může zabránit chybám nebo neúmyslnému chování, které se může zobrazit při opakovaném generování nových hodnot. Pokud chcete vytvořit key Vault a uložit v něm vygenerovaný tajný klíč, použijte níže uvedený kód Bicep. Úplný ukázkový kód pro tyto moduly si můžete prohlédnout v úložišti GitHub v Azure Developer CLI.

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

Toto nastavení Bicep umožňuje správu tajných kódů pomocí následujícího pracovního postupu:

1. Pokud zadaný tajný klíč existuje, načte se ze služby Key Vault pomocí secretOrRandomPassword funkce.
2. Pokud tajný klíč neexistuje, vytvoří se služba Key Vault a náhodně vygenerovaný tajný klíč se uloží do něj.
3. Při budoucích nasazeních secretOrRandomPassword metoda načte uložený tajný klíč, který teď existuje ve službě Key Vault. Key Vault se znovu nevytvoří, pokud už existuje, ale stejná hodnota tajného kódu se znovu uloží pro další spuštění.

Ano, ale každé umístění Azure může mít pouze jedno nasazení. Pokud jste už vybrané umístění Azure použili, zobrazí se chyba nasazení:

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.

Problém můžete vyřešit výběrem jiného umístění Azure.

K tomu může dojít kvůli naší metodě pojmenování prostředků.

Naše vytvořené šablony Azure Pro vývoj umožňují konfigurovat název prostředku. Uděláte to tak, že do složky přidáte položku main.parameters.jsoninfra . Příklad:

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

Tato položka vytvoří nový prostředek s názvem my-unique-name místo randomizované hodnoty, například app-web-aj84u2adj při příštím zřízení aplikace. Starou skupinu prostředků můžete buď odebrat ručně pomocí webu Azure Portal, nebo ji můžete spustit azd down a odebrat všechna předchozí nasazení. Po odebrání prostředků je spusťte azd provision a vytvořte je znovu s novým názvem.

Tento název musí být globálně jedinečný, jinak se při azd provision pokusu o vytvoření prostředku zobrazí chyba ARM.

Příkaz používá šablony Bicep, které se nacházejí v části <your-project-directory-name>/infra zřizování prostředků Azure.

Přejděte do https://portal.azure.com a vyhledejte skupinu prostředků, což je rg-<your-environment-name>.

Ke zřízení prostředků Azure používáme šablony Bicep, které najdete v části <your-project-directory-name>/infra. Pokud dojde k problémům, zahrneme chybovou zprávu do výstupu rozhraní příkazového řádku.

Můžete také přejít na https://portal.azure.com skupinu prostředků a pak vyhledat skupinu prostředků, což je rg-<your-environment-name>. Pokud některá z nasazení selže, vyberte odkaz na chybu a získejte další informace.

Další prostředky najdete v tématu Řešení běžných chyb nasazení Azure – Azure Resource Manager.

Již brzy. Tato funkce se plánuje pro budoucí verzi.

Ano.

Během nasazování nejprve zjistí všechny skupiny prostředků, azd které tvoří vaši aplikaci, vyhledáním skupin označených azd-env-name a hodnotou, která odpovídá názvu vašeho prostředí. Pak vytvoří výčet všech prostředků v každé z těchto skupin prostředků a vyhledá prostředek označený azd-service-name hodnotou, která odpovídá názvu vaší služby z azure.yaml.

I když u prostředků doporučujeme používat značky, můžete vlastnost azure.yaml použít resourceName také k zadání explicitního názvu prostředku. V takovém případě se výše uvedená logika nespustí.

Ano. Používáme režim přírůstkového nasazení.

Již brzy. Tato funkce se plánuje pro budoucí verzi.

Instanční objekt Azure je identita vytvořená pro použití s aplikacemi, hostovanými službami a automatizovanými nástroji pro přístup k prostředkům Azure. Tento přístup je omezený rolemi, které jsou přiřazeny k instančnímu objektu, což vám dává kontrolu nad tím, ke kterým prostředkům je možné přistupovat, a na jaké úrovni. Další informace o ověřování z Azure do GitHubu najdete v tématu Připojení GitHubu a Azure | Microsoft Docs.

Ne. Příkaz azd pipeline config se postará o vytvoření instančního objektu Azure a provedení nezbytných kroků k uložení tajných kódů do úložiště GitHub.

Příkaz ukládá čtyři tajné kódy na GitHubu: AZURE_CREDENTIALS, AZURE_ENV_NAME, AZURE_LOCATION a AZURE_SUBSCRIPTION_ID. Hodnotu každého tajného kódu můžete přepsat tak, že přejdete na https://github.com/<your-GH-account>/<your-repo>/secrets/actions.

Pomocí OpenID Connectu si mohou vaše pracovní postupy vyměňovat krátkodobé tokeny přímo z Azure.

I když se OIDC podporuje jako výchozí pro GitHub Actions a Azure Pipeline (nastavené jako federované), azure DevOps ani Terraform se nepodporuje.

• V případě Azure DevOps explicitně volají --auth-type , protože federated výsledkem bude chyba.
• Pro Terraform:
  • Pokud --auth-type není definovaná, vrátí clientcredentials se zpět a výsledkem bude upozornění.
  • Pokud --auth-type je explicitně nastavená federated, dojde k chybě.

Přejděte na https://github.com/<your-GH-account>/<your-repo>settings/secrets/actionspoložku a pak aktualizujte AZURE_CREDENTIALS zkopírováním a vložením celého objektu JSON pro nový instanční objekt. Příklad:

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

Cesta k souboru GitHub Actions je <your-project-directory-name>\.github\workflows\azure-dev.yml.

Ano. Nahraďte run: azd up --no-promptrun: azd deploy --no-prompt.

Přejděte na https://github.com/<your-GH-account>/<your-repo>/actionspříkaz a pak se podívejte na soubor protokolu ve spuštění pracovního postupu.

Při vytváření kontejnerových aplikací místně musíte spustit azd auth login v kontejneru, aby aplikace fungovala s aplikací AzureDeveloperCliCredential. Případně můžete aplikaci nakonfigurovat tak, aby místo instančního objektu používala AzureDeveloperCliCredentialinstanční objekt.