Tip

Konten ini adalah kutipan dari eBook, Porting Aplikasi ASP.NET yang ada ke .NET 6, tersedia di .NET Docs atau sebagai PDF yang dapat diunduh gratis yang dapat dibaca secara offline.



Aplikasi ASP.NET MVC dan Web API yang ada berjalan di IIS dan Windows. Aplikasi besar mungkin memerlukan pendekatan bertahap atau berdampingan saat melakukan porting ke ASP.NET Core. Di bab sebelumnya, Anda mempelajari sejumlah strategi untuk memigrasikan aplikasi .NET Framework besar ke ASP.NET Core secara bertahap. Dalam bab ini, Anda akan melihat bagaimana skenario penerapan yang berbeda dapat dicapai ketika ada kebutuhan untuk mempertahankan aplikasi asli dalam produksi sambil memigrasikan sebagiannya.

Pisahkan aplikasi web besar

Pertimbangkan skenario umum aplikasi web besar yang saat ini dihosting di IIS dalam satu situs web. Dalam aplikasi besar, fungsionalitas tersegmentasi ke dalam rute dan/atau direktori yang berbeda. Aplikasi ini merupakan campuran dari tampilan MVC dan titik akhir API. Rute MVC mencakup banyak jalur berbeda berdasarkan fungsionalitas dan semuanya dimulai dari akar aplikasi menggunakan standar /controller/action/id? pola rute. Titik akhir API mengikuti pola yang sama, tetapi semuanya berada di bawah /api akar.

Dengan asumsi tugas porting aplikasi dibagi sedemikian rupa sehingga fungsionalitas MVC atau fungsionalitas API dimigrasikan ke ASP.NET Core terlebih dahulu, bagaimana situs asli akan terus berfungsi dengan mulus dengan aplikasi ASP.NET Core baru yang berjalan di tempat lain? Pengguna sistem harus terus melihat URL yang sama seperti yang mereka lakukan sebelum migrasi, kecuali jika benar-benar diperlukan untuk mengubahnya.

Untungnya, IIS adalah server web yang kaya fitur, dan dua fitur yang dimilikinya adalah modul Penulisan Ulang URL dan Perutean Permintaan Aplikasi. Dengan menggunakan fitur ini, IIS dapat bertindak sebagai proxy terbalik, merutekan permintaan klien ke aplikasi web back-end yang sesuai. Untuk mengonfigurasi IIS sebagai proxy terbalik, periksa: Aktifkan proxy centang kotak di fitur Perutean Permintaan Aplikasi, lalu tambahkan aturan Penulisan Ulang URL seperti ini:

<rule name="NetCoreProxy">
  <match url="(.*)> />
  <action type="Rewrite" url="http://servername/R:1" />
</rule>

Sebagai proxy terbalik, IIS dapat merutekan lalu lintas yang cocok dengan pola tertentu ke aplikasi yang sepenuhnya terpisah, berpotensi di server yang berbeda.

Dengan hanya menggunakan modul Penulisan Ulang URL (mungkin dikombinasikan dengan header host), IIS dapat dengan mudah mendukung beberapa situs web, masing-masing berpotensi menjalankan versi .NET yang berbeda. Aplikasi web besar mungkin digunakan sebagai kumpulan situs individual, masing-masing merespons alamat IP dan/atau header host yang berbeda, atau sebagai situs web tunggal dengan satu atau lebih sub-aplikasi di dalamnya yang merespons jalur URL tertentu (yang tidak bahkan memerlukan Penulisan Ulang URL).

Penting

Subdomain biasanya merujuk ke bagian domain sebelum dua tingkat teratas. Misalnya, di domain api.contoso.com, api adalah subdomain dari contoso.com domain (yang sendiri terdiri dari contoso nama domain dan .com domain tingkat atas atau TLD). Jalur URL merujuk ke bagian URL yang mengikuti nama domain, dimulai dengan a /. URL-nya https://contoso.com/api memiliki jalur /api.

Ada pro dan kontra untuk menggunakan subdomain (dan domain) yang sama atau berbeda untuk meng-host satu aplikasi. Fitur seperti cookie dan komunikasi intra-aplikasi menggunakan mekanisme seperti CORS mungkin memerlukan lebih banyak konfigurasi agar berfungsi dengan baik di aplikasi terdistribusi. Namun, aplikasi yang menggunakan subdomain berbeda dapat lebih mudah menggunakan DNS untuk merutekan permintaan ke tujuan jaringan yang sama sekali berbeda, sehingga dapat lebih mudah diterapkan ke banyak server berbeda (virtual atau lainnya) tanpa perlu IIS bertindak sebagai proxy terbalik.

Dalam contoh yang dijelaskan di atas, asumsikan titik akhir API ditetapkan sebagai bagian pertama dari aplikasi yang akan di-porting ke ASP.NET Core. Dalam hal ini, aplikasi ASP.NET Core baru dibuat dan dihosting di IIS sebagai web terpisah aplikasi dalam web ASP.NET MVC yang ada lokasi. Karena itu akan ditambahkan sebagai anak dari situs web asli dan akan diberi nama apirute defaultnya tidak boleh lagi dimulai dengan api/. Menjaga ini akan menghasilkan URL yang cocok dengan formulir /api/api/endpoint.

Gambar 5-1 menunjukkan bagaimana ASP.NET Core 2.1 api aplikasi muncul di IIS Manager sebagai bagian dari yang ada Aplikasi DotNetMvc lokasi.

Manajer IIS menampilkan aplikasi api di dalam situs .NET Framework

Gambar 5-1. Situs .NET Framework dengan aplikasi .NET Core di IIS.

Itu Aplikasi DotNetMvc situs dihosting sebagai aplikasi MVC 5 yang berjalan di .NET Framework 4.7.2. Ini memiliki kumpulan aplikasi IIS sendiri yang dikonfigurasi dalam mode terintegrasi dan menjalankan .NET CLR versi 4.0.30319. Itu api app adalah aplikasi ASP.NET Core yang berjalan di .NET Framework 4.6.1 (net461). Itu ditambahkan ke Aplikasi DotNetMvc sebagai aplikasi IIS baru dan dikonfigurasi untuk menggunakan Kumpulan Aplikasinya sendiri. Kumpulan Aplikasinya juga berjalan dalam mode terintegrasi tetapi dikonfigurasi dengan versi .NET CLR dari Tidak Ada Kode Terkelola karena akan dieksekusi menggunakan ASP.NET Core Module. Versi aplikasi ASP.NET Core hanyalah sebuah contoh. Itu juga dapat dikonfigurasi untuk berjalan di .NET Core 3.1 atau .NET 5. Meskipun pada saat itu, itu tidak lagi dapat menargetkan pustaka .NET Framework (lihat Memilih Versi Inti .NET yang Tepat)

Dikonfigurasi dengan cara ini, satu-satunya perubahan yang harus dilakukan agar API aplikasi ASP.NET Core dirutekan dengan benar adalah dengan mengubah templat rute default dari [Route("[api/controller]")] ke [Route("[controller]")].

Sebagai alternatif, aplikasi ASP.NET Core dapat menjadi situs web tingkat atas lainnya di IIS. Dalam hal ini, Anda dapat mengonfigurasi situs asli untuk menggunakan aturan penulisan ulang (dengan Penulisan Ulang URL) yang akan mengalihkan ke aplikasi lain jika jalur dimulai dengan /api. Aplikasi ASP.NET Core dapat menggunakan header host yang berbeda untuk rutenya sehingga tidak bertentangan dengan aplikasi utama tetapi masih dapat menanggapi permintaan menggunakan rute berbasis root.

Sebagai contoh, aplikasi ASP.NET Core yang sama yang digunakan pada Gambar 5-1 dapat digunakan ke folder lain yang dikonfigurasi sebagai situs web IIS. Situs harus menggunakan kumpulan aplikasi yang dikonfigurasi seperti sebelumnya, dengan Tidak Ada Kode Terkelola. Konfigurasikan bindingnya untuk merespons nama host unik di server, seperti api.contoso.com. Untuk mengonfigurasi Penulisan Ulang URL untuk menulis ulang permintaan yang cocok /api cukup tambahkan aturan masuk baru di tingkat server IIS (atau situs individual). Cocokkan polanya ^/api(.*) dan tentukan jenis Tindakan dari Rewrite dan URL Tulis Ulang dari api.contoso.com/R:1. Kombinasi menggunakan (.*) dalam pola yang cocok dan R:1 di URL penulisan ulang akan memastikan sisa jalur digunakan dengan URL baru. Dengan ini di tempat, situs terpisah di server IIS yang sama dapat hidup berdampingan menjalankan versi terpisah dari .NET, tetapi mereka dapat dibuat muncul ke Internet sebagai satu aplikasi web. Gambar 5-2 menunjukkan aturan penulisan ulang sebagaimana dikonfigurasi di IIS dengan situs web terpisah.

Manajer IIS menampilkan aturan Penulisan Ulang URL untuk merutekan permintaan subfolder ke situs web terpisah

Gambar 5-2. Aturan penulisan ulang untuk menulis ulang permintaan subfolder ke situs web lain.

Jika aplikasi Anda memerlukan sistem masuk tunggal antara situs atau aplikasi yang berbeda dalam IIS, lihat dokumentasi tentang cara berbagi cookie autentikasi di antara aplikasi ASP.NET untuk petunjuk mendetail tentang mendukung skenario ini.

Ringkasan

Pendekatan umum untuk mem-porting aplikasi besar dari .NET Framework ke ASP.NET Core adalah memilih bagian individual dari aplikasi yang akan dimigrasikan satu per satu. Karena setiap bagian aplikasi di-porting, seluruh aplikasi tetap berjalan dan dapat digunakan, dengan beberapa bagian berjalan dalam konfigurasi aslinya dan bagian lain berjalan pada beberapa versi .NET Core. Dengan mengikuti pendekatan ini, migrasi aplikasi besar dapat dilakukan secara bertahap. Pendekatan ini menghasilkan pembatasan risiko dengan memberikan umpan balik yang lebih cepat dan mengurangi total luas permukaan yang terlibat dalam pengujian. Ini juga memungkinkan realisasi manfaat .NET Core yang lebih cepat, seperti peningkatan kinerja. Meskipun aplikasi ASP.NET Core tidak lagi diperlukan untuk dihosting di IIS, IIS tetap menjadi server web yang sangat fleksibel dan kuat yang dapat dikonfigurasi untuk mendukung berbagai skenario hosting yang melibatkan aplikasi .NET Framework dan ASP.NET Core secara bersamaan. Contoh IIS atau bahkan di-host di server yang berbeda.

Referensi

By AKDSEO