Misingi ya Docker Compose kwenye VPS yako

Unachojenga

Docker Compose ni msingi wa karibu kila kitu kingine kwenye tovuti hii. Nextcloud, Vaultwarden, n8n, Immich, Rocket.Chat; kila mwongozo huo huanza kwa kusema “andika compose file hii”, na ukurasa huu unaeleza maana halisi ya file hiyo. Utaweka Docker Engine na Compose plugin kutoka kwenye apt repository rasmi ya Docker kwenye Ubuntu 24.04. Kisha utaanzisha stack halisi yenye huduma mbili: Miniflux, msomaji mdogo wa RSS, pamoja na PostgreSQL. Jozi hii inatumia kila muundo unaotumiwa na programu kubwa zaidi: images zilizowekewa matoleo maalum, database yenye healthcheck, volume iliyopewa jina, secrets kwenye file ya .env, na port iliyochapishwa kwa localhost pekee.

Usakinishaji huchukua dakika tano. Sehemu iliyobaki ya mwongozo huu inashughulikia mambo yanayoweza kusababisha matatizo baadaye: docker group kuwa root kwa jina jingine, ports zilizochapishwa kupita moja kwa moja bila kuzingatia sheria zako za ufw, na flag moja kwenye docker compose down inayofuta database yako bila kukuuliza uthibitishe.

Masharti ya awali: KVM VPS mpya yenye Ubuntu 24.04, mtumiaji mwenye sudo, na RAM ya gigabyte moja au zaidi. Ikiwa tayari una Docker iliyosakinishwa, hilo pia ni sawa; sehemu ya kwanza inaeleza unachopaswa kuondoa.

Sakinisha kutoka kwenye repo ya Docker, si ya Ubuntu

Kuna makosa mawili ya kuepuka kabla ya kutekeleza amri ya kwanza. Kifurushi cha docker.io cha Ubuntu kinafanya kazi, lakini kinachelewa kulingana na releases za Docker na kinakosa mpangilio wa plugin ambao programu nyingine zote huutegemea. Na amri ya docker-compose yenye hyphen ndiyo njia ambayo mafunzo ya zamani hukuongoza. Kwenye seva ya zamani, amri hiyo kwa kawaida ni Compose v1, iliyoandikwa kwa Python, ambayo Docker imetangaza kuwa imefikia mwisho wa maisha yake (end of life), na ndiyo sababu mafunzo hayo hayafanyi kazi. Docker bado inachapisha binary ya docker-compose inayojitegemea iliyojengwa kwa msimbo wa Go wa sasa, lakini ukurasa wake wa usakinishaji unasema njia hiyo haipendekezwi na inatumika tu kwa ajili ya backward compatibility. Compose ya sasa ni docker compose yenye nafasi (space), ni CLI plugin, inayosakinishwa kutoka kwenye repository ileile ya engine.

Ikiwa yoyote kati ya hayo yapo kwenye seva, yaondoe kwanza, ikiwemo docker-compose-v2 na docker-buildx, ambazo ni vifurushi vya Ubuntu vya plugin hizo, ili kila kitu kitoke kwenye repository moja:

sudo apt remove -y docker.io docker-compose docker-compose-v2 docker-doc docker-buildx podman-docker containerd runc

Package 'docker.io' is not installed, so not removed ndiyo matokeo ya kawaida kwenye VPS mpya. Kisha ongeza repository ya Docker na usakinishe:

sudo apt update
sudo apt install -y ca-certificates curl
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc
echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
sudo apt update
sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

Thibitisha tabaka zote tatu:

docker --version
docker compose version
sudo docker run --rm hello-world

Tabaka mbili za kwanza huchapisha version strings, Docker Compose version v5.x.x inathibitisha kuwa una plugin, si binary ya v1 iliyopitwa na wakati. Plugin hiyo iliruka kutoka v2 moja kwa moja hadi v5 mnamo Desemba 2025, ikiruka 3 na 4 ili kuepuka mkanganyiko na version za zamani za muundo wa faili za compose, kwa hivyo miongozo inayoonyesha v2.x.x hapa inafafanua zana ileile. Utekelezaji wa hello-world unapaswa kuishia na Hello from Docker!. Kifurushi hiki huwezesha huduma wakati wa boot; systemctl is-enabled docker huchapisha enabled.

Kundi la docker ni root, amua kwa tahadhari

Hivi sasa kila amri ya docker inahitaji sudo, kwa sababu socket ya daemon iliyopo /var/run/docker.sock inamilikiwa na root pamoja na kundi la docker. Bila kuwa mwanachama wa kundi hili, utapata kosa la Docker linalotafutwa zaidi mtandaoni:

permission denied while trying to connect to the Docker daemon socket at
unix:///var/run/docker.sock

Suluhisho la kawaida:

sudo usermod -aG docker $USER

Uanachama wa kundi huanza kufanya kazi baada ya kuingia kwenye mfumo (login), kwa hivyo kosa litaendelea kuwepo kwenye shell yako ya sasa. Tekeleza newgrp docker kwa ajili ya kikao hiki, au ondoka (log out) na uingie tena; id inapaswa kuonyesha docker kwenye makundi yako.

Sasa sehemu ya ukweli, iliyoelezwa wazi: kuwa mwanachama wa kundi la docker ni sawa na kuwa root kwenye seva. Sio "kama root", sio "mamlaka yaliyoongezwa", ni root kamili. Mtu yeyote aliye kwenye kundi hilo anaweza kutekeleza docker run --rm -it -v /:/host alpine chroot /host na kumiliki mfumo mzima wa faili, bila kuulizwa nenosiri. Kundi hili lipo kwa ajili ya urahisi, si kwa ajili ya usalama.

Hali ya rootless ya Docker ndiyo njia mbadala ya kweli, ambapo daemon yenyewe huendeshwa kama mtumiaji wa kawaida asiye na upendeleo. Gharama zake ni: bandari (ports) zilizo chini ya 1024 zinahitaji usanidi wa ziada, mtandao hupitia shim ya userspace yenye mzigo wa ziada wa kiutendaji, na baadhi ya images hazifanyi kazi vizuri bila root halisi. Kwenye VPS yenye msimamizi mmoja ambapo mtumiaji pekee tayari ana sudo, mabadiliko ya kundi hayaleti tofauti yoyote kivitendo, na ndivyo kila mwongozo hapa unavyochukulia, lakini usiwahi kuligawa kundi hili kana kwamba lina mamlaka madogo kuliko sudo.

Muundo wa faili la compose

Weka kila stack katika directory yake, kwa sababu jina la directory huwa jina la project linalowekwa mwanzoni mwa majina ya containers, networks na volumes:

sudo mkdir -p /opt/miniflux && sudo chown $USER /opt/miniflux && cd /opt/miniflux

Unda compose.yml (hili ndilo jina la kisasa; docker-compose.yml bado linafanya kazi). Usitumie key ya zamani ya version:, kwa sababu imepitwa na wakati na Compose hutoa onyo ikiiona.

services:
  miniflux:
    image: miniflux/miniflux:2.2.9
    restart: unless-stopped
    ports:
      - "127.0.0.1:8080:8080"
    environment:
      - DATABASE_URL=postgres://miniflux:${POSTGRES_PASSWORD}@db/miniflux?sslmode=disable
      - RUN_MIGRATIONS=1
      - CREATE_ADMIN=1
      - ADMIN_USERNAME=admin
      - ADMIN_PASSWORD=${ADMIN_PASSWORD}
    depends_on:
      db:
        condition: service_healthy

  db:
    image: postgres:16-alpine
    restart: unless-stopped
    environment:
      - POSTGRES_USER=miniflux
      - POSTGRES_PASSWORD=${POSTGRES_PASSWORD}
      - POSTGRES_DB=miniflux
    volumes:
      - db-data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD", "pg_isready", "-U", "miniflux", "-d", "miniflux"]
      interval: 10s
      timeout: 5s
      retries: 5

volumes:
  db-data:

Kila mstari hapo juu ni uamuzi. Uuchunguze mmoja baada ya mwingine.

Funga matoleo ya image; :latest pamoja na pull ni upgrade isiyosimamiwa

postgres:16-alpine, si postgres:latest. Tag haijafungwa kwenye toleo maalum: :latest hutafuta tena tag hiyo na kupata kile maintainer alichosukuma hivi karibuni, kila unapofanya pull. Ukiunganisha hilo na utaratibu wa kawaida wa upgrade utakaojifunza, docker compose pull && docker compose up -d, basi :latest inamaanisha mabadiliko ya major version yanaingia wakati upstream inapoyatoa, si wakati unapochagua. Kwa PostgreSQL, hili si jambo la kinadharia: kuruka bila kutarajiwa kutoka 16 hadi 17 huacha container ikiingia kwenye crash loop kwa sababu directory ya data haiendani, kwa kuwa upgrade ya major version ya Postgres inahitaji dump na restore, si restart.

Funga angalau major version (postgres:16-alpine hufuata patch releases za 16.x), na funga applications kwenye release maalum kama miniflux/miniflux:2.2.9. Angalia ukurasa wa releases wa project na utumie toleo la sasa wakati unaandika faili. Upgrade itakuwa mabadiliko ya mstari mmoja unayoyafanya kwa makusudi, yanayoonekana katika git diff.

Publish kwenye 127.0.0.1, kwa sababu Docker hupita kando ya ufw

"127.0.0.1:8080:8080", host address, host port, container port. Tutorials nyingi huandika "8080:8080", ambayo ni kifupi cha 0.0.0.0:8080:8080: kusikiliza kwenye kila interface, ikiwemo interface ya umma.

Hapa ndipo mtego ulipo, na karibu kila mtu hukumbana nao angalau mara moja. Docker huchapisha port kwa kuandika DNAT rule inayobadilisha destination ya packet kuwa IP ya ndani ya container kabla ya filtering. Kwa hiyo packet hufuata njia ya FORWARD na haigusi INPUT, ambako rules zako za ufw zipo. sudo ufw deny 8080 huripoti mafanikio, ufw status huonyesha kwamba port imekataliwa, lakini service bado inajibu Internet nzima. Firewall yako haijaharibika; inapitiwa kimakusudi. Kwa nini Docker hupita kando ya ufw, na jinsi ya kuchuja traffic ya containers kwa njia halisi inaeleza utaratibu huo na DOCKER-USER fix ya ports zinazopaswa kubaki za umma.

Utaratibu unaoondoa tatizo lote ni huu: bind published ports kwenye 127.0.0.1 isipokuwa uwe na sababu maalum ya kutofanya hivyo, kisha weka reverse proxy mbele ya huduma yoyote inayopaswa kufikiwa na umma. Hilo ndilo linalojengwa na mwongozo wa Traefik reverse proxy kama hatua inayofuata baada ya ukurasa huu: container moja inayomiliki ports 80 na 443 na kuelekeza maombi kwa huduma nyingine kwa kutumia hostname, pamoja na TLS. (Unatoka kwenye setup ya zamani ya Traefik v2? Mwongozo wa kuhamia kutoka Traefik v2 kwenda v3 unaeleza majina mapya na mabadiliko ya rules.)

Thibitisha bind baada ya kuanzisha stack: sudo ss -tlnp | grep 8080 inapaswa kuonyesha 127.0.0.1:8080, si 0.0.0.0:8080 au *:8080.

Named volumes dhidi ya bind mounts

db-data:/var/lib/postgresql/data ni named volume: Docker huunda na kusimamia directory chini ya /var/lib/docker/volumes/ na kui-mount ndani ya container. Chaguo jingine ni bind mount, ./data:/var/lib/postgresql/data, inayounganisha path uliyochagua kwenye host.

Mgawanyo unaofanya kazi vizuri kwa vitendo ni huu: tumia named volumes kwa data inayoguswa na containers pekee, hasa databases, kwa sababu Docker huanzisha volume ikiwa na ownership inayotarajiwa na image na file permissions hufanya kazi moja kwa moja. Tumia bind mounts kwa files unazogusa kutoka host, kama config files unazohariri kwa text editor, media library unayoingiza kwa rsync, au kitu chochote ambacho unataka path yake ijulikane wazi. Tatizo la kawaida la bind mount ni ownership: image huendesha process yake kwa UID maalum (Miniflux image huendesha kwa UID 65534, postgres:16-alpine hushuka hadi UID 70), directory kwenye host yako inamilikiwa na UID 1000, na app hushindwa kuanza ikiwa na permission denied katika logs zake. Named volumes huondoa kwa kiasi kikubwa aina hii ya hitilafu, kwa gharama ya data kuhifadhiwa kwenye path inayosimamiwa na Docker, kama ilivyoelezwa hapa chini.

environment na .env, weka secrets nje ya git

Compose hujaza ${POSTGRES_PASSWORD} kutoka kwenye file lenye jina .env lililo karibu na compose.yml, lakini hufanya hivyo tu wakati shell yako haijaweka variable hiyo tayari: value iliyotangazwa kwenye shell environment yako hushinda value ya file la .env. Kwa hiyo, export POSTGRES_PASSWORD=... iliyosahaulika kutoka jaribio la awali inaweza kubadilisha file hilo bila kuonekana, na docker compose config (hapa chini) huonyesha ni value ipi iliyotumika. Unda file hilo:

cat > .env <<'EOF'
POSTGRES_PASSWORD=change-me-to-something-long
ADMIN_PASSWORD=change-me-too
EOF
chmod 600 .env
echo ".env" >> .gitignore

Tengeneza values halisi kwa openssl rand -hex 24. Tumia hex, si base64, kwa makusudi: password hii itawekwa ndani ya connection string ya DATABASE_URL, na characters za /, + na = zinazozalishwa na base64 huharibu URL parsing. Hitilafu hiyo hujitokeza kama authentication error, si syntax error, na inaweza kukupotezea jioni nzima. Mstari wa .gitignore huwekwa kabla ya commit ya kwanza: compose file ni salama kuchapisha na kuweka kwenye version control, lakini file la .env kamwe si salama kufanya hivyo. Secret iliyowahi kuingia kwenye historia ya git ni secret unayopaswa kuzungusha. Ukianzisha stack bila variable fulani, Compose hutoa onyo wazi na kuendelea ikiwa na empty string. Kwa password ya Postgres, hiyo husababisha deployment iliyoharibika:

WARN[0000] The "POSTGRES_PASSWORD" variable is not set. Defaulting to a blank string.

docker compose config huchapisha file baada ya interpolation kamili, na ndiyo njia ya haraka zaidi ya kukagua kile ambacho containers zitapokea; kumbuka kwamba output yake inajumuisha secrets zako.

depends_on haisubiri chochote isipokuwa uongeze healthcheck

depends_on: [db] ya kawaida hudhibiti mpangilio wa kuanza pekee: Compose huanzisha Postgres kwanza na app muda mfupi baadaye, wakati Postgres bado inahitaji sekunde kadhaa kabla ya kukubali connections. App hujaribu kuunganisha kwenye database, hushindwa, kisha huanguka au kujaribu tena kulingana na ubora wa implementation yake.

Njia ya kuaminika ndiyo inayotumiwa na file hapo juu: service ya db hufafanua healthcheck (Postgres husafirisha pg_isready kwa madhumuni hayo), na app hutangaza depends_on pamoja na condition: service_healthy. Compose huanzisha database, hukagua kila baada ya sekunde 10, na huanza Miniflux baada ya check kufaulu. Database ikiwa haijawahi kuwa healthy, kwa mfano kwa sababu ya password isiyo sahihi au volume iliyoharibika, app haianzi na Compose hukuambia ni dependency gani iliyoshindwa:

dependency failed to start: container miniflux-db-1 is unhealthy

Ujumbe huo unakuelekeza kwenye docker compose logs db, ambako error halisi ipo.

restart: unless-stopped

restart: unless-stopped kwenye services zote mbili inamaanisha containers zitarudi baada ya crash na baada ya reboot ya VPS, lakini zitabaki zikiwa zimezimwa ikiwa uliendesha docker compose stop kwa makusudi. Chaguo jingine, always, hufufua containers hata baada ya kuzisimamisha mwenyewe, jambo ambalo si mara nyingi unalokusudia. Bila restart policy, reboot inayotokana na kernel update saa 4 asubuhi inaweza kuzima services zako kimya kimya hadi utakapogundua.

Vitenzi vya kila siku

Kila kitu cha kila siku kinahusu amri tano, zinazoendeshwa kutoka kwenye saraka ya mradi.

docker compose up -d        # create and start; idempotent, recreates only what changed
docker compose ps           # status, ports, and health of this project's containers
docker compose logs -f miniflux   # follow one service's logs; --tail 100 for recent history
docker compose pull && docker compose up -d   # upgrade to the pinned tags
docker compose down         # stop and remove containers and the network

up -d ni salama kuendeshwa mara kwa mara, inalinganisha faili na hali halisi na kugusa tu huduma ambazo usanidi au image yake imebadilika. Jozi ya upgrade inapakua chochote ambacho tags zako zilizofungwa (pinned tags) zinaelekeza sasa: matoleo ya patch chini ya postgres:16-alpine, hakuna kitakachotokea kwa pin kamili hadi uihariri, ambayo ndiyo lengo. Images za zamani hujikusanya baada ya upgrades; rudisha nafasi ya diski kwa docker image prune -f.

Sasa ile ya uharibifu, iliyotajwa kwa msisitizo: docker compose down ni salama, containers na mtandao ni vitu vinavyoweza kutupwa, na data yako iko kwenye volume. docker compose down -v inafuta volumes zilizopewa majina pia. Hiyo ndiyo database yako, imepotea, papo hapo, bila ujumbe wa kuthibitisha na bila uwezekano wa kutendua. Flag ya -v ipo kwa ajili ya kubomoa majaribio; kwenye stack inayoshikilia data halisi, itendee kama unavyoitendea rm -rf. Hakuna pipa la takataka chini ya /var/lib/docker/volumes/.

Kwa shell ya mara moja ndani ya container inayofanya kazi: docker compose exec db psql -U miniflux inakuingiza kwenye database, na docker compose exec miniflux sh inakupa shell ndani ya app.

Mahali data yako ilipo kihalisi

Named volumes hupata prefix ya mradi, kwa hivyo db-data katika saraka inayoitwa miniflux inakuwa miniflux_db-data:

docker volume ls
docker volume inspect miniflux_db-data

Toleo la inspect linajumuisha mstari muhimu:

"Mountpoint": "/var/lib/docker/volumes/miniflux_db-data/_data"

Saraka hiyo ndiyo hifadhidata, inayomilikiwa na root, kwenye mfumo wa faili wa seva pangishi (host), na hudumu baada ya down, maboresho, na ujenzi upya wa container. Pia ndiyo hasa inayopaswa kunaswa na backups zako.

Kuhifadhi nakala ya volume iliyopewa jina

Mbinu ya kawaida ni kutumia container ya muda inayopachika (mount) volume hiyo kwa hali ya kusoma pekee (read-only) kando ya saraka ya mwenyeji (host directory), kisha kutumia tar kuhamisha data:

docker run --rm \
  -v miniflux_db-data:/data:ro \
  -v "$PWD":/backup \
  alpine:3.22 tar czf /backup/miniflux-db-$(date +%F).tar.gz -C /data .

Hakuna haja ya kusakinisha chochote, hakuna kinachobaki kikiwa kinafanya kazi, na urejeshaji wa data ni kinyume chake, kwa kutumia tar xzf kwenye volume mpya tupu huku mapachiko (mounts) yakiwa yamebadilishwa.

Tahadhari moja kwa database: kutumia tar kwenye saraka ya data ya Postgres inayofanya kazi kunaweza kunasa hali ya katikati ya uandishi ambayo haitawaka vizuri. Aidha tumia docker compose stop kwa sekunde ambazo tar inachukua, au bora zaidi, fanya logical dump, ambayo huwa thabiti kwa asili yake:

docker compose exec -T db pg_dump -U miniflux miniflux | gzip > miniflux-$(date +%F).sql.gz

Amri ya -T huzima pseudo-terminal ambayo Compose hutenga kwa chaguo-msingi, kwani kupitisha matokeo ya dump kupitia TTY kunaweza kuharibu data. Weka mojawapo ya amri hizi kwenye cron na unakili matokeo nje ya VPS; nakala ya chelezo iliyo kwenye diski moja na data inayolindwa ni nakala tu, si chelezo. Mwongozo wa Nextcloud hujenga utaratibu kamili uliopangwa kulingana na mbinu hizi mbili.

Aina za kushindwa, pamoja na mifuatano utakayoiona

permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock, bado hujaongezwa kwenye group la docker, au umeongezwa lakini session hii ilianza kabla ya mabadiliko hayo. id huonyesha groups zako zinazotumika; newgrp docker hutumika kwa shell ya sasa, huku kutoka na kuingia tena kukitumia mabadiliko hayo yote.

Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?, hili ni tatizo tofauti: daemon yenyewe haifanyi kazi. sudo systemctl status docker na sudo journalctl -u docker -n 50 huonyesha sababu. Kwenye VPS, sababu ya kawaida ni disk kujaa; anza kwa df -h /var/lib/docker.

Bind for 127.0.0.1:8080 failed: port is already allocated, container nyingine tayari imechapisha host port hiyo. docker ps huonyesha ni ipi; mara nyingi chanzo ni container ya zamani kutoka kwenye docker run ya majaribio ya wiki kadhaa zilizopita. Ikiwa docker ps haina matokeo, process isiyotumia Docker ndiyo inashikilia port: sudo ss -tlnp | grep 8080 huitaja.

yaml: line 14: did not find expected key, kuna kosa la indentation kwenye mstari uliotajwa au karibu juu yake. Compose files ni YAML: tumia indentation ya spaces mbili, spaces pekee, na tab character yoyote ni kosa lisilorekebishika. docker compose config huthibitisha file bila kuanzisha chochote, na kuiendesha baada ya kila mabadiliko ni desturi rahisi yenye gharama ndogo.

Mshangao wa ufw hautoi error yoyote, jambo linaloufanya uwe hatari: deploy inafanikiwa, ufw status inaonekana sawa, lakini port scan kutoka nje bado hupata database yako. Soma tena sehemu ya ports hapo juu, kagua kila ingizo la ports: ili kuona kama limekosa prefix ya 127.0.0.1:, na uthibitishe kutoka kwenye mashine tofauti kwa curl http://your-vps-ip:8080; jibu unalotaka ni connection refused.

Kuanzia hapa, mwongozo wa Traefik hubadilisha stack hii moja kuwa apps nyingi nyuma ya HTTPS entry point moja, na programu zinazofaa kuji-host mwaka 2026 ni orodha ya kuzipitia. Baada ya stacks kadhaa kuwaka na kila moja kuwa na login form yake, SSO server ya kuji-host kama Authentik huzirudisha kwenye account moja nyuma ya proxy hiyo hiyo.

Game server kama Minecraft server kwenye VPS ni Compose project nzuri ya kwanza kwa mazoezi. Ikiwa ungependa kujifunza kwa kitu unachofungua kila siku, openGym, workout tracker ya kuji-host ni stack ndogo iliyofungwa kwenye git tag badala ya image tag, na inahitaji TLS mbele yake kabla hujasajili passkey ya kwanza. Picha kwa kawaida ndicho kitu cha kwanza ambacho watu hutaka kukiondoa kwenye cloud ya mtu mwingine, na ulinganisho wa PhotoPrism na Immich huweka wazi kiwango cha chini cha RAM na utaratibu wa backup utakaochagua kabla ya kuhusisha volume na mojawapo. Huduma mbili zikianza kuonekana hazitoshi, kuanzisha AFFiNE kama workspace ya mtindo wa Notion hutumia mifumo hiyo hiyo kwenye containers nne, na ni jaribio zuri la kuona kama pinned tags, healthchecks na named volumes zilizo hapo juu zimekuwa desturi.

FAQ

Kwa nini napata "permission denied while trying to connect to the Docker daemon socket"?

Mtumiaji wako hayupo kwenye kundi la docker, au aliongezwa baada ya session ya sasa kuanza; uanachama huanza kufanya kazi tu baada ya kuingia (login). Tekeleza sudo usermod -aG docker $USER, kisha newgrp docker au toka (log out) na uingie tena, kisha thibitisha kwa id. Kundi hili hutoa uwezo sawa na root kwenye host, kwa hivyo ongeza tu watumiaji ambao ungewapa sudo.

Je, docker compose down inafuta data zangu?

docker compose down ya kawaida haifuti, inaondoa containers na mtandao wa mradi; named volumes hubaki na up -d inayofuata itaziunganisha tena. docker compose down -v ndiyo njia ya uharibifu: inafuta named volumes, kumaanisha database yako, bila uthibitisho na bila njia ya kurudisha (undo). Usitekeleze kamwe -v kwenye stack yenye data halisi isipokuwa kama una backup iliyothibitishwa.

Kuna tofauti gani kati ya docker-compose na docker compose?

docker-compose (hyphen) ni njia ya zamani ya kuita Compose. Kwenye seva za zamani kwa kawaida ni Compose v1, ile ya asili ya Python ambayo Docker imetangaza kuwa imefikia mwisho wa maisha yake. Docker bado inachapisha binary ya docker-compose inayojitegemea iliyojengwa kwa msimbo wa Go wa sasa, lakini inaweka lebo ya usakinishaji huo kuwa haipendekezwi na inatumika tu kwa ajili ya backward compatibility, kwa hivyo iache kwenye seva mpya. docker compose (nafasi) ndiyo Compose ya sasa, kuanzia v2 na kuendelea na kupewa namba v5 tangu Desemba 2025, ni Go plugin kwa ajili ya Docker CLI, inayosakinishwa kama docker-compose-plugin kutoka kwenye apt repository ya Docker. Amri na YAML zinaoana karibu kikamilifu, kwa hivyo wakati mafunzo ya zamani yanaposema docker-compose up, andika docker compose up.

Kwa nini naweza kufikia Docker container yangu kutoka kwenye Internet ingawa ufw inazuia port hiyo?

Kwa sababu Docker huchapisha ports kwa sheria za DNAT kwenye chain ya PREROUTING ya iptables, na pakiti zilizobadilishwa husafiri kupitia njia ya FORWARD kupitia chains za Docker yenyewe, hazigusi kamwe chain ya INPUT ambapo sheria za ufw hutumika. ufw deny 8080 kwa hivyo haifanyi chochote kwenye port ya container iliyochapishwa. Rekebisha kwenye chanzo: chapisha kwenye 127.0.0.1: na uweke huduma kupitia reverse proxy badala yake.

Je, nitumie named volume au bind mount?

Tumia named volumes kwa data ambazo container pekee ndiyo inazigusa, hasa database, kwa sababu Docker huweka umiliki (ownership) ambao image inatarajia na ruhusa hufanya kazi bila shida. Tumia bind mounts kwa faili ambazo unazishughulikia pia kutoka kwenye host: configs unazohariri, media unazopakia, chochote ambacho unataka njia yake (path) iwe wazi. Ikiwa container inashindwa kuanza na permission denied kwenye bind mount, kutolingana kwa UID kati ya host na container ndilo jambo la kwanza la kuangalia.