Amri za Docker Compose kwa seva: Mwongozo wa haraka

Amri za Compose unazotumia mara kwa mara

Docker Compose ina subcommands zaidi ya arobaini. Kazi ya 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 yenye nafasi, siyo hati ya zamani ya docker-compose. V2 ni plugin ya Go 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 mpya 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, kisha humaliza kazi. Inamaliza kazi 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 sawa, na inatoa exit code isiyo sifuri ikiwa huduma yoyote haitafika hali hiyo. Flag hii ni nzuri kulingana na 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 zikiwa na writable layer ileile. down huzisimamisha kisha hufuta containers na mtandao wa mradi. Kila kitu kilichoandikwa ndani ya container na nje ya volume hupotea pamoja nazo. Hilo ndilo kosa la kuelewa la gharama kubwa zaidi katika Compose, na tofauti kamili kati ya down na stop inaelezea mahali ambapo kosa hili huleta madhara.

restart siyo reload. Inasimamisha na kuanzisha container ileile kwa usanidi ilionao tayari, kwa hivyo environment variable iliyobadilishwa, image tag mpya au port mapping iliyohaririwa haina athari yoyote. Ili kutumia mabadiliko ya faili, unaendesha 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 chochote 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 hufanya mambo mawili tofauti. pull hupakua image ya sasa kwa kila tag iliyotajwa kwenye faili. Kisha up -d hutambua kuwa ID ya image ya service hailingani tena na container inayoendesha, na huiunda upya. Ukiruka pull, up -d itaendelea kuendesha latest ya mwezi uliopita bila kosa. Hatari iliyo kinyume huonekana kwenye stack yenye services nyingi, ambapo kupakua latest kwa kila service kwa wakati mmoja kunaweza kuvuruga app iliyokuwa ikifanya kazi sekunde kumi zilizopita. Ndiyo sababu workspace ya AFFiNE inayojihostia hubandika kila moja ya tag zake nne za image badala yake. Kubandika tag pia hubadilisha upgrade kuwa uhariri wa makusudi wa tag, ukifuatiwa na pull na recreate hiyo hiyo. Kwenye stack inayohamisha database inapowashwa, unapaswa kuwa na dump kabla ya kutekeleza amri yoyote kati ya hizo mbili. Hiyo ndiyo utaratibu unaofuatwa na desk ya usaidizi ya Chatwoot inayojihostia kwa kila ongezeko la version.

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

Seeing what is running

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 lists running containers only. A service that crashed during start is invisible there until you add -a, so a container missing from ps while ps -a shows it as Exited (1) is the normal shape of a startup failure. Read the exit code, then read the logs.

logs -f follows every service at once and prefixes each line with the service name, which is the view you want when services talk to each other and the order of events matters. Name a service to narrow it. --tail=100 matters on a container that has been up for a month, because the default prints the entire history and floods the terminal. --since 15m answers the question you usually have, which is what happened during the restart you just did.

top lists the processes inside each container, which separates "the container is running" from "the process inside it is running". ls steps outside the current directory and lists every Compose project on the host with its status, so you can find the stack you started three months ago.

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 wakati huduma haikai muda mrefu wa kutosha ili kuingia ndani kwa kutumia exec. Daima unganisha run na --rm, kwa sababu bila hiyo kila uendeshaji huacha container iliyosimamishwa nyuma, na hizo hujilimbikiza hadi docker compose ps -a inakuwa haiwezi kusomeka.

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

run --rm web env ndiyo njia ya haraka zaidi ya kuona mazingira (environment) ambayo huduma imepata kweli, baada ya kila faili ya .env, block ya environment: na variable ya shell kuunganishwa. Thamani inapokuwa si sahihi, mpangilio wa uunganishaji (merge order) mara nyingi ndiyo sababu, 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 service kwenye network moja ya project, na jina la kila service huwa DNS name kwenye network hiyo. Kuendesha getent hosts db ndani ya web huonyesha container IP wakati resolution inafanya kazi, na hakuonyeshi chochote wakati haifanyi kazi. Kwa hiyo, inajibu swali “je, hizi containers zinaweza kuwasiliana?” ndani ya sekunde mbili. Jina likipatikana lakini connection ikakataliwa, 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. Boundary hiyo hiyo inaeleza kwa nini container iliyoanzishwa nje ya project, iwe kwa docker run au kama stack yake, haiwezi kabisa kutatua jina kama jellyfin. Hili ndilo jambo la kwanza kuangalia wakati front end ya Halcyon ya library yako ya Jellyfin haiwezi kufikia server iliyoelekezwa. Maelezo mengine ya muundo huo yako katika jinsi Compose networks na service DNS zinavyofanya 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 huimiliki yenyewe, na sheria hiyo hukaa mbele ya sheria zako, kwa hivyo huduma uliyodhani ni ya faragha inaweza kuwa wazi kwa Internet. Kisa hicho kimefafanuliwa kwenye kwa nini port za Docker zilizochapishwa hupita ufw. Kuacha port hizo bila kuchapishwa na kuweka proxy moja ya uthibitishaji kwenye mtandao wa mradi mbele ya huduma hizo badala yake ndiyo njia salama zaidi, ambayo ndiyo kuendesha Authentik kama safu ya single sign-on inakupa.

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 zilizotajwa ambazo mradi unatangaza, moja kwa kila mstari. Orodha hiyo ndiyo unayopaswa kuhifadhi (backup). Wakati volumes zikiwa na kitu kisichoweza kubadilishwa, amri sahihi ya backup ni muhimu kama orodha yenyewe, ndiyo maana ulinganisho wa PhotoPrism na Immich unaelezea amri za dump na copy ambazo kila seva ya picha inahitaji. cp hunakili faili ndani au nje ya container bila kufungua shell, kwa kutumia muundo wa service:path upande wowote ulio container.

down -v huondoa volumes hizo zilizotajwa pamoja na containers. Hii ndiyo amri sahihi ya kubomoa stack ya majaribio na ni amri mbaya kwa kitu chochote chenye data unayojali, kwa sababu hakuna uthibitisho na hakuna njia ya kutengua (undo). Bind mounts husalia baada ya amri hii, kwa sababu huishi kwenye filesystem ya host. Pengo hilo katika eneo la athari 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 zinazomilikiwa na mradi lakini hazionekani tena kwenye faili, jambo ambalo hutokea baada ya kubadili jina la huduma. Bila amri hii, container hizo huendelea kufanya kazi, zikiwa hazionekani kwa docker compose ps.

docker system df huonyesha mahali ambapo nafasi ya diski imetumika kabla ya kufuta chochote, ikigawanya picha (images), container, local volumes na build cache pamoja na kiasi kinachoweza kurejeshwa kwa kila moja. 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 bora zaidi ya kupata nafasi. 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 ndizo zinazofanya hivyo.

Kukagua faili kabla halijasababisha hitilafu

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

config --quiet hufanya uthibitishaji na haitoi ujumbe wowote likifanikiwa, kwa hivyo linapaswa kutumika katika hatua ya kabla ya deploy au kwenye git hook. config ya kawaida huchapisha faili lililounganishwa kikamilifu na kuingizwa data, ambayo ndiyo njia ya kuthibitisha kama variable imetatuliwa na kama faili la override limepangwa 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. Huchapisha kila hatua ambayo Compose ingechukua bila kubadilisha chochote, muda ambao ni vyema kuutumia kwa sekunde thelathini 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 na faili ndogo ya kubatilisha kwa ajili ya uzalishaji (production), ingawa sheria hutofautiana kwa orodha na ramani, kwa hivyo soma jinsi Compose inavyounganisha faili nyingi kabla ya kutatua hitilafu usiyotarajia.

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

FAQ

Ni nini kilichochukua nafasi ya docker-compose kwa kutumia kistari?

Compose V2, inayotumiwa kama docker compose kwa kutumia nafasi (space). Hii ni plugin iliyojumuishwa ndani ya Docker Engine, na zana ya Python ya V1 haisakinishwi tena na vifurushi vya sasa. Ikiwa umbizo la nafasi halitoi matokeo yoyote, sakinisha kifurushi cha docker-compose-plugin kwa ajili ya mfumo wako (distribution). Sasisha hati (scripts) za zamani ili zitumie umbizo la 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 wakati 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 image ID 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 iliyopita bila kutoa error yoyote.

Ni amri zipi za usafishaji zilizo 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 unapomaliza. Tumia exec badala yake wakati container tayari inafanya kazi, kwa sababu exec hujiunga na mchakato unaoendelea na kukuonyesha hali halisi ya huduma hiyo.