Docker Compose cheat sheet para sa real servers

Mga Compose command na aktuwal mong ginagamit

Naglalabas ang Docker Compose ng mahigit apatnapung subcommand. Sa pang-araw-araw na gawain sa server, humigit-kumulang isang dosena lamang ang ginagamit. Pinangkat sa page na ito ang mga ito ayon sa trabahong ginagawa mo, may isang malinaw na dahilan para sa bawat isa, at may pagtukoy sa mas detalyadong paliwanag kapag may nakatagong problema ang isang command.

Lahat dito ay gumagamit ng Compose V2: docker compose na may space, hindi ang lumang docker-compose script. Ang V2 ay isang Go plugin na ini-install kasama ng Docker Engine, at wala na ang V1 sa mga kasalukuyang package. Kaya inaasahan ang docker-compose: command not found sa isang bagong Ubuntu box noong July 2026, at hindi ito nangangahulugang may sira. Tingnan gamit ang docker compose version. Kung walang ilabas ang command na iyon, i-install ang docker-compose-plugin package.

Ang bawat command sa ibaba ay pinapatakbo mula sa directory na naglalaman ng iyong compose.yaml, dahil kinukuha ng Compose ang project name mula sa directory na iyon at hinahanap ang file batay sa lokasyon nito. Kung patakbuhin mo ang parehong command isang level pataas, hihinto ang Compose at ilalabas ang no configuration file provided: not found. Kung bago sa iyo ang file format mismo, magsimula sa unang Compose file sa isang VPS at bumalik dito para sa mga command.

Lifecycle: ang apat na tina-type mo, at ang isa na nag-aalis ng mga container

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

Ginagawa ng up -d ang network, ginagawa ang mga container, sinisimulan ang mga ito, at nagbabalik. Nagbabalik ito sa sandaling nagawa na ang mga container. Dahil dito, madalas mabigo sa unang pagsubok ang deploy script na sinusundan ito ng curl probe. Hinaharangan ng up -d --wait ang pagpapatuloy hanggang mag-ulat na healthy ang bawat service na may healthcheck, at nag-e-exit ito na may non-zero status kung may service na hindi kailanman umabot sa estadong iyon. Kasinghusay lamang ng check na nasa likod nito ang flag, kaya sumulat muna ng healthcheck na mapagkakatiwalaan ng Compose bago ito gamitin sa automation.

Pinahihinto ng stop ang mga container at pinananatili ang mga ito. Kaya ibinabalik ng start ang parehong mga container kasama ang parehong writable layer. Pinahihinto ng down ang mga ito, pagkatapos ay inaalis ang mga container at ang project network. Mawawala ang anumang isinulat sa loob ng container at wala sa isang volume. Ito ang pinakamagastos na maling pagkaunawa sa Compose, at ipinaliliwanag ng kumpletong pagkakaiba ng down at stop kung saan ito nagdudulot ng problema.

Hindi reload ang restart. Pinahihinto at sinisimulan nitong muli ang parehong container gamit ang configuration na mayroon na ito. Kaya walang epekto ang binagong environment variable, bagong image tag, o binagong port mapping. Para mailapat ang pagbabago sa file, patakbuhin muli ang up -d. Inihahambing ng Compose ang bawat service sa tumatakbo nitong container at nire-recreate lamang ang mga container na nagbago ang configuration.

Paglalapat ng pagbabago: muling likhain, i-pull, o muling i-build

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

Walang ginagawa ang up -d kapag walang nagbago, kaya ligtas itong patakbuhin nang paulit-ulit. Ino-override ng --force-recreate ang paghahambing na ito at pinapalitan ang bawat container kahit magkapareho ang configuration, kaya ito ang pinakamabilis na paraan para i-clear ang kakaibang state sa loob ng container.

Dalawang command ang kailangan para mag-update ng image dahil magkaiba ang ginagawa ng mga ito. Dina-download ng pull ang kasalukuyang image para sa bawat tag na nakasaad sa file. Pagkatapos, nakikita ng up -d na hindi na tugma ang image ID ng service sa tumatakbo nitong container at muli itong ginagawa. Kapag nilaktawan ang pull, patuloy na tatakbo ang up -d gamit ang latest noong nakaraang buwan nang walang error.

Nalalapat ang build sa mga service na nagdedeklara ng seksyong build: sa halip na image:. Muling bina-build at sinisimulan ng up -d --build ang mga ito sa isang hakbang, na siyang karaniwang workflow habang binabago mo ang code. Gamitin lamang ang --no-cache kapag malinaw na luma ang isang naka-cache na layer, dahil muli nitong bina-build ang bawat layer mula sa simula.

Pagtingin sa mga tumatakbo

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 ay naglilista lamang ng mga tumatakbong container. Hindi makikita rito ang serbisyong nag-crash habang nagsisimula hanggang idagdag mo ang -a. Kaya ang container na wala sa ps habang ipinapakita naman ito ng ps -a bilang Exited (1) ay karaniwang senyales ng startup failure. Basahin ang exit code, pagkatapos ay basahin ang mga log.

Sinusubaybayan ng logs -f ang lahat ng serbisyo nang sabay-sabay at nilalagyan ng pangalan ng serbisyo ang simula ng bawat linya. Ito ang view na kailangan kapag nakikipag-ugnayan ang mga serbisyo sa isa't isa at mahalaga ang pagkakasunod-sunod ng mga event. Tukuyin ang pangalan ng serbisyo para paliitin ang output. Mahalaga ang --tail=100 sa container na isang buwan nang tumatakbo, dahil ipinapakita ng default ang buong history at napupuno ang terminal. Sinasagot ng --since 15m ang karaniwang tanong: ano ang nangyari sa restart na kakagawa mo lang?

Inililista ng top ang mga process sa loob ng bawat container. Nakakatulong ito upang maihiwalay ang "tumatakbo ang container" sa "tumatakbo ang process sa loob nito". Lumalabas ang ls sa kasalukuyang directory at inililista nito ang lahat ng Compose project sa host kasama ang status ng mga ito. Dahil dito, mahahanap mo ang stack na sinimulan mo tatlong buwan na ang nakalipas.

Pagbubukas ng shell sa loob ng isang 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 ay nagpapatakbo ng command sa loob ng container na kasalukuyang umaandar. run ay nagsisimula ng bagong container mula sa parehong service definition. Ito ang kailangan kapag hindi sapat ang tagal ng pagtakbo ng service para mapagpatakbuhan ito ng exec. Palaging ipares ang run sa --rm. Kung hindi, mag-iiwan ang bawat invocation ng tumigil na container, at maiipon ang mga ito hanggang sa hindi na mabasa ang docker compose ps -a.

Subukan ang sh bago ang bash. Walang bash ang mga image na batay sa Alpine, kaya ang lalabas na error ay exec: "bash": executable file not found in $PATH. Ang pagdaragdag ng --no-deps sa run ay lumalaktaw sa mga dependency ng service. Pinipigilan nito ang isang mabilis na pagsusuri ng config na i-boot ang buong database.

Ang run --rm web env ang pinakamabilis na paraan para makita ang aktuwal na environment na natanggap ng service, matapos pagsamahin ang bawat .env file, environment: block, at shell variable. Kapag mali ang isang value, karaniwang merge order ang dahilan. Ipinapaliwanag sa kung paano nireresolba ng Compose ang env files at secrets kung aling source ang mananaig.

Mga network, port, at name resolution

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

Inilalagay ng Compose ang bawat service sa iisang project network, at ang pangalan ng bawat service ay isang DNS name dito. Kapag pinatakbo ang getent hosts db sa loob ng web, ipinapakita nito ang container IP kapag gumagana ang resolution at walang ipinapakita kapag hindi ito gumagana. Dahil dito, nasasagot nito sa loob ng dalawang segundo kung nakikita ng mga container ang isa't isa. Kung nareresolba ang name pero tinatanggihan ang connection, naka-bind ang process sa loob ng db sa 127.0.0.1 sa halip na sa 0.0.0.0. Kaya hindi ito tumatanggap ng packet mula sa ibang container. Makikita ang iba pang bahagi ng modelong ito sa kung paano gumagana ang Compose network at service DNS.

Ipinapakita ng port web 80 ang host address at port kung saan naka-publish ang container port. Nakakatulong ito kapag variable ang ginamit sa mapping, kaya hindi na kailangang manghula. Ang pag-publish ng port ay gumagawa rin ng firewall rule na awtomatikong pinamamahalaan ng Docker. Nauuna ang rule na iyon sa sarili mong rule. Kaya maaaring maging accessible sa internet ang service na inakala mong private. Tinalakay ang sitwasyong ito sa kung bakit nilalampasan ng mga Docker port na naka-publish ang ufw.

Mga volume at data

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

Ipinapakita ng config --volumes ang mga named volume na idineklara ng project, tig-iisa sa bawat linya. Ang listahang iyon ang kailangan mong i-back up. Kinokopya ng cp ang file papunta o palabas ng container nang hindi nagbubukas ng shell, gamit ang anyong service:path sa panig na container.

Inaalis ng down -v ang mga named volume kasama ng mga container. Ito ang tamang command para alisin ang isang test stack, ngunit maling gamitin sa anumang may data na mahalaga sa iyo dahil walang confirmation at walang undo. Hindi nito naaapektuhan ang bind mounts dahil nasa host filesystem ang mga ito. Dahil dito, mahalagang piliin nang maingat kung gagamit ng bind mounts o named volumes.

Paglilinis na naglalabas ng disk space nang hindi nawawala ang data

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

--remove-orphans ay nagde-delete ng mga container na kabilang sa project ngunit hindi na lumilitaw sa file. Ito mismo ang nangyayari kapag pinalitan ang pangalan ng isang service. Kung wala ito, patuloy na tatakbo ang mga container na iyon at hindi makikita sa docker compose ps.

Ipinapakita ng docker system df kung saan napunta ang disk space bago ka mag-delete ng anuman. Hinahati nito ang paggamit sa images, containers, local volumes, at build cache, kasama ang reclaimable na halaga para sa bawat isa. Inaalis ng image prune -a ang bawat image na walang tinuturong tag. Sa isang server na nakapag-pull ng ilang bersyon ng malaking image, kadalasan ito ang may pinakamalaking epekto. Nililinis ng builder prune ang build cache, na unti-unting lumalaki sa anumang server na gumagawa ng sarili nitong images.

Wala sa mga iyon ang nakaaapekto sa named volume. Tanging docker volume prune at docker compose down -v lamang ang gumagawa nito.

Sinusuri ang file bago ito magdulot ng problema

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

Nagsasagawa ng validation ang config --quiet at walang inilalabas kapag matagumpay, kaya dapat itong ilagay sa pre-deploy step o git hook. Inilalabas ng simpleng config ang ganap na pinagsama at na-interpolate na file. Sa ganitong paraan, makukumpirma mong na-resolve ang isang variable at na-layer ang override file ayon sa inaasahan mo. Lumilitaw doon ang isang unset na variable bilang walang laman na value, kasabay ng babalang The "X" variable is not set. Defaulting to a blank string.

Ang --dry-run ay isang global flag, hindi flag ng subcommand, kaya inilalagay ito bago ang up. Inililista nito ang bawat action na isasagawa ng Compose at wala itong binabago. Sulit ang tatlumpung segundo bago ang down sa isang mahalagang stack.

Paggawa sa maraming file, profile, at project

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

Pinagsasama ang maraming -f flag ayon sa pagkakasunod-sunod, at ina-override ng mga file na nasa hulihan ang mga naunang file, key bawat key. Ito ang karaniwang paraan para magkaroon ng isang base file at maliit na production override. Naiiba ang mga panuntunan para sa mga list at map. Basahin ang kung paano pinagsasama ng Compose ang maraming file bago siyasatin ang hindi inaasahang resulta.

Sinisimulan ng --profile ang mga service na may nakatalagang profile kasama ng mga service na walang profile. Dahil dito, hindi kasama ang mga debug tool sa karaniwang up. Itinatakda ng -p ang pangalan ng project. Dahil dito, maaaring sabay na tumakbo ang dalawang kopya ng isang stack gamit ang magkahiwalay na network at magkahiwalay na volume name. Para awtomatikong maibalik ang stack pagkatapos ng reboot, hindi command ang itina-type mo. Sa halip, isang unit ang awtomatikong nagpapatakbo nito. Inilalarawan ito sa pagsisimula ng mga Compose stack sa boot.

FAQ

Ano ang pumalit sa docker-compose na may hyphen?

Ang Compose V2, na tinatawag bilang docker compose na may space. Isa itong plugin na kasama sa Docker Engine, at hindi na ini-install ng mga kasalukuyang package ang Python tool na V1. Kung walang output ang anyong may space, i-install ang docker-compose-plugin package para sa iyong distribution. I-update ang mga lumang script upang gamitin ang anyong may space sa halip na magdagdag ng alias, dahil may mga flag ang V2 na wala sa V1.

Bakit hindi nakikita ng docker compose restart ang pagbabago ko sa config?

Hinihinto at sinisimulan muli ng restart ang kasalukuyang container gamit ang configuration kung saan ito nilikha, at hindi nito muling binabasa ang compose.yaml. Anumang pagbabago sa environment variables, ports, volumes o image tag ay nangangailangan ng docker compose up -d. Inihahambing nito ang bawat service sa tumatakbo nitong container at nililikha muli ang mga hindi magkatugma. Idagdag ang --force-recreate kung gusto mong mangyari ang pagpapalit kahit walang nagbago sa file.

Paano ko ia-update ang isang service sa mas bagong image?

Patakbuhin ang docker compose pull, pagkatapos ay ang docker compose up -d. Kinukuha ng pull ang kasalukuyang image para sa bawat tag sa file, at nililikha muli ng up -d ang anumang service na hindi na tugma ang image ID sa container nito. Kapag up -d lang ang pinatakbo, gagamitin muli nito ang image na nasa disk na. Dahil dito, maaaring manatili ang isang stack na naka-pin sa latest sa build na ilang buwan na, nang walang anumang error na ipinapakita.

Aling mga cleanup command ang ligtas sa aktibong server?

Ang docker system df, docker image prune -a at docker builder prune ay nag-aalis lamang ng images at cache, kaya patuloy na gumagana ang mga tumatakbong service at hindi naaapektuhan ang named volumes. Ang mapanganib na pares ay docker compose down -v at docker volume prune, na nagtatanggal ng named volumes nang walang prompt. Patakbuhin muna ang docker compose config --volumes upang malaman mo kung ano ang maaaring maapektuhan.

Maaari ba akong magpatakbo ng isang command nang hindi sinisimulan ang buong stack?

Oo. Sinisimulan ng docker compose run --rm --no-deps web sh ang isang container mula sa web service definition, nilalaktawan ang mga dependency nito, at inaalis ang container kapag lumabas ka. Gamitin naman ang exec kapag tumatakbo na ang container, dahil kumokonekta ang exec sa aktibong process at ipinapakita ang aktuwal na kalagayan ng service.