Sepanjang enam chapter sebelumnya kita membangun pemahaman konsep demi konsep — dari definisi Docker, masalah yang diselesaikannya, perbandingan dengan virtual machine, arsitektur client-server, dua jalur distribusi, sampai siklus hidup image dan container. Teori sebanyak itu memang penting, tetapi alasan Docker begitu populer justru terasa saat kita memakainya untuk pekerjaan sehari-hari. Chapter ini merangkai seluruh konsep tersebut ke dalam enam skenario nyata yang paling sering dijumpai developer, dari menjalankan proyek tim sampai bereksperimen dengan alat baru tanpa mengotori laptop. Pilih skenario yang paling dekat dengan pekerjaan kita, lalu perhatikan bagaimana image, container, network, dan registry dari chapter-chapter sebelumnya bekerja bersama:

  • Lingkungan development yang konsisten
  • Database lokal tanpa instalasi
  • Build sekali, jalan di mana pun
  • Microservices dan jaringan antar container
  • Batch job dengan batas resource
  • Demo dan eksperimen yang bersih

Lingkungan Development yang Konsisten #

Masalah Budi dan Siti pada Chapter Masalah yang Diselesaikan Docker menemui ujungnya ketika seluruh stack aplikasi dinyalakan dari satu berkas compose.yaml. Budi mendefinisikan service web dan db beserta konfigurasinya di dalam berkas tersebut, lalu meng-commit-nya ke repositori; Siti cukup menarik repositori yang sama dan menjalankan satu perintah. Docker Compose kemudian membuat network untuk proyek, menjalankan container database, menunggu healthcheck-nya sehat, dan terakhir menyalakan container aplikasi — persis seperti di laptop Budi:

bash 
$ docker compose up -d

Output yang Dihasilkan:

text 
[+] Running 3/3
 ✔ Network katalog_default Created
 ✔ Container katalog-db-1 Healthy
 ✔ Container katalog-web-1 Started

Mari kita telaah tiga baris output di atas. Baris pertama menandakan network khusus proyek dibuat agar service-nya saling terhubung; baris kedua menunjukkan container database sudah melewati healthcheck dan dinyatakan sehat; baris ketiga baru menyalakan aplikasi setelah databasenya benar-benar siap. Urutan ini bukan kebetulan, melainkan hasil deklarasi ketergantungan antar service — topik yang kita bedah tuntas pada Section Docker Compose.

Database Lokal tanpa Instalasi #

Developer membutuhkan basis data untuk mengembangkan aplikasi, tetapi memasang PostgreSQL secara global mencemari laptop dan menyulitkan pergantian versi. Dengan Docker, satu baris perintah menyalakan PostgreSQL yang terisolasi dalam hitungan detik: berkas datanya tinggal di dalam container, dan container bisa dibuang begitu pekerjaan selesai. Variabel POSTGRES_PASSWORD memberi tahu image postgres kata sandi superuser saat inisialisasi pertama, sementara tag 18-alpine memilih PostgreSQL 18 varian kecil berbasis Alpine. Ketika proyek berikutnya butuh versi lain, kita cukup menjalankan tag lain tanpa menyentuh instalasi yang ada:

bash 
$ docker run -d --name latihan-db \
    -e POSTGRES_PASSWORD=rahasia123 \
    postgres:18-alpine

Output yang Dihasilkan:

text 
8f3a1c9d2e4b5f6a7d8c9e0f1a2b3c4d5e6f708192a3b4c5d6e7f8091a2b3c4d

Mari kita telaah perintah di atas:

  1. -e POSTGRES_PASSWORD=rahasia123 — image postgres memerlukan variabel ini pada kali pertama dijalankan; tanpa variabel tersebut, container gagal inisialisasi dan langsung berhenti.
  2. --name latihan-db dan -d — container diberi nama agar mudah dirujuk, lalu dijalankan di latar belakang; baris output di bawahnya adalah ID container versi penuh.
  3. postgres:18-alpine — tag eksplisit versi PostgreSQL 18 varian Alpine; jika aplikasi di host perlu tersambung, tambahkan flag -p 5432:5432 untuk menerbitkan portnya — mekanisme port publishing kita bahas pada Chapter Port Publishing.

Kita bisa memastikan basis data siap dipakai melalui log-nya:

bash 
$ docker logs latihan-db

Output yang Dihasilkan:

text 
PostgreSQL Database directory appears to be empty.
Initializing database files...
2026-10-13 09:41:30.482 UTC [1] LOG:  database system is ready to accept connections

Baris terakhir itulah penanda bahwa PostgreSQL telah selesai menginisialisasi basis data dan siap menerima koneksi. Baris-baris log lain dipotong agar ringkas; membaca log container secara menyeluruh akan kita latih pada Chapter Melihat Log Container. Skenario database berlaku juga untuk MySQL, MariaDB, dan Redis — tinggal ganti nama imagenya, polanya sama persis.

Build Sekali Jalan di Mana Pun #

Prinsip build sekali, jalan di mana pun adalah tulang punggung pipeline CI/CD modern. Server CI membangun image dari Dockerfile sekali per commit, menguji aplikasi di dalam container yang identik dengan produksi, lalu mendorong image yang lulus uji ke registry. Server staging maupun produksi tinggal menarik image yang sama persis — tidak ada lagi langkah build terpisah di tiap lingkungan yang bisa saling berbeda hasilnya. Ketika bug muncul di produksi, image yang sedang berjalan adalah image yang diuji, bukan hasil rakitan ulang:

bash 
$ docker build -t katalog:1.0 .

Output yang Dihasilkan:

text 
[+] Building 11.2s (9/9) FINISHED
 => [internal] load build definition
 => [1/4] FROM docker.io/library/python:3.12-slim
...
 => exporting layers
 => writing image sha256:2d5f8e1a9c4b7a3e6f0d8c1b4a7e2f5c8b3a6d9e0f2c5b8a1d4e7f0c3b6a9d2e
 => naming to docker.io/library/katalog:1.0

Sebagian langkah build di tengah dipotong agar ringkas. Flag -t katalog:1.0 memberi nama dan versi pada image hasil build, sedangkan titik di akhir perintah menunjuk folder saat ini sebagai build context. Sejak Docker 23.0, docker build berjalan di atas BuildKit dan merupakan alias dari docker buildx build — kita bedah seluruh mekanismenya pada Section Image Build dan Optimisasi.

Microservices dan Jaringan Antar Container #

Pada arsitektur microservices, puluhan service saling memanggil, dan ketergantungan pada alamat IP yang diketik manual adalah sumber kerapuhan tanpa ujung. Docker menjawabnya dengan network custom: semua container yang bergabung ke satu network dapat saling memanggil lewat nama containernya, dan nama tersebut diterjemahkan oleh DNS embedded Docker pada alamat 127.0.0.11. Perhatikan bahwa DNS embedded hanya aktif pada network buatan sendiri — default bridge tidak menyediakannya, dan itulah alasan kita membuat network secara eksplisit. Aplikasi di container app cukup menyambung ke host bernama db tanpa pernah tahu alamat IP di baliknya:

bash 
$ docker network create latihan-net
$ docker run -d --name app --network latihan-net katalog:1.0
$ docker run -d --name db --network latihan-net \
    -e POSTGRES_PASSWORD=rahasia123 postgres:18-alpine

Output yang Dihasilkan:

text 
1f4a9e2c8b3d7a6f0e5c4b9d2a8e7f3c1b6d4a9e8c2f5b0d3a7e1c4f9b2d6a8e

Baris output di atas adalah ID network yang baru dibuat. Dua perintah docker run setelahnya mengembalikan ID container panjang seperti pada demo Chapter Image, Container, dan Registry. Dari titik ini, container app dapat menjangkau container db dengan menyebut nama db sebagai host — dasar dari service discovery sederhana yang kita bangun lebih jauh pada Section Jaringan Container dan Section Aplikasi Multi-Container.

Batch Job dengan Batas Resource #

Tugas latar belakang seperti laporan mingguan atau migrasi data idealnya berjalan sekali lalu pergi tanpa meninggalkan bekas. Flag --rm memerintahkan Docker menghapus container begitu tugasnya selesai, sehingga daftar container tidak ditumbuhi sisa-sisa pekerjaan. Flag --cpus dan --memory membatasi resource container lewat cgroups agar job tidak menggerus server yang dipakai bersama service lain; jika job melampaui batas memori, kernel membunuh prosesnya dan container berhenti dengan exit code 137 — kode yang kita bedah pada Chapter Memahami Exit Code:

bash 
$ docker run --rm --cpus 1 --memory 512m \
    -v "$PWD":/kerja -w /kerja \
    python:3.12-slim python laporan.py

Output yang Dihasilkan:

text 
Laporan penjualan mingguan selesai: 1.248 transaksi diproses

Mari kita telaah flag-flag pada perintah di atas:

  1. --rm — container dihapus otomatis segera setelah prosesnya selesai; hasil pekerjaan tinggal berkas laporan di folder proyek kita.
  2. --cpus 1 dan --memory 512m — container dibatasi maksimal satu inti CPU dan 512 megabyte memori; pembatasan ini ditegakkan oleh cgroups di level kernel, bukan oleh kesantuan aplikasi.
  3. -v "$PWD":/kerja -w /kerja — folder saat ini di-mount ke path /kerja di dalam container dan dijadikan working directory, sehingga skrip laporan.py dari laptop kita dapat dijalankan oleh Python di dalam container tanpa memasang Python di host.

Demo dan Eksperimen yang Bersih #

Terakhir, Docker adalah kotak pasir untuk rasa penasaran. Ingin mencicipi shell Alpine, mencoba CLI basis data, atau menguji image diagnostik jaringan seperti netshoot? Jalankan container interaktif dengan flag -it, selesai eksperimen ketik exit, dan tidak ada jejak yang tertinggal di laptop berkat --rm. Image alpine:3.20 hanya berukuran 7.8MB sehingga biaya mencoba hampir nol:

bash 
$ docker run --rm -it alpine:3.20 sh

Output yang Dihasilkan:

text 
/ # grep -E '^(NAME|ID)=' /etc/os-release
NAME="Alpine Linux"
ID=alpine
/ # exit

Prompt / # menandakan kita sudah berada di dalam shell Alpine Linux. Ganti alpine:3.20 dengan image lain untuk bereksperimen dengan alat yang berbeda, dan seluruh kerusakan yang kita buat di dalam container ikut lenyap saat container dihapus. Kebiasaan mencoba di dalam container inilah yang membuat memori laptop developer tetap sehat dari puluhan instalasi setengah jadi.

Dengan ini Section Pengantar Docker tuntas: kita mengenal definisi dan sejarah Docker, empat masalah klasik yang dijawabnya lewat image, posisi container di samping virtual machine, arsitektur client-server di balik layar, dua jalur distribusi Engine dan Desktop, trio image-container-registry, dan enam skenario pemakaian nyata. Enam skenario di atas sengaja dipilih karena semuanya bisa dicoba begitu Docker terpasang — dari menyalakan stack proyek tim sampai bermain dengan shell Alpine. Perjalanan kita selanjutnya berpindah dari konsep ke praktik: Section Instalasi dan Konfigurasi akan memandu kita memilih lingkungan yang tepat, memasang Docker di Linux, Windows, dan macOS, sampai memverifikasi bahwa daemon menyala dengan benar — dimulai dari Chapter Memilih Lingkungan Docker.

Referensi #