# 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: ```bash #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)**. 1. **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. 2. **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: ```bash 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: ```typescript .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: ```bash 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: ```typescript 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. ๐Ÿš€