Pengenalan LXD

Bab 28 menutup pembahasan virtualisasi penuh dengan konsekuensi yang cukup jelas, yaitu setiap VM KVM membawa kernelnya sendiri, lengkap dengan seluruh overhead boot dan resource yang menyertainya. Container Docker pada Bab 26 dan 27 berada di ujung yang berlawanan, sangat ringan karena berbagi kernel dengan host, tetapi dirancang untuk menjalankan satu proses aplikasi saja dan berhenti begitu proses tersebut selesai. Sysadmin di lapangan sering menghadapi kebutuhan yang tidak pas di kedua ujung ini. Bagaimana jika Developer membutuhkan lingkungan yang terasa seperti server Ubuntu penuh, lengkap dengan systemd, banyak service berjalan sekaligus, dan bisa di-SSH seperti VM biasa, tetapi tanpa harus menanggung overhead boot dan alokasi RAM sebesar KVM? Bab 29 menjawab kebutuhan ini melalui system container, yang dipraktikkan melalui LXD, sebuah container dan virtual machine manager resmi buatan Canonical yang menempatkan diri tepat di tengah antara Docker dan KVM. Bab ini dimulai dari konsep system container dan sejarah LXD, dilanjutkan instalasi dan inisialisasi di Ubuntu Server 26.04 LTS, praktik membuat serta mengelola container sistem pertama, hingga ditutup dengan panduan memilih antara LXD dan Docker sesuai dengan kebutuhan nyata di lapangan.

29.1 Konsep System Container: LXC dan LXD

Sebelum masuk ke instalasi, kita perlu memahami terlebih dahulu dari mana LXD berasal dan apa yang membedakan pendekatannya dari Docker yang sudah kita kuasai maupun KVM yang baru saja kita pelajari.

29.1.1 LXC sebagai Fondasi, LXD sebagai Lapisan Manajemen

LXC (Linux Containers) adalah userspace interface tingkat rendah yang memanfaatkan namespace dan cgroup milik kernel Linux, yaitu teknologi isolasi yang sama dengan yang mendasari Docker. Hanya saja LXC hadir lebih awal sejak sekitar tahun 2008, jauh sebelum Docker populer. Mengelola container melalui LXC secara langsung cukup merepotkan karena minimnya tooling manajemen tingkat tinggi, sehingga Canonical mengembangkan LXD pada tahun 2014 sebagai daemon dan REST API di atas LXC, menambahkan manajemen image, storage pool, networking, dan snapshot yang jauh lebih mudah digunakan melalui satu binary client bernama lxc.

Satu sumber kebingungan yang perlu diluruskan sejak awal, penamaan lxc pada LXD bukan LXC yang dijelaskan di atas. LXD justru memakai nama lxc untuk binary client-nya sendiri, terpisah total dari perintah lxc-create, lxc-start, dan sejenisnya milik LXC klasik. Sepanjang bab ini, setiap perintah lxc ... merujuk ke client LXD, bukan tooling LXC tingkat rendah yang jarang dipakai langsung lagi di lapangan.

29.1.2 Fork 2023: Incus sebagai Alternatif Komunitas

Pada Agustus 2023, Canonical mewajibkan setiap kontributor LXD menandatangani Contributor License Agreement (CLA) yang menyerahkan hak penuh atas kontribusi tersebut kepada Canonical, sekaligus membatasi keanggotaan tim inti LXD hanya untuk karyawan Canonical. Kebijakan ini memicu sebagian mantan anggota tim inti LXD, termasuk Stéphane Graber, untuk melakukan fork LXD menjadi proyek terpisah bernama Incus di bawah naungan Linux Containers, dikembangkan secara independen sebagai alternatif yang sepenuhnya dikelola komunitas.

Series ini secara konsisten memakai LXD, bukan Incus, karena LXD tetap menjadi produk resmi yang didukung penuh oleh Canonical dan terintegrasi erat dengan ekosistem Ubuntu, mulai dari channel snap LTS yang dibahas pada Bagian 29.2 hingga dukungan Ubuntu Pro. Bagi yang tertarik menjajaki alternatif community-driven, Incus layak dijadikan bahan eksplorasi lanjutan di luar cakupan bab ini, mengingat kedua proyek berbagi akar kode yang sama meski kini berkembang dengan arah teknis masing-masing.

29.1.3 System Container vs Application Container vs Virtual Machine

Istilah system container merujuk pada container yang mensimulasikan sistem operasi penuh, lengkap dengan init system, process manager, dan banyak proses yang berjalan bersamaan, mirip pengalaman VM tetapi tetap berbagi kernel dengan host. Hal ini berbeda dari application container seperti yang dihasilkan Docker, yang membungkus satu proses aplikasi saja dan dirancang untuk berhenti begitu proses tersebut selesai. Kedua pendekatan sebenarnya saling melengkapi, bukan bersaing secara mutlak. Menjalankan Docker di dalam system container LXD adalah pola yang lazim digunakan, sedangkan menjalankan LXD di dalam container Docker bukanlah pola yang didukung.

Satu detail keamanan yang layak dicatat sejak awal, sebagai bekal menuju Bagian VIII tentang hardening: container LXD berjalan secara unprivileged secara default, artinya rentang UID/GID di dalam container dipetakan ke rentang UID/GID yang tidak tumpang tindih di host melalui /etc/subuid dan /etc/subgid. Akun root di dalam container bukanlah root sungguhan di host, sehingga proses yang berhasil keluar dari isolasi container tetap terjebak sebagai user tidak berprivilege di sisi host. Hal ini menjadi lapisan pertahanan tambahan yang tidak dimiliki oleh container privileged model lama.

LXD sebenarnya bukan hanya pengelola system container. Tool yang sama juga dapat menjalankan virtual machine penuh melalui QEMU, yaitu mesin emulasi yang sama seperti yang sudah kita kenal pada Bagian 28.1.3. Hanya saja LXD mengelola siklus hidup VM tersebut langsung melalui API-nya sendiri tanpa melibatkan libvirt sama sekali, dan karena LXD didistribusikan sebagai snap dengan strict confinement, binary QEMU yang dibutuhkan ikut disalurkan lewat snap terpisah yang saling terhubung, bukan dependency paket apt biasa seperti pada instalasi KVM murni di Bab 28. Kemampuan VM ini dibahas sekilas pada Bagian 29.3, meskipun fokus utama bab ini tetap pada system container.

29.2 Instalasi dan Inisialisasi LXD di Ubuntu Server 26.04 LTS

Bagian ini memasang LXD lewat snap, menyiapkan akses non-root, lalu menginisialisasi storage dan networking dasar yang dibutuhkan sebelum container pertama dapat dibuat.

29.2.1 Instalasi LXD Lewat Snap

Berbeda dari Incus yang dibahas sekilas pada Bagian 29.1.2 dan tersedia sebagai paket apt native, LXD justru sudah lama ditarik Canonical dari repository apt biasa dan didistribusikan eksklusif lewat snap, mekanisme paket containerized milik Canonical sendiri yang memudahkan rilis lintas versi Ubuntu tanpa terikat siklus LTS.

Langkah Praktik

1. Ubuntu Server 26.04 LTS sudah menyertakan paket kecil lxd-installer secara default, berfungsi sebagai wrapper yang memicu instalasi snap LXD saat pertama kali dibutuhkan. Jika belum ada (misalnya pada instalasi minimal), pasang lebih dulu.

   sudo apt install lxd-installer

2. Panggil perintah lxc untuk pertama kali. lxd-installer akan mendeteksi bahwa snap LXD belum terpasang, lalu menampilkan pilihan channel (misalnya latest/stable atau 5.21/stable) sebelum menjalankan instalasi snap secara otomatis.

   lxc list

3. Sebagai alternatif yang lebih eksplisit dan lebih disarankan untuk server produksi karena tidak bergantung pada wizard interaktif, pasang snap LXD secara langsung dengan channel yang dipilih sendiri.

   sudo snap install lxd --channel=latest/stable

Verifikasi dan Troubleshooting

• Konfirmasikan snap dan versi LXD yang terpasang.

  snap list lxd
  lxd version

• Channel latest/stable saat ini mengarah ke seri LXD 5.21 sebagai LTS yang direkomendasikan Canonical untuk kebutuhan produksi. Seri 6.x (rilis terbaru saat ini di angka 6.9) berstatus feature release yang membawa fitur lebih baru namun secara eksplisit tidak direkomendasikan Canonical untuk lingkungan produksi, sehingga tetap pilih channel default kecuali memang butuh fitur spesifik dari seri 6.x dan siap menanggung risikonya.
• Jika perintah lxc atau lxd tidak dikenali setelah instalasi snap, buka sesi shell baru atau jalankan hash -r, karena PATH ke binary snap (/snap/bin) terkadang baru terbaca penuh di sesi shell berikutnya.

29.2.2 Akses Non-root Lewat Group lxd

Sama seperti pola akses non-root libvirt pada Bagian 28.2.3, LXD memakai group khusus bernama lxd agar operasional harian tidak perlu selalu diawali dengan sudo.

Langkah Praktik

1. Tambahkan user yang sedang aktif ke group lxd.

   sudo usermod -aG lxd $USER

2. Terapkan keanggotaan group baru ke sesi shell yang sedang berjalan tanpa logout penuh.

   newgrp lxd

Verifikasi dan Troubleshooting

• Pastikan perintah lxc dapat berjalan tanpa sudo.

  lxc list

• Perintah newgrp hanya memperbarui sesi terminal yang sedang aktif saat ini. Sesi SSH lain yang sudah terbuka sebelumnya, atau proses login berikutnya, baru sepenuhnya mengenali keanggotaan group baru setelah melakukan logout dan login ulang.

29.2.3 Inisialisasi Storage dan Networking dengan lxd init

LXD, sama seperti libvirt pada Bagian 28.2.4, membutuhkan storage pool untuk menyimpan disk instance dan network bridge untuk konektivitas. Namun, LXD menyatukan kedua konfigurasi awal ini dalam satu wizard interaktif bernama lxd init.

Langkah Praktik

1. Jalankan wizard inisialisasi.

   lxd init

2. Ikuti rangkaian pertanyaan interaktif. Berikut alur pertanyaan yang umum muncul beserta jawaban yang disarankan untuk single-server setup di server pembelajaran (perhatikan bahwa redaksi persis tiap pertanyaan bisa sedikit berbeda mengikuti versi LXD yang terpasang).

   Would you like to use clustering? (yes/no) [default=no]: no
   Do you want to configure a new storage pool? (yes/no) [default=yes]: yes
   Name of the new storage pool [default=default]: default
   Name of the storage backend to use (dir, lvm, zfs, btrfs, ceph) [default=zfs]: zfs
   Create a new ZFS pool? (yes/no) [default=yes]: yes
   Would you like to use an existing empty block device? (yes/no) [default=no]: no
   Size in GiB of the new loop device (1GiB minimum) [default=30GiB]: 30GiB
   Would you like to create a new local network bridge? (yes/no) [default=yes]: yes
   What should the new bridge be called? [default=lxdbr0]: lxdbr0
   What IPv4 address should be used? (CIDR subnet notation, "auto" or "none") [default=auto]: auto
   What IPv6 address should be used? (CIDR subnet notation, "auto" or "none") [default=auto]: auto
   Would you like the server to be available over the network? (yes/no) [default=no]: no
   Would you like stale cached images to be updated automatically? (yes/no) [default=yes]: yes
   Would you like a YAML "init" preseed to be printed? (yes/no) [default=no]: no

Beberapa jawaban di atas layak dijelaskan secara lebih detail. Backend storage zfs menjadi default karena mendukung snapshot dan clone yang jauh lebih cepat dibandingkan dengan backend dir yang sekadar menulis file biasa ke filesystem, mirip dengan pertimbangan yang sama saat memilih LVM untuk KVM pada Bab 7. Jika paket zfsutils-linux belum terpasang, LXD akan menawarkan instalasi otomatis melalui apt pada tahap ini, sehingga tidak perlu memasangnya secara manual terlebih dahulu. Bridge lxdbr0 yang terbentuk berfungsi persis seperti virbr0 pada Bagian 28.2.4, yaitu menjalankan dnsmasq untuk DHCP dan DNS internal, lalu meneruskan traffic keluar melalui NAT.

Verifikasi dan Troubleshooting

• Periksa storage pool dan network yang baru terbentuk.

  lxc storage list
  lxc network list

• Konfirmasikan bahwa bridge lxdbr0 sudah memperoleh alamat IP di sisi host.

  ip addr show lxdbr0

• Untuk kebutuhan lab atau eksperimen cepat yang tidak membutuhkan performa snapshot optimal, opsi lxd init --minimal melewati seluruh pertanyaan interaktif di atas dan langsung membuat storage pool berbasis dir serta bridge NAT dengan DHCP secara otomatis. Kelemahannya, backend dir tidak mendukung snapshot maupun clone cepat, sehingga tidak disarankan untuk latihan Bagian 29.3.5 nanti mengenai snapshot.
• Jika wizard sudah pernah dijalankan sebelumnya dan ingin diulang dari awal, jalankan kembali lxd init; LXD akan menampilkan pertanyaan tambahan terkait konfigurasi lama yang sudah ada, alih-alih menimpanya secara diam-diam.

29.3 Membuat dan Mengelola Container Sistem dengan LXD

Setelah storage dan network siap, bagian ini mempraktikkan siklus hidup lengkap sebuah system container, mulai dari peluncuran pertama hingga snapshot untuk rollback cepat.

29.3.1 Meluncurkan Container Pertama dengan lxc launch

LXD mengambil image sistem operasi dari remote image server yang sudah terkonfigurasi secara bawaan. Remote bernama ubuntu: mengarah ke image resmi Ubuntu yang dirilis langsung oleh Canonical, sedangkan remote images: menyediakan image komunitas untuk berbagai distribusi lain di luar Ubuntu, dikelola oleh proyek Linux Containers.

Langkah Praktik

1. Luncurkan container baru berbasis image resmi Ubuntu 26.04.

   lxc launch ubuntu:26.04 web01

2. Lihat daftar instance yang sedang berjalan, termasuk alamat IP yang diperoleh secara otomatis dari lxdbr0.

   lxc list

Verifikasi dan Troubleshooting

• Kolom STATE yang bernilai RUNNING beserta alamat IPv4 pada kolom IPV4 menandakan bahwa container sudah menyala penuh dan mendapat lease DHCP dari lxdbr0.
• Perintah lxc launch secara otomatis mengunduh image apabila belum tersedia secara lokal, sehingga peluncuran pertama sedikit lebih lama dibandingkan dengan peluncuran berikutnya yang sudah menggunakan cache image lokal.
• Perbedaan penting dibandingkan dengan virt-install pada Bagian 28.3.2, container di sini menyala langsung dalam hitungan detik tanpa perlu melewati proses instalasi Subiquity sama sekali, karena image yang diunduh sudah berupa root filesystem Ubuntu yang siap pakai, bukan installer ISO.

29.3.2 Masuk ke dalam Container dengan lxc exec

Langkah Praktik

1. Buka shell interaktif di dalam container.

   lxc exec web01 -- bash

2. Jalankan perintah tunggal tanpa masuk ke sesi interaktif, berguna untuk automasi.

   lxc exec web01 -- apt update
   lxc exec web01 -- apt install -y nginx

Verifikasi dan Troubleshooting

• Prompt shell yang berubah menandakan bahwa sesi sudah benar-benar berada di dalam container, bukan di host. Jalankan hostname untuk memastikannya.
• Tanda -- pada lxc exec web01 -- bash memisahkan flag milik lxc exec itu sendiri dari perintah yang hendak dijalankan di dalam container, mencegah flag seperti -y pada contoh apt install di atas salah ditafsirkan sebagai flag lxc exec.
• LXD juga menyediakan alias singkat lxc shell web01, setara dengan lxc exec web01 -- su -l, yang langsung masuk sebagai sesi login root lengkap dengan environment variable yang benar, sedikit lebih nyaman dibanding memanggil bash apa adanya untuk sesi interaktif sehari-hari.

29.3.3 Siklus Hidup Container

Langkah Praktik

1. Hentikan container secara graceful lalu periksa statusnya.

   lxc stop web01
   lxc list

2. Nyalakan kembali.

   lxc start web01

Verifikasi dan Troubleshooting

• Catatan jujur mengenai risiko: lxc delete tanpa --force menolak menghapus container yang sedang menyala sebagai pengaman bawaan. Setelah flag --force ditambahkan, penghapusan bersifat permanen dan langsung menghapus seluruh isi disk container dari storage pool, tanpa tahap konfirmasi tambahan maupun recycle bin.
• Container yang gagal berhenti secara graceful dalam waktu yang wajar (misalnya karena proses zombie di dalamnya) dapat dipaksa berhenti melalui lxc stop web01 --force, setara dengan mencabut kabel power, dengan risiko data belum tersimpan yang sama seperti virsh destroy pada Bagian 28.4.1.

29.3.4 Membatasi Resource Container

Tanpa batasan eksplisit, sebuah container secara teknis dapat menggunakan seluruh CPU dan RAM host yang tersedia. Menetapkan limit sejak awal mencegah satu container "nakal" menghabiskan resource container lain di host yang sama.

Langkah Praktik

1. Batasi container yang sudah ada ke maksimum 1 vCPU dan 512 MiB RAM.

   lxc config set web01 limits.cpu=1
   lxc config set web01 limits.memory=512MiB
   lxc restart web01

2. Atau, tetapkan limit sekaligus saat peluncuran container baru.

   lxc launch ubuntu:26.04 web02 --config limits.cpu=1 --config limits.memory=512MiB

Verifikasi dan Troubleshooting

• Tampilkan konfigurasi limit yang sedang aktif.

  lxc config show web01

• Verifikasi dari dalam container bahwa kernel benar-benar melihat batasan memory tersebut, bukan hanya tercatat di konfigurasi LXD.

  lxc exec web01 -- free -m

• Limit ini ditegakkan melalui cgroup v2 di sisi host, yaitu mekanisme kernel yang sama seperti yang mendasari limit resource pada Docker (Bab 26) dan migrasi cgroup v2 pada Bagian 5.5, bukan mekanisme eksklusif milik LXD.

29.3.5 Transfer File dan Snapshot

Selain lxc exec, LXD menyediakan cara memindahkan file secara langsung antara host dan container tanpa perlu SSH maupun shared folder, serta snapshot untuk rollback cepat sebelum perubahan berisiko, mirip fungsi snapshot LVM pada Bagian 7.2 dan snapshot QEMU pada Bagian 28.4.4.

Langkah Praktik

1. Salin file konfigurasi dari host ke dalam container.

   lxc file push /etc/hosts web01/tmp/hosts-host

2. Ambil file dari dalam container ke host.

   lxc file pull web01/etc/nginx/nginx.conf .

3. Buat snapshot sebelum melakukan perubahan berisiko, misalnya sebelum upgrade paket.

   lxc snapshot web01 sebelum-upgrade

4. Jika perubahan bermasalah, kembalikan container ke kondisi snapshot.

   lxc restore web01 sebelum-upgrade

5. Hapus snapshot yang sudah tidak diperlukan, memakai format nama_instance/nama_snapshot.

   lxc delete web01/sebelum-upgrade

Verifikasi dan Troubleshooting

• Lihat daftar snapshot yang tersimpan untuk sebuah container.

  lxc list web01

• Snapshot hanya berjalan cepat dan hemat storage jika backend storage pool menggunakan zfs atau btrfs, karena keduanya mendukung copy-on-write di level filesystem. Backend dir yang digunakan melalui opsi --minimal pada Bagian 29.2.3 tetap dapat membuat snapshot, tetapi dengan menyalin seluruh isi disk secara penuh setiap kali, sehingga jauh lebih lambat dan boros storage untuk container berukuran besar.
• Snapshot tersimpan di storage pool yang sama dengan container aslinya, persis seperti catatan pada Bagian 28.4.4 mengenai snapshot QEMU. Kegagalan disk fisik host tetap akan menghilangkan container beserta seluruh snapshot-nya sekaligus, sehingga snapshot bukan merupakan pengganti backup off-site yang akan dibahas pada Bab 40.

29.4 Kapan Memilih System Container (LXD) vs Docker

Setelah mempraktikkan Docker pada Bab 26 dan 27 serta LXD pada bab ini, pertanyaan yang paling sering muncul di lapangan adalah kapan sebaiknya memilih salah satu, mengingat keduanya sama-sama berbagi kernel dengan host dan jauh lebih ringan dibandingkan dengan VM KVM. Jawabannya bergantung pada bentuk workload, bukan sekadar preferensi teknologi.

Sebagai catatan dari lapangan, kombinasi keduanya justru lazim ditemui pada infrastruktur nyata. Sysadmin yang mengelola banyak klien VPS-style sering memakai LXD sebagai lapisan isolasi antar-tenant, sementara di dalam setiap container LXD tersebut, Developer tetap bebas menjalankan Docker Compose seperti yang sudah dipraktikkan pada Bab 27, karena kernel yang sama tetap mendukung nested container selama fitur yang dibutuhkan (seperti overlayfs) diizinkan oleh profil keamanan container induk. Pola sebaliknya, yaitu memasang LXD di dalam container Docker, bukan konfigurasi yang didukung maupun disarankan.

Sampai di sini, kita sudah memahami posisi LXD sebagai produk resmi Canonical untuk system container, mempraktikkan instalasi lewat snap dan inisialisasi storage/networking-nya di Ubuntu Server 26.04 LTS, hingga mengelola siklus hidup, resource limit, dan snapshot container sistem melalui perintah lxc. Bagian VII tentang virtualisasi dan containerization pun telah lengkap, mencakup tiga pendekatan dengan trade-off berbeda: Docker untuk aplikasi ephemeral, LXD untuk system container yang menyerupai VM ringan, dan KVM untuk isolasi penuh tingkat kernel. Bagian VIII berikutnya beralih fokus ke keamanan server, dimulai dari Bab 30 tentang hardening, tempat prinsip minimal attack surface yang sudah beberapa kali disinggung sepanjang series ini, termasuk model unprivileged container pada Bagian 29.1.3, dibahas secara menyeluruh dan sistematis.