Modüllere parametre ve çıkış ekleme

  • 7 dakika

Oluşturduğunuz her modülün net bir amacı olmalıdır. Modülü sözleşmeli olarak düşünün. Bir parametre kümesini kabul eder, bir kaynak kümesi oluşturur ve üst şablona bazı çıkışlar sağlayabilir. Modülü kim kullanırsa kullansın nasıl çalıştığı konusunda endişelenmesi gerekmez, yalnızca beklediğini yapar.

Bir modülü planlarken şunları göz önünde bulundurun:

  • Modülün amacını yerine getirebilmek için bilmeniz gerekenler.
  • Modülünüzü kullanan herkesin sağlamayı bekleyeceği şeyler.
  • Modülünüzü kullanan herkesin çıkış olarak erişmesi beklenir.

Modül parametreleri

Modülünüz tarafından kabul edilen parametreleri ve her parametrenin isteğe bağlı mı yoksa gerekli mi olması gerektiğini düşünün.

Şablonlar için parametreler oluşturduğunuzda, varsayılan parametreleri ekleyebileceğiniz bir yöntemdir. Modüllerde, modülünüz kendi varsayılan parametrelerini kullanabilecek bir üst şablon tarafından kullanılacağından, varsayılan parametreleri eklemek her zaman o kadar önemli değildir. Her iki dosyada da varsayılan değerlerle benzer parametreleriniz varsa, şablonunuzun kullanıcılarının hangi varsayılan değerin uygulanacağını anlayıp tutarlılığı zorlaması zor olabilir. Üst şablonda varsayılan değeri bırakmak ve modülden kaldırmak genellikle daha iyidir.

Ayrıca, kaynaklarınız ve diğer önemli yapılandırma ayarları için SKU'ları denetleen parametreleri nasıl yönettiğinizi de düşünmelisiniz. Tek başına bicep şablonu oluşturduğunuzda, iş kurallarını şablonunuz içine eklemek yaygın bir durum olur. Örneğin: Bir üretim ortamı dağıttığımda depolama hesabı GRS katmanını kullanmalıdır. Ancak modüller bazen farklı endişeler sunar.

Yeniden kullanılabilir ve esnek olması gereken bir modül oluşturuyorsanız, her üst şablon için iş kurallarının farklı olabileceğini unutmayın; bu nedenle genel modüllere iş kuralları eklemek çok anlamlı olmayabilir. Üst şablonunuzda iş kurallarını tanımlamayı ve ardından modül yapılandırmasını parametreler aracılığıyla açıkça geçirmeyi göz önünde bulundurun.

Ancak, kendi kuruluşunuzun gereksinimlerinize uygun kaynakları dağıtmasını kolaylaştırmaya yönelik bir modül oluşturursanız, üst şablonları basitleştirmek için iş kuralları eklemek mantıklıdır.

Modülünüze hangi parametreleri eklerseniz ekleyin özniteliğini kullanarak anlamlı bir açıklama eklediğinizden @description emin olun:

@description('The name of the storage account to deploy.')
param storageAccountName string

Koşulları kullanma

Bicep gibi bir kod kullanarak altyapı dağıtmanın amaçlarından biri, yineleme çabasından kaçınmak, hatta aynı veya benzer amaçlarla birkaç şablon oluşturmaktır. Bicep'in özellikleri, çeşitli durumlarda kullanılabilen yeniden kullanılabilir modüller oluşturmak için size güçlü bir araç kutusu sağlar. İhtiyacınız olan esnekliği sağlayan yeniden kullanılabilir kod oluşturmak için modüller, ifadeler, varsayılan parametre değerleri ve koşullar gibi özellikleri birleştirebilirsiniz.

Azure Cosmos DB hesabı dağıtan bir modül oluşturduğunuzu varsayalım. Üretim ortamınıza dağıtıldığında hesabı günlüklerini Log Analytics çalışma alanına gönderecek şekilde yapılandırmanız gerekir. Log Analytics'e gönderilecek günlükleri yapılandırmak için bir tanılama Ayarlar kaynağı tanımlayacaksınız.

Kaynak tanımına bir koşul ekleyerek ve çalışma alanı kimliği parametresini varsayılan bir değer ekleyerek isteğe bağlı hale getirerek gereksiniminize ulaşabilirsiniz:

param logAnalyticsWorkspaceId string = ''

resource cosmosDBAccount 'Microsoft.DocumentDB/databaseAccounts@2022-08-15' = {
  // ...
}

resource cosmosDBAccountDiagnostics 'Microsoft.Insights/diagnosticSettings@2021-05-01-preview' =  if (logAnalyticsWorkspaceId != '') {
  scope: cosmosDBAccount
  name: 'route-logs-to-log-analytics'
  properties: {
    workspaceId: logAnalyticsWorkspaceId
    logs: [
      {
        category: 'DataPlaneRequests'
        enabled: true
      }
    ]
  }
}

Bu modülü bir Bicep şablonuna eklediğinizde, çalışma alanı kimliği ayarlayarak Azure Cosmos DB hesap günlüklerini Log Analytics'e gönderecek şekilde kolayca yapılandırabilirsiniz. Ya da dağıttığınız ortam için günlüklere ihtiyacınız yoksa parametresini atlayın. Varsayılan bir değere sahiptir. Modül, gereksinimleriniz için doğru şeyi yapmak için gereken mantığı kapsüller.

Bahşiş

Şablonunuzun her iki senaryo için de geçerli olduğunu sınamayı unutmayın; if deyimi veya falseolarak true değerlendirildiğinde.

Modül çıkışları

Modüller çıkışları tanımlayabilir. Üst şablonun kullanması gerekebilecek bilgiler için bir çıkış oluşturmak iyi bir fikirdir. Örneğin, modülünüz bir depolama hesabı tanımlıyorsa, üst şablonun erişebilmesi için depolama hesabının adı için bir çıkış oluşturmayı göz önünde bulundurun.

Uyarı

Gizli dizi değerleri için çıkışları kullanmayın. Çıkışlar dağıtım geçmişinin bir parçası olarak günlüğe kaydedilir, bu nedenle güvenli değerler için uygun değildir. Bunun yerine aşağıdaki seçeneklerden birini göz önünde bulundurabilirsiniz:

  • Kaynağın adını sağlamak için bir çıkış kullanın. Ardından üst şablon bu ada sahip bir existing kaynak oluşturabilir ve güvenli değeri dinamik olarak arayabilir.
  • Değerini bir Azure Key Vault gizli dizisine yazın. Üst şablonun gerektiğinde kasadan gizli diziyi okumasını sağlayın.

Üst şablon modül çıkışlarını değişkenlerde kullanabilir, diğer kaynak tanımlarının özelliklerini kullanabilir veya değişkenleri ve özellikleri çıkışların kendisi olarak kullanıma sunabilir. Bicep dosyalarınızın tamamında çıkışları kullanıma sunarak ve kullanarak ekibinizle paylaşılabilen ve birden çok dağıtımda yeniden kullanılabilen yeniden kullanılabilir Bicep modülleri oluşturabilirsiniz. Özniteliğini kullanarak çıkışlara anlamlı bir açıklama eklemek de iyi bir uygulamadır @description :

@description('The fully qualified Azure resource ID of the blob container within the storage account.')
output blobContainerResourceId string = storageAccount::blobService::container.id

Bahşiş

Ayrıca, Bicep şablonunuzun oluşturduğu ayarları depolamak, yönetmek ve bunlara erişmek için ayrılmış hizmetleri de kullanabilirsiniz. Key Vault, güvenli değerleri depolamak için tasarlanmıştır. Azure Uygulaması Yapılandırması, diğer (güvenli olmayan) değerleri depolamak için tasarlanmıştır.

Modülleri birbirine zincirleme

Birden çok modülü bir arada oluşturan bir üst Bicep dosyası oluşturmak yaygın bir durumdır. Örneğin, ayrılmış sanal ağlar kullanan sanal makineleri dağıtmak için yeni bir Bicep şablonu oluşturduğunuzu düşünün. Sanal ağ tanımlamak için bir modül oluşturabilirsiniz. Daha sonra sanal ağın alt ağ kaynak kimliğini bu modülden çıktı olarak alabilir ve sanal makine modülüne giriş olarak kullanabilirsiniz:

@description('Username for the virtual machine.')
param adminUsername string

@description('Password for the virtual machine.')
@minLength(12)
@secure()
param adminPassword string

module virtualNetwork 'modules/vnet.bicep' = {
  name: 'virtual-network'
}

module virtualMachine 'modules/vm.bicep' = {
  name: 'virtual-machine'
  params: {
    adminUsername: adminUsername
    adminPassword: adminPassword
    subnetResourceId: virtualNetwork.outputs.subnetResourceId
  }
}

Bu örnekte, modüller arasındaki başvuru için sembolik adlar kullanılır. Bu başvuru, Bicep'in modüller arasındaki ilişkileri otomatik olarak anlamasına yardımcı olur.

Bicep bir bağımlılık olduğunu anladığı için modülleri sırayla dağıtır:

  1. Bicep modüldeki virtualNetwork her şeyi dağıtır.
  2. Bu dağıtım başarılı olursa, Bicep çıkış değerine erişir subnetResourceId ve bunu parametre olarak modüle virtualMachine geçirir.
  3. Bicep modüldeki virtualMachine her şeyi dağıtır.

Dekont

Bir modüle bağlı olduğunuzda Bicep, modül dağıtımının tamamının tamamlanmasını bekler. Modüllerinizi planlarken bunu unutmamanız önemlidir. Dağıtımı uzun süren bir kaynağı tanımlayan bir modül oluşturursanız, bu modüle bağımlı olan diğer tüm kaynaklar modülün dağıtımının tamamının tamamlanmasını bekler.