Opsi containment MXC dan dukungan platform

MXC membantu Anda mengelola kompleksitas penggunaan kontainer: Anda menggunakan MXC untuk mendefinisikan kebijakan dan mengelola siklus hidup kontainer, tetapi backend kontainer yang dipilih melakukan penegakan aktual. Setiap backend dibangun pada mekanisme sistem operasi yang berbeda. Akibatnya, backend berbeda dalam cara mereka mengisolasi beban kerja dan dalam cara mereka menangani file, jaringan, UI, dan siklus hidup.

Mulai dari apa yang dibutuhkan beban kerja Anda, lalu konfirmasikan bahwa backend dapat menyediakannya pada host yang Anda targetkan. Nama atau versi sistem operasi itu saja tidak akan memberi tahu Anda apakah backend didukung.

Memahami lingkungan host dan lingkungan beban kerja

Dalam permintaan, Anda dapat meminta semacam lingkungan, yang disebut intent containment, atau Anda dapat memberi nama backend tertentu. intent process dipetakan ke backend isolasi proses asli pada host tempat Anda menjalankannya. Karena backend tersebut berbeda menurut sistem operasi, intent yang sama dapat memberi Anda kemampuan yang berbeda pada Windows, Linux, dan macOS.

Host Backend proses bawaan Lingkungan lain
Windows ProcessContainer Sesi Windows terpisah, VM Windows, atau beban kerja Linux melalui WSLc, jika didukung
Linux Bubblewrap LXC dan backend virtualisasi khusus, jika didukung
macOS Sabuk pengaman Periksa rilis yang Anda instal untuk opsi lain yang didukung

Beban kerja tidak harus berjalan pada sistem operasi yang sama dengan host. Misalnya, WSLc menjalankan beban kerja Linux pada host Windows. Ini memiliki prasyaratnya sendiri, dan berbagi sumber daya dengan host secara berbeda dibandingkan dengan cara kerja sandbox proses Windows.

Periksa status rilis dan cakupan SDK

Dukungan backend berubah dari rilis ke rilis, jadi periksa informasi dukungan untuk versi paket yang Anda instal.

Di MXC v1.0.0, SDK V1 dapat membuat kontainer dengan backend ini:

  • Windows: ProcessContainer, IsolationSession, dan WSLc
  • Linux: Bubblewrap dan LXC
  • macOS: Seatbelt

Windows Sandbox, MicroVM, dan Hyperlight bersifat eksperimental. Mereka memerlukan otorisasi eksperimental eksplisit, dan Anda tidak dapat membuatnya melalui API SDK V1. Jika Anda mempertimbangkan salah satu lingkungan khusus ini atau lainnya, periksa catatan rilis untuk versi Anda terlebih dahulu.

Backend yang tersedia di host mungkin masih belum mendukung operasi SDK yang Anda rencanakan untuk dipanggil. Di SDK V1:

  • API siklus hidup hanya berfungsi dengan IsolationSession dan WSLc.
  • Eksekusi PTY satu bidikan berfungsi dengan IsolationSession, Bubblewrap, LXC, dan Seatbelt.
  • Eksekusi PTY dalam kontainer yang ada hanya berfungsi dengan IsolationSession.

Untuk detailnya, lihat referensi SDK:

Jika Anda menggunakan Rust, dukungan backend juga bergantung pada fitur crate yang Anda aktifkan. Untuk menggunakan IsolationSession atau WSLc, aktifkan fitur isolation_session atau wslc pada crate mxc-sdk. Untuk informasi selengkapnya, lihat panduan Rust SDK.

Mulai dengan penemuan runtime

Setiap SDK dapat memberi tahu Anda apa yang didukung host saat ini sebelum Anda meluncurkan apa pun. Jalankan pemeriksaan ini terlebih dahulu, tetapi terus tangani kesalahan peluncuran juga, karena konfigurasi host dapat berubah antara pemeriksaan dan peluncuran.

Gunakan dukungan platform untuk mengetahui apakah Anda dapat meluncurkan kontainer, backend yang tersedia untuk mendapatkan tampilan host yang lebih luas, dan probe untuk menguji permintaan tertentu di Windows sebelum Anda menjalankannya.

SDK Discovery API Apa yang harus diperiksa
.NET MxcPlatform.GetPlatformSupport() IsSupported, Reason, dan AvailableMethods, yang mencantumkan backend yang dapat diluncurkan SDK
.NET MxcPlatform.GetAvailableBackends() Ketersediaan host, kemampuan opsional, dan peringatan. Beberapa API eksekusi tidak dapat menggunakan setiap backend yang tercantum di sini.
.NET MxcContainer.Probe() Pada Windows, tingkat isolasi ProcessContainer, diagnostik kompatibilitas khusus untuk permintaan yang akan diperoleh, tanpa membuat kontainer
TypeScript getPlatformSupport() isSupported, reason, availableMethods, dan setiap bidang peringatan dan kemampuan khusus host
TypeScript getAvailableBackends() Ketersediaan host, kemampuan opsional, dan peringatan. Beberapa API eksekusi tidak dapat menggunakan setiap backend yang tercantum di sini.
TypeScript probe() Pada Windows, pada tingkat isolasi ProcessContainer, permintaan akan mendapatkan diagnostik kompatibilitas khusus untuk permintaan tersebut, tanpa membuat kontainer
Rust v1::platform_support() is_supported, reason, available_methods, dan, pada Linux, Kemampuan jaringan Bubblewrap
Rust v1::available_backends() Ketersediaan host, kemampuan opsional, dan peringatan. Beberapa API eksekusi tidak dapat menggunakan setiap backend yang tercantum di sini.
Rust v1::probe() Pada Windows, permintaan akan mendapatkan tingkat isolasi ProcessContainer dan diagnostik kompatibilitas khusus untuk permintaan, tanpa membuat kontainer

Bidang yang tidak berlaku atau tidak dapat dideteksi mungkin hilang dari hasilnya. Discovery adalah pemeriksaan pertama yang berguna, tetapi tidak memvalidasi seluruh kebijakan Anda. Untuk memastikannya, buat permintaan yang Anda rencanakan untuk dijalankan dan konfirmasikan bahwa backend yang dipilih dapat memberlakukan setiap kontrol yang diperlukan.

Beberapa host memerlukan komponen tambahan atau penyiapan administrator sebelum backend berfungsi. Hasil penemuan dan kesalahan peluncuran dapat memberi tahu Anda apa yang hilang, tetapi itu tidak memberi aplikasi Anda atau agen pengodean Anda izin untuk mengubah host. Minta orang yang mengelola host untuk mengikuti langkah-langkah penyiapan backend yang didokumenkan.

Untuk Windows, lihat dukungan kebijakan versi OS. Versi Windows dapat didukung oleh MXC dan masih tidak memiliki fitur kebijakan tertentu, jadi periksa keduanya.

Periksa batasan yang dibutuhkan beban kerja Anda

Dua backend dapat menerima sintaks kebijakan yang sama dan masih menerapkannya secara berbeda. Sebelum Anda memilih backend, pertimbangkan area seperti:

Area Pertanyaan yang perlu diajukan
Files Dapatkah backend mengekspresikan pemberian baca, tulis, dan penolakan yang Anda butuhkan, termasuk yang tumpang tindih? Apakah ini berbagi file dengan host, memasangnya, atau menyalinnya?
Network Dapatkah itu memberlakukan model jaringan Anda, baik secara langsung maupun melalui proksi, termasuk aturan jaringan privat dan host-loopback?
Antarmuka Pengguna Bisakah ini menerapkan pembatasan jendela, clipboard, dan input yang Anda butuhkan?
Lifecycle Apakah ini menjalankan setiap perintah secara independen, atau dapatkah ini menjaga lingkungan di antara perintah? Apa yang disimpan setelah penghentian?
Mode Pembelajaran Apakah host mendukung pencatatan penolakan ProcessContainer? Jika tidak, alur kerja diagnosis apa yang disediakan backend?

Panduan MXC di GitHub mencantumkan kemampuan, build OS, dan persyaratan yang didukung untuk setiap backend.

Pilih backend berdasarkan kebutuhan Anda

Sebelum Anda memilih backend, tuliskan:

  • Sistem operasi host dan arsitektur prosesor yang didukung oleh aplikasi Anda.
  • Lingkungan tamu atau lingkungan alat yang diperlukan beban kerja.
  • Beban kerja memerlukan akses ke file, jaringan, UI, perangkat, dan alat host.
  • Apakah setiap perintah berjalan sendiri atau memerlukan status dari perintah sebelumnya.
  • Batas Anda untuk waktu startup, sumber daya, deployment, dan interaksi pengguna.
  • Seberapa kuat batas isolasi yang diperlukan beban kerja dan datanya.
  • Apakah backend dapat memberlakukan setiap kontrol kebijakan yang Anda butuhkan.

Kemudian uji setiap konfigurasi host yang Anda dukung, dengan tes positif dan negatif. Peluncuran yang berhasil hanya menunjukkan bahwa MXC menerima konfigurasi. Tes negatif, seperti upaya untuk menulis di luar path yang diizinkan, menunjukkan apakah pembatasan benar-benar berlaku.

Konten terkait

  • Terakhir diperbarui pada