Azure Developer CLI – gyakori kérdések

A azd eltávolításának különböző lehetőségei vannak attól függően, hogy eredetileg hogyan telepítette. A részletekért látogasson el a telepítési oldalára.

Azure Developer CLI (azd) és Azure CLI (az) egyaránt parancssori eszközök, de különböző feladatok elvégzésében segítenek.

azd a magas szintű fejlesztői munkafolyamatra összpontosít. Az Azure-erőforrások kiépítése/kezelése mellett azd segít a felhőösszetevők, a helyi fejlesztési konfiguráció és a folyamatautomatizálás teljes megoldássá alakításában.

Az Azure CLI egy vezérlősík-eszköz az Azure-infrastruktúra, például a virtuális gépek, a virtuális hálózatok és a tárolók létrehozásához és felügyeletéhez. Az Azure CLI konkrét felügyeleti feladatok részletes parancsai köré van tervezve.

Az Azure Developer CLI egy környezetnév használatával állítja be az Azure Developer CLI-sablonok által használt AZURE_ENV_NAME környezeti változót. AZURE_ENV_NAME az Azure-erőforráscsoport nevének előtagját is használja. Mivel minden környezet saját konfigurációkészlettel rendelkezik, az Azure Developer CLI az összes konfigurációs fájlt környezeti könyvtárakban tárolja.

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

Igen. Különböző környezeteket (például fejlesztés, tesztelés, éles környezet) állíthat be. Ezeket a környezeteket azd env kezelheti.

Az .env fájl elérési útja <your-project-directory-name>\.azure\<your-environment-name>\.env.

Az Azure Developer CLI-ben a azd parancsok az .env fájlra vonatkoznak a környezetkonfigurációhoz. Az olyan parancsok, mint azd deploy az .env fájlt is frissítik például a db kapcsolati sztringjével és az Azure Key Vault végpontjával.

Igen. Helyileg folytathatja a fejlesztést.

1. Futtassa a azd init -t <template repo> a sablonprojekt klónozásához a helyi gépre.
2. A Codespaces használatával létrehozott meglévő env lekéréséhez futtassa azd env refresh. Győződjön meg arról, hogy ugyanazt a környezetnevet, előfizetést és helyet adja meg, mint korábban.

Az azure.yaml fájl a sablonban található Azure-erőforrások alkalmazásait és típusait ismerteti.

A secretOrRandomPassword függvény lekéri a titkos kulcsot az Azure Key Vaultból, ha meg vannak adva a kulcstartó nevének és titkos kódjának paraméterei. Ha ezek a paraméterek nincsenek megadva, vagy egy titkos kód nem kérhető le, akkor a függvény egy véletlenszerűen generált jelszót ad vissza helyette.

Az alábbi példa a secretOrRandomPassword gyakori használati esetét mutatja be egy main.parameters.json-fájlban. A ${AZURE_KEY_VAULT_NAME} és sqlAdminPassword változók paraméterként lesznek átadva a Key Vault és a titkos kulcs neveihez. Ha az érték nem kérhető le, a rendszer ehelyett véletlenszerű jelszót hoz létre.

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

A secretOrRandomPassword kimenetét is menteni kell a Key Vaultba a Bicep használatával a későbbi futtatásokhoz. Ha ugyanazokat a titkos kulcsokat szeretné beolvasni és újrahasználni az üzembe helyezések között, megelőzheti az új értékek ismételt létrehozásakor megjelenő hibákat vagy nem szándékos viselkedéseket. Key Vault létrehozásához és a létrehozott titkos kód tárolásához használja az alábbi Bicep-kódot. A modulok teljes mintakódját az Azure Developer CLI GitHub-adattárban tekintheti meg.

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

Ez a Bicep-beállítás a következő munkafolyamatot teszi lehetővé a titkos kódok kezeléséhez:

1. Ha a megadott titkos kód létezik, a rendszer lekéri a Key Vaultból a secretOrRandomPassword függvénnyel.
2. Ha a titkos kulcs nem létezik, létrejön egy Key Vault, és a véletlenszerűen létrehozott titkos kulcs benne lesz tárolva.
3. A jövőbeli üzembe helyezések során a secretOrRandomPassword metódus lekéri a tárolt titkos kulcsot, most, hogy már létezik a Key Vaultban. A Key Vault nem lesz újra létrehozva, ha már létezik, de ugyanazt a titkos értéket a rendszer a következő futtatáskor újra tárolja.

Igen, de minden Azure-hely csak egy üzembe helyezéssel rendelkezhet. Ha már használta a kijelölt Azure-helyet, az üzembe helyezési hiba jelenik meg:

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.

A probléma megoldásához választhat egy másik Azure-helyet.

Ez az erőforrások elnevezési módszere miatt fordulhat elő.

Az Azure Dev által készített sablonjaink lehetővé teszik az erőforrás nevének konfigurálását. Ehhez hozzáadhat egy bejegyzést a main.parameters.json a infra mappában. Például:

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

Ez a bejegyzés egy "my-unique-name" nevű új erőforrást hoz létre véletlenszerű érték helyett, például "app-web-aj84u2adj" az alkalmazás következő üzembe helyezésekor. Manuálisan is eltávolíthatja a régi erőforráscsoportot az Azure Portalon, vagy futtathatja a azd down az összes korábbi üzembe helyezés eltávolításához. Az erőforrások eltávolítása után futtassa a azd provision az új névvel való újbóli létrehozásához.

Ennek a névnek globálisan egyedinek kell lennie, ellenkező esetben arm-hibaüzenet jelenik meg az erőforrás létrehozásakor azd provision során.

A parancs Bicep-sablonokat használ, amelyek a <your-project-directory-name>/infra alatt találhatók az Azure-erőforrások kiépítéséhez.

Nyissa meg a https://portal.azure.com, majd keresse meg az erőforráscsoportot, amely rg-<your-environment-name>.

Az Azure-erőforrások kiépítéséhez a <your-project-directory-name>/infraalatt található Bicep-sablonokat használjuk. Ha problémák merülnek fel, a parancssori felület kimenetében szerepel a hibaüzenet.

A https://portal.azure.com is megnyithatja, majd megkeresheti az erőforráscsoportot, amely rg-<your-environment-name>. Ha valamelyik üzembe helyezés sikertelen, a hibahivatkozást választva további információt kaphat.

Egyéb erőforrásokért lásd: Gyakori Azure-telepítési hibák elhárítása – Azure Resource Manager.

Hamarosan. Ez a funkció egy későbbi kiadásra készül.

Igen.

Az üzembe helyezés során azd először felderíti az alkalmazást alkotó összes erőforráscsoportot úgy, hogy olyan csoportokat keres, amelyek azd-env-name címkével és a környezet nevével egyező értékkel lettek megjelölve. Ezután számba adja az egyes erőforráscsoportok összes erőforrását, és olyan erőforrást keres, amely azd-service-name címkével rendelkezik, és amely megfelel a szolgáltatás nevének azure.yaml.

Bár azt javasoljuk, hogy címkéket használjon az erőforrásokon, a resourceNameazure.yaml tulajdonságával explicit erőforrásnevet is megadhat. Ebben az esetben a fenti logika nem fut.

A projekt üzembe helyezésekor dönthet úgy, hogy a parancsban megadja a szolgáltatás nevét (például azd deploy api), vagy egy olyan almappába lép, amely csak az üzembe helyezni kívánt szolgáltatást tartalmazza. Ha így tesz, az összes többi szolgáltatás - Skippedlesz felsorolva.

Ha nem szeretne kihagyni semmilyen szolgáltatást, mindenképpen futtassa a parancsot a gyökérmappából, vagy adja hozzá a --all jelzőt a parancshoz.

Igen. A növekményes üzembe helyezési módothasználjuk.

Hamarosan. Ez a funkció egy későbbi kiadásra készül.

Az Azure-szolgáltatásnevek olyan identitások, amelyek alkalmazásokkal, üzemeltetett szolgáltatásokkal és automatizált eszközökkel való használatra készültek az Azure-erőforrások eléréséhez. Ezt a hozzáférést a szolgáltatásnévhez rendelt szerepkörök korlátozzák, így szabályozhatja, hogy mely erőforrások érhetők el, és mely szinten. További információ az Azure-ból a GitHubra történő hitelesítésről: A GitHub és az Azure csatlakoztatása | Microsoft Docs.

Nem. A azd pipeline config parancs gondoskodik az Azure-szolgáltatásnév létrehozásáról és a titkos kulcsok GitHub-adattárban való tárolásához szükséges lépések elvégzéséről.

A parancs négy titkos kódot tárol a GitHubon: AZURE_CREDENTIALS, AZURE_ENV_NAME, AZURE_LOCATION és AZURE_SUBSCRIPTION_ID. Az egyes titkos kódok értékét felülbírálhatja a https://github.com/<your-github-account>/<your-repo>/secrets/actions.

Az OpenID Connecthasználatával a munkafolyamatok közvetlenül az Azure-ból cserélhetnek rövid élettartamú jogkivonatokat.

Bár az OIDC a GitHub Actions és az Azure Pipeline alapértelmezett beállítása (összevont), az Azure DevOps és a Terraform esetében nem támogatott.

• Az Azure DevOps esetében a --auth-type kifejezett meghívása federated hibát eredményez.
• Terraform esetén:
  • Ha --auth-type nincs definiálva, az visszaesik a clientcredentials, és figyelmeztetést eredményez.
  • Ha --auth-type kifejezetten federatedértékre van állítva, az hibát fog eredményezni.

Lépjen a https://github.com/<your-github-account>/<your-repo>settings/secrets/actions, majd frissítse a AZURE_CREDENTIALS az új szolgáltatásnév teljes JSON-objektumának másolásával és beillesztésével. Például:

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

A GitHub Actions fájl elérési útja <your-project-directory-name>\.github\workflows\azure-dev.yml.

Igen. Cserélje le run: azd up --no-promptrun: azd deploy --no-prompt.

Nyissa meg a https://github.com/<your-github-account>/<your-repo>/actions, majd tekintse meg a munkafolyamat-futtatás naplófájljának lépéseit.

Tárolóalkalmazások helyi létrehozásakor azd auth login kell futtatnia a tárolóban ahhoz, hogy az alkalmazás működjön a AzureDeveloperCliCredential. Másik lehetőségként úgy is konfigurálhatja az alkalmazást, hogy a AzureDeveloperCliCredentialhelyett szolgáltatásnevet használjon.