Environment Isolation

Setiap proyek membawa dunianya sendiri: proyek lama masih butuh Python 3.10, proyek baru menuntut pustaka versi terbaru, dan aplikasi produksi punya kredensial yang tidak boleh beredar. Bila semuanya dicampur di satu sistem, muncul keluhan klasik: “di komputer saya bisa jalan”. Penyakit ini disembuhkan dengan isolasi — memberi tiap proyek ruang versi dan konfigurasi sendiri sehingga perubahan di satu proyek tidak merusak yang lain. Chapter ini memetakan tekniknya pada tiga lapis: bahasa, variabel, dan sistem.

Tiga Lapis Isolasi #

Prinsip pemilihannya sederhana: pakai lapis paling rendah yang menyelesaikan masalah. Versi pustaka Python yang berbeda tidak butuh container — cukup virtual environment; sebaliknya, aplikasi yang hanya jalan di distro lama tidak tertolong oleh venv mana pun. Kita mulai dari lapis pertama karena paling sering dipakai sehari-hari.

Isolasi Level Bahasa: virtualenv Python #

venv membuat salinan tipis interpreter Python di dalam folder proyek, lengkap dengan direktori site-packages sendiri, sehingga pustaka di dalamnya tidak pernah bertabrakan dengan pustaka sistem. Manajer versi bahasa lain serupa — dibahas di chapter Node.js Development dan Rust Development . Sistem latihan ini berbasis Debian, dan Debian memecah Python menjadi banyak package; kita akan menabraknya langsung:

python3 -m venv .venv 2>&1

Output yang Dihasilkan:

The virtual environment was not created successfully because ensurepip is not
available.  On Debian/Ubuntu systems, you need to install the python3-venv
package using the following command.

    apt install python3.13-venv

You may need to use sudo with that command.  After installing the python3-venv
package, recreate your virtual environment.

Failing command: /home/budi/.venv/bin/python3

Pesan kegagalan ini justru informatif: modul venv ada, tetapi ensurepip — penyalin pip ke environment baru — dikemas Debian terpisah. Pada komputer sendiri obatnya satu perintah, sudo apt install python3-venv (nama tepatnya mengikuti versi Python). Karena sistem latihan tidak punya root, kita lanjut dengan --without-pip:

rm -rf .venv
python3 -m venv --without-pip .venv
.venv/bin/python --version
.venv/bin/python -c "import sys; print(sys.prefix)"
python3 -c "import sys; print(sys.prefix)"

Output yang Dihasilkan:

Python 3.13.5
/home/budi/.venv
/usr

Baris-barisnya menunjukkan mekanisme isolasinya:

1. rm -rf .venv: membersihkan sisa percobaan gagal sebelumnya agar blok selalu mulai dari keadaan kosong.
2. python3 -m venv --without-pip .venv: membuat environment di folder .venv — path /home/budi pada output mengikuti nama user di mesin masing-masing.
3. Dua kueri sys.prefix: interpreter di dalam environment melaporkan prefix miliknya (/home/budi/.venv), sedangkan interpreter sistem tetap melaporkan /usr — bukti pustaka keduanya terpisah.

Skrip activate (source .venv/bin/activate) sebenarnya hanya memanipulasi PATH supaya python menunjuk ke .venv/bin. Detail alurnya dibedah di chapter Python Development .

Variabel per Proyek: File .env #

Variabel lingkungan (DATABASE_URL, mode aplikasi, batas koneksi) sering didefinisikan lewat export di ~/.bashrc. Akibatnya semua proyek berbagi satu papan nilai global: ganti nilai untuk proyek A, proyek B ikut rusak. Pola yang lebih sehat menyimpan variabel sebagai file .env di akar tiap proyek:

cat > .env << 'AKHIR'
# Konfigurasi proyek latihan
APP_MODE=produksi
DATABASE_URL=postgresql://budi@localhost/latihan
MAX_KONEKSI=10
AKHIR
export $(grep -v '^#' .env | xargs)
printf 'APP_MODE=%s\n' "$APP_MODE"
printf 'DATABASE_URL=%s\n' "$DATABASE_URL"
printf 'MAX_KONEKSI=%s\n' "$MAX_KONEKSI"

Output yang Dihasilkan:

APP_MODE=produksi
DATABASE_URL=postgresql://budi@localhost/latihan
MAX_KONEKSI=10

Cara kerjanya:

1. cat > .env << 'AKHIR': menulis file konfigurasi berisi komentar dan tiga variabel.
2. grep -v '^#' .env | xargs: grep -v membuang baris komentar, xargs merangkai sisanya menjadi satu baris APP_MODE=produksi DATABASE_URL=... MAX_KONEKSI=10.
3. export $(...): substitusi perintah menempelkan baris itu ke export, sehingga ketiga variabel hidup di lingkungan proses berikutnya — printf membuktikannya.

Alat direnv mengotomatiskan pola ini: file .envrc di akar proyek dimuat saat kita masuk folder itu dan dibongkar saat keluar, setelah satu kali direnv allow.

Isolasi Level Sistem: chroot dan container #

Terkadang yang harus diisolasi bukan pustaka satu bahasa, melainkan sistem operasinya. Alat tertuanya adalah chroot: syscall yang memindahkan akar direktori sebuah proses ke folder tertentu sehingga proses itu tidak melihat filesystem asli; rinciannya ada di chroot(2) . Container melangkah lebih jauh: chroot digabung namespace (isolasi pandangan proses, jaringan, mount) dan cgroup (pembatasan resource), lalu dikemas menjadi image berisi aplikasi beserta seluruh dependensinya — dua proyek pun bisa memakai distro berbeda berdampingan di satu host. Perbincangan lengkapnya menjadi pembuka section Virtualization dan Containers ; di sini cukup satu kesimpulan: container adalah jawaban isolasi ketika perbedaan proyek sudah menyangkut level sistem.

Dengan tiga lapis ini, tiap proyek kini punya dunianya sendiri. Pekerjaan berikutnya adalah mengotomatiskan langkah-langkah di dalamnya — mengompilasi, menguji, membersihkan — tanpa menghafal urutan perintah manual. Itulah wilayah make, chapter berikutnya.