Docker: Dasar Container

Bagian VI series ini selesai membahas file sharing melalui Samba pada Bab 24 dan NFS pada Bab 25. Bab 26 membuka Bagian VII dengan topik yang mengubah cara Developer mengemas dan men-deploy aplikasi ke server: containerization melalui Docker. Skenario yang sering ditemui Sysadmin di lapangan biasanya seperti ini: Developer sudah menguji aplikasi Node.js di laptopnya menggunakan Node 22 seperti pada Bab 15, tetapi saat di-deploy ke server produksi yang masih menjalankan Node versi lain, aplikasi tiba-tiba error karena perbedaan versi dependency yang tidak terlihat sebelumnya. Masalah klasik "jalan di laptop saya" ini menjadi alasan utama Docker menjadi standar industri: membungkus aplikasi beserta seluruh dependency-nya ke dalam satu paket yang berjalan identik di mana pun, baik di laptop Developer maupun di server produksi kita. Bab ini dimulai dari konsep dasar container dibandingkan virtual machine, memasang Docker Engine 29 lewat installer script resmi, mempraktikkan perintah dasar docker run, ps, stop, dan rm, memahami perbedaan image dan container melalui docker pull dan docker build, sampai menutup bab dengan volume dan networking dasar agar data container tidak hilang begitu saja serta antarcontainer dapat saling terhubung.

26.1 Konsep Container vs Virtual Machine

Sebelum memasang Docker, kita perlu memahami terlebih dahulu hal yang sebenarnya membuat container berbeda dari virtual machine (VM) yang mungkin sudah lebih akrab bagi sebagian Sysadmin, terutama yang terbiasa dengan VirtualBox atau KVM.

26.1.1 Virtualisasi Penuh vs Containerization: Beda Arsitektur

Virtual machine, yang akan dibahas lebih dalam pada Bab 28 melalui KVM/QEMU, bekerja dengan menjalankan hypervisor yang mengemulasi hardware lengkap, lalu di atasnya berjalan sistem operasi tamu (guest OS) yang utuh, lengkap dengan kernelnya sendiri. Pendekatan ini memberikan isolasi yang sangat kuat, tetapi juga berat: setiap VM membawa kernel penuh, membutuhkan waktu boot dalam hitungan puluhan detik hingga menit, serta menghabiskan resource RAM dan storage yang cukup besar hanya untuk menjalankan sistem operasinya sendiri sebelum aplikasi sungguhan sempat berjalan.

Container mengambil pendekatan yang jauh lebih ringan. Alih-alih mengemulasi hardware dan menjalankan kernel terpisah, container berbagi satu kernel Linux yang sama dengan host-nya, lalu menggunakan fitur isolasi bawaan kernel untuk membuat setiap container terasa seperti sistem yang berdiri sendiri padahal sebenarnya hanya proses biasa yang diisolasi secara ketat. Karena tidak perlu boot kernel terpisah, container biasanya siap dalam hitungan detik atau bahkan kurang dari satu detik, dan ukurannya jauh lebih kecil karena hanya membawa aplikasi beserta library yang benar-benar dibutuhkan, bukan sistem operasi lengkap.

Perbedaan ini bukan berarti container selalu lebih unggul daripada VM. Container tetap berbagi kernel yang sama dengan host, sehingga isolasinya secara teori tidak seketat VM yang benar-benar memiliki kernel terpisah. Untuk kebutuhan yang menuntut isolasi keamanan maksimal atau menjalankan sistem operasi yang berbeda dari host, VM tetap menjadi pilihan yang lebih tepat. Namun untuk kebutuhan packaging dan distribusi aplikasi seperti kasus Developer di awal bab ini, container jauh lebih efisien dan praktis.

26.1.2 Namespace dan cgroup: Fondasi Container di Kernel Linux

Docker bukan teknologi yang menciptakan mekanisme isolasi dari nol. Docker sebenarnya adalah lapisan tooling yang memudahkan penggunaan dua fitur kernel Linux yang sudah ada sejak lama: namespace dan cgroup. Namespace bertugas mengisolasi hal yang dapat "dilihat" oleh sebuah proses, mulai dari pid namespace (proses di dalam container hanya melihat proses miliknya sendiri, tidak melihat proses lain di host), net namespace (setiap container memiliki stack jaringan dan IP address sendiri), mnt namespace (setiap container memiliki susunan filesystem sendiri), hingga uts dan ipc namespace untuk hostname dan komunikasi antarproses. Sementara itu, cgroup (control group) bertugas membatasi seberapa besar resource seperti CPU, memory, dan I/O yang boleh digunakan oleh sekumpulan proses, yang telah dibahas secara mendalam pada Bagian 5.4 saat kita membahas migrasi cgroup v1 ke cgroup v2.

Kabar baiknya, karena Ubuntu Server 26.04 LTS sudah sepenuhnya berjalan di atas cgroup v2 unified sejak awal (cgroup v1 sudah dihapus total seperti dibahas pada Bagian 1.4), Docker Engine yang kita pasang nanti langsung menggunakan cgroup v2 tanpa perlu konfigurasi tambahan apa pun. Hal ini berbeda dari pengalaman pada generasi Ubuntu lama, ketika Sysadmin terkadang masih perlu mengatur ulang cgroup driver secara manual agar Docker dan systemd tidak saling berebut kendali atas resource.

Sebagai gambaran singkat, kita dapat melihat sendiri daftar namespace yang sedang aktif untuk shell yang sedang kita gunakan saat ini, meskipun Docker belum terpasang sama sekali.

ls -la /proc/self/ns/

Output-nya kurang lebih berupa daftar symlink berikut, yang masing-masing mewakili satu jenis namespace yang sedang digunakan oleh proses shell kita.

lrwxrwxrwx 1 root root 0 Aug 27 10:00 cgroup -> 'cgroup:[4026531835]'
lrwxrwxrwx 1 root root 0 Aug 27 10:00 ipc -> 'ipc:[4026531839]'
lrwxrwxrwx 1 root root 0 Aug 27 10:00 mnt -> 'mnt:[4026531840]'
lrwxrwxrwx 1 root root 0 Aug 27 10:00 net -> 'net:[4026531841]'
lrwxrwxrwx 1 root root 0 Aug 27 10:00 pid -> 'pid:[4026531836]'
lrwxrwxrwx 1 root root 0 Aug 27 10:00 uts -> 'uts:[4026531838]'

Angka di dalam kurung siku adalah nomor inode unik penanda instance namespace tersebut, dan nilainya akan berbeda pada setiap server. Begitu Docker terpasang dan sebuah container berjalan, proses di dalam container tersebut akan menunjuk ke nomor inode namespace yang berbeda dari proses di host. Hal itulah yang menjadi wujud konkret dari isolasi yang selama ini disebut sebagai "container".

26.2 Instalasi Docker Engine dengan Installer Script Resmi

Selain instalasi manual lewat GPG key dan repository APT seperti yang kita praktikkan untuk MongoDB pada Bagian 21.2, Docker juga menyediakan jalan pintas resmi berupa convenience script: satu script shell yang otomatis mendeteksi distro Linux yang sedang dipakai, mendaftarkan repository resmi Docker, lalu memasang Docker Engine beserta seluruh komponen pendukungnya hanya dengan satu perintah. Script ini dihosting Docker sendiri di get.docker.com dan didokumentasikan resmi sebagai cara tercepat untuk memulai, cocok untuk lingkungan development, testing, atau lab seperti yang kita pakai sepanjang series ini.

26.2.1 Menjalankan Installer Script

Langkah Praktik

1. Unduh sekaligus jalankan installer script resmi Docker dalam satu perintah.

   sudo sh -c "curl -fsSL https://get.docker.com/ | sh"

   Script ini mendeteksi bahwa server menjalankan Ubuntu, lalu otomatis mengerjakan seluruh langkah yang sebelumnya harus dilakukan manual: menambahkan GPG key, mendaftarkan repository APT resmi Docker, menjalankan apt update, hingga memasang lima paket sekaligus, yaitu docker-ce (daemon utama dockerd), docker-ce-cli (perintah docker di terminal), containerd.io (container runtime tingkat rendah yang benar-benar menjalankan container di kernel), docker-buildx-plugin, dan docker-compose-plugin yang menghadirkan perintah docker compose untuk Bab 27 nanti.
2. Pastikan service docker aktif dan otomatis menyala saat boot. Installer script biasanya sudah mengaktifkannya secara otomatis, tetapi tidak ada salahnya untuk memastikan.

   sudo systemctl enable --now docker

Verifikasi dan Troubleshooting

• Konfirmasikan versi Docker Engine yang terpasang.

  docker --version

• Jalankan container uji resmi dari Docker untuk memastikan seluruh rantai instalasi, mulai dari daemon, networking, sampai kemampuan menarik image dari internet, benar-benar berfungsi.

  sudo docker run hello-world

  Output yang diharapkan diawali dengan kalimat Hello from Docker! disertai penjelasan singkat bahwa Docker berhasil menarik image, membuat container, menjalankannya, lalu container tersebut berhenti dengan sendirinya karena tugasnya hanya mencetak pesan itu.
• Periksa detail environment Docker, termasuk memastikan cgroup driver yang digunakan sudah systemd dan versi cgroup yang aktif adalah versi 2, sesuai dengan pembahasan Bagian 26.1.2.

  sudo docker info | grep -i cgroup

  Baris Cgroup Driver: systemd dan Cgroup Version: 2 menandakan Docker sudah selaras dengan systemd sebagai pengelola resource utama di server, tanpa konflik pengaturan seperti yang kadang terjadi pada generasi Ubuntu lama.
• Jika instalasi gagal dengan pesan semacam Unsupported distribution, kemungkinan besar codename Ubuntu 26.04 belum dikenali script karena rilis masih tergolong baru, mirip catatan pada Bagian 21.5 untuk MongoDB. Sebagai solusi sementara, tunggu pembaruan dari Docker atau pasang manual lewat repository APT resmi Docker dengan codename LTS sebelumnya sebagai fallback.

26.2.2 Menjalankan Docker Tanpa sudo

Perintah docker secara default membutuhkan akses root karena daemon dockerd berjalan sebagai root dan berkomunikasi melalui socket Unix /var/run/docker.sock yang hanya bisa diakses oleh root. Agar Sysadmin tidak perlu mengetik sudo pada setiap perintah docker, kita dapat menambahkan user ke group docker yang sudah dibuat secara otomatis saat instalasi.

Langkah Praktik

1. Tambahkan user yang sedang login ke group docker.

   sudo usermod -aG docker $USER

2. Terapkan keanggotaan group baru tanpa perlu logout, cukup dengan memulai ulang sesi shell group.

   newgrp docker

Verifikasi dan Troubleshooting

• Jalankan ulang container uji tanpa sudo, yang seharusnya berjalan tanpa error permission.

  docker run hello-world

• Jika masih muncul error permission denied while trying to connect to the Docker daemon socket, keanggotaan group belum benar-benar diterapkan pada sesi shell saat ini. Cara paling pasti adalah logout total dari sesi SSH lalu login kembali, bukan hanya mengandalkan newgrp.
• Catatan jujur soal keamanan yang wajib dipahami oleh setiap Sysadmin: keanggotaan group docker pada praktiknya setara dengan akses root penuh ke server. Siapa pun di dalam group ini dapat me-mount seluruh filesystem host ke dalam container lalu memodifikasinya secara bebas, misalnya melalui docker run -v /:/host alpine chroot /host. Jangan pernah memasukkan user sembarangan ke dalam group ini di server produksi, dan perlakukan keanggotaan ini seperti memberi akses sudo penuh.

26.3 Perintah Dasar Docker: run, ps, stop, rm

Docker Engine sudah aktif. Bagian ini mempraktikkan siklus hidup container paling dasar yang akan digunakan setiap hari: menjalankan, memeriksa, menghentikan, dan menghapus container.

26.3.1 Menjalankan Container Pertama dengan docker run

Langkah Praktik

1. Jalankan container Nginx sederhana di latar belakang, dengan memetakan port 8080 di host ke port 80 di dalam container.

   docker run -d --name web-test -p 8080:80 nginx:stable

   Tiga flag di atas masing-masing penting untuk dipahami. Flag -d (detached) menjalankan container di latar belakang sehingga terminal tidak tersandera menunggu proses container selesai. Flag --name memberikan nama yang mudah diingat, karena tanpa flag ini Docker akan membuatkan nama acak seperti fervent_mendeleev. Flag -p 8080:80 memetakan port host ke port container dengan format port_host:port_container, karena secara default port di dalam container tidak dapat diakses langsung dari luar host tanpa pemetaan eksplisit ini.

Verifikasi dan Troubleshooting

• Akses web server yang baru saja berjalan di dalam container.

  curl http://localhost:8080

  Output berupa halaman HTML default Nginx menandakan container benar-benar melayani traffic, bukan sekadar berstatus "running" secara kosmetik.
• Jika muncul error port is already allocated, port 8080 di host sudah digunakan oleh proses atau container lain. Periksa dengan sudo ss -tlnp | grep 8080, lalu ganti pemetaan port pada perintah docker run berikutnya.

26.3.2 Melihat, Menghentikan, dan Menghapus Container

Langkah Praktik

1. Lihat daftar container yang sedang berjalan.

   docker ps

2. Lihat seluruh container, termasuk yang sudah berhenti, sekaligus membandingkannya dengan daftar yang hanya menampilkan container aktif.

   docker ps -a

3. Lihat log output container web-test, cara paling umum untuk debugging saat aplikasi di dalam container tidak berjalan sesuai harapan.

   docker logs web-test

4. Masuk secara interaktif ke dalam container yang sedang berjalan, berguna untuk memeriksa isi filesystem atau menjalankan perintah diagnostik langsung dari dalamnya.

   docker exec -it web-test sh

   Flag -it menggabungkan mode interactive (-i, menjaga standard input tetap terbuka) dan alokasi pseudo-terminal (-t), kombinasi yang selalu dibutuhkan setiap kali membuka shell interaktif di dalam container. Ketik exit untuk keluar dari shell tersebut dan kembali ke terminal host; container itu sendiri tetap berjalan di latar belakang, tidak ikut berhenti. Bentuk lain docker exec tanpa -it juga bisa dipakai untuk menjalankan satu perintah tunggal tanpa masuk ke sesi interaktif, seperti akan kita praktikkan pada Bagian 26.5.1.
5. Hentikan container web-test. Perintah ini mengirimkan sinyal SIGTERM ke proses utama di dalam container agar berhenti secara graceful, lalu menunggu maksimal 10 detik sebelum memaksa dengan SIGKILL jika container belum juga berhenti.

   docker stop web-test

6. Hapus container yang sudah berhenti. Docker tidak mengizinkan penghapusan container yang masih berjalan tanpa flag paksa, sebagai pengaman agar Sysadmin tidak sengaja menghapus container produksi yang masih aktif.

   docker rm web-test

Verifikasi dan Troubleshooting

• Konfirmasikan web-test sudah benar-benar hilang dari daftar, bahkan dari daftar container yang sudah berhenti.

  docker ps -a

• Jika terburu-buru dan ingin menghentikan sekaligus menghapus dalam satu langkah, flag -f (force) pada docker rm -f nama_container akan langsung mengirim SIGKILL tanpa masa tunggu graceful shutdown. Langkah ini praktis untuk container uji coba, tetapi sebaiknya dihindari untuk container produksi yang sedang menangani koneksi aktif, karena data yang belum sempat di-flush ke disk berisiko hilang.

26.4 Image vs Container: Pull dan Build

Bagian ini membedah dua istilah yang sering tertukar oleh pemula: image dan container. Kita akan menarik image resmi dari registry publik, lalu membangun image sendiri melalui Dockerfile.

26.4.1 Image Adalah Blueprint, Container Adalah Instance-nya

Image adalah paket read-only berisi filesystem lengkap dari sebuah aplikasi: kode program, runtime, library, dan file konfigurasi yang dibutuhkan agar aplikasi dapat berjalan. Bagi Developer yang terbiasa dengan pemrograman berorientasi objek, analogi paling mudah adalah image setara dengan class, sedangkan container adalah instance yang benar-benar berjalan dari class tersebut. Satu image yang sama dapat digunakan untuk menjalankan banyak container sekaligus, yang masing-masing berjalan secara terisolasi satu sama lain melalui namespace yang sudah dibahas pada Bagian 26.1.2.

Secara teknis, image tersusun dari beberapa layer yang ditumpuk menggunakan union filesystem (Docker Engine modern menggunakan driver overlay2 secara default). Setiap instruksi di dalam Dockerfile, yang akan kita bahas pada Bagian 26.4.3, menghasilkan satu layer baru yang bersifat read-only. Begitu image dijalankan menjadi container, Docker menambahkan satu layer tambahan yang dapat ditulis di paling atas, yang disebut container layer. Perubahan apa pun yang terjadi selama container berjalan, misalnya file baru yang dibuat oleh aplikasi, hanya tersimpan di layer tulis ini, sedangkan layer image di bawahnya tetap utuh dan tidak berubah. Konsekuensi pentingnya, begitu container dihapus, layer tulis ini ikut hilang seluruhnya. Itulah sebabnya kita membutuhkan volume yang dibahas pada Bagian 26.5 untuk data yang harus bertahan lebih lama dari umur satu container.

26.4.2 Menarik Image dengan docker pull dan Mengenal Image Layer

Langkah Praktik

1. Tarik image Nginx versi stable secara eksplisit dari Docker Hub, registry publik bawaan Docker.

   docker pull nginx:stable

2. Lihat daftar image yang sudah tersimpan secara lokal di server.

   docker images

Verifikasi dan Troubleshooting

• Lihat riwayat layer pembentuk image tersebut, beserta ukuran dari masing-masing layer.

  docker history nginx:stable

• Perhatikan format nama image nginx:stable. Bagian sebelum titik dua adalah nama repository, dan bagian setelahnya adalah tag. Jika tag tidak dituliskan sama sekali, Docker secara otomatis menggunakan tag latest. Kebiasaan ini sebaiknya dihindari di server produksi karena isi latest dapat berubah kapan saja mengikuti rilis terbaru upstream, yang membuat deployment sulit direproduksi ulang secara konsisten.

26.4.3 Membangun Image Sendiri dengan Dockerfile dan docker build

Dockerfile adalah berkas teks berisi instruksi langkah demi langkah untuk membangun image kustom. Bagian ini membangun image sederhana berisi halaman statis, sebagai gambaran paling ringkas dari alur kerja yang sama persis digunakan oleh Developer saat membungkus aplikasi Node.js atau PHP mereka menjadi image Docker.

Langkah Praktik

1. Buat direktori proyek beserta halaman HTML sederhana yang akan dibungkus ke dalam image.

   mkdir -p ~/situs-statis && cd ~/situs-statis
   echo "<h1>Halo dari image Docker kustom</h1>" > index.html

2. Buat Dockerfile di direktori yang sama.

   nano Dockerfile

   FROM nginx:stable
   COPY index.html /usr/share/nginx/html/index.html

   Instruksi FROM menentukan image dasar yang digunakan sebagai fondasi, dalam kasus ini image Nginx resmi yang sudah kita tarik sebelumnya. Instruksi COPY menyalin file dari direktori build di host ke dalam filesystem image, sehingga menimpa halaman default Nginx dengan halaman kustom kita.
3. Bangun image dari Dockerfile tersebut, dengan memberikan nama situs-statis dan tag 1.0. Tanda titik di akhir perintah menunjuk ke direktori saat ini sebagai build context, yaitu kumpulan file yang dikirim ke Docker daemon selama proses build.

   docker build -t situs-statis:1.0 .

4. Jalankan container dari image yang baru saja dibangun.

   docker run -d --name situs-statis -p 8081:80 situs-statis:1.0

Verifikasi dan Troubleshooting

• Akses halaman kustom yang baru dibangun.

  curl http://localhost:8081

  Output seharusnya menampilkan <h1>Halo dari image Docker kustom</h1>, bukan lagi halaman default Nginx.
• Konfirmasikan image situs-statis:1.0 muncul di daftar image lokal beserta ukurannya.

  docker images | grep situs-statis

• Error failed to solve: nginx:stable: failed to resolve source metadata saat build biasanya menandakan bahwa server tidak memiliki koneksi keluar ke internet untuk menarik image dasar FROM. Periksa kembali koneksi jaringan dan resolusi DNS server seperti pada Bab 9.

26.5 Volume dan Networking Dasar di Docker

Dua kebutuhan terakhir yang wajib dikuasai sebelum benar-benar mengoperasikan Docker di server produksi: bagaimana data tetap aman meskipun container dihapus, dan bagaimana antarcontainer dapat saling terhubung layaknya server terpisah di satu jaringan internal.

26.5.1 Persistensi Data dengan Docker Volume

Seperti dibahas pada Bagian 26.4.1, seluruh perubahan yang terjadi selama container berjalan tersimpan di container layer yang ikut terhapus begitu container dihapus. Volume adalah mekanisme resmi Docker untuk menyimpan data di luar siklus hidup container, yang dikelola langsung oleh Docker Engine dan disimpan di /var/lib/docker/volumes/ pada host.

Langkah Praktik

1. Buat volume baru bernama web-data.

   docker volume create web-data

2. Jalankan container Nginx dengan volume tersebut di-mount ke direktori konten web di dalam container.

   docker run -d --name web1 -v web-data:/usr/share/nginx/html -p 8082:80 nginx:stable

3. Tulis file baru ke dalam volume lewat docker exec, kali ini memakai bentuk satu perintah tunggal seperti disinggung pada Bagian 26.3.2, tanpa perlu membuka sesi interaktif.

   docker exec web1 sh -c 'echo "Data ini tersimpan di volume" > /usr/share/nginx/html/index.html'

4. Hapus paksa container web1 secara penuh, seolah container tersebut hilang total.

   docker rm -f web1

5. Jalankan container baru dengan nama berbeda, tetapi tetap menggunakan volume web-data yang sama.

   docker run -d --name web2 -v web-data:/usr/share/nginx/html -p 8082:80 nginx:stable

Verifikasi dan Troubleshooting

• Akses ulang port yang sama, dan pastikan isi file yang ditulis melalui web1 tadi tetap ada meskipun container aslinya telah dihapus total.

  curl http://localhost:8082

  Output Data ini tersimpan di volume membuktikan bahwa volume benar-benar independen dari umur satu container tertentu.
• Lihat detail lokasi fisik volume di host, yang berguna saat membutuhkan backup langsung dari sisi filesystem.

  docker volume inspect web-data

26.5.2 Bind Mount vs Named Volume

Selain named volume seperti web-data di atas, Docker juga mendukung bind mount, yaitu me-mount langsung sebuah path di filesystem host ke dalam container, tanpa dikelola melalui abstraksi volume Docker.

Langkah Praktik

1. Siapkan direktori di host beserta file HTML sederhana.

   mkdir -p ~/situs-bind
   echo "<h1>Diedit langsung dari host</h1>" > ~/situs-bind/index.html

2. Jalankan container dengan bind mount, yang menunjuk langsung ke path absolut di host.

   docker run -d --name web-bind -v ~/situs-bind:/usr/share/nginx/html -p 8083:80 nginx:stable

3. Edit file di host secara langsung, tanpa masuk ke dalam container sama sekali.

   echo "<h1>Perubahan langsung, tanpa rebuild</h1>" > ~/situs-bind/index.html

Verifikasi dan Troubleshooting

• Muat ulang halaman, perubahan dari host seharusnya langsung terlihat tanpa perlu restart container sama sekali.

  curl http://localhost:8083

Sebagai catatan dari lapangan, bind mount sangat nyaman digunakan oleh Developer saat pengembangan lokal karena perubahan kode langsung terlihat tanpa build ulang image. Namun untuk data produksi yang membutuhkan portabilitas dan kemudahan backup terstandardisasi, named volume tetap menjadi pilihan yang lebih direkomendasikan.

26.5.3 Docker Network dan Komunikasi Antar-Container

Setiap kali Docker terpasang, secara otomatis tersedia beberapa network bawaan yang dapat dilihat langsung.

Langkah Praktik

1. Lihat daftar network yang tersedia saat ini.

   docker network ls

   Tiga network bawaan yang selalu ada adalah bridge (network default tempat container berjalan jika tidak ditentukan lain), host (container berbagi stack jaringan langsung dengan host, tanpa isolasi network sama sekali), dan none (container tanpa akses jaringan apa pun).
2. Buat network kustom bertipe bridge, yang akan digunakan agar dua container dapat saling menemukan melalui nama.

   docker network create app-net

3. Jalankan container PostgreSQL 18, konsisten dengan versi yang sudah dibahas pada Bab 18, yang terhubung ke network app-net.

   docker run -d --name db-demo --network app-net \
     -e POSTGRES_PASSWORD=rahasia123 postgres:18

4. Dari container terpisah yang juga terhubung ke app-net, coba hubungi db-demo langsung menggunakan namanya, bukan IP address.

   docker run -it --rm --network app-net -e PGPASSWORD=rahasia123 \
     postgres:18 psql -h db-demo -U postgres -c "SELECT version();"

Verifikasi dan Troubleshooting

• Perintah psql di atas seharusnya berhasil terhubung dan menampilkan output versi PostgreSQL, meskipun kita sama sekali tidak menuliskan IP address db-demo secara manual. Hal ini terjadi karena setiap network kustom yang dibuat melalui docker network create secara otomatis mendapatkan embedded DNS server bawaan Docker, yang menerjemahkan nama container menjadi IP address internalnya secara otomatis. Kemudahan ini sengaja tidak berlaku di network bridge default, yang menjadi salah satu alasan kuat mengapa network kustom seperti app-net lebih disarankan daripada mengandalkan network bawaan.
• Bersihkan sisa container percobaan pada bab ini sebelum melanjutkan ke Bab 27, karena beberapa nama container di atas akan digunakan kembali dengan konfigurasi berbeda di sana. Container web-test dan web1 tidak perlu disebutkan lagi karena keduanya sudah dihapus pada langkah sebelumnya.

  docker rm -f web2 web-bind situs-statis db-demo
  docker network rm app-net

Sampai di sini, server kita sudah menjalankan Docker Engine 29 lengkap dengan container pertama, image kustom hasil Dockerfile sendiri, serta pemahaman volume dan network dasar agar data tidak hilang dan antarcontainer dapat saling terhubung. Namun menjalankan aplikasi web beserta database-nya melalui perintah docker run satu per satu, seperti yang baru saja kita praktikkan dengan web-test dan db-demo secara terpisah, jelas tidak praktis untuk aplikasi produksi yang terdiri dari banyak service sekaligus. Bab 27 menyelesaikan masalah ini melalui Docker Compose, mendefinisikan seluruh aplikasi multi-container hanya dalam satu file docker-compose.yml.