Menganalisis dan Mengatasi Error "No Space Left on Device" Saat Deploy Docker

Proses deployment adalah momen krusial bagi setiap pengembang. Namun, tidak jarang proses ini terhenti oleh error yang tampak sepele namun bisa membuat frustrasi. Salah satu error yang paling umum adalah no space left on device. Log yang Anda berikan adalah contoh sempurna dari kasus ini, di mana proses build Docker yang tampaknya berjalan lancar tiba-tiba gagal di tengah jalan.

Mari kita bedah masalah ini, mulai dari analisis log hingga solusi praktis yang bisa diterapkan.

## Analisis Masalah: Membedah Log Kegagalan

Sekilas, log menunjukkan proses yang standar: menarik kode dari Git, lalu membangun image Docker. Proses build menggunakan multi-stage build, yang ditandai dengan adanya tahap ui-builder dan runner. Ini adalah praktik yang sangat baik untuk menghasilkan image akhir yang ramping.

Semua berjalan lancar hingga tahap ke-11 (ui-builder 6/6), di mana aplikasi berhasil di-build oleh Vite. Namun, bencana terjadi pada tahap berikutnya:

#12 [runner  3/13] COPY --from=ui-builder /app/dist/public ./dist/public
#12 ERROR: failed to mkdir /var/lib/docker/overlay2/.../merged/app/dist/public/assets: mkdir /app/dist/public/assets: no space left on device
------
 > [runner  3/13] COPY --from=ui-builder /app/dist/public ./dist/public:
------
failed to solve: ResourceExhausted: failed to mkdir ...: no space left on device

Penyebab Utama:

Pesan error ini sangat jelas: server tempat Anda menjalankan proses build Docker kehabisan ruang penyimpanan (disk).

Di mana Masalahnya? Error terjadi di direktori /var/lib/docker/overlay2/.... Ini adalah lokasi internal Docker di server host (bukan di dalam kontainer) yang digunakan untuk menyimpan layers dari image. Saat perintah COPY dijalankan, Docker mencoba membuat layer baru untuk image runner, tetapi gagal karena tidak ada lagi ruang disk yang tersedia di server.
Kenapa Bisa Terjadi? Docker dapat menghabiskan banyak ruang disk, terutama karena:
- Build Cache: Setiap perintah dalam Dockerfile (seperti RUN, COPY) membuat sebuah layer yang disimpan dalam cache. Jika tidak dikelola, cache ini bisa membengkak.
- Image Tidak Terpakai (Unused/Dangling Images): Setiap kali Anda membangun image baru tanpa menghapus yang lama, image lama akan menumpuk.
- Kontainer yang Berhenti (Stopped Containers): Kontainer yang sudah tidak berjalan tetap memakan ruang disk.
- Volume Tidak Terpakai (Unused Volumes): Volume yang tidak lagi terhubung ke kontainer manapun juga akan menumpuk.

Proses build Anda, meskipun menggunakan multi-stage, tetap membutuhkan ruang sementara yang cukup besar di server untuk tahap ui-builder sebelum akhirnya menyalin artefak ke tahap runner. Kegagalan ini adalah "puncak gunung es" dari akumulasi data Docker di server Anda.

## Solusi: Dari Perbaikan Cepat Hingga Pencegahan

Ada beberapa langkah yang bisa Anda ambil, mulai dari yang paling cepat hingga strategi jangka panjang.

### 1. Solusi Cepat: Bersihkan "Sampah" Docker 🧹

Ini adalah langkah pertama dan paling efektif untuk mengatasi masalah secara langsung. Gunakan perintah bawaan Docker untuk membersihkan sumber daya yang tidak terpakai.

Jalankan perintah ini di terminal server Anda:

docker system prune -a --volumes

Penjelasan Perintah:

docker system prune: Perintah utama untuk membersihkan.
-a (all): Akan menghapus semua image yang tidak digunakan oleh setidaknya satu kontainer (bukan hanya dangling images). Hati-hati jika Anda menyimpan image spesifik untuk tujuan lain.
--volumes: Akan menghapus semua volume yang tidak digunakan. PERINGATAN: Pastikan tidak ada data penting dalam volume yang tidak terhubung ke kontainer aktif.

Perintah ini biasanya akan membebaskan ruang disk dalam jumlah yang signifikan. Setelah menjalankannya, coba proses deploy Anda kembali.

### 2. Optimalisasi Proses Build

Meskipun Anda sudah menggunakan multi-stage build, ada beberapa hal yang bisa dioptimalkan untuk mengurangi penggunaan disk saat proses build.

Gunakan .dockerignore Secara Efektif Pastikan Anda memiliki file .dockerignore di root project Anda. File ini berfungsi seperti .gitignore, mencegah file atau direktori yang tidak perlu disalin ke dalam konteks build Docker. Ini mempercepat proses build dan mengurangi ukuran layer.

Contoh file .dockerignore untuk proyek Node.js/Bun:

.git
.github
node_modules
dist
logs
.env
README.md

Dengan ini, perintah COPY . . di Dockerfile Anda tidak akan menyalin direktori node_modules atau dist dari local Anda, yang bisa sangat besar.

### 3. Manajemen Kapasitas Server (Jangka Panjang)

Jika masalah ini terus berulang, berarti pembersihan saja tidak cukup.

a. Monitoring Ruang Disk Secara rutin periksa penggunaan disk di server Anda dengan perintah:

df -h

Ini akan menampilkan penggunaan disk untuk semua filesystem yang terpasang. Perhatikan partisi yang digunakan oleh /var/lib/docker. Jika sering mendekati 85-90%, Anda perlu mengambil tindakan.

b. Menambah Kapasitas Disk Solusi paling mendasar adalah menambah kapasitas penyimpanan server Anda. Jika Anda menggunakan penyedia cloud seperti AWS, GCP, atau DigitalOcean, proses ini biasanya cukup mudah dilakukan melalui dashboard mereka dengan me-resize volume disk.

c. Jadwalkan Pembersihan Otomatis Anda dapat membuat cron job di server Anda untuk menjalankan docker system prune secara berkala (misalnya, setiap minggu). Ini adalah cara proaktif untuk mencegah penumpukan "sampah" Docker.

Contoh cron job yang berjalan setiap Minggu jam 3 pagi:

0 3 * * 0 /usr/bin/docker system prune -af --volumes > /dev/null 2>&1

Flag -f ditambahkan untuk menjalankan perintah tanpa meminta konfirmasi.

## Kesimpulan

Error no space left on device saat deploy Docker adalah masalah umum yang sumbernya ada di server host, bukan pada kode aplikasi Anda. Analisis log menunjukkan kegagalan terjadi saat Docker mencoba menulis layer baru ke disk yang sudah penuh.

Solusinya melibatkan kombinasi dari tindakan reaktif (membersihkan sumber daya Docker dengan docker system prune) dan strategi proaktif (menggunakan .dockerignore, memonitor kapasitas, dan mempertimbangkan penambahan ruang disk). Dengan menerapkan praktik ini, Anda dapat memastikan proses deployment berjalan lebih lancar dan andal. 🚀