Bagikan melalui

Mengembangkan templat ARM untuk konsistensi cloud

  • Artikel

Penting

Untuk menggunakan fitur Azure ini dari PowerShell wajib menginstal modul AzureRM. Ini adalah modul lama yang hanya tersedia untuk Windows PowerShell 5.1 yang tidak lagi mendapatkan fitur baru. Modul Az dan AzureRM tidak kompatibel ketika diinstal untuk versi PowerShell yang sama. Jika Anda memerlukan kedua versi:

  1. Hapus instalan modul Az dari sesi PowerShell 5.1.
  2. Instal modul AzureRM dari sesi PowerShell 5.1.
  3. Unduh dan instal PowerShell Core 6.x atau yang lebih baru.
  4. Instal modul Az dalam sesi PowerShell Core.

Keuntungan utama Azure adalah konsistensi. Investasi pengembangan untuk satu lokasi dapat digunakan kembali di lokasi lain. Templat Azure Resource Manager (templat ARM) membuat penyebaran Anda konsisten dan dapat diulang di seluruh lingkungan, termasuk Azure global, sovereign cloud Azure, dan Azure Stack. Namun, untuk menggunakan kembali templat di seluruh cloud, Anda perlu mempertimbangkan dependensi khusus cloud seperti yang dijelaskan panduan ini.

Microsoft menawarkan layanan cloud cerdas siap perusahaan di banyak lokasi, termasuk:

  • Platform Azure global didukung oleh jaringan pusat data yang dikelola Microsoft yang terus berkembang di berbagai wilayah di seluruh dunia.
  • Sovereign cloud terisolasi seperti Azure Jerman, Azure Government, dan Microsoft Azure yang dioperasikan oleh 21Vianet. Sovereign cloud menyediakan platform yang konsisten dengan sebagian besar fitur hebat yang sama dengan yang dapat diakses oleh pelanggan Azure global.
  • Azure Stack, platform cloud hibrid yang memungkinkan Anda mengirimkan layanan Azure dari pusat data organisasi Anda. Perusahaan dapat menyiapkan Azure Stack di pusat data mereka sendiri, atau menggunakan Layanan Azure dari penyedia layanan, menjalankan Azure Stack di fasilitas mereka (kadang-kadang dikenal sebagai wilayah yang dihosting).

Inti dari semua cloud ini, Azure Resource Manager menyediakan API yang memungkinkan berbagai antarmuka pengguna untuk berkomunikasi dengan platform Azure. API ini memberi Anda kemampuan infrastruktur sebagai kode yang kuat. Semua jenis sumber daya yang tersedia di platform cloud Azure dapat disebarkan dan dikonfigurasi dengan Azure Resource Manager. Dengan templat tunggal, Anda dapat menyebarkan dan mengonfigurasi aplikasi lengkap ke status akhir operasional.

Diagram berbagai lingkungan Azure termasuk Azure global, sovereign cloud, dan Azure Stack.

Konsistensi Azure global, sovereign cloud, cloud yang dihosting, dan cloud di pusat data membantu Anda mendapatkan keuntungan dari Azure Resource Manager. Anda dapat menggunakan kembali investasi pengembangan Anda di seluruh cloud ini saat menyiapkan penyebaran dan konfigurasi sumber daya berbasis templat.

Namun, meskipun cloud global, sovereign, dihosting, dan hibrid memberikan layanan yang konsisten, tidak semua cloud identik. Akibatnya, Anda dapat membuat templat dengan dependensi pada fitur yang hanya tersedia di cloud tertentu.

Panduan ini selanjutnya menjelaskan area yang perlu dipertimbangkan saat berencana mengembangkan templat ARM baru atau memperbarui templat ARM yang ada untuk Azure Stack. Secara umum, daftar periksa Anda harus menyertakan item berikut:

  • Verifikasi bahwa fungsi, titik akhir, layanan, dan sumber daya lain dalam templat Anda tersedia di lokasi penyebaran target.
  • Simpan templat berlapis dan artefak konfigurasi di lokasi yang dapat diakses, memastikan akses di seluruh cloud.
  • Gunakan referensi dinamis sebagai ganti tautan dan elemen yang di-hardcode.
  • Pastikan parameter templat yang Anda gunakan berfungsi di cloud target.
  • Verifikasi bahwa properti khusus sumber daya tersedia di cloud target.

Untuk pengenalan templat ARM, lihat Penyebaran templat.

Memastikan fungsi templat berfungsi

Sintaks dasar templat ARM adalah JSON. Templat menggunakan superset JSON, memperluas sintaks dengan ekspresi dan fungsi. Prosesor bahasa templat sering diperbarui untuk mendukung fungsi templat tambahan. Untuk daftar fungsi templat yang tersedia, lihat fungsi templat ARM.

Fungsi templat baru yang diperkenalkan ke Azure Resource Manager tidak segera tersedia di sovereign cloud atau Azure Stack. Agar berhasil menyebarkan templat, semua fungsi yang direferensikan dalam templat harus tersedia di cloud target.

Kemampuan Azure Resource Manager akan selalu diperkenalkan ke Azure global terlebih dahulu. Anda bisa menggunakan skrip PowerShell berikut ini untuk memverifikasi apakah fungsi templat yang baru diperkenalkan juga tersedia di Azure Stack:

  1. Buat kloning repositori GitHub: https://github.com/marcvaneijk/arm-template-functions.

  2. Setelah Anda memiliki klon lokal repositori, sambungkan ke Azure Resource Manager tujuan dengan PowerShell.

  3. Impor modul PSM1 dan jalankan cmdlet Test-AzureRmTemplateFunctions:

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

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

Skrip menyebarkan beberapa templat yang diminimalkan, masing-masing hanya berisi fungsi templat yang unik. Output skrip melaporkan fungsi templat yang didukung dan tidak tersedia.

Bekerja dengan artefak yang ditautkan

Templat dapat berisi referensi ke artefak yang ditautkan dan berisi sumber daya penyebaran yang ditautkan ke templat lain. Templat yang ditautkan (juga disebut sebagai templat berlapis) diambil oleh Resource Manager saat runtime. Templat juga dapat berisi referensi ke artefak untuk ekstensi komputer virtual (VM). Artefak ini diambil oleh ekstensi komputer virtual yang berjalan di dalam komputer virtual untuk konfigurasi ekstensi komputer virtual selama penyebaran templat.

Bagian berikut ini menjelaskan pertimbangan untuk konsistensi cloud saat mengembangkan templat yang menyertakan artefak yang berada di luar templat penyebaran utama.

Menggunakan templat berlapis di seluruh wilayah

Templat dapat diurai menjadi templat kecil yang dapat digunakan kembali, yang masing-masing memiliki tujuan tertentu dan dapat digunakan kembali di seluruh skenario penyebaran. Untuk menjalankan penyebaran, Anda menentukan templat tunggal yang dikenal sebagai templat utama atau master. Ini menentukan sumber daya untuk disebarkan, seperti jaringan virtual, komputer virtual, dan aplikasi web. Templat utama juga dapat berisi tautan ke templat lain, yang berarti Anda dapat melapis templat. Demikian juga, templat berlapis dapat berisi tautan ke templat lain. Anda dapat membuat lapisan hingga lima tingkat.

Kode berikut menunjukkan bagaimana parameter templateLink mengacu pada templat berlapis:

"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 mengevaluasi templat utama pada runtime serta mengambil dan mengevaluasi setiap templat berlapis. Setelah semua templat berlapis diambil, templat diratakan, dan pemrosesan lebih lanjut dimulai.

Membuat templat tertaut dapat diakses di seluruh cloud

Pertimbangkan di mana dan bagaimana cara menyimpan templat tertaut yang Anda gunakan. Saat runtime, Azure Resource Manager mengambil—dan karena itu memerlukan akses langsung ke—templat yang ditautkan. Praktik umum adalah menggunakan GitHub untuk menyimpan templat berlapis. Repositori GitHub dapat berisi file yang dapat diakses secara publik melalui URL. Meskipun teknik ini berfungsi dengan baik untuk cloud publik dan sovereign cloud, lingkungan Azure Stack mungkin terletak di jaringan perusahaan atau di lokasi jarak jauh yang terputus, tanpa akses Internet outbound. Dalam kasus tersebut, Azure Resource Manager akan gagal mengambil templat berlapis.

Praktik yang lebih baik untuk penyebaran lintas cloud adalah menyimpan templat tertaut Anda di lokasi yang dapat diakses oleh cloud target. Idealnya, semua artefak penyebaran dipertahankan dan disebarkan dari alur integrasi berkelanjutan/pengembangan berkelanjutan (CI/CD). Atau, Anda dapat menyimpan templat berlapis dalam kontainer penyimpanan blob, tempat Azure Resource Manager bisa mengambilnya.

Karena penyimpanan blob di setiap cloud menggunakan nama domain yang sepenuhnya memenuhi syarat titik akhir (FQDN) yang berbeda, konfigurasikan templat dengan lokasi templat yang ditautkan dengan dua parameter. Parameter dapat menerima input pengguna pada waktu penyebaran. Templat biasanya ditulis dan dibagikan oleh beberapa orang, jadi praktik terbaiknya adalah menggunakan nama standar untuk parameter ini. Konvensi penamaan membantu membuat templat lebih dapat digunakan kembali di seluruh wilayah, cloud, dan pembuat.

Dalam kode berikut, _artifactsLocation digunakan untuk menunjuk ke satu lokasi, berisi semua artefak terkait penyebaran. Perhatikan bahwa nilai default disediakan. Pada waktu penyebaran, jika tidak ada nilai input yang ditentukan untuk _artifactsLocation, nilai default digunakan. _artifactsLocationSasToken digunakan sebagai input untuk sasToken. Nilai default harus merupakan string kosong untuk skenario di mana _artifactsLocation tidak diamankan — misalnya, repositori GitHub publik.

"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": ""
  }
}

Di seluruh templat, tautan dihasilkan dengan menggabungkan URI dasar (dari parameter _artifactsLocation) dengan jalur artefak-relatif dan _artifactsLocationSasToken. Kode berikut menunjukkan cara menentukan tautan ke templat berlapis menggunakan fungsi templat uri:

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

Dengan menggunakan pendekatan ini, nilai default untuk parameter _artifactsLocation digunakan. Jika templat yang ditautkan perlu diambil dari lokasi yang berbeda, input parameter dapat digunakan pada waktu penyebaran untuk mengambil alih nilai default—tidak diperlukan perubahan pada templat itu sendiri.

Gunakan _artifactsLocation bukan tautan yang di-hardcode

Selain digunakan untuk templat berlapis, URL dalam parameter _artifactsLocation digunakan sebagai dasar untuk semua artefak terkait dari templat penyebaran. Beberapa ekstensi komputer virtual menyertakan tautan ke skrip yang disimpan di luar templat. Untuk ekstensi ini, Anda tidak boleh melakukan hardcode tautan. Misalnya, ekstensi DSC Skrip Kustom dan PowerShell dapat ditautkan ke skrip eksternal di GitHub seperti yang ditunjukkan:

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

Melakukan hardcode tautan ke skrip berpotensi mencegah templat berhasil disebarkan ke lokasi lain. Selama konfigurasi sumber daya komputer virtual, agen komputer virtual yang berjalan di dalam komputer virtual memulai pengunduhan semua skrip yang ditautkan dalam ekstensi komputer virtual, dan kemudian menyimpan skrip pada disk lokal komputer virtual. Pendekatan ini berfungsi seperti tautan templat berlapis yang dijelaskan sebelumnya di bagian "Menggunakan templat berlapis di seluruh wilayah".

Resource Manager mengambil templat berlapis saat runtime. Untuk ekstensi komputer virtual, pengambilan artefak eksternal apa pun dilakukan oleh agen komputer virtual. Selain inisiator pengambilan artefak yang berbeda, solusi dalam penentuan templat adalah sama. Gunakan parameter _artifactsLocation dengan nilai default jalur dasar di mana semua artefak disimpan (termasuk skrip ekstensi komputer virtual) dan parameter _artifactsLocationSasToken untuk input untuk sasToken.

"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": ""
  }
}

Untuk membangun URI absolut artefak, metode yang disukai adalah menggunakan fungsi templat uri, bukan fungsi templat concat. Dengan mengganti tautan yang di-hardcode ke skrip di ekstensi komputer virtual dengan fungsi templat uri, fungsi ini dalam templat dikonfigurasi untuk konsistensi cloud.

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

Dengan pendekatan ini, semua artefak penyebaran, termasuk skrip konfigurasi, dapat disimpan di lokasi yang sama dengan templat itu sendiri. Untuk mengubah lokasi semua tautan, Anda hanya perlu menentukan URL dasar yang berbeda untuk parameter artefakLokasi.

Faktor dalam kemampuan regional yang berbeda

Dengan pengembangan tangkas dan alur pembaruan berkelanjutan dan layanan baru yang diperkenalkan ke Azure, wilayah dapat berbeda dalam ketersediaan layanan atau pembaruan. Setelah pengujian internal yang ketat, layanan baru atau pembaruan untuk layanan yang ada biasanya diperkenalkan kepada audiens kecil pelanggan yang berpartisipasi dalam program validasi. Setelah validasi pelanggan berhasil, layanan atau pembaruan akan tersedia dalam subset wilayah Azure, kemudian diperkenalkan ke lebih banyak wilayah, diluncurkan ke sovereign cloud, dan berpotensi tersedia untuk pelanggan Azure Stack juga.

Karena wilayah Azure dan cloud mungkin berbeda dalam layanan yang tersedia, Anda dapat membuat beberapa keputusan proaktif tentang templat Anda. Tempat yang baik untuk memulai adalah dengan memeriksa penyedia sumber yang tersedia untuk cloud. Penyedia sumber memberi tahu Anda set sumber daya dan operasi yang tersedia untuk layanan Azure.

Templat menyebarkan dan mengonfigurasi sumber daya. Jenis sumber daya disediakan oleh penyedia sumber. Misalnya, penyedia sumber komputasi (Microsoft.Compute), menyediakan beberapa jenis sumber daya seperti virtualMachines dan availabilitySets. Setiap penyedia sumber menyediakan API ke Azure Resource Manager yang ditentukan oleh kontrak umum, memungkinkan pengalaman penulisan terpadu yang konsisten di semua penyedia sumber. Namun, penyedia sumber yang tersedia di Azure global mungkin tidak tersedia di sovereign cloud atau wilayah Azure Stack.

Diagram yang mengilustrasikan hubungan antara penyedia sumber daya, jenis sumber daya, dan versi API.

Untuk memverifikasi penyedia sumber yang tersedia di cloud tertentu, jalankan skrip berikut di Azure CLI:

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

Anda juga bisa menggunakan cmdlet PowerShell berikut ini untuk melihat penyedia sumber yang tersedia:

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

Memverifikasi versi semua jenis sumber daya

Set properti umum untuk semua jenis sumber daya, tetapi setiap sumber daya juga memiliki sifat spesifiknya sendiri. Fitur baru dan properti terkait ditambahkan ke jenis sumber daya yang ada sekaligus melalui versi API baru. Sumber daya dalam templat memiliki properti versi API-nya sendiri - apiVersion. Penerapan versi ini memastikan bahwa konfigurasi sumber daya yang ada dalam templat tidak dipengaruhi oleh perubahan pada platform.

Versi API baru yang diperkenalkan ke jenis sumber daya yang ada di Azure global mungkin tidak segera tersedia di semua wilayah, sovereign cloud, atau Azure Stack. Untuk melihat daftar penyedia sumber, jenis sumber daya, dan versi API yang tersedia untuk cloud, Anda dapat menggunakan Resource Explorer di portal Microsoft Azure. Cari Resource Explorer di menu Semua Layanan. Perluas node Penyedia di Resource Explorer untuk mengembalikan semua penyedia sumber yang tersedia, jenis sumber daya mereka, dan versi API di cloud tersebut.

Untuk mencantumkan versi API yang tersedia untuk semua jenis sumber daya di cloud tertentu di Azure CLI, jalankan skrip berikut:

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

Anda juga bisa menggunakan cmdlet PowerShell berikut ini:

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

Merujuk ke lokasi sumber daya dengan parameter

Templat selalu disebarkan ke dalam grup sumber daya yang berada di suatu wilayah. Selain penyebaran itu sendiri, setiap sumber daya dalam templat juga memiliki properti lokasi yang Anda gunakan untuk menentukan wilayah yang akan disebarkan. Untuk mengembangkan templat Anda untuk konsistensi cloud, Anda memerlukan cara dinamis untuk merujuk ke lokasi sumber daya, karena setiap Azure Stack dapat berisi nama lokasi yang unik. Biasanya sumber daya disebarkan di wilayah yang sama dengan grup sumber daya, tetapi untuk mendukung skenario seperti ketersediaan aplikasi lintas wilayah, sebaiknya menyebarkan sumber daya di seluruh wilayah.

Meskipun Anda dapat melakukan hardcode nama wilayah saat menentukan properti sumber daya dalam templat, pendekatan ini tidak menjamin bahwa templat dapat disebarkan ke lingkungan Azure Stack lainnya, karena nama wilayah kemungkinan besar tidak ada di sana.

Untuk mengakomodasi berbagai wilayah, tambahkan lokasi parameter input ke templat dengan nilai default. Nilai default akan digunakan jika tidak ada nilai yang ditentukan selama penyebaran.

Fungsi templat [resourceGroup()] mengembalikan objek yang berisi pasangan kunci/nilai berikut:

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

Dengan merujuk kunci lokasi objek dalam defaultValue parameter input, Azure Resource Manager akan, saat runtime, mengganti fungsi templat [resourceGroup().location] dengan nama lokasi grup sumber daya tempat templat disebarkan.

"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')]",
    ...

Dengan fungsi templat ini, Anda dapat menyebarkan templat Anda ke cloud apa pun tanpa mengetahui nama wilayah sebelumnya. Selain itu, lokasi untuk sumber daya tertentu dalam templat dapat berbeda dari lokasi grup sumber daya. Dalam hal ini, Anda dapat mengonfigurasinya dengan menggunakan parameter input tambahan untuk sumber daya tertentu, sementara sumber daya lain dalam templat yang sama masih menggunakan parameter input lokasi awal.

Melacak versi menggunakan profil API

Ini bisa sangat menantang untuk melacak semua penyedia sumber yang tersedia dan versi API terkait yang ada di Azure Stack. Misalnya, pada saat penulisan, versi API terbaru untuk Microsoft.Compute/availabilitySets di Azure adalah 2018-04-01, sedangkan versi API yang tersedia umum untuk Azure dan Azure Stack adalah 2016-03-30. Versi API umum untuk Microsoft.Storage/storageAccounts dibagikan di antara semua lokasi Azure dan Azure Stack adalah 2016-01-01, sedangkan versi API terbaru di Azure adalah 2018-02-01.

Untuk alasan ini, Resource Manager memperkenalkan konsep profil API ke templat. Tanpa profil API, setiap sumber daya dalam templat dikonfigurasi dengan elemen apiVersion yang menjelaskan versi API untuk sumber daya tertentu tersebut.

{
  "$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": {}
}

Versi profil API bertindak sebagai alias untuk satu versi API per jenis sumber daya yang umum untuk Azure dan Azure Stack. Sebagai ganti menentukan versi API untuk setiap sumber daya dalam templat, Anda hanya menentukan versi profil API dalam elemen akar baru yang disebut apiProfile dan menghilangkan elemen apiVersion untuk sumber daya individual.

{
    "$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": {}
}

Profil API memastikan bahwa versi API tersedia di seluruh lokasi, sehingga Anda tidak perlu memverifikasi apiVersions yang tersedia secara manual di lokasi tertentu. Untuk memastikan versi API yang dirujuk oleh profil API Anda ada di lingkungan Azure Stack, operator Azure Stack harus selalu menyiapkan solusi berdasarkan kebijakan untuk dukungan. Jika sistem lebih dari enam bulan kedaluwarsa, sistem dianggap tidak patuh, dan lingkungan harus diperbarui.

Profil API bukanlah elemen yang diperlukan dalam templat. Bahkan jika Anda menambahkan elemen, itu hanya akan digunakan untuk sumber daya yang apiVersion tidak ditentukan. Elemen ini memungkinkan perubahan bertahap tetapi tidak memerlukan perubahan apa pun pada templat yang ada.

{
    "$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": {}
}

Memeriksa referensi titik akhir

Sumber daya dapat memiliki referensi ke layanan lain di platform. Misalnya, IP publik dapat memiliki nama DNS publik yang ditetapkan untuknya. Cloud publik, sovereign cloud, dan solusi Azure Stack memiliki namespace titik akhir yang berbeda. Dalam kebanyakan kasus, sumber daya hanya memerlukan awalan sebagai input dalam templat. Selama runtime, Azure Resource Manager menambahkan nilai titik akhir ke runtime tersebut. Beberapa nilai titik akhir perlu ditentukan secara eksplisit dalam templat.

Catatan

Untuk mengembangkan templat untuk konsistensi cloud, jangan melakukan hardcode namespace titik akhir.

Dua contoh berikut adalah namespace titik akhir umum yang perlu ditentukan secara eksplisit saat membuat sumber daya:

  • Akun penyimpanan (blob, antrean, tabel, dan file)
  • String koneksi untuk database dan Azure Cache for Redis

Namespace titik akhir juga dapat digunakan dalam output templat sebagai informasi untuk pengguna saat penyebaran selesai. Berikut ini adalah contoh umum:

  • Akun penyimpanan (blob, antrean, tabel, dan file)
  • String koneksi (MySql, SQLServer, SQLAzure, Custom, NotificationHub, ServiceBus, EventHub, ApiHub, DocDb, RedisCache, PostgreSQL)
  • Traffic Manager
  • domainNameLabel dari alamat IP publik
  • Layanan cloud

Secara umum, hindari titik akhir yang di-hardcode dalam templat. Praktik terbaik adalah menggunakan fungsi templat referensi untuk mengambil titik akhir secara dinamis. Misalnya, titik akhir yang paling sering di-hardcode adalah namespace titik akhir untuk akun penyimpanan. Setiap akun penyimpanan memiliki FQDN unik yang dibangun dengan menggabungkan nama akun penyimpanan dengan namespace titik akhir. Akun penyimpanan blob bernama mystorageaccount1 menghasilkan FQDN yang berbeda tergantung cloud:

  • mystorageaccount1.blob.core.windows.net saat dibuat di cloud Azure global.
  • mystorageaccount1.blob.core.chinacloudapi.cn saat dibuat di Azure yang dioperasikan oleh cloud 21Vianet.

Fungsi templat referensi berikut ini mengambil namespace titik akhir dari penyedia sumber penyimpanan:

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

Dengan mengganti nilai yang di-hardcode dari titik akhir akun penyimpanan dengan fungsi templat reference, Anda dapat menggunakan templat yang sama untuk disebarkan ke lingkungan yang berbeda dengan sukses tanpa membuat perubahan pada referensi titik akhir.

Lihat sumber daya yang ada dengan ID unik

Anda juga bisa merujuk ke sumber daya yang ada dari grup sumber daya yang sama atau lainnya, dan dalam langganan yang sama atau langganan lain, dalam penyewa yang sama di cloud yang sama. Untuk mengambil properti sumber daya, Anda harus menggunakan pengidentifikasi unik untuk sumber daya itu sendiri. Fungsi templat resourceId mengambil ID unik sumber daya seperti SQL Server seperti yang ditunjukkan oleh kode berikut ini:

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

Anda kemudian dapat menggunakan fungsi resourceId di dalam fungsi templat reference untuk mengambil properti database. Objek yang dikembalikan berisi properti fullyQualifiedDomainName yang menyimpan nilai titik akhir penuh. Nilai ini diambil saat runtime dan menyediakan namespace titik akhir khusus lingkungan cloud. Untuk menentukan string koneksi tanpa melakukan hardcode namespace titik akhir, Anda dapat merujuk ke properti objek yang dikembalikan secara langsung dalam string koneksi seperti yang ditunjukkan:

"[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;')]"

Mempertimbangkan properti sumber daya

Sumber daya tertentu dalam lingkungan Azure Stack memiliki properti unik yang harus Anda pertimbangkan di templat Anda.

Memastikan citra komputer virtual tersedia

Azure menyediakan banyak pilihan citra komputer virtual. Citra-citra ini dibuat dan disiapkan untuk penyebaran oleh Microsoft dan mitranya. Citra membentuk fondasi untuk komputer virtual pada platform. Namun, templat yang konsisten dengan cloud harus mengacu pada parameter yang tersedia saja — khususnya, penerbit, penawaran, dan SKU citra komputer virtual yang tersedia untuk Azure global, sovereign cloud Azure, atau solusi Azure Stack.

Untuk mengambil daftar citra komputer virtual yang tersedia di lokasi, jalankan perintah Azure CLI berikut ini:

az vm image list -all

Anda dapat mengambil daftar yang sama dengan cmdlet Azure PowerShell Get-AzureRmVMImagePublisher dan menentukan lokasi yang Anda inginkan dengan parameter -Location. Contohnya:

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

Perintah ini membutuhkan waktu beberapa menit untuk mengembalikan semua citra yang tersedia di wilayah Eropa Barat dari cloud Azure global.

Jika Anda membuat citra komputer virtual ini tersedia untuk Azure Stack, semua penyimpanan yang tersedia akan digunakan. Untuk mengakomodasi bahkan pelajaran skala terkecil, Azure Stack memungkinkan Anda memilih citra yang ingin Anda tambahkan ke lingkungan.

Contoh kode berikut menunjukkan pendekatan yang konsisten untuk merujuk ke parameter penerbit, penawaran, dan SKU di templat ARM Anda:

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

Memeriksa ukuran komputer virtual lokal

Untuk mengembangkan templat untuk konsistensi cloud, Anda perlu memastikan ukuran komputer virtual yang Anda inginkan tersedia di semua lingkungan target. Ukuran komputer virtual adalah pengelompokan karakteristik dan kemampuan performa. Beberapa ukuran komputer virtual bergantung pada perangkat keras yang dijalankan komputer virtual. Misalnya, jika Anda ingin menyebarkan komputer virtual yang dioptimalkan GPU, perangkat keras yang menjalankan hypervisor harus memiliki GPU perangkat keras.

Ketika Microsoft memperkenalkan ukuran baru komputer virtual yang memiliki dependensi perangkat keras tertentu, ukuran komputer virtual biasanya tersedia terlebih dahulu dalam subset kecil wilayah di cloud Azure. Kemudian, tersedia untuk wilayah dan cloud lain. Untuk memastikan ukuran komputer virtual ada di setiap cloud yang Anda sebarkan, Anda dapat mengambil ukuran yang tersedia dengan perintah Cli Azure berikut:

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

Untuk Azure PowerShell, gunakan:

Get-AzureRmVMSize -Location "West Europe"

Untuk daftar lengkap layanan yang tersedia, lihat Produk yang tersedia menurut wilayah.

Memeriksa penggunaan Azure Managed Disks di Azure Stack

Disk terkelola menangani penyimpanan untuk penyewa Azure. Daripada secara eksplisit membuat akun penyimpanan dan menentukan URI untuk hard disk virtual (VHD), Anda dapat menggunakan disk terkelola untuk secara implisit melakukan tindakan ini saat Anda menyebarkan komputer virtual. Disk terkelola meningkatkan ketersediaan dengan menempatkan semua disk dari komputer virtual dalam ketersediaan yang sama diatur ke pelajaran penyimpanan yang berbeda. Selain itu, VHD yang ada dapat dikonversi dari penyimpanan Standar ke Premium dengan waktu henti yang jauh lebih sedikit.

Meskipun disk terkelola berada di peta strategi untuk Azure Stack, disk tersebut saat ini tidak didukung. Hingga akhirnya, Anda dapat mengembangkan templat yang konsisten dengan cloud untuk Azure Stack dengan secara eksplisit menentukan VHD menggunakan elemen vhd dalam templat untuk sumber daya komputer virtual seperti yang ditunjukkan:

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

Sebaliknya, untuk menentukan konfigurasi disk terkelola dalam templat, hapus elemen vhd dari konfigurasi disk.

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

Perubahan yang sama juga berlaku untuk disk data.

Memverifikasi ekstensi komputer virtual tersedia di Azure Stack

Pertimbangan lain untuk konsistensi cloud adalah penggunaan ekstensi komputer virtual untuk mengonfigurasi sumber daya di dalam komputer virtual. Tidak semua ekstensi komputer virtual tersedia di Azure Stack. Templat dapat menentukan sumber daya yang didedikasikan untuk ekstensi komputer virtual, membuat dependensi dan kondisi dalam templat.

Misalnya, jika Anda ingin mengonfigurasi komputer virtual yang menjalankan Microsoft SQL Server, ekstensi komputer virtual dapat mengonfigurasi SQL Server sebagai bagian dari penyebaran templat. Pertimbangkan apa yang terjadi jika templat penyebaran juga berisi server aplikasi yang dikonfigurasi untuk membuat database di komputer virtual yang menjalankan SQL Server. Selain juga menggunakan ekstensi komputer virtual untuk server aplikasi, Anda dapat mengonfigurasi dependensi server aplikasi pada keberhasilan pengembalian sumber daya ekstensi komputer virtual SQL Server. Pendekatan ini memastikan komputer virtual yang menjalankan SQL Server dikonfigurasi dan tersedia ketika server aplikasi diinstruksikan untuk membuat database.

Pendekatan deklaratif templat memungkinkan Anda untuk menentukan status akhir sumber daya dan antar-dependensinya, sementara platform menangani logika yang diperlukan untuk dependensi tersebut.

Memeriksa apakah ekstensi komputer virtual tersedia

Ada banyak jenis ekstensi komputer virtual. Saat mengembangkan templat untuk konsistensi cloud, pastikan untuk hanya menggunakan ekstensi yang tersedia di semua wilayah target templat.

Untuk mengambil daftar ekstensi komputer virtual yang tersedia untuk wilayah tertentu (dalam contoh ini, myLocation), jalankan perintah Azure CLI berikut ini:

az vm extension image list --location myLocation

Anda juga dapat menjalankan cmdlet Azure PowerShell Get-AzureRmVmImagePublisher dan menggunakan -Location untuk menentukan lokasi citra komputer virtual. Contohnya:

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

Memastikan bahwa versi tersedia

Karena ekstensi komputer virtual adalah sumber daya Resource Manager pihak pertama, ekstensi tersebut memiliki versi API-nya sendiri. Seperti yang ditunjukkan oleh kode berikut, jenis ekstensi komputer virtual adalah sumber daya berlapis di penyedia sumber Microsoft.Compute.

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

Versi API dari sumber daya ekstensi komputer virtual harus ada di semua lokasi yang Anda rencanakan untuk ditargetkan dengan templat Anda. Dependensi lokasi berfungsi seperti ketersediaan versi API penyedia sumber yang dibahas sebelumnya di bagian "Memverifikasi versi semua jenis sumber daya".

Untuk mengambil daftar versi API yang tersedia untuk sumber daya ekstensi komputer virtual, gunakan cmdlet Get-AzureRmResourceProvider dengan penyedia sumber Microsoft.Compute seperti yang ditunjukkan:

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

Anda juga dapat menggunakan ekstensi komputer virtual dalam set skala komputer virtual. Kondisi lokasi yang sama berlaku. Untuk mengembangkan templat Anda untuk konsistensi cloud, pastikan versi API tersedia di semua lokasi yang Anda rencanakan untuk disebarkan. Untuk mengambil versi API dari sumber daya ekstensi komputer virtual untuk set skala, gunakan cmdlet yang sama seperti sebelumnya, tetapi tentukan jenis sumber daya set skala komputer virtual seperti yang ditunjukkan:

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

Setiap ekstensi tertentu juga diterapkan versinya. Versi ini ditampilkan di properti typeHandlerVersion ekstensi komputer virtual. Pastikan bahwa versi yang ditentukan dalam elemen typeHandlerVersion ekstensi komputer virtual templat Anda tersedia di lokasi tempat Anda berencana untuk menyebarkan templat. Misalnya, kode berikut menentukan versi 1.7:

{
    "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",
        ...

Untuk mengambil daftar versi yang tersedia untuk ekstensi komputer virtual tertentu, gunakan cmdlet Get-AzureRmVMExtensionImage. Contoh berikut mengambil versi yang tersedia untuk ekstensi komputer virtual PowerShell DSC (Desired State Configuration) dari myLocation:

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

Untuk mendapatkan daftar penerbit, gunakan perintah Get-AzureRmVmImagePublisher. Untuk meminta jenis, gunakan perintah Get-AzureRmVMExtensionImageType.

Tips untuk pengujian dan otomatisasi

Ini adalah tantangan untuk melacak semua pengaturan, kemampuan, dan batasan terkait saat penulisan templat. Pendekatan umum adalah mengembangkan dan menguji templat terhadap satu cloud sebelum lokasi lain ditargetkan. Namun, semakin awal pengujian dilakukan dalam proses penulisan, semakin sedikit pemecahan masalah dan penulisan ulang kode yang harus dilakukan tim pengembangan Anda. Penyebaran yang gagal karena ketergantungan lokasi dapat memakan waktu lama untuk memecahkan masalah. Itu sebabnya kami merekomendasikan pengujian otomatis sedini mungkin dalam siklus penulisan. Pada akhirnya, Anda akan membutuhkan lebih sedikit waktu pengembangan dan lebih sedikit sumber daya, dan artefak yang konsisten dengan cloud Anda akan menjadi lebih berharga.

Citra berikut menunjukkan contoh umum proses pengembangan untuk tim yang menggunakan lingkungan pengembangan terintegrasi (IDE). Pada tahap yang berbeda di garis waktu, berbagai jenis pengujian dijalankan. Di sini, dua pengembang sedang mengerjakan solusi yang sama, tetapi skenario ini berlaku sama untuk satu pengembang atau tim besar. Setiap pengembang biasanya membuat salinan lokal repositori pusat, memungkinkan masing-masing pengembang bekerja pada salinan lokal tanpa berdampak pada orang lain yang mungkin bekerja pada file yang sama.

Diagram yang menunjukkan pengujian unit paralel dan pengujian integrasi di ID lokal, menggabungkan alur pengembangan CI/CD dengan pengujian unit, pengujian integrasi, penyebaran pengujian, dan penyebaran akhir.

Pertimbangkan tips berikut untuk pengujian dan otomatisasi:

  • Manfaatkan alat pengujian. Misalnya, Visual Studio Code dan Visual Studio menyertakan IntelliSense dan fitur lain yang dapat membantu Anda memvalidasi templat Anda.
  • Untuk meningkatkan kualitas kode selama pengembangan pada IDE lokal, lakukan analisis kode statis dengan pengujian pelajaran dan pengujian integrasi.
  • Untuk pengalaman yang lebih baik selama pengembangan awal, pengujian pelajaran dan pengujian integrasi hanya boleh memperingatkan ketika masalah ditemukan dan melanjutkan tes. Dengan demikian, Anda dapat mengidentifikasi masalah untuk mengatasi dan memprioritaskan urutan perubahan, yang juga disebut sebagai penyebaran berbasis pengujian (TDD).
  • Ketahuilah bahwa beberapa pengujian dapat dilakukan tanpa tersambung ke Azure Resource Manager. Tindakan lainnya, seperti menguji penyebaran templat, memerlukan Resource Manager untuk melakukan tindakan tertentu yang tidak dapat dilakukan secara offline.
  • Menguji templat penyebaran terhadap API validasi tidak sama dengan penyebaran aktual. Selain itu, bahkan jika Anda menyebarkan templat dari file lokal, referensi apa pun ke templat berlapis dalam templat diambil oleh Resource Manager secara langsung, dan artefak yang dirujuk oleh ekstensi komputer virtual diambil oleh agen komputer virtual yang berjalan di dalam komputer virtual yang disebarkan.

Langkah berikutnya