Troubleshooting Instalasi

Seluruh section ini berjalan mulus di mesin Budi dan Siti, tetapi dunia nyata jarang sekooperatif itu. Daemon mendadak menolak menyala setelah suntikan daemon.json, pesan permission denied muncul padahal grup sudah ditambahkan, WSL menolak bangun dengan kode galat berbilang hex, dan disk server penuh diam-diam oleh image lama yang terlupakan. Kabar baiknya: hampir semua masalah instalasi Docker mengelompok ke dalam delapan pola yang sama, dan masing-masing punya jalur diagnosis yang bisa dipelajari sampai jadi refleks. Chapter penutup ini merangkum kedelapan pola tersebut dalam satu tabel, lalu membedah empat kasus yang paling banyak menyita waktu, lengkap dengan keluaran asli perintah diagnosisnya.

Delapan Gejala Paling Umum #

Tabel berikut adalah peta lengkapnya: baca kolom gejala, cocokkan dengan yang kita alami, lalu ikuti petunjuk penyebab dan solusinya. Empat gejala yang paling sering menghabiskan waktu — daemon mati, izin socket, disk penuh, dan service masked — dibedah tuntas pada bagian-bagian berikutnya:

Bedah Kasus Daemon yang Mati #

Gejala ini paling sering muncul dan paling mudah dipatahkan jika kita tahu urutannya. Semuanya bermula dari pesan klasik saat menjalankan perintah apa pun:

$ docker ps

Output yang Dihasilkan:

Cannot connect to the Docker daemon. Is the docker daemon running on this host?

Langkah diagnosis pertama selalu sama: tanyakan keadaan layanan kepada systemd:

$ systemctl status docker

Output yang Dihasilkan:

× docker.service - Docker Application Container Engine
     Loaded: loaded (/lib/systemd/system/docker.service; enabled; preset: enabled)
     Active: failed (Result: exit-code) since Tue 2026-10-13 10:02:15 WIB; 31s ago
   Duration: 1.842s
    Process: 31244 ExecStart=/usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock (code=exited, status=1/FAILURE)
   Main PID: 31244 (code=exited, status=1/FAILURE)
...

Tanda × bersama Active: failed (Result: exit-code) menegaskan daemon sudah mencoba menyala lalu menyerah — bukan sekadar tidak pernah dinyalakan. Langkah kedua: minta jurnal sistem menceritakan kalimat terakhir daemon sebelum menyerah:

$ sudo journalctl -u docker --no-pager -n 20

Output yang Dihasilkan:

Okt 13 10:02:13 server systemd[1]: Starting docker.service - Docker Application Container Engine...
Okt 13 10:02:15 server dockerd[31244]: unable to configure the Docker daemon with file /etc/docker/daemon.json: invalid character '}' looking for beginning of object key string
Okt 13 10:02:15 server systemd[1]: docker.service: Main process exited, code=exited, status=1/FAILURE
Okt 13 10:02:15 server systemd[1]: docker.service: Failed with result 'exit-code'.

Baris kedua jurnal tersebut mengungkap tersangka utamanya: daemon.json tidak dapat diurai karena ada karakter yang tidak pada tempatnya — koma menempel di ujung blok adalah kecelakaan yang paling lazim. Perhatikan pula baris ExecStart=/usr/bin/dockerd -H fd:// pada keluaran status di atas: inilah argumen yang bentrok dengan kunci hosts di daemon.json sebagaimana kita bahas pada Chapter Konfigurasi Docker Engine. Setelah tersangkanya jelas, perbaikannya tinggal urutan singkat:

1. Buka /etc/docker/daemon.json dan perbaiki kesalahan sintaksnya — hapus koma ekstra di ujung blok yang terakhir.
2. Validasi berkasnya tanpa memulai ulang daemon: sudo dockerd --validate --config-file /etc/docker/daemon.json — ulangi sampai keluar configuration OK.
3. Mulai ulang layanan: sudo systemctl restart docker.
4. Pastikan daemon benar-benar hidup: systemctl status docker menunjukkan active (running).

Bedah Kasus Permission Denied pada Socket #

Gejala kedua klasiknya berbunyi demikian — dan ingat, daemon di sini sama sekali sehat:

$ docker ps

Output yang Dihasilkan:

docker: permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: ...

Bagian akhir pesan yang memuat alamat internal galat dipotong agar ringkas. Diagnosisnya satu langkah: cocokkan identitas kita dengan penjaga pintu:

$ id -nG
$ ls -l /var/run/docker.sock

Output yang Dihasilkan:

budi sudo
srw-rw---- 1 root docker 0 Okt 13 09:41 /var/run/docker.sock

Dua baris tersebut bercerita lengkap: grup yang aktif pada sesi Budi hanya budi dan sudo, sementara socket menuntut keanggotaan grup docker — persis mekanisme yang kita bedah pada Chapter Mengatur Akses Docker. Perbaikannya mengikuti temuan tersebut:

1. Daftarkan pengguna ke grup docker: sudo usermod -aG docker $USER.
2. Tutup seluruh sesi lalu login kembali — keanggotaan grup baru hanya berlaku pada sesi login yang baru; newgrp docker boleh dipakai sebagai jembatan sementara.
3. Ulangi pemeriksaan id -nG — nama docker kini harus tampil di daftar grup.
4. Uji akses tanpa sudo: docker ps kini menampilkan header tabel kontainer tanpa pesan izin apa pun.

Bedah Kasus Ruang Disk Habis #

Gejala ketiga datang dari arah yang tidak curiga: operasi pull atau build biasa tiba-tiba gagal dengan pesan singkat nan kejam:

$ docker pull nginx:1.29-alpine

Output yang Dihasilkan:

1.29-alpine: Pulling from library/nginx
...
docker: write /var/lib/docker/tmp/GetImageBlob918273645012: no space left on device

Diagnosisnya dua arah — berapa sisa ruang di disk, dan siapa yang memakannya:

$ df -h /var/lib/docker
$ docker system df

Output yang Dihasilkan:

Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1        40G   38G  1.2G  97% /

TYPE            TOTAL     ACTIVE    SIZE      RECLAIMABLE
Images          18        3         6.12GB    4.47GB (73%)
Containers      6         1         512MB     128MB (25%)
Local Volumes   5         2         894MB     410MB (45%)
Build Cache     102       0         2.33GB    2.33GB

Dua keluaran tersebut saling melengkapi: disk partisi sudah terisi 97 persen, dan docker system df merinci pelakunya — 18 image dengan hanya 3 yang aktif dipakai, ditambah build cache 2.33GB yang tidak dipakai satu pun. Kolom RECLAIMABLE menunjukkan berapa yang bisa direbut kembali dari masing-masing jenis. Pembersihannya mengikuti urutan dari yang paling aman:

1. Bersihkan build cache yang tidak terpakai: docker builder prune — pada contoh di atas, langkah ini saja sudah membebaskan 2.33GB.
2. Hapus image yang tidak dipakai container mana pun: docker image prune — versi dengan flag -a lebih agresif karena turut membuang image yang tidak direferensikan container mana pun; pastikan image penting sudah ter-push ke registry sebelumnya.
3. Aktifkan rotasi log pada daemon.json sebagaimana dibahas pada Chapter Konfigurasi Docker Engine — tanpa max-size dan max-file, log container akan mengulangi bencana ini secara berkala.
4. Bila kebutuhan memang melampaui kapasitas disk, pindahkan data-root ke partisi data yang lebih besar atau tambah kapasitas disknya.
5. Pantau ulang dengan docker system df dan df -h /var/lib/docker sampai angka Use% kembali sehat.

Bedah Kasus Service yang Dimatikan Paksa #

Gejala keempat paling membingungkan karena pesan kegagalannya nyaris tidak menyebut Docker:

$ sudo systemctl start docker

Output yang Dihasilkan:

Failed to start docker.service: Unit docker.service is masked.

Status masked berarti unit layanan ditautkan ke /dev/null — sistem sengaja melarangnya dinyalakan, biasanya karena kebijakan pengerasan keamanan administrator atau sisa skrip lama yang lupa dibuka. Kondisinya terlihat jelas pada status layanan:

$ systemctl status docker

Output yang Dihasilkan:

× docker.service
     Loaded: masked (Reason: Unit docker.service is masked.)
     Active: inactive (dead)

Berbeda dengan tiga kasus sebelumnya, di sini tidak ada yang salah dengan instalasi Docker — yang perlu dipulihkan adalah unit systemd-nya:

1. Buka penutupnya: sudo systemctl unmask docker.service.
2. Jalankan layanan: sudo systemctl start docker.
3. Aktifkan startup otomatis: sudo systemctl enable docker.
4. Selidiki siapa yang memasang masker — bila kebijakan keamanan tim yang mengharuskannya, bicaralah sebelum menyalakannya kembali; melepas masker tanpa izin sama saja dengan menembak kebijakan secara diam-diam.

Dengan delapan pola masalah di tangan dan empat diagnosis lengkap di kepala, kita menutup Section Instalasi dan Konfigurasi dengan bekal yang lengkap: Docker terpasang di Linux, Windows, dan macOS; daemon dan CLI terkonfigurasi sesuai kebutuhan; instalasi terverifikasi sehat; akses dikelola dengan sadar; dan kerusakan punya peta penanganannya. Seluruh perbekalan itu menyiapkan kita untuk babak berikutnya yang jauh lebih menyenangkan: menguasai perintah-perintah Docker itu sendiri. Section Dasar Docker CLI menanti, dibuka oleh Chapter Struktur Perintah Docker yang mengajarkan membaca perintah docker apa pun tanpa membuka dokumentasi terlalu sering.

Referensi #

• Linux post-installation steps — penanganan masalah umum pasca instalasi termasuk izin socket.
• Konfigurasi daemon Docker — rujukan resmi daemon.json untuk mencegah dan memperbaiki galat konfigurasi.
• Docker Desktop — catatan galat khas WSL 2 dan backend virtualisasi pada dokumentasi resmi.