Docker Compose: Cheat Sheet ya Seva Halisi

Amri za Compose unazotumia mara kwa mara

Docker Compose ina amri ndogo nyingi. Kazi ya kila siku kwenye seva hutumia kama kumi na mbili hivi. Ukurasa huu unazipanga 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 au V5: docker compose yenye nafasi, si hati ya zamani ya docker-compose. Zote ni Go plugins; kwenye Linux, Compose plugin husakinishwa kando na Docker Engine. Ubuntu 24.04 LTS bado inatoa zana ya zamani ya Python V1 kama docker-compose toleo la 1.29.2-6ubuntu1 katika hazina yake ya universe. Hakiki kwa docker compose version. Ikiwa amri haipatikani, sanidi hazina ya Docker na usakinishe kifurushi cha docker-compose-plugin.

Kila amri hapa chini inaendeshwa kutoka kwenye saraka iliyo na compose.yaml yako; Compose hutumia jina la saraka hiyo kama jina la mradi wa msingi isipokuwa ulibadilishe. Bila -f au COMPOSE_FILE, Compose hutafuta faili ya usanidi katika saraka ya sasa na saraka mama zake, kwa hivyo kuendesha amri ukiwa ngazi moja juu kutapata stack yako ikiwa tu faili yake bado iko kwenye njia hiyo ya utafutaji. Ikiwa muundo wa faili yenyewe 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. Amri hii humaliza baada ya kuanzisha containers bila kusubiri programu kuwa tayari, ndiyo maana hati ya deploy inayofuatiwa na uchunguzi wa curl mara nyingi hushindwa kwenye jaribio la kwanza. up -d --wait husubiri huduma zenye healthchecks ziwe katika hali nzuri na huduma zisizo nazo ziwe zinafanya kazi; huduma isiyo katika hali nzuri au --wait-timeout iliyoisha muda wake husababisha exit code isiyo sifuri. 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, hivyo start huleta containers zilezile zikiwa na writable layer ileile. down husimamisha containers kisha kuzifuta pamoja na mtandao wa mradi. Kila kitu kilichoandikwa ndani ya container na nje ya volume hupotea pamoja nazo. Hilo ndilo kosa kubwa zaidi la kutoelewana katika Compose, na tofauti kamili kati ya down na stop inaelezea mahali ambapo kosa hili huleta madhara.

restart si amri ya reload. Husimamisha na kuanzisha container ileile kwa usanidi ilionao tayari, kwa hivyo variable ya mazingira iliyobadilishwa, image tag mpya 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 ambazo usanidi wake au image imebadilika.

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 hutumia tena container zinazoendelea kufanya kazi wakati configuration na image zake hazijabadilika; image pulls na builds hufuata sera ya pull ya huduma husika. --force-recreate hupuuza ulinganisho huo na kuchukua nafasi ya kila container hata kama configuration ni sawa, kwa hivyo ndiyo njia ya haraka zaidi ya kufuta hali isiyo ya kawaida ndani ya container.

Utaratibu wa wazi wa kusasisha image hutumia amri mbili kwa sababu hufanya mambo mawili 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 yake inayofanya kazi na kuiumba upya. Kwa sera chaguo-msingi ya pull ya missing, tag zilizohifadhiwa kwenye cache hutumiwa tena isipokuwa latest, ambayo hupakuliwa kila wakati. Hatari inayokinzana huonekana kwenye stack ya huduma nyingi, ambapo kufanya pull ya latest kwa kila huduma kwa wakati mmoja kunaweza kuvunja programu iliyokuwa ikifanya kazi sekunde kumi zilizopita, ndiyo maana a self-hosted AFFiNE workspace inapendekeza kufunga (pinning) image ya programu na ile ya migration kwenye digest moja. Kufunga image pia hubadilisha uboreshaji kuwa uhariri wa makusudi wa tag ikifuatiwa na pull na recreate hiyo hiyo, na kwenye stack inayofanya migration ya database yake inapoanza, unahitaji kuwa na dump mkononi kabla ya amri yoyote kati ya hizo, ambayo ndiyo utaratibu a self-hosted Chatwoot support desk unaofuata kwa kila ongezeko la toleo.

build inahusu huduma zinazotangaza sehemu ya build:, ikiwemo huduma zinazotangaza pia image:. up -d --build hujenga na kuanza katika hatua moja, ambayo ndiyo mzunguko wa kawaida wakati unabadilisha code. Tumia --no-cache pale tu ambapo layer iliyohifadhiwa kwenye cache inaonekana imepitwa na wakati, kwa sababu hujenga kila layer upya kutoka mwanzo. Baadhi ya miradi husafirisha njia zote mbili kutoka repo moja iliyokopiwa, na hapo mizunguko hiyo miwili huwa njia mbadala za kusasisha: a self-hosted openGym workout tracker hutumia docker compose up -d --build kujenga checkout yake iliyofungwa, kwa sababu kufanya pull ya image zake za latest kunaweza kuendesha toleo jipya zaidi kuliko checkout hiyo.

Kuangalia 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 ya kuanza (startup failure). Soma exit code, kisha soma logi.

logs -f hufuatilia kila huduma kwa wakati mmoja na kuweka jina la huduma mwanzoni mwa kila mstari, hii ndiyo hali unayohitaji wakati huduma zinawasiliana na mpangilio wa matukio ni muhimu. Taja jina la huduma ili kupunguza wigo. --tail=100 ni muhimu kwenye container iliyokuwa ikiendelea kwa mwezi mmoja, 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 inaendelea" na "process iliyo ndani yake inaendelea". ls hutoka nje ya saraka ya sasa na kuorodhesha miradi ya Compose inayoendelea kwenye host pamoja na hali zake; ongeza -a ili kujumuisha miradi iliyosimamishwa.

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 kufanya hivyo, kila uendeshaji huacha container iliyosimamishwa nyuma, na hizo hujilimbikiza hadi docker compose ps -a inakuwa haiwezi kusomeka.

Jaribu sh kabla ya bash. Baadhi ya images zinazotegemea Alpine zinajumuisha bash, ikiwemo image rasmi ya PostgreSQL Alpine; wakati haipo, hitilafu inayotokea inasomeka exec: "bash": executable file not found in $PATH. Kuongeza --no-deps kwenye run huruka dependencies za huduma, 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 kweli, baada ya kila faili ya .env, block ya environment: na variable ya shell kuunganishwa. Wakati thamani fulani si sahihi, mpangilio wa kuunganisha (merge order) ndiyo sababu ya kawaida, na jinsi Compose inavyotatua faili za env na secrets 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

Kwa chaguo-msingi, 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, wakati image inajumuisha getent, hukagua utatuzi wa majina; haijaribu kama db inakubali miunganisho. Ikiwa jina linatatuliwa lakini muunganisho unakataliwa, hakikisha seva inafanya kazi na inasikiliza kwenye anwani na port iliyoombwa; kufunga (bind) kwenye 127.0.0.1 pekee ni sababu moja inayowezekana. Mpaka huo huo unaelezea kwa nini container iliyoanzishwa nje ya mradi, iwe kwa docker run au kama stack yake yenyewe, inahitaji mtandao wa pamoja ili kutatua jina la huduma kama jellyfin, jambo ambalo ni la kwanza kukagua wakati front end ya Halcyon kwa ajili ya maktaba yako ya Jellyfin haiwezi kufikia seva inayoelekezwa. Sehemu nyingine ya mfano huo iko kwenye 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 linalookoa kubahatisha wakati mapping inatoka kwenye variable. Kuchapisha port pia huandika sheria ya firewall ambayo Docker huimiliki yenyewe, na sheria hiyo hukaa mbele ya zako, kwa hivyo huduma uliyodhani ni ya faragha inaweza kuwa wazi kwa mtandao wa 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 huchapisha volumes zenye majina ambazo mradi hutangaza, moja kwa kila mstari. Orodha hiyo ni sehemu tu ya orodha ya backup: bind mounts na faili za configuration pia zinahitaji kukaguliwa. Wakati volumes zikihifadhi kitu kisichoweza kubadilishwa, amri kamili ya backup ni muhimu kama orodha yenyewe, ndiyo maana ulinganisho wa PhotoPrism na Immich unafafanua 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 zenye majina zilizotangazwa isipokuwa zile za nje, pamoja na anonymous volumes zilizounganishwa kwenye containers, pamoja na containers zenyewe. 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 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 kontena zinazomilikiwa na mradi lakini hazionekani tena kwenye faili, jambo ambalo hutokea baada ya kubadili jina la huduma. Bila amri hii, kontena hizo huendelea kufanya kazi, na docker compose ps hujumuisha kontena yatima zinazoendelea kufanya kazi kwa chaguo-msingi.

docker system df huonyesha mahali ambapo nafasi ya diski imetumika kabla ya kufuta chochote, ikigawanya picha (images), kontena, volumu za ndani (local volumes) na akiba ya ujenzi (build cache) huku ikionyesha kiasi kinachoweza kurejeshwa kwa kila moja. image prune -a huondoa kila picha ambayo haitumiwi na kontena yoyote, iwe imetambulishwa (tagged) au la, na kwenye seva iliyopakua matoleo kadhaa ya picha kubwa, hii mara nyingi ndiyo njia bora zaidi ya kupata nafasi. builder prune huondoa akiba ya ujenzi iliyoachwa bila kazi kwa chaguo-msingi; ongeza -a ili kuondoa akiba yote ya ujenzi ambayo haitumiki.

Hakuna amri kati ya hizo inayogusa volumu zenye majina (named volumes). docker volume prune --all, docker compose down -v na docker volume rm huondoa volumu zenye majina. docker volume prune pekee huondoa volumu zisizo na majina (anonymous volumes) pekee.

Kukagua faili kabla halijasababisha tatizo

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

config --quiet huthibitisha faili na haitoi chochote ikiwa imefanikiwa, kwa hiyo inafaa kutumika katika hatua ya kabla ya deployment au git hook. config ya kawaida huchapisha faili iliyounganishwa na kuingiza thamani zote, jambo linalokuwezesha kuthibitisha kuwa variable imetatuliwa na override file imepangwa kama ulivyotarajia. Variable ambayo haijawekwa huonekana hapo ikiwa na thamani tupu, pamoja na onyo The "X" variable is not set. Defaulting to a blank string.

--dry-run ni flag ya kimataifa, si flag ya subcommand, kwa hiyo huwekwa kabla ya up. Huchapisha kila hatua ambayo Compose ingechukua na haibadilishi chochote. Hivyo, inafaa kutumia sekunde thelathini kabla ya 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 (override) kwa ajili ya uzalishaji, ingawa sheria hutofautiana kwa orodha (lists) na ramani (maps), kwa hivyo soma jinsi Compose inavyounganisha faili nyingi kabla ya kutatua hitilafu usiyoitarajia.

--profile huanzisha huduma zilizowekewa alama ya profaili hiyo pamoja na zile zisizo na alama, jambo linalosaidia kuweka zana za utatuzi (debug tooling) nje ya up ya kawaida. -p huweka jina la mradi, ili nakala mbili za stack moja ziweze kuendeshwa sambamba na mitandao tofauti na majina tofauti ya volume. Kurejesha stack baada ya reboot hutumia sera ya kuanzisha upya (restart policy) au unit inayokuendeshea Compose, iliyoelezwa katika kuanzisha stack za Compose wakati wa boot.

FAQ

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

Compose V2 na V5, zinazoitwa kama docker compose kwa kutumia nafasi (space). Kwenye Linux, Compose ni plugin inayosanikishwa kando; Ubuntu 24.04 LTS bado inatoa zana ya Python ya V1 katika hazina yake ya universe. Ikiwa muundo wa nafasi haupatikani, sanidi hazina ya Docker na usakinishe kifurushi cha docker-compose-plugin. Sasisha hati za zamani ili zitumie muundo wa nafasi badala ya kuongeza alias, kwa sababu V2 ina flag 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 unataka 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 hufuata sera ya pull: sera chaguo-msingi ya missing hutumia tena images zilizohifadhiwa kwenye cache isipokuwa kwa latest, ambayo huchotwa kila wakati.

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

docker system df huripoti matumizi ya diski bila kufuta chochote; docker image prune -a na docker builder prune hufuta images zisizotumika na cache ya build, kwa hivyo huduma zinazoendelea kufanya kazi hazitaathirika na named volumes hazitaguswa. Jozi hatari ni docker compose down -v, ambayo hufuta named volumes za mradi zilizotangazwa kama zisizo za nje (non-external) na anonymous volumes zilizounganishwa bila kuuliza, na docker volume prune --all, ambayo hufuta local volumes zisizotumika, ikiwemo zile zenye majina, baada ya kuuliza y/N mara moja, au bila kuuliza kabisa ukitumia -f. 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 hutekeleza amri yako ndani ya container iliyo hai na kukuonyesha hali halisi ya huduma hiyo.