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 (azd) a Azure CLI (az) jsou nástroje příkazového řádku, ale pomáhají provádět různé úlohy.

azd se zaměřuje na pracovní postup vývojáře vysoké úrovně. Kromě zřizování a správy prostředků Azure azd pomáhá spojit cloudové komponenty, místní konfiguraci vývoje a automatizaci kanálů 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 slouží také k předponě názvu skupiny prostředků Azure. Vzhledem k tomu, že každé prostředí má vlastní sadu konfigurací, ukládá Azure Developer CLI 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 příkazy azd odkazují na soubor .env pro konfiguraci prostředí. Příkazy jako azd deploy také aktualizují soubor .env například připojovacím řetězcem databáze a koncovým bodem služby Azure Key Vault.

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

1. Spuštěním azd init -t <template repo> naklonujte projekt šablony do místního počítače.
2. Pokud chcete stáhnout existující prostředí 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 a tajný klíč trezoru klíčů. Pokud tyto parametry nejsou zadané nebo tajný kód nelze načíst, funkce místo toho vrátí náhodně vygenerované heslo.

Následující příklad ukazuje běžný případ použití secretOrRandomPassword v souboru main.parameters.json. Proměnné ${AZURE_KEY_VAULT_NAME} a sqlAdminPassword se 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ý vzorový kód pro tyto moduly si můžete prohlédnout v úložišti Azure Developer CLI na GitHubu.

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í funkce secretOrRandomPassword.
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 metoda secretOrRandomPassword 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 main.parameters.json ve složce infra přidáte položku. Napří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 spustit azd down a odebrat všechna předchozí nasazení. Po odebrání prostředků spusťte azd provision a vytvořte je znovu s novým názvem.

Tento název bude muset být globálně jedinečný, jinak se během azd provision při 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 ke zřízení prostředků Azure.

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

K zřizování 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 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í azd nejprve zjistí všechny skupiny prostředků, 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í. Potom 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 také použít vlastnost resourceName v azure.yaml k zadání explicitního názvu prostředku. V takovém případě se výše uvedená logika nespustí.

Při nasazování projektu se můžete rozhodnout nasadit konkrétní služby zadáním názvu služby v příkazu (tj. azd deploy api) nebo přechodem do podsložky, která obsahuje pouze služby, které chcete nasadit. Když to uděláte, budou všechny ostatní služby uvedeny jako - Skipped.

Pokud nechcete přeskočit žádné služby, nezapomeňte buď spustit příkaz z kořenové složky, nebo přidat příznak --all do příkazu.

Ano. Používámerežimu 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 na 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ů pro 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.

S OpenID Connectmůžou 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é), pro Azure DevOps ani Terraform se nepodporuje.

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

Přejděte na https://github.com/<your-GH-account>/<your-repo>settings/secrets/actionsa potom aktualizujte AZURE_CREDENTIALS zkopírováním a vložením celého objektu JSON pro nový instanční objekt. Napří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>/actionsa pak přejděte na soubor protokolu ve spuštění pracovního postupu.

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