Amri za Docker Compose kwa seva: Mwongozo wa haraka

Amri za Compose unazotumia mara kwa mara

Docker Compose ina subcommands zaidi ya arobaini. Kazi za kila siku kwenye seva hutumia kama kumi na mbili hivi. Ukurasa huu unazipanga amri hizo kulingana na kazi unayofanya, unatoa sababu moja rahisi kwa kila moja, na unaelekeza kwenye maelezo ya kina pale amri inapoficha mtego.

Kila kitu hapa kinatumia Compose V2: docker compose ikiwa na nafasi, si ule script wa zamani wa docker-compose. V2 ni Go plugin inayofungwa pamoja na Docker Engine, na V1 haipo tena kwenye vifurushi vya sasa, kwa hivyo docker-compose: command not found kwenye mashine mpya ya Ubuntu kufikia Julai 2026 inatarajiwa kufanya kazi badala ya kuharibika. Hakikisha kwa kutumia docker compose version. Ikiwa haitoi matokeo yoyote, funga kifurushi cha docker-compose-plugin.

Kila amri hapa chini inaendeshwa kutoka kwenye saraka iliyo na compose.yaml yako, kwa sababu Compose huchukua jina la mradi kutoka kwenye saraka hiyo na kutafuta faili kulingana na eneo hilo. Endesha amri hiyo hiyo ukiwa ngazi moja juu na Compose itasimama na kutoa no configuration file provided: not found. Ikiwa muundo wa faili wenyewe ni mgeni kwako, anza na faili ya kwanza ya Compose kwenye VPS kisha urudi hapa kwa ajili ya amri hizi.

Mzunguko wa maisha: amri nne unazotumia, na ile inayofuta containers

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

up -d hutengeneza mtandao, hutengeneza containers, huzianzisha, na kurejea. Inarejea mara tu containers zinapokuwa zimetengenezwa, ndiyo maana hati ya deploy inayofuatiwa na uchunguzi wa curl mara nyingi hushindwa kwenye jaribio la kwanza. up -d --wait husubiri hadi kila huduma inayotangaza healthcheck iripoti kuwa iko salama, na hutoka kwa status isiyo ya sifuri ikiwa huduma yoyote haitafika hapo. Flag hii ni nzuri kulingana na ubora wa check iliyo nyuma yake, kwa hivyo andika healthcheck ambayo Compose inaweza kuiamini kabla ya kuitegemea katika otomatiki.

stop husimamisha containers na kuzihifadhi, kwa hivyo start huleta containers zilezile tena zikiwa na safu ileile ya kuandikika (writable layer). down huzisimamisha kisha hufuta containers na mtandao wa mradi. Kila kitu kilichoandikwa ndani ya container na nje ya volume hupotea pamoja nazo. Hiyo ndiyo kutoelewana kwa gharama kubwa zaidi katika Compose, na tofauti kamili kati ya down na stop inaelezea mahali ambapo jambo hili huleta madhara.

restart siyo reload. Inasimamisha na kuanzisha container ileile ikiwa na usanidi ilionao tayari, kwa hivyo variable ya mazingira iliyobadilishwa, tag mpya ya image au port mapping iliyohaririwa haina athari yoyote. Ili kutumia mabadiliko ya faili unapaswa kuendesha up -d tena. Compose hulinganisha kila huduma na container yake inayofanya kazi na kutengeneza upya zile tu ambazo usanidi wake umebadilika.

Kutumia mabadiliko: recreate, pull, au 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 web

up -d pekee haifanyi kazi yoyote ikiwa hakuna kilichobadilika, ndiyo maana ni salama kuiendesha mara kwa mara. --force-recreate hupuuza ulinganisho huo na kuchukua nafasi ya kila container hata kama usanidi ni uleule, kwa hivyo ndiyo njia ya haraka zaidi ya kufuta hali isiyo ya kawaida ndani ya container.

Kusasisha image kunahitaji amri mbili kwa sababu zinafanya kazi mbili tofauti. pull hupakua image ya sasa kwa kila tag iliyotajwa kwenye faili. up -d kisha huona kuwa ID ya image ya huduma hailingani tena na container inayofanya kazi na kuunda upya container hiyo. Ruka hatua ya pull na up -d itaendelea kuendesha latest ya mwezi uliopita bila hitilafu.

build inahusu huduma zinazotangaza sehemu ya build: badala ya image:. up -d --build hujenga na kuanza katika hatua moja, ambayo ndiyo mzunguko wa kawaida wakati unabadilisha msimbo. Tumia --no-cache pale tu ambapo layer iliyohifadhiwa (cached layer) imepitwa na wakati, kwa sababu inajenga upya kila layer kuanzia mwanzo.

Kuona kinachoendelea

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 container zinazoendelea pekee. Huduma iliyokwama wakati wa kuanza haionekani hapo hadi utakapoongeza -a, kwa hivyo container inayokosekana kwenye ps wakati ps -a ikionyesha kama Exited (1) ni hali ya kawaida ya hitilafu wakati wa kuanza. Soma exit code, kisha soma logs.

logs -f hufuatilia kila huduma kwa wakati mmoja na kuweka jina la huduma mwanzoni mwa kila mstari, huu ndio mtazamo unaohitaji wakati huduma zinawasiliana na mpangilio wa matukio ni muhimu. Taja jina la huduma ili kupunguza wigo. --tail=100 ni muhimu kwenye container ambayo imekuwa ikifanya kazi kwa mwezi mzima, kwa sababu chaguo-msingi huchapisha historia nzima na kujaza terminal. --since 15m hujibu swali ambalo kwa kawaida unalo, nalo ni nini kilitokea wakati wa restart uliyofanya sasa hivi.

top huorodhesha processes ndani ya kila container, jambo linalotofautisha kati ya "container inafanya kazi" na "process iliyo ndani yake inafanya kazi". ls hutoka nje ya saraka ya sasa na kuorodhesha kila mradi wa Compose kwenye host pamoja na hali yake, ili uweze kupata stack uliyoianzisha miezi mitatu iliyopita.

Kupata shell ndani ya huduma

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 inafanya kazi. run huanzisha container mpya kutoka kwenye ufafanuzi uleule wa huduma, jambo ambalo unahitaji pale huduma inaposhindwa kukaa hewani kwa muda mrefu ili uweze kufanya exec. Daima unganisha run na --rm, kwa sababu bila kufanya hivyo kila uendeshaji huacha container iliyosimamishwa nyuma, na hizo hujikusanya hadi docker compose ps -a inakuwa haiwezi kusomeka.

Jaribu sh kabla ya bash. Image zinazotegemea Alpine hazina bash, na kosa linalotokea linasomeka kama exec: "bash": executable file not found in $PATH. Kuongeza --no-deps kwenye run huruka utegemezi wa huduma hiyo, jambo linalozuia ukaguzi wa haraka wa usanidi (config check) usianzishe database yako nzima.

run --rm web env ndiyo njia ya haraka zaidi ya kuona mazingira (environment) ambayo huduma imepata kihalisi, baada ya kila faili ya .env, block ya environment: na variable ya shell kuunganishwa. Thamani inapokuwa si sahihi, mpangilio wa uunganishaji (merge order) ndiyo sababu ya kawaida, na jinsi Compose inavyotatua faili za env na siri inaelezea ni chanzo kipi kinachoshinda.

Mitandao, port, na utatuzi wa majina

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

Compose huweka kila huduma kwenye mtandao mmoja wa mradi, na kila jina la huduma huwa jina la DNS kwenye mtandao huo. Kuendesha getent hosts db ndani ya web huchapisha IP ya container wakati utatuzi wa jina unafanya kazi na huchapisha kitu chochote wakati haufanyi kazi, kwa hivyo inajibu swali "je, hizi container zinaweza kuonana" ndani ya sekunde mbili. Ikiwa jina linatatuliwa lakini muunganisho unakataliwa, mchakato ndani ya db umefungwa kwenye 127.0.0.1 badala ya 0.0.0.0, kwa hivyo haikubali pakiti kutoka kwa container nyingine. Maelezo mengine ya mfumo huo yapo katika jinsi mitandao ya Compose na DNS ya huduma inavyofanya kazi.

port web 80 huchapisha anwani ya host na port ambayo port ya container imechapishwa, jambo ambalo huondoa kubahatisha wakati mapping inatoka kwenye variable. Kuchapisha port pia huandika sheria ya firewall ambayo Docker huimudu yenyewe, na sheria hiyo hukaa mbele ya zako, kwa hivyo huduma uliyodhani ni ya faragha inaweza kuwa wazi kwa Internet. Kisa hicho kimefafanuliwa katika kwa nini port za Docker zilizochapishwa hupita ufw.

Volumes na data

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

config --volumes huorodhesha volumes zenye majina ambazo mradi hutangaza, moja kwa kila mstari. Orodha hiyo ndiyo unayopaswa kuhifadhi (backup). cp hunakili faili ndani au nje ya container bila kufungua shell, kwa kutumia muundo wa service:path kwenye upande wowote ulio container.

down -v huondoa volumes hizo zenye majina pamoja na containers. Hii ndiyo amri sahihi ya kubomoa stack ya majaribio na ni amri mbaya kwa kitu chochote kinachohifadhi data unayojali, kwa sababu hakuna uthibitisho na hakuna njia ya kutendua. Bind mounts hupona baada ya amri hii, kwa sababu huishi kwenye filesystem ya host. Pengo hilo katika wigo wa uharibifu ni sababu moja ya kuchagua kwa makini kati ya bind mounts na named volumes.

Usafishaji unaoachia nafasi ya diski bila kupoteza data

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

--remove-orphans hufuta container ambazo ni za mradi husika lakini hazionekani tena kwenye faili, jambo ambalo hutokea baada ya kubadilisha jina la huduma. Bila amri hii, container hizo huendelea kufanya kazi, zikiwa hazionekani kwa docker compose ps.

docker system df huonyesha mahali ambapo diski imetumika kabla ya kufuta chochote, ikigawanya picha (images), container, local volumes na build cache huku ikionyesha kiasi kinachoweza kurejeshwa kwa kila kimoja. image prune -a huondoa kila picha ambayo haina tag inayoelekeza kwake, na kwenye seva iliyopakua matoleo kadhaa ya picha kubwa, hii kwa kawaida ndiyo njia inayotoa nafasi nyingi zaidi. builder prune husafisha build cache, ambayo hukua kimya kimya kwenye seva yoyote inayojijengea picha zake.

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

Kukagua faili kabla ya kusababisha hitilafu

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

config --quiet hufanya uthibitisho na haitoi matokeo yoyote ikifanikiwa, hivyo inafaa kutumika katika hatua ya kabla ya deploy au kwenye git hook. config ya kawaida huchapisha faili iliyounganishwa na kuingizwa data kikamilifu; hii ndiyo njia ya kuhakikisha kuwa variable imetatuliwa na faili ya override imepangwa kama ulivyotarajia. Variable ambayo haijawekwa thamani huonekana hapo kama thamani tupu, kando ya onyo la The "X" variable is not set. Defaulting to a blank string..

--dry-run ni flag ya kimataifa badala ya kuwa flag ya subcommand, kwa hivyo huwekwa kabla ya up. Inachapisha kila hatua ambayo Compose ingechukua bila kubadilisha chochote; huu ni muda uliotumika vyema kabla ya kufanya down kwenye stack muhimu.

Kufanya kazi na 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 zile za awali kulingana na ufunguo (key). Hii ndiyo njia ya kawaida ya kuhifadhi faili moja ya msingi yenye marekebisho madogo ya uzalishaji (production), ingawa sheria hutofautiana kwa orodha (lists) na ramani (maps), kwa hivyo soma jinsi Compose inavyounganisha faili nyingi kabla ya kutatua tatizo usilolitarajia.

--profile huanzisha huduma zilizowekewa alama ya profaili hiyo pamoja na zile zisizo na alama, jambo ambalo huweka zana za utatuzi (debug tooling) nje ya up ya kawaida. -p huweka jina la mradi, ili nakala mbili za stack moja ziweze kufanya kazi sambamba zikiwa na mitandao tofauti na majina tofauti ya volume. Kurudisha stack baada ya reboot si amri unayoiandika, bali ni unit inayoiendesha kwa ajili yako, iliyoelezwa katika kuanzisha Compose stacks wakati wa boot.

FAQ

Ni nini kilichochukua nafasi ya docker-compose kwa kutumia alama ya hyphen?

Compose V2, inayotumika kama docker compose ikiwa na nafasi (space). Hii ni plugin iliyounganishwa na Docker Engine, na zana ya Python ya V1 haisakinishwi tena na vifurushi vya sasa. Ikiwa fomu yenye nafasi haitoi matokeo yoyote, sakinisha kifurushi cha docker-compose-plugin kwa ajili ya mfumo wako (distribution). Sasisha hati (scripts) za zamani ili zitumie fomu yenye nafasi badala ya kuongeza alias, kwa sababu V2 ina flags ambazo V1 haikuwa nazo.

Kwa nini docker compose restart haioni mabadiliko yangu ya usanidi?

restart husimamisha na kuanzisha upya container iliyopo kwa kutumia usanidi uliotumika wakati wa kuiumba, na haisomi tena compose.yaml. Mabadiliko yoyote kwenye environment variables, ports, volumes au image tag yanahitaji docker compose up -d, ambayo hulinganisha kila huduma na container yake inayofanya kazi na kuunda upya zile zinazotofautiana. Ongeza --force-recreate pale unapotaka uingizwaji ufanyike hata kama hakuna kilichobadilika kwenye faili.

Ninawezaje kusasisha huduma ili itumie image mpya zaidi?

Tekeleza docker compose pull, kisha docker compose up -d. Amri ya pull huchota image ya sasa kwa kila tag iliyo kwenye faili, na up -d huunda upya huduma yoyote ambayo ID ya image yake hailingani tena na container yake. Kutekeleza up -d pekee hutumia tena image iliyopo kwenye diski, ndiyo maana stack iliyofungwa kwenye latest inaweza kubaki kwenye build ya miezi kadhaa bila kutoa kosa lolote.

Ni amri zipi za usafishaji ni salama kwenye seva inayofanya kazi?

docker system df, docker image prune -a na docker builder prune huondoa images na cache pekee, kwa hivyo huduma zinazoendelea kufanya kazi hazitaathirika na named volumes hazitaguswa. 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 nini kiko hatarini.

Je, ninaweza kutekeleza amri moja bila kuanzisha stack nzima?

Ndiyo. docker compose run --rm --no-deps web sh huanzisha container moja kutoka kwenye ufafanuzi wa huduma ya web, huruka dependencies zake, na kuifuta container hiyo unapotoka. Tumia exec badala yake wakati container tayari inafanya kazi, kwa sababu exec hujiunga na mchakato unaoendelea na kukuonyesha hali halisi ya huduma hiyo.