Amri za Docker Compose kwa Seva Halisi

Amri za Compose unazotumia kwa vitendo

Docker Compose hutoa zaidi ya amri ndogo 40. Kazi za kila siku kwenye seva hutumia takribani dazeni moja. Ukurasa huu unazipanga kulingana na kazi unayofanya, unaeleza sababu moja wazi kwa kila amri, na unaelekeza kwenye maelezo ya kina pale amri inapoficha tatizo.

Kila kitu hapa kinatumia Compose V2: docker compose ikiwa na nafasi, si script ya zamani ya docker-compose. V2 ni programu-jalizi ya Go inayosakinishwa pamoja na Docker Engine, na V1 haipo tena kwenye vifurushi vya sasa. Kwa hiyo, docker-compose: command not found kwenye mfumo mpya wa Ubuntu kufikia Julai 2026 ni hali inayotarajiwa, si hitilafu. Kagua kwa docker compose version. Ikiwa hiyo haitoi kitu, sakinisha kifurushi cha docker-compose-plugin.

Kila amri iliyo hapa chini inaendeshwa kutoka kwenye saraka iliyo na compose.yaml, kwa sababu Compose huchukua jina la mradi kutoka kwenye saraka hiyo na hutafuta faili humo. Ukiendesha amri hiyo kutoka kiwango kimoja juu, Compose husitisha utekelezaji kwa no configuration file provided: not found. Ikiwa muundo wa faili wenyewe bado ni mpya kwako, anza na faili ya kwanza ya Compose kwenye VPS kisha urudi hapa kwa ajili ya amri.

Mzunguko wa maisha: amri nne unazoandika, na amri moja inayoondoa kontena

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

up -d huunda mtandao, huunda kontena, huziwasha, kisha hurudi. Hurudi mara tu kontena zinapoundwa, ndiyo sababu hati ya upelekaji inayofuata kwa uchunguzi wa curl mara nyingi hushindwa katika jaribio la kwanza. up -d --wait husubiri hadi kila huduma iliyotangaza healthcheck iripoti kuwa na afya, na hutoka kwa msimbo usio sifuri ikiwa huduma yoyote haifiki hali hiyo. Bendera hii ina ufanisi kulingana na ukaguzi unaoiunga mkono, kwa hiyo andika healthcheck ambayo Compose inaweza kuiamini kabla ya kuitumia katika uwekaji otomatiki.

stop husimamisha kontena na kuzihifadhi, kwa hiyo start hurudisha kontena zilezile pamoja na safu ileile inayoweza kuandikwa. down huzisimamisha, kisha huondoa kontena na mtandao wa mradi. Kitu chochote kilichoandikwa ndani ya kontena na nje ya volume huondolewa pamoja nazo. Hilo ndilo kosa la uelewa lenye gharama kubwa zaidi katika Compose, na tofauti kamili kati ya down na stop inaeleza mahali linapotokea.

restart si reload. Husimamisha na kuwasha kontena lilelile kwa kutumia usanidi lilionao tayari, kwa hiyo mabadiliko ya kigezo cha mazingira, tag mpya ya image au mabadiliko ya port mapping hayana athari yoyote. Ili kutumia mabadiliko ya faili, endesha up -d tena. Compose hulinganisha kila huduma na kontena lake linaloendesha, kisha huunda upya zile ambazo usanidi wake umebadilika pekee.

Kutumia mabadiliko: kuunda upya, kuvuta, au kujenga upya

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 peke yake haifanyi chochote ikiwa hakuna kilichobadilika. Hilo huifanya iwe salama kuiendesha mara kwa mara. --force-recreate hupuuza ulinganisho huo na kubadilisha kila container hata usanidi unapofanana. Kwa hiyo, ndiyo njia ya haraka zaidi ya kuondoa hali isiyo ya kawaida ndani ya container.

Kusasisha image kunahitaji commands mbili kwa sababu zinafanya mambo mawili tofauti. pull hupakua image ya sasa kwa kila tag iliyotajwa kwenye faili. Kisha up -d hutambua kuwa image ID ya service hailingani tena na container inayofanya kazi, na huiunda upya. Ukiruka pull, up -d itaendelea kutumia latest ya mwezi uliopita bila kosa.

build hutumika kwa services zinazotangaza sehemu ya build: badala ya image:. up -d --build hujenga na kuanzisha kwa hatua moja. Huo ndio mzunguko wa kawaida unapobadilisha msimbo. Tumia --no-cache tu wakati layer iliyowekwa kwenye cache imepitwa na wakati waziwazi, kwa sababu hujenga upya kila layer kutoka mwanzo.

Kuona kinachoendesha

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 huorodhesha kontena zinazoendesha pekee. Huduma iliyoharibika wakati wa kuanza haionekani hapo hadi uongeze -a. Kwa hiyo, kontena ambalo halipo kwenye ps huku ps -a likilionyesha kama Exited (1) ni hali ya kawaida ya kushindwa kuanza. Soma msimbo wa kutoka, kisha soma kumbukumbu.

logs -f hufuata kila huduma kwa wakati mmoja na huweka jina la huduma mwanzoni mwa kila mstari. Huu ndio mwonekano unaohitaji huduma zinapowasiliana na mpangilio wa matukio unapokuwa muhimu. Taja huduma ili kupunguza matokeo. --tail=100 ni muhimu kwenye kontena ambalo limekuwa likiendesha kwa mwezi mmoja, kwa sababu mpangilio chaguo-msingi huchapisha historia yote na kujaza terminal. --since 15m hujibu swali unalouliza mara nyingi: nini kilitokea wakati wa kuwasha upya uliokamilisha hivi karibuni.

top huorodhesha michakato iliyo ndani ya kila kontena. Hii hutofautisha kati ya “kontena linaendesha” na “mchakato ulio ndani yake unaendesha”. ls hutoka kwenye saraka ya sasa na huorodhesha kila mradi wa Compose kwenye host pamoja na hali yake. Hivyo unaweza kupata stack uliyoanzisha miezi mitatu iliyopita.

Kupata shell ndani ya service

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 huendesha amri ndani ya container ambayo tayari iko katika hali ya uendeshaji. run huanzisha container mpya kwa kutumia ufafanuzi uleule wa service. Hili ndilo unalohitaji wakati service haibaki katika hali ya uendeshaji kwa muda wa kutosha kutumia exec. Daima tumia run pamoja na --rm. Bila chaguo hilo, kila utekelezaji huacha container iliyosimamishwa, na hizo hujazana hadi docker compose ps -a isiweze kusomeka.

Jaribu sh kabla ya bash. Images zinazotumia Alpine hazina bash, na hitilafu huonyesha exec: "bash": executable file not found in $PATH. Kuongeza --no-deps kwenye run huruka dependencies za service. Hivyo ukaguzi wa haraka wa usanidi hauanzishi database yako yote.

run --rm web env ndiyo njia ya haraka zaidi ya kuona mazingira ambayo service ilipokea kwa kweli, baada ya kila faili ya .env, block ya environment: na variable ya shell kuunganishwa. Thamani inapokuwa si sahihi, mpangilio wa uunganishaji huwa kwa kawaida ndiyo sababu. jinsi Compose inavyotatua faili za env na secrets inaeleza ni chanzo kipi hutangulia.

Mitandao, milango na utatuzi wa majina

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

Compose huweka kila service kwenye mtandao mmoja wa mradi, na jina la kila service huwa jina la DNS kwenye mtandao huo. Kuendesha getent hosts db ndani ya web huonyesha IP ya container utatuzi unapofaulu, na hakuonyeshi chochote unaposhindikana. Hivyo, ndani ya sekunde mbili hujibu swali "je, container hizi zinaweza kuwasiliana?" Jina likitatuliwa lakini muunganisho ukakataliwa, process iliyo ndani ya db imefungwa kwenye 127.0.0.1 badala ya 0.0.0.0. Kwa hiyo, haipokei packet kutoka kwa container nyingine. Maelezo mengine ya muundo huo yako katika jinsi mitandao ya Compose na DNS ya service inavyofanya kazi.

port web 80 huonyesha anwani ya host na port ambayo port ya container imechapishwa, hivyo huondoa hitaji la kukisia wakati mapping imetoka kwenye variable. Kuchapisha port pia huandika firewall rule ambayo Docker huisimamia yenyewe. Rule hiyo hutangulia rule zako, kwa hiyo service uliyodhani ni ya faragha inaweza kuwa wazi kwa internet. Hali hiyo imeelezwa katika kwa nini port za Docker zilizochapishwa hupita ufw.

Volumu na data

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

config --volumes huonyesha volumu zilizopewa majina ambazo mradi umetangaza, moja kwa kila mstari. Orodha hiyo ndiyo unayopaswa kuhifadhi nakala. cp hunakili faili kuingia au kutoka kwenye kontena bila kufungua shell, kwa kutumia muundo wa service:path upande wowote ambao ni wa kontena.

down -v huondoa volumu hizo zilizopewa majina pamoja na makontena. Hii ndiyo amri sahihi ya kuondoa stack ya majaribio, lakini si sahihi kwa kitu chochote chenye data muhimu, kwa sababu hakuna uthibitishaji wala njia ya kutendua. Bind mounts hubaki, kwa kuwa huhifadhiwa kwenye mfumo wa faili wa host. Tofauti hii katika ukubwa wa athari ni mojawapo ya sababu za kuchagua kwa makusudi kati ya bind mounts na volumu zilizopewa majina.

Usafishaji unaofungua nafasi ya diski bila kupoteza data

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

--remove-orphans hufuta kontena za mradi ambazo hazionekani tena kwenye faili. Hilo ndilo hutokea baada ya kubadilisha jina la huduma. Bila chaguo hilo, kontena hizo huendelea kufanya kazi bila kuonekana kwenye docker compose ps.

docker system df huonyesha diski ilitumikaje kabla ya kufuta chochote. Hupanga picha, kontena, ujazo wa ndani na akiba ya ujenzi, pamoja na kiasi kinachoweza kurejeshwa kwa kila moja. image prune -a huondoa kila picha ambayo hakuna tag inayorejelea. Kwenye seva iliyopakua matoleo kadhaa ya picha kubwa, hatua hiyo kwa kawaida hutoa nafasi kubwa zaidi. builder prune husafisha akiba ya ujenzi, ambayo hukua polepole kwenye seva yoyote inayounda picha zake yenyewe.

Hakuna amri kati ya hizo inayogusa ujazo wenye jina. Ni docker volume prune na docker compose down -v pekee zinazofanya hivyo.

Kukagua faili kabla haijasababisha tatizo

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

config --quiet hufanya uthibitishaji na haitoi kitu chochote ikiwa hakuna hitilafu. Kwa hiyo, iweke katika hatua ya kabla ya deployment au katika git hook. config ya kawaida huchapisha faili iliyounganishwa na kubadilishwa kikamilifu. Hivi ndivyo unavyothibitisha kuwa kigezo kimetatuliwa na faili ya override imepangwa kwa namna uliyotarajia. Kigezo ambacho hakijawekwa huonekana kama thamani tupu, pamoja na onyo The "X" variable is not set. Defaulting to a blank string.

--dry-run ni global flag badala ya subcommand flag, kwa hiyo huwekwa kabla ya up. Huchapisha kila hatua ambayo Compose ingefanya bila kubadilisha chochote. Hivyo, ni sekunde thelathini zinazotumika vizuri kabla ya down kwenye stack muhimu.

Kufanya kazi kati ya faili, profaili na miradi

docker compose -f compose.yaml -f compose.prod.yaml up -d
docker compose --profile debug up -d
docker compose -p staging up -d

Bendera nyingi za -f huunganishwa kwa mpangilio, na faili za baadaye hubatilisha faili za awali kwa kila ufunguo. Hii ndiyo njia ya kawaida ya kuweka faili moja ya msingi pamoja na faili ndogo ya kubatilisha mipangilio ya uzalishaji. Hata hivyo, kanuni hutofautiana kwa orodha na ramani, kwa hiyo soma jinsi Compose huunganisha faili nyingi kabla ya kutatua tatizo lisilotarajiwa.

--profile huanzisha huduma zilizo na lebo ya profaili hiyo pamoja na huduma zisizo na lebo. Hivyo, zana za utatuzi hazijumuishwi katika up ya kawaida. -p huweka jina la mradi, kwa hiyo nakala mbili za stack moja zinaweza kuendeshwa kwa wakati mmoja zikiwa na mitandao tofauti na majina tofauti ya volume. Kurejesha stack baada ya kuwashwa upya si amri unayoandika mwenyewe. Ni unit inayokuendeshea amri hiyo, kama ilivyoelezwa katika kuanzisha stack za Compose wakati wa kuwasha mfumo.

FAQ

Ni nini kilichochukua nafasi ya docker-compose chenye kistari?

Compose V2, inayoitwa kwa docker compose yenye nafasi. Ni programu-jalizi inayokuja pamoja na Docker Engine, na zana ya Python ya V1 haisakinishwi tena na vifurushi vya sasa. Ikiwa mfumo wa kuandika wenye nafasi hautoi matokeo, sakinisha kifurushi cha docker-compose-plugin cha usambazaji wako. Sasisha hati za zamani zitumie mfumo wenye nafasi badala ya kuongeza alias, kwa sababu V2 ina flags ambazo V1 haikuwa nazo.

Kwa nini docker compose restart haitumii mabadiliko yangu ya usanidi?

restart husimamisha na kuanzisha tena container iliyopo kwa kutumia usanidi uliotumika kuunda container hiyo, na haisomi tena compose.yaml. Mabadiliko yoyote ya vigezo vya mazingira, ports, volumes au tag ya image yanahitaji docker compose up -d, ambayo hulinganisha kila service na container yake inayoendesha na kuunda upya zile zinazotofautiana. Ongeza --force-recreate unapotaka replacement ifanyike hata kama hakuna kilichobadilika kwenye faili.

Ninawezaje kusasisha service itumie image mpya zaidi?

Tekeleza docker compose pull, kisha docker compose up -d. Pull hupakua image ya sasa kwa kila tag iliyo kwenye faili, na up -d huunda upya service yoyote ambayo image ID yake hailingani tena na container yake. Kutekeleza up -d pekee hutumia tena image iliyo tayari kwenye diski. Hivyo stack iliyofungwa kwenye latest inaweza kubaki kwenye build yenye umri wa miezi bila kuonyesha kosa lolote.

Ni amri zipi za usafishaji zilizo salama kwenye server inayoendesha?

docker system df, docker image prune -a na docker builder prune huondoa images na cache pekee. Kwa hiyo services zinazoendesha huendelea kufanya kazi, na named volumes haziguswi. Jozi hatari ni docker compose down -v na docker volume prune, ambazo hufuta named volumes bila kuuliza uthibitisho. Tekeleza docker compose config --volumes kwanza ili ujue vilivyo hatarini.

Je, ninaweza kutekeleza amri moja bila kuanzisha stack nzima?

Ndiyo. docker compose run --rm --no-deps web sh huanzisha container moja kutoka kwenye service definition ya web, huruka dependencies zake, na huondoa container unapotoka. Tumia exec badala yake ikiwa container tayari inaendesha, kwa sababu exec hujiunga na process inayoendelea na kukuonyesha hali halisi ya service.