Jinsi ya kutumia Docker Compose kwenye Ubuntu 24.04

Unachojenga

Docker Compose ndiyo msingi wa karibu kila kitu kwenye tovuti hii. Nextcloud, Vaultwarden, n8n, Immich, Rocket.Chat, kila mwongozo kati ya hiyo huanza na "andika faili hili la compose", na hii ndiyo ukurasa unaoelezea maana halisi ya faili hilo. Utaweka Docker Engine na plugin ya Compose v2 kutoka kwenye apt repository ya Docker yenyewe kwenye Ubuntu 24.04, kisha utaanzisha stack halisi ya huduma mbili, Miniflux, kisoma RSS kidogo, pamoja na PostgreSQL, kwa sababu jozi hiyo hutumia kila muundo unaotumiwa na programu kubwa: images zilizofungwa (pinned), database yenye healthcheck, named volume, siri (secrets) kwenye faili la .env, na port iliyochapishwa kwa localhost pekee.

Ufungaji huchukua dakika tano. Sehemu iliyobaki ya mwongozo huu inashughulikia sehemu zinazosababisha matatizo baadaye: kundi la docker kuwa root kwa jina lingine, ports zilizochapishwa kupita moja kwa moja kwenye sheria zako za ufw, na flag moja kwenye docker compose down inayofuta database yako bila kuuliza uthibitisho.

Mahitaji: VPS ya Ubuntu 24.04 KVM mpya, mtumiaji mwenye sudo, na gigabyte moja ya RAM au zaidi. Ufungaji wa Docker uliopo tayari pia unafaa, sehemu ya kwanza inashughulikia kile cha kuondoa.

Sakinisha kutoka kwenye repo ya Docker, siyo ya Ubuntu

Kuna makosa mawili ya kuepuka kabla ya kutekeleza amri ya kwanza. Kifurushi cha docker.io cha Ubuntu kinafanya kazi, lakini kinachelewa kutoa releases za Docker na kinakosa mpangilio wa plugin ambao programu nyingine zote huutegemea. Vilevile, binary ya pekee ya docker-compose, ile yenye kistari, ni Compose v1: iliyoandikwa kwa Python, imefikia mwisho wa maisha yake tangu 2023, na ndiyo sababu mafunzo ya zamani hayafanyi kazi. Compose ya sasa ni docker compose yenye nafasi, ambayo ni CLI plugin, inayosakinishwa kutoka kwenye repository moja na engine.

Ikiwa mojawapo ya hayo tayari yapo kwenye seva, yaondoe kwanza, ikijumuisha docker-compose-v2, kifurushi cha Ubuntu cha plugin hiyo, ili kila kitu kitoke kwenye repository moja:

sudo apt remove -y docker.io docker-compose docker-compose-v2 docker-doc 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 matabaka yote matatu:

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

Amri mbili za kwanza huchapisha kamba za toleo, Docker Compose version v2.x.x inathibitisha kuwa unayo plugin, siyo ile binary ya v1 iliyokufa. Uendeshaji wa hello-world unapaswa kumalizika kwa Hello from Docker!. Kifurushi hiki huwezesha huduma kuwaka 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.

Anatomy ya faili ya compose

Ipe kila stack saraka yake binafsi; jina la saraka huwa jina la mradi, ambalo huongeza kiambishi awali kwenye containers, networks, na volumes:

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

Unda compose.yml (jina la kisasa; docker-compose.yml bado inafanya kazi). Achana na ufunguo wa zamani wa version:, umepitwa na wakati na Compose hutoa onyo ikiona mmoja.

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. Yachukue moja baada ya lingine.

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

Tumia postgres:16-alpine, si postgres:latest. Tag si kitu kilichoganda: :latest hurejelea upya chochote ambacho maintainer amekipush hivi karibuni, kila unapofanya pull. Ukichanganya hilo na mazoea ya kufanya upgrade ya kawaida unayokaribia kujifunza, docker compose pull && docker compose up -d, basi :latest inamaanisha kuwa mabadiliko ya major-version huingia wakati wowote upstream inapoyatoa, si wakati unapoamua wewe. Kwa PostgreSQL hili si dhana tu: kuruka ghafla kutoka 16 kwenda 17 kutafanya container iwe kwenye crash-loop kwa sababu ya data directory isiyooana, kwa kuwa upgrades za major za Postgres zinahitaji dump na restore, si restart.

Funga angalau toleo la major (postgres:16-alpine hufuata matoleo ya patch ya 16.x), na funga programu kwenye release kamili kama miniflux/miniflux:2.2.9; angalia ukurasa wa releases wa mradi na utumie chochote kilicho cha sasa unapoandika faili. Upgrade kisha inakuwa ni mabadiliko ya mstari mmoja uliyofanya kwa makusudi, yanayoonekana kwenye git diff.

Chapisha kwenye 127.0.0.1, kwa sababu Docker hupita pembeni ya ufw

"127.0.0.1:8080:8080", anwani ya host, port ya host, port ya container. Mafunzo mengi huandika "8080:8080", ambayo ni ufupisho wa 0.0.0.0:8080:8080: kusikiliza kwenye kila interface, ikiwemo ile ya umma.

Hapa ndipo mtego ulipo, na karibu kila mtu hukutana nao mara moja. Docker huchapisha port kwa kuandika sheria ya DNAT inayobadilisha destination ya pakiti kwenda kwenye IP ya ndani ya container kabla ya kuchujwa, kwa hivyo pakiti hupita kwenye njia ya FORWARD na haigusi kamwe INPUT, ambapo sheria zako za ufw zipo. sudo ufw deny 8080 huripoti mafanikio, ufw status huonyesha port imekataliwa, na huduma bado hujibu mtandao mzima. Firewall yako haijaharibika; inapitwa pembeni kwa makusudi ya usanifu. Kwa nini Docker hupita pembeni ya ufw, na jinsi ya kuchuja trafiki ya container kwa uhalisi hufafanua utaratibu huu na suluhisho la DOCKER-USER kwa ports ambazo lazima zibaki za umma.

Mazoea yanayofanya tatizo lote kutoweka: funga ports zilizochapishwa kwenye 127.0.0.1 isipokuwa kama una sababu maalum ya kutofanya hivyo, na uweke reverse proxy mbele kwa chochote kinachopaswa kukabili ulimwengu. Hilo ndilo hasa mwongozo wa Traefik reverse proxy unalojenga kama hatua inayofuata baada ya ukurasa huu, container moja inayomiliki ports 80 na 443 na kuelekeza kwenye kila kitu kingine kwa kutumia hostname, ikiwa na TLS. (Unatoka kwenye usanidi wa zamani wa Traefik v2? Mwongozo wa kuhama kutoka Traefik v2 kwenda v3 unashughulikia mabadiliko ya majina na sheria.)

Thibitisha ufungaji 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 saraka chini ya /var/lib/docker/volumes/ na kuiweka ndani ya container. Mbadala wake ni bind mount, ./data:/var/lib/postgresql/data, ambayo hupanga njia uliyochagua kwenye host.

Mgawanyo unaofanya kazi kivitendo: named volumes kwa ajili ya data ambazo containers pekee ndizo huzigusa, hasa database, kwa kuwa Docker huanzisha volume ikiwa na umiliki ambao image inatarajia na ruhusa za faili hufanya kazi zenyewe. Bind mounts kwa ajili ya faili unazozigusa kutoka kwa host, faili za usanidi unazozihariri kwa kihariri cha maandishi, maktaba ya media unayoi-rsync, chochote ambacho unataka njia yake iwe wazi. Kushindwa kwa bind-mount kwa kawaida ni suala la umiliki: container huendeshwa kama UID 999, saraka yako ya host inamilikiwa na UID 1000, na programu hufa wakati wa kuanza ikiwa na permission denied kwenye logs zake. Named volumes hufanya aina hiyo ya hitilafu kutoweka, kwa gharama ya data kuishi kwenye njia inayosimamiwa na Docker, iliyofafanuliwa hapa chini.

environment na .env, weka siri nje ya git

${POSTGRES_PASSWORD} haisomwi kutoka kwenye shell yako; Compose huweka thamani zake kutoka kwenye faili inayoitwa .env iliyokaa karibu na compose.yml. Iunde:

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

Tengeneza thamani halisi kwa openssl rand -hex 24. Hex, si base64, kwa makusudi: nenosiri hili huingia ndani ya connection string ya DATABASE_URL, na herufi za /, +, na = ambazo base64 huzalisha huvunja uchanganuzi wa URL, hitilafu inayojitokeza kama hitilafu ya uthibitishaji, si hitilafu ya sintaksia, na hugharimu jioni nzima. Mstari wa .gitignore huwekwa kabla ya commit ya kwanza: faili ya compose ni salama kuchapishwa na kuwekwa kwenye version control, faili ya .env haipaswi kamwe, na siri iliyogusa historia ya git ni siri unayopaswa kuibadilisha. Ukianzisha stack huku variable ikikosekana, Compose hutoa onyo kali na kuendelea na kamba tupu, ambayo kwa nenosiri la Postgres inamaanisha deployment iliyovunjika:

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

docker compose config huchapisha faili iliyokamilika, njia ya haraka zaidi ya kuangalia kile ambacho containers zitapokea; kumbuka kuwa matokeo yake yanajumuisha siri zako.

depends_on haisubiri chochote, isipokuwa uongeze healthcheck

depends_on: [db] tupu hudhibiti mpangilio wa kuanza pekee: Compose huzindua Postgres kwanza na programu muda mfupi baadaye, wakati Postgres bado iko sekunde chache mbali na kukubali miunganisho. Programu hupiga database, inashindwa, na kuanguka au kujaribu tena kulingana na jinsi ilivyoandikwa vizuri.

Toleo la kutegemewa ni lile ambalo faili hapo juu inatumia: huduma ya db hufafanua healthcheck (Postgres hutoa pg_isready kwa ajili ya hili hasa), na programu hutangaza depends_on na condition: service_healthy. Compose huanzisha database, hupiga kura ya ukaguzi kila sekunde 10, na huanzisha Miniflux tu wakati ukaguzi utakapofaulu. Ikiwa database haitakuwa na afya kamwe, nenosiri mbaya, volume iliyoharibika, programu haitaanza kamwe na Compose itakuambia ni dependency ipi iliyoshindwa:

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

Ujumbe huo hukuonyesha docker compose logs db, ambapo hitilafu halisi ipo.

restart: unless-stopped

restart: unless-stopped kwenye huduma zote mbili inamaanisha kuwa containers hurudi baada ya kuanguka na baada ya reboot ya VPS, lakini hubaki zimezimwa ikiwa uliendesha docker compose stop kwa makusudi. Mbadala wake always hufufua containers hata baada ya kusimamishwa kwa mikono, jambo ambalo mara chache ndilo unalokusudia. Bila sera ya restart, reboot ya kernel-update saa 9 usiku itazima huduma 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.

Njia za kufeli, pamoja na ujumbe utakaouona

permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock, haupo kwenye kundi la docker bado, au upo lakini kikao chako cha sasa kimeanza kabla ya kuongezwa. id inaonyesha makundi yako ya sasa; newgrp docker inarekebisha shell ya sasa, na kutoka kisha kuingia tena (logout/login) kunarekebisha makundi yote.

Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?, tatizo tofauti: daemon yenyewe imezimika. sudo systemctl status docker na sudo journalctl -u docker -n 50 zinaeleza sababu. Kwenye VPS, sababu ya kawaida ni diski kujaa, angalia df -h /var/lib/docker kwanza.

Bind for 127.0.0.1:8080 failed: port is already allocated, container nyingine tayari imetumia port hiyo ya host. docker ps inaonyesha ni ipi; mara nyingi ni container iliyosalia kutoka kwa docker run ya majaribio ya wiki zilizopita. Ikiwa docker ps haina kitu, basi mchakato usio wa Docker unashikilia port hiyo: sudo ss -tlnp | grep 8080 itakuonyesha ni mchakato upi.

yaml: line 14: did not find expected key, hitilafu ya mpangilio (indentation) kwenye mstari uliotajwa au karibu nao. Faili za Compose ni YAML: tumia nafasi mbili (two-space) kwa mpangilio, tumia nafasi (spaces) pekee, na tab yoyote itasababisha faili kufeli. docker compose config inahakiki faili bila kuanzisha chochote, na kuikimbiza baada ya kila marekebisho ni tabia nzuri na rahisi.

Mshangao wa ufw haitoi ujumbe wowote wa hitilafu, jambo linaloufanya kuwa hatari: deploy inafanikiwa, ufw status inaonekana sawa, na scan ya port kutoka nje bado inaona database yako. Soma tena sehemu ya ports hapo juu, hakikisha kila ingizo la ports: halikosi prefix ya 127.0.0.1:, na uthibitishe kutoka kwa mashine nyingine kwa kutumia curl http://your-vps-ip:8080; "connection refused" ndilo jibu unalotaka kuona.

Kuanzia hapa, mwongozo wa Traefik unageuza stack hii moja kuwa programu nyingi nyuma ya sehemu moja ya kuingilia ya HTTPS, na vitu vinavyofaa kuji-host mwaka 2026 ni orodha ya vitu vya kujaribu. Mara tu stack kadhaa zinapokuwa zinafanya kazi na kila moja ikiwa na mfumo wake wa kuingia (login), seva ya SSO ya kuji-host kama Authentik inaziunganisha zote kuwa akaunti moja nyuma ya proxy hiyo hiyo.

Seva ya mchezo kama seva ya Minecraft kwenye VPS ni mradi mzuri wa kwanza wa Compose wa kufanyia mazoezi. Ikiwa ungependa kujifunza kwa kutumia kitu unachofungua kila siku, openGym, kifuatiliaji cha mazoezi kinachojihostiwa ni stack ndogo iliyofungwa kwenye git tag badala ya image tag, na inahitaji TLS iwekwe mbele kabla hujasajili passkey ya kwanza. Picha kwa kawaida huwa jambo la kwanza ambalo watu hutaka kuliondoa kwenye cloud ya mtu mwingine, na kulinganisha PhotoPrism na Immich husaidia kubainisha kiwango cha chini cha RAM pamoja na utaratibu wa backup unaouhitaji kabla ya kuhusisha volume na mojawapo. Huduma mbili zinapoanza 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 zilizoelezwa hapo juu zimekuwa mazoea.

FAQ

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

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

Je, docker compose down inafuta data zangu?

Amri ya kawaida ya docker compose down haifuti data; inaondoa tu containers na mtandao wa mradi. Named volumes hubaki salama na amri ya up -d inayofuata itaziunganisha tena. docker compose down -v ni njia ya uharibifu: inafuta named volumes, ikiwemo database yako, bila kuuliza uthibitisho na bila njia ya kurudisha data. Usitekeleze -v kwenye stack yenye data halisi isipokuwa kama una backup iliyothibitishwa.

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

docker-compose (yenye kistari) ni Compose v1, programu ya Python inayojitegemea ambayo ilifikia mwisho wa maisha yake mwaka 2023 na haipaswi kusakinishwa kwenye seva mpya. docker compose (yenye nafasi) ni Compose v2, plugin ya Go kwa ajili ya Docker CLI, inayopatikana kama docker-compose-plugin kutoka kwenye apt repository ya Docker. Amri na faili za YAML zinaoana karibu kikamilifu, hivyo wakati mafunzo ya zamani yanaposema docker-compose up, andika docker compose up.

Kwa nini ninaweza kufikia Docker container yangu kutoka kwenye Internet hata kama ufw imefunga port hiyo?

Kwa sababu Docker huchapisha ports kwa kutumia sheria za DNAT kwenye chain ya PREROUTING ya iptables, na pakiti zilizobadilishwa hupita kwenye njia ya FORWARD kupitia chains za Docker yenyewe, hazipiti kamwe kwenye chain ya INPUT ambapo sheria za ufw hutumika. Kwa hivyo, ufw deny 8080 haifanyi kazi yoyote kwenye port ya container iliyochapishwa. Tatua hili 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) unaotarajiwa na image na ruhusa hufanya kazi bila shida. Tumia bind mounts kwa faili ambazo wewe pia unazishughulikia kutoka kwenye seva: configs unazohariri, media unazopakia, au chochote ambacho unataka njia yake (path) iwe wazi. Ikiwa container inashindwa kuanza na permission denied kwenye bind mount, kutolingana kwa UID kati ya seva na container ndilo jambo la kwanza la kuchunguza.