Docker Compose down vs stop: Ano ang Pagkakaiba?

Ang maikling sagot

docker compose stop ay pinahihinto ang mga container at iniiwan ang mga ito sa disk. docker compose down ay pinahihinto ang mga ito, at pagkatapos ay binubura ang mga container at ang network na ginawa ng Compose para sa project. Walang named volume na naaapektuhan ng alinman sa dalawang command. Buburahin lamang ang database kapag idinagdag mo ang -v, gaya ng nasa docker compose down -v, na nag-aalis ng mga named volume na idineklara sa seksyong volumes ng Compose file.

Iyon ang buong pagkakaiba sa isang talata. Sa natitirang bahagi ng gabay na ito, mapapatunayan ito gamit ang isang Postgres volume na maaari mong i-monitor habang nakaliligtas ito sa down at nawawala sa ilalim ng down -v. Ipapaliwanag din nito ang dalawang sitwasyon kung kailan kailangan mo ang --force-recreate.

docker compose stop: nananatili ang mga container

stop ay nagpapadala ng SIGTERM sa pangunahing proseso ng bawat container, naghihintay, at nagpapadala ng SIGKILL kung tumatakbo pa rin ang proseso. Ang default na paghihintay ay 10 segundo, at binabago ito ng -t. Walang dine-delete. Pinananatili ng container ang ID nito, writable layer nito, IP reservation nito, at mga log nito.

docker compose stop
docker compose ps -a

docker compose ps kapag nag-iisa ay mga tumatakbong container lang ang ipinapakita. Kaya pagkatapos ng stop, isang walang-lamang table ang ipinapakita at iniisip ng mga tao na nawala na ang mga container. Isinasama ng ps -a ang mga stopped container, at doon mo makikita ang Exited (0) sa tabi ng bawat service. Ibalik ang mga ito gamit ang docker compose start, na muling gumagamit sa eksaktong parehong mga container.

Dahil umiiral pa rin ang mga container, nananatili roon ang anumang isinulat sa loob ng mga ito na wala sa isang volume. Kasama rito ang package na mano-mano mong na-install gamit ang docker compose exec at ang config file na in-edit mo sa loob ng container. Ito ang praktikal na dahilan para mas piliin ang stop habang nagde-debug: maaari kang mag-restart sa parehong state.

docker compose down: inaalis ang mga container at network

down ay humihinto sa mga container at pagkatapos ay inaalis ang mga ito, kasama ang default network na ginawa ng Compose para sa project. Inilalarawan ito ng Docker documentation bilang paghinto sa mga container at pag-aalis ng mga container, network, volume, at image na ginawa ng up, ngunit nangyayari lamang ang pag-aalis ng mga volume at image kapag hiniling mo ito gamit ang -v at --rmi.

docker compose down
docker compose ps -a
docker network ls

Pagkatapos ng down, walang inilalabas na anuman ang ps -a para sa project, at wala na ang <project>_default network. Ang pangalan ng project ay nagmumula sa pangalan ng directory maliban kung itinakda mo ang name: sa Compose file o ipinasa ang -p. Hindi na mababawi ang anumang pagbabagong ginawa mo sa writable layer ng container, kaya ituring ang down bilang command na nagtatanggal sa container at nagpapanatili sa data na inilagay mo sa mga volume.

Kung patatakbuhin mo ito sa maling directory, makukuha mo ang no configuration file provided: not found. Hindi alam ng Compose kung aling project ang tinutukoy mo, kaya tumatanggi itong tumakbo. Gamitin ang docker compose -f /srv/myapp/compose.yaml down kapag wala ka sa project folder.

Tinatanggal ba ng docker compose down ang mga volume ko?

Hindi. Ang named volume na dineklara sa top-level na volumes key ay nananatili lampas sa down, at nananatili rin lampas sa container na pinag-attach-an dito. Ito ang pinakakaraniwang pangamba tungkol sa command, at pareho ang sagot sa lahat ng Compose v2.

Mag-set up ng stack na maaari mong subukan. Ilagay ito sa compose.yaml sa isang walang lamang directory na tinatawag na voltest.

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

volumes:
  pgdata:

Simulan ito at magsulat ng isang row na makikilala mo sa susunod.

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');"

Ngayon, burahin ang container at tingnan ang volume.

docker compose down
docker volume ls

Nakalista pa rin sa output ang voltest_pgdata. Wala na ang container, pero naroon pa rin ang data. Ibalik ang stack at basahin ang row.

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

Makakakuha ka ng isang row na naglalaman ng survived. Ibang container ang bagong container, na may ibang ID, pero naka-attach ito sa parehong volume. Kung kailangan mo ng mas malawak na paliwanag, tinatalakay sa gabay sa mga batayan ng Compose ang named volumes kumpara sa bind mounts at kung saan talaga nakalagay ang bawat isa sa host.

Ano mismo ang sinisira ng down -v

Tinatanggal ng -v (mahabang anyo: --volumes) ang mga named volume na idineklara sa seksyong volumes ng Compose file, pati ang mga anonymous volume na nakakabit sa mga container. Patakbuhin ito sa parehong stack.

docker compose down -v
docker volume ls

Hindi na nakalista ang voltest_pgdata. Simulan muli ang stack. Makakakita ang Postgres entrypoint ng walang laman na data directory, kaya magsisimula ito ng bagong cluster. Malinaw itong ipinapakita ng container log.

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

Kapag nakita mo ang block na iyon sa stack na ilang buwan nang tumatakbo, nangangahulugan itong natanggal ang volume. Nawala na ang iyong marker table, at backup lamang ang paraan para maibalik ito.

May storage na hindi kailanman inaalis ng -v. Ang bind mount ay host path, kaya iniu-unmount lamang ito ng Docker at nananatili ang iyong mga file sa dati nilang lokasyon. Ang volume na may markang external: true ay idineklarang pagmamay-ari ng nasa labas ng project na ito, kaya hindi ito inaalis ng Compose. Ang named volume na tinanggal mo sa Compose file bago patakbuhin ang down -v ay hindi na idineklara. Hindi alam ng Compose na kailangan itong alisin, kaya naiiwan ito bilang orphan para sa docker volume prune.

Madalas itong mangyari kapag nire-refactor ang configuration. Alisin ang isang service at ang volume nito sa file, pagkatapos ay patakbuhin ang down -v. Mapananatili ang volume dahil hindi na ito binabanggit ng file. Patakbuhin ang down -v bago mo i-edit ang file, hindi pagkatapos.

Kapag talagang kailangan ang --force-recreate

docker compose up -d ay hindi muling nagbu-build ng lahat sa bawat pagtakbo. Nag-iimbak ang Compose ng hash ng naresolbang configuration ng bawat service bilang label sa container. Kung magkapareho ang hash at image ID, hindi gagalawin ang container at makakakuha ka ng Container voltest-db-1 Running sa halip na Recreated. Ito ang karaniwang gusto mong mangyari, dahil ligtas na patakbuhin nang paulit-ulit ang up -d.

Ito rin ang dahilan kung bakit may ilang pag-edit na tila walang epekto. Hinahash ng Compose ang naresolbang service definition, hindi ang mga laman ng file na tinutukoy nito. Ang config file na naka-mount sa container at isang beses lang binabasa sa startup ay hindi magti-trigger ng recreate kapag in-edit mo ito, dahil hindi nagbago ang mount path. Patuloy na tumatakbo ang service gamit ang mga value na nabasa nito sa boot.

docker compose up -d --force-recreate

Ihihinto at aalisin nito ang bawat container, pagkatapos ay gagawa ng bago mula sa parehong definition. Gamitin ito pagkatapos mag-edit ng naka-mount na config file, at kapag ang isang container ay napunta sa state na hindi mo maipaliwanag. Hindi gagalawin ang volumes, kaya mananatili ang database pagkatapos ng force recreate. Para makuha ang mas bagong image sa parehong tag, kailangan mo rin ang pull.

docker compose pull
docker compose up -d

Kinukuha ng pull ang bagong image ID, at nakikita naman ng up -d na iba ang image ID nito sa image ID ng tumatakbong container, kaya awtomatiko nitong nire-recreate ang container. Kapag idinagdag ang --force-recreate nang wala ang pull, makakakuha ka ng bagong container mula sa dati ring image. Kaya karaniwan ang reklamo na “nag-force recreate ako pero lumang version pa rin ito.”

Walang ginagawa sa mga ito ang docker compose restart. Nire-restart nito ang mga kasalukuyang container at hindi nito muling binabasa ang Compose file, kaya hindi mailalapat ang binagong environment variable o port mapping. Kung in-edit mo ang file, gamitin ang up -d.

Dapat tandaan na mental model

Napapalitan ang mga container. Ang container ay isang process kasama ang manipis na writable layer, at makakagawa ang Compose ng kaparehong container mula sa file sa loob ng humigit-kumulang isang segundo. Hindi napapalitan ang mga volume dahil nasa mga ito ang nag-iisang kopya ng state na hindi kayang buuing muli ng anumang file sa repository mo.

Tumutugma sa paghahating ito ang bawat Compose verb. Pinananatili ng stop at start ang container. Pinapalitan ng down at up ang container at pinananatili ang volume. Ang down -v lang ang karaniwang command na nag-aalis ng state, kaya kailangan nito ng explicit flag. Bago mo ito i-type sa anumang aktwal na system, tiyaking mayroon kang backup na kahit isang beses mo nang na-restore.

Nalalapat din ang parehong lohika sa mga secret. Ang password na itinakda sa pamamagitan ng POSTGRES_PASSWORD ay binabasa lamang sa unang pag-initialize ng database, kaya kapag binago mo ito sa environment file at pinatakbo ang up -d, makukuha mo ang password authentication failed for user "postgres". Bago ang container at luma ang volume, kaya nasa lumang volume pa rin ang lumang password. Ipinapaliwanag ng Paano nireresolba ng Compose ang env files at secrets kung aling layer ang nangingibabaw kapag dalawang beses itinakda ang parehong variable.

Mga failure mode at mga string na makikita mo

Ang no configuration file provided: not found ay nangangahulugang tumatakbo ang Compose sa isang directory na walang compose.yaml at walang docker-compose.yml. Ibigay ang -f kasama ang buong path.

Ang network voltest_default has active endpoints sa down ay nangangahulugang may container sa labas ng project na nakakabit sa project network. Karaniwan, ito ay container na mano-manong sinimulan gamit ang docker run --network. Alisin ang container na iyon, pagkatapos ay patakbuhin muli ang down.

Lumilitaw ang Found orphan containers ([voltest-old-1]) for this project pagkatapos mong palitan ang pangalan o burahin ang isang service. Taglay pa rin ng lumang container ang project label. Nililinis ito ng docker compose down --remove-orphans, at ligtas itong patakbuhin sa isang maayos na stack.

Ang Error response from daemon: remove voltest_pgdata: volume is in use sa isang manual na docker volume rm ay nangangahulugang may container pa ring tumutukoy sa volume, kabilang ang isang naka-stop na container. Patakbuhin muna ang docker compose down, pagkatapos ay alisin ang volume, o gamitin na lang ang down -v. Sa mas malaking project, ipinapakita ng isang multi service Compose stack kung gaano karaming volume ang maaaring maipon ng isang project.

FAQ

Binubura ba ng docker compose down ang aking database?

Hindi kung nasa named volume o bind mount ang database. Tinatanggal ng down ang mga container at ang project network, ngunit nananatili sa disk ang volume kasama ang buo nitong data. Sa susunod na docker compose up -d, ikinakabit ang bagong container sa parehong volume at naroon pa rin ang data. Named volumes lamang ang tinatanggal ng docker compose down -v, at ang mga ito lamang na idineklara sa seksyong volumes ng Compose file.

Ano ang pagkakaiba ng stop at down para sa container na gusto kong gamitin muli?

Pinananatili ng stop ang container, kaya ibinabalik ka ng docker compose start sa parehong container at writable layer. Nananatili ang anumang manu-mong na-install o na-edit mo sa loob ng container. Tinatanggal ng down ang container, kaya gumagawa ang susunod na up -d ng bagong container mula sa image at nawawala ang mga manu-manong pagbabagong iyon. Habang nagde-debug, gamitin ang stop.

Paano ko tatanggalin ang lahat ng ginawa ng isang Compose project?

Tinatanggal ng docker compose down -v --rmi all --remove-orphans ang mga container, project network, named volumes na idineklara sa file, mga image na ginamit ng mga service, at anumang container na may label pa ng project name. Hindi nito ginagalaw ang mga bind mount o volume na may markang external: true. Suriin muna ang mga mawawala gamit ang docker volume ls bago ito patakbuhin.

Bakit hindi nakikita ng container ko ang pagbabagong ginawa ko sa naka-mount na config file?

Tinutukoy ng Compose kung kailangan nitong gumawa muli ng container sa pamamagitan ng paghahambing ng hash ng resolved service definition. Hindi kasama sa hash na iyon ang nilalaman ng naka-mount na file. Hindi nagbago ang path, kaya patuloy na pinapagana ng Compose ang container gamit ang mga value na binasa nito sa startup. Patakbuhin ang docker compose up -d --force-recreate upang gumawa ng bagong container na muling babasa sa file.

Bakit hindi gumagana ang bago kong POSTGRES_PASSWORD matapos ko itong baguhin?

Binabasa lamang ng Postgres image ang POSTGRES_PASSWORD kapag ini-initialize nito ang isang walang laman na data directory. May initialized cluster na ang volume mo, kaya hindi pinapansin ang variable at nananatiling ginagamit ang lumang password. Makikita mo ang password authentication failed for user "postgres". Baguhin ang password gamit ang ALTER USER sa loob ng tumatakbong database, o tanggapin ang pagkawala ng data at magsimulang muli gamit ang docker compose down -v.