Megosztás a következőn keresztül:


Azure fejlesztői parancssori felület eszközhasználatával és környezetével kapcsolatos gyakori kérdések

Ez a cikk a Azure fejlesztői parancssori felülettel (azd) kapcsolatos gyakori kérdésekre ad választ.

Általános kérdések

A következő szakasz az általános azd eszközkezelési és környezeti kérdésekre összpontosít.

Hogyan távolíthatom el Azure fejlesztői parancssori felületet?

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.

Mi a különbség a Azure fejlesztői parancssori felület és a Azure CLI között?

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

azd a magas szintű fejlesztői munkafolyamatra összpontosít. A Azure erőforrások kiépítése/kezelése mellett a azd segít összefűzni a felhőösszetevőket, a helyi fejlesztési konfigurációt és a folyamatautomatizálást egy teljes megoldással.

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

További információért látogasson el az Azure Developer CLI és Azure CLI összehasonlítására.

Mi az a környezet neve?

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

├── .Azure                          [This directory displays after you run `azd 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

A munkafolyamatokkal kapcsolatos további információkért lásd az azd init és azd up című témakört.

Beállíthatok egynél több környezetet?

Igen. Beállíthat különböző környezeteket (például fejlesztői, tesztelői, produkciós környezet). Az azd env használatával kezelheti ezeket a környezeteket.

Hol van tárolva a környezeti konfigurációs (.env) fájl?

Az .env fájl elérési útja <your-project-directory-name>\.azure\<your-environment-name>\.env. További információ: Környezeti változók kezelése.

Hogyan használja az .env fájlt?

A Azure fejlesztői parancssori felületen a azd parancsok a környezeti konfiguráció .env fájljában találhatóak. Az olyan parancsok, mint a azd deploy az .env fájlt is frissítik, például az adatbázis-csatolási karakterlánccal és az Azure Key Vault végponttal.

Futtattam azd up a Codespacesben. Folytathatom a munkámat helyi fejlesztési környezetben?

Igen. Helyileg folytathatja a fejlesztést.

  1. Futtassa a azd init -t <template repo> parancsot a sablonprojekt klónozásához a helyi gépen.
  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.

Hogyan hitelesíthetők a Codespace-ben, ha az eszköz bejelentkezése problémát jelez?

Ha problémákat tapasztal az eszközkód-hitelesítéssel kapcsolatban a Codespacesben (például ismétlődő 2FA-kérések vagy hibák), próbálkozzon az alábbi kerülő megoldással a VS Code Desktop használatával:

  1. Nyissa meg a Codespace-t a VS Code Desktopban az alábbi módszerek egyikével:
    • Használja a parancskatalógust (Ctrl+Shift+P Windows vagy Cmd+Shift+P macos gépen), és válassza a Kódterek: Megnyitás a VS Code Desktopban.
    • Kattintson a kódtér bal alsó sarkára a böngészőben, és válassza a Megnyitás a VS Code Desktopban lehetőséget.
  2. A VS Code Desktop terminálon futtassa az azd auth bejelentkezést , és fejezze be a böngészőalapú hitelesítést.
  3. A hitelesítést követően zárja be a VS Code Desktopot, és térjen vissza a kódtérhez a böngészőben. A hitelesítési állapotnak fenn kell maradnia.

Hogyan használja az azure.yaml fájlt?

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

Mi a függvény viselkedése secretOrRandomPassword ?

A secretOrRandomPassword függvény lekér egy titkos adatot az Azure Key Vaultból, ha a kulcstároló neve és a titkos adat paraméterek meg vannak adva. 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 kód nevének. 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 a jövőbeli futtatásokhoz Bicep használatával a Key Vaultba is menteni kell. 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. Egy 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 a Azure fejlesztői parancssori felület GitHub adattárában 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 Key Vault a secretOrRandomPassword függvény használatával.
  2. Ha a titkos kód nem létezik, létrejön egy Key Vault, és a véletlenszerűen létrehozott titkos kód benne lesz tárolva.
  3. A jövőbeli üzembe helyezések során a secretOrRandomPassword metódus lekéri a tárolt titkos adatot, most, hogy az már létezik a Key Vaultban. A Key Vault nem hozza létre újra, ha már létezik, de ugyanazt a titkos értéket a rendszer a következő futtatáskor újra tárolja.

Használhatom Azure ingyenes előfizetést?

Igen, de minden Azure helyen csak egy üzemelő példány lehet. 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 másik Azure helyet is választhat.

Az Azure App Service által üzemeltetett alkalmazásom "Megtévesztő weboldal" figyelmeztetést aktivál. Hogyan javíthatom ki?

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

A "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. A régi erőforráscsoportot manuálisan is eltávolíthatja a Azure portálon, vagy a azd down futtatásával eltávolíthatja az összes korábbi üzembe helyezést. Az erőforrások eltávolítása után futtassa a azd provision parancsot az új névvel történő ú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.

Dolgozhatok több Azure bérlővel?

Igen. Ha egy adott bérlővel szeretne hitelesíteni, használja a --tenant-id paramétert a azd auth login paranccsal.

azd auth login --tenant-id <tenant-id>

Alternatív megoldásként, ha azt szeretné, hogy azd hozzáférjen az összes bérlőjéhez, először a böngészőben kezelheti a többtényezős hitelesítés (MFA) kihívásait.

  1. Nyissa meg a Azure Portal a böngészőben.
  2. Váltson egyenként az egyes bérlőkre. Ez a művelet elindítja a szükséges MFA-kihívásokat, és frissíti a tokeneket.
  3. Futtasd azd auth login a terminálban. azd a böngésző meglévő munkamenet- és hozzáférési jogkivonatait fogja használni, amelyek mostantól érvényesek az összes meglátogatott bérlőre.

Futtathatok azd up többször is?

Igen. A növekményes üzembe helyezési módothasználjuk. További információ: azd up.

Provisioning

A következő szakasz a azd kiépítési folyamatra összpontosít.

Futtathatom a(z) azd provision többször is?

Igen. A növekményes üzembe helyezési módothasználjuk. További információ: azd provision.

Honnan tudja a azd provision parancs, hogy milyen erőforrásokat kell kiépíteni?

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

Hol találhatók a Azure kiosztott erőforrások?

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

Hogyan találhatok további információt Azure hibákról?

Bicep <your-project-directory-name>/infra alatt található sablonokat használunk Azure erőforrások kiépítéséhez. 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.

További információért lásd: Az Azure üzembe helyezés gyakori hibáinak elhárítása – Azure Resource Manager.

Van naplófájl a következőhöz azd provision?

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

Deployment

A következő szakasz az azd üzembe helyezési folyamatra összpontosít.

Lehetséges futtatni a azd deploy többször is?

Igen. További információt az azd deploy című témakörben talál.

Hogyan találja meg az azd a Azure erőforrást a kód üzembe helyezéséhez?

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, az resourceNameazure.yaml tulajdonságával explicit erőforrásnevet is megadhat. Ebben az esetben a fenti logika nem fut.

Hogyan helyezhetek üzembe bizonyos szolgáltatásokat a projektemben, miközben kihagyok másokat?

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.

Folyamatkonfiguráció

A következő szakasz a CI/CD folyamatlánc konfigurációjára összpontosít.

Mi az az Azure szolgáltatásidentitás?

Az Azure szolgáltatásfő olyan identitás, amelyet alkalmazásokkal, üzemeltetett szolgáltatásokkal és automatizált eszközökkel való együttműködésre hoztak létre, az Azure erőforrásokhoz való hozzáféréshez. 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óért az Azure és GitHub közötti hitelesítésről lásd: GitHub Azure összekapcsolása | Microsoft Docs.

Létre kell hoznom egy Azure szolgáltatási főkomponenst, mielőtt a azd pipeline config parancsot futtatom?

Nem. A azd folyamat konfigurációja parancs gondoskodik a 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.

Milyen titkokat tárolnak a GitHubban?

A parancs négy titkos kódot tárol a GitHub: 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.

Mi az OpenID Connect (OIDC), és támogatott?

A OpenID Connect használatával a munkafolyamatok közvetlenül az Azure-ból direk cserélhetik a rövid élettartamú jogkivonatokat.

Bár az OIDC az alapértelmezett támogatott megoldás a GitHub Actionnök és az Azure Pipeline esetében (ahogy federated be van állítva), nem támogatott az Azure DevOps vagy a Terraform számára.

  • A Azure DevOps esetén a --auth-typefederated kifejezett meghívása hibát eredményez.
  • Terraform esetén:
    • Ha --auth-type nincs definiálva, akkor helyettesítőként clientcredentials-t használja, és figyelmeztetés lesz az eredmény.
    • Ha --auth-type kifejezetten federatedértékre van állítva, az hibát fog eredményezni.

Hogyan állíthatom alaphelyzetbe az Azure szolgáltatás objektumot, amit a GitHub Actions-ban tároltak?

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>",
(...)
}

Hol található a GitHub Actions fájl?

A GitHub Actions fájl elérési útja <your-project-directory-name>\.github\workflows\azure-dev.yml. További információért tekintse meg Gyors kezdés: Szolgáltatásfelelős létrehozása és GitHub művelet futtatása.

A azure-dev.yml fájlban üzembe helyezhetem csak a kódot a buildelési lépésben?

Igen. Csere erre run: azd up --no-prompt : run: azd deploy --no-prompt.

Hol található a GitHub Actions feladat naplója, amelyet azd pipeline config futtatásakor aktiváltam?

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

Tárolóalkalmazás helyi létrehozása

Miért nem tudom helyileg futtatni az általam létrehozott tárolóalkalmazást?

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