Cara Memperbaiki Docker "No Space Left on Device": Panduan Lengkap

Error Docker "no space left on device" biasanya muncul di saat yang paling buruk: saat deployment, ketika build kritis berlangsung, atau saat menarik image penting. Saya pernah beberapa kali mengalami error ini, dan saya bisa katakan bahwa terburu-buru menghapus file tanpa diagnosis yang tepat adalah resep kehilangan data.

Yang membuat error ini menantang adalah jarang sekali memiliki satu penyebab. Anda bisa berhadapan dengan akumulasi image Docker, log container yang tak terkendali, inode yang habis karena jutaan file kecil, atau bahkan ruang "hantu" yang dikonsumsi oleh file yang sudah dihapus tetapi masih dibuka oleh proses yang berjalan. Setiap skenario membutuhkan solusi yang berbeda.

Itulah mengapa saya selalu menekankan diagnosis sebelum bertindak. Memahami akar masalah memungkinkan Anda menerapkan solusi yang tepat sasaran secara efisien dan menghindari gangguan pada lingkungan produksi. Dalam panduan ini, saya akan memandu Anda melalui pendekatan sistematis untuk mendiagnosis, menyelesaikan, dan mencegah masalah yang menjengkelkan ini.

Jika Anda baru mengenal Docker, saya merekomendasikan kursus Introduction to Docker kami yang bersifat praktis, yang membahas semua hal yang Anda butuhkan untuk memulai kontainerisasi.

Apa Itu Error Docker "No Space Left on Device"?

Ketika Docker menampilkan error ini, itu menandakan dua masalah mendasar pada penyimpanan sistem Anda:

• Kehabisan blok disk fisik
• Kehabisan inode

Memahami perbedaan antara kedua penyebab ini sangat penting untuk menerapkan solusi yang tepat.

Penyebab utama di balik error “no space left on device”

Penyebab pertama dan paling mudah dipahami adalah kehabisan blok disk fisik. Sistem file Anda kehabisan ruang penyimpanan aktual untuk menulis data. Ini skenario yang lebih intuitif: Anda hanya memenuhi disk dengan image Docker, container, log, atau file lainnya.

Penyebab kedua yang kurang jelas adalah kehabisan inode. Bahkan dengan ruang kosong gigabyte yang tersedia, sistem file Anda dapat kehabisan inode (struktur metadata yang digunakan untuk melacak file dan direktori). Setiap file dan direktori mengonsumsi satu inode, sehingga aplikasi yang membuat jutaan file kecil (pikirkan file sesi PHP atau direktori node_modules milik npm) dapat menghabiskan inode sementara ruang disk masih tersisa.

Memahami storage driver overlay2

Docker umumnya menggunakan storage driver overlay2, yang berbasis OverlayFS Linux. OverlayFS melapiskan banyak direktori pada satu host dan menyajikannya sebagai satu sistem file terpadu. Lapisan image di-mount sebagai direktori bawah yang read-only, sementara setiap container yang berjalan menambahkan lapisan atas yang tipis dan writable. Tampilan gabungan diekspos sebagai satu direktori ke container.

Driver overlay2 secara native mendukung hingga 128 lapisan OverlayFS bagian bawah secara teoritis, tetapi penyimpanan lapisan Docker memberlakukan batas praktis 125 lapisan dasar per image. Ini memungkinkan komposisi image yang efisien dan peningkatan performa untuk operasi seperti docker build dan docker commit. 

Meskipun overlay2 dirancang untuk mengonsumsi lebih sedikit inode daripada storage driver sebelumnya, lingkungan Docker yang berulang kali membangun image, menarik lapisan, atau membuat container tetap dapat memberi tekanan besar pada blok disk dan inode seiring waktu, terutama saat image atau lapisan aplikasi berisi banyak file kecil.

Bagaimana error ini muncul bergantung pada lingkungan deployment:

• Pada system Linux native, ini memengaruhi sistem file yang mendukung /var/lib/docker. 

• Pada Docker Desktop untuk Windows atau macOS, keterbatasan ada di dalam image disk mesin virtual Docker (seperti file .raw atau .vhdx), yang menambahkan pertimbangan tambahan saat merebut kembali atau mengubah ukuran penyimpanan.

Langkah 1: Diagnosis Akar Masalah

Sebelum menghapus apa pun, saya selalu memulai dengan diagnosis menyeluruh. Investasi beberapa menit ini dapat menghemat berjam-jam penelusuran masalah dan mencegah kehilangan data yang tidak disengaja.

Periksa kapasitas tingkat sistem

Mulailah dengan memeriksa penggunaan disk host Anda dengan df -H (df singkatan dari disk free):

df -HDidukung oleh

Pemeriksaan disk bebas di WSL

Perintah ini menampilkan penggunaan disk dalam format yang mudah dibaca manusia. Cari sistem file yang berada pada atau mendekati kapasitas 100%. 

Pada instalasi Linux native, perhatikan secara khusus partisi tempat /var/lib/docker berada. Ini biasanya partisi root Anda (/) atau partisi Docker khusus. 

Pada Docker Desktop (Windows/Mac), carilah mount sistem file utama (biasanya /dev/sdf atau sejenisnya), yang menampung data VM Docker, alih-alih referensi spesifik ke /var/lib/docker, karena Docker berjalan di dalam mesin virtual.

Selanjutnya, periksa kehabisan inode menggunakan df -i:

df -iDidukung oleh

Pemeriksaan kehabisan inode

Jika Anda melihat penggunaan inode 100% (IUse%) pada sistem file mana pun, Anda telah menemukan masalahnya. Skenario ini mengejutkan umum di server build dan lingkungan CI/CD, di mana Docker berulang kali membuat dan menghancurkan container dengan banyak file kecil.

Analisis penggunaan khusus Docker

Sekarang setelah kita memastikan apakah masalahnya ruang disk atau inode, mari telusuri lebih dalam dan periksa konsumsi sumber daya spesifik Docker. Perintah docker system df memberikan ringkasan tingkat tinggi yang berlaku universal di semua instalasi Docker:

docker system dfDidukung oleh

Keluaran ini merinci penggunaan ruang menjadi empat kategori: image, container, volume lokal, dan build cache.

Kolom RECLAIMABLE sangat bernilai. Ini menunjukkan berapa banyak ruang yang dapat Anda pulihkan tanpa memengaruhi container yang berjalan. Memahami perbedaan antara dua metrik ini adalah kuncinya: ruang "aktif" saat ini digunakan oleh container yang berjalan, sementara ruang "reclaimable" dapat dibebaskan dengan aman.

Untuk detail yang lebih granular, tambahkan flag verbose:

docker system df -vDidukung oleh

Analisis penggunaan Docker

Output verbose ini mencantumkan setiap image, container, dan volume beserta ukurannya, memberikan rincian granular yang Anda butuhkan untuk mengidentifikasi pemakan ruang. Berikut yang perlu diperhatikan pada setiap bagian:

• Images: Menampilkan ukuran setiap image dan apakah saat ini digunakan. Cari image besar yang tidak digunakan atau duplikat dengan tag berbeda. Image yang ditandai "unused" dapat dihapus dengan aman tanpa memengaruhi container yang berjalan.

• Containers: Menampilkan ukuran lapisan writable untuk setiap container. Jika container yang berhenti menunjukkan SIZE signifikan di sini, berarti ia menulis data ke sistem file-nya. Kolom CREATED membantu mengidentifikasi container lama yang mungkin terlupakan.

• Volumes: Mencantumkan ukuran volume dan apakah sedang digunakan. Volume yang ditandai tidak digunakan adalah kandidat aman untuk dihapus, meskipun selalu verifikasi bahwa volume tersebut tidak berisi data penting sebelum memangkasnya.

• Build Cache: Sering menjadi konsumen terbesar dan kerap terlewatkan. Ini adalah lapisan perantara dari operasi docker build yang disimpan Docker untuk mempercepat build berikutnya.

Perintah spesifik OS

Untuk pengguna Linux native yang menginginkan wawasan sistem file lebih dalam, Anda dapat secara opsional memeriksa subdirektori secara langsung untuk menunjukkan subdirektori mana (overlay2, containers, volumes) yang paling banyak mengonsumsi ruang:

sudo du -h --max-depth=1 /var/lib/docker | sort -hDidukung oleh

Namun, untuk pengguna Docker Desktop, /var/lib/docker berada di dalam mesin virtual tersembunyi Docker dan tidak dapat diakses secara langsung. Kabar baiknya adalah docker system df -v memberikan semua informasi yang dapat ditindaklanjuti yang Anda butuhkan, terlepas dari platform Anda, sehingga menjadi pendekatan diagnosis paling andal.

Langkah 2: Bersihkan Sistem dengan Docker Prune 

Setelah mengidentifikasi di mana ruang dikonsumsi, saya dapat merebutnya kembali dengan aman menggunakan perintah pruning bawaan Docker. Operasi ini dirancang untuk hanya menghapus sumber daya yang tidak digunakan, meminimalkan risiko mengganggu layanan yang berjalan.

Memangkas sumber daya dangling

Docker membedakan antara sumber daya "dangling" dan "unused". Image dangling adalah image tanpa tag dan tanpa referensi container. Biasanya, lapisan perantara dari build yang gagal atau sudah tergantikan. Ini selalu aman untuk dihapus.

Mulailah dengan perintah prune dasar:

docker system pruneDidukung oleh

Ini menghapus semua container yang tidak digunakan, jaringan, dan image dangling. Ini tidak akan menyentuh image ber-tag atau volume kecuali ditentukan secara eksplisit. Docker akan meminta konfirmasi sebelum melanjutkan.

Untuk lebih agresif dan menghapus semua image yang tidak digunakan (bukan hanya yang dangling), tambahkan flag --all:

docker system prune --allDidukung oleh

Docker system prune

Perintah ini menghapus image apa pun yang saat ini tidak terkait dengan container. Berhati-hatilah: deployment berikutnya perlu menarik ulang image yang dihapus.

Jika Anda ingin menyertakan volume dalam pembersihan (yang berisi data persisten), tambahkan flag --volumes:

docker system prune --all --volumesDidukung oleh

Peringatan: Ini akan menghapus permanen data di volume yang tidak digunakan. Selalu verifikasi volume tidak berisi data penting sebelum menggunakan flag ini.

Kelola build cache

Di sinilah hal menjadi menarik. Build cache, yang menyimpan lapisan perantara dari operasi Docker build, sering menjadi konsumen ruang terbesar, namun docker system prune sengaja mengecualikannya untuk menjaga performa build.

Untuk menargetkan build cache secara khusus:

docker builder pruneDidukung oleh

Jika Anda ingin selektif dan mempertahankan lapisan cache terbaru, gunakan filter berbasis waktu:

docker builder prune --filter "until=24h"Didukung oleh

Ini hanya menghapus lapisan cache yang berusia lebih dari 24 jam, menjaga pekerjaan terbaru Anda tetap utuh.

Bersihkan volume dengan aman

Volume membutuhkan kehati-hatian ekstra karena berisi data persisten, seperti database, file yang diunggah, dan state aplikasi. Menghapus volume yang salah berarti kehilangan data permanen.

Pertama, identifikasi volume dangling (yang tidak terpasang pada container mana pun):

docker volume ls -f dangling=trueDidukung oleh

Tinjau daftar ini dengan saksama. Jika Anda yakin volume ini tidak diperlukan, pangkas:

docker volume pruneDidukung oleh

Docker akan meminta konfirmasi sebelum melanjutkan. Jika ragu, cadangkan volume sebelum memangkas.

Langkah 3: Tangani Kelebihan File Log Docker

Log container diam-diam dapat mengonsumsi ruang disk dalam jumlah besar, terkadang melebihi 50 GB per container.

Identifikasi file log yang membengkak

Logging driver json-file bawaan Docker menangkap semua stdout dan stderr container ke file JSON. Tanpa pengaturan ukuran maksimum (bawaan -1, tanpa batas), file ini tumbuh tanpa terkendali.

Periksa ukuran container di semua lingkungan:

docker ps -a --format "table {{.ID}}\t{{.Names}}\t{{.Size}}"Didukung oleh

Untuk memeriksa ukuran file log container tertentu:

ls -lh $(docker inspect --format='{{.LogPath}}' <container-name>)Didukung oleh

Khusus Linux native, temukan file log terbesar secara langsung:

sudo find /var/lib/docker/containers/ -name "*-json.log" -exec du -h {} + | sort -h | tail -10Didukung oleh

Jika docker logs menjadi lambat atau container gagal mulai, log yang terlalu besar kemungkinan menjadi penyebabnya. Untuk mengatasinya, Anda dapat memangkas (truncate) log.

Pangkas log dengan aman

Memangkas log akan menyediakan lebih banyak ruang. Namun, jangan pernah menghapus file log dengan rm saat container berjalan. Docker daemon menahan handle file terbuka ke log ini, dan menghapusnya menciptakan file "deleted but open" yang terus mengonsumsi ruang hingga daemon di-restart.

Pendekatan aman adalah memangkas log menjadi nol:

sudo truncate -s 0 $(docker inspect --format='{{.LogPath}}' <container-name>)Didukung oleh

Ini langsung melepaskan ruang tanpa merusak handle file. Container terus mencatat ke file yang sama.

Langkah 4: Penelusuran Masalah Lanjutan dan Isu Tersembunyi

Ketika pembersihan standar gagal, kemungkinan Anda berurusan dengan salah satu isu yang kurang umum namun sama berdampaknya berikut:

• Kehabisan inode: Sistem file Anda kehabisan struktur metadata file meski ruang disk masih ada

• File yang dihapus tetapi masih terbuka: Proses yang menahan handle file pada file yang dihapus, menciptakan penggunaan ruang "hantu"

• Pembengkakan disk virtual Docker Desktop: File .raw atau .vhdx di host tidak menyusut setelah Anda menghapus data di dalam VM

Mari tangani masing-masing skenario ini secara sistematis.

Mengatasi kehabisan inode

Ini dapat disebabkan oleh aplikasi yang membuat jutaan file kecil, seperti sesi PHP, node_modules npm, atau artefak build yang mengonsumsi inode dengan laju mengkhawatirkan.

Pertama, verifikasi kehabisan inode:

df -iDidukung oleh

Menggunakan perintah Docker (semua lingkungan):

docker ps -a | wc -l             # Cek jumlah container
docker images | wc -l         # Cek jumlah image
docker image prune -a      # Hapus image yang tidak digunakan untuk membebaskan inodeDidukung oleh

Untuk instalasi Linux, identifikasi direktori yang padat inode:

for dir in /var/lib/docker/*/; do
    echo "$dir: $(sudo find $dir -type f 2>/dev/null | wc -l) files"
doneDidukung oleh

Menghapus image yang tidak digunakan dengan docker rmi juga membebaskan inode. Untuk masalah di tingkat aplikasi, terapkan pembersihan di dalam container atau gunakan mount volume untuk file sementara.

Tangani file yang dihapus tetapi masih terbuka (khusus Linux)

Ketika file dihapus sementara proses masih membukanya, sistem file tidak melepaskan ruang hingga proses menutup handle file (penggunaan ruang "hantu").

Untuk pengguna Linux, Anda dapat memverifikasi apakah ini terjadi dengan mencari entri "deleted" dalam daftar file terbuka.

Pertama, identifikasi file-file ini:

sudo lsof | grep deleted Didukung oleh

File Docker yang dihapus

Lalu, untuk melepaskan ruang, restart proses tertentu (menggunakan PID dari lsof) atau restart Docker. Setelah Anda melakukan ini, jika Anda menjalankan perintah lagi, file tersebut tidak akan muncul lagi, yang berarti telah dihapus dengan benar.

Sekarang mari kita bahas strategi penelusuran masalah lanjutan terakhir, yang hanya berlaku untuk Docker Desktop: mengelola disk virtual.

Mengelola disk virtual Docker Desktop

Docker Desktop menyimpan data dalam file disk virtual (.raw di Mac, .vhdx di Windows) yang tumbuh secara dinamis tetapi tidak menyusut secara otomatis saat Anda menghapus data. Anda memangkas image dan container, melihat ruang kosong di dalam VM meningkat, tetapi disk host Anda tetap penuh.

Untuk mengelolanya, pendekatan paling aman adalah menggunakan fstrim untuk mengompakkan disk tanpa kehilangan data:

docker run --privileged --pid=host alpine nsenter -t 1 -m -u -i -n fstrim /Didukung oleh

Perintah ini memangkas sistem file VM Docker Desktop, melepaskan blok yang tidak digunakan kembali ke sistem host Anda. Image, container, dan volume Anda tetap utuh.

Sebagai alternatif, jika Anda ingin memulai benar-benar dari awal (ini menghapus semua data), gunakan Docker Desktop Settings → Troubleshoot → Reset to factory defaults. 

Peringatan: Ini bersifat destruktif dan menghapus semua image, container, volume, dan pengaturan. Ini sebaiknya menjadi pilihan terakhir, jika semua cara lain gagal.

Reset ke setelan pabrik

Langkah 5: Cegah Error Docker “No Space Left on Device”

Sekarang setelah kita menyelesaikan krisis langsung, mari terapkan perubahan struktural untuk mencegahnya terulang. Konfigurasi ini memerlukan perencanaan tetapi memberikan keuntungan besar bagi stabilitas sistem.

Pindahkan direktori root Docker (khusus Linux)

Pengguna Docker Desktop tidak dapat dengan mudah mengubah lokasi data root. Sebagai gantinya, Anda dapat:

• Tingkatkan ruang disk: Gunakan metode pemadatan disk virtual yang dijelaskan pada Langkah 4

• Untuk backend WSL2: Kelola batasan melalui file .wslconfig seperti yang ditunjukkan di Docker Desktop Settings → Resources

Namun, jika Anda berada di Linux dan partisi root Anda terbatas, tetapi Anda memiliki partisi yang lebih besar tersedia (mungkin disk data khusus), memindahkan direktori data Docker adalah solusi permanen.

Pertama, hentikan Docker:

sudo systemctl stop dockerDidukung oleh

Edit /etc/docker/daemon.json untuk menentukan lokasi baru:

{
  "data-root": "/mnt/docker-data"
}Didukung oleh

Migrasikan data yang ada untuk mempertahankan image dan container Anda:

sudo rsync -aP /var/lib/docker/ /mnt/docker-data/Didukung oleh

Terakhir, mulai ulang Docker:

sudo systemctl start dockerDidukung oleh

Docker sekarang menyimpan semua data di lokasi baru. Verifikasi dengan docker info | grep "Docker Root Dir" untuk mengonfirmasi path ke direktori baru.

Konfigurasikan rotasi log global

Rotasi log adalah strategi pencegahan paling efektif yang pernah saya terapkan. Secara bawaan, driver json-file Docker memiliki max-size: -1 (tanpa batas), yang merupakan bencana yang menunggu terjadi di produksi.

Untuk instalasi Linux native, edit /etc/docker/daemon.json untuk menerapkan batas secara global:

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  }
}Didukung oleh

Setelah mengedit file, restart Docker.

Untuk pengguna Docker Desktop, Anda tidak mengedit /etc/docker/daemon.json secara langsung. Sebagai gantinya:

1. Buka Docker Desktop
2. Buka Settings → Docker Engine
3. Anda akan melihat editor JSON dengan konfigurasi daemon
4. Tambahkan pengaturan rotasi log ke JSON yang ada:

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  }
}Didukung oleh

Terakhir, klik Apply & Restart.

Contoh konfigurasi ini membatasi setiap container hingga tiga file log berukuran 10MB masing-masing (total 30MB per container).

Catatan penting: Pengaturan ini hanya berlaku untuk container yang baru dibuat. Container yang sudah ada mempertahankan konfigurasi log aslinya. Anda harus membuat ulang container untuk menerapkan batas baru.

Untuk kompresi dan performa yang lebih baik, pertimbangkan logging driver local:

{
  "log-driver": "local",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3",
    "compress": "true"
  }
}Didukung oleh

Selain itu, Anda juga dapat menimpa pengaturan log per layanan di docker-compose.yml:

services:
  web:
    image: nginx
    logging:
      driver: "json-file"
      options:
        max-size: "50m"
        max-file: "5"Didukung oleh

Otomatiskan pemeliharaan

Praktik baik lainnya adalah mengotomatiskan proses tertentu. Sering dikatakan bahwa pencegahan lebih baik daripada manajemen krisis. Oleh karena itu, saya merekomendasikan mengotomatiskan pembersihan dengan cron job yang berjalan saat jendela pemeliharaan:

# Buat skrip pembersihan
sudo cat > /usr/local/bin/docker-cleanup.sh << 'EOF'
#!/bin/bash
docker system prune -f
docker builder prune -f --filter "until=168h"
EOF

sudo chmod +x /usr/local/bin/docker-cleanup.sh

# Tambahkan ke crontab untuk berjalan mingguan pada hari Minggu pukul 2 pagi
echo "0 2 * * 0 /usr/local/bin/docker-cleanup.sh" | sudo crontab -Didukung oleh

Skrip ini membuat tugas terjadwal yang secara otomatis menghapus container yang berhenti dan data yang tidak digunakan setiap hari Minggu pukul 2 pagi. Ini juga membersihkan dengan aman lapisan build cache yang lebih lama dari satu minggu (168 jam) untuk mencegah penggunaan disk tumbuh tanpa batas.

Selain itu, optimalkan Dockerfile Anda menggunakan multi-stage builds untuk meminimalkan ukuran image. Multi-stage builds memungkinkan Anda menggunakan satu tahap untuk kompilasi dan build (dengan semua tools pengembangan yang berat), lalu menyalin hanya artefak final ke tahap produksi yang bersih dan minimal. 

Ini menghilangkan dependensi build, kode sumber, dan file perantara dari image final Anda, secara dramatis mengurangi ukurannya dan permukaan serangan.

# Build stage
FROM node:16 AS builder
WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .
RUN npm run build

# Production stage
FROM node:16-alpine
WORKDIR /app
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/node_modules ./node_modules
CMD ["node", "dist/index.js"]Didukung oleh

Pola ini mengurangi ukuran image produksi dengan mengecualikan tools build dan kode sumber.

Penutup

Memperbaiki error "no space left on device" mengikuti pola yang dapat diprediksi: diagnosis terlebih dahulu untuk memahami apakah Anda berurusan dengan blok disk atau inode, memangkas dengan aman untuk merebut kembali ruang tanpa kehilangan data, lalu mengoptimalkan konfigurasi untuk mencegahnya terulang.

Selama bertahun-tahun mengelola lingkungan Docker, saya belajar bahwa rotasi log adalah strategi pencegahan paling efektif. Konfigurasi sederhana daemon.json dapat mencegah sebagian besar insiden kehabisan ruang.

Saya mendorong Anda untuk mengaudit konfigurasi daemon.json Anda sekarang. Jika Anda belum menyetel max-size dan max-file untuk logging driver Anda, tambahkan segera. Anda akan berterima kasih pada diri sendiri di masa depan saat berhasil menghindari krisis ruang berikutnya.

Siap menjadi ahli Docker? Langkah berikutnya adalah mendaftar di Containerization and Virtualization with Docker and Kubernetes skill track, yang sangat saya rekomendasikan.