Alat-alat Ekosistem Docker

Perintah docker CLI resmi sudah cukup untuk menjalankan hampir semua kebutuhan sehari-hari, tapi begitu jumlah container bertambah banyak, Sysadmin/DevOps Engineer maupun Developer sering butuh cara yang lebih cepat untuk memantau, membersihkan, dan mengelola resource tersebut. Di sinilah ekosistem tool pihak ketiga di sekitar Docker berperan: ada yang menyediakan antarmuka visual berbasis web, ada yang berbentuk dashboard interaktif di terminal, ada yang khusus membedah isi layer image untuk mencari pemborosan ukuran, ada yang mengotomasi update container, dan ada yang menyatukan seluruh environment development ke dalam container supaya konsisten di semua mesin. Bab ini membahas lima tool populer tersebut: Portainer, lazydocker dan ctop, Dive, Watchtower, serta Dev Containers di VS Code, lengkap dengan cara instalasi, penggunaan dasar, dan catatan risiko masing-masing.

44.1 Portainer: GUI Management untuk Docker

Portainer adalah antarmuka web yang menampilkan container, image, volume, dan network dalam bentuk dashboard visual, sehingga Sysadmin/DevOps Engineer yang baru terjun ke sebuah host Docker bisa langsung melihat kondisi keseluruhan sistem tanpa perlu mengetik serangkaian perintah docker ps, docker inspect, atau docker logs satu per satu. Tool ini juga membantu Developer yang belum terlalu hafal CLI Docker untuk tetap bisa menjalankan, menghentikan, atau melihat log container lewat klik di browser.

44.1.1 Instalasi Portainer CE dengan Docker

Portainer Community Edition (CE) didistribusikan sebagai image Docker resmi, sehingga cara paling praktis menjalankannya adalah lewat container itu sendiri. Buat dulu named volume untuk menyimpan data konfigurasi Portainer supaya tidak hilang saat container-nya diperbarui.

docker volume create portainer_data

Jalankan container Portainer dengan mem-mount socket Docker daemon, supaya Portainer bisa membaca dan mengendalikan seluruh resource Docker di host tersebut.

docker run -d -p 8000:8000 -p 9443:9443 \
  --name portainer --restart=always \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v portainer_data:/data \
  portainer/portainer-ce:lts

Port 9443 melayani antarmuka web lewat HTTPS, sedangkan port 8000 dipakai untuk fitur tunnel server saat menghubungkan Portainer ke Edge Agent di environment lain. Setelah container berjalan, buka https://localhost:9443 (ganti localhost dengan alamat host yang sesuai) untuk membuat akun admin pertama kali. Perlu diperhatikan, mem-mount /var/run/docker.sock ke dalam container berarti memberi Portainer akses penuh setara root terhadap Docker daemon di host, jadi batasi akses jaringan ke port Portainer hanya untuk pengguna yang memang berwenang, terutama di server production yang terekspos ke internet.

44.1.2 Mengelola Container Lewat Portainer

Setelah login, Portainer menampilkan Environment yang mewakili satu Docker daemon (bisa host lokal atau remote lewat Docker API). Dari dashboard environment, kita bisa melihat ringkasan jumlah container yang running dan stopped, total image, volume, serta network, lalu masuk ke menu Containers untuk start, stop, restart, atau menghapus container langsung lewat tombol tanpa mengetik perintah CLI.

Menu Stacks di Portainer menerima file docker-compose.yml langsung lewat editor bawaan atau upload file, lalu men-deploy-nya sebagai satu kesatuan stack, setara dengan menjalankan docker compose up -d tapi lewat antarmuka web. Di lapangan, kombinasi ini sering dipakai tim kecil yang ingin memberi anggota non-teknis akses terbatas untuk memantau status aplikasi tanpa perlu diajari perintah Docker CLI, memakai fitur Users dan Role-Based Access Control di Portainer untuk membatasi environment atau stack mana saja yang boleh mereka lihat dan ubah.

Verifikasi Portainer sudah membaca kondisi Docker daemon dengan benar dengan membandingkan jumlah container yang tampil di dashboard dengan hasil perintah CLI biasa.

docker ps -a --format '{{.Names}}: {{.Status}}'

Kalau Portainer gagal terhubung atau menampilkan data kosong padahal container jelas berjalan, penyebab paling umum adalah mount socket /var/run/docker.sock yang tidak sesuai path aslinya di host, atau permission socket tersebut yang tidak bisa diakses user di dalam container Portainer.

44.2 Lazydocker dan ctop: Monitoring Berbasis Terminal

Tidak semua Sysadmin/DevOps Engineer punya akses browser langsung ke server, terutama saat bekerja lewat koneksi SSH ke mesin remote. Untuk kondisi seperti ini, dashboard berbasis terminal seperti lazydocker dan ctop jadi alternatif yang lebih ringan dibanding Portainer, karena berjalan langsung di terminal tanpa perlu membuka port tambahan atau browser sama sekali.

44.2.1 Instalasi dan Penggunaan Lazydocker

Lazydocker adalah antarmuka teks interaktif yang merangkum status container, image, volume, dan log ke dalam satu layar, dengan navigasi memakai keyboard maupun mouse. Instalasi paling cepat di Linux atau macOS memakai script resmi berikut.

curl https://raw.githubusercontent.com/jesseduffield/lazydocker/master/scripts/install_update_linux.sh | bash

Cara lain yang lebih transparan (tanpa menjalankan script dari internet langsung) adalah lewat Homebrew di macOS atau Linux yang sudah terpasang brew.

brew install jesseduffield/lazydocker/lazydocker

Jalankan lazydocker langsung dari terminal setelah terpasang.

lazydocker

Layar lazydocker terbagi jadi beberapa panel: daftar container, daftar image, daftar volume, dan panel log/detail di sisi kanan. Pindah antar container dengan tombol panah, lalu tekan huruf tertentu (tampil sebagai petunjuk di bagian bawah layar) untuk restart, stop, atau exec ke dalam container yang sedang dipilih, tanpa perlu mengetik nama container secara manual seperti pada perintah docker exec biasa. Bagi Developer yang bekerja dengan banyak service lewat Docker Compose di local development, lazydocker sangat membantu untuk memantau log beberapa service sekaligus tanpa membuka banyak terminal terpisah untuk masing-masing docker compose logs -f.

44.2.2 Instalasi dan Penggunaan ctop

ctop punya fokus lebih sempit dibanding lazydocker: menampilkan metrik resource (CPU, memory, network, disk I/O) tiap container secara real-time dalam tampilan mirip perintah top bawaan Linux. Instalasi di Linux bisa memakai binary langsung dari rilis resmi.

sudo wget https://github.com/bcicen/ctop/releases/download/v0.7.7/ctop-0.7.7-linux-amd64 \
  -O /usr/local/bin/ctop
sudo chmod +x /usr/local/bin/ctop

Jalankan ctop tanpa argumen tambahan; tool ini otomatis membaca Docker daemon lewat socket default.

ctop

Tekan s untuk memilih kolom pengurutan (misalnya berdasarkan pemakaian CPU atau memory tertinggi), r untuk membalik urutan, dan o untuk masuk ke tampilan detail satu container. Di lapangan, ctop sering jadi pilihan pertama saat Sysadmin/DevOps Engineer perlu cepat mengecek container mana yang tiba-tiba menghabiskan CPU saat alert monitoring berbunyi, karena tampilannya jauh lebih ringkas dibanding scroll output docker stats biasa untuk host dengan puluhan container. Perlu dicatat, proyek ctop sudah jarang menerima update rilis baru, jadi selalu periksa halaman rilis resminya di GitHub untuk memastikan versi yang dipasang masih kompatibel dengan versi Docker Engine terbaru sebelum dipasang di server production.

44.3 Dive: Analisis Layer Image

Ukuran image yang membengkak sering kali bukan karena aplikasinya besar, melainkan karena ada file sementara, cache package manager, atau dependency development yang ikut tersimpan di salah satu layer padahal sudah dihapus di layer berikutnya. Masalah ini sulit terlihat hanya dari docker images yang cuma menampilkan ukuran total; di sinilah Dive berperan sebagai tool khusus untuk membedah isi tiap layer image satu per satu.

44.3.1 Instalasi dan Menjalankan Dive

Di Linux berbasis Debian/Ubuntu, pasang Dive lewat paket .deb dari halaman rilis resminya.

DIVE_VERSION=$(curl -sL "https://api.github.com/repos/wagoodman/dive/releases/latest" | grep '"tag_name":' | sed -E 's/.*"v([^"]+)".*/\1/')
curl -fOL "https://github.com/wagoodman/dive/releases/download/v${DIVE_VERSION}/dive_${DIVE_VERSION}_linux_amd64.deb"
sudo apt install ./dive_${DIVE_VERSION}_linux_amd64.deb

Di macOS, instalasi lebih sederhana lewat Homebrew.

brew install dive

Analisis sebuah image yang sudah ada di local dengan menyebut nama dan tag-nya langsung.

dive nginx:1.27-alpine

Dive juga bisa langsung membangun image dari Dockerfile sekaligus menganalisisnya dalam satu perintah, cocok dipakai berulang kali saat sedang mengoptimasi Dockerfile.

dive build -t aplikasi-web:dev .

44.3.2 Membaca Efficiency Score dan Wasted Space

Tampilan Dive terbagi dua panel utama: panel kiri berisi daftar layer beserta perintah Dockerfile yang menghasilkannya, dan panel kanan berisi struktur file di dalam layer yang sedang dipilih, dengan tanda warna untuk file yang ditambahkan, diubah, atau dihapus dibanding layer sebelumnya. Di bagian bawah layar, Dive menampilkan efficiency score dalam persentase dan estimasi wasted space, yaitu total ukuran file yang sebenarnya sudah tidak terpakai di layer akhir tapi masih memakan ruang karena pernah ditulis di layer sebelumnya.

Pitfall yang paling sering ditemukan lewat Dive adalah pola RUN apt-get update && apt-get install ... yang dipisah jadi beberapa instruksi RUN berbeda, sehingga cache package manager tetap tersimpan permanen di layer awal meski instruksi RUN apt-get clean dijalankan belakangan di layer terpisah; solusinya adalah menggabungkan langkah install dan pembersihan cache dalam satu instruksi RUN yang sama supaya keduanya berada di layer yang sama pula. Untuk kebutuhan otomasi di pipeline CI/CD, jalankan Dive dalam mode non-interaktif lewat environment variable CI, yang membuat Dive keluar dengan exit code bukan nol kalau efficiency score berada di bawah ambang batas yang ditentukan, alih-alih menampilkan antarmuka interaktif yang butuh input manual.

CI=true dive aplikasi-web:dev

Exit code bukan nol dari perintah di atas bisa langsung dipakai sebagai syarat gagal (fail) pada tahap build pipeline CI/CD, sehingga image yang boros ruang tidak lolos ke tahap deployment tanpa perlu ada yang meninjau hasilnya secara manual satu per satu.

44.4 Watchtower: Automated Container Updates

Watchtower memantau image yang sedang dipakai container yang berjalan, menariknya ulang secara berkala, lalu membuat ulang container tersebut secara otomatis kalau ternyata ada versi image yang lebih baru di registry. Tool ini populer di kalangan Developer yang menjalankan homelab atau environment development pribadi, karena menghilangkan kebutuhan menjalankan docker compose pull dan docker compose up -d secara manual setiap kali ada update image.

44.4.1 Menjalankan Watchtower

Jalankan Watchtower sebagai container biasa dengan mem-mount socket Docker daemon, sama seperti Portainer, karena Watchtower perlu akses untuk memeriksa dan mengganti container lain.

docker run -d --name watchtower \
  -v /var/run/docker.sock:/var/run/docker.sock \
  containrrr/watchtower

Tanpa argumen tambahan, Watchtower memantau seluruh container yang berjalan di host tersebut. Untuk membatasi pemantauan hanya ke container tertentu, sebutkan nama containernya sebagai argumen tambahan setelah nama image.

docker run -d --name watchtower \
  -v /var/run/docker.sock:/var/run/docker.sock \
  containrrr/watchtower web-app db-postgres

44.4.2 Konfigurasi Interval, Cleanup, dan Notifikasi

Secara default, Watchtower memeriksa image baru setiap 86400 detik (24 jam) sekali. Ubah interval ini lewat flag --interval kalau pemeriksaan perlu dilakukan lebih sering.

docker run -d --name watchtower \
  -v /var/run/docker.sock:/var/run/docker.sock \
  containrrr/watchtower --interval 3600

Tambahkan flag --cleanup supaya Watchtower otomatis menghapus image lama yang sudah tidak dipakai container manapun setelah proses update selesai, mencegah disk penuh oleh tumpukan image versi lama yang menganggur.

docker run -d --name watchtower \
  -v /var/run/docker.sock:/var/run/docker.sock \
  containrrr/watchtower --cleanup --interval 3600

Untuk menguji konfigurasi tanpa menunggu jadwal interval berjalan, gunakan flag --run-once yang langsung memeriksa dan mengupdate container satu kali lalu keluar.

docker run --rm \
  -v /var/run/docker.sock:/var/run/docker.sock \
  containrrr/watchtower --run-once web-app

Sebelum memasang Watchtower di production, pertimbangkan risikonya dengan jujur: update otomatis berarti container bisa berganti versi kapan saja tanpa proses review atau testing terlebih dahulu, yang berbahaya kalau image baru ternyata membawa breaking change. Karena itu Watchtower jauh lebih cocok dipakai di environment development, homelab, atau service internal yang toleran terhadap downtime singkat, dibanding service production kritikal yang idealnya tetap memakai pipeline CI/CD dengan tahap testing eksplisit sebelum image baru di-deploy. Perlu dicatat juga, repository resmi Watchtower (containrrr/watchtower) sudah diarsipkan pemiliknya dan dinyatakan tidak lagi dikelola aktif; image lama di Docker Hub tetap bisa ditarik dan dipakai seperti contoh di atas, tapi periksa dulu status terkini proyek ini atau pertimbangkan alternatif yang masih aktif dikembangkan sebelum mengandalkannya untuk kebutuhan jangka panjang.

44.5 Dev Containers: Development Environment Terintegrasi dengan VS Code

Masalah klasik "di laptop saya jalan, tapi di laptop teman satu tim malah error" sering muncul karena perbedaan versi bahasa pemrograman, library sistem, atau tool CLI yang terpasang di masing-masing mesin Developer. Dev Containers menjawab masalah ini dengan menjalankan seluruh environment development, mulai dari runtime bahasa pemrograman sampai extension editor, di dalam container yang didefinisikan lewat satu file konfigurasi yang di-commit bersama source code.

44.5.1 Struktur devcontainer.json

Konfigurasi Dev Containers disimpan di file .devcontainer/devcontainer.json pada root project. Contoh berikut mendefinisikan environment development untuk project Node.js memakai image resmi sebagai base, sekaligus mengaktifkan sebuah extension VS Code secara otomatis.

{
  "name": "aplikasi-node-dev",
  "image": "node:20-bookworm",
  "forwardPorts": [3000],
  "postCreateCommand": "npm install",
  "customizations": {
    "vscode": {
      "extensions": ["dbaeumer.vscode-eslint"]
    }
  },
  "remoteUser": "node"
}

Properti image menunjuk image dasar yang dipakai (bisa diganti dengan properti build berisi dockerfile dan context kalau environment butuh Dockerfile custom, bukan sekadar image jadi). Properti forwardPorts otomatis meneruskan port dari dalam container ke mesin host, sementara postCreateCommand menjalankan perintah sekali saja setelah container pertama kali dibuat, cocok untuk instalasi dependency seperti npm install di atas. Properti customizations.vscode.extensions memastikan extension yang relevan (misalnya linter atau formatter) otomatis terpasang begitu VS Code terhubung ke container, tanpa perlu Developer lain memasangnya manual satu per satu.

Kebutuhan tool tambahan seperti Git, Docker CLI di dalam container, atau runtime bahasa lain bisa ditambahkan lewat properti features, yang mengambil komponen siap pakai dari registry Dev Container Features tanpa perlu menulis instruksi instalasi manual di Dockerfile.

{
  "name": "aplikasi-node-dev",
  "image": "node:20-bookworm",
  "features": {
    "ghcr.io/devcontainers/features/docker-in-docker:2": {}
  }
}

44.5.2 Membuka Project dengan Dev Containers

Pasang extension resmi Dev Containers (penerbit Microsoft) dari VS Code Marketplace terlebih dahulu. Setelah file .devcontainer/devcontainer.json tersedia di root project, buka Command Palette (Ctrl+Shift+P atau Cmd+Shift+P di macOS) lalu jalankan perintah Dev Containers: Reopen in Container. VS Code akan membangun (atau menarik) image sesuai konfigurasi, menjalankan container tersebut, lalu menyambungkan jendela editor langsung ke dalamnya, termasuk terminal terintegrasi yang berjalan di dalam container, bukan di mesin host.

Verifikasi environment sudah berjalan di dalam container dengan memeriksa versi runtime lewat terminal VS Code yang baru tersambung.

node --version
which npm

Kalau hasilnya menunjukkan versi Node.js sesuai yang didefinisikan di image pada devcontainer.json, bukan versi yang mungkin terpasang berbeda di mesin host, berarti konfigurasi Dev Containers sudah bekerja dengan benar. Selain lewat VS Code, konfigurasi devcontainer.json yang sama juga bisa dijalankan lewat devcontainer CLI (paket @devcontainers/cli) di pipeline CI/CD, sehingga environment testing di CI benar-benar identik dengan environment development di laptop masing-masing anggota tim, menghindari celah "environment beda" yang sering jadi sumber bug yang sulit direproduksi.