Menggunakan Kontainer Windows untuk "Kontainerisasi" Aplikasi yang Ada

Berlaku untuk: Windows Server 2022, Windows Server 2019, Windows Server 2016

Kontainer Windows menyediakan mekanisme yang bagus untuk memodernisasi aplikasi tradisional atau warisan. Meskipun Anda mungkin mendengar pendekatan ini disebut sebagai "angkat dan geser ke kontainer," metafora lift-and-shift berasal dari pergeseran beban kerja dari fisik ke komputer virtual dan telah digunakan akhir-akhir ini ketika mengacu pada pemindahan beban kerja apa adanya ke cloud (baik privat atau publik). Saat ini istilah ini lebih tepat diterapkan untuk memigrasikan komputer virtual (VM). Tetapi kontainer bukan VM dan menganggapnya sebagai VM dapat menyebabkan kebingungan tentang bagaimana aplikasi dapat ditampung, atau apakah itu bahkan dapat - atau harus - ditampung.

Topik ini memberikan panduan praktis tentang memindahkan aplikasi tradisional ke kontainer Windows. Ini bertujuan untuk membantu Anda memprioritaskan aplikasi mana yang harus dikontainerisasi, dengan menjelaskan pertimbangan khusus di muka.

Pengantar

Apa itu kontainer Windows, dan apa itu tidak

Istilah generik kontainer mengacu pada teknologi yang memvirtualisasikan sistem operasi (OS). Virtualisasi ini memberikan tingkat isolasi dari OS server/host itu sendiri, yang pada gilirannya memungkinkan lebih banyak kelincahan bagi pengembang aplikasi dan tim operasi.

Kontainer Windows adalah implementasi khusus dari teknologi kontainer. Mereka menyediakan instans sistem operasi virtual yang diisolasi dari OS Windows. Tetapi total interdependensi antara kontainer dan host tidak mungkin: kontainer Windows harus mengoordinasikan permintaannya untuk sumber daya dan fungsi dengan OS Windows. Mengapa ini penting? Karena kontainer Windows bukan seluruh server virtual dan beberapa hal yang mungkin ingin Anda lakukan dengan aplikasi tidak dapat dilakukan hanya dengan OS virtual.

Anda dapat membaca lebih lanjut tentang topik ini di Kontainer vs. komputer virtual. Tetapi beberapa poin bagus yang membantu Anda mengingat perbedaan kontainer vs. VM adalah:

• Kontainer bukan solusi yang setara dengan virtualisasi aplikasi desktop. Mereka hanya mendukung aplikasi sisi server yang tidak memerlukan sesi interaktif. Karena berjalan pada gambar kontainer khusus, mereka hanya mendukung aplikasi yang tidak memerlukan ujung depan grafis.
• Kontainer bersifat ephemeral. Ini berarti bahwa, secara default, tidak ada mekanisme untuk menyimpan status instans kontainer. Jika instans gagal, instans lain akan menggantikannya.

Teknologi kontainer dimulai di Linux, dengan Docker muncul sebagai standar. Microsoft telah bekerja sama dengan Docker untuk memastikan fungsionalitas kontainer sama pada Windows seperti yang mungkin. Perbedaan yang melekat antara Linux dan Windows mungkin muncul dengan cara yang tampaknya merupakan batasan kontainer Windows padahal sebenarnya hanya perbedaan Linux versus Windows. Di sisi lain, kontainer Windows menyediakan beberapa implementasi unik, seperti isolasi Hyper-V, yang akan dibahas nanti. Topik ini akan membantu Anda memahami perbedaan tersebut dan cara mengakomodasinya.

Manfaat menggunakan kontainer

Sama seperti menjalankan beberapa VM pada satu host fisik, Anda dapat menjalankan beberapa kontainer pada satu host fisik atau virtual. Tetapi tidak seperti VM, Anda tidak perlu mengelola OS untuk kontainer, yang memberi Anda fleksibilitas untuk fokus pada pengembangan aplikasi dan infrastruktur yang mendasar. Ini juga berarti Anda dapat mengisolasi aplikasi sehingga tidak terpengaruh oleh proses lain yang didukung oleh OS.

Kontainer menyediakan metode ringan untuk membuat dan secara dinamis menghentikan sumber daya yang diperlukan untuk aplikasi yang berfungsi. Meskipun memungkinkan untuk membuat dan menyebarkan VM saat permintaan aplikasi meningkat, lebih cepat menggunakan kontainer untuk perluasan skala. Dengan kontainer, Anda juga dapat memulai ulang dengan cepat jika terjadi crash atau gangguan perangkat keras. Kontainer memungkinkan Anda untuk mengambil aplikasi apa pun dari pengembangan ke produksi dengan sedikit atau tanpa perubahan kode, karena mereka "berisi" dependensi aplikasi sehingga mereka bekerja di seluruh lingkungan. Kemampuan untuk melakukan kontainerisasi aplikasi yang ada dengan perubahan kode minimal, karena integrasi Docker di seluruh alat pengembang Microsoft, juga merupakan faktor yang kuat dalam pengembangan dan pemeliharaan aplikasi.

Akhirnya, salah satu manfaat terpenting menggunakan kontainer adalah kelincahan yang Anda peroleh untuk pengembangan aplikasi, karena Anda dapat memiliki versi aplikasi yang berbeda yang berjalan pada host yang sama tanpa bentrokan sumber daya.

Anda dapat menemukan daftar manfaat yang jauh lebih lengkap untuk menggunakan kontainer untuk aplikasi yang ada di halaman dokumentasi Microsoft .NET.

Konsep penting tingkat isolasi

Kontainer Windows menyediakan isolasi dari OS Windows, isolasi yang menguntungkan saat Anda membangun, menguji, dan mempromosikan aplikasi ke produksi. Tetapi cara isolasi dicapai penting untuk dipahami ketika Anda berpikir tentang kontainerisasi aplikasi.

Kontainer Windows menawarkan dua mode isolasi runtime yang berbeda: proses dan Hyper-V. Kontainer di bawah kedua mode dibuat dan dikelola secara identik, dan berfungsi identik. Jadi, apa perbedaan dan mengapa Anda harus peduli? Dalam isolasi proses, beberapa kontainer berjalan bersamaan pada satu host dengan isolasi yang disediakan melalui namespace, kontrol sumber daya, dan fitur lainnya. Kontainer dalam mode isolasi proses berbagi kernel yang sama dengan host serta satu sama lain. Ini kira-kira sama dengan cara kontainer Linux berjalan.

Dalam isolasi Hyper-V, beberapa kontainer juga berjalan bersamaan pada satu host, tetapi kontainer berjalan di dalam komputer virtual yang sangat dioptimalkan, dengan masing-masing secara efektif mendapatkan kernelnya sendiri. Kehadiran komputer virtual ini – secara efektif merupakan VM "utilitas" – menyediakan isolasi tingkat perangkat keras antara setiap kontainer, serta host kontainer.

Dengan cara, mode isolasi Hyper-V hampir seperti hibrida VM dan kontainer, memberikan lapisan keamanan tambahan yang sangat membantu jika aplikasi Anda membutuhkan multitenansi. Tetapi kemungkinan trade-off menggunakan mode isolasi Hyper-V meliputi:

• Waktu mulai yang lebih lama untuk kontainer, dan kemungkinan berdampak pada performa aplikasi secara keseluruhan.
• Tidak semua alat bekerja secara asli dengan isolasi Hyper-V.
• Baik Azure Kubernetes Service (AKS) maupun AKS di Azure Stack HCI tidak mendukung isolasi Hyper-V saat ini.

Anda dapat membaca selengkapnya tentang bagaimana dua mode isolasi diimplementasikan dalam topik Mode Isolasi. Saat pertama kali melakukan kontainerisasi aplikasi, Anda harus memilih di antara dua mode. Untungnya, sangat mudah untuk mengubah dari satu mode ke mode lain nanti, karena tidak memerlukan perubahan apa pun pada aplikasi atau kontainer. Namun perlu diketahui bahwa, saat Anda membuat kontainer aplikasi, memilih di antara kedua mode adalah salah satu hal pertama yang harus Anda lakukan.

Orkestrasi kontainer

Kemampuan untuk menjalankan beberapa kontainer pada satu atau beberapa host tanpa kekhawatiran terhadap manajemen OS memberi Anda fleksibilitas besar, membantu Anda bergerak menuju arsitektur berbasis layanan mikro. Satu trade-off untuk fleksibilitas itu, adalah bahwa lingkungan berdasarkan kontainer dan layanan mikro dapat dengan cepat menjamur ke banyak bagian yang bergerak - terlalu banyak untuk dilacak. Untungnya, mengelola penyeimbangan beban, ketersediaan tinggi, penjadwalan kontainer, manajemen sumber daya, dan banyak lagi, adalah peran orkestrator kontainer.

Orkestrator mungkin salah nama; mereka lebih seperti konduktor orkestra karena mereka mengoordinasikan aktivitas beberapa kontainer untuk menjaga musik tetap diputar. Dalam arti tertentu, kontainer menangani penjadwalan dan alokasi sumber daya untuk kontainer dengan cara yang mirip dengan fungsi OS. Jadi, saat Anda pindah ke kontainer aplikasi Anda, Anda harus memilih di antara orkestrator yang mendukung kontainer Windows. Beberapa yang paling umum adalah Kubernetes dan Docker Swarm.

Apa yang tidak dapat dipindahkan ke kontainer Windows

Ketika Anda mempertimbangkan apakah aplikasi dapat ditampung atau tidak, mungkin paling mudah untuk memulai dengan daftar faktor yang sepenuhnya mengesampingkan kontainer Windows sebagai opsi.

Tabel berikut ini meringkas jenis aplikasi yang tidak dapat dipindahkan ke kontainer Windows, dan mengapa tidak. Alasannya lebih sepenuhnya dijelaskan dalam sub-bagian setelah tabel. Memahami alasan keterbatasan ini dapat memberi Anda gambaran yang lebih jelas tentang apa itu kontainer, termasuk perbedaannya dengan VM. Ini pada gilirannya akan membantu Anda menilai dengan lebih baik kemampuan kontainer Windows yang dapat Anda manfaatkan dengan aplikasi yang ada yang dapat Anda kontainerisasi.

Catatan: Daftar di bawah ini bukan daftar lengkap. Sebaliknya, ini adalah kompilasi aplikasi yang telah dilihat Microsoft kepada pelanggan yang mencoba melakukan kontainerisasi.

Aplikasi/fitur tidak didukung	Mengapa tidak didukung	Dapatkah Anda bekerja di sekitar ini?
Aplikasi yang memerlukan desktop	Kontainer tidak mendukung Antarmuka Pengguna Grafis (GUI)	Jika aplikasi hanya memerlukan GUI untuk diinstal, mengubahnya menjadi penginstalan senyap mungkin menjadi solusi
Aplikasi yang menggunakan Protokol Desktop Jauh (RDP)	RDP adalah untuk sesi interaktif, sehingga prinsip di atas juga berlaku di sini	Anda mungkin dapat menggunakan Windows Admin Center (WAC) atau Remote PowerShell sebagai alternatif untuk manajemen jarak jauh
Aplikasi stateful	Kontainer bersifat ephemeral	Ya, beberapa aplikasi mungkin memerlukan perubahan minimal, sehingga tidak menyimpan data atau status di dalam kontainer
Aplikasi database	Kontainer bersifat ephemeral	Ya, beberapa aplikasi mungkin memerlukan perubahan minimal, sehingga tidak menyimpan data atau status di dalam kontainer
Direktori Aktif	Desain dan tujuan Direktori Aktif menghalangi berjalan dalam kontainer	Nomor. Namun, aplikasi yang bergantung pada Direktori Aktif dapat menggunakan Akun Layanan Terkelola Grup (gMSA). Informasi lebih lanjut tentang gMSA disediakan di bawah ini
Versi Windows Server yang lebih lama	Hanya Windows Server 2016 atau yang lebih baru yang didukung	Nomor. Namun, kompatibilitas aplikasi mungkin merupakan opsi - sebagian besar Windows Server 2008/R2 dan aplikasi yang lebih lama berjalan pada versi Windows Server yang lebih baru
Aplikasi yang menggunakan .NET Framework versi 2.0 atau yang lebih lama	Gambar kontainer tertentu diperlukan untuk mendukung .NET Framework, dan hanya versi yang lebih baru yang didukung	Versi yang lebih lama dari 2.0 tidak didukung sama sekali, tetapi lihat di bawah ini untuk gambar kontainer yang diperlukan untuk versi yang lebih baru
Aplikasi yang menggunakan kerangka kerja pihak ketiga lainnya	Microsoft tidak secara khusus mensertifikasi atau mendukung penggunaan kerangka kerja non-Microsoft pada Kontainer Windows	Tanyakan kepada vendor kerangka kerja atau aplikasi tertentu kebijakan dukungan untuk kontainer Windows. Lihat di bawah ini untuk informasi selengkapnya

Mari kita pertimbangkan masing-masing batasan ini secara bergantian.

Aplikasi yang memerlukan desktop

Kontainer sangat ideal untuk fungsi ephemeral yang dipanggil dari aplikasi lain, termasuk yang memiliki interaksi pengguna. Tetapi Anda tidak dapat menggunakannya untuk aplikasi yang memiliki GUI itu sendiri. Ini berlaku bahkan jika aplikasi itu sendiri tidak memiliki GUI tetapi memiliki alat penginstal yang bergantung pada GUI. Secara umum, Pemasang Windows dapat dipanggil menggunakan PowerShell, tetapi jika aplikasi Anda memerlukan penginstalan melalui GUI, persyaratan tersebut menghilangkannya sebagai kandidat untuk kontainerisasi.

Ini bukan masalah dengan cara kontainer Windows diterapkan, melainkan konsep dasar tentang cara kerja kontainer.

Ini adalah masalah yang berbeda jika aplikasi membutuhkan API GUI. API didukung meskipun GUI yang dilayani oleh API tersebut tidak. Ini lebih sepenuhnya dijelaskan dalam topik Nano Server x Server Core x Server - Gambar dasar mana yang tepat untuk Anda?

Aplikasi yang menggunakan RDP

Karena seluruh tujuan Protokol Desktop Jarak Jauh (RDP) adalah untuk membuat sesi visual interaktif, batasan GUI yang baru saja dijelaskan juga berlaku. Aplikasi yang menggunakan RDP tidak dapat dikemas apa adanya.

Namun, alternatif yang baik adalah alat manajemen jarak jauh seperti Windows Admin Center. Anda dapat menggunakan Windows Admin Center untuk mengelola host kontainer Windows, dan kontainer itu sendiri, tanpa perlu RDP ke dalamnya. Anda juga dapat membuka sesi PowerShell jarak jauh ke host dan/atau kontainer untuk mengelolanya.

Aplikasi stateful

Aplikasi yang perlu mempertahankan data status hanya dapat ditampung jika Anda mengisolasi data yang diperlukan dari satu sesi ke sesi berikutnya dan menyimpannya di penyimpanan persisten. Ini mungkin memerlukan beberapa "meracik ulang" yang mungkin atau mungkin tidak sepele tetapi melanjutkannya akan menghilangkan hambatan ini untuk kontainerisasi.

Contoh status adalah aplikasi web yang menyimpan gambar atau file musik ke folder lokal. Dalam lingkungan Windows tradisional, file disimpan ke disk saat operasi tulis menyimpulkan, jadi jika instans (VM dalam hal ini) gagal, Anda cukup membawanya kembali dan file masih akan ada di sana. Sebaliknya, jika instans kontainer yang melakukan operasi tulis gagal, instans kontainer baru tidak akan menyertakan file tersebut. Untuk alasan ini, Anda harus mempertimbangkan untuk menggunakan penyimpanan persisten sehingga semua instans kontainer dapat menyimpan data status atau file ke lokasi terpusat dan tahan lama. Jenis pembuatan ulang ini tidak mengharuskan Anda mengubah kode aplikasi, hanya jenis penyimpanan yang digunakan oleh instans Windows. Untuk informasi selengkapnya, lihat dokumentasi kontainer Windows tentang penyimpanan.

Namun, ini membawa topik lain yang terkait ...

Aplikasi database

Sebagai aturan umum, aplikasi database bukanlah kandidat yang bagus untuk kontainerisasi. Meskipun Anda dapat menjalankan database di dalam kontainer, kontainerisasi database yang ada biasanya tidak ideal, karena dua alasan.

Pertama, performa yang diperlukan untuk database mungkin memerlukan seluruh sumber daya perangkat keras yang tersedia untuk host - yang merancang manfaat konsolidasi. Kedua, beberapa instans tingkat database tunggal membutuhkan koordinasi untuk operasi tulisnya. Orkestrasi kontainer dapat menyelesaikannya, tetapi untuk database yang ada, orkestrasi mungkin menjadi overhead. Sebagian besar database, seperti Microsoft SQL Server, memiliki keseimbangan beban bawaan dan mekanisme ketersediaan tinggi.

Peran Infrastruktur di Windows Server

Peran infrastruktur Windows Server terutama menangani fungsi yang lebih dekat dengan sistem operasi (misalnya, AD, DHCP, dan Server File). Dengan demikian mereka tidak tersedia untuk menjalankan kontainer. Oleh karena itu, aplikasi yang membutuhkan peran ini akan selalu sulit untuk di-containerize.

Ada beberapa daerah abu-abu. Misalnya, beberapa fitur seperti DNS mungkin berfungsi pada kontainer Windows meskipun tidak benar-benar dimaksudkan untuk digunakan dalam kontainer. Peran infrastruktur lainnya hanya dihapus dari gambar kontainer dasar dan tidak dapat diinstal, seperti Direktori Aktif, DHCP, dan lainnya.

Direktori Aktif (AD)

Direktori Aktif dirilis lebih dari dua puluh tahun yang lalu di sepanjang Windows 2000 Server. Ini menggunakan mekanisme di mana setiap perangkat atau pengguna diwakili oleh objek yang disimpan dalam databasenya. Hubungan ini digabungkan dengan erat, dan objek disimpan dalam database meskipun pengguna atau perangkat yang sebenarnya tidak lagi dimainkan. Pendekatan untuk Direktori Aktif itu secara langsung bertentangan dengan sifat kontainer sementara, yang diharapkan berumur pendek atau dihapus saat dimatikan. Mempertahankan hubungan satu-ke-satu ini dengan Direktori Aktif tidak ideal untuk skenario tersebut.

Untuk alasan itu, kontainer Windows tidak dapat bergabung dengan domain. Sebagai efek dari itu, Anda tidak dapat menjalankan Active Directory Domain Services sebagai peran infrastruktur pada kontainer Windows. Anda dapat menjalankan modul PowerShell untuk mengelola Pengendali Domain dari jarak jauh di dalam kontainer Windows.

Untuk aplikasi yang berjalan pada kontainer Windows yang bergantung pada Direktori Aktif, Anda dapat menggunakan Akun Layanan Terkelola Grup (gMSA), yang akan dijelaskan lebih lanjut.

Aplikasi yang menggunakan .NET Framework versi 2.0 atau yang lebih lama

Jika aplikasi Anda memerlukan .NET, kemampuan Anda untuk melakukan kontainerisasi sepenuhnya bergantung pada versi .NET Framework yang digunakannya. Versi apa pun sebelum .NET Framework 2.0 tidak didukung sama sekali; versi yang lebih tinggi memerlukan penggunaan gambar tertentu seperti yang dijelaskan nanti.

Aplikasi yang menggunakan kerangka kerja pihak ketiga (non-Microsoft)

Secara umum, Microsoft tidak dapat mensertifikasi kerangka kerja atau aplikasi pihak ketiga, atau mendukungnya berjalan pada kontainer Windows - atau komputer fisik dan virtual untuk hal itu. Namun, Microsoft melakukan pengujian internalnya sendiri untuk kegunaan beberapa kerangka kerja dan alat pihak ketiga, termasuk Apache, Cassandra, Chocolatey, Datadog, Django, Flask, Git, Golang, JBoss, Jenkins, Rust, Nodejs, Pearl, Python, Ruby, Tomcat, dan banyak lainnya.

Untuk kerangka kerja atau perangkat lunak pihak ketiga apa pun, validasi dukungannya pada kontainer Windows dengan vendor yang memasoknya.

Kandidat ideal untuk kontainerisasi

Sekarang setelah kami mempertimbangkan batasan keras pada aplikasi kontainer, lebih mudah untuk melihat jenis aplikasi apa yang lebih mudah dipinjamkan sendiri ke kontainer Windows. Kandidat ideal untuk kontainer Windows, dan pertimbangan khusus apa pun untuk kontainerisasi, ada dalam tabel berikut.

Jenis aplikasi	Mengapa ini adalah kandidat yang baik	Pertimbangan khusus
Aplikasi konsol	Tanpa batasan GUI, aplikasi konsol adalah kandidat ideal untuk kontainer.	Gunakan gambar kontainer dasar yang sesuai tergantung pada kebutuhan aplikasi.
Layanan Windows	Karena ini adalah proses latar belakang yang tidak memerlukan interaksi pengguna langsung	Gunakan gambar kontainer dasar yang sesuai tergantung pada kebutuhan aplikasi. Anda perlu membuat proses latar depan agar proses latar belakang kontainer tetap berjalan. Lihat bagian tentang Layanan latar belakang di bawah ini.
Layanan Windows Communication Foundation (WCF)	Karena mereka adalah aplikasi berorientasi layanan yang juga dapat berjalan di latar belakang	Gunakan gambar kontainer dasar yang sesuai tergantung pada kebutuhan aplikasi. Anda mungkin perlu membuat proses latar depan agar proses latar belakang kontainer tetap berjalan. Lihat bagian tentang Layanan latar belakang di bawah ini.
Aplikasi web	Aplikasi web pada dasarnya adalah layanan latar belakang yang mendengarkan pada port tertentu dan oleh karena itu merupakan kandidat yang bagus untuk kontainerisasi, karena dapat memanfaatkan skalabilitas yang ditawarkan oleh kontainer	Gunakan gambar kontainer dasar yang sesuai tergantung pada kebutuhan aplikasi.

Catatan: bahkan kandidat ideal untuk kontainerisasi ini dapat mengandalkan fitur dan komponen Windows inti yang perlu ditangani secara berbeda dalam kontainer Windows. Bagian berikutnya, yang masuk ke detail lebih lanjut tentang pertimbangan praktis seperti itu, akan lebih mempersiapkan Anda untuk memanfaatkan fungsionalitas kontainer Windows.

Pertimbangan praktis untuk aplikasi yang dapat ditampung

Proyek renovasi aplikasi biasanya mempertimbangkan apakah aplikasi tertentu dapat ditampung melalui perspektif fungsi bisnis aplikasi. Tetapi fungsionalitas bisnis bukanlah faktor yang menentukan apakah itu mungkin secara teknis. Yang penting adalah arsitektur aplikasi, yaitu komponen teknis apa yang diandalkannya. Oleh karena itu, tidak ada jawaban mudah untuk pertanyaan seperti "Dapatkah saya melakukan kontainerisasi aplikasi SDM saya?" karena bukan apa yang dilakukan aplikasi, itu adalah bagaimana (dan komponen/layanan Windows apa yang digunakannya) yang membuat perbedaan.

Ini adalah perbedaan penting, karena jika aplikasi Anda tidak dibangun dengan arsitektur layanan mikro untuk memulai, kemungkinan akan lebih sulit untuk ditampung. Saat Anda melanjutkan untuk melakukan kontainerisasi, fitur tertentu mungkin memerlukan penanganan khusus. Beberapa mungkin karena penggunaan komponen dan kerangka kerja Windows inti aplikasi yang tidak didukung dalam kontainer Windows. Lainnya, seperti pengelogan dan pemantauan peristiwa, disebabkan oleh perbedaan melekat antara Linux dan Windows yang menjadi jelas hanya ketika Anda melakukan kontainerisasi aplikasi. Masih yang lain, seperti tugas terjadwal dan layanan latar belakang, harus dipahami dari perspektif bahwa kontainer bukan VM tetapi sementara, dan oleh karena itu perlu penanganan khusus.

Tabel berikut menyajikan ringkasan cepat komponen/fitur aplikasi yang memerlukan pertimbangan khusus saat Anda berpikir tentang kontainerisasi. Sub bagian berikut memberi Anda lebih banyak detail, termasuk contoh yang menggambarkan teknik untuk menangani setiap skenario. Sementara daftar di bawah ini mencakup skenario yang didukung pada kontainer Windows, skenario ini masih perlu menghormati panduan dari bab sebelumnya. Misalnya, meskipun layanan latar belakang didukung, menjalankan layanan latar belakang pada .NET Framework 1.1 tidak didukung.

Fitur/komponen Windows yang memerlukan penanganan khusus	Alasan
antrean Microsoft Olahpesan (MSMQ)	MSMQ berasal jauh sebelum kontainer dan tidak semua model penyebarannya untuk antrean pesan kompatibel dengan arsitektur kontainer.
Microsoft Koordinator Transaksi Terdistribusi (MSDTC).	Resolusi nama antara MSDTC dan kontainer memerlukan pertimbangan khusus.
IIS	IIS sama seperti dalam VM, tetapi ada pertimbangan penting saat menjalankannya di lingkungan kontainer, seperti manajemen sertifikat, string koneksi database, dan banyak lagi.
Tugas terjadwal	Kontainer Windows dapat menjalankan tugas terjadwal, sama seperti instans Windows apa pun. Namun, Anda mungkin perlu menjalankan tugas latar depan agar instans kontainer tetap berjalan. Bergantung pada aplikasi, Anda mungkin ingin mempertimbangkan pendekatan berbasis peristiwa.
Layanan latar belakang	Karena kontainer berjalan sebagai proses sementara, Anda memerlukan penanganan tambahan untuk menjaga kontainer tetap berjalan
.NET Framework dan .NET (sebelumnya .Net Core)	Pastikan untuk menggunakan gambar yang tepat untuk memastikan kompatibilitas, seperti yang dijelaskan dalam subbagian di bawah ini

Komponen pendukung lainnya

Komponen yang membutuhkan penanganan khusus	Alasan	Pendekatan alternatif
Pengelogan/pemantauan peristiwa	Karena cara Windows menulis peristiwa dan log secara inheren berbeda dari stdout Linux	Gunakan alat Log Monitor baru untuk menormalkan data dan menggabungkan dari Linux dan Windows
Keamanan kontainer Windows	Meskipun banyak praktik keamanan tetap sama, kontainer memerlukan langkah-langkah keamanan tambahan	Gunakan registri yang dibuat khusus dan alat pemindaian gambar – detail selengkapnya nanti
Pencadangan kontainer Windows	Kontainer tidak boleh memiliki data atau status di dalamnya	Mencadangkan penyimpanan persisten apa pun yang digunakan oleh kontainer, serta gambar kontainer

Komponen/fitur Windows

Sekarang mari kita selaraskan detail aplikasi dan komponen yang dapat ditampung, tetapi memang memerlukan penanganan tambahan.

MSMQ

Jika aplikasi Anda bergantung pada MSMQ, apakah Anda dapat melakukan kontainerisasi tergantung pada skenario penyebaran MSMQ-nya. MSMQ menyertakan beberapa opsi penyebaran. Faktor-faktor antrean privat vs. publik, transaksional atau tidak, dan jenis autentikasi membentuk matriks skenario yang awalnya dirancang untuk didukung oleh MSMQ. Tidak semua ini dapat dengan mudah dipindahkan ke kontainer Windows. Tabel berikut ini mencantumkan skenario yang didukung:

Cakupan	Transaksional?	Lokasi antrean	Jenis autentikasi	Kirim dan terima?
Privat	Ya	Kontainer yang sama (kontainer tunggal)	Anonim	Ya
Privat	Ya	Volume persisten	Anonim	Ya
Privat	Ya	Pengendali Domain	Anonim	Ya
Privat	Ya	Host tunggal (dua kontainer)	Anonim	Ya
Publik	Tidak	Dua host	Anonim	Ya
Publik	Ya	Dua host	Anonim	Ya

Beberapa catatan tentang skenario yang didukung ini, yang telah divalidasi oleh tim pengembangan internal Microsoft:

• Mode isolasi: Mode proses dan mode Hyper-V untuk pekerjaan isolasi dengan skenario yang tercantum di atas.
• OS minimal dan gambar kontainer: Versi OS minimal yang direkomendasikan untuk digunakan dengan MSMQ adalah Windows Server 2019.
• Volume persisten: Skenario di atas divalidasi menjalankan MSMQ di Azure Kubernetes Service (AKS) menggunakan file Azure untuk penyimpanan persisten.

Saat Anda menyatukan pertimbangan ini dengan tabel di atas, Anda dapat melihat bahwa satu-satunya skenario yang tidak didukung adalah untuk antrean yang memerlukan autentikasi dengan Direktori Aktif. Integrasi gMSA (Akun Layanan Terkelola Grup) dengan MSMQ saat ini tidak didukung karena MSMQ memiliki dependensi pada Direktori Aktif yang belum ada.

Atau, gunakan Azure Service Bus alih-alih MSMQ. Microsoft Azure Service Bus adalah broker pesan perusahaan terkelola penuh dengan antrean pesan dan topik terbit-berlangganan (di kumpulan nama XML). Beralih dari MSMQ ke Azure Service Bus memerlukan perubahan kode dan arsitektur ulang aplikasi, tetapi akan memberi Anda kelincahan untuk pindah ke platform modern.

MSDTC

Koordinator Transaksi Terdistribusi Microsoft (MSDTC) banyak digunakan dalam aplikasi warisan Windows di antara perusahaan besar. MSDTC dapat diinstal pada Kontainer Windows tetapi ada skenario tertentu yang tidak berfungsi dan tidak dapat direproduksi pada Kontainer Windows.

• Saat membuat kontainer, pastikan untuk meneruskan parameter --name ke perintah docker run. Parameter nama inilah yang memungkinkan kontainer berkomunikasi melalui jaringan docker. Jika menggunakan gMSA, nama harus cocok dengan nama host yang harus cocok dengan nama akun gMSA.
  • Berikut adalah contoh perintah jalankan dengan gMSA:

docker run -d --security-opt "credentialspec=file://contoso_webapp01.json" --hostname webapp01 -- name webapp01 mcr.microsoft.com/windows/servercore:ltsc2022

• Kontainer harus dapat menyelesaikan satu sama lain menggunakan nama NETBIOS. Jika ada kesulitan dengan ini, cara terbaik untuk mengatasinya adalah dengan menambahkan nama dan ip kontainer ke masing-masing file host lainnya.
• Uuid untuk msdtc pada kedua kontainer harus unik. Uuid dapat ditemukan dengan menjalankan "Get-Dtc" di PowerShell pada kontainer. Jika tidak unik, salah satu cara untuk mengatasinya adalah dengan menghapus instalan dan menginstal ulang msdtc pada salah satu kontainer. Perintah powershelll ini dapat digunakan - "uninstall-dtc", "install-dtc".
• Saat ini, MSDTC tidak didukung pada Azure Kubernetes Services. Jika Anda memiliki kebutuhan khusus untuk menjalankan MSDTC di AKS, beri tahu tim kontainer Windows dengan membuka masalah pada repositori kontainer Windows di GitHub.

Cara kerja IIS dalam kontainer vs. VM

IIS berfungsi sama pada kontainer Windows seperti dalam VM. Namun, ada beberapa aspek menjalankan instans IIS yang harus dipertimbangkan saat berjalan di lingkungan kontainer:

• Penyimpanan persisten untuk data lokal: Folder tempat aplikasi menulis/membaca file ke/dari adalah contoh yang bagus dari sesuatu yang akan Anda simpan di VM untuk instans IIS. Dengan kontainer, Anda tidak ingin data ditulis langsung ke dalam kontainer. Kontainer menggunakan "ruang goresan" untuk penyimpanan lokal dan ketika kontainer baru muncul untuk aplikasi yang sama, kontainer tersebut tidak memiliki akses ke area tersebut dari kontainer sebelumnya. Untuk alasan itu, Anda harus menggunakan penyimpanan persisten untuk data yang perlu dapat diakses oleh aplikasi web, sehingga instans kontainer apa pun dapat memiliki akses ke penyimpanan tersebut.
• Sertifikat: Meskipun Anda dapat memiliki sertifikat lokal pada instans kontainer, Anda harus menghindarinya, karena jika sertifikat perlu diperbarui, Anda harus membangun kembali gambar kontainer Anda. Atau, Anda dapat menggunakan orkestrator kontainer dengan kontrol Ingress. Pengontrol Ingress dapat menerapkan kebijakan jaringan dan juga menangani manajemen sertifikat untuk situs web yang dihosting di belakangnya. Yang terbalik adalah Anda memisahkan manajemen siklus hidup sertifikat dari manajemen situs web.
• String koneksi database: Untuk penyebaran IIS tradisional, Anda dapat meneruskan string koneksi DB sebagai bagian dari penyebaran aplikasi Anda. Meskipun kontainer Windows memungkinkan Anda untuk mengikuti model tersebut, Anda mungkin ingin mempertimbangkan untuk memisahkan string koneksi DB dari kontainer ke konfigurasi terpusat yang disediakan oleh orkestrator kontainer, tempat aplikasi dapat membaca. Ini memungkinkan Anda mengelola dan memperbarui string koneksi DB secara independen dari aplikasi. Jika DB berubah (untuk kasus Lift and Shift ke cloud, misalnya) Anda dapat dengan mudah mengubah string koneksi tanpa membangun kembali gambar kontainer Anda. Pendekatan ini juga memungkinkan Anda untuk menyimpan rahasia (seperti nama pengguna dan kata sandi untuk terhubung ke DB) di penyimpanan rahasia.
• Skala otomatis horizontal: Ketika beban meningkat, sistem komputasi cenderung memperlambat performa yang dirasakan saat mencoba memproses permintaan simultan. Umumnya ada dua cara untuk menghindari dampak performa, – skala vertikal atau horizontal. Skala vertikal meningkatkan sumber daya yang tersedia untuk instans komputasi yang ada (lebih banyak CPU, Memori, dll.). Skala horizontal meningkatkan jumlah instans yang mendukung permintaan (lebih banyak host fisik, atau VM, atau kontainer). Untuk tingkat web seperti IIS, skala horizontal cenderung lebih efisien daripada vertikal, tetapi lingkungan lokal mungkin mengalami keterbatasan sumber daya dan masalah penyeimbangan beban. Dengan lingkungan cloud, skala horizontal jauh lebih mudah karena sumber daya tersedia (dengan biaya tambahan) dan penyedia cloud biasanya merancang mekanisme penyeimbangan bebannya dengan ingat skala horizontal. Kontainer Windows dapat memanfaatkan skala horizontal untuk IIS, tetapi aspek kontainer ephemeral memainkan peran penting. Sangat penting bahwa kontainer Anda memiliki konfigurasi yang sama dan tidak ada status atau data yang disimpan untuk memungkinkan peningkatan atau penurunan jumlah instans yang mendukung aplikasi web Anda.

Tugas terjadwal

Tugas terjadwal digunakan untuk memanggil program, layanan, atau skrip kapan saja di lingkungan Windows. Secara tradisional, Anda memiliki instans Windows yang aktif dan berjalan setiap saat dan ketika pemicu terpenuhi, tugas dijalankan. Ini dimungkinkan dengan kontainer Windows dan - selain dari fakta bahwa Anda perlu mengonfigurasi dan mengelola tugas terjadwal melalui Azure PowerShell - mereka bekerja persis sama.

Namun, dengan pendekatan layanan mikro, Anda memiliki beberapa opsi untuk menghindari menjaga kontainer tetap berjalan untuk menunggu pemicu:

• Gunakan PaaS berbasis peristiwa (Platform as a Service) seperti Azure Function untuk menyimpan kode Anda dan menentukan pemicu untuk aplikasi tersebut. Azure Functions bahkan mendukung gambar kontainer Windows untuk dijalankan saat pemicu terpenuhi.
• Gunakan kontainer Windows bersama dengan orkestrator kontainer. Kontainer hanya dapat berjalan ketika pemicu terpenuhi dan dipanggil dari bagian lain aplikasi. Dalam hal ini, orkestrator kontainer akan menangani penjadwalan dan pemicu untuk aplikasi.
• Terakhir, tetap jalankan kontainer Windows untuk menjalankan tugas terjadwal. Anda akan memerlukan layanan latar depan (seperti Monitor Layanan) untuk menjaga kontainer tetap berjalan.

Layanan latar belakang

Meskipun kontainer umumnya untuk proses sementara, Anda dapat mengkontainerisasi latar belakang, aplikasi jangka panjang asalkan Anda membuat proses latar depan untuk memulai dan membuatnya tetap berjalan.

Contoh yang bagus dari ini adalah ServiceMonitor, yang merupakan Executable Windows yang dirancang untuk digunakan sebagai proses titik masuk saat menjalankan IIS dalam kontainer. Meskipun dibangun untuk IIS, alat ServiceMonitor menawarkan model yang juga dapat digunakan untuk memantau layanan lain, dengan beberapa batasan.

Untuk informasi selengkapnya tentang ServiceMonitor, lihat dokumentasi di Github.

.NET Framework dan .NET

Kontainer Windows mendukung .NET Framework dan .NET (sebelumnya, .NET Core). Tim .NET membuat gambar resminya sendiri untuk kedua kerangka kerja di atas gambar kontainer dasar Windows. Memilih gambar yang sesuai sangat penting untuk memastikan kompatibilitas. Tim .NET menyediakan gambar .Net Framework di atas gambar kontainer dasar Server Core dan gambar .NET di atas gambar kontainer dasar Server Core dan Nano Server. Server Core memiliki set API yang lebih besar daripada Nano Server, yang memungkinkan kompatibilitas yang lebih besar, tetapi juga ukuran gambar yang lebih besar. Nano Server memiliki permukaan API yang sangat berkurang, tetapi ukuran gambar yang jauh lebih kecil.

Dalam beberapa kasus, Anda mungkin perlu membangun gambar .NET Framework atau .NET Anda sendiri di atas gambar kontainer dasar Windows, atau Server. Ini mungkin diperlukan jika aplikasi Anda tidak hanya memiliki dependensi kerangka kerja tetapi dependensi OS. Anda akan dapat mendeteksi dependensi tersebut dengan menguji aplikasi Anda dengan gambar kontainer dasar tertentu.

Misalnya, gambar kontainer dasar Server Core dan Nano Server hanya memiliki satu font yang tersedia, untuk mengurangi ukuran gambar. Jika aplikasi Anda memerlukan font yang berbeda, Anda harus menginstal font tersebut atau menggunakan gambar Server atau Windows, yang memiliki set API yang lebih besar dan menyertakan semua font Windows default. Dari sudut pandang kompatibilitas, ini memungkinkan hampir semua aplikasi (selama mereka menghormati sifat kontainer, seperti no-GUI) untuk ditampung. Pada kelemahannya, ukurannya akan jauh lebih besar, yang dapat memengaruhi performa.

Saat memvalidasi apakah aplikasi yang akan dikontainerisasi berfungsi pada kontainer Windows, Microsoft merekomendasikan hal berikut:

Untuk kerangka kerja ini	Uji dengan gambar kontainer ini terlebih dahulu	Fallback ke gambar kontainer ini jika pertama kali tidak berfungsi	Gambar dasar
.NET Framework versi 2.X dan 3.X	.NET Framework 4.x	.NET Framework 3,5	Windows Server Core
.NET Framework versi 4.x	.NET Framework 4.x	Membangun gambar kontainer .NET Framework Anda dengan gambar Server atau Windows	Windows Server Core
.NET 6 atau 7	.NET 6 atau 7 masing-masing	Membangun gambar kontainer .NET Anda dengan citra dasar Windows atau Server	Windows Nano Server atau Server Core

Komponen pendukung lainnya

Komponen dan topik di bawah ini memberikan panduan tambahan untuk item yang berdampingan atau yang memberikan kejelasan yang lebih baik pada kontainer Windows.

Pengelogan peristiwa

Windows dan Linux menggunakan metode yang berbeda untuk menyimpan dan menyajikan log dan peristiwa kepada penggunanya. Secara tradisional, Windows telah menggunakan format EVT, yang dapat dilihat dengan cara terstruktur dalam Pemantau Peristiwa. Linux, sebaliknya, telah menyediakan pendekatan yang disederhanakan dengan Output Standar (stdout) yang diandalkan oleh alat lain, seperti Docker.

Docker selalu memiliki mekanisme untuk mengekstrak log dari kontainer Linux. Menggunakan perintah "log docker" dengan konfigurasi stdout default, Docker mengeluarkan log aplikasi dari kontainer tanpa membuka kontainer secara interaktif. Namun, hingga peluncuran alat Log Monitor, teknik yang sama tidak berfungsi di Windows.

Alat Log Monitor menyajikan log Windows dalam format stdout sehingga alat lain, seperti Docker, dapat mengumpulkan informasi yang diperlukan untuk menampilkannya. Manfaat tambahan untuk menggunakan Log Monitor meliputi:

• Mampu memfilter jenis peristiwa/log mana yang ingin Anda ekspos di stdout. Misalnya, Anda dapat memfilter log aplikasi untuk pesan "kesalahan" dan "peringatan" hanya jika Anda tidak tertarik dengan peristiwa "informasi".
• Kemampuan untuk memilih dari Log Peristiwa, File Log Kustom, atau Pelacakan Peristiwa untuk Windows (ETW). Ini sangat membantu jika aplikasi Anda menulis pada sumber log yang berbeda. Contohnya adalah log IIS yang terletak di folder "C:\inetpub".
• Fakta bahwa Log Monitor membuat kontainer Windows berperilaku seperti kontainer Linux, dan oleh karena itu alat yang mencari stdout dan berinteraksi dengan fungsi runtime kontainer seperti yang diharapkan. Misalnya, jika Anda berpindah dari Docker ke ContainerD sebagai runtime kontainer, log masih harus terlihat dari host kontainer melalui (misalnya) "log crictl".

Anda dapat membaca selengkapnya tentang alat Monitor Log di posting blog ini.

Keamanan kontainer Windows

Kontainer Windows dibangun pada dasar yang sama dengan instans Windows yang berjalan pada komputer fisik atau virtual. Memahami kekhususan bagaimana kontainer diimplementasikan, terutama sifat kernel bersama mereka, membantu Anda mengamankan aplikasi dalam kontainer:

• Komponen bersama. Kontainer Windows berbagi beberapa komponen host untuk tujuan keamanan. Ini termasuk Firewall Windows, Pertahanan Windows (Antivirus), dan batasan akses sumber daya lainnya. Anda tidak perlu mengonfigurasi komponen ini pada kontainer Anda secara langsung karena host kontainer membuat penyesuaian yang diperlukan berdasarkan beban kerja kontainer Anda. Misalnya, jika kontainer membuat permintaan web, host kontainer akan meneruskan lalu lintas yang diperlukan melalui firewall-nya sehingga kontainer dapat mengakses web.
• Mode isolasi. Seperti yang dibahas, kontainer Windows dapat disebarkan dalam proses atau mode isolasi Hyper-V, dengan Hyper-V menyediakan isolasi yang paling aman. Dalam isolasi proses, kontainer berbagi kernel, sistem file, dan registrinya dengan host, yang memungkinkan proses yang ditinggikan (admin) berinteraksi dengan proses dan layanan kontainer. Memilih mode isolasi yang benar untuk aplikasi Anda penting untuk memastikan model keamanan yang sesuai.
• Pembaruan Windows. Karena tumpukan layanan tidak ada pada kontainer Windows, kontainer Windows tidak menerima pembaruan seperti instans Windows umum. Sebagai gantinya, Anda perlu membangun kembali kontainer Windows menggunakan gambar kontainer dasar terbaru yang tersedia. Pelanggan dapat memanfaatkan alur DevOps untuk tujuan tersebut. Microsoft memperbarui gambar kontainer dasar untuk semua gambar resminya setiap bulan setelah irama Selasa Patch.
• Akun pengguna kontainer. Secara default, aplikasi di dalam kontainer Windows berjalan dengan hak istimewa yang ditinggikan di bawah akun pengguna ContainerAdmin. Ini berguna untuk menginstal dan mengonfigurasi komponen yang diperlukan di dalam gambar kontainer. Namun, Anda harus mempertimbangkan untuk mengubah akun pengguna ke ContainerUser saat menjalankan aplikasi yang tidak memerlukan hak istimewa yang ditingkatkan. Untuk skenario tertentu, Anda juga dapat membuat akun baru dengan hak istimewa yang sesuai.
• Pemindaian gambar dan runtime. Kontainer mengharuskan gambar pada repositori dan instans kontainer aman. Microsoft menyarankan agar Anda menggunakan Microsoft Defender untuk Kontainer untuk pemindaian gambar dan pemindaian runtime. Defender for Containers mendukung kontainer Windows untuk penilaian kerentanan dengan pemindaian registri dan perlindungan runtime dengan deteksi ancaman.

Informasi lebih lanjut tentang topik di atas dapat ditemukan di halaman dokumentasi kontainer Windows.

Pencadangan kontainer Windows

Anda perlu memikirkan cadangan secara berbeda saat menggunakan kontainer. Seperti yang dibahas sebelumnya, kontainer tidak boleh digunakan untuk menyimpan status atau data mengingat sifat sementaranya. Jika Anda memisahkan status dan data dari instans kontainer, masalah pencadangan Anda berada di luar runtime instans kontainer, yang dapat diganti dengan yang baru di mana semua penyimpanan persisten yang diperlukan masih akan tersedia.

Namun, masih ada komponen yang bertanggung jawab untuk dicadangkan; termasuk aplikasi, gambar kontainer, dan dockerfile yang membangun gambar kontainer. Sebagian besar operasi ini ditangani oleh platform tempat Anda menjalankan beban kerja produksi dan pengembangan. Saat mengadopsi pendekatan DevOps, pertimbangkan kasus yang paling umum:

• Aplikasi: Aplikasi Anda mungkin berada di repositori sumber seperti GitHub atau Azure DevOps. Repositori ini menyediakan kontrol versi, yang memungkinkan Anda untuk kembali ke versi aplikasi tertentu. Jika Anda memiliki repositori sumber, pastikan untuk mengikuti rekomendasi pencadangan dan manajemennya.
• Gambar kontainer: Untuk lingkungan produksi, gambar kontainer Anda harus hidup di repositori gambar terpusat, seperti Azure Container Registry (ACR). Anda dapat mendorong gambar kontainer Anda ke ACR sehingga membuatnya tersedia untuk host lain untuk menariknya. ACR menangani ketersediaan gambar kontainer dan berfungsi sebagai opsi cadangan - namun, perlu diingat bahwa sementara ACR menangani ketersediaan gambar, itu tidak mencegah gambar dihapus atau ditimpa. Untuk repositori gambar lokal atau lokal lainnya, ikuti rekomendasi vendor untuk mencadangkan registri yang ada.
• Dockerfile: Dockerfiles membangun gambar kontainer baru dan biasanya disimpan bersama dengan sumber aplikasi. Karena dockerfile mungkin belum dibuat dengan aplikasi, terutama jika itu adalah aplikasi yang ada yang sedang dikontainerisasi, Anda bertanggung jawab untuk memastikan dockerfile disimpan di lokasi yang aman dan dicadangkan. Anda juga harus memastikan bahwa aset lain yang diperlukan agar aplikasi Anda berfungsi dalam kontainer dicadangkan; misalnya: File YAML dan JSON untuk templat Kubernetes, Docker Swarm, dan Azure ARM mengikuti panduan yang sama seperti di atas.

Merencanakan proses lift-and-shift

Setelah Menilai kesiapan aplikasi untuk kontainer, gunakan panduan umum berikut untuk merencanakan proses:

1. Tentukan gambar dasar sistem operasi Windows yang Anda butuhkan: gambar Windows Server Core, Nano Server, Windows, atau Server .
2. Tentukan jenis mode isolasi untuk kontainer: pilih antara proses atau mode isolasi Hyper-V. Catatan: Saat ini, AKS dan AKS di Azure Stack HCI hanya mendukung kontainer yang diisolasi proses. Dalam rilis mendatang, baik AKS maupun AKS di Azure Stack HCI juga akan mendukung kontainer yang terisolasi Hyper-V. Untuk informasi selengkapnya, lihat Mode Isolasi.
3. Pilih versi Windows Server yang tepat untuk aplikasi Anda untuk tujuan kompatasi aplikasi. Versi Windows Server minimal untuk kontainer adalah Windows Server 2016, tetapi Windows Server 2019 dan Windows Server 2022 adalah satu-satunya sistem operasi host kontainer yang didukung pada AKS dan AKS di Azure Stack HCI.
4. Pastikan kebijakan keamanan perusahaan Anda diterapkan untuk lingkungan kontainer. Ini termasuk beradaptasi dengan persyaratan khusus kontainer, seperti pemindaian registri dan deteksi ancaman.
5. Pertimbangkan kebutuhan penyeimbangan beban. Kontainer itu sendiri tidak bergerak; Anda dapat menggunakan orkestrator sebagai gantinya untuk memulai atau menghentikan kontainer secara otomatis pada node kluster, atau untuk mengelola perubahan beban dan ketersediaan dengan skala horizontal otomatis.
6. Pertimbangkan kebutuhan orkestrasi. Setelah dikontainerisasi, aplikasi Anda kemungkinan memerlukan manajemen otomatis yang tersedia dengan alat seperti Kubernetes, AKS, atau AKS di Azure Stack HCI. Lihat Gambaran umum orkestrasi Kontainer Windows untuk diskusi lengkap dan panduan untuk memilih di antara alat.
7. Kontainerisasi aplikasi.
8. Dorong aplikasi ke repositori gambar. Ini akan memungkinkan host kontainer mengunduh gambar di lingkungan apa pun, termasuk pengembangan, pengujian, dan produksi.

Azure Migrate dapat menyediakan proses terpandu untuk menemukan, menilai, dan memigrasikan aplikasi Windows yang ada ke Azure Kubernetes Service. Untuk informasi selengkapnya, lihat halaman dokumentasi Azure Migrate .