--- title: "Kesalahan Umum Menjalankan Docker di Produksi" description: "Tag latest, data di luar volume, port yang lolos firewall, log yang memenuhi disk: kesalahan Docker di produksi yang sering terjadi dan cara mencegahnya." url: "https://nivelva.com/insight/kesalahan-docker-di-produksi" category: "Server \u0026 Infrastruktur" tags: ["docker","docker compose","produksi","devops","vps"] author: "Theresia Candiawan" published: "2026-11-07T01:42:00+07:00" updated: "2026-11-07T01:42:00+07:00" language: "id" publisher: "Nivelva (https://nivelva.com)" --- # Kesalahan Umum Menjalankan Docker di Produksi > **Jawaban singkat:** Kesalahan Docker produksi yang paling sering: memakai tag latest, tanpa restart policy, data disimpan di dalam container, port dipublikasikan sehingga melewati firewall, log tanpa batas, tanpa batas resource, dan image yang tidak pernah diperbarui. Semuanya bisa dicegah lewat file compose yang rapi. Docker di produksi jarang gagal karena Docker-nya, melainkan karena kebiasaan dari laptop developer yang terbawa ke server. Di komputer sendiri, container yang hilang datanya atau berhenti saat restart hanya bikin kesal. Di server yang melayani pelanggan, akibatnya bisa berupa database kosong setelah update, aplikasi mati tengah malam, atau disk penuh oleh log. Tujuh kesalahan di bawah ini muncul berulang kali, dan hampir semuanya bisa dicegah dengan beberapa baris di `compose.yaml`. Kalau kamu masih baru dengan konsep container, mulai dulu dari [apa itu Docker](https://nivelva.com/insight/apa-itu-docker). ## 1. Memakai tag latest `image: postgres:latest` terlihat praktis, tapi tag `latest` tidak berarti "versi stabil". Ia hanya penunjuk ke image yang terakhir diberi tag itu oleh pembuatnya. Begitu versi mayor baru dirilis, `docker compose pull` berikutnya bisa langsung membawamu ke sana tanpa peringatan. Untuk database, lompatan seperti itu bisa membuat container gagal start karena format data berbeda antar versi mayor. Untuk aplikasi, perubahan perilaku muncul tanpa kamu sadari kapan masuknya. Cara yang lebih aman: tulis versi yang jelas, misalnya `postgres:18` atau bahkan versi minornya. Naikkan versi dengan sengaja, setelah membaca catatan rilis. ## 2. Tidak memasang restart policy Tanpa restart policy, container yang crash akan tetap mati. Begitu pula setelah server reboot karena pembaruan kernel: Docker hidup lagi, tapi container kamu tidak. Tambahkan satu baris ini di setiap service: ``` restart: unless-stopped ``` Container akan dihidupkan ulang otomatis kecuali kamu sendiri yang menghentikannya. Pastikan juga service Docker aktif saat boot dengan `systemctl is-enabled docker`. ## 3. Menyimpan data di dalam container Ini kesalahan yang paling mahal. File yang ditulis di dalam container ikut hilang saat container dihapus dan dibuat ulang, dan itu terjadi setiap kali kamu memperbarui image. Semua yang perlu bertahan harus berada di volume atau bind mount: folder data database, file unggahan pengguna, konfigurasi yang diubah dari dalam aplikasi. Contoh untuk image resmi PostgreSQL 18: ``` volumes: - pgdata:/var/lib/postgresql ``` Perhatikan, mulai image PostgreSQL 18 titik volume-nya pindah dari `/var/lib/postgresql/data` ke `/var/lib/postgresql`. Contoh lama untuk versi 17 ke bawah masih memakai jalur `/data`. Inilah alasan selalu mengecek dokumentasi tiap image untuk tahu folder mana yang harus dipisahkan. Lalu ingat: volume di server yang sama belum termasuk backup. Kalau disk rusak, volume ikut hilang. Prinsipnya dibahas di [backup website otomatis](https://nivelva.com/insight/backup-website-otomatis). ## 4. Port yang dipublikasikan melewati firewall Banyak orang mengaktifkan UFW, menolak port 5432, lalu merasa database aman. Padahal dokumentasi resmi Docker menyebutkan bahwa port container yang dipublikasikan melewati aturan ufw maupun firewalld. Docker menulis aturan iptables-nya sendiri. Akibatnya, `ports: - "5432:5432"` bisa membuat database terbuka ke internet walau `ufw status` bilang sebaliknya. > **Cara yang aman:** > > Untuk layanan internal, jangan publikasikan port sama sekali. Container dalam satu jaringan compose sudah bisa saling memanggil lewat nama service. Bila memang perlu diakses dari host, ikat ke localhost: `"127.0.0.1:5432:5432"`. Aturan firewall tambahan untuk container ditaruh di chain `DOCKER-USER`. Hanya reverse proxy (Nginx, Caddy, atau Traefik) yang perlu mempublikasikan port 80 dan 443. Daftar port yang wajar terbuka ada di [port penting di server](https://nivelva.com/insight/port-penting-server). ## 5. Log tanpa batas yang memenuhi disk Driver log bawaan Docker, `json-file`, menulis log ke file di host tanpa rotasi. Dokumentasi Docker sendiri mengingatkan file ini terus membesar dan bisa menghabiskan disk. Aplikasi yang cerewet bisa menghasilkan gigabyte log dalam beberapa minggu, lalu suatu hari database berhenti karena tidak bisa menulis. Ada dua jalan. Batasi per service: ``` logging: driver: json-file options: max-size: "10m" max-file: "3" ``` Atau atur default untuk semua container di `/etc/docker/daemon.json`, misalnya memakai driver `local` yang merotasi log secara default. Perubahan daemon hanya berlaku untuk container yang dibuat setelahnya. Cara membaca dan merapikan log lain di server ada di [lokasi log penting di Linux](https://nivelva.com/insight/log-linux-penting). ## 6. Tidak membatasi resource Secara default, container boleh memakai CPU dan RAM sebanyak yang tersedia di host. Satu container dengan kebocoran memori bisa memicu OOM killer Linux, dan yang dimatikan belum tentu container itu. Bisa jadi database-mu. Batasi container yang rawan, terutama aplikasi yang memproses file besar atau menjalankan antrean pekerjaan: ``` deploy: resources: limits: memory: 1g cpus: "1.0" ``` Pilih angkanya dari pemantauan pemakaian nyata, misalnya `docker stats` selama beberapa hari, bukan tebakan. ## 7. Image yang tidak pernah diperbarui Container yang berjalan setahun tanpa disentuh juga membawa celah keamanan setahun yang tidak ditambal: dari library sistem di image dasar sampai aplikasinya sendiri. Memperbarui host dengan `apt upgrade` tidak memperbarui isi container. Jadwalkan pembaruan rutin: tarik image versi patch terbaru, uji, lalu jalankan ulang. ``` docker compose pull docker compose up -d docker image prune ``` Karena tag sudah kamu kunci di versi tertentu (poin 1), langkah ini hanya membawa pembaruan di jalur versi yang sama, bukan lompatan mayor. ## Kesalahan mana yang paling berbahaya? Tidak semuanya setara. Ringkasan berikut membantu menentukan urutan perbaikan bila kamu mewarisi server yang berantakan. | Kesalahan | Akibat terburuk | Perbaikan | |:--|:--|:--| | Data di dalam container | Data hilang saat update | Volume untuk semua data | | Port dipublikasikan | Database terbuka ke internet | Jangan publikasikan, atau ikat ke 127.0.0.1 | | Log tanpa batas | Disk penuh, layanan berhenti | Rotasi log per service atau di daemon | | Image tidak diperbarui | Celah keamanan menumpuk | Jadwal pull dan uji rutin | | Tag latest | Lompatan versi tak terduga | Kunci versi image | | Tanpa batas resource | Satu container menjatuhkan server | Limit memori dan CPU | | Tanpa restart policy | Layanan mati setelah reboot | `restart: unless-stopped` | Satu kebiasaan menyatukan semuanya: simpan konfigurasi di file compose yang tercatat (misalnya di Git), bukan di perintah `docker run` panjang yang hanya ada di riwayat terminal. Dengan begitu, server baru bisa dibangun ulang dengan hasil yang sama. ## Pertanyaan yang sering diajukan ### Apakah docker compose cukup untuk produksi atau harus Kubernetes? Untuk satu atau beberapa server dengan aplikasi yang tidak terlalu banyak, compose sudah memadai asalkan dikonfigurasi dengan rapi. Kubernetes masuk akal saat kamu butuh penjadwalan di banyak node dan punya tim yang siap merawatnya. ### Bagaimana menjalankan database dengan aman di Docker? Simpan data di volume, kunci versi image, jangan publikasikan port ke internet, dan buat backup logis (misalnya pg_dump) secara terjadwal ke lokasi lain. Snapshot volume saja tidak selalu konsisten bila diambil saat database aktif menulis. ### Apakah user di grup docker sama dengan root? Secara praktis ya. Dokumentasi Docker menyatakan grup docker memberi hak setara root. Jangan masukkan akun yang tidak benar-benar perlu ke grup itu, atau pertimbangkan mode rootless. Kalau waktumu terbatas, perbaiki dua hal hari ini juga: pastikan semua data ada di volume dan tidak ada port database yang dipublikasikan. Lima lainnya bisa menyusul minggu ini. ## Sumber - - - - --- Diterbitkan oleh Nivelva Insight (https://nivelva.com/insight/). Artikel ini: https://nivelva.com/insight/kesalahan-docker-di-produksi Kontak Nivelva: WhatsApp https://wa.me/6285111245007, email hello@nivelva.com