Bagikan melalui

Cara Membuat ILB ASEv1 Menggunakan Templat Azure Resource Manager

  • Artikel

Penting

Artikel ini tentang Lingkungan App Service v1. Lingkungan App Service v1 dan v2 dihentikan per 31 Agustus 2024. Terdapat versi baru Lingkungan App Service yang lebih mudah digunakan dan berjalan di infrastruktur yang lebih kuat. Untuk mempelajari selengkapnya tentang versi baru, mulai dengan Pengantar Lingkungan App Service. Jika saat ini Anda menggunakan Lingkungan App Service v1, ikuti langkah-langkah dalam artikel ini untuk bermigrasi ke versi baru.

Pada 31 Agustus 2024, Perjanjian Tingkat Layanan (SLA) dan Kredit Layanan tidak lagi berlaku untuk beban kerja App Service Environment v1 dan v2 yang terus diproduksi karena mereka adalah produk yang dihentikan. Penonaktifan perangkat keras App Service Environment v1 dan v2 telah dimulai, dan ini dapat memengaruhi ketersediaan dan performa aplikasi dan data Anda.

Anda harus segera menyelesaikan migrasi ke App Service Environment v3 atau aplikasi dan sumber daya Anda dapat dihapus. Kami akan mencoba memigrasikan secara otomatis Lingkungan App Service v1 dan v2 yang tersisa berdasarkan upaya terbaik menggunakan fitur migrasi di tempat, tetapi Microsoft tidak membuat klaim atau jaminan tentang ketersediaan aplikasi setelah migrasi otomatis. Anda mungkin perlu melakukan konfigurasi manual untuk menyelesaikan migrasi dan mengoptimalkan pilihan SKU paket App Service Anda untuk memenuhi kebutuhan Anda. Jika migrasi otomatis tidak memungkinkan, sumber daya dan data aplikasi terkait Anda akan dihapus. Kami sangat mendorong Anda untuk bertindak sekarang untuk menghindari salah satu skenario ekstrem ini.

Jika Anda memerlukan waktu tambahan, kami dapat menawarkan masa tenggang 30 hari sekali bagi Anda untuk menyelesaikan migrasi Anda. Untuk informasi selengkapnya dan untuk meminta masa tenggang ini, tinjau gambaran umum masa tenggang, lalu buka portal Azure dan kunjungi bilah Migrasi untuk setiap Lingkungan App Service Anda.

Untuk informasi terbaru tentang penghentian App Service Environment v1/v2, lihat pembaruan penghentian App Service Environment v1 dan v2.

Gambaran Umum

App Service Environment dapat dibuat dengan alamat internal jaringan virtual daripada VIP publik. Alamat internal ini disediakan oleh komponen Azure yang disebut load balancer internal (ILB). ILB ASE dapat dibuat menggunakan portal Azure. Itu juga dapat dibuat menggunakan automasi melalui templat Azure Resource Manager. Artikel ini membahas langkah-langkah dan sintaks yang diperlukan untuk membuat ILB ASE dengan templat Azure Resource Manager.

Ada tiga langkah yang terlibat dalam mengautomasi pembuatan ILB ASE:

  1. Pertama, ASE dasar dibuat dalam jaringan virtual menggunakan alamat load balancer internal daripada VIP publik. Sebagai bagian dari langkah ini, nama domain akar ditetapkan ke ILB ASE.
  2. Setelah ILB ASE dibuat, sertifikat TLS/SSL diunggah.
  3. Sertifikat TLS/SSL yang diunggah secara eksplisit ditetapkan ke ILB ASE sebagai sertifikat TLS/SSL "default". Sertifikat TLS/SSL ini akan digunakan untuk lalu lintas TLS ke aplikasi di ILB ASE saat aplikasi ditangani menggunakan domain root umum yang ditetapkan untuk ASE (mis. https://someapp.mycustomrootcomain.com)

Membuat ILB ASE Dasar

Contoh templat Azure Resource Manager, dan file parameter terkaitnya, tersedia di sini.

Sebagian besar parameter dalam file azuredeploy.parameters.json umum digunakan untuk membuat ILB ASE, serta ASE yang dikaitkan ke VIP publik. Daftar di bawah ini memanggil parameter catatan khusus, atau yang unik, saat membuat ILB ASE:

  • internalLoadBalancingMode: Menentukan bagaimana kontrol dan port data diekspos.
    • 3 berarti lalu lintas HTTP/HTTPS di port 80/443, dan port saluran kontrol/data yang didengarkan ke layanan FTP di ASE, akan dikaitkan dengan alamat internal jaringan virtual alokasi ILB.
    • 2 berarti hanya port terkait layanan FTP (saluran kontrol dan data) yang akan dikaitkan dengan alamat ILB, sedangkan lalu lintas HTTP/HTTPS akan tetap berada di VIP publik.
    • 0 berarti semua lalu lintas dikaitkan dengan ke VIP publik yang membuat ASE eksternal.
  • dnsSuffix: Parameter ini menentukan domain root default yang akan ditetapkan ke ASE. Dalam variasi publik Azure App Service, domain akar default untuk semua aplikasi web adalah azurewebsites.net. Namun karena ASE ILB bersifat internal untuk jaringan virtual pelanggan, tidak masuk akal untuk menggunakan domain akar default layanan publik. Sebaliknya, ASE ILB harus memiliki domain akar default yang masuk akal untuk digunakan dalam jaringan virtual internal perusahaan. Misalnya, Contoso Corporation hipotetis mungkin menggunakan domain akar default internal.contoso.com untuk aplikasi yang dimaksudkan untuk hanya dapat diselesaikan dan dapat diakses dalam jaringan virtual Contoso.
  • ipSslAddressCount: Parameter ini secara otomatis ditetapkan ke nilai 0 dalam file azuredeploy.json karena ILB ASE hanya memiliki satu alamat ILB. Tidak ada alamat IP-SSL yang eksplisit untuk ILB ASE. Oleh karena itu, kumpulan alamat IP-SSL untuk ILB ASE harus diatur ke nol, jika tidak, kesalahan provisi akan terjadi.

Setelah file azuredeploy.parameters.json diisi untuk ILB ASE, ILB ASE kemudian dapat dibuat menggunakan cuplikan kode PowerShell berikut. Ubah jalur file agar sesuai dengan tempat file templat Azure Resource Manager berada di mesin Anda. Ingatlah juga untuk memberikan nilai Anda sendiri untuk nama penyebaran Azure Resource Manager, dan nama grup sumber daya.

$templatePath="PATH\azuredeploy.json"
$parameterPath="PATH\azuredeploy.parameters.json"

New-AzResourceGroupDeployment -Name "CHANGEME" -ResourceGroupName "YOUR-RG-NAME-HERE" -TemplateFile $templatePath -TemplateParameterFile $parameterPath

Setelah templat Azure Resource Manager dikirimkan, dibutuhkan waktu beberapa jam untuk membuat ILB ASE. Setelah pembuatan selesai, ILB ASE akan muncul di UX portal dalam daftar Lingkungan Layanan Aplikasi untuk langganan yang memicu penyebaran.

Mengunggah dan Mengonfigurasi Sertifikat TLS/SSL "Default"

Setelah ILB ASE dibuat, sertifikat TLS/SSL harus dikaitkan dengan ASE sebagai penggunaan sertifikat TLS/SSL "default" untuk membuat koneksi TLS/SSL ke aplikasi. Melanjutkan dengan contoh Contoso Corporation hipotetis, jika akhiran DNS default ASE internal.contoso.com, maka koneksi untuk https://some-random-app.internal.contoso.com memerlukan sertifikat TLS/SSL yang valid untuk *.internal.contoso.com.

Ada berbagai cara untuk mendapatkan sertifikat TLS/SSL yang valid termasuk CA internal, membeli sertifikat dari penerbit eksternal, dan menggunakan sertifikat yang ditandatangani sendiri. Terlepas dari sumber sertifikat TLS/SSL, atribut sertifikat berikut perlu dikonfigurasi dengan benar:

  • Subjek: Atribut ini harus diatur ke *.your-root-domain-here.com
  • Nama Alternatif Subjek: Atribut ini harus menyertakan .your-root-domain-here.com, dan*.scm.your-root-domain-here.com*. Alasan untuk entri kedua adalah bahwa koneksi TLS ke situs SCM/Kudu yang terkait dengan setiap aplikasi akan dibuat menggunakan alamat formulir your-app-name.scm.your-root-domain-here.com.

Dengan sertifikat TLS/SSL yang valid, dua langkah persiapan tambahan diperlukan. Sertifikat TLS/SSL perlu dikonversi/disimpan sebagai file .pfx. Ingatlah bahwa file .pfx harus menyertakan semua sertifikat akar dan perantara, dan juga harus diamankan dengan kata sandi.

Kemudian file .pfx yang dihasilkan perlu diubah menjadi string base64 karena sertifikat TLS/SSL akan diunggah menggunakan templat Azure Resource Manager. Karena templat Azure Resource Manager adalah file teks, file .pfx perlu diubah menjadi string base64 sehingga dapat disertakan sebagai parameter templat.

Cuplikan kode PowerShell di bawah ini menunjukkan contoh pembuatan sertifikat yang ditandatangani sendiri, mengekspor sertifikat sebagai file .pfx, mengonversi file .pfx menjadi string yang dikodekan base64, lalu menyimpan string yang dikodekan base64 ke file terpisah. Kode PowerShell untuk pengodean base64 diadaptasi dari Blog Skrip PowerShell.

$certificate = New-SelfSignedCertificate -certstorelocation cert:\localmachine\my -dnsname "*.internal.contoso.com","*.scm.internal.contoso.com"

$certThumbprint = "cert:\localMachine\my\" + $certificate.Thumbprint
$password = ConvertTo-SecureString -String "CHANGETHISPASSWORD" -Force -AsPlainText

$fileName = "exportedcert.pfx"
Export-PfxCertificate -cert $certThumbprint -FilePath $fileName -Password $password     

$fileContentBytes = get-content -encoding byte $fileName
$fileContentEncoded = [System.Convert]::ToBase64String($fileContentBytes)
$fileContentEncoded | set-content ($fileName + ".b64")

Setelah sertifikat TLS/SSL berhasil dibuat dan dikonversi ke string berkode base64, contoh templat Azure Resource Manager untuk mengonfigurasi sertifikat TLS/SSL default dapat digunakan.

Parameter dalam file azuredeploy.parameters.json tercantum di bawah ini:

  • appServiceEnvironmentName: Nama ILB ASE sedang dikonfigurasi.
  • existingAseLocation: String teks yang berisi wilayah Azure tempat ILB ASE disebarkan. Misalnya: "US Tengah Selatan".
  • pfxBlobString: Representasi string yang dikodekan based64 dari file .pfx. Dengan menggunakan cuplikan kode yang ditampilkan sebelumnya, Anda akan menyalin string yang terdapat dalam "exportedcert.pfx.b64" dan menempelkannya sebagai nilai atribut pfxBlobString.
  • kata sandi: Sandi yang digunakan untuk mengamankan berkas .pfx.
  • certificateThumbprint: Sidik jari sertifikat. Jika Anda mengambil nilai ini dari PowerShell (misalnya, $certThumbprint dari cuplikan kode sebelumnya), Anda dapat menggunakan nilai apa adanya. Namun jika Anda menyalin nilai dari dialog sertifikat Windows, ingatlah untuk menghapus spasi asing. certificateThumbprint akan terlihat seperti: AF3143EB61D43F6727842115BB7F17BBCECAECAE
  • certificateName: Pengidentifikasi string ramah pilihan Anda sendiri yang digunakan untuk mengidentifikasi sertifikat. Nama tersebut digunakan sebagai bagian dari pengidentifikasi Azure Resource Manager unik untuk entitas Microsoft.Web/certificates yang mewakili sertifikat TLS/SSL. Nama harus diakhiri dengan akhiran berikut: _yourASENameHere_InternalLoadBalancingASE. Akhiran ini digunakan oleh portal sebagai indikator bahwa sertifikat digunakan untuk mengamankan ASE yang mendukung ILB.

Contoh singkatan dari azuredeploy.parameters.json ditampilkan di bawah:

{
    "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentParameters.json",
    "contentVersion": "1.0.0.0",
    "parameters": {
        "appServiceEnvironmentName": {
            "value": "yourASENameHere"
        },
        "existingAseLocation": {
            "value": "East US 2"
        },
        "pfxBlobString": {
            "value": "MIIKcAIBAz...snip...snip...pkCAgfQ"
        },
        "password": {
            "value": "PASSWORDGOESHERE"
        },
        "certificateThumbprint": {
            "value": "AF3143EB61D43F6727842115BB7F17BBCECAECAE"
        },
        "certificateName": {
            "value": "DefaultCertificateFor_yourASENameHere_InternalLoadBalancingASE"
        }
    }
}

Setelah file azuredeploy.parameters.json diisi, sertifikat TLS/SSL default dapat dikonfigurasi menggunakan cuplikan kode PowerShell berikut. Ubah jalur file agar sesuai dengan tempat file templat Azure Resource Manager berada di mesin Anda. Ingatlah juga untuk memberikan nilai Anda sendiri untuk nama penyebaran Azure Resource Manager, dan nama grup sumber daya.

$templatePath="PATH\azuredeploy.json"
$parameterPath="PATH\azuredeploy.parameters.json"

New-AzResourceGroupDeployment -Name "CHANGEME" -ResourceGroupName "YOUR-RG-NAME-HERE" -TemplateFile $templatePath -TemplateParameterFile $parameterPath

Setelah templat Azure Resource Manager dikirimkan, dibutuhkan waktu kira-kira 40 menit per ASE front-end untuk menerapkan perubahan. Misalnya, dengan ASE berukuran default yang menggunakan dua front-end, dibutuhkan waktu kira-kira 1 jam 20 menit untuk menyelesaikan templat. Saat templat sedang berjalan, ASE tidak akan dapat diskalakan.

Setelah templat selesai, aplikasi di ILB ASE dapat diakses melalui HTTPS dan koneksi akan diamankan menggunakan sertifikat TLS/SSL default. Sertifikat TLS/SSL default akan digunakan saat aplikasi di ILB ASE ditangani menggunakan kombinasi nama aplikasi ditambah nama host default. Misalnya, https://mycustomapp.internal.contoso.com akan menggunakan sertifikat TLS/SSL default untuk *.internal.contoso.com.

Namun, seperti aplikasi yang berjalan di layanan multi-penyewa publik, pengembang juga dapat mengonfigurasi nama host khusus untuk masing-masing aplikasi, lalu mengonfigurasi pengikatan sertifikat SNI TLS/SSL unik untuk masing-masing aplikasi.

Memulai

Untuk mulai menggunakan Lingkungan App Service, lihat Pengenalan Lingkungan App Service

Catatan

Jika Anda ingin mulai menggunakan Azure App Service sebelum mendaftar untuk akun Azure, buka Coba Layanan Aplikasi, di mana Anda dapat segera membuat aplikasi web starter berumur pendek di Layanan Aplikasi. Tidak diperlukan kartu kredit; tidak ada komitmen.