Meracik Stack Docker + Colima

Saya pasang stack dev/self-hosting di Mac Studio saya: nginx, MariaDB, dan PostgreSQL, semuanya jalan sebagai container lewat Docker Compose. Awalnya semua lancar pakai Docker Desktop, sampai saya iseng cek Activity Monitor dan kaget sendiri — VM default Docker Desktop nyedot sekitar 8GB RAM, plus GUI Electron-nya sekitar 1GB lagi. Padahal container yang saya jalankan sendiri, kalau ditotal, cuma butuh sekitar 150MB. Ada gap besar antara "ongkos menjalankan Docker" dan "ongkos aplikasi yang sebenarnya butuh Docker".

Root cause: bayar mahal buat GUI yang gak dipakai

Docker Desktop itu dirancang buat pengalaman desktop — ada GUI, ada VM yang di-provision besar dari awal biar "aman" buat berbagai skenario. Tapi saya gak butuh GUI-nya sama sekali, semua saya kelola dari terminal. Jadi sebagian besar RAM itu terbuang buat komponen yang gak pernah saya sentuh.

Solusi: pindah ke Colima

Saya ganti ke Colima — ini cuma Docker engine tanpa GUI, jalan di atas VM ringan tipe vz dengan virtiofs buat filesystem sharing yang lebih cepat dibanding cara lama. Saya konfigurasi VM-nya pas-pasan sesuai kebutuhan nyata: 2 CPU, 1.5GB RAM, 30GB disk. Hasilnya total pemakaian RAM yang terkait Docker turun dari sekitar 7.9GB jadi sekitar 2.5GB — hemat lebih dari separuh, tanpa kehilangan fungsi apa pun karena command docker dan docker compose tetap sama persis.

colima start --cpu 2 --memory 1.5 --disk 30 --vm-type vz --mount-type virtiofs

Sambil beres-beres, saya audit keamanan stack-nya

Ganti runtime jadi momen bagus buat audit menyeluruh, karena saya harus bikin ulang volume dan konfigurasi dari nol. Saya lakukan hardening di lima sisi:

  • Kredensial: semua password root/superuser database saya rotate ke nilai acak yang panjang, disimpan di file environment dengan permission ketat (chmod 600), bukan nongkrong di command history atau compose file.
  • Least privilege: aplikasi saya kasih user database terbatas, bukan root — kalau ada bug di aplikasi, blast radius-nya kecil.
  • Exposure jaringan: ini yang paling bikin deg-degan. Saya cek ulang dan ternyata port database bisa diakses dari perangkat lain di jaringan WiFi rumah, bukan cuma dari mesin itu sendiri. Celah nyata yang ternyata gampang banget kelewat kalau cuma modal docker run -p 5432:5432 tanpa mikir. Saya bind ulang semua port database cuma ke localhost.
  • Auth di level database: akses root MariaDB yang tadinya wildcard ke semua host saya hapus, dan konfigurasi auth PostgreSQL saya ganti supaya cuma percaya koneksi dari localhost dan subnet docker sendiri.
  • Supply chain & resource: semua image saya pin ke versi exact, bukan latest — biar gak ada update mengejutkan yang bikin behavior berubah diam-diam. Tiap service juga saya kasih limit CPU/memory, dan saya bikin backup harian otomatis ke folder lokal dengan retensi 14 hari.

Satu keputusan yang sengaja saya ambil: nginx saya biarkan tanpa TLS, karena tugasnya cuma serve satu halaman statis. Risikonya rendah dibanding kerumitan yang ditambahkan kalau saya urus sertifikat buat kasus sesederhana itu — trade-off yang menurut saya masuk akal, bukan kelalaian.

Bonus temuan yang gak terduga

Pas lagi ngecek pengaturan sistem buat audit ini, saya sadar screensaver idle timer di macOS ternyata belum pernah di-set. Saya kira kebijakan "lock setelah screensaver nyala" itu aktif, padahal gak pernah kepicu sama sekali karena screensaver-nya sendiri gak pernah jalan. Baru ketahuan pas iseng dicek — pengingat bagus kalau asumsi soal keamanan itu perlu diverifikasi, bukan cuma diasumsikan benar.

Takeaway

Dua pelajaran dari sesi ini: pertama, tooling default sering dioptimasi buat kasus umum, bukan buat setup spesifik saya — cek asumsi resource-nya sebelum terima begitu saja. Kedua, "port terbuka di localhost" itu gampang salah kira jadi "port cuma bisa diakses dari mesin ini", padahal kalau bind-nya ke semua interface, siapa saja di jaringan yang sama bisa nyambung. Audit berkala, walau kelihatan repetitif, tetap perlu.