Senarai Perintah Docker Compose Penting untuk Pelayan

Perintah Compose yang benar-benar anda gunakan

Docker Compose menyediakan berpuluh-puluh subperintah. Kerja harian pada pelayan biasanya menggunakan kira-kira sedozen daripadanya. Halaman ini mengumpulkan subperintah tersebut mengikut tugas, memberikan satu sebab ringkas bagi setiap satunya dan merujuk kepada penerangan terperinci apabila sesuatu perintah mempunyai perangkap tersembunyi.

Semua contoh di sini menggunakan Compose V2 atau V5: docker compose dengan ruang, bukan skrip lama docker-compose. Kedua-duanya ialah plugin Go; pada Linux, plugin Compose dipasang secara berasingan daripada Docker Engine. Ubuntu 24.04 LTS masih menyediakan alat Python V1 lama sebagai docker-compose versi 1.29.2-6ubuntu1 dalam repositori universe. Semak dengan docker compose version. Jika perintah itu tidak tersedia, sediakan repositori Docker dan pasang pakej docker-compose-plugin.

Setiap perintah di bawah dijalankan dari direktori yang mengandungi compose.yaml; Compose menggunakan nama direktori tersebut sebagai nama projek lalai melainkan anda menggantikannya. Tanpa -f atau COMPOSE_FILE, Compose mencari fail konfigurasi dalam direktori kerja dan direktori induknya. Oleh itu, menjalankan perintah dari satu tahap di atas hanya akan menemui stack anda jika failnya masih berada dalam laluan carian tersebut. Jika format fail itu sendiri masih baharu bagi anda, mulakan dengan fail Compose pertama pada VPS dan kembali ke sini untuk melihat perintah yang tersedia.

Kitar hayat: empat arahan yang anda taip, dan satu arahan yang membuang container

docker compose up -d
docker compose up -d --wait
docker compose stop
docker compose start
docker compose restart web
docker compose down

up -d mencipta rangkaian, mencipta container, memulakannya dan kemudian selesai. Arahan ini selesai sebaik sahaja container dimulakan, tanpa menunggu aplikasi bersedia. Oleh itu, skrip deployment yang menjalankan probe curl selepasnya sering gagal pada percubaan pertama. up -d --wait menunggu servis yang mempunyai healthcheck sehingga statusnya menjadi sihat, dan menunggu servis tanpa healthcheck sehingga berjalan. Servis yang tidak sihat atau --wait-timeout yang tamat tempoh menyebabkan arahan keluar dengan kod bukan sifar. Flag ini hanya berkesan setakat ketepatan semakan yang mendasarinya. Oleh itu, tulis healthcheck yang boleh dipercayai oleh Compose sebelum menggunakannya dalam automasi.

stop menghentikan container dan mengekalkannya. Oleh itu, start memulakan semula container yang sama dengan writable layer yang sama. down menghentikan container, kemudian membuang container dan rangkaian projek. Apa-apa yang ditulis di dalam container tetapi di luar volume akan turut hilang. Ini ialah salah faham paling merugikan tentang Compose. Perbezaan penuh antara down dan stop menerangkan keadaan yang boleh menyebabkan masalah ini.

restart bukan arahan reload. Arahan ini menghentikan dan memulakan semula container yang sama dengan konfigurasi sedia ada. Oleh itu, perubahan pada pemboleh ubah persekitaran, tag image baharu atau pemetaan port yang diedit tidak memberi kesan langsung. Untuk menggunakan perubahan pada fail, jalankan up -d sekali lagi. Compose membandingkan setiap servis dengan container yang sedang berjalan dan mencipta semula container yang konfigurasi atau image-nya telah berubah.

Menerapkan perubahan: cipta semula, tarik atau bina

docker compose up -d --force-recreate
docker compose pull && docker compose up -d
docker compose build --no-cache web
docker compose up -d --build web

up -d menggunakan semula container yang sedang berjalan apabila konfigurasinya dan image tidak berubah; proses pull dan build image mengikut dasar pull servis tersebut. --force-recreate mengatasi perbandingan itu dan menggantikan setiap container walaupun konfigurasinya sama. Oleh itu, cara ini paling cepat untuk menghapuskan keadaan luar biasa dalam container.

Rutin kemas kini image secara eksplisit menggunakan dua arahan kerana kedua-duanya menjalankan tugas yang berbeza. pull memuat turun image semasa bagi setiap tag yang dinamakan dalam fail. up -d kemudian mengesan bahawa ID image servis tidak lagi sepadan dengan container yang sedang berjalan, lalu mencipta semulanya. Dengan dasar pull lalai missing, tag yang dicache digunakan semula kecuali latest, yang sentiasa ditarik. Risiko sebaliknya berlaku pada stack berbilang servis. Menarik latest untuk semua servis serentak boleh menyebabkan aplikasi yang berfungsi sepuluh saat sebelumnya gagal. Oleh itu, ruang kerja AFFiNE yang dihos sendiri mengesyorkan supaya image aplikasi dan image migrasi dipasak pada digest yang sama. Pinning juga menjadikan naik taraf sebagai perubahan tag yang disengajakan, diikuti pull dan penciptaan semula yang sama. Bagi stack yang memigrasikan pangkalan datanya semasa dimulakan, anda perlu menyediakan dump sebelum menjalankan mana-mana arahan tersebut. Inilah rutin yang diikuti oleh meja sokongan Chatwoot yang dihos sendiri bagi setiap peningkatan versi.

build digunakan pada servis yang mengisytiharkan bahagian build:, termasuk servis yang turut mengisytiharkan image:. up -d --build membina dan memulakan servis dalam satu langkah. Ini ialah kitaran biasa apabila anda sedang mengubah kod. Gunakan --no-cache hanya apabila lapisan cache jelas sudah lapuk kerana arahan ini membina semula setiap lapisan dari awal. Sesetengah projek menyediakan kedua-dua laluan daripada satu repositori yang diklon. Dalam keadaan itu, kedua-dua kitaran tersebut ialah laluan kemas kini alternatif: penjejak senaman openGym yang dihos sendiri menggunakan docker compose up -d --build untuk membina checkout yang dipasak kerana menarik image latest boleh menjalankan keluaran yang lebih baharu daripada checkout tersebut.

Melihat perkara 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 ls

ps hanya menyenaraikan container yang sedang berjalan. Servis yang terhenti semasa dimulakan tidak kelihatan sehingga anda menambah -a. Oleh itu, container yang tiada dalam ps tetapi ps -a memaparkannya sebagai Exited (1) ialah keadaan biasa bagi kegagalan semasa permulaan. Baca exit code, kemudian baca log.

logs -f memantau semua servis serentak dan menambahkan nama servis pada awal setiap baris. Paparan ini sesuai apabila servis saling berkomunikasi dan turutan peristiwa penting. Nyatakan nama servis untuk mengehadkan paparan. --tail=100 penting bagi container yang telah berjalan selama sebulan kerana tetapan lalai memaparkan seluruh sejarah dan memenuhi terminal dengan output. --since 15m menjawab soalan yang biasanya anda ingin tahu, iaitu perkara yang berlaku semasa restart yang baru anda lakukan.

top menyenaraikan proses dalam setiap container. Ini membezakan antara "container sedang berjalan" dengan "proses di dalamnya sedang berjalan". ls keluar daripada direktori semasa dan menyenaraikan projek Compose yang sedang berjalan pada host berserta statusnya. Tambah -a untuk menyertakan projek yang telah dihentikan.

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 sh

exec menjalankan perintah di dalam container yang sedang berjalan. run memulakan container baharu berdasarkan takrifan servis yang sama. Gunakan run apabila servis tidak kekal aktif cukup lama untuk diakses dengan exec. Sentiasa gabungkan run dengan --rm. Tanpa pilihan itu, setiap pemanggilan meninggalkan container yang telah berhenti. Container tersebut akan bertambah sehingga docker compose ps -a tidak lagi mudah dibaca.

Cuba sh sebelum bash. Sesetengah imej berasaskan Alpine menyertakan bash, termasuk imej PostgreSQL Alpine rasmi. Jika bash tiada, ralat yang dipaparkan ialah exec: "bash": executable file not found in $PATH. Menambah --no-deps pada run mengabaikan dependency servis. Ini menghalang semakan konfigurasi ringkas daripada memulakan keseluruhan pangkalan data.

run --rm web env ialah cara terpantas untuk melihat persekitaran sebenar yang diterima oleh servis selepas setiap fail .env, blok environment: dan pemboleh ubah shell digabungkan. Jika sesuatu nilai tidak betul, punca biasanya ialah susunan penggabungan. cara Compose menyelesaikan fail env dan secret menerangkan sumber yang mempunyai keutamaan.

Rangkaian, port dan penyelesaian nama

docker compose port web 80
docker compose exec web getent hosts db
docker compose config --networks

Secara lalai, Compose meletakkan setiap servis pada satu rangkaian projek, dan nama setiap servis menjadi nama DNS pada rangkaian itu. Menjalankan getent hosts db di dalam web, apabila imej tersebut menyertakan getent, menguji penyelesaian nama; arahan itu tidak menguji sama ada db menerima sambungan. Jika nama berjaya diselesaikan tetapi sambungan ditolak, semak sama ada pelayan sedang berjalan dan mendengar pada alamat serta port yang diminta; hanya mengikat pada 127.0.0.1 ialah salah satu punca yang mungkin. Batas yang sama menerangkan sebab container yang dimulakan di luar projek, sama ada melalui docker run atau sebagai stack tersendiri, memerlukan rangkaian bersama untuk menyelesaikan nama servis seperti jellyfin. Ini perkara pertama yang perlu diperiksa apabila front end Halcyon untuk pustaka Jellyfin anda tidak dapat mencapai pelayan yang ditujunya. Penjelasan selebihnya tentang model ini terdapat dalam cara rangkaian Compose dan DNS servis berfungsi.

port web 80 memaparkan alamat host dan port tempat port container diterbitkan. Ini mengelakkan anda perlu meneka apabila pemetaan datang daripada pemboleh ubah. Penerbitan port juga menulis peraturan firewall yang diurus sendiri oleh Docker, dan peraturan itu berada sebelum peraturan anda. Oleh itu, servis yang anda anggap sebagai peribadi mungkin terbuka kepada internet. Kes ini diterangkan dalam sebab port Docker yang diterbitkan memintas ufw. Membiarkan port tersebut tidak diterbitkan dan meletakkan satu proxy yang mengesahkan pengguna pada rangkaian projek di hadapan servis adalah reka bentuk yang lebih selamat. Itulah yang diberikan oleh menjalankan Authentik sebagai lapisan log masuk tunggal.

Volume dan data

docker compose config --volumes
docker compose cp db:/etc/postgresql/pg_hba.conf ./pg_hba.conf
docker compose down -v

config --volumes memaparkan volume bernama yang diisytiharkan oleh projek, satu pada setiap baris. Senarai itu hanya sebahagian daripada inventori sandaran: bind mount dan fail konfigurasi juga perlu diperiksa. Jika volume mengandungi data yang tidak boleh diganti, arahan sandaran yang tepat sama pentingnya dengan senarai tersebut. Oleh itu, perbandingan PhotoPrism dan Immich menerangkan arahan dump dan salin yang diperlukan oleh setiap pelayan foto. cp menyalin fail ke dalam atau keluar dari container tanpa membuka shell, menggunakan bentuk service:path pada mana-mana sisi yang merupakan container.

down -v mengalih keluar volume bernama yang diisytiharkan kecuali volume luaran, serta volume tanpa nama yang dilampirkan pada container, bersama-sama dengan container tersebut. Arahan ini sesuai untuk merobohkan test stack, tetapi tidak sesuai untuk apa-apa yang mengandungi data penting kerana tiada pengesahan dan tiada cara untuk membuat asal tindakan itu. Bind mount kekal selepas arahan ini dijalankan kerana bind mount berada pada filesystem host. Perbezaan dari segi skop kesan ini ialah salah satu sebab anda perlu memilih dengan sengaja antara bind mount dan volume bernama.

Pembersihan yang membebaskan ruang cakera tanpa kehilangan data

docker compose down --remove-orphans
docker system df
docker image prune -a
docker builder prune

--remove-orphans memadam container yang tergolong dalam projek tetapi tidak lagi muncul dalam fail. Situasi ini berlaku selepas menamakan semula sesuatu servis. Tanpa perintah ini, container tersebut terus berjalan, dan docker compose ps menyertakan orphan yang sedang berjalan secara lalai.

docker system df menunjukkan penggunaan cakera sebelum anda memadam apa-apa. Perintah ini memisahkan penggunaan oleh image, container, local volume dan build cache, serta menunjukkan jumlah yang boleh dituntut semula bagi setiap kategori. image prune -a membuang semua image yang tidak digunakan oleh mana-mana container, sama ada mempunyai tag atau tidak. Pada sistem yang telah menarik beberapa versi image besar, perintah ini biasanya memberikan penjimatan terbesar. builder prune membuang build cache yang tidak lagi dirujuk secara lalai. Tambahkan -a untuk membuang semua build cache yang tidak digunakan.

Tiada satu pun perintah tersebut menyentuh named volume. docker volume prune --all, docker compose down -v dan docker volume rm membuang named volume. docker volume prune biasa hanya membuang anonymous volume.

Memeriksa fail sebelum ia menyebabkan kerosakan

docker compose config --quiet
docker compose config --services
docker compose --dry-run up -d

config --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 -d

Beberapa flag -f digabungkan mengikut turutan, dan fail yang kemudian mengatasi fail terdahulu mengikut setiap kunci. Ini ialah cara standard untuk mengekalkan satu fail asas dengan override pengeluaran yang kecil. Walau bagaimanapun, peraturannya berbeza untuk senarai dan peta. Oleh itu, baca cara Compose menggabungkan beberapa fail sebelum menyahpepijat hasil yang tidak dijangka.

--profile memulakan servis yang ditag dengan profil itu bersama servis tanpa tag. Ini menghalang alat penyahpepijatan daripada dimuatkan dalam up biasa. -p menetapkan nama projek. Oleh itu, dua salinan satu stack boleh berjalan serentak dengan rangkaian dan nama volume yang berasingan. Untuk memulihkan stack selepas reboot, gunakan restart policy atau unit yang menjalankan Compose untuk anda, seperti yang diterangkan dalam memulakan stack Compose semasa boot.

FAQ

Apa yang menggantikan docker-compose dengan tanda sempang?

Compose V2 dan V5, yang dipanggil sebagai docker compose dengan ruang. Pada Linux, Compose ialah plugin yang dipasang secara berasingan; Ubuntu 24.04 LTS masih menawarkan alat Python V1 dalam repositori universe. Jika bentuk dengan ruang tidak tersedia, sediakan repositori Docker dan pasang pakej docker-compose-plugin. Kemas kini skrip lama kepada bentuk dengan ruang dan bukannya menambah alias, kerana V2 mempunyai flag yang tiada dalam V1.

Mengapa docker compose restart tidak menggunakan perubahan konfigurasi saya?

restart menghentikan dan memulakan semula container sedia ada menggunakan konfigurasi semasa container itu dicipta, dan tidak membaca semula compose.yaml. Sebarang perubahan pada pemboleh ubah persekitaran, port, volume atau tag imej memerlukan docker compose up -d, yang membandingkan setiap servis dengan container yang sedang berjalan dan mencipta semula container yang berbeza. Tambahkan --force-recreate jika anda mahu penggantian berlaku walaupun tiada perubahan pada fail.

Bagaimanakah saya mengemas kini servis kepada imej yang lebih baharu?

Jalankan docker compose pull, kemudian docker compose up -d. Perintah pull mendapatkan imej semasa bagi setiap tag dalam fail, manakala up -d mencipta semula mana-mana servis yang ID imejnya tidak lagi sepadan dengan containernya. Menjalankan up -d sahaja mengikut dasar pull: dasar lalai missing menggunakan semula imej yang dicache kecuali latest, yang sentiasa melakukan pull.

Apakah perintah pembersihan yang selamat pada pelayan aktif?

docker system df melaporkan penggunaan cakera tanpa memadam apa-apa; docker image prune -a dan docker builder prune membuang imej serta cache binaan yang tidak digunakan, jadi servis yang sedang berjalan terus berfungsi dan volume bernama tidak terjejas. Pasangan yang berbahaya ialah docker compose down -v, yang memadam volume bernama bukan luaran yang diisytiharkan oleh projek serta volume tanpa nama yang dilampirkan tanpa meminta pengesahan, dan docker volume prune --all, yang memadam volume tempatan yang tidak digunakan, termasuk volume bernama, selepas satu gesaan y/N, atau tanpa gesaan langsung dengan -f. Jalankan docker compose config --volumes terlebih dahulu supaya anda mengetahui perkara yang berisiko.

Bolehkah saya menjalankan satu perintah tanpa memulakan keseluruhan stack?

Ya. docker compose run --rm --no-deps web sh memulakan satu container daripada definisi servis web, melangkau dependency-nya dan membuang container apabila anda keluar. Gunakan exec jika container itu sudah berjalan, kerana exec menjalankan perintah anda di dalam container yang aktif dan memaparkan keadaan sebenar servis tersebut.