VPSలో Docker Compose ఎలా వాడాలి

మీరు నిర్మించేది ఏమిటి

Docker Compose ఈ సైట్‌లోని దాదాపు ప్రతిదానికీ అడుగున ఉన్న పునాది. Nextcloud, Vaultwarden, n8n, Immich, Rocket.Chat — ఆ ప్రతి గైడ్‌లోనూ "ఈ compose file వ్రాయండి" అని ప్రారంభమవుతుంది, ఆ file నిజానికి ఏమి అర్థం అని వివరించే పేజీ ఇది. మీరు Ubuntu 24.04‌లో Docker సొంత apt repository నుండి Docker Engine మరియు Compose v2 plugin ను ఇన్‌స్టాల్ చేస్తారు. తర్వాత ఒక నిజమైన రెండు-సేవల స్టాక్‌ను నడుపుతారు — Miniflux, ఒక చిన్న RSS రీడర్, మరియు PostgreSQL — ఎందుకంటే ఆ జంట పెద్ద యాప్‌లు వాడే ప్రతి ప్యాటర్న్‌ను ఉపయోగిస్తుంది: pinned images, healthcheck తో ఒక డేటాబేస్, ఒక named volume, .env file లో రహస్యాలు, మరియు localhost కు మాత్రమే పబ్లిష్ చేసిన పోర్ట్.

ఇన్‌స్టాలేషన్‌కు ఐదు నిమిషాలు పడుతుంది. ఈ గైడ్ మిగిలిన భాగం తర్వాత ఇబ్బంది కలిగించే అంశాలను కవర్ చేస్తుంది: docker గ్రూప్ మరొక పేరుతో root అవ్వడం, పబ్లిష్ చేసిన పోర్ట్‌లు మీ ufw నియమాలను నేరుగా దాటిపోవడం, మరియు ఎటువంటి నిర్ధారణ అడుగు లేకుండా మీ డేటాబేస్‌ను తొలగించే docker compose down పై ఒక ఫ్లాగ్.

ముందస్తు అవసరాలు: ఒక కొత్త Ubuntu 24.04 KVM VPS, sudo తో ఒక యూజర్, మరియు ఒక గిగాబైట్ లేదా అంతకంటే ఎక్కువ RAM. ఇప్పటికే ఉన్న Docker ఇన్‌స్టాలేషన్ కూడా సరే — తొలగించాల్సింది ఏమిటో మొదటి విభాగం కవర్ చేస్తుంది.

Docker రిపోజిటరీ నుండి ఇన్‌స్టాల్ చేయండి, Ubuntu నుండి కాదు

మొదటి కమాండ్‌కు ముందు తప్పించుకోవలసిన రెండు తప్పు దారులు. Ubuntu స్వంత docker.io ప్యాకేజ్ పనిచేస్తుంది, అయితే అది Docker విడుదలల వెనుక ఉంటుంది. మిగతా అన్నీ ఊహించే ప్లగిన్ నిర్మాణం దానికి లేదు. ప్రత్యేక docker-compose బైనరీ — హైఫన్‌తో ఉన్నది — Compose v1: Python, 2023 నుండి జీవితకాలం ముగిసింది. పాత ట్యుటోరియల్‌లు విఫలమవ్వడానికి ఇదే కారణం. నేటి Compose అనేది స్పేస్‌తో ఉన్న docker compose, ఒక CLI ప్లగిన్, ఇంజిన్‌ మాదిరిగానే అదే రిపోజిటరీ నుండి ఇన్‌స్టాల్ చేయబడుతుంది.

అందులో ఏదైనా ఇప్పటికే సిస్టమ్‌లో ఉంటే, ముందుగా వాటిని తొలగించండి — ప్లగిన్‌ను Ubuntu స్వంతగా ప్యాకేజ్ చేసిన docker-compose-v2 తో సహా, తద్వారా ప్రతిదీ ఒకే రిపోజిటరీ నుండి వస్తుంది:

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

కొత్త VPSలో Package 'docker.io' is not installed, so not removed అనేది సాధారణ అవుట్‌పుట్. తర్వాత Docker రిపోజిటరీని జోడించి ఇన్‌స్టాల్ చేయండి:

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

మూడు పొరలను ధృవీకరించండి:

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

మొదటి రెండు వెర్షన్ స్ట్రింగ్‌లను ప్రింట్ చేస్తాయి — Docker Compose version v2.x.x మీకు ప్లగిన్ ఉందని నిర్ధారిస్తుంది, పని చేయని v1 బైనరీ కాదు. hello-world రన్ Hello from Docker!తో ముగియాలి. ఈ ప్యాకేజ్ సర్వీస్‌ను బూట్ సమయంలో ప్రారంభించమని సెట్ చేస్తుంది; systemctl is-enabled docker అనేది enabledను ప్రింట్ చేస్తుంది.

docker సమూహం అనేది rootకి సమానం — జాగ్రత్తతో నిర్ణయించండి

ప్రస్తుతం ప్రతి docker కమాండ్‌కు sudo అవసరం. దీనికి కారణం /var/run/docker.sock వద్ద ఉన్న డెమాన్ సాకెట్‌ను root మరియు docker సమూహం యాజమాన్యంలో ఉండటం. సమూహ సభ్యత్వం లేకపోతే మీరు అత్యధికంగా శోధించబడుతున్న Docker దోషాన్ని పొందుతారు:

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

ప్రామాణిక పరిష్కారం:

sudo usermod -aG docker $USER

సమూహ సభ్యత్వం లాగిన్ సమయంలో వర్తిస్తుంది. కాబట్టి ఈ దోషం మీ ప్రస్తుత షెల్‌లో కొనసాగుతుంది. ఈ సెషన్ కోసం newgrp docker నడపండి, లేదా లాగ్ అవుట్ చేసి తిరిగి లాగిన్ అవ్వండి. అప్పుడు id మీ సమూహాలలో docker ను జాబితా చేస్తుంది.

ఇప్పుడు స్పష్టమైన నిజం: docker సమూహ సభ్యత్వం అనేది హోస్ట్‌పై rootకి సమానం. "root లాంటిది" కాదు, "అధికారం ఉన్నది" కాదు — అది ఖచ్చితంగా root. ఆ సమూహంలో ఉన్న ఎవరైనా docker run --rm -it -v /:/host alpine chroot /host నడపగలరు మరియు మొత్తం ఫైల్‌సిస్టమ్‌ను యాజమాన్యంలోకి తీసుకోగలరు. పాస్‌వర్డ్ అడగదు. ఆ సమూహం సౌలభ్యం కోసం ఉంది, భద్రత కోసం కాదు.

Docker యొక్క rootless మోడ్ నిజమైన ప్రత్యామ్నాయం. దీనిలో డెమాన్ మీ అన్‌ప్రివిలేజ్డ్ యూజర్‌గా నడుస్తుంది. దీనికి కొన్ని ధరలు ఉన్నాయి: 1024 కంటే తక్కువ పోర్టులకు అదనపు సెటప్ అవసరం. నెట్‌వర్కింగ్ యూజర్‌స్పేస్ షిమ్ ద్వారా నడుస్తుంది, దీనికి కొలవదగిన ఓవర్‌హెడ్ ఉంటుంది. కొన్ని ఇమేజ్‌లు నిజమైన root లేకుండా సరిగా పనిచేయవు. ఒకే అడ్మిన్ ఉన్న VPSలో, అక్కడ ఉన్న ఏకైక లాగిన్‌కు ఇప్పటికే sudo ఉంటే, ఈ సమూహం ఆచరణలో మార్పును తీసుకురాదు. ఇక్కడ ఉన్న ప్రతి గైడ్ దీనినే ఊహిస్తుంది. అయితే దీన్ని sudo కంటే తక్కువగా భావించి ఇవ్వవద్దు.

కంపోజ్ ఫైలు నిర్మాణం

ప్రతి స్టాక్‌కు దాని స్వంత డైరెక్టరీని ఇవ్వండి — డైరెక్టరీ పేరు ప్రాజెక్ట్ పేరు అవుతుంది, అది కంటైనర్‌లు, నెట్‌వర్క్‌లు మరియు వాల్యూమ్‌లకు ప్రిఫిక్స్ అవుతుంది:

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

compose.yml ని సృష్టించండి (ఇది ఆధునిక పేరు; docker-compose.yml ఇంకా పనిచేస్తుంది). పాత version: కీని వదిలివేయండి — అది పనికిరాదు మరియు దానిని చూసినట్లయితే కంపోజ్ హెచ్చరిస్తుంది.

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:

పైన ఉన్న ప్రతి వరుస ఒక నిర్ణయం. వాటిని ఒక్కొక్కటిగా తీసుకోండి.

ఇమేజ్ వర్షన్‌లను పిన్ చేయండి — :latest ప్లస్ ఒక pull అనేది మీ పర్యవేక్షణ లేని అప్‌గ్రేడ్

postgres:latest కాదు, postgres:16-alpine. ఒక ట్యాగ్ ఫ్రోజన్ చేయబడదు: మీరు పుల్ చేసిన ప్రతిసారి, :latest అనేది మెయింటైనర్ ఇటీవల పుష్ చేసిన దేనికైతే అది తిరిగి రిజాల్వ్ అవుతుంది. దీన్ని మీరు నేర్చుకోబోయే రొటీన్ అప్‌గ్రేడ్ అలవాటుతో — docker compose pull && docker compose up -d — కలపండి, మరియు :latest అంటే మెజర్-వర్షన్ జంప్‌లు మీరు ఎంచుకున్నప్పుడు కాకుండా, అప్‌స్ట్రీమ్ వాటిని షిప్ చేసినప్పుడల్లా వస్తాయి. PostgreSQL విషయంలో ఇది ఊహాత్మకం కాదు: 16 నుండి 17 కు అకస్మాత్తు జంప్ కంటైనర్‌ను కంపాటిబుల్ కాని డేటా డైరెక్టరీపై క్రాష్-లూప్‌లో ఉంచుతుంది, ఎందుకంటే పోస్ట్‌గ్రెస్ మెజర్ అప్‌గ్రేడ్‌లకు రీస్టార్ట్ కాదు, డంప్ మరియు రిస్టోర్ అవసరం.

కనీసం మెజర్ వర్షన్‌ను పిన్ చేయండి (postgres:16-alpine అనేది 16.x ప్యాచ్ రిలీజ్‌లను అనుసరిస్తుంది), మరియు అప్లికేషన్‌లను miniflux/miniflux:2.2.9 వంటి ఖచ్చితమైన రిలీజ్‌కు పిన్ చేయండి — ప్రాజెక్ట్ రిలీజ్ పేజీని తనిఖీ చేసి, మీరు ఫైలును వ్రాసేటప్పుడు ప్రస్తుతం ఏది అందుబాటులో ఉందో దాన్ని ఉపయోగించండి. అప్పుడు అప్‌గ్రేడ్ అనేది మీరు ఉద్దేశపూర్వకంగా చేసిన ఒక వరుస ఎడిట్ అవుతుంది, ఇది git diff లో కనిపిస్తుంది.

127.0.0.1 కు పబ్లిష్ చేయండి, ఎందుకంటే Docker అనేది ufw ను దాటి వెళ్తుంది

"127.0.0.1:8080:8080" — హోస్ట్ చిరునామా, హోస్ట్ పోర్ట్, కంటైనర్ పోర్ట్. చాలా ట్యుటోరియల్‌లు "8080:8080" ను వ్రాస్తాయి, ఇది 0.0.0.0:8080:8080 కు షార్ట్‌హ్యాండ్: పబ్లిక్ ఇంటర్‌ఫేస్ సహా ప్రతి ఇంటర్‌ఫేస్‌పై లిజన్ చేస్తుంది.

ఇక్కడ ఒక ఉచ్చు ఉంది, మరియు ఇది దాదాపు ప్రతి ఒక్కరినీ ఒకసారి కాటేస్తుంది. Docker ఒక పోర్ట్‌ను పబ్లిష్ చేయడం ద్వారా ఒక DNAT రూల్‌ను వ్రాస్తుంది, అది ఫిల్టరింగ్‌కు ముందు ప్యాకెట్ గమ్యస్థానాన్ని కంటైనర్ యొక్క అంతర్గత IP కి మారుస్తుంది, కాబట్టి ప్యాకెట్ FORWARD మార్గాన్ని తీసుకుంటుంది మరియు మీ ufw రూల్స్ ఉన్న INPUT ను ఎప్పుడూ తాకదు. sudo ufw deny 8080 విజయాన్ని నివేదిస్తుంది, ufw status పోర్ట్ తిరస్కరించబడిందని చూపుతుంది, మరియు సర్వీస్ ఇంకా మొత్తం ఇంటర్నెట్‌కు స్పందిస్తుంది. మీ ఫైర్‌వాల్ పాడవలేదు; అది డిజైన్ ప్రకారం బైపాస్ అవుతోంది. Docker ఎందుకు ufw ను బైపాస్ చేస్తుందో, మరియు కంటైనర్ ట్రాఫిక్‌ను నిజంగా ఫిల్టర్ చేయడం ఎలా అనేది మెకానిజం మరియు పబ్లిక్‌గా ఉండాల్సిన పోర్ట్‌ల కోసం DOCKER-USER పరిష్కారం గురించి వివరిస్తుంది.

మొత్తం సమస్యను మాయం చేసే అలవాటు: మీకు తప్పనిసరి అనిపించే నిర్దిష్ట కారణం లేకపోతే పబ్లిష్ చేసిన పోర్ట్‌లను 127.0.0.1 కు బైండ్ చేయండి, మరియు ప్రపంచానికి ఎదురుగా ఉండాల్సిన వాటి కోసం ముందుగా ఒక రివర్స్ ప్రాక్సీని ఉంచండి. ఈ పేజీ తర్వాత తదుపరి దశగా Traefik రివర్స్ ప్రాక్సీ గైడ్ నిర్మించేది ఖచ్చితంగా అదే — పోర్ట్లు 80 మరియు 443 ను కలిగి ఉన్న మరియు TLS తో హోస్ట్‌పేరు ద్వారా మిగతా అన్నింటికీ రూట్ అయ్యే ఒక కంటైనర్. (పాత Traefik v2 సెటప్ నుండి వస్తున్నారా? Traefik v2 నుండి v3 మైగ్రేషన్ గైడ్ పేరు మార్పులు మరియు రూల్ మార్పులను కవర్ చేస్తుంది.)

స్టాక్‌ను ప్రారంభించిన తర్వాత బైండ్‌ను ధృవీకరించండి: sudo ss -tlnp | grep 8080 అనేది 0.0.0.0:8080 లేదా *:8080 కాకుండా 127.0.0.1:8080 ను చూపించాలి.

నేమ్డ్ వాల్యూమ్‌లు vs బైండ్ మౌంట్‌లు

db-data:/var/lib/postgresql/data అనేది ఒక నేమ్డ్ వాల్యూమ్: Docker అనేది /var/lib/docker/volumes/ కింద ఒక డైరెక్టరీని సృష్టిస్తుంది మరియు నిర్వహిస్తుంది మరియు దాన్ని కంటైనర్‌లోకి మౌంట్ చేస్తుంది. ప్రత్యామ్నాయం ఒక బైండ్ మౌంట్, ./data:/var/lib/postgresql/data, ఇది హోస్ట్‌పై మీరు ఎంచుకున్న పాత్‌ను మ్యాప్ చేస్తుంది.

ప్రాక్టీస్‌లో నిలిచే విభజన ఇది: కంటైనర్‌లు తాకే డేటా కోసం నేమ్డ్ వాల్యూమ్‌లు — పైగా డేటాబేస్‌లు, ఎందుకంటే Docker వాల్యూమ్‌ను ఇమేజ్ ఆశించే యాజమాన్యంతో ప్రారంభిస్తుంది మరియు ఫైల్ అనుమతులు సరిగ్గా పని చేస్తాయి. మీరు హోస్ట్ నుండి తాకే ఫైళ్ల కోసం బైండ్ మౌంట్‌లు — మీరు టెక్స్ట్ ఎడిటర్‌తో ఎడిట్ చేసే కాన్ఫిగ్ ఫైళ్లు, మీరు rsync చేసే మీడియా లైబ్రరీ, దేని పాత్ స్పష్టంగా కనిపించాలో అది. సాంప్రదాయిక బైండ్-మౌంట్ వైఫల్యం యాజమాన్యం: కంటైనర్ UID 999 వలే నడుస్తుంది, మీ హోస్ట్ డైరెక్టరీ UID 1000 యాజమాన్యంలో ఉంటుంది, మరియు యాప్ స్టార్టప్‌పై దాని లాగ్‌లలో permission denied తో మరణిస్తుంది. నేమ్డ్ వాల్యూమ్‌లు ఆ తరగతి బగ్‌లను ఎక్కువగా అదృశ్యం చేస్తాయి, డేటా Docker-నిర్వహించే పాత్ వద్ద ఉండే ఖర్చుతో — దిగువన కవర్ చేయబడింది.

environment మరియు .env — సీక్రెట్‌లను git బయట ఉంచండి

${POSTGRES_PASSWORD} అనేది మీ షెల్ నుండి చదవబడదు; Compose అనేది compose.yml పక్కన ఉన్న .env అనే ఫైలు నుండి దాన్ని ఇంటర్‌పోలేట్ చేస్తుంది. దాన్ని సృష్టించండి:

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

openssl rand -hex 24 తో నిజమైన విలువలను జనరేట్ చేయండి. ఉద్దేశపూర్వకంగా బేస్64 కాదు, హెక్స్: ఈ పాస్‌వర్డ్ DATABASE_URL కనెక్షన్ స్ట్రింగ్ లోపల వస్తుంది, మరియు బేస్64 ఉత్పత్తి చేసే /, +, మరియు = అక్షరాలు URL పార్సింగ్‌ను విరుగుస్తాయి — ఇది సింటాక్స్ ఎర్రర్ కాదు, ఆథెంటికేషన్ ఎర్రర్‌గా కనిపించే వైఫల్యం, మరియు ఇది ఒక సాయంత్రం ఖర్చు అవుతుంది. .gitignore వరుస మొదటి కమిట్‌కు ముందు వస్తుంది: కంపోజ్ ఫైలు పబ్లిష్ చేయడానికి మరియు వర్షన్ చేయడానికి సురక్షితం, .env ఫైలు ఎప్పటికీ కాదు, మరియు git హిస్టరీని తాకిన సీక్రెట్ అనేది మీరు రొటేట్ చేసే సీక్రెట్. మీరు ఒక వేరియబుల్ లేకుండా స్టాక్‌ను ప్రారంభిస్తే, Compose బిగ్గగా హెచ్చరిస్తుంది మరియు ఖాళీ స్ట్రింగ్‌తో కొనసాగుతుంది — పోస్ట్‌గ్రెస్ పాస్‌వర్డ్ విషయంలో దానర్థం ఒక పాడైన డెప్లాయ్‌మెంట్:

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

docker compose config అనేది పూర్తిగా-ఇంటర్‌పోలేట్ చేయబడిన ఫైలును ప్రింట్ చేస్తుంది — కంటైనర్‌లు వాస్తవంగా ఏమి స్వీకరిస్తాయో తనిఖీ చేయడానికి వేగవంతమైన మార్గం; దాని అవుట్‌పుట్‌లో మీ సీక్రెట్‌లు ఉన్నాయని గుర్తుంచుకోండి.

depends_on ఏదీకోసం వేచి ఉండదు — మీరు ఒక హెల్త్‌చెక్ జోడించకపోతే

ఒక బేర్ depends_on: [db] స్టార్ట్ క్రమాన్ని మాత్రమే నియంత్రిస్తుంది: Compose ముందుగా పోస్ట్‌గ్రెస్‌ను ప్రారంభిస్తుంది మరియు యాప్‌ను ఒక క్షణం తర్వాత, పోస్ట్‌గ్రెస్ కనెక్షన్‌లను ఆమోదించడానికి ఇంకా సెకన్ల దూరంలో ఉన్నప్పుడు ప్రారంభిస్తుంది. యాప్ డేటాబేస్‌ను హిట్ చేస్తుంది, విఫలమవుతుంది, మరియు అది ఎంత బాగా వ్రాయబడిందో అనుగుణంగా క్రాష్ అవుతుంది లేదా రీట్రై చేస్తుంది.

నమ్మకమైన వర్షన్ పైన ఉన్న ఫైలు ఉపయోగించేది: db సర్వీస్ ఒక healthcheck ను నిర్వచిస్తుంది (పోస్ట్‌గ్రెస్ ఖచ్చితంగా దీని కోసం pg_isready ను షిప్ చేస్తుంది), మరియు యాప్ depends_on తో condition: service_healthy ను డిక్లేర్ చేస్తుంది. Compose డేటాబేస్‌ను ప్రారంభిస్తుంది, ప్రతి 10 సెకన్లకు చెక్‌ను పోల్ చేస్తుంది, మరియు చెక్ పాస్ అయిన తర్వాత మాత్రమే Miniflux ను ప్రారంభిస్తుంది. డేటాబేస్ ఎప్పటికీ హెల్దీ అవ్నకపోతే — తప్పు పాస్‌వర్డ్, పాడైన వాల్యూమ్ — యాప్ ఎప్పటికీ ప్రారంభించబడదు మరియు Compose ఏ డిపెండెన్సీ విఫలమైందో మీకు చెబుతుంది:

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

ఆ సందేశం మీకు docker compose logs db వైపు సూచిస్తుంది, అక్కడే నిజమైన ఎర్రర్ ఉంటుంది.

restart: unless-stopped

రెండు సర్వీసులపై restart: unless-stopped అంటే కంటైనర్‌లు క్రాష్ తర్వాత మరియు VPS రీబూట్ తర్వాత తిరిగి వస్తాయి, కానీ మీరు ఉద్దేశపూర్వకంగా docker compose stop నడిపితే అవి డౌన్‌లో ఉంటాయి. ప్రత్యామ్నాయం always మాన్యువల్ స్టాప్ తర్వాత కూడా కంటైనర్‌లను తిరిగి బ్రతిస్తుంది — అరుదుగా మీరు అర్థం చేసుకున్నది. ఒక రీస్టార్ట్ పాలసీ లేకుండా, అనగా 4 a.m. వద్ద ఒక కెర్నల్-అప్‌డేట్ రీబూట్ మీ సర్వీసులను మీరు గమనించే వరకు నిశ్శబ్దంగా డౌన్ చేస్తుంది.

రోజువారీ ఆదేశాలు

ప్రతిరోజూ అవసరమైనదంతా ఐదు ఆదేశాలే. అవి ప్రాజెక్ట్ డైరెక్టరీ నుండి నడుపండి.

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 ను పదేపదే నడపడం సురక్షితం. అది ఫైల్‌ను వాస్తవ స్థితితో పోలుస్తుంది. కాన్ఫిగ్ లేదా ఇమేజ్ మారిన సర్వీసులను మాత్రమే మారుస్తుంది. అప్‌గ్రేడ్ జంట మీ పిన్ చేసిన ట్యాగ్‌లు ప్రస్తుతం సూచించే వాటిని పొందుతుంది. postgres:16-alpine కింద ప్యాచ్ విడుదలలు వస్తాయి. సరైన పిన్‌కి మీరు దాన్ని సవరించే వరకు ఏమీ రాదు — ఇదే దాని ఉద్దేశ్యం. అప్‌గ్రేడ్‌ల తర్వాత పాత ఇమేజ్‌లు పేరుకుంటాయి. docker image prune -f తో డిస్క్ స్థలాన్ని తిరిగి పొందండి.

ఇప్పుడు నాశనకారకమైనది, స్పష్టంగా చెప్పుకుందాం: docker compose down సురక్షితమే — కంటైనర్‌లు, నెట్‌వర్క్ నశించదగినవే. మీ డేటా వాల్యూమ్‌లో ఉంటుంది. docker compose down -v పేరున్న వాల్యూమ్‌లను కూడా తొలగిస్తుంది. అది మీ డేటాబేస్. వెంటనే పోతుంది. ఎలాంటి నిర్ధారణ అడగదు. తిరిగి పొందలేరు. -v ఫ్ల్యాగ్ ప్రయోగాలను తొలగించడానికి ఉంది. నిజమైన డేటా ఉన్న స్టాక్‌పై దాన్ని rm -rf లాగా జాగ్రత్తగా చూడండి. /var/lib/docker/volumes/ కింద ట్రాష్ బుట్ట లేదు.

నడుస్తున్న కంటైనర్ లోపల ఒకసారి షెల్ కావాలంటే: docker compose exec db psql -U miniflux మిమ్మల్ని డేటాబేస్‌లోకి తీసుకువెళ్తుంది. docker compose exec miniflux sh యాప్‌లో షెల్ ఇస్తుంది.

మీ డేటా వాస్తవానికి ఎక్కడ ఉంటుంది

నేమ్‌డ్ వాల్యూమ్‌లు ప్రాజెక్ట్ ప్రిఫిక్స్‌ను పొందుతాయి. కాబట్టి miniflux అనే డైరెక్టరీలోని db-data అవుతుంది miniflux_db-data:

docker volume ls
docker volume inspect miniflux_db-data

inspect అవుట్‌పుట్ ముఖ్యమైన లైన్‌ను కలిగి ఉంటుంది:

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

ఆ డైరెక్టరీయే డేటాబేస్. అది హోస్ట్ ఫైల్ సిస్టమ్‌లో root యాజమాన్యంలో ఉంటుంది. అది down, అప్‌గ్రేడ్‌లు మరియు కంటైనర్ రీబిల్డ్‌లను తట్టుకుని నిలుస్తుంది. మీ బ్యాకప్‌లు కచ్చితంగా క్యాప్చర్ చేయాల్సింది కూడా అదే.

నేమ్‌డ్ వాల్యూమ్‌ను బ్యాకప్ చేయడం

ప్రామాణిక పద్ధతి ఒక థ్రోఅవే కంటైనర్‌ను ఉపయోగించడం. అది వాల్యూమ్‌ను రీడ్-ఓన్లీగా హోస్ట్ డైరెక్టరీ పక్కన మౌంట్ చేస్తుంది. తర్వాత టార్ ఆర్కైవ్‌ను సృష్టిస్తుంది:

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 .

ఏ ఇన్‌స్టాలేషన్ అవసరం లేదు. ఏమీ నడుస్తూ ఉండదు. పునరుద్ధరణ దీనికి అద్దం లాంటిది — tar xzf ద్వారా మౌంట్‌లను వ్యతిరేక క్రమంలో ఉపయోగించి, అదే పేరుతో కొత్త ఖాళీ వాల్యూమ్‌లోకి పునరుద్ధరిస్తారు.

డేటాబేస్‌లకు ఒక హెచ్చరిక ఉంది: నడుస్తున్న Postgres డేటా డైరెక్టరీని టార్ చేయడం వల్ల మధ్యలో రాస్తున్న స్థితి నమోదవుతుంది. అది క్లిష్టంగా ప్రారంభం కాదు. టార్ పూర్తయ్యే కొన్ని సెకన్ల పాటు docker compose stop చేయండి. లేదా — మెరుగైనది — లాజికల్ డంప్ తీసుకోండి. అది రూపొందించిన విధంగానే స్థిరంగా ఉంటుంది:

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

-T అనేది Compose అప్రమేయంగా కేటాయించే సూడో-టెర్మినల్‌ను అచేతనం చేస్తుంది — డంప్ అవుట్‌పుట్‌ను TTY ద్వారా పంపడం వల్ల అది పాడవుతుంది. వీటిలో ఒకదాన్ని cronలో ఉంచండి. ఫలితాన్ని VPS నుండి బయటకు కాపీ చేయండి; ఒక డేటాను రక్షించే అదే డిస్క్‌లో ఉన్న బ్యాకప్ అనేది కాపీ మాత్రమే, బ్యాకప్ కాదు. నెక్స్ట్‌క్లౌడ్ గైడ్ ఈ రెండు పద్ధతుల చుట్టూ ఒక పూర్తి షెడ్యూల్డ్ రొటీన్‌ను రూపొందిస్తుంది.

వైఫల్య రకాలు, మీరు చూసే స్ట్రింగ్‌లతో

permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock — మీరు ఇంకా docker గ్రూప్‌లో లేరు, లేదా ఉన్నా సెషన్ దానికి ముందే ఉంది. id మీ వర్తమాన గ్రూప్‌లను చూపుతుంది; newgrp docker ప్రస్తుత షెల్‌ను సరిచేస్తుంది, లాగ్ అవుట్ చేసి తిరిగి లాగిన్ అవ్వడం అన్నింటినీ సరిచేస్తుంది.

Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running? — వేరే సమస్య: డెమన్ స్వయంగా డౌన్ అయింది. sudo systemctl status docker మరియు sudo journalctl -u docker -n 50 కారణాన్ని చెబుతాయి. VPSలో సాధారణ కారణం డిస్క్ నిండిపోవడం — ముందుగా df -h /var/lib/docker చేయండి.

Bind for 127.0.0.1:8080 failed: port is already allocated — మరొక కంటైనర్ ఇప్పటికే ఆ హోస్ట్ పోర్ట్‌ను ప్రచురించింది. docker ps దేది చూపుతుంది; కొన్ని వారాల క్రితం ఒక ప్రయోగాత్మక docker run నుండి మిగిలిన పాత కంటైనర్ సాధారణ కారణం. docker ps క్లీన్‌గా ఉంటే, Docker కాని ప్రాసెస్ ఆ పోర్ట్‌ను ఆక్రమించి ఉంది: sudo ss -tlnp | grep 8080 దాని పేరును చెబుతుంది.

yaml: line 14: did not find expected key — పేర్కొన్న లైన్ వద్ద లేదా కొద్దిగా పైన ఇండెంటేషన్ పొరపాటు ఉంది. Compose ఫైళ్లు YAML: రెండు-స్పేస్ ఇండెంటేషన్, స్పేస్‌లు మాత్రమే, మరియు ఎక్కడైనా ఒక tab అక్షరం ఉంటే అది ప్రాణాంతకం. docker compose config ఏదీ ప్రారంభించకుండా ఫైల్‌ను ధ్రువీకరిస్తుంది, మరియు ప్రతి సవరణ తర్వాత దాన్ని నడపడం ఒక చిన్న అలవాటు.

ufw ఆశ్చర్యం అసలు ఎలాంటి ఎర్రర్‌ను ప్రింట్ చేయదు, అందుకే అది ప్రమాదకరం: డిప్లాయ్ పనిచేస్తుంది, ufw status సరైనదిగా కనిపిస్తుంది, మరియు బయట నుండి ఒక పోర్ట్ స్కాన్ మీ డేటాబేస్‌ను ఏమైనా కనుగొంటుంది. పైన ఉన్న పోర్ట్స్ విభాగాన్ని మళ్లీ చదవండి, ప్రతి ports: ఎంట్రీలో 127.0.0.1: ప్రిఫిక్స్ లేకుండా ఉందో లేదో తనిఖీ చేయండి, మరియు వేరే మెషీన్ నుండి curl http://your-vps-ip:8080తో నిర్ధారించండి — కనెక్షన్ తిరస్కరించబడటమే మీరు కోరుకునే సమాధానం.

ఇక్కడ నుండి, Traefik గైడ్ ఈ ఒంటరి స్టాక్‌ను ఒక HTTPS ఎంట్రీ పాయింట్ వెనుక అనేక యాప్‌లుగా మారుస్తుంది, మరియు 2026లో స్వయం-హోస్ట్ చేయడానికి విలువైనవి దాని ద్వారా నడపడానికి ఒక షాపింగ్ జాబితా.

VPSలో ఒక Minecraft సర్వర్ వంటి ఒక గేమ్ సర్వర్ అభ్యాసం చేయడానికి స్నేహపూర్వకమైన మొదటి Compose ప్రాజెక్ట్.

FAQ

"Docker daemon socket కి కనెక్ట్ అవ్వడానికి ప్రయత్నిస్తున్నప్పుడు నాకు permission denied ఎందుకు వస్తుంది" అని ఎందుకు వస్తుంది?

మీ యూజర్ docker గ్రూప్‌లో లేరు, లేదా ప్రస్తుత సెషన్ ప్రారంభమైన తర్వాత జోడించబడ్డారు — సభ్యత్వం లాగిన్ సమయంలో మాత్రమే వర్తిస్తుంది. sudo usermod -aG docker $USER నడపండి, తర్వాత newgrp docker లేదా లాగ్ అవుట్ చేసి తిరిగి లాగిన్ అవ్వండి, మరియు id తో నిర్ధారించుకోండి. ఈ గ్రూప్ హోస్ట్‌కు root-కి సమానమైన యాక్సెస్‌ను ఇస్తుంది, కాబట్టి మీరు sudo ఇచ్చే యూజర్‌లను మాత్రమే జోడించండి.

docker compose down నా డేటాను డిలీట్ చేస్తుందా?

సాధారణ docker compose down చేయదు — ఇది కంటైనర్‌లు మరియు ప్రాజెక్ట్ నెట్‌వర్క్‌ను తొలగిస్తుంది; నేమ్డ్ వాల్యూమ్‌లు మిగిలిపోతాయి మరియు తదుపరి up -d వాటిని తిరిగి జోడిస్తుంది. docker compose down -v ప్రమాదకరమైన రూపం: ఇది నేమ్డ్ వాల్యూమ్‌లను డిలీట్ చేస్తుంది, అంటే మీ డేటాబేస్, ఎలాంటి నిర్ధారణ లేకుండా మరియు తిరిగి చేయలేని విధంగా. వెరిఫై చేసిన బ్యాకప్ మీ దగ్గర ఉన్నప్పుడు మాత్రమే నిజమైన డేటా ఉన్న స్టాక్‌పై -v నడపండి.

docker-compose మరియు docker compose మధ్య తేడా ఏమిటి?

docker-compose (హైఫన్) అనేది Compose v1, 2023లో జీవితకాలం ముగిసిన స్టాండలోన్ Python బైనరీ, దీన్ని కొత్త సర్వర్‌లపై ఇన్‌స్టాల్ చేయకూడదు. docker compose (స్పేస్) అనేది Compose v2, Docker CLI కోసం Go ప్లగిన్, Docker యొక్క apt రిపాజిటరీ నుండి docker-compose-plugin గా ఇన్‌స్టాల్ చేయబడింది. కమాండ్‌లు మరియు YAML దాదాపు పూర్తిగా అనుకూలంగా ఉన్నాయి, కాబట్టి పాత ట్యుటోరియల్ docker-compose up అని చెప్పినప్పుడు, మీరు docker compose up టైప్ చేయండి.

ufw పోర్ట్‌ను బ్లాక్ చేసినప్పటికీ, నేను ఇంటర్నెట్ నుండి నా Docker కంటైనర్‌ను ఎలా చేరుకోగలను?

ఎందుకంటే Docker పోర్ట్‌లను iptables యొక్క PREROUTING చైన్‌లో DNAT నియమాలతో పబ్లిష్ చేస్తుంది, మరియు రీరైట్ చేయబడిన ప్యాకెట్‌లు Docker యొక్క స్వంత చైన్‌ల ద్వారా FORWARD పాత్‌లో ప్రయాణిస్తాయి — అవి ufw నియమాలు వర్తించే INPUT చైన్‌ను ఎప్పుడూ తాకవు. కాబట్టి ufw deny 8080 పబ్లిష్ చేసిన కంటైనర్ పోర్ట్‌కు ఏమీ చేయదు. దీన్ని మూలం వద్దే పరిష్కరించండి: 127.0.0.1: కు పబ్లిష్ చేయండి మరియు సర్వీస్‌లను రివర్స్ ప్రాక్సీ ద్వారా బయటకు అందించండి.

నేను నేమ్డ్ వాల్యూమ్ వాడాలా లేదా బైండ్ మౌంట్ వాడాలా?

కంటైనర్ మాత్రమే తాకే డేటా కోసం నేమ్డ్ వాల్యూమ్‌లు — ముఖ్యంగా డేటాబేస్‌లు, ఎందుకంటే Docker ఇమేజ్ ఆశించే యాజమాన్యాన్ని సెట్ చేస్తుంది మరియు అనుమతులు సరిగ్గా పనిచేస్తాయి. మీరు హోస్ట్ నుండి కూడా హ్యాండిల్ చేసే ఫైళ్ల కోసం బైండ్ మౌంట్‌లు: మీరు ఎడిట్ చేసే కాన్ఫిగ్‌లు, మీరు అప్‌లోడ్ చేసే మీడియా, దేని పాత్ మీరు స్పష్టంగా కావాలనుకుంటున్నారో అది. బైండ్ మౌంట్‌పై ఒక కంటైనర్ స్టార్టప్ వద్ద permission denied తో విఫలమైతే, హోస్ట్-వర్సస్-కంటైనర్ UID అసమానతను మీరు మొదట తనిఖీ చేయాలి.