Docker Compose Cheat Sheet para sa mga Server

Ang mga Compose command na aktuwal mong ginagamit

May mahigit 40 subcommand ang Docker Compose. Sa pang-araw-araw na pag-manage ng server, humigit-kumulang isang dosena lang ang ginagamit. Pinangkat sa page na ito ang mga ito ayon sa ginagawa mo, may malinaw na dahilan para sa bawat isa, at may link sa mas detalyadong paliwanag kapag may nakatagong problema ang isang command.

Compose V2 ang ginagamit ng lahat dito: docker compose na may space, hindi ang lumang docker-compose script. Isang Go plugin ang V2 na nag-i-install kasama ng Docker Engine. Wala na ang V1 sa mga kasalukuyang package, kaya ang docker-compose: command not found sa bagong Ubuntu box noong July 2026 ay inaasahan at hindi indikasyon ng sira. Suriin ito gamit ang docker compose version. Kung walang output, i-install ang docker-compose-plugin package.

Ang bawat command sa ibaba ay dapat patakbuhin mula sa directory na naglalaman ng iyong compose.yaml, dahil kinukuha ng Compose ang project name mula sa directory na iyon at doon din hinahanap ang file. Kapag pinatakbo mo ang parehong command isang level pataas, hihinto ang Compose at maglalabas ng no configuration file provided: not found. Kung bago sa iyo ang file format, 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 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 ang gumagawa ng network, gumagawa ng containers, nagsisimula sa mga ito, at nagbabalik. Nagbabalik ito kapag nagawa na ang mga container, kaya madalas mabigo sa unang pagsubok ang deploy script na sinusundan ito ng curl probe. Hinihintay ng up -d --wait na mag-report ng healthy ang bawat service na may healthcheck, at nag-e-exit ito nang non-zero kung may service na hindi umabot sa status na iyon. Kasinghusay lamang ng check na nasa likod nito ang flag, kaya gumawa 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 at 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 pinakamalaking maling pagkaunawa sa Compose, at ipinaliliwanag sa buong pagkakaiba ng down at stop kung saan ito nagdudulot ng problema.

Hindi reload ang restart. Pinahihinto at sinisimulan nito ang parehong container gamit ang kasalukuyang configuration nito, 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: recreate, pull, o 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

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 nakalista sa file. Pagkatapos, nakikita ng up -d na hindi na tugma ang image ID ng service sa tumatakbong container nito at nire-recreate ito. Kapag nilaktawan ang pull, patuloy na tumatakbo ang up -d gamit ang latest noong nakaraang buwan nang walang error. Lumilitaw ang kabaligtarang panganib sa isang multi-service stack: kapag sabay-sabay na nag-pull ng latest para sa bawat service, maaaring masira ang app na gumagana pa sampung segundo lamang ang nakalipas. Dahil dito, sa halip ay pini-pin ng isang self-hosted na AFFiNE workspace ang bawat isa sa apat nitong image tag.

Nalalapat ang build sa mga service na nagdeklara ng seksyong build: sa halip na image:. Binubuo at sinisimulan ng up -d --build ang service sa isang hakbang, na siyang karaniwang workflow habang binabago mo ang code. Gamitin lamang ang --no-cache kapag malinaw na luma na ang naka-cache na layer, dahil nire-rebuild nito 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

Ang ps ay naglilista lamang ng mga container na kasalukuyang tumatakbo. Ang serbisyong nag-crash habang nagsisimula ay hindi makikita rito hangga't hindi mo idinadagdag ang -a. Kaya ang container na wala sa ps habang ipinapakita naman ng ps -a bilang Exited (1) ay karaniwang senyales ng startup failure. Basahin ang exit code, pagkatapos ay basahin ang logs.

Sinusundan ng logs -f ang lahat ng serbisyo nang sabay-sabay at nilalagyan ng service name ang simula ng bawat linya. Ito ang view na kailangan kapag nag-uusap ang mga serbisyo at mahalaga ang pagkakasunod-sunod ng mga event. Magbigay ng service name para paliitin ang output. Mahalaga ang --tail=100 sa container na isang buwan nang tumatakbo, dahil ini-print ng default ang buong history at napupuno ang terminal. Sinasagot ng --since 15m ang karaniwang tanong: ano ang nangyari sa restart na katatapos mo lamang gawin?

Inililista ng top ang mga process sa loob ng bawat container. Nakakatulong ito para maihiwalay ang “tumatakbo ang container” sa “tumatakbo ang process sa loob nito.” Lumalabas ang ls sa kasalukuyang directory at inililista 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.

Pagkuha ng shell sa loob ng 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

Ang exec ay nagpapatakbo ng command sa loob ng container na kasalukuyang tumatakbo. Ang run ay nagsisimula ng bagong container mula sa parehong service definition. Ito ang kailangan kapag hindi sapat ang tagal ng pagtakbo ng service para makapag-exec dito. Palaging ipares ang run sa --rm. Kung hindi, bawat invocation ay mag-iiwan ng stopped container, at maiipon ang mga ito hanggang sa hindi na mabasa ang docker compose ps -a.

Subukan muna ang sh bago ang bash. Walang bash ang mga Alpine-based image, kaya ang failure ay magiging exec: "bash": executable file not found in $PATH. Kapag idinagdag ang --no-deps sa run, hindi isasama ang dependencies ng service. Dahil dito, hindi magbo-boot ang buong database para lamang sa isang mabilis na config check.

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, kadalasan ay 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. Kaya nasasagot nito sa loob ng dalawang segundo ang tanong na “nakikita ba ng mga container ang isa’t isa?” Kung nari-resolve ang pangalan pero nire-refuse ang connection, naka-bind ang process sa loob ng db sa 127.0.0.1 at hindi sa 0.0.0.0. Dahil dito, hindi ito tumatanggap ng packet mula sa ibang container. Nasa kung paano gumagana ang Compose networks at service DNS ang iba pang detalye ng modelong ito.

Ipinapakita ng port web 80 ang host address at port kung saan naka-publish ang container port. Nakakatulong ito kapag galing sa variable ang mapping at ayaw mong manghula. Kapag nag-publish ka ng port, gumagawa rin ito ng firewall rule na awtomatikong mina-manage ng Docker. Nauuna ang rule na ito sa sarili mong rule. Kaya maaaring maging bukas sa internet ang service na inakala mong private. Saklaw ito ng kung bakit nilalampasan ng mga published Docker port ang ufw. Mas ligtas na huwag i-publish ang mga port na iyon. Sa halip, maglagay ng isang proxy na may authentication sa project network, sa harap ng mga service. Ito ang setup na ibinibigay ng pagpapatakbo ng Authentik bilang single sign-on layer.

Mga volume at data

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

config --volumes inililista ang mga named volume na dineklara ng project, tig-iisa sa bawat linya. Ang listahang iyon ang kailangan mong i-back up. Kapag may hindi mapapalitang data sa mga volume, kasinghalaga ng listahan ang eksaktong backup command. Kaya inilalahad sa paghahambing ng PhotoPrism at Immich ang dump at copy command na kailangan ng bawat photo server. Kinokopya ng cp ang file papasok o palabas ng container nang hindi nagbubukas ng shell. Ginagamit nito ang anyong service:path sa panig kung nasaan ang container.

Inaalis ng down -v ang mga named volume kasama ng mga container. Tamang command ito para tanggalin ang isang test stack, pero maling gamitin sa anumang may data na mahalaga sa iyo dahil walang confirmation at walang paraan para i-undo ito. Nananatili ang bind mount dahil nasa filesystem ng host ang mga ito. Dahil magkaiba ang lawak ng epekto ng mga ito, dapat planuhin nang mabuti ang pagpili sa pagitan ng bind mount at named volume.

Paglilinis na nagpapalaya 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 ang nagde-delete ng mga container na kabilang sa project pero hindi na lumalabas sa file. Ito mismo ang nangyayari kapag nag-rename ka ng 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 images, containers, local volumes, at build cache, kasama ang reclaimable figure para sa bawat isa. Tinatanggal ng image prune -a ang bawat image na wala nang tumutukoy na tag. Sa server na nakapag-pull ng ilang version ng malaking image, kadalasan ito ang may pinakamalaking epekto. Nililinis ng builder prune ang build cache, na tahimik na lumalaki sa anumang server na gumagawa ng sarili nitong images.

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

Sinusuri ang file bago ito makasira ng ibang bagay

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

Ang config --quiet ay nagva-validate at walang ipinapakitang output kapag matagumpay, kaya angkop itong gamitin sa pre-deploy step o git hook. Ang plain na config ay nagpi-print ng ganap na merged at interpolated na file. Ito ang paraan upang kumpirmahing 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 warning na 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. Ipi-print nito ang bawat action na gagawin ng Compose at wala itong babaguhin. 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 ino-override ng mga file na nasa hulihan ang mga naunang file key by key. Ito ang karaniwang paraan upang mapanatili ang isang base file na may maliit na production override. Magkakaiba ang mga panuntunan para sa lists at maps, kaya basahin ang kung paano pinagsasama ng Compose ang maraming file bago mag-debug ng hindi inaasahang resulta.

Sinisimulan ng --profile ang mga service na may katumbas na profile kasama ng mga service na walang profile. Dahil dito, hindi kasama ang debug tooling sa karaniwang up. Itinatakda ng -p ang project name, kaya maaaring magpatakbo nang magkatabi ng dalawang kopya ng iisang stack na may magkahiwalay na network at magkahiwalay na volume name. Ang pagbabalik ng stack pagkatapos ng reboot ay hindi command na ita-type mo. Isa itong unit na awtomatikong nagpapatakbo nito, gaya ng inilalarawan sa pagsisimula ng mga Compose stack sa boot.

FAQ

Ano ang pumalit sa docker-compose na may hyphen?

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 V1 Python tool. 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?

Itinitigil at sinisimulan muli ng restart ang kasalukuyang container gamit ang configuration kung saan ito ginawa, at hindi nito muling binabasa ang compose.yaml. Ang anumang pagbabago sa environment variables, ports, volumes, o image tag ay nangangailangan ng docker compose up -d, na naghahambing sa bawat service sa tumatakbo nitong container at muling gumagawa sa mga hindi tugma. 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 muling ginagawa ng up -d ang anumang service na hindi na tugma ang image ID sa container nito. Kapag up -d lamang ang pinatakbo, ginagamit nitong muli ang image na nasa disk na. Dahil dito, maaaring manatili ang stack na naka-pin sa latest sa build na ilang buwan na nang hindi nagpapakita ng anumang error.

Aling mga cleanup command ang ligtas sa live 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 nagbubura ng named volumes nang walang prompt. Patakbuhin muna ang docker compose config --volumes upang malaman 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 dependencies nito, at inaalis ang container kapag nag-exit ka. Gamitin naman ang exec kapag tumatakbo na ang container, dahil kumokonekta ang exec sa live process at ipinapakita ang aktuwal na kalagayan ng service.