Azure Developer CLI – GYIK

Az eltávolításnak azd 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 oldalra .

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

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

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évvel állítja be az Azure Developer CLI-sablonok által használt AZURE_ENV_NAME környezeti változót. Az AZURE_ENV_NAME az Azure-erőforráscsoport nevének előtagjaként is használatos. Mivel minden környezet saját konfigurációkészlettel rendelkezik, az Azure Developer CLI minden konfigurációs fájlt környezeti mappákban tárol.

├── .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 az azd env paranccsal kezelheti.

A .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. Olyan parancsok, mint azd deploy például az .env fájl frissítése a db kapcsolati sztring és az Azure Key Vault-végponttal.

Igen. Helyileg folytathatja a fejlesztést.

1. Futtassa azd init -t <template repo> a sablonprojekt klónozását a helyi gépre.
2. A Codespaces használatával létrehozott meglévő env lekéréséhez futtassa a következőt 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 a kulcstartó nevének és titkos kódjának paraméterei meg vannak adva. Ha ezek a paraméterek nincsenek megadva, vagy egy titkos kód nem kérhető le, a függvény ehelyett egy véletlenszerűen generált jelszót ad vissza a használathoz.

Az alábbi példa egy fájl gyakori használati esetét secretOrRandomPassword mutatja be main.parameters.json . A ${AZURE_KEY_VAULT_NAME} rendszer paraméterként adja át a kulcstartó és sqlAdminPassword a titkos kulcs nevét és a változókat. 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 kimenetet secretOrRandomPassword a Key Vaultba is menteni kell 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ény használatával.
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 kódot, 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 felvehet egy bejegyzést a main.parameters.jsoninfra mappába. 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 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 azd provision újra azokat az új névvel.

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

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

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

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

Megkeresheti az erőforráscsoportot is https://portal.azure.com , amely az 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ásokat az Azure gyakori üzembehelyezési hibáinak elhárítása – Azure Resource Manager című témakörben talál.

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

Igen.

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

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

Igen. Növekményes üzembe helyezési módot használunk.

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: Csatlakozás GitHub és Azure | 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 következő lépéssel https://github.com/<your-GH-account>/<your-repo>/secrets/actions: .

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

Bár az OIDC a GitHub Actions és az Azure Pipeline alapértelmezett értéke (összevontként van beállítva), az Azure DevOps és a Terraform esetében nem támogatott.

• Az Azure DevOps esetében a explicit meghívás --auth-typefederated hibát eredményez.
• Terraform esetén:
  • Ha --auth-type nincs definiálva, az visszaesik clientcredentials , és figyelmeztetést eredményez.
  • Ha --auth-type explicit módon van beállítva federated, az hibát fog eredményezni.

Nyissa meg https://github.com/<your-GH-account>/<your-repo>settings/secrets/actionsa elemet, majd frissítsen 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 a run: azd up --no-prompt elemet a run: azd deploy --no-prompt kérdésre.

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

Tárolóalkalmazások helyi létrehozásakor a tárolóban kell futnia azd auth login 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 szolgáltatásnév helyett egy egyszerű szolgáltatást használjon AzureDeveloperCliCredential.