Bulut tutarlılığı için ARM şablonları geliştirme

Makale
03/20/2024

Önemli

PowerShell'in bu Azure özelliğini kullanmak için modülün AzureRM yüklü olması gerekir. Bu, yalnızca Windows PowerShell 5.1'de artık yeni özellikler almayan eski bir modüldür. Ve modülleri, PowerShell'in Az aynı sürümleri için yüklendiğinde uyumlu değildir.AzureRM Her iki sürüme de ihtiyacınız varsa:

PowerShell 5.1 oturumundan Az modülünü kaldırın.
PowerShell 5.1 oturumundan AzureRM modülünü yükleyin.
PowerShell Core 6.x veya üzerini indirip yükleyin.
Az modülünü bir PowerShell Core oturumuna yükleyin.

Azure'ın temel avantajlarından biri tutarlılıktır. Bir konum için geliştirme yatırımları başka bir konumda yeniden kullanılabilir. Azure Resource Manager şablonu (ARM şablonu), dağıtımlarınızı genel Azure, Azure bağımsız bulutları ve Azure Stack gibi ortamlarda tutarlı ve yinelenebilir hale getirir. Öte yandan şablonları bulutlar arasında yeniden kullanmak için, bu kılavuzda açıklandığı gibi buluta özgü bağımlılıkları göz önünde bulundurmanız gerekir.

Microsoft, aşağıdakiler dahil olmak üzere birçok konumda akıllı, kurumsal kullanıma hazır bulut hizmetleri sunar:

Dünyanın dört bir yanındaki bölgelerde microsoft tarafından yönetilen veri merkezlerinden oluşan büyüyen bir ağ tarafından desteklenen küresel Azure platformu.
Azure Almanya, Azure Kamu ve 21Vianet tarafından işletilen Microsoft Azure gibi yalıtılmış bağımsız bulutlar. Bağımsız bulutlar, genel Azure müşterilerinin eriştikleri harika özelliklerin çoğuna sahip tutarlı bir platform sağlar.
Azure Stack, kuruluşunuzun veri merkezinden Azure hizmetleri sunmanızı sağlayan hibrit bir bulut platformudur. Kuruluşlar Azure Stack'i kendi veri merkezlerinde ayarlayabilir veya hizmet sağlayıcılarından Azure Hizmetlerini kullanabilir ve Azure Stack'i tesislerinde çalıştırabilir (bazen barındırılan bölgeler olarak da bilinir).

Tüm bu bulutların temelinde, Azure Resource Manager çok çeşitli kullanıcı arabirimlerinin Azure platformuyla iletişim kurmasına olanak tanıyan bir API sağlar. Bu API size güçlü kod olarak altyapı özellikleri sağlar. Azure bulut platformunda kullanılabilen her tür kaynak, Azure Resource Manager ile dağıtılabilir ve yapılandırılabilir. Tek bir şablonla, uygulamanızın tamamını işletimsel son durumuna dağıtabilir ve yapılandırabilirsiniz.

Genel Azure, bağımsız bulutlar ve Azure Stack gibi çeşitli Azure ortamlarının diyagramı.

Küresel Azure'ın, bağımsız bulutların, barındırılan bulutların ve veri merkezinizdeki bir bulutun tutarlılığı, Azure Resource Manager'dan yararlanmanıza yardımcı olur. Şablon tabanlı kaynak dağıtımı ve yapılandırması ayarlarken geliştirme yatırımlarınızı bu bulutlarda yeniden kullanabilirsiniz.

Ancak küresel, bağımsız, barındırılan ve hibrit bulutlar tutarlı hizmetler sağlasa da tüm bulutlar aynı değildir. Sonuç olarak, yalnızca belirli bir bulutta kullanılabilen özelliklere bağımlılıkları olan bir şablon oluşturabilirsiniz.

Bu kılavuzun geri kalanında, Azure Stack için yeni ARM şablonları geliştirmeyi veya mevcut ARM şablonlarını güncelleştirmeyi planlarken dikkate alınacak alanlar açıklanmaktadır. Genel olarak, denetim listenize aşağıdaki öğeler eklenmelidir:

Şablonunuzdaki işlevlerin, uç noktaların, hizmetlerin ve diğer kaynakların hedef dağıtım konumlarında kullanılabilir olduğunu doğrulayın.
İç içe yerleştirilmiş şablonları ve yapılandırma yapıtlarını erişilebilir konumlarda depolayarak bulutlar arasında erişim sağlayın.
Bağlantıları ve öğeleri sabit kodlamak yerine dinamik başvurular kullanın.
Kullandığınız şablon parametrelerinin hedef bulutlarda çalıştığından emin olun.
Kaynağa özgü özelliklerin hedef bulutlarda kullanılabilir olduğunu doğrulayın.

ARM şablonlarına giriş için bkz. Şablon dağıtımı.

Şablon işlevlerinin çalıştığından emin olun

ARM şablonunun temel söz dizimi JSON'dır. Şablonlar JSON'un üst kümesini kullanır ve söz dizimini ifadeler ve işlevlerle genişletir. Şablon dili işlemcisi sık sık ek şablon işlevlerini destekleyecek şekilde güncelleştirilir. Kullanılabilir şablon işlevlerinin ayrıntılı açıklaması için bkz. ARM şablonu işlevleri.

Azure Resource Manager tanıtılan yeni şablon işlevleri bağımsız bulutlarda veya Azure Stack'te hemen kullanılamaz. Bir şablonu başarıyla dağıtmak için, şablonda başvuruda bulunulan tüm işlevlerin hedef bulutta kullanılabilir olması gerekir.

Azure Resource Manager özellikleri her zaman önce genel Azure'a tanıtılacaktır. Yeni tanıtılan şablon işlevlerinin Azure Stack'te de kullanılabilir olup olmadığını doğrulamak için aşağıdaki PowerShell betiğini kullanabilirsiniz:

GitHub deposunun bir kopyasını oluşturun: https://github.com/marcvaneijk/arm-template-functions.
Deponun yerel bir kopyasına sahip olduktan sonra PowerShell ile hedefin Azure Resource Manager bağlanın.

psm1 modülünü içeri aktarın ve Test-AzureRmTemplateFunctions cmdlet'ini yürütün:

# Import the module
Import-module <path to local clone>\AzTemplateFunctions.psm1

# Execute the Test-AzureRmTemplateFunctions cmdlet
Test-AzureRmTemplateFunctions -path <path to local clone>

Betik, her birinde yalnızca benzersiz şablon işlevleri bulunan birden çok simge durumuna küçültülmüş şablon dağıtır. Betiğin çıktısı, desteklenen ve kullanılamayan şablon işlevlerini bildirir.

Bağlantılı yapıtlarla çalışma

Şablon, bağlantılı yapıtlara başvurular içerebilir ve başka bir şablona bağlanan bir dağıtım kaynağı içerebilir. Bağlı şablonlar (iç içe şablon olarak da adlandırılır) çalışma zamanında Resource Manager tarafından alınır. Şablon, sanal makine (VM) uzantıları için yapıtlara başvurular da içerebilir. Bu yapıtlar, şablon dağıtımı sırasında VM uzantısının yapılandırılması için VM'nin içinde çalışan VM uzantısı tarafından alınır.

Aşağıdaki bölümlerde, ana dağıtım şablonunun dışında kalan yapıtlar içeren şablonlar geliştirirken bulut tutarlılığı konusunda dikkat edilmesi gereken noktalar açıklanmaktadır.

Bölgeler arasında iç içe şablonları kullanma

Şablonlar, her biri belirli bir amaca sahip olan ve dağıtım senaryolarında yeniden kullanılabilen küçük, yeniden kullanılabilir şablonlar halinde ayrıştırılabilir. Bir dağıtımı yürütmek için ana veya ana şablon olarak bilinen tek bir şablon belirtirsiniz. Sanal ağlar, VM'ler ve web uygulamaları gibi dağıtılacak kaynakları belirtir. Ana şablon başka bir şablona bağlantı da içerebilir; bu da şablonları iç içe yerleştirebileceğiniz anlamına gelir. Benzer şekilde, iç içe yerleştirilmiş bir şablon diğer şablonlara bağlantılar içerebilir. Beş düzeye kadar iç içe yerleştirebilirsiniz.

Aşağıdaki kod templateLink parametresinin iç içe yerleştirilmiş bir şablona nasıl başvurduğu gösterir:

"resources": [
  {
     "type": "Microsoft.Resources/deployments",
     "apiVersion": "2020-10-01",
     "name": "linkedTemplate",
     "properties": {
       "mode": "incremental",
       "templateLink": {
          "uri":"https://mystorageaccount.blob.core.windows.net/AzureTemplates/vNet.json",
          "contentVersion":"1.0.0.0"
       }
     }
  }
]

Azure Resource Manager, çalışma zamanında ana şablonu değerlendirir ve iç içe yerleştirilmiş her şablonu alır ve değerlendirir. İç içe yerleştirilmiş tüm şablonlar alındıktan sonra şablon düzleştirilir ve daha fazla işlem başlatılır.

Bağlantılı şablonları bulutlar arasında erişilebilir hale getirme

Kullandığınız bağlantılı şablonları nerede ve nasıl depolayabileceğinizi göz önünde bulundurun. Çalışma zamanında Azure Resource Manager tüm bağlantılı şablonları getirir ve bu nedenle doğrudan erişim gerektirir. İç içe şablonları depolamak için GitHub'ı kullanmak yaygın bir uygulamadır. GitHub deposu, URL aracılığıyla genel olarak erişilebilen dosyalar içerebilir. Bu teknik genel bulut ve bağımsız bulutlar için iyi çalışsa da, Azure Stack ortamı giden İnternet erişimi olmadan bir şirket ağında veya bağlantısı kesilmiş uzak bir konumda bulunabilir. Bu gibi durumlarda Azure Resource Manager iç içe şablonları alamaz.

Bulutlar arası dağıtımlar için daha iyi bir uygulama, bağlantılı şablonlarınızı hedef bulut için erişilebilir bir konumda depolamaktır. İdeal olarak tüm dağıtım yapıtları sürekli tümleştirme/sürekli geliştirme (CI/CD) işlem hattında tutulur ve dağıtılır. Alternatif olarak, iç içe yerleştirilmiş şablonları Azure Resource Manager tarafından alınabilecek bir blob depolama kapsayıcısında depolayabilirsiniz.

Her bulut üzerindeki blob depolama farklı bir uç nokta tam etki alanı adı (FQDN) kullandığından, şablonu bağlı şablonların konumuyla iki parametreyle yapılandırın. Parametreler dağıtım zamanında kullanıcı girişini kabul edebilir. Şablonlar genellikle birden çok kişi tarafından yazılır ve paylaşılır, bu nedenle en iyi yöntem bu parametreler için standart bir ad kullanmaktır. Adlandırma kuralları, şablonların bölgeler, bulutlar ve yazarlar arasında daha fazla yeniden kullanılabilir olmasını sağlamaya yardımcı olur.

Aşağıdaki kodda, _artifactsLocation dağıtımla ilgili tüm yapıtları içeren tek bir konuma işaret etmek için kullanılır. Varsayılan bir değer sağlandığına dikkat edin. Dağıtım zamanında için hiçbir giriş değeri belirtilmezse _artifactsLocationvarsayılan değer kullanılır. _artifactsLocationSasToken, için sasTokengiriş olarak kullanılır. Varsayılan değer, güvenliği sağlanmadığı _artifactsLocation senaryolar için boş bir dize (örneğin, genel bir GitHub deposu) olmalıdır.

"parameters": {
  "_artifactsLocation": {
    "type": "string",
    "metadata": {
      "description": "The base URI where artifacts required by this template are located."
    },
    "defaultValue": "https://raw.githubusercontent.com/Azure/azure-quickstart-templates/master/quickstarts/microsoft.compute/vm-custom-script-windows/"
  },
  "_artifactsLocationSasToken": {
    "type": "securestring",
    "metadata": {
      "description": "The sasToken required to access _artifactsLocation."
    },
    "defaultValue": ""
  }
}

Şablon boyunca bağlantılar, temel URI (parametresinden _artifactsLocation ) bir yapıt göreli yolu ve _artifactsLocationSasTokenile birleştirilerek oluşturulur. Aşağıdaki kod, uri şablonu işlevini kullanarak iç içe şablon bağlantısının nasıl belirtileceğini gösterir:

"resources": [
  {
    "type": "Microsoft.Resources/deployments",
    "apiVersion": "2020-10-01",
    "name": "shared",
    "properties": {
      "mode": "Incremental",
      "templateLink": {
        "uri": "[uri(parameters('_artifactsLocation'), concat('nested/vnet.json', parameters('_artifactsLocationSasToken')))]",
        "contentVersion": "1.0.0.0"
      }
    }
  }
]

Bu yaklaşım kullanıldığında parametresi için _artifactsLocation varsayılan değer kullanılır. Bağlantılı şablonların farklı bir konumdan alınması gerekiyorsa, varsayılan değeri geçersiz kılmak için dağıtım zamanında parametre girişi kullanılabilir; şablonun kendisinde değişiklik yapılması gerekmez.

Sabit kodlama bağlantıları yerine _artifactsLocation kullanın

İç içe şablonlar için kullanılmasının yanı sıra, parametresindeki URL bir dağıtım şablonunun _artifactsLocation tüm ilgili yapıtları için temel olarak kullanılır. Bazı VM uzantıları, şablonun dışında depolanan bir betiğin bağlantısını içerir. Bu uzantılar için bağlantıları sabit kodlamamalısınız. Örneğin, Özel Betik ve PowerShell DSC uzantıları, gösterildiği gibi GitHub'da bir dış betik bağlantısı verebilir:

"properties": {
  "publisher": "Microsoft.Compute",
  "type": "CustomScriptExtension",
  "typeHandlerVersion": "1.9",
  "autoUpgradeMinorVersion": true,
  "settings": {
    "fileUris": [
      "https://raw.githubusercontent.com/Microsoft/dotnet-core-sample-templates/master/dotnet-core-music-windows/scripts/configure-music-app.ps1"
    ]
  }
}

Betiğin bağlantılarını sabit kodlamak, şablonun başka bir konuma başarıyla dağıtılmasını engelleyebilir. VM kaynağının yapılandırması sırasında, VM içinde çalışan VM aracısı, VM uzantısına bağlı tüm betiklerin indirilmesini başlatır ve ardından betikleri VM'nin yerel diskinde depolar. Bu yaklaşım, daha önce "Bölgeler arasında iç içe şablonları kullanma" bölümünde açıklanan iç içe şablon bağlantıları gibi çalışır.

Resource Manager çalışma zamanında iç içe şablonları alır. VM uzantıları için, herhangi bir dış yapıtın alınması VM aracısı tarafından gerçekleştirilir. Yapıt alma işleminin farklı başlatıcısının yanı sıra şablon tanımındaki çözüm de aynıdır. _artifactsLocation parametresini, tüm yapıtların depolandığı temel yolun varsayılan değeriyle (VM uzantısı betikleri dahil) ve _artifactsLocationSasToken sasToken girişinin parametresiyle kullanın.

"parameters": {
  "_artifactsLocation": {
    "type": "string",
    "metadata": {
      "description": "The base URI where artifacts required by this template are located."
    },
    "defaultValue": "https://raw.githubusercontent.com/Microsoft/dotnet-core-sample-templates/master/dotnet-core-music-windows/"
  },
  "_artifactsLocationSasToken": {
    "type": "securestring",
    "metadata": {
      "description": "The sasToken required to access _artifactsLocation."
    },
    "defaultValue": ""
  }
}

Bir yapıtın mutlak URI'sini oluşturmak için tercih edilen yöntem, concat şablon işlevi yerine uri şablon işlevini kullanmaktır. Sabit kodlanmış bağlantıları VM uzantısındaki betiklere uri şablon işleviyle değiştirerek, şablondaki bu işlev bulut tutarlılığı için yapılandırılır.

"properties": {
  "publisher": "Microsoft.Compute",
  "type": "CustomScriptExtension",
  "typeHandlerVersion": "1.9",
  "autoUpgradeMinorVersion": true,
  "settings": {
    "fileUris": [
      "[uri(parameters('_artifactsLocation'), concat('scripts/configure-music-app.ps1', parameters('_artifactsLocationSasToken')))]"
    ]
  }
}

Bu yaklaşımla, yapılandırma betikleri de dahil olmak üzere tüm dağıtım yapıtları şablonun kendisiyle aynı konumda depolanabilir. Tüm bağlantıların konumunu değiştirmek için artifactsLocation parametreleri için yalnızca farklı bir temel URL belirtmeniz gerekir.

Farklı bölgesel özellikleri dikkate alma

Azure'a sunulan güncelleştirmelerin ve yeni hizmetlerin çevik geliştirmesi ve sürekli akışıyla, bölgeler hizmetlerin veya güncelleştirmelerin kullanılabilirliği açısından farklılık gösterebilir . Sıkı iç testlerden sonra, mevcut hizmetlere yönelik yeni hizmetler veya güncelleştirmeler genellikle bir doğrulama programına katılan küçük bir müşteri kitlesine sunulur. Müşteri doğrulaması başarılı olduktan sonra hizmetler veya güncelleştirmeler Azure bölgelerinin bir alt kümesinde kullanıma sunulur, daha sonra daha fazla bölgeye tanıtılır, bağımsız bulutlara dağıtılır ve potansiyel olarak Azure Stack müşterileri için de kullanılabilir hale gelir.

Azure bölgelerinin ve bulutlarının kullanılabilir hizmetlerinde farklılık gösterebileceğini bilerek şablonlarınız hakkında proaktif kararlar alabilirsiniz. Başlamak için iyi bir yer, bulut için kullanılabilir kaynak sağlayıcılarını incelemektir. Kaynak sağlayıcısı, bir Azure hizmeti için kullanılabilen kaynak ve işlem kümesini bildirir.

Bir şablon kaynakları dağıtır ve yapılandırr. Kaynak türü bir kaynak sağlayıcısı tarafından sağlanır. Örneğin, işlem kaynağı sağlayıcısı (Microsoft.Compute), virtualMachines ve availabilitySets gibi birden çok kaynak türü sağlar. Her kaynak sağlayıcısı, azure Resource Manager ortak bir sözleşmeyle tanımlanan bir API sunarak tüm kaynak sağlayıcılarında tutarlı, birleşik bir yazma deneyimi sağlar. Ancak, genel Azure'da kullanılabilen bir kaynak sağlayıcısı bağımsız bir bulutta veya Azure Stack bölgesinde kullanılamayabilir.

Kaynak sağlayıcıları, kaynak türleri ve API sürümleri arasındaki ilişkiyi gösteren diyagram.

Belirli bir bulutta kullanılabilen kaynak sağlayıcılarını doğrulamak için Azure CLI'da aşağıdaki betiği çalıştırın:

az provider list --query "[].{Provider:namespace, Status:registrationState}" --out table

Kullanılabilir kaynak sağlayıcılarını görmek için aşağıdaki PowerShell cmdlet'ini de kullanabilirsiniz:

Get-AzureRmResourceProvider -ListAvailable | Select-Object ProviderNamespace, RegistrationState

Tüm kaynak türlerinin sürümünü doğrulama

Bir özellik kümesi tüm kaynak türleri için ortaktır, ancak her kaynağın kendi özel özellikleri de vardır. Yeni özellikler ve ilgili özellikler, yeni bir API sürümü aracılığıyla zaman zaman mevcut kaynak türlerine eklenir. Şablondaki bir kaynağın kendi API sürümü özelliği vardır: apiVersion. Bu sürüm oluşturma, bir şablondaki mevcut kaynak yapılandırmasının platformdaki değişikliklerden etkilenmemesini sağlar.

Genel Azure'daki mevcut kaynak türlerine sunulan yeni API sürümleri tüm bölgelerde, bağımsız bulutlarda veya Azure Stack'te hemen kullanılamayabilir. Bulut için kullanılabilir kaynak sağlayıcılarının, kaynak türlerinin ve API sürümlerinin listesini görüntülemek için Azure portal'de Kaynak Gezgini'ni kullanabilirsiniz. Tüm Hizmetler menüsünde Kaynak Gezgini'ni arayın. Kaynak Gezgini'ndeki Sağlayıcılar düğümünü genişleterek kullanılabilir tüm kaynak sağlayıcılarını, kaynak türlerini ve bu buluttaki API sürümlerini döndürebilirsiniz.

Azure CLI'daki belirli bir buluttaki tüm kaynak türleri için kullanılabilir API sürümünü listelemek için aşağıdaki betiği çalıştırın:

az provider list --query "[].{namespace:namespace, resourceType:resourceType[]}"

Aşağıdaki PowerShell cmdlet'ini de kullanabilirsiniz:

Get-AzureRmResourceProvider | select-object ProviderNamespace -ExpandProperty ResourceTypes | ft ProviderNamespace, ResourceTypeName, ApiVersions

Parametre ile kaynak konumlarına bakın

Şablon her zaman bir bölgede bulunan bir kaynak grubuna dağıtılır. Dağıtımın yanı sıra, bir şablondaki her kaynağın dağıtılacak bölgeyi belirtmek için kullandığınız bir konum özelliği de vardır. Şablonunuzu bulut tutarlılığı için geliştirmek için kaynak konumlarına başvurmak için dinamik bir yönteme ihtiyacınız vardır çünkü her Azure Stack benzersiz konum adları içerebilir. Kaynaklar genellikle kaynak grubuyla aynı bölgeye dağıtılır, ancak bölgeler arası uygulama kullanılabilirliği gibi senaryoları desteklemek için kaynakları bölgelere yaymak yararlı olabilir.

Bir şablonda kaynak özelliklerini belirtirken bölge adlarını sabit kodlamanız mümkün olsa da, bölge adı büyük olasılıkla orada olmadığından bu yaklaşım şablonun diğer Azure Stack ortamlarına dağıtılabilmesini garanti etmez.

Farklı bölgeleri barındırmak için şablona varsayılan değerle bir giriş parametresi konumu ekleyin. Dağıtım sırasında hiçbir değer belirtilmezse varsayılan değer kullanılır.

Şablon işlevi [resourceGroup()] aşağıdaki anahtar/değer çiftlerini içeren bir nesne döndürür:

{
  "id": "/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}",
  "name": "{resourceGroupName}",
  "location": "{resourceGroupLocation}",
  "tags": {
  },
  "properties": {
    "provisioningState": "{status}"
  }
}

Giriş parametresinin defaultValue değerindeki nesnenin konum anahtarına başvurarak Azure Resource Manager, çalışma zamanında şablon işlevini şablonun dağıtılacağı kaynak grubunun konumuyla değiştirir[resourceGroup().location].

"parameters": {
  "location": {
    "type": "string",
    "metadata": {
      "description": "Location the resources will be deployed to."
    },
    "defaultValue": "[resourceGroup().location]"
  }
},
"resources": [
  {
    "type": "Microsoft.Storage/storageAccounts",
    "apiVersion": "2015-06-15",
    "name": "storageaccount1",
    "location": "[parameters('location')]",
    ...

Bu şablon işleviyle, önceden bölge adlarını bile bilmeden şablonunuzu herhangi bir buluta dağıtabilirsiniz. Ayrıca, şablondaki belirli bir kaynağın konumu kaynak grubu konumundan farklı olabilir. Bu durumda, söz konusu kaynak için ek giriş parametreleri kullanarak yapılandırabilirsiniz, ancak aynı şablondaki diğer kaynaklar ilk konum giriş parametresini kullanmaya devam eder.

API profillerini kullanarak sürümleri izleme

Azure Stack'te mevcut olan tüm kullanılabilir kaynak sağlayıcılarını ve ilgili API sürümlerini izlemek çok zor olabilir. Örneğin, yazma sırasında, Azure'daki Microsoft.Compute/availabilitySets için en son API sürümü olurken 2018-04-01, Azure ve Azure Stack için ortak olan kullanılabilir API sürümü şeklindedir 2016-03-30. Tüm Azure ve Azure Stack konumları arasında paylaşılan Microsoft.Storage/storageAccounts için ortak API sürümü olurken 2016-01-01, Azure'daki en son API sürümü şeklindedir 2018-02-01.

Bu nedenle Resource Manager şablonlara API profilleri kavramını tanıttı. API profilleri olmadan, bir şablondaki her kaynak ilgili kaynağın API sürümünü açıklayan bir apiVersion öğeyle yapılandırılır.

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "location": {
      "type": "string",
      "metadata": {
          "description": "Location the resources will be deployed to."
      },
      "defaultValue": "[resourceGroup().location]"
    }
  },
  "variables": {},
  "resources": [
    {
      "type": "Microsoft.Storage/storageAccounts",
      "apiVersion": "2016-01-01",
      "name": "mystorageaccount",
      "location": "[parameters('location')]",
      "properties": {
        "accountType": "Standard_LRS"
      }
    },
    {
      "type": "Microsoft.Compute/availabilitySets",
      "apiVersion": "2016-03-30",
      "name": "myavailabilityset",
      "location": "[parameters('location')]",
      "properties": {
        "platformFaultDomainCount": 2,
        "platformUpdateDomainCount": 2
      }
    }
  ],
  "outputs": {}
}

API profili sürümü, Azure ve Azure Stack için ortak olan kaynak türü başına tek bir API sürümü için diğer ad işlevi görür. Şablondaki her kaynak için bir API sürümü belirtmek yerine, adlı apiProfile yeni bir kök öğede yalnızca API profili sürümünü belirtir ve tek tek kaynaklar için öğesini atlarsınız apiVersion .

{
    "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
    "contentVersion": "1.0.0.0",
    "apiProfile": "2018–03-01-hybrid",
    "parameters": {
        "location": {
            "type": "string",
            "metadata": {
                "description": "Location the resources will be deployed to."
            },
            "defaultValue": "[resourceGroup().location]"
        }
    },
    "variables": {},
    "resources": [
        {
            "type": "Microsoft.Storage/storageAccounts",
            "name": "mystorageaccount",
            "location": "[parameters('location')]",
            "properties": {
                "accountType": "Standard_LRS"
            }
        },
        {
            "type": "Microsoft.Compute/availabilitySets",
            "name": "myavailabilityset",
            "location": "[parameters('location')]",
            "properties": {
                "platformFaultDomainCount": 2,
                "platformUpdateDomainCount": 2
            }
        }
    ],
    "outputs": {}
}

API profili, API sürümlerinin konumlar arasında kullanılabilir olmasını sağlar, bu nedenle belirli bir konumda bulunan apiVersion'ları el ile doğrulamanız gerekmez. API profiliniz tarafından başvuruda bulunılan API sürümlerinin bir Azure Stack ortamında mevcut olduğundan emin olmak için, Azure Stack operatörlerinin destek ilkesine göre çözümü güncel tutması gerekir. Bir sistem altı aydan daha eskiyse, uyumsuz olarak kabul edilir ve ortamın güncelleştirilmiş olması gerekir.

API profili şablonda gerekli bir öğe değildir. öğesini ekleseniz bile, yalnızca belirtilmemiş apiVersion kaynaklar için kullanılır. Bu öğe aşamalı değişikliklere izin verir, ancak mevcut şablonlarda herhangi bir değişiklik gerektirmez.

{
    "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
    "contentVersion": "1.0.0.0",
    "apiProfile": "2018–03-01-hybrid",
    "parameters": {
        "location": {
            "type": "string",
            "metadata": {
                "description": "Location the resources will be deployed to."
            },
            "defaultValue": "[resourceGroup().location]"
        }
    },
    "variables": {},
    "resources": [
        {
            "type": "Microsoft.Storage/storageAccounts",
            "apiVersion": "2016-01-01",
            "name": "mystorageaccount",
            "location": "[parameters('location')]",
            "properties": {
                "accountType": "Standard_LRS"
            }
        },
        {
            "type": "Microsoft.Compute/availabilitySets",
            "name": "myavailabilityset",
            "location": "[parameters('location')]",
            "properties": {
                "platformFaultDomainCount": 2,
                "platformUpdateDomainCount": 2
            }
        }
    ],
    "outputs": {}
}

Uç nokta başvurularını denetleme

Kaynakların platformdaki diğer hizmetlere başvuruları olabilir. Örneğin, bir genel IP'ye atanmış bir genel DNS adı olabilir. Genel bulut, bağımsız bulutlar ve Azure Stack çözümlerinin kendi farklı uç nokta ad alanları vardır. Çoğu durumda, bir kaynak şablonda giriş olarak yalnızca bir ön ek gerektirir. Çalışma zamanı sırasında Azure Resource Manager uç nokta değerini ekler. Bazı uç nokta değerlerinin şablonda açıkça belirtilmesi gerekir.

Not

Bulut tutarlılığı için şablonlar geliştirmek için uç nokta ad alanlarını sabit kodlamayın.

Aşağıdaki iki örnek, kaynak oluştururken açıkça belirtilmesi gereken yaygın uç nokta ad alanlarıdır:

Depolama hesapları (blob, kuyruk, tablo ve dosya)
Veritabanları ve Redis için Azure Cache için bağlantı dizeleri

Uç nokta ad alanları, dağıtım tamamlandığında kullanıcı için bilgi olarak bir şablonun çıkışında da kullanılabilir. Aşağıda yaygın örnekler verilmiştir:

Depolama hesapları (blob, kuyruk, tablo ve dosya)
Bağlantı dizeleri (MySql, SQLServer, SQLAzure, Custom, NotificationHub, ServiceBus, EventHub, ApiHub, DocDb, RedisCache, PostgreSQL)
Traffic Manager
genel IP adresinin domainNameLabel'i
Bulut hizmetleri

Genel olarak, şablonda sabit kodlanmış uç noktalardan kaçının. En iyi yöntem, uç noktaları dinamik olarak almak için başvuru şablonu işlevini kullanmaktır. Örneğin, en yaygın olarak sabit kodlanmış uç nokta, depolama hesapları için uç nokta ad alanıdır. Her depolama hesabının, depolama hesabının adı uç nokta ad alanıyla birleştirilerek yapılandırılmış benzersiz bir FQDN'si vardır. mystorageaccount1 adlı bir blob depolama hesabı, buluta bağlı olarak farklı FQDN'lere neden olur:

mystorageaccount1.blob.core.windows.net genel Azure bulutu üzerinde oluşturulduğunda.
mystorageaccount1.blob.core.chinacloudapi.cn 21Vianet bulutu tarafından sağlanan Azure'da oluşturulduğunda.

Aşağıdaki başvuru şablonu işlevi, depolama kaynak sağlayıcısından uç nokta ad alanını alır:

"diskUri":"[concat(reference(resourceId('Microsoft.Storage/storageAccounts', variables('storageAccountName'))).primaryEndpoints.blob, 'container/myosdisk.vhd')]"

Depolama hesabı uç noktasının sabit kodlanmış değerini şablon işleviyle reference değiştirerek, uç nokta başvurusunda herhangi bir değişiklik yapmadan farklı ortamlara başarıyla dağıtmak için aynı şablonu kullanabilirsiniz.

Benzersiz kimlikle mevcut kaynaklara bakın

Ayrıca, aynı veya başka bir kaynak grubundan ve aynı abonelikte veya başka bir abonelikte, aynı buluttaki aynı kiracıda bulunan mevcut bir kaynağa da başvurabilirsiniz. Kaynak özelliklerini almak için kaynağın kendisi için benzersiz tanımlayıcıyı kullanmanız gerekir. Şablon resourceId işlevi, aşağıdaki kodda gösterildiği gibi SQL Server gibi bir kaynağın benzersiz kimliğini alır:

"outputs": {
  "resourceId":{
    "type": "string",
    "value": "[resourceId('otherResourceGroup', 'Microsoft.Sql/servers', parameters('serverName'))]"
  }
}

Daha sonra bir veritabanının resourceId özelliklerini almak için şablon işlevinin içindeki reference işlevini kullanabilirsiniz. Dönüş nesnesi, tam uç nokta değerini tutan özelliği içerir fullyQualifiedDomainName . Bu değer çalışma zamanında alınır ve bulut ortamına özgü uç nokta ad alanını sağlar. Uç nokta ad alanını sabit kodlamadan bağlantı dizesini tanımlamak için, döndürülen nesnenin özelliğine gösterildiği gibi doğrudan bağlantı dizesinde başvurabilirsiniz:

"[concat('Server=tcp:', reference(resourceId('sql', 'Microsoft.Sql/servers', parameters('test')), '2015-05-01-preview').fullyQualifiedDomainName, ',1433;Initial Catalog=', parameters('database'),';User ID=', parameters('username'), ';Password=', parameters('pass'), ';Encrypt=True;')]"

Kaynak özelliklerini göz önünde bulundurun

Azure Stack ortamlarındaki belirli kaynakların şablonunuzda dikkate almanız gereken benzersiz özellikleri vardır.

VM görüntülerinin kullanılabilir olduğundan emin olun

Azure, vm görüntülerinin zengin bir seçkisini sağlar. Bu görüntüler Microsoft ve iş ortakları tarafından oluşturulur ve dağıtım için hazırlanır. Görüntüler, platformdaki VM'lerin temelini oluşturur. Ancak bulutla tutarlı bir şablon yalnızca kullanılabilir parametrelere (özellikle genel Azure, Azure bağımsız bulutları veya Azure Stack çözümü için kullanılabilen VM görüntülerinin yayımcısı, teklifi ve SKU'su) başvurmalıdır.

Bir konumdaki kullanılabilir VM görüntülerinin listesini almak için aşağıdaki Azure CLI komutunu çalıştırın:

az vm image list -all

Get-AzureRmVMImagePublisher Azure PowerShell cmdlet'i ile aynı listeyi alabilir ve parametresiyle -Location istediğiniz konumu belirtebilirsiniz. Örnek:

Get-AzureRmVMImagePublisher -Location "West Europe" | Get-AzureRmVMImageOffer | Get-AzureRmVMImageSku | Get-AzureRmVMImage

Bu komutun küresel Azure bulutunun Batı Avrupa bölgesindeki tüm kullanılabilir görüntüleri döndürmesi birkaç dakika sürer.

Bu VM görüntülerini Azure Stack'in kullanımına sunsaydınız tüm kullanılabilir depolama alanı kullanılırdı. Azure Stack, en küçük ölçek birimini bile barındırmak için bir ortama eklemek istediğiniz görüntüleri seçmenize olanak tanır.

Aşağıdaki kod örneği ARM şablonlarınızdaki yayımcı, teklif ve SKU parametrelerine başvurmak için tutarlı bir yaklaşım gösterir:

"storageProfile": {
    "imageReference": {
    "publisher": "MicrosoftWindowsServer",
    "offer": "WindowsServer",
    "sku": "2016-Datacenter",
    "version": "latest"
    }
}

Yerel VM boyutlarını denetleme

Şablonunuzu bulut tutarlılığı için geliştirmek için, istediğiniz VM boyutunun tüm hedef ortamlarda kullanılabilir olduğundan emin olmanız gerekir. VM boyutları, performans özelliklerinin ve özelliklerinin gruplandırılmasıdır. Bazı VM boyutları, VM'nin üzerinde çalıştığı donanıma bağlıdır. Örneğin, GPU için iyileştirilmiş bir VM dağıtmak istiyorsanız hiper yöneticiyi çalıştıran donanımın donanım GPU'larına sahip olması gerekir.

Microsoft belirli donanım bağımlılıklarına sahip yeni bir VM boyutu sağladığında, VM boyutu genellikle önce Azure bulutundaki bölgelerin küçük bir alt kümesinde kullanılabilir hale getirilir. Daha sonra diğer bölgelerin ve bulutların kullanımına sunulur. Dağıttığınız her bulutta VM boyutunun mevcut olduğundan emin olmak için aşağıdaki Azure CLI komutuyla kullanılabilir boyutları alabilirsiniz:

az vm list-sizes --location "West Europe"

Azure PowerShell için şunu kullanın:

Get-AzureRmVMSize -Location "West Europe"

Kullanılabilir hizmetlerin tam listesi için bkz. Bölgeye göre kullanılabilir ürünler.

Azure Stack'te Azure Yönetilen Diskler kullanımını denetleme

Yönetilen diskler bir Azure kiracısı için depolamayı işler. Açıkça bir depolama hesabı oluşturmak ve sanal sabit disk (VHD) için URI'yi belirtmek yerine, vm dağıtırken bu eylemleri örtük olarak gerçekleştirmek için yönetilen diskleri kullanabilirsiniz. Yönetilen diskler, VM'lerdeki tüm diskleri aynı kullanılabilirlik kümesindeki farklı depolama birimlerine yerleştirerek kullanılabilirliği artırır. Ayrıca, mevcut VHD'ler önemli ölçüde daha az kapalı kalma süresiyle Standart depolamadan Premium depolamaya dönüştürülebilir.

Yönetilen diskler Azure Stack yol haritasında olsa da şu anda desteklenmemektedir. Bunlar oluşturulana kadar, gösterildiği gibi VM kaynağı için şablondaki öğesini kullanarak vhd VHD'leri açıkça belirterek Azure Stack için bulutla tutarlı şablonlar geliştirebilirsiniz:

"storageProfile": {
  "imageReference": {
    "publisher": "MicrosoftWindowsServer",
    "offer": "WindowsServer",
    "sku": "[parameters('windowsOSVersion')]",
    "version": "latest"
  },
  "osDisk": {
    "name": "osdisk",
    "vhd": {
      "uri": "[concat(reference(resourceId('Microsoft.Storage/storageAccounts/', variables('storageAccountName')), '2015-06-15').primaryEndpoints.blob, 'vhds/osdisk.vhd')]"
    },
    "caching": "ReadWrite",
    "createOption": "FromImage"
  }
}

Buna karşılık, bir şablonda yönetilen disk yapılandırmasını belirtmek için öğesini disk yapılandırmasından kaldırın vhd .

"storageProfile": {
  "imageReference": {
    "publisher": "MicrosoftWindowsServer",
    "offer": "WindowsServer",
    "sku": "[parameters('windowsOSVersion')]",
    "version": "latest"
  },
  "osDisk": {
    "caching": "ReadWrite",
    "createOption": "FromImage"
  }
}

Aynı değişiklikler veri disklerini de uygular.

VM uzantılarının Azure Stack'te kullanılabilir olduğunu doğrulayın

Bulut tutarlılığı konusunda dikkat edilmesi gereken bir diğer nokta da sanal makine uzantılarının vm içindeki kaynakları yapılandırmak için kullanılmasıdır. Tüm VM uzantıları Azure Stack'te kullanılamaz. Şablon, VM uzantısına ayrılmış kaynakları belirterek şablon içinde bağımlılıklar ve koşullar oluşturabilir.

Örneğin, Microsoft SQL Server çalıştıran bir VM yapılandırmak istiyorsanız, VM uzantısı şablon dağıtımının bir parçası olarak SQL Server yapılandırabilir. Dağıtım şablonu, SQL Server çalıştıran VM'de veritabanı oluşturmak için yapılandırılmış bir uygulama sunucusu da içeriyorsa ne olacağını göz önünde bulundurun. Uygulama sunucuları için bir VM uzantısı kullanmanın yanı sıra, SQL Server VM uzantısı kaynağının başarılı bir şekilde döndürülmesiyle uygulama sunucusunun bağımlılığını yapılandırabilirsiniz. Bu yaklaşım, SQL Server çalıştıran VM'nin yapılandırılmasını ve uygulama sunucusuna veritabanını oluşturma talimatı verildiğinde kullanılabilir olmasını sağlar.

Şablonun bildirim temelli yaklaşımı, kaynakların ve bunların bağımlılıkları arasında son durumunu tanımlamanızı sağlarken, platform bağımlılıklar için gerekli mantığın bakımını üstlenir.

VM uzantılarının kullanılabilir olup olmadığını denetleyin

Birçok vm uzantısı türü vardır. Bulut tutarlılığı için şablon geliştirirken, yalnızca şablon hedeflerinin tüm bölgelerinde bulunan uzantıları kullandığınızdan emin olun.

Belirli bir bölge için kullanılabilen VM uzantılarının listesini almak için (bu örnekte, myLocation) aşağıdaki Azure CLI komutunu çalıştırın:

az vm extension image list --location myLocation

Azure PowerShell Get-AzureRmVmImagePublisher cmdlet'ini yürütebilir ve sanal makine görüntüsünün konumunu belirtmek için kullanabilirsiniz-Location. Örnek:

Get-AzureRmVmImagePublisher -Location myLocation | Get-AzureRmVMExtensionImageType | Get-AzureRmVMExtensionImage | Select Type, Version

Sürümlerin kullanılabilir olduğundan emin olun

VM uzantıları birinci taraf Resource Manager kaynakları olduğundan, kendi API sürümleri vardır. Aşağıdaki kodda gösterildiği gibi, VM uzantısı türü Microsoft.Compute kaynak sağlayıcısında iç içe yerleştirilmiş bir kaynaktır.

{
    "type": "Microsoft.Compute/virtualMachines/extensions",
    "apiVersion": "2015-06-15",
    "name": "myExtension",
    "location": "[parameters('location')]",
    ...

VM uzantısı kaynağının API sürümü, şablonunuzla hedeflemeyi planladığınız tüm konumlarda bulunmalıdır. Konum bağımlılığı, daha önce "Tüm kaynak türlerinin sürümünü doğrulama" bölümünde açıklanan kaynak sağlayıcısı API sürümü kullanılabilirliği gibi çalışır.

VM uzantısı kaynağının kullanılabilir API sürümlerinin listesini almak için, aşağıda gösterildiği gibi Microsoft.Compute kaynak sağlayıcısı ile Get-AzureRmResourceProvider cmdlet'ini kullanın:

Get-AzureRmResourceProvider -ProviderNamespace "Microsoft.Compute" | Select-Object -ExpandProperty ResourceTypes | Select ResourceTypeName, Locations, ApiVersions | where {$_.ResourceTypeName -eq "virtualMachines/extensions"}

Sanal makine ölçek kümelerinde VM uzantılarını da kullanabilirsiniz. Aynı konum koşulları geçerlidir. Şablonunuzu bulut tutarlılığı için geliştirmek için, API sürümlerinin dağıtım yapmayı planladığınız tüm konumlarda kullanılabilir olduğundan emin olun. Ölçek kümeleri için VM uzantısı kaynağının API sürümlerini almak için, öncekiyle aynı cmdlet'i kullanın, ancak gösterildiği gibi sanal makine ölçek kümeleri kaynak türünü belirtin:

Get-AzureRmResourceProvider -ProviderNamespace "Microsoft.Compute" | Select-Object -ExpandProperty ResourceTypes | Select ResourceTypeName, Locations, ApiVersions | where {$_.ResourceTypeName -eq "virtualMachineScaleSets/extensions"}

Belirli uzantıların her biri de sürüm olarak oluşturulur. Bu sürüm, VM uzantısının özelliğinde typeHandlerVersion gösterilir. Şablonunuzun VM uzantılarının typeHandlerVersion öğesinde belirtilen sürümün, şablonu dağıtmayı planladığınız konumlarda kullanılabilir olduğundan emin olun. Örneğin, aşağıdaki kod 1.7 sürümünü belirtir:

{
    "type": "extensions",
    "apiVersion": "2016-03-30",
    "name": "MyCustomScriptExtension",
    "location": "[parameters('location')]",
    "dependsOn": [
        "[concat('Microsoft.Compute/virtualMachines/myVM', copyindex())]"
    ],
    "properties": {
        "publisher": "Microsoft.Compute",
        "type": "CustomScriptExtension",
        "typeHandlerVersion": "1.7",
        ...

Belirli bir VM uzantısı için kullanılabilir sürümlerin listesini almak için Get-AzureRmVMExtensionImage cmdlet'ini kullanın. Aşağıdaki örnek, myLocation'dan PowerShell DSC (Desired State Configuration) VM uzantısı için kullanılabilir sürümleri alır:

Get-AzureRmVMExtensionImage -Location myLocation -PublisherName Microsoft.PowerShell -Type DSC | FT

Yayımcıların listesini almak için Get-AzureRmVmImagePublisher komutunu kullanın. İstek türü için Get-AzureRmVMExtensionImageType commend komutunu kullanın.

Test ve otomasyon ipuçları

Şablon yazarken tüm ilgili ayarları, özellikleri ve sınırlamaları izlemek zor olabilir. Yaygın yaklaşım, diğer konumlar hedeflenmeden önce şablonları tek bir bulutta geliştirmek ve test etmektir. Ancak, testler yazma işleminde ne kadar erken gerçekleştirilirse geliştirme ekibinizin daha az sorun giderme ve kod yeniden yazma işlemi yapması gerekir. Konum bağımlılıkları nedeniyle başarısız olan dağıtımlar, sorunları gidermek için zaman alabilir. Bu nedenle, yazma döngüsünde mümkün olduğunca erken otomatik test önerilir. Sonuç olarak daha az geliştirme süresine ve daha az kaynağa ihtiyacınız olacak ve bulutla tutarlı yapıtlarınız daha da değerli hale gelecektir.

Aşağıdaki görüntüde, tümleşik geliştirme ortamı (IDE) kullanan bir ekip için geliştirme sürecinin tipik bir örneği gösterilmektedir. Zaman çizelgesinin farklı aşamalarında farklı test türleri yürütülür. Burada iki geliştirici aynı çözüm üzerinde çalışmaktadır ancak bu senaryo tek bir geliştirici veya büyük bir ekip için de geçerlidir. Her geliştirici genellikle merkezi bir deponun yerel bir kopyasını oluşturur ve her birinin aynı dosyalar üzerinde çalışan diğer dosyaları etkilemeden yerel kopya üzerinde çalışmasını sağlar.

Yerel IDE'lerdeki paralel birim testlerini ve tümleştirme testlerini gösteren diyagram; birim testleri, tümleştirme testleri, test dağıtımı ve son dağıtım ile CI/CD geliştirme akışına birleştirilir.

Test ve otomasyon için aşağıdaki ipuçlarını göz önünde bulundurun:

Test araçlarını kullanın. Örneğin, Visual Studio Code ve Visual Studio, şablonlarınızı doğrulamanıza yardımcı olabilecek IntelliSense ve diğer özellikleri içerir.
Yerel IDE'de geliştirme sırasında kod kalitesini geliştirmek için birim testleri ve tümleştirme testleri ile statik kod analizi gerçekleştirin.
İlk geliştirme sırasında daha da iyi bir deneyim için, birim testleri ve tümleştirme testleri yalnızca bir sorun bulunduğunda uyarır ve testlerle devam eder. Bu şekilde, ele alınması gereken sorunları belirleyebilir ve test temelli dağıtım (TDD) olarak da adlandırılan değişikliklerin sırasını belirleyebilirsiniz.
Bazı testlerin Azure Resource Manager bağlanmadan gerçekleştirilebileceğini unutmayın. Şablon dağıtımlarını test etme gibi diğerleri, çevrimdışı gerçekleştirilemeyen bazı eylemleri gerçekleştirmek için Resource Manager gerektirir.
Bir dağıtım şablonunu doğrulama API'sine karşı test etmek gerçek bir dağıtıma eşit değildir. Ayrıca, bir şablonu yerel bir dosyadan dağıtsanız bile, şablondaki iç içe şablonlara yapılan tüm başvurular doğrudan Resource Manager tarafından alınır ve VM uzantıları tarafından başvuruda bulunılan yapıtlar dağıtılan VM içinde çalışan VM aracısı tarafından alınır.