FAQ Azure Developer CLI

Ada berbagai opsi untuk menghapus instalan azd tergantung pada bagaimana Anda awalnya menginstalnya. Kunjungi halaman penginstalan untuk detailnya.

Azure Developer CLI (azd) dan Azure CLI (az) keduanya adalah alat baris perintah, tetapi membantu Anda melakukan tugas yang berbeda.

azd berfokus pada alur kerja pengembang tingkat tinggi. Selain menyediakan/mengelola sumber daya Azure, azd membantu menjahit komponen cloud, konfigurasi pengembangan lokal, dan otomatisasi alur bersama-sama menjadi solusi lengkap.

Azure CLI adalah alat sarana kontrol untuk membuat dan mengelola infrastruktur Azure seperti komputer virtual, jaringan virtual, dan penyimpanan. Azure CLI dirancang di sekitar perintah terperinci untuk tugas administratif tertentu.

Azure Developer CLI menggunakan nama lingkungan untuk mengatur AZURE_ENV_NAME variabel lingkungan yang digunakan oleh templat Azure Developer CLI. AZURE_ENV_NAME juga digunakan sebagai awalan nama grup sumber daya Azure. Karena setiap lingkungan memiliki set konfigurasinya sendiri, Azure Developer CLI menyimpan semua file konfigurasi di direktori lingkungan.

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

Ya. Anda dapat menyiapkan berbagai lingkungan (misalnya, dev, test, production). Anda dapat menggunakan azd env untuk mengelola lingkungan ini.

Jalur file .env adalah <your-project-directory-name>\.azure\<your-environment-name>\.env.

Di Azure Developer CLI, azd perintah merujuk ke file .env untuk konfigurasi lingkungan. Perintah seperti azd deploy juga memperbarui file .env dengan, misalnya, string koneksi db dan titik akhir Azure Key Vault.

Ya. Anda dapat melanjutkan pekerjaan pengembangan secara lokal.

1. Jalankan azd init -t <template repo> untuk mengkloning proyek templat ke komputer lokal Anda.
2. Untuk menarik env yang ada yang dibuat menggunakan Codespaces, jalankan azd env refresh. Pastikan Anda memberikan nama lingkungan, langganan, dan lokasi yang sama seperti sebelumnya.

File azure.yaml menjelaskan aplikasi dan jenis sumber daya Azure yang disertakan dalam templat.

Fungsi ini secretOrRandomPassword mengambil rahasia dari Azure Key Vault jika parameter untuk nama dan rahasia brankas kunci disediakan. Jika parameter ini tidak disediakan atau rahasia tidak dapat diambil, fungsi akan mengembalikan kata sandi yang dihasilkan secara acak untuk digunakan sebagai gantinya.

Contoh berikut menunjukkan kasus secretOrRandomPassword penggunaan umum dalam main.parameters.json file. Variabel ${AZURE_KEY_VAULT_NAME} dan sqlAdminPassword diteruskan sebagai parameter untuk nama Key Vault dan rahasia. Jika nilai tidak dapat diambil, kata sandi acak dihasilkan sebagai gantinya.

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

Output secretOrRandomPassword juga harus disimpan ke Key Vault menggunakan Bicep untuk eksekusi di masa mendatang. Mengambil dan menggunakan kembali rahasia yang sama di seluruh penyebaran dapat mencegah kesalahan atau perilaku yang tidak diinginkan yang dapat muncul ketika berulang kali menghasilkan nilai baru. Untuk membuat Key Vault dan menyimpan rahasia yang dihasilkan di dalamnya, gunakan kode Bicep di bawah ini. Anda dapat melihat kode sampel lengkap untuk modul ini di repositori GitHub 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
  }
}]

Penyiapan Bicep ini memungkinkan alur kerja berikut untuk mengelola rahasia Anda:

1. Jika rahasia yang ditentukan ada, rahasia diambil dari Key Vault menggunakan fungsi .secretOrRandomPassword
2. Jika rahasia tidak ada, Key Vault dibuat, dan rahasia yang dihasilkan secara acak disimpan di dalamnya.
3. Pada penyebaran di secretOrRandomPassword masa mendatang, metode mengambil rahasia tersimpan sekarang setelah ada di Key Vault. Key Vault tidak akan dibuat ulang jika sudah ada, tetapi nilai rahasia yang sama akan disimpan lagi untuk eksekusi berikutnya.

Ya, tetapi setiap lokasi Azure hanya dapat memiliki satu penyebaran. Jika Anda telah menggunakan lokasi Azure yang dipilih, Anda akan melihat kesalahan penyebaran:

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.

Anda dapat memilih lokasi Azure yang berbeda untuk memperbaiki masalah tersebut.

Ini mungkin terjadi karena metode kami untuk penamaan sumber daya.

Templat 'Azure Dev' kami yang ditulis memungkinkan untuk mengonfigurasi nama sumber daya. Untuk melakukannya, Anda dapat menambahkan entri ke main.parameters.json dalam infra folder. Misalnya:

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

Entri ini membuat sumber daya baru bernama "my-unique-name" alih-alih nilai acak seperti "app-web-aj84u2adj" saat Berikutnya Anda memprovisikan aplikasi Anda. Anda dapat menghapus grup sumber daya lama secara manual menggunakan Portal Microsoft Azure atau menjalankan azd down untuk menghapus semua penyebaran sebelumnya. Setelah menghapus sumber daya, jalankan azd provision untuk membuatnya lagi dengan nama baru.

Nama ini harus unik secara global, jika tidak, Anda akan menerima kesalahan ARM selama azd provision mencoba membuat sumber daya.

Perintah ini menggunakan templat Bicep, yang ditemukan di bawah <your-project-directory-name>/infra untuk memprovisikan sumber daya Azure.

https://portal.azure.com Buka lalu cari grup sumber daya Anda, yaitu rg-<your-environment-name>.

Kami menggunakan templat Bicep, yang ditemukan di bawah <your-project-directory-name>/infra, untuk memprovisikan sumber daya Azure. Jika ada masalah, kami menyertakan pesan kesalahan dalam output CLI.

Anda juga dapat membuka https://portal.azure.com dan kemudian mencari grup sumber daya Anda, yaitu rg-<your-environment-name>. Jika salah satu penyebaran gagal, pilih tautan kesalahan untuk mendapatkan informasi selengkapnya.

Untuk sumber daya lain, lihat Memecahkan masalah kesalahan umum penyebaran Azure - Azure Resource Manager.

Segera hadir. Fitur ini direncanakan untuk rilis mendatang.

Ya.

Selama penyebaran, azd pertama-tama temukan semua grup sumber daya yang membentuk aplikasi Anda dengan mencari grup yang ditandai dengan dan dengan nilai yang cocok dengan azd-env-name nama lingkungan Anda. Kemudian, ini menghitung semua sumber daya di setiap grup sumber daya ini, mencari sumber daya yang ditandai dengan nilai yang cocok dengan azd-service-name nama layanan Anda dari azure.yaml.

Meskipun sebaiknya gunakan tag pada sumber daya, Anda juga dapat menggunakan resourceName properti untuk azure.yaml memberikan nama sumber daya eksplisit. Dalam hal ini, logika di atas tidak dijalankan.

Ya. Kami menggunakan mode penyebaran bertahap.

Segera hadir. Fitur ini direncanakan untuk rilis mendatang.

Perwakilan layanan Azure adalah identitas yang dibuat untuk digunakan dengan aplikasi, layanan yang dihosting, dan alat otomatis untuk mengakses sumber daya Azure. Akses ini dibatasi oleh peran yang ditetapkan ke perwakilan layanan, yang memberi Anda kontrol atas sumber daya mana yang dapat diakses dan pada tingkat mana. Untuk informasi selengkapnya tentang mengautentikasi dari Azure ke GitHub, lihat Koneksi GitHub dan Azure | Microsoft Docs.

Tidak. Perintah azd pipeline config ini mengurus pembuatan perwakilan layanan Azure dan melakukan langkah-langkah yang diperlukan untuk menyimpan rahasia di repositori GitHub Anda.

Perintah menyimpan empat rahasia di GitHub: AZURE_CREDENTIALS, AZURE_ENV_NAME, AZURE_LOCATION, dan AZURE_SUBSCRIPTION_ID. Anda dapat mengambil alih nilai setiap rahasia dengan masuk ke https://github.com/<your-GH-account>/<your-repo>/secrets/actions.

Dengan OpenID Connect, alur kerja Anda dapat bertukar token berumur pendek langsung dari Azure.

Meskipun OIDC didukung sebagai default untuk GitHub Actions dan Azure Pipeline (diatur sebagai federasi), OIDC tidak didukung untuk Azure DevOps atau Terraform.

• Untuk Azure DevOps, secara eksplisit memanggil --auth-type sebagai federated akan mengakibatkan kesalahan.
• Untuk Terraform:
  • Jika --auth-type tidak didefinisikan, itu akan kembali ke clientcredentials dan akan menghasilkan peringatan.
  • Jika --auth-type secara eksplisit diatur ke federated, itu akan mengakibatkan kesalahan.

https://github.com/<your-GH-account>/<your-repo>settings/secrets/actionsBuka , lalu perbarui AZURE_CREDENTIALS dengan menyalin dan menempelkan seluruh objek JSON untuk perwakilan layanan baru. Misalnya:

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

Jalur file GitHub Actions adalah <your-project-directory-name>\.github\workflows\azure-dev.yml.

Ya. Ganti run: azd up --no-prompt dengan run: azd deploy --no-prompt.

https://github.com/<your-GH-account>/<your-repo>/actionsBuka , lalu lihat file log dalam alur kerja yang dijalankan.

Saat membangun aplikasi kontainer secara lokal, Anda perlu menjalankan azd auth login dalam kontainer agar aplikasi berfungsi dengan AzureDeveloperCliCredential. Atau, Anda dapat mengonfigurasi aplikasi Anda untuk menggunakan perwakilan layanan alih-alih AzureDeveloperCliCredential.