Docker Compose down vs stop: Apa Bedanya?

Jawaban singkat

docker compose stop menghentikan container dan membiarkannya tetap tersimpan di disk. docker compose down menghentikan container, lalu menghapus container tersebut serta network yang dibuat Compose untuk project. Tidak satu pun dari kedua perintah ini menyentuh named volume. Database Anda hanya terhapus jika Anda menambahkan -v, seperti pada docker compose down -v. Opsi ini menghapus named volume yang dideklarasikan di bagian volumes pada file Compose.

Itulah seluruh perbedaannya dalam satu paragraf. Bagian selanjutnya membuktikannya dengan volume Postgres yang dapat Anda pantau tetap ada setelah down dan hilang setelah down -v, serta menjelaskan dua kasus yang memerlukan --force-recreate.

docker compose stop: container tetap ada

stop mengirim SIGTERM ke proses utama di setiap container, menunggu, lalu mengirim SIGKILL jika proses tersebut masih berjalan. Waktu tunggu default adalah 10 detik dan -t mengubahnya. Tidak ada yang dihapus. Container mempertahankan ID, writable layer, reservasi IP, dan log-nya.

docker compose stop
docker compose ps -a

docker compose ps secara mandiri hanya menampilkan container yang sedang berjalan. Karena itu, setelah stop, perintah tersebut menampilkan tabel kosong dan pengguna mengira container sudah hilang. ps -a menyertakan container yang sudah dihentikan. Di sana Anda akan melihat Exited (0) di samping setiap service. Jalankan kembali container dengan docker compose start, yang menggunakan container yang sama persis.

Karena container masih ada, semua yang ditulis di dalamnya di luar volume juga tetap tersimpan. Ini termasuk package yang Anda instal secara manual dengan docker compose exec dan file konfigurasi yang Anda edit di dalam container. Inilah alasan praktis untuk memilih stop saat melakukan debugging: Anda dapat memulai ulang container dalam keadaan yang sama.

docker compose down: kontainer dan jaringan dihapus

down menghentikan kontainer, lalu menghapusnya bersama jaringan default yang dibuat Compose untuk proyek tersebut. Dokumentasi Docker menjelaskan bahwa perintah ini menghentikan dan menghapus kontainer, jaringan, volume, serta image yang dibuat oleh up. Namun, volume dan image hanya dihapus jika Anda memintanya menggunakan -v dan --rmi.

docker compose down
docker compose ps -a
docker network ls

Setelah down, ps -a tidak menampilkan apa pun untuk proyek tersebut, dan jaringan <project>_default sudah tidak ada. Nama proyek berasal dari nama direktori, kecuali Anda menetapkan name: di file Compose atau meneruskan -p. Semua perubahan yang Anda buat di dalam writable layer kontainer kini tidak dapat dipulihkan. Karena itu, anggap down sebagai perintah yang membuang kontainer dan mempertahankan data yang Anda simpan di dalam volume.

Jika dijalankan di direktori yang salah, perintah ini menghasilkan no configuration file provided: not found. Compose tidak mengetahui proyek yang Anda maksud, sehingga perintah tersebut ditolak. Gunakan docker compose -f /srv/myapp/compose.yaml down jika Anda tidak berada di folder proyek.

Apakah docker compose down menghapus volume saya?

Tidak. Volume bernama yang dideklarasikan di bawah kunci tingkat teratas volumes tetap ada setelah down selesai, dan tetap ada setelah container yang menggunakannya dihapus. Ini adalah kekhawatiran yang paling umum terkait perintah tersebut. Jawabannya tetap sama pada Compose v2.

Siapkan stack untuk pengujian. Simpan konfigurasi berikut sebagai compose.yaml di direktori kosong bernama voltest.

services:
  db:
    image: postgres:16.4
    restart: unless-stopped
    environment:
      POSTGRES_PASSWORD: example
    volumes:
      - pgdata:/var/lib/postgresql/data

volumes:
  pgdata:

Jalankan stack tersebut, lalu tulis satu baris yang dapat Anda kenali nanti.

docker compose up -d
sleep 10
docker compose exec -T db psql -U postgres -c "create table marker (note text);"
docker compose exec -T db psql -U postgres -c "insert into marker values ('survived');"

Sekarang hapus container dan periksa volume.

docker compose down
docker volume ls

Output tetap mencantumkan voltest_pgdata. Container sudah dihapus, tetapi datanya tetap ada. Jalankan kembali stack tersebut dan baca barisnya.

docker compose up -d
sleep 10
docker compose exec -T db psql -U postgres -c "select * from marker;"

Anda mendapatkan satu baris yang berisi survived. Container baru tersebut berbeda dari container sebelumnya dan memiliki ID yang berbeda, tetapi terhubung ke volume yang sama. Untuk gambaran yang lebih luas, panduan dasar Compose membahas volume bernama dibandingkan dengan bind mount serta lokasi sebenarnya masing-masing di host.

Apa yang dihancurkan down -v secara tepat

-v (bentuk panjang --volumes) menghapus volume bernama yang dideklarasikan di bagian volumes pada file Compose, serta volume anonim yang terpasang pada container. Jalankan perintah ini pada stack yang sama.

docker compose down -v
docker volume ls

voltest_pgdata tidak lagi tercantum. Jalankan kembali stack tersebut. Entry point Postgres menemukan direktori data yang kosong, lalu menginisialisasi cluster baru. Log container menyatakan hal itu dengan jelas.

The files belonging to this database system will be owned by user "postgres".
PostgreSQL init process complete; ready for start up.

Jika blok tersebut muncul pada stack yang telah berjalan selama berbulan-bulan, berarti volume telah dihapus. Tabel marker Anda hilang, dan satu-satunya cara untuk memulihkannya adalah dari cadangan.

Sebagian penyimpanan tidak pernah dihapus oleh -v. Bind mount adalah path pada host, sehingga Docker hanya melepas mount dan file Anda tetap berada di tempatnya. Volume yang ditandai external: true dideklarasikan sebagai milik sesuatu di luar proyek ini, sehingga Compose tidak pernah menghapusnya. Volume bernama yang Anda hapus dari file Compose sebelum menjalankan down -v tidak lagi dideklarasikan. Compose tidak mengetahuinya untuk dihapus, sehingga volume tersebut tertinggal sebagai orphan selama docker volume prune.

Kasus terakhir sering terjadi saat refactor. Hapus sebuah service dan volumenya dari file, lalu jalankan down -v. Volume tersebut tetap ada karena file itu tidak lagi menyebutkannya. Jalankan down -v sebelum mengedit file, bukan setelahnya.

Saat Anda benar-benar memerlukan --force-recreate

docker compose up -d tidak membangun ulang semuanya setiap kali dijalankan. Compose menyimpan hash konfigurasi terurai setiap service pada container sebagai label. Jika hash dan ID image sama, container dibiarkan dan Anda mendapatkan Container voltest-db-1 Running, bukan Recreated. Biasanya, inilah perilaku yang diinginkan karena membuat up -d aman dijalankan berulang kali.

Hal ini juga menjelaskan mengapa beberapa perubahan tampaknya tidak berpengaruh. Compose menghitung hash definisi service yang terurai, bukan isi file yang dirujuk oleh definisi tersebut. File konfigurasi yang di-mount ke dalam container dan dibaca sekali saat startup tidak akan memicu pembuatan ulang ketika Anda mengeditnya, karena path mount tidak berubah. Service tetap berjalan dengan nilai yang dibacanya saat boot.

docker compose up -d --force-recreate

Perintah tersebut menghentikan dan menghapus setiap container, lalu membuat container baru dari definisi yang sama. Gunakan setelah mengedit file konfigurasi yang di-mount, atau ketika kondisi container berubah dan penyebabnya tidak dapat Anda jelaskan. Volume tidak disentuh, sehingga database tetap ada setelah force recreate. Untuk menggunakan image yang lebih baru dengan tag yang sama, Anda juga perlu melakukan pull.

docker compose pull
docker compose up -d

pull mengambil ID image baru, lalu up -d melihat bahwa ID image tersebut berbeda dari container yang sedang berjalan dan membuat ulang container secara otomatis. Menambahkan --force-recreate tanpa pull hanya memberi Anda container baru dari image lama yang sama. Karena itu, keluhan "Saya melakukan force recreate, tetapi versinya masih lama" sering terjadi.

docker compose restart tidak melakukan semua itu. Perintah tersebut hanya me-restart container yang ada dan tidak membaca ulang file Compose, sehingga perubahan variabel lingkungan atau pemetaan port tidak diterapkan. Jika Anda mengedit file, gunakan up -d.

Model mental yang perlu dipertahankan

Container dapat diganti. Container adalah proses dengan lapisan tulis tipis, dan Compose dapat membuat container yang identik dari file tersebut dalam waktu sekitar satu detik. Volume tidak dapat diganti karena menyimpan satu-satunya salinan state yang tidak dapat dibuat ulang oleh file apa pun dalam repositori Anda.

Setiap perintah Compose mengikuti pemisahan tersebut. stop dan start mempertahankan container. down dan up mengganti container dan mempertahankan volume. down -v adalah satu-satunya perintah rutin yang menghapus state, sehingga memerlukan flag eksplisit. Sebelum mengetikkannya pada sistem yang sebenarnya, pastikan Anda memiliki backup yang sudah pernah dipulihkan setidaknya satu kali.

Logika yang sama berlaku untuk secret. Password yang ditetapkan melalui POSTGRES_PASSWORD hanya dibaca saat database pertama kali diinisialisasi. Jadi, mengubahnya dalam file environment lalu menjalankan up -d menghasilkan password authentication failed for user "postgres". Container tersebut baru, tetapi volumenya lama, dan volume lama masih menyimpan password lama. Cara Compose menyelesaikan file env dan secret menjelaskan layer mana yang berlaku jika variabel yang sama ditetapkan dua kali.

Mode kegagalan dan pesan yang akan Anda lihat

no configuration file provided: not found berarti Compose berjalan di direktori yang tidak memiliki compose.yaml maupun docker-compose.yml. Teruskan -f dengan path lengkap.

network voltest_default has active endpoints pada down berarti container di luar project ini terhubung ke network project, biasanya container yang dijalankan secara manual dengan docker run --network. Hapus container tersebut, lalu jalankan down lagi.

Found orphan containers ([voltest-old-1]) for this project muncul setelah Anda mengganti nama atau menghapus service. Container lama masih memiliki label project. docker compose down --remove-orphans membersihkan container tersebut, dan aman dijalankan pada stack yang sehat.

Error response from daemon: remove voltest_pgdata: volume is in use pada docker volume rm manual berarti masih ada container yang mereferensikan volume tersebut, termasuk container yang berhenti. Jalankan docker compose down terlebih dahulu, lalu hapus volume tersebut, atau cukup gunakan down -v. Pada project yang lebih besar, stack Compose multi-service menunjukkan jumlah volume yang dapat terakumulasi oleh satu project.

FAQ

Apakah docker compose down menghapus database saya?

Tidak, jika database berada di volume bernama atau bind mount. down menghapus container dan jaringan project, sedangkan volume tetap berada di disk beserta datanya. docker compose up -d berikutnya memasang container baru ke volume yang sama, sehingga datanya tetap tersedia. Hanya docker compose down -v yang menghapus volume bernama, dan hanya volume yang dideklarasikan di bagian volumes pada file Compose.

Apa perbedaan stop dan down untuk container yang ingin saya gunakan kembali?

stop mempertahankan container, sehingga docker compose start mengembalikan Anda ke container yang sama dengan writable layer yang sama. Apa pun yang Anda instal atau edit secara manual di dalam container tetap ada. down menghapus container, sehingga up -d berikutnya membuat container baru dari image dan perubahan manual tersebut hilang. Saat melakukan debugging, gunakan stop.

Bagaimana cara menghapus semua yang dibuat oleh project Compose?

docker compose down -v --rmi all --remove-orphans menghapus container, jaringan project, volume bernama yang dideklarasikan dalam file, image yang digunakan service, dan setiap container yang masih memiliki label nama project. Perintah ini tidak menyentuh bind mount atau volume yang ditandai external: true. Periksa item yang akan dihapus dengan docker volume ls sebelum menjalankannya.

Mengapa container saya mengabaikan perubahan pada file konfigurasi yang dipasang?

Compose menentukan apakah container perlu dibuat ulang dengan membandingkan hash definisi service yang telah diselesaikan. Hash tersebut tidak mencakup isi file yang dipasang. Path tidak berubah, sehingga Compose membiarkan container tetap berjalan dengan nilai yang dibacanya saat startup. Jalankan docker compose up -d --force-recreate untuk membuat container baru yang membaca kembali file tersebut.

Mengapa POSTGRES_PASSWORD baru saya tidak berfungsi setelah diubah?

Image Postgres hanya membaca POSTGRES_PASSWORD saat menginisialisasi direktori data yang kosong. Volume Anda sudah berisi cluster yang telah diinisialisasi, sehingga variabel tersebut diabaikan dan password lama tetap berlaku. Anda akan melihat password authentication failed for user "postgres". Ubah password dengan ALTER USER di dalam database yang sedang berjalan, atau terima kehilangan data dan mulai ulang dengan docker compose down -v.