Azure Developer CLI hakkında SSS

İlk yükleme şeklinize bağlı olarak kaldırma azd için farklı seçenekler vardır. Ayrıntılar için yükleme sayfasını ziyaret edin.

Azure Geliştirici CLI'sı (azd) ve Azure CLI (az), komut satırı araçlarıdır ancak farklı görevler gerçekleştirmenize yardımcı olur.

azd üst düzey geliştirici iş akışına odaklanır. Azure kaynaklarını sağlamanın/yönetmenin dışında bulut bileşenlerini, azd yerel geliştirme yapılandırmasını ve işlem hattı otomasyonlarını eksiksiz bir çözüm olarak birleştirmeye yardımcı olur.

Azure CLI, sanal makineler, sanal ağlar ve depolama gibi Azure altyapısını oluşturmaya ve yönetmeye yönelik bir denetim düzlemi aracıdır. Azure CLI, belirli yönetim görevleri için ayrıntılı komutlar etrafında tasarlanmıştır.

Azure Developer CLI, Azure Developer CLI şablonları tarafından kullanılan AZURE_ENV_NAME ortam değişkenini ayarlamak için bir ortam adı kullanır. Azure kaynak grubu adına ön ek olarak AZURE_ENV_NAME de kullanılır. Her ortamın kendi yapılandırmaları olduğundan Azure Developer CLI tüm yapılandırma dosyalarını ortam dizinlerinde depolar.

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

Evet. Çeşitli ortamlar (geliştirme, test, üretim gibi) ayarlayabilirsiniz. Bu ortamları yönetmek için azd env kullanabilirsiniz.

.env dosya yolu <your-project-directory-name>\.azure\<your-environment-name>\.env şeklindedir.

Azure Geliştirici CLI'sinde komutlar azd , ortam yapılandırması için .env dosyasına başvurur. azd deploy.env dosyasını veritabanı bağlantı dizesi ve Azure Key Vault uç noktası gibi komutlarla da güncelleştirebilirsiniz.

Evet. Geliştirme çalışmalarına yerel olarak devam edebilirsiniz.

1. Şablon projesini yerel makinenize kopyalamak için komutunu çalıştırın azd init -t <template repo> .
2. Codespaces kullanılarak oluşturulan mevcut env dosyasını aşağı çekmek için komutunu çalıştırın azd env refresh. Öncekiyle aynı ortam adını, aboneliği ve konumu sağladığından emin olun.

azure.yaml dosyası, şablona dahil edilen Azure kaynaklarının uygulamalarını ve türlerini açıklar.

Anahtar secretOrRandomPassword kasası adı ve gizli dizisi için parametreler sağlanmışsa işlev Azure Key Vault'tan bir gizli dizi alır. Bu parametreler sağlanmamışsa veya gizli dizi alınamıyorsa, işlev bunun yerine kullanmak üzere rastgele oluşturulmuş bir parola döndürür.

Aşağıdaki örnek, bir dosyadaki öğesinin yaygın kullanım örneğini secretOrRandomPassword main.parameters.json gösterir. ${AZURE_KEY_VAULT_NAME} ve sqlAdminPassword değişkenleri, Key Vault ve gizli dizi adları için parametre olarak geçirilir. Değer alınamıyorsa, bunun yerine rastgele bir parola oluşturulur.

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

çıktısı secretOrRandomPassword , gelecekteki çalıştırmalar için Bicep kullanılarak Key Vault'a da kaydedilmelidir. Dağıtımlar arasında aynı gizli dizilerin alınması ve yeniden kullanılmasının, sürekli olarak yeni değerler oluşturulurken ortaya çıkarabilecek hataları veya istenmeyen davranışları önleyebileceği. Key Vault oluşturmak ve oluşturulan gizli diziyi bu kasada depolamak için aşağıdaki Bicep kodunu kullanın. Bu modüllerin tam örnek kodunu Azure Developer CLI GitHub deposunda görüntüleyebilirsiniz.

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

Bu Bicep kurulumu, gizli dizilerinizi yönetmek için aşağıdaki iş akışını etkinleştirir:

1. Belirtilen gizli dizi varsa, işlevi kullanılarak secretOrRandomPassword Key Vault'tan alınır.
2. Gizli dizi yoksa bir Key Vault oluşturulur ve rastgele oluşturulan gizli dizi içinde depolanır.
3. Gelecekteki dağıtımlarda yöntemi, secretOrRandomPassword Key Vault'ta mevcut olduğu için depolanan gizli diziyi alır. Key Vault zaten varsa yeniden oluşturulmayacak, ancak aynı gizli dizi değeri bir sonraki çalıştırma için yeniden depolanacaktır.

Evet, ancak her Azure konumunun yalnızca bir dağıtımı olabilir. Seçili Azure konumunu zaten kullandıysanız dağıtım hatasını görürsünüz:

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.

Sorunu çözmek için farklı bir Azure konumu seçebilirsiniz.

Bunun nedeni kaynakları adlandırma yöntemimiz olabilir.

'Azure Dev' tarafından yazılan şablonlarımız kaynağın adını yapılandırmaya olanak sağlar. Bunu yapmak için klasörüne main.parameters.json infra bir girdi ekleyebilirsiniz. Örneğin:

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

Bu giriş, uygulamanızı bir sonraki sağlamanızda "app-web-aj84u2adj" gibi rastgele bir değer yerine "my-unique-name" adlı yeni bir kaynak oluşturur. Azure Portal'ı kullanarak eski kaynak grubunu el ile kaldırabilir veya önceki tüm dağıtımları kaldırmak için komutunu çalıştırabilirsiniz azd down . Kaynakları kaldırdıktan sonra komutunu çalıştırarak azd provision yeni adla yeniden oluşturun.

Bu adın genel olarak benzersiz olması gerekir, aksi takdirde kaynağı oluşturmaya çalışırken arm hatası azd provision alırsınız.

Komutu, Azure kaynaklarını sağlamak için altında <your-project-directory-name>/infra bulunan Bicep şablonlarını kullanır.

adresine https://portal.azure.com gidin ve kaynak grubunuzu (olan) rg-<your-environment-name>arayın.

Azure kaynaklarını sağlamak için altında <your-project-directory-name>/infrabulunan Bicep şablonlarını kullanırız. Sorun varsa, CLI çıkışına hata iletisini ekleriz.

Ayrıca adresine https://portal.azure.com gidip kaynak grubunuzu (olan) rg-<your-environment-name>arayabilirsiniz. Dağıtımlardan herhangi biri başarısız olursa daha fazla bilgi edinmek için hata bağlantısını seçin.

Diğer kaynaklar için bkz . Yaygın Azure dağıtım hatalarını giderme - Azure Resource Manager.

Çok yakında sunulacak. Bu özellik gelecekteki bir sürüm için planlanıyor.

Evet.

Dağıtım sırasında, azd önce ile etiketlenmiş ve ortamınızın adıyla eşleşen bir değere azd-env-name sahip grupları arayarak uygulamanızı oluşturan tüm kaynak gruplarını bulur. Ardından, bu kaynak gruplarının her birindeki tüm kaynakları numaralandırır ve hizmetinizin azure.yamladıyla eşleşen bir değerle azd-service-name etiketlenmiş bir kaynak arar.

Kaynaklarda etiketlerin kullanılmasını önersek de, açık bir kaynak adı sağlamak için içindeki azure.yaml özelliğini de kullanabilirsinizresourceName. Bu durumda yukarıdaki mantık çalıştırılamaz.

Evet. Artımlı dağıtım modunu kullanırız.

Çok yakında sunulacak. Bu özellik gelecekteki bir sürüm için planlanıyor.

Azure hizmet sorumlusu, Azure kaynaklarına erişmek için uygulamalar, barındırılan hizmetler ve otomatik araçlarla kullanılmak üzere oluşturulmuş bir kimliktir. Bu erişim, hangi kaynaklara ve hangi düzeyde erişilebileceğini denetlemenizi sağlayan hizmet sorumlusuna atanan rollerle kısıtlanır. Azure'dan GitHub'a kimlik doğrulaması hakkında daha fazla bilgi için bkz . GitHub ve Azure'ı bağlama | Microsoft Docs.

Hayır Komutu, azd pipeline config Azure hizmet sorumlusu oluşturma ve gitHub deponuzda gizli dizileri depolamak için gerekli adımları gerçekleştirme işlemlerini gerçekleştirir.

Komut GitHub'da dört gizli dizi depolar: AZURE_CREDENTIALS, AZURE_ENV_NAME, AZURE_LOCATION ve AZURE_SUBSCRIPTION_ID. adresine giderek https://github.com/<your-GH-account>/<your-repo>/secrets/actionsher gizli anahtarın değerini geçersiz kılabilirsiniz.

OpenID Connect ile, iş yükleriniz kısa ömürlü belirteçleri doğrudan Azure'dan değiştirebilir.

GitHub Actions ve Azure Pipeline için varsayılan olarak OIDC destekleniyor olsa da (federasyon olarak ayarlanır), Azure DevOps veya Terraform için desteklenmez.

• Azure DevOps için açıkça çağrılması --auth-type federated hataya neden olur.
• Terraform için:
  • Tanımlanmamışsa --auth-type , öğesine geri clientcredentials döner ve bir uyarıyla sonuçlanır.
  • açıkça olarak federatedolarak ayarlanırsa --auth-type hataya neden olur.

adresine https://github.com/<your-GH-account>/<your-repo>settings/secrets/actionsgidin ve yeni hizmet sorumlusu için JSON nesnesinin tamamını kopyalayıp yapıştırarak güncelleştirin AZURE_CREDENTIALS . Örneğin:

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

GitHub Actions dosya yolu şeklindedir <your-project-directory-name>\.github\workflows\azure-dev.yml.

Evet. run: azd up --no-prompt öğesini run: azd deploy --no-prompt ile değiştirin.

adresine https://github.com/<your-GH-account>/<your-repo>/actionsgidin ve iş akışı çalıştırmasında günlük dosyasına bakın.

Kapsayıcı uygulamalarını yerel olarak oluştururken, uygulamanın ile AzureDeveloperCliCredentialçalışması için kapsayıcıda çalıştırmanız azd auth login gerekir. Alternatif olarak, uygulamanızı yerine bir hizmet sorumlusu AzureDeveloperCliCredentialkullanacak şekilde yapılandırabilirsiniz.