Senarai Perintah Docker Compose Penting untuk Pelayan
Kuasai pengurusan kontena dengan senarai perintah Docker Compose V2 yang kerap digunakan. Panduan ini merangkumi kitaran hayat, log, rangkaian, dan pembersihan yang selamat.
Perintah Compose yang kerap digunakan
Docker Compose mempunyai lebih daripada empat puluh subperintah. Tugasan harian pada pelayan hanya menggunakan kira-kira sedozen daripadanya. Halaman ini mengumpulkan perintah tersebut mengikut fungsi, memberikan satu sebab ringkas bagi setiap satu, serta merujuk kepada perincian teknikal apabila sesuatu perintah mempunyai perangkap tersembunyi.
Segala kandungan di sini menggunakan Compose V2: docker compose dengan ruang, bukan skrip docker-compose yang lama. V2 ialah pemalam Go yang dipasang bersama Docker Engine, dan V1 telah tiada dalam pakej semasa, jadi docker-compose: command not found pada sistem Ubuntu baharu setakat Julai 2026 adalah dijangkakan dan bukannya ralat. Semak dengan docker compose version. Jika ia tidak memaparkan apa-apa, pasang pakej docker-compose-plugin.
Setiap perintah di bawah dijalankan dari direktori yang mengandungi compose.yaml anda, kerana Compose mengambil nama projek daripada direktori tersebut dan mencari fail berdasarkan lokasi relatifnya. Jalankan perintah yang sama satu tahap di atas dan Compose akan berhenti dengan no configuration file provided: not found. Jika format fail itu sendiri baharu bagi anda, mulakan dengan fail Compose pertama pada VPS dan kembali ke sini untuk melihat perintah-perintahnya.
Kitaran hayat: empat arahan yang anda taip, dan satu yang membuang container
docker compose up -d
docker compose up -d --wait
docker compose stop
docker compose start
docker compose restart web
docker compose downup -d mencipta rangkaian, mencipta container, memulakannya, dan kembali semula. Ia kembali sebaik sahaja container dicipta, itulah sebabnya skrip penggunaan yang disusuli dengan probe curl sering gagal pada percubaan pertama. up -d --wait menyekat sehingga setiap servis yang mengisytiharkan healthcheck melaporkan status sihat, dan keluar dengan kod bukan sifar jika salah satu daripadanya tidak mencapai status tersebut. Flag ini hanya berkesan berdasarkan semakan di sebaliknya, jadi tulis healthcheck yang boleh dipercayai oleh Compose sebelum anda bergantung padanya dalam automasi.
stop menghentikan container dan menyimpannya, jadi start membawa kembali container yang sama dengan lapisan boleh tulis (writable layer) yang sama. down menghentikan dan kemudian membuang container serta rangkaian projek tersebut. Apa-apa sahaja yang ditulis di dalam container dan di luar volume akan hilang bersamanya. Itu adalah salah faham paling mahal dalam Compose, dan perbezaan penuh antara down dan stop merangkumi bahagian yang sering menimbulkan masalah.
restart bukanlah satu muat semula (reload). Ia menghentikan dan memulakan container yang sama dengan konfigurasi sedia ada, jadi perubahan pada pemboleh ubah persekitaran (environment variable), tag imej baharu atau pemetaan port yang disunting tidak akan memberi sebarang kesan. Untuk menggunakan perubahan fail, anda perlu menjalankan up -d sekali lagi. Compose membandingkan setiap servis dengan container yang sedang berjalan dan mencipta semula hanya servis yang konfigurasinya telah berubah.
Menggunakan perubahan: recreate, pull, atau rebuild
docker compose up -d --force-recreate
docker compose pull && docker compose up -d
docker compose build --no-cache web
docker compose up -d --build webup -d dengan sendirinya tidak melakukan apa-apa apabila tiada perubahan, itulah sebabnya ia selamat untuk dijalankan berulang kali. --force-recreate mengatasi perbandingan tersebut dan menggantikan setiap kontena walaupun konfigurasi adalah sama, jadi ia merupakan cara terpantas untuk membersihkan status dalam kontena yang ganjil.
Mengemas kini imej memerlukan dua arahan kerana kedua-duanya menjalankan tugas yang berbeza. pull memuat turun imej semasa bagi setiap tag yang disenaraikan dalam fail tersebut. up -d kemudian mendapati bahawa ID imej servis itu tidak lagi sepadan dengan bekas yang sedang berjalan, lalu mencipta semulanya. Jika langkah pull dilangkau, up -d akan terus menjalankan latest bulan lalu tanpa sebarang ralat. Risiko yang berlawanan berlaku pada tindanan berbilang servis, apabila menarik latest untuk semua servis serentak boleh merosakkan aplikasi yang berfungsi sepuluh saat sebelumnya. Oleh itu, ruang kerja AFFiNE yang dihos sendiri menetapkan setiap daripada empat tag imejnya secara khusus. Penetapan tag juga menjadikan peningkatan sebagai proses yang disengajakan: edit tag, kemudian jalankan pull dan cipta semula dengan arahan yang sama. Bagi tindanan yang memindahkan pangkalan datanya semasa proses boot, anda perlu menyediakan dump terlebih dahulu sebelum menjalankan mana-mana arahan tersebut. Inilah rutin yang digunakan oleh meja bantuan Chatwoot yang dihos sendiri bagi setiap peningkatan versi.
build terpakai pada servis yang mengisytiharkan bahagian build: dan bukannya image:. up -d --build membina dan memulakan dalam satu langkah, yang merupakan gelung biasa semasa anda menukar kod. Gunakan --no-cache hanya apabila lapisan cache jelas sudah lapuk, kerana ia membina semula setiap lapisan dari awal.
Melihat proses yang sedang berjalan
docker compose ps
docker compose ps -a
docker compose logs -f --tail=100
docker compose logs --since 15m --timestamps db
docker compose top
docker compose lsps hanya menyenaraikan kontena yang sedang berjalan. Servis yang terhenti semasa permulaan tidak akan kelihatan di situ sehingga anda menambah -a, jadi kontena yang tiada dalam ps sedangkan ps -a menunjukkannya sebagai Exited (1) adalah keadaan biasa bagi kegagalan semasa permulaan. Baca kod keluar (exit code), kemudian baca log.
top menyenaraikan proses di dalam setiap kontena, yang membezakan antara "kontena sedang berjalan" dengan "proses di dalamnya sedang berjalan". ls melangkah keluar dari direktori semasa dan menyenaraikan setiap projek Compose pada hos berserta statusnya, supaya anda boleh mencari stack yang anda mulakan tiga bulan lalu.
logs -f mengikuti setiap servis secara serentak dan meletakkan nama servis sebagai awalan pada setiap baris, iaitu paparan yang anda perlukan apabila servis berkomunikasi antara satu sama lain dan urutan peristiwa adalah penting. Namakan servis untuk mengecilkan skop carian. --tail=100 penting pada kontena yang telah berjalan selama sebulan, kerana tetapan lalai akan mencetak keseluruhan sejarah dan membanjiri terminal. --since 15m menjawab soalan yang biasanya anda miliki, iaitu apa yang berlaku semasa but semula yang baru sahaja anda lakukan.
Mendapatkan shell di dalam servis
docker compose exec web sh
docker compose exec -u root web sh
docker compose run --rm web env
docker compose run --rm --no-deps web shexec menjalankan arahan di dalam kontena yang sudah berjalan. run memulakan kontena baharu daripada definisi servis yang sama, iaitu tindakan yang diperlukan apabila servis tidak kekal berjalan cukup lama untuk melakukan exec. Sentiasa gandingkan run dengan --rm, kerana tanpanya setiap penggunaan akan meninggalkan kontena yang terhenti, dan kontena tersebut akan terkumpul sehingga docker compose ps -a menjadi sukar dibaca.
Cuba sh sebelum bash. Imej berasaskan Alpine tidak membawa bash, dan kegagalan akan memaparkan ralat exec: "bash": executable file not found in $PATH. Menambah --no-deps pada run akan melangkau dependency servis tersebut, yang menghalang pemeriksaan konfigurasi pantas daripada memulakan keseluruhan pangkalan data anda.
run --rm web env ialah cara terpantas untuk melihat persekitaran sebenar yang diterima oleh sesuatu servis, selepas setiap fail .env, blok environment: dan pemboleh ubah shell digabungkan. Apabila sesuatu nilai didapati salah, urutan penggabungan biasanya menjadi puncanya, dan bagaimana Compose menyelesaikan fail env dan rahsia menjelaskan sumber mana yang akan diutamakan.
Rangkaian, port, dan resolusi nama
docker compose port web 80
docker compose exec web getent hosts db
docker compose config --networksCompose meletakkan setiap servis pada satu rangkaian projek, dan nama setiap servis menjadi nama DNS dalam rangkaian itu. Menjalankan getent hosts db di dalam web memaparkan IP kontena apabila resolusi berjaya, dan tidak memaparkan apa-apa apabila resolusi gagal. Oleh itu, perintah ini menjawab soalan "bolehkah kontena ini saling berhubung" dalam masa dua saat. Jika nama berjaya diresolve tetapi sambungan ditolak, proses di dalam db terikat pada 127.0.0.1 dan bukannya 0.0.0.0. Oleh itu, proses tersebut tidak menerima paket daripada kontena lain. Batas yang sama menjelaskan sebab kontena yang dimulakan di luar projek, sama ada oleh docker run atau sebagai tindanan tersendiri, langsung tidak dapat mengresolve nama seperti jellyfin. Perkara ini perlu diperiksa dahulu apabila frontend Halcyon untuk pustaka Jellyfin anda tidak dapat mencapai pelayan yang ditetapkan. Penjelasan lanjut tentang model ini terdapat dalam cara rangkaian Compose dan DNS servis berfungsi.
port web 80 memaparkan alamat hos dan port tempat port kontena diterbitkan, yang menjimatkan masa daripada meneka apabila pemetaan datang daripada pemboleh ubah. Menerbitkan port juga menulis peraturan firewall yang diuruskan sendiri oleh Docker, dan peraturan itu berada di hadapan peraturan anda, jadi servis yang anda sangka peribadi boleh terdedah kepada internet. Kes tersebut dibincangkan dalam mengapa port Docker yang diterbitkan memintas ufw. Membiarkan port tersebut tidak diterbitkan dan meletakkan satu proksi pengesahan pada rangkaian projek di hadapan servis adalah bentuk yang lebih selamat, iaitu apa yang diberikan oleh menjalankan Authentik sebagai lapisan daftar masuk tunggal.
Volume dan data
docker compose config --volumes
docker compose cp db:/etc/postgresql/pg_hba.conf ./pg_hba.conf
docker compose down -vconfig --volumes mencetak volume bernama yang diisytiharkan oleh projek, satu per baris. Senarai tersebut ialah perkara yang perlu anda sandarkan. Apabila volume menyimpan sesuatu yang tidak boleh diganti, arahan sandaran yang tepat adalah sama penting dengan senarai tersebut, itulah sebabnya perbandingan PhotoPrism dan Immich memperincikan arahan dump dan copy yang diperlukan oleh setiap pelayan foto. cp menyalin fail ke dalam atau keluar dari container tanpa membuka shell, menggunakan format service:path pada mana-mana bahagian yang merupakan container.
down -v membuang volume bernama tersebut bersama-sama dengan container. Ia adalah arahan yang betul untuk meruntuhkan stack ujian dan arahan yang salah untuk sebarang data yang penting bagi anda, kerana tiada pengesahan dan tiada fungsi undo. Bind mount terselamat daripada arahan ini, kerana ia berada pada sistem fail hos. Jurang dalam radius impak ini adalah salah satu sebab untuk memilih secara sengaja antara bind mount dan volume bernama.
Pembersihan yang mengosongkan ruang cakera tanpa kehilangan data
docker compose down --remove-orphans
docker system df
docker image prune -a
docker builder prune--remove-orphans memadamkan kontena yang tergolong dalam projek tetapi tidak lagi muncul dalam fail, iaitu hasil yang anda peroleh selepas menamakan semula sesuatu servis. Tanpanya, kontena tersebut akan terus berjalan dan tidak kelihatan oleh docker compose ps.
docker system df menunjukkan ke mana perginya ruang cakera sebelum anda memadamkan apa-apa, dengan memisahkan imej, kontena, volum tempatan dan cache binaan berserta angka yang boleh dituntut semula bagi setiap satu. image prune -a membuang setiap imej yang tidak mempunyai tag yang merujuk kepadanya, dan pada pelayan yang telah memuat turun beberapa versi imej yang besar, ini biasanya memberikan penjimatan ruang yang paling ketara. builder prune membersihkan cache binaan, yang berkembang secara senyap pada mana-mana pelayan yang membina imejnya sendiri.
Tiada satu pun daripada arahan tersebut menyentuh volum bernama. Hanya docker volume prune dan docker compose down -v yang melakukannya.
Memeriksa fail sebelum ia menyebabkan kerosakan
docker compose config --quiet
docker compose config --services
docker compose --dry-run up -dconfig --quiet melakukan pengesahan dan tidak mencetak apa-apa jika berjaya, jadi ia sesuai diletakkan dalam langkah pra-atur cara (pre-deploy) atau git hook. config pula mencetak fail yang telah digabung dan diinterpolasi sepenuhnya; ini cara untuk mengesahkan pemboleh ubah telah diselesaikan dan fail override telah disusun mengikut jangkaan anda. Pemboleh ubah yang tidak ditetapkan akan muncul di situ sebagai nilai kosong, bersebelahan dengan amaran The "X" variable is not set. Defaulting to a blank string..
--dry-run ialah flag global dan bukannya flag subperintah, jadi ia diletakkan sebelum up. Ia mencetak setiap tindakan yang akan diambil oleh Compose tanpa mengubah apa-apa; ini merupakan masa selama tiga puluh saat yang berbaloi sebelum menjalankan down pada stack yang penting.
Bekerja merentas fail, profil, dan projek
docker compose -f compose.yaml -f compose.prod.yaml up -d
docker compose --profile debug up -d
docker compose -p staging up -dBerbilang flag -f akan digabungkan mengikut urutan, dan fail yang kemudian akan mengatasi fail sebelumnya mengikut kunci. Ini merupakan cara standard untuk mengekalkan satu fail asas dengan pengubahsuaian pengeluaran (production override) yang kecil, namun peraturannya berbeza bagi senarai dan peta. Oleh itu, baca cara Compose menggabungkan berbilang fail sebelum anda menyahpepijat (debug) sebarang hasil yang tidak dijangka.
--profile memulakan servis yang ditandakan dengan profil tersebut bersama-sama servis yang tidak bertanda, yang memastikan alatan nyahpepijat tidak termasuk dalam up biasa. -p menetapkan nama projek, supaya dua salinan satu stack boleh dijalankan serentak dengan rangkaian dan nama volum yang berasingan. Mendapatkan semula stack selepas but semula (reboot) bukanlah arahan yang perlu anda taip, sebaliknya ia adalah unit yang menjalankannya untuk anda, seperti yang diterangkan dalam memulakan stack Compose semasa but.
FAQ
Apakah yang menggantikan docker-compose dengan tanda sempang?
Compose V2, yang dipanggil sebagai docker compose dengan ruang. Ia merupakan pemalam yang disertakan bersama Docker Engine, dan alat Python V1 tidak lagi dipasang oleh pakej semasa. Jika format dengan ruang tidak memaparkan apa-apa, pasang pakej docker-compose-plugin untuk pengedaran anda. Kemas kini skrip lama kepada format dengan ruang dan bukannya menambah alias, kerana V2 mempunyai flag yang tidak dimiliki oleh V1.
Mengapa docker compose restart tidak mengambil perubahan konfigurasi saya?
restart menghentikan dan memulakan bekas sedia ada dengan konfigurasi asal semasa ia dicipta, dan ia tidak membaca semula compose.yaml. Sebarang perubahan pada pemboleh ubah persekitaran, port, volum atau tag imej memerlukan docker compose up -d, yang membandingkan setiap servis dengan bekas yang sedang berjalan dan mencipta semula servis yang berbeza. Tambahkan --force-recreate apabila anda mahu penggantian berlaku walaupun tiada perubahan dalam fail.
Bagaimanakah cara saya mengemas kini servis kepada imej yang lebih baharu?
Jalankan docker compose pull, kemudian docker compose up -d. Arahan pull akan mengambil imej semasa untuk setiap tag dalam fail, dan up -d akan mencipta semula mana-mana servis yang ID imejnya tidak lagi sepadan dengan bekasnya. Menjalankan up -d secara sendirian akan menggunakan semula imej yang sudah ada pada cakera, itulah sebabnya stack yang ditetapkan kepada latest kekal pada binaan berusia berbulan-bulan tanpa memaparkan sebarang ralat.
Perintah pembersihan manakah yang selamat pada pelayan yang sedang berjalan?
docker system df, docker image prune -a dan docker builder prune hanya membuang imej dan cache, jadi servis yang sedang berjalan akan terus berfungsi dan volum bernama tidak akan disentuh. Pasangan yang berbahaya ialah docker compose down -v dan docker volume prune, yang memadamkan volum bernama tanpa sebarang gesaan. Jalankan docker compose config --volumes terlebih dahulu supaya anda tahu apa yang berisiko.
Bolehkah saya menjalankan satu perintah tanpa memulakan keseluruhan stack?
Boleh. docker compose run --rm --no-deps web sh memulakan satu bekas daripada definisi servis web, melangkau dependensinya, dan membuang bekas tersebut apabila anda keluar. Gunakan exec sebaliknya apabila bekas sudah berjalan, kerana exec menyertai proses yang sedang aktif dan menunjukkan kepada anda keadaan sebenar servis tersebut.