Aracılığıyla paylaş

Azure Geliştirici CLI araç ve ortamları Hakkında Sıkça Sorulan Sorular (SSS)

Bu makalede, Azure Geliştirici CLI (azd) araçları, komutları ve ortamları hakkında sık sorulan soruların yanıtları sağlanır.

Genel Sorular

Aşağıdaki bölümde genel azd araçlar ve ortam sorularına odaklanmaktadır.

Azure Geliştirici CLI'sini nasıl kaldırırım?

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

Azure Geliştirici CLI'sı ile Azure CLI arasındaki fark nedir?

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

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

Azure CLI, sanal makineler, sanal ağlar ve depolama gibi Azure altyapısı 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.

Daha fazla bilgi için Azure Developer CLI vs Azure CLI adresini ziyaret edin.

Ortam adı nedir?

Azure Geliştirici CLI'sı, Azure Geliştirici CLI şablonları tarafından kullanılan AZURE_ENV_NAME ortam değişkenini ayarlamak için bir ortam adı kullanır. AZURE_ENV_NAME, Azure kaynak grubu adının ön ekini eklemek için de kullanılır. Her ortamın kendi yapılandırma kümesi olduğundan, Azure Geliştirici CLI tüm yapılandırma dosyalarını ortam dizinlerinde depolar.

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

İş akışları hakkında daha fazla bilgi için bkz. azd init ve azd up.

Birden fazla ortam ayarlayabilir miyim?

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

Ortam yapılandırması (.env) dosyası nerede depolanır?

.env dosya yolu <your-project-directory-name>\.azure\<your-environment-name>\.env. Daha fazla bilgi için bkz. Ortam değişkenlerini yönetme.

.env dosyası nasıl kullanılır?

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

Codespaces'da çalıştırdım azd up . Yerel bir geliştirme ortamında çalışmama devam edebilir miyim?

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

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

Cihaz oturum açma işleminde sorun varsa Codespaces'ta nasıl kimlik doğrulaması yapabilirim?

Codespaces'ta cihaz kodu kimlik doğrulamasıyla ilgili sorunlar yaşıyorsanız (örneğin, yinelenen 2FA istekleri veya hataları), VS Code Desktop'ı kullanarak aşağıdaki geçici çözümü deneyin:

  1. Aşağıdaki yöntemlerden birini kullanarak Codespace'inizi VS Code Desktop'ta açın:
    • Komut paletini (Windows Ctrl+Shift+P veya MacO'larda Cmd+Shift+P) kullanın ve Codespaces: OPEN in VS Code Desktop öğesini seçin.
    • Tarayıcıda Codespace'ın sol alt köşesine tıklayın ve VS Code Desktop'ta Aç'ı seçin).
  2. VS Code Masaüstü terminalinde azd auth login komutunu çalıştırın ve tarayıcı tabanlı kimlik doğrulamasını tamamlayın.
  3. Kimlik doğrulaması yaptıktan sonra VS Code Desktop'ı kapatın ve tarayıcıda Codespace'inize dönün. Kimlik doğrulama durumu kalıcı olmalıdır.

azure.yaml dosyası nasıl kullanılır?

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

İşlev secretOrRandomPassword'ün davranışı nedir?

secretOrRandomPassword işlevi, anahtar kasasının adı ve sır için parametreler sağlanıyorsa Azure Key Vault'tan bir sır 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 secretOrRandomPassword dosyasındaki main.parameters.json yaygın kullanım örneğini gösterir. ${AZURE_KEY_VAULT_NAME} ve sqlAdminPassword değişkenleri, Key Vault ve gizli 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)"
}

secretOrRandomPassword çıkışı, gelecekteki çalıştırmalar için Bicep kullanılarak Key Vault'a kaydedilmelidir. Dağıtımlar arasında aynı gizli anahtarlara erişilmesi ve yeniden kullanılması, sürekli olarak yeni değerler üretilmesi durumunda ortaya çıkabilecek hataları veya istenmeyen davranışları önleyebilir. Bir Key Vault oluşturmak ve oluşturulan gizli bilgiyi içinde 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, sırlarınızı yönetmek için aşağıdaki iş akışını etkinleştirir.

  1. Belirtilen gizli anahtar varsa, secretOrRandomPassword işlevi kullanılarak Key Vault'tan alınır.
  2. Gizli anahtar yoksa, bir Key Vault oluşturulur ve rastgele oluşturulan gizli anahtar içine depolanır.
  3. Gelecekteki dağıtımlarda, secretOrRandomPassword yöntemi, Key Vault'da artık mevcut olan depolanmış gizli bilgiyi alır. Key Vault zaten mevcutsa yeniden oluşturulmayacak, ancak aynı gizli değer bir sonraki çalıştırma için yeniden depolanacaktır.

Azure Ücretsiz Aboneliği kullanabilir miyim?

Evet, ancak her Azure konumu yalnızca bir dağıtıma sahip 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.

Azure App Service ile barındırılan uygulamam "Bu site güvenli değil" uyarısı veriyor. Nasıl düzeltebilirim?

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, main.parameters.json klasöründeki infra bir girdi ekleyebilirsiniz. Örneğin:

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

Uygulamanızı bir sonraki sağlama işleminizde "app-web-aj84u2adj" gibi rastgele bir değer yerine "my-unique-name" adında yeni bir kaynak oluşturacak şekilde bu girdiyi yapın. Azure portalını kullanarak eski kaynak grubunu el ile kaldırabilir veya önceki tüm dağıtımları kaldırmak için azd down çalıştırabilirsiniz. Kaynakları kaldırdıktan sonra, yeni adla yeniden oluşturmak için azd provision çalıştırın.

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

Birden çok Azure kiracısıyla çalışabilir miyim?

Evet. Belirli bir kiracıyla kimlik doğrulaması yapmak için --tenant-id komutunu kullanarak azd auth login parametresini kullanın.

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

Alternatif olarak, tüm kiracılarınıza erişmek istiyorsanız azd , önce tarayıcıda Multi-Factor Authentication (MFA) sınamalarını işleyebilirsiniz:

  1. tarayıcınızda Azure Portal açın.
  2. Kiracılarınızın her birine birer birer geçiş yapın. Bu eylem gerekli Çok Faktörlü Kimlik Doğrulama sınamalarını tetikler ve belirteçlerinizi yeniler.
  3. Terminalinizde çalıştırın azd auth login . azd artık ziyaret ettiğiniz tüm kiracılar için geçerli olan tarayıcının mevcut oturumunu ve erişim belirteçlerini kullanır.

Birden çok kez azd up çalıştırabilir miyim?

Evet. Artımlı dağıtım modunu kullanırız. Daha fazla bilgi için bkz. azd up.

Provisioning

Aşağıdaki bölümde azd tedarik etme süreci üzerinde durulmaktadır.

azd provision'yi birden çok kez çalıştırabilir miyim?

Evet. Biz artımlı dağıtım modunu kullanırız. Daha fazla bilgi için bkz. azd provision.

azd provision komutu, hangi kaynakların sağlanacağını nasıl biliyor?

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

Azure hangi kaynakların sağlandığına nereden erişebilirim?

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

Azure hataları hakkında nasıl daha fazla bilgi bulabilirim?

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

Ayrıca https://portal.azure.com öğesine gidip, rg-<your-environment-name> olarak adlandırılan kaynak grubunuzu 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.

azd provision için bir günlük dosyası var mı?

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

Dağıtım

Aşağıdaki bölümde dağıtım işlemine odaklanılır azd .

azd deploy birden çok kez çalıştırabilir miyim?

Evet. Daha fazla bilgi için bkz. azd deploy .

azd, kodumun dağıtılacağı Azure kaynağını nasıl bulur?

Dağıtım sırasında azd önce azd-env-name ile etiketlenmiş ve ortamınızın adıyla eşleşen bir değere 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 azd-service-namehizmetinizin adıyla eşleşen bir değerle azure.yaml etiketli bir kaynak arar.

Kaynaklarda etiketlerin kullanılmasını önersek de resourceName özelliğini kullanarak açık bir kaynak adı da sağlayabilirsiniz. Bu durumda yukarıdaki mantık çalıştırılamaz.

Diğer hizmetleri atlarken projeme belirli hizmetleri nasıl dağıtacağım?

Projenizi dağıtırken, komutta hizmet adını belirterek (azd deploy api) veya yalnızca dağıtmak istediğiniz hizmetleri içeren bir alt klasöre giderek belirli hizmetleri dağıtmayı seçebilirsiniz. Bunu yaparken, diğer tüm hizmetler - Skippedolarak listelenir.

Hiçbir hizmeti atlamak istemiyorsanız, komutunu kök klasörden çalıştırdığınızdan veya --all bayrağını komutunuza eklediğinizden emin olun.

İşlem hattı yapılandırması

Aşağıdaki bölümde CI/CD işlem hattı yapılandırmasına odaklanmaktadır.

Azure hizmet sorumlusu nedir?

Azure hizmet sorumlusu, uygulamalar, barındırılan hizmetler ve Azure kaynaklara erişmek için 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 GitHub kimlik doğrulaması hakkında daha fazla bilgi için bkz. Connect GitHub ve Azure | Microsoft Docs.

azd pipeline config çalıştırmadan önce bir Azure hizmet sorumlusu oluşturmam gerekiyor mu?

Hayır. azd pipeline config komutu, Azure hizmet sorumlusunu oluşturur ve gizli dizileri GitHub deponuzda depolamak için gerekli adımları gerçekleştirir.

GitHub'da depolanan tüm gizlilikler nelerdir?

Komut, GitHub'da dört gizli anahtarı saklar: AZURE_CREDENTIALS, AZURE_ENV_NAME, AZURE_LOCATION ve AZURE_SUBSCRIPTION_ID. https://github.com/<your-github-account>/<your-repo>/secrets/actions gidip her bir gizlinin değerini geçersiz kılabilirsiniz.

OpenID Connect (OIDC) nedir ve destekleniyor mu?

OpenID Connect ile iş akışlarınız Azure'dan doğrudan kısa süreli belirteçler alabilir.

OIDC, GitHub Actions ve Azure İşlem Hattı için varsayılan olarak destekleniyor olsa da (federated olarak ayarlanır), Azure DevOps veya Terraform için desteklenmez.

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

GitHub Actions depolanan Azure hizmet sorumlusunu nasıl sıfırlayabilirim?

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

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

GitHub Actions dosyası nerede depolanır?

GitHub Actions dosya yolu <your-project-directory-name>\.github\workflows\azure-dev.yml. Daha fazla bilgi için bkz. Quickstart: Hizmet sorumlusu oluşturma ve GitHub Eylemi çalıştırma.

azure-dev.yml dosyasında yalnızca derleme adımındaki kodu dağıtabilir miyim?

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

azd pipeline config çalıştırdığımda tetiklemiş olduğum GitHub Actions işinin günlüğünü nerede bulabilirim?

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

Yerel olarak kapsayıcı uygulaması oluşturma

Neden oluşturmakta olduğum kapsayıcı uygulamasını yerel olarak çalıştıramıyorum?

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

  • Last updated on