Tofauti kati ya docker compose stop na down

Jibu fupi

docker compose stop husimamisha container na kuziacha kwenye diski. docker compose down husimamisha container kisha kuzifuta pamoja na mtandao ambao Compose iliutengeneza kwa ajili ya mradi huo. Amri zote mbili hazigusi named volume. Kuongeza -v, kama ilivyo kwenye docker compose down -v, hufuta named volume zisizo za nje (non-external) zilizotangazwa kwenye sehemu ya volumes ya faili ya Compose ambazo ni mali ya mradi huu. Kitu ambacho down hufuta ni chochote ambacho container iliandika kwenye safu yake ya kuandika (writable layer), nje ya volume yoyote.

Huo ndio utofauti wote katika aya moja. Sehemu iliyobaki ya mwongozo huu inathibitisha hilo kwa kutumia Postgres volume unayoweza kuona ikinusurika down na kutoweka chini ya down -v, na inaelezea visa viwili ambapo unahitaji --force-recreate.

docker compose stop: kontena hubaki

stop hutuma ishara ya kusimamisha iliyosanidiwa ya kontena, kwa kawaida SIGTERM, kwa mchakato mkuu katika kila kontena, husubiri, kisha hutuma SIGKILL ikiwa mchakato bado unafanya kazi. Muda wa kusubiri chaguo-msingi ni sekunde 10 na -t huubadilisha. Hakuna kinachofutwa. Kontena huhifadhi ID yake, safu yake inayoweza kuandikwa (writable layer), na logi zake.

docker compose stop
docker compose ps -a

docker compose ps pekee huonyesha kontena zinazoendelea kufanya kazi tu, kwa hivyo baada ya stop huchapisha jedwali tupu na watu hufikiri kontena zimepotea. ps -a hujumuisha zile zilizosimamishwa, na hapo ndipo utaona hali ya Exited kando ya kila huduma, pamoja na exit code iliyorejeshwa na mchakato wake. Kuzima kwa usahihi mara nyingi huonyesha Exited (0), lakini si kila wakati. Baadhi ya seva hukamilisha kuzima kwa utaratibu kisha huibua tena ishara ya kusimamisha ili mchakato uishe kwa ishara hiyo, na Uvicorn hufanya hivi hasa, kwa hivyo kusimamisha kwa utaratibu bado kunaweza kuacha code isiyo ya sifuri. Code isiyo ya sifuri inaweza pia kumaanisha mchakato umefeli au uliua baada ya muda kuisha. Zirejeshe kwa docker compose start, ambayo hutumia tena kontena zilezile.

Kwa sababu kontena bado zipo, chochote kilichoandikwa ndani yake nje ya volume bado kipo. Hiyo inajumuisha kifurushi ulichosakinisha kwa mkono kwa docker compose exec, na faili ya usanidi uliyohariri ndani ya kontena. Hii ndiyo sababu ya kivitendo ya kupendelea stop wakati unatatua hitilafu: unaweza kuanzisha upya katika hali ileile.

docker compose down: containers na networks zinaondolewa

down husimamisha containers kisha kuziondoa, pamoja na network ya default ambayo Compose iliunda kwa ajili ya mradi huo. Nyaraka za Docker zinaelezea kuwa hii husimamisha containers na kuondoa containers, networks, volumes na images zilizoundwa na up, lakini sehemu za volumes na images hutokea tu unapozihitaji kwa kutumia -v na --rmi.

docker compose down
docker compose ps -a
docker network ls

Baada ya down, ps -a haitoi matokeo yoyote kwa mradi huo na network ya <project>_default inakuwa haipo tena. Jina la mradi hutokana na jina la saraka ya mradi isipokuwa ukiweka name: kwenye faili ya Compose, ukaweka COMPOSE_PROJECT_NAME, au ukapitisha -p. Kila mabadiliko uliyofanya ndani ya safu inayoweza kuandikwa (writable layer) ya container sasa hayawezi kurejeshwa, kwa hivyo chukulia down kama amri inayotupa container na kuhifadhi data uliyoweka kwenye volumes.

Ikiwa Compose haiwezi kupata faili ya configuration katika saraka ya sasa au saraka mama zake, na hujatoa faili kupitia -f au COMPOSE_FILE, utapata no configuration file provided: not found. Compose haina taarifa kuhusu mradi uliokusudia, kwa hivyo inakataa kufanya kazi. Tumia docker compose -f /srv/myapp/compose.yaml down wakati haupo kwenye folda ya mradi.

Je, docker compose down inafuta volumes zangu?

Hapana. Named volume iliyotangazwa chini ya ufunguo wa kiwango cha juu wa volumes hudumu zaidi ya down, na hudumu zaidi ya container iliyokuwa imeunganishwa nayo. Hii ndiyo hofu ya kawaida kuhusu amri hii. Compose v5.7.0 ilibadilisha down -v: sasa inaruka named volumes zinazomilikiwa na mradi mwingine au zilizoundwa nje ya Compose, huku ikitoa onyo.

Sanidi stack unayoweza kuijaribu. Weka hii kwenye compose.yaml katika saraka tupu inayoitwa voltest.

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

volumes:
  pgdata:

Ianzishe na uandike mstari utakaoutambua baadaye.

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

Sasa haribu container na uangalie volume.

docker compose down
docker volume ls

Matokeo bado yanaorodhesha voltest_pgdata. Container imetoweka na data haijafutwa. Rudisha stack na usome mstari huo.

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

Unapata mstari mmoja wenye survived. Container mpya ni container tofauti yenye ID tofauti, iliyounganishwa kwenye volume ileile. Ikiwa unataka picha pana zaidi, mwongozo wa misingi ya Compose unaelezea named volumes dhidi ya bind mounts na mahali ambapo kila moja huishi kihalisi kwenye host.

Kile ambacho down -v huharibu, kwa usahihi

-v (fomu ndefu --volumes) huondoa named volumes zisizo za nje zilizotangazwa kwenye sehemu ya volumes ya faili ya Compose ambazo ni mali ya mradi huu, pamoja na anonymous volumes zilizounganishwa kwenye containers. Katika Compose v5.7.0, named volume yenye lebo ya umiliki ya mradi mwingine au isiyo na lebo ya mradi hurukwa na onyo; ikiwa umiliki wake hauwezi kukaguliwa, amri inafeli na kuhifadhi volume hiyo. Iendeshe dhidi ya stack ileile.

docker compose down -v
docker volume ls

voltest_pgdata haijaorodheshwa tena. Anzisha stack hiyo tena na Postgres entrypoint itapata saraka ya data tupu, kwa hivyo itaanza cluster mpya. Log ya container inasema hivyo kwa maneno ya wazi.

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

Kuona kizuizi hicho kwenye stack ambayo imekuwa ikifanya kazi kwa miezi inamaanisha Postgres inaanza saraka ya data tupu. Jedwali lako la marker limepotea na njia pekee ya kurudi ni backup.

Baadhi ya hifadhi haiondolewi kamwe na -v. Bind mount ni njia ya host, kwa hivyo Docker huondoa mount tu na faili zako hubaki zilipo. Volume iliyotiwa alama external: true inatangazwa kama mali ya kitu kilicho nje ya mradi huu, na Compose haiiondoi kamwe. Named volume uliyofuta kutoka kwenye faili ya Compose kabla ya kuendesha down -v haijatangazwa tena, kwa hivyo Compose haijui kuiondoa na inaachwa kama yatima kwa ajili ya docker volume prune -a pindi hakuna container inayoiashiria.

Kisa hicho cha mwisho huwakamata watu wakati wa refactor. Ondoa huduma na volume yake kutoka kwenye faili, endesha down -v, na volume inabaki kwa sababu faili haitaji tena. Endesha down -v kabla ya kuhariri faili, si baada ya hapo.

Wakati unapohitaji kutumia --force-recreate

docker compose up -d haijengi upya kila kitu kila wakati. Compose huhifadhi hash ya configuration iliyosuluhishwa ya kila huduma kwenye container kama label. Katika Compose v5.7.0, container inayofanya kazi huachwa kama ilivyo wakati hash ya configuration, ID ya image, na digest ya image-volume zikilingana, viunganisho vyake vya mtandao na mount za volume zilizopewa majina vikiwepo, na hakuna mzazi anayeshiriki namespace au volume anayejengwa upya. Unapata Container voltest-db-1 Running badala ya Recreated. Hiyo ndiyo tabia unayotaka karibu kila wakati, kwa sababu inafanya up -d kuwa salama kuendeshwa mara kwa mara.

Hii pia ndiyo sababu baadhi ya marekebisho yanaonekana kutofanya chochote. Compose hufanya hashing ya ufafanuzi wa huduma uliotatuliwa, si maudhui ya faili ambazo ufafanuzi huo unazielekeza. Faili ya config iliyowekwa (mounted) kwenye container na kusomwa mara moja wakati wa kuanza haitasababisha ujenzi upya (recreate) unapoihariri, kwa sababu njia ya mount haikubadilika. Huduma huendelea kufanya kazi na thamani ilizozisoma wakati wa boot.

docker compose up -d --force-recreate

Hii husimamisha na kuondoa kila container na kuunda mpya kutoka kwa ufafanuzi uleule. Itumie baada ya kuhariri faili ya config iliyowekwa, na wakati container imepotoka hadi hali ambayo huwezi kuielezea. Volume haziguswi, kwa hivyo database husalia baada ya force recreate. Ili kuchukua image mpya zaidi kwenye tag ileile unahitaji pia kufanya pull.

docker compose pull
docker compose up -d

pull huchota ID mpya ya image, na up -d kisha huona ID tofauti ya image kutoka kwa container inayofanya kazi na kuijenga upya yenyewe. Kuongeza --force-recreate bila pull kutakupa container mpya kutoka kwa image ileile ya zamani. Hiyo ndiyo sababu "Nimefanya force recreate na bado ni toleo la zamani" ni malalamiko ya kawaida sana.

docker compose restart haifanyi yoyote kati ya haya. Inawasha upya container zilizopo bila kutumia mabadiliko kwenye configuration zao, kwa hivyo variable ya mazingira iliyobadilishwa au port mapping iliyobadilishwa haitatumika. Ikiwa umehariri faili, tumia up -d.

Mfumo wa kiakili wa kuzingatia

Containers zinaweza kubadilishwa. Container ni mchakato pamoja na safu nyembamba inayoweza kuandikwa, na Compose inaweza kuunda mbadala kutoka kwenye faili na image. Volumes haziwezi kubadilishwa, kwa sababu zinashikilia nakala pekee ya hali (state) ambayo hakuna faili kwenye repository yako inayoweza kuizalisha upya.

Kila kitenzi cha Compose kinaendana na mgawanyo huo. stop na start huhifadhi container. down na up hubadilisha container na kuhifadhi volume. down -v ndiyo amri pekee ya kawaida inayofuta hali (state), ndiyo maana inahitaji flag maalum. Kabla ya kuiandika kwenye mfumo wowote halisi, hakikisha una backup ambayo umewahi kuirejesha angalau mara moja.

Mantiki hiyo hiyo inatumika kwa secrets. Nenosiri lililowekwa kupitia POSTGRES_PASSWORD hutumika tu kuweka nenosiri la database wakati database inapoanzishwa kwa mara ya kwanza, kwa hivyo kulibadilisha kwenye faili yako ya mazingira na kuendesha up -d hakubadilishi nenosiri lililohifadhiwa. Container ni mpya na volume ni ya zamani, na volume ya zamani bado inashikilia nenosiri la zamani. Jinsi Compose inavyotatua faili za env na secrets inaelezea ni safu ipi inayoshinda wakati variable moja imewekwa mara mbili.

Njia za kufeli na ujumbe utakaouona

no configuration file provided: not found inamaanisha kuwa Compose haikuweza kupata faili ya usanidi kupitia saraka ya sasa na utafutaji wa saraka mama, -f, au COMPOSE_FILE. Pitisha -f ikiwa na njia kamili ya faili.

Network voltest_default Resource is still in use kwenye down katika Compose v5.7.0 inamaanisha kuwa kontena bado zimeunganishwa kwenye mtandao wa mradi, kwa kawaida zile zilizo nje ya mradi huu zilizozinduliwa kwa mkono kwa kutumia docker run --network. Ondoa kontena hizo, kisha uendeshe down tena.

Found orphan containers (voltest-old-1) for this project huonekana baada ya kubadilisha jina au kufuta huduma. Compose ya sasa huorodhesha majina hayo bila alama za ziada na yakiwa yametenganishwa kwa koma. Matoleo ya zamani ya Compose v2 huchapisha onyo lilelile huku majina yakiwa ndani ya mabano ya mraba, kama ilivyo katika ([voltest-old-1]). Kontena la zamani bado hubeba lebo ya mradi. docker compose down --remove-orphans huyafuta.

Error response from daemon: remove voltest_pgdata: volume is in use kwenye docker volume rm ya mwongozo inamaanisha kuwa kontena fulani bado linarejelea volume hiyo, ikiwemo kontena lililosimamishwa. Endesha docker compose down kwanza, kisha uondoe volume hiyo, au tumia tu down -v. Katika mradi mkubwa, stack ya Compose yenye huduma nyingi inaonyesha ni kiasi gani cha volume ambacho mradi mmoja unaweza kukusanya.

FAQ

Je, docker compose down hufuta database yangu?

Haitafuta ikiwa database imehifadhiwa kwenye named volume au bind mount. down huondoa container na mtandao wa mradi, na volume hubaki kwenye diski ikiwa na data zake. docker compose up -d inayofuata huunganisha container mpya kwenye volume ileile na data zitakuwepo. docker compose down -v huondoa named volumes zisizo za nje (non-external) zilizotangazwa kwenye sehemu ya volumes ya faili ya Compose ambazo ni za mradi huu.

Kuna tofauti gani kati ya stop na down kwa container ninayotaka kuirejesha?

stop huacha container ikiwa ipo, kwa hivyo docker compose start hukurudisha kwenye container ileile yenye safu ya data (writable layer) ileile. Kila kitu ulichokisakinisha au kukihariri ndani ya container kwa mikono bado kitakuwepo. down hufuta container, kwa hivyo up -d inayofuata hujenga container mpya kutoka kwenye image na mabadiliko hayo ya mikono hupotea. Unapofanya debugging, tumia stop.

Ninawezaje kuondoa kila kitu kilichoundwa na mradi wa Compose?

docker compose down -v --rmi all --remove-orphans huondoa container, mtandao wa mradi, named volumes zisizo za nje zilizotangazwa kwenye faili ambazo ni za mradi huu, image zilizotumiwa na huduma, na container zozote za ziada (orphan containers) za mradi huo. Haigusi bind mounts au volumes zilizowekewa alama ya external: true. Hakikisha unachotaka kufuta kwa kutumia docker volume ls kabla ya kukiendesha.

Kwa nini container yangu hupuuza mabadiliko niliyofanya kwenye faili ya config iliyopachikwa (mounted)?

Compose huamua kama itaunda upya container kwa kulinganisha hash ya ufafanuzi wa huduma, na hash hiyo haijumuishi yaliyomo kwenye faili iliyopachikwa. Njia (path) haikubadilika, kwa hivyo Compose huacha container ikiendelea kufanya kazi na thamani ilizozisoma wakati wa kuanza. Endesha docker compose up -d --force-recreate ili kujenga container mpya inayosoma faili hiyo tena.

Kwa nini POSTGRES_PASSWORD yangu mpya haifanyi kazi baada ya kuibadilisha?

Image ya Postgres hutumia POSTGRES_PASSWORD kuweka nenosiri la database wakati tu inapoanzisha saraka tupu ya data. Volume yako tayari ina cluster iliyoanzishwa, kwa hivyo variable hiyo hupuuzwa na nenosiri la zamani bado linatumika. Kujaribu kuunganisha kwa nenosiri jipya kutakupa password authentication failed for user "postgres". Badilisha nenosiri kwa kutumia ALTER USER ndani ya database inayofanya kazi, au kubali kupoteza data na uanze upya kwa docker compose down -v.