Wadah Linux (LXC) di Red Hat / CentOS EL6 - lxc-create versus libvirt?

Sulit mencoba untuk tetap berada dalam rahmat baik Red Hat dan masih merencanakan umur panjang sistem ...

Saya telah menjadi pendukung Linux Containers (LXC) selama lebih dari setahun. Instalasi awal saya didasarkan pada informasi yang diperoleh dari tutorial online, seperti ini dan ini . Ini berpusat di sekitar lxc-create, lxc-start|stopdan lxc-destroymemerintahkan dan memodifikasi templat OpenVZ yang ada .

Ini bekerja dengan baik dan berjalan dengan gembira dalam produksi. Namun, saya membawa beberapa sistem tambahan dan memutuskan untuk memeriksa dokumentasi Red Hat saat ini mengenai kontainer di EL6. Saya terkejut melihat sikap resmi mereka tentang ini.

Di Apakah RHEL 6 menyediakan alat LXC yang diperlukan untuk menggunakan Linux Containers? , Red Hat menggambarkan LXC sebagai Pratinjau Teknologi dan menyarankan menggunakan libvirt untuk mengelola membuat dan mengelola wadah .

Namun Oracle menganjurkan teknik kontainerisasi yang sama sekali berbeda di Linux Unbreakable.

Tampaknya ada beberapa fungsi yang hilang dalam metode libvirt, tetapi pendekatan awal saya dengan perintah lxc- * adalah sedikit proses manual ... Saya tidak bisa mengatakan apa yang benar atau cara "diterima" untuk mengelola wadah pada EL6 .

• Apa kebijaksanaan konvensional mengenai sistem seperti LXC dan RHEL saat ini?
• Bagaimana Anda menerapkannya di organisasi Anda?
• Apakah ada keuntungan dari satu pendekatan versus yang lain?
• Bisakah ini hidup berdampingan?

Apa kebijaksanaan konvensional mengenai sistem seperti LXC dan RHEL saat ini?

Secara pribadi, saya menemukan pengaturan saat ini agak kurang. LXC tampaknya lebih di garis depan - tentu lebih terawat.

Bagaimana Anda menerapkannya?

Dalam hal menawarkannya sebagai opsi virtualisasi, saya tidak. Saya menemukan pengaturan teknologi saat ini kurang.

• Tidak ada ruang nama pengguna.
• Mountpoints tertentu tidak diketahui namespace (cgroups, selinux)
• Nilai-nilai di / proc adalah sistem global yang menyesatkan yang tidak memperhitungkan partisi sumber daya dalam ruang nama.
• Istirahat audit.

Saya menemukan alat yang sangat bagus untuk penahanan level aplikasi. Kami menggunakan ruang nama dan grup secara langsung untuk memuat sumber daya jaringan dan IPC untuk aplikasi web yang dijalankan pengguna tertentu. Kami menyediakan antarmuka kami sendiri untuk mengendalikannya. Di RHEL7 saya sedang mempertimbangkan untuk memindahkan fungsi ini ke libvirt-lxcsebagai revisi yang lebih baru libvirtmendukung konsep ACL pengguna.

Untuk virtualisasi dalam hal sistem sepenuhnya diinisialisasi, saya menunggu wee apa yang ditawarkan di RHEL7, tetapi dalam semua kejujuran, saya merasa kami mungkin hanya melihat solusi yang cukup baik setelah kami pada rilis kecil kemudian RHEL7 dan kemudian mungkin hanya pada kondisi pratinjau teknologi.

Mengawasi Anda pada systemd-nspawnsesuatu memberitahu saya dalam 18 bulan ke depan atau lebih mungkin mengambil tempat adalah alat terbaik untuk melakukan sepenuhnya virtualisasi yang terkandung linux, baik itu penulis sistem membuat jelas itu tidak aman sekarang! Saya tidak akan terkejut jika libvirttetes libvirt-lxcakhirnya dan hanya menawarkan pembungkus systemd-nspawndengan irisan systemd didefinisikan.

Juga, berhati-hatilah bahwa ada banyak pembicaraan selama 6 bulan terakhir dalam hal menerapkan kembali cgroup sebagai antarmuka pemrogram kernel daripada antarmuka sistem file (mungkin menggunakan netlink atau sesuatu, belum diperiksa) sehingga systemd harus sangat panas pada ekor untuk memperbaikinya dengan sangat cepat.

Adakah keuntungan dari satu pendekatan versus yang lain?

Saya pikir opsi LXC (bukan libvirt-lxc) lebih baik dipertahankan. Setelah membaca libvirt-lxckode sumber, rasanya terburu-buru. LXC tradisional tentu memiliki fitur-fitur baru yang telah diuji lebih baik. Keduanya memerlukan tingkat kompatibilitas oleh sistem init yang dijalankan di dalamnya, tetapi saya menduga Anda akan menemukan LXC sedikit lebih "turn-key" daripada libvirt-lxcopsi khususnya dalam hal membuat distro untuk bekerja di dalamnya.

Bisakah ini hidup berdampingan?

Tentu, ingat bahwa untuk semua maksud dan tujuan, keduanya melakukan hal yang sama. Mengatur ruang nama, kelompok, dan titik pemasangan. Semua primitif ditangani oleh kernel itu sendiri. Kedua lxcimplementasi hanya menawarkan mekanisme untuk berinteraksi dengan opsi kernel yang tersedia.

Red Hat membuat dorongan kontainerisasi besar . Mereka sedang membangun seluruh produk baru, Red Hat Enterprise Linux Atom Host , di sekitarnya.

Untuk pendekatan yang kurang radikal, lihat Panduan Manajemen Sumber Daya beta dan Linux Containers RHEL7 beta mereka ; Anda akan melihatnya mendorong libvirt-lxc dan tidak menyebutkan alat lxc.

Eksekusi lxc- * dikemas dalam paket lxc dalam EPEL . Namun itu adalah rilis "dukungan jangka panjang" lama. Anda bahkan tidak memiliki opsi "-f" di lxc-ls. Saya cukup menginstal Ubuntu untuk host LXC saya.

Cara RHEL untuk mengelola LXC tampaknya melalui libvirt-lxc tetapi tampaknya sudah usang .

Tercatat bahwa Ubuntu mendukung banyak pengembangan lxc / lxd baru sementara Redhat berfokus pada KVM dan buruh pelabuhan.