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. Az Ve AzureRM modülleri, PowerShell'in aynı sürümleri için yüklendiğinde uyumlu değildir. 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 indirin ve 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.
21Vianet tarafından sağlanan Azure Almanya, Azure Kamu ve Microsoft Azure gibi yalıtılmış bağımsız bulutlar. Bağımsız bulutlar, küresel Azure müşterilerinin eriştikleri harika özelliklerin çoğuyla 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 (bazen barındırılan bölgeler olarak da bilinir) çalıştırabilir.

Tüm bu bulutların merkezinde, Azure Resource Manager çok çeşitli kullanıcı arabirimlerinin Azure platformuyla iletişim kurmasını sağlayan bir API sağlar. Bu API size güçlü kod olarak altyapı özellikleri sunar. 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, bağımsız bulutlar, barındırılan bulutlar 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 göz önünde bulundurmanız gereken 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'a sunulan 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 bulunulmuş tüm işlevlerin hedef bulutta kullanılabilir olması gerekir.

Azure Resource Manager özellikleri her zaman ilk olarak genel Azure'a tanıtılı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'a 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 içeren birden çok simge durumuna küçültülmüş şablon dağıtır. Betiğin çıkışı desteklenen ve kullanılamayan şablon işlevlerini raporlar.

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 gerekenler 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 şablonun bağlantısını 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. tüm iç içe şablonlar alındıktan sonra şablon düzleştirilmiş ve daha fazla işleme başlatılmıştı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. Azure Resource Manager çalışma zamanında tüm bağlantılı şablonları getirir ve bu nedenle doğrudan erişim gerektirir. Yaygın bir uygulama, iç içe şablonları depolamak için GitHub'ı kullanmaktı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ş bir uzak 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ğ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'ın bunları alabildiği 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 iki parametreyle bağlantılı şablonların konumuyla 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 hale getirmelerine 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ğinin _artifactsLocation sağlanmadığı senaryolar için boş bir dize (örneğin, genel 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'yi (parametresinden _artifactsLocation ) yapıt göreli yolu ve _artifactsLocationSasTokenile birleştirerek 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ılarak parametresi için _artifactsLocation varsayılan değer kullanılır. Bağlantılı şablonların farklı bir konumdan alınması gerekiyorsa, parametre girişi varsayılan değeri geçersiz kılmak için dağıtım zamanında 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ı GitHub'da aşağıdaki gibi bir dış betikle bağlantı 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ırılması sırasında, VM'nin 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 yerleştirilmiş şablonları alır. VM uzantıları için, tüm dış yapıtları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 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. VM uzantısındaki betiklere sabit kodlanmış bağlantıları 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 özelliklerde faktör

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, yeni hizmetler veya mevcut hizmetlere yapılan güncelleştirmeler genellikle doğrulama programına katılan müşterilerin küçük bir hedef kitlesine sunulur. Müşteri doğrulaması başarılı olduktan sonra hizmetler veya güncelleştirmeler Azure bölgelerinin bir alt kümesi içinde kullanıma sunulur, ardından 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ı, 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'a ortak bir sözleşmeyle tanımlanan bir API sunarak tüm kaynak sağlayıcılarında tutarlı ve 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. Bir 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ında 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 bu buluttaki tüm kullanılabilir kaynak sağlayıcılarını, kaynak türlerini ve 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 kendisinin 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ılabildiğini 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}"
  }
}

Azure Resource Manager, giriş parametresinin defaultValue içindeki nesnenin konum anahtarına başvurarak, ç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, bölge adlarını önceden 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ü olurken2018-04-01, Azure ve Azure Stack için yaygın olarak kullanılan kullanılabilir API sürümü şeklindedir2016-03-30. Tüm Azure ve Azure Stack konumları arasında paylaşılan Microsoft.Storage/storageAccounts için yaygın API sürümü olurken2016-01-01, Azure'daki en son API sürümü şeklindedir2018-02-01.

Bu nedenle Resource Manager, şablonlara API profilleri kavramını tanıttı. API profilleri olmadan, bir şablondaki her kaynak, söz konusu 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 değişiklik yapılmasını 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 ayrı 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şturulurken 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. Yaygın örnekler şunlardır:

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
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 üretilen 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 kaynağı 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, aynı şablonu kullanarak uç nokta başvurusunda herhangi bir değişiklik yapmadan farklı ortamlara başarıyla dağıtabilirsiniz.

Var olan kaynaklara benzersiz kimlikle başvurma

Aynı veya başka bir kaynak grubundan ve aynı abonelikte veya başka bir abonelikte, aynı bulutta aynı kiracıda bulunan mevcut bir kaynağa da başvurabilirsiniz. Kaynak özelliklerini almak için kaynağın benzersiz tanımlayıcısını 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ı dizesi tanımlamak için, döndürülen nesnenin özelliğine gösterildiği gibi doğrudan bağlantı dizesi 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, şablonunuzda dikkate almanız gereken benzersiz özelliklere sahiptir.

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

Azure, zengin bir VM görüntüsü seçimi 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 bir 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'iyle aynı listeyi alabilir ve parametresiyle -Location istediğiniz konumu belirtebilirsiniz. Örneğin:

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

Bu komutun genel 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 bir 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 tanıttığı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. Vm boyutunun dağıttığınız her bulutta 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ümesinde 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 olana 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 diskleri için de geçerlidir.

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

Bulut tutarlılığında 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. Azure Stack'te tüm VM uzantıları 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, uygulama sunucusuna veritabanını oluşturma talimatı verildiğinde SQL Server çalıştıran VM'nin yapılandırılmasını ve kullanılabilir olmasını sağlar.

Şablonun bildirim temelli yaklaşımı, kaynakların son durumunu ve bunların bağımlılıkları arasında tanımlamanızı sağlarken, platform bağımlılıklar için gerekli mantığı ü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 şablonun hedeflediğini tüm bölgelerde kullanılabilen 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), myLocationaşağıdaki Azure CLI komutunu çalıştırın:

az vm extension image list --location myLocation

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

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 mevcut olmalı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ğıdaki gibi Microsoft.Compute kaynak sağlayıcısıyla 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 sanal makine ölçek kümeleri kaynak türünü gösterildiği gibi 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ümlenmiştir. Bu sürüm, VM uzantısının typeHandlerVersion özelliğinde gösterilir. Şablonunuzun VM uzantılarının öğesinde typeHandlerVersion 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 konumundan PowerShell DSC (İstenen Durum Yapılandırması) 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. Tür istemek için Get-AzureRmVMExtensionImageType commend değerini 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, yazma işleminde testler ne kadar erken yapılırsa 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 yapmanızı öneririz. 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 çizelgesindeki farklı aşamalarda 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 aynı şekilde geçerlidir. Her geliştirici genellikle merkezi bir deponun yerel kopyasını oluşturur ve her birinin aynı dosyalar üzerinde çalışan diğer kişileri etkilemeden yerel kopya üzerinde çalışmasını sağlar.

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

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, giderilen sorunları belirleyebilir ve test temelli dağıtım (TDD) olarak da adlandırılan değişikliklerin sırasını önceliklendikleyebilirsiniz.
Bazı testlerin Azure Resource Manager'a bağlanmadan gerçekleştirilebileceğini unutmayın. Şablon dağıtımlarını test etme gibi diğerleri, Resource Manager'ın çevrimdışı gerçekleştirilemeyen bazı eylemleri gerçekleştirmesini gerektirir.
Dağıtım şablonunu doğrulama API'sine karşı test etmek gerçek bir dağıtıma eşit değildir. Ayrıca, yerel bir dosyadan şablon 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.

Aracılığıyla paylaş