VPS वर Docker Compose सेटअप Ubuntu 24.04 वर

तुम्ही काय तयार करत आहात

Docker Compose हे या साइटवरील जवळपास प्रत्येक गोष्टीचे पायाभूत स्तर आहे. Nextcloud, Vaultwarden, n8n, Immich, Rocket.Chat — या पैकी प्रत्येक मार्गदर्शक "ही compose फाइल लिहा" या वाक्याने सुरू होते, आणि त्या फाइलचा प्रत्यक्ष अर्थ काय आहे हे या पृष्ठावर स्पष्ट केले आहे. तुम्ही Ubuntu 24.04 वर Docker च्या स्वतःच्या apt रेपॉझिटरीमधून Docker Engine आणि Compose v2 प्लगइन इंस्टॉल कराल, नंतर एक वास्तविक दोन-सेवा स्टॅक उभाराल — Miniflux, एक लहान RSS रीडर, आणि PostgreSQL — कारण ही जोडी त्या सर्व पॅटर्नचा वापर करते जो मोठे ऍप्लिकेशन्स वापरतात: पिन केलेले इमेजेस, healthcheck सह एक डेटाबेस, एक नेम्ड व्हॉल्यूम, .env फाइलमधील सिक्रेट्स, आणि फक्त 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 पासून end-of-life आहे, आणि जुने ट्यूटोरियल्स अयशस्वी होण्याचे हे कारण आहे. आज Compose म्हणजे docker compose आहे, ज्यात स्पेस आहे, हे एक CLI प्लगइन आहे, आणि इंजिनसोबत त्याच रेपॉजिटरीमधून इंस्टॉल होते.

जर यापैकी काहीही आधीच सिस्टमवर असेल, तर ते आधी काढा — यामध्ये docker-compose-v2 चा समावेश आहे, जे Ubuntu चे स्वतःचे प्लगइन पॅकेज आहे, जेणेकरून सर्व काही एकाच रेपॉजिटरीमधून येईल:

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 गटाच्या मालकीचा आहे. गटात सदस्यत्व नसल्यास तुम्हाला Google वर सर्वाधिक शोधला जाणारा 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 पेक्षा कमी पोर्टना अतिरिक्त सेटअप लागतो, नेटवर्किंग userspace शिमद्वारे चालते ज्याचा मोजण्यायोग्य खर्च आहे, आणि काही इमेजेस खर्या root शिवाय योग्यरित्या काम करत नाहीत. एका-प्रशासक असलेल्या VPS वर, जेथे एकमेव लॉगिनकडे आधीच sudo आहे, तेथे गट व्यवहारात काहीही बदलत नाही, आणि इथील प्रत्येक मार्गदर्शक हेच गृहीतक धरतो — फक्त ते sudo पेक्षा कमी आहे असे समजून ते कधीच देऊ नका.

compose फाईलची रचना

प्रत्येक stack ला त्याची स्वतःची डिरेक्टरी द्या — डिरेक्टरीचे नावच प्रोजेक्ट नाव बनते, जे containers, networks आणि volumes ला प्रीफिक्स देते:

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

compose.yml तयार करा (हे आधुनिक नाव आहे; docker-compose.yml देखील काम करते). जुनी version: की वगळा — ती अप्रचलित आहे आणि Compose ला ती दिसल्यास ते सूचित करते.

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:

वरील प्रत्येक ओळ एक निर्णय आहे. त्या एका-एका घेऊन पाहूया.

प्रतिमा (image) आवृत्त्या निश्चित करा — :latest आणि pull हा एक अनattended अपग्रेड आहे

postgres:16-alpine, postgres:latest नाही. टॅग फ्रोझन नसतो: :latest हे प्रत्येक वेळी pull करताना maintainer ने सर्वात अलीकडे कोणती आवृत्ती पुश केली आहे, त्यावर पुन्हा-निराकरण करते. तुम्ही शिकणार असलेल्या नियमित अपग्रेड सवयीसोबत — docker compose pull && docker compose up -d — हे जोडा, आणि :latest म्हणजे जेव्हा upstream त्या पाठवते, तेव्हा major-version च्या झेपा येतात, तुम्ही निवडल्यावर नाही. PostgreSQL साठी हे गृहीतक नाही: 16 वरून 17 वर अचानक झेप घेतल्यास container एका विसंगत डेटा डिरेक्टरीवर crash-looping करत राहतो, कारण Postgres major अपग्रेड्सना restart न लागता dump आणि restore आवश्यक असते.

किमान major आवृत्ती निश्चित करा (postgres:16-alpine हे 16.x patch प्रकाशनांचे अनुसरण करते), आणि ॲप्लिकेशन्सना miniflux/miniflux:2.2.9 सारख्या नेमके प्रकाशन निश्चित करा — प्रोजेक्टच्या प्रकाशन पृष्ठावर तपासा आणि तुम्ही फाईल लिहिताना जे वर्तमान आहे ते वापरा. अपग्रेड तेव्हा एक-ओळीचा बदल बनतो जो तुम्ही जाणीवपूर्वक केला, जो git diff मध्ये दिसतो.

127.0.0.1 वर प्रकाशित करा, कारण Docker ufw च्या बाहेरून फिरते

"127.0.0.1:8080:8080" — होस्ट पत्ता, होस्ट पोर्ट, container पोर्ट. बहुतेक ट्यूटोरियल्स "8080:8080" लिहितात, जे 0.0.0.0:8080:8080 चे शॉर्टहँड आहे: प्रत्येक इंटरफेसवर, जनतेच्या इंटरफेससह, ऐकणे.

हा अडथळा आहे, आणि हे जणू कधीतरी प्रत्येकाला त्रास देतेच. Docker एक पोर्ट प्रकाशित करते असे लिहून DNAT नियम लागू करते जे फिल्टरिंगच्या आधी पॅकेटचे गंतव्य container च्या आंतरिक IP ला पुन्हा-लिहिते, म्हणून पॅकेट FORWARD मार्ग घेते आणि कधीच INPUT ला स्पर्श करत नाही, जिथे तुमचे ufw नियम आहेत. sudo ufw deny 8080 यश दर्शवते, ufw status पोर्ट नाकारलेला दर्शवते, आणि सेवा तरीही संपूर्ण इंटरनेटला उत्तर देते. तुमचे फायरवॉल तुटलेले नाही; त्याची रचनाच त्याला वगळण्याची केलेली आहे. Docker ufw का वगळते, आणि container ट्रॅफिक खरोखर कसे फिल्टर करावे यात या यंत्रणेचे आणि सार्वजनिक ठेवावे लागणाऱ्या पोर्टसाठी DOCKER-USER उपायाचे स्पष्टीकरण दिले आहे.

संपूर्ण समस्या नाहीशी करणारी सवय: विशिष्ट कारण नसल्यास प्रकाशित पोर्ट्स 127.0.0.1 ला बांधा, आणि जगासमोर यायचे असलेल्या प्रत्येक गोष्टीसाठी त्यापुढे एक रिव्हर्स प्रॉक्सी ठेवा. तेच ते Traefik रिव्हर्स प्रॉक्सी मार्गदर्शक हे या पानानंतरच्या पुढील पायरी म्हणून तयार करते — एक container जे पोर्ट्स 80 आणि 443 वर ताबा ठेवते आणि hostname नुसार TLS सह बाकी सर्वांना राउट करते. (जुन्या Traefik v2 सेटअपकडून येत आहात? Traefik v2 ते v3 मायग्रेशन मार्गदर्शक हे नावबदल आणि नियम बदल सांगते.)

stack सुरू केल्यानंतर बाइंड तपासा: sudo ss -tlnp | grep 8080 मध्ये 127.0.0.1:8080 दिसायला हवे, 0.0.0.0:8080 किंवा *:8080 नाही.

नाव दिलेले volumes vs bind mounts

db-data:/var/lib/postgresql/data हा एक नाव दिलेला volume आहे: Docker /var/lib/docker/volumes/ अंतर्गत एक डिरेक्टरी तयार करते आणि व्यवस्थापित करते आणि ती container मध्ये माउंट करते. पर्याय म्हणजे bind mount, ./data:/var/lib/postgresql/data, जे तुम्ही होस्टवर निवडलेल्या पथाचा मॅप करते.

व्यवहारात टिकून राहणारे विभाजन: फक्त container स्पर्श करतात अशा डेटासाठी नाव दिलेले volumes — विशेषतः डेटाबेस, कारण Docker volume ला प्रतिमा अपेक्षित मालकीसह प्रारंभ करते आणि फाईल परवानग्या नुसारच काम करतात. तुम्ही होस्टवरून स्पर्श करता अशा फायलींसाठी Bind mounts — कॉन्फिग फायली जो तुम्ही टेक्स्ट एडिटरने संपादित करता, मीडिया लायब्ररी जी तुम्ही rsync करता, अशी कोणतीही गोष्ट जिचा पथ स्पष्ट असावा असे तुम्हाला वाटते. क्लासिक bind-mount अपयश म्हणजे मालकी: container UID 999 म्हणून चालतो, तुमची होस्ट डिरेक्टरी UID 1000 मालकीची आहे, आणि ॲप्लिकेशन स्टार्टअपवर त्याच्या लॉगमध्ये permission denied सह बंद पडते. नाव दिलेले volumes त्या प्रकारचे दोष बहुतांशी गायब करतात, पण त्याच्या बदल्यात डेटा Docker-व्यवस्थापित पथावर राहतो — खाली समाविष्ट आहे.

environment आणि .env — गिटमधून गुप्तता बाहेर ठेवा

${POSTGRES_PASSWORD} तुमच्या शेलमधून वाचले जात नाही; Compose ते compose.yml च्या बाजूला असलेल्या .env नावाच्या फाईलमधून interpolate करते. ती तयार करा:

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 सह वास्तविक मूल्ये तयार करा. हेक्स, base64 नाही, हे जाणीवपूर्वक: हा पासवर्ड DATABASE_URL कनेक्शन स्ट्रिंगमध्ये जातो, आणि base64 तयार करत असलेले /, +, आणि = अक्षरे URL पार्सिंग तोडतात — हा अपयश प्रमाणीकरण त्रुटी म्हणून समोर येतो, वाक्यरचना त्रुटी म्हणून नाही, आणि त्याला एक संध्याकाळ जातो. .gitignore ओळ पहिल्या commit पूर्वी आत जाते: compose फाईल प्रकाशित आणि आवृत्तीबद्ध करण्यास सुरक्षित आहे, .env फाईल कधीच नाही, आणि गिट इतिहासाला स्पर्श केलेली गुप्तता म्हणजे तुम्ही बदलणारी गुप्तता. तुम्ही एक व्हेरिएबल वगळून stack सुरू केल्यास, Compose जोरात इशारा देते आणि रिकाम्या स्ट्रिंगसह पुढे चालते — जे Postgres पासवर्डसाठी एक तुटलेली डिप्लॉयमेंट म्हणजे:

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

docker compose config पूर्ण-interpolate केलेली फाईल प्रिंट करते — containers खरोखर काय मिळवतील हे तपासण्याचा सर्वात जलद मार्ग; लक्षात ठेवा त्याचे आउटपुट तुमच्या गुप्तता समाविष्ट करते.

depends_on कशाचीही वाट बघत नाही — जोपर्यंत तुम्ही healthcheck जोडत नाही

एका साध्या depends_on: [db] मध्ये फक्त सुरूवातीचा क्रम नियंत्रित होतो: Compose प्रथम Postgres सुरू करते आणि ॲप्लिकेशन थोड्या वेळाने, तर Postgres अजूनही कनेक्शन स्वीकारण्यापासून सेकंद दूर असतो. ॲप्लिकेशन डेटाबेसला स्पर्श करते, अपयशी होते, आणि ते किती चांगले लिहिले गेले आहे त्यावर अवलंबून क्रॅश होते किंवा पुन्हा प्रयत्न करते.

विश्वसनीय आवृत्ती तीच आहे जी वरील फाईल वापरते: db सेवा एक healthcheck व्याख्यित करते (Postgres तंतोतंत यासाठी pg_isready पुश करते), आणि ॲप्लिकेशन depends_on सह condition: service_healthy घोषित करते. Compose डेटाबेस सुरू करते, दर 10 सेकंदांनी तपासणी विनंती करते, आणि तपासणी उत्तीर्ण झाल्यावरच Miniflux सुरू करते. डेटाबेस कधीच healthy होत नसेल — चुकीचा पासवर्ड, भ्रष्ट volume — तर ॲप्लिकेशन कधीच सुरू होत नाही आणि Compose तुम्हाला सांगते की कोणती अवलंबित्व अपयशी झाली:

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

तो संदेश तुम्हाला docker compose logs db कडे निर्देश करतो, जिथे वास्तविक त्रुटी आहे.

restart: unless-stopped

दोन्ही सेवांवर restart: unless-stopped म्हणजे containers क्रॅश नंतर आणि VPS रीबूट नंतर परत येतात, पण तुम्ही जाणीवपूर्वक docker compose stop चालवल्यास ते बंद राहतात. पर्यायी always मॅन्युअल स्टॉप नंतरही containers पुनरुज्जीवित करते — तुम्हाला हवे होते असे क्वचितच. restart policy नसल्यास, पहाटे 4 वाजता kernel-update रीबूट शांतपणे तुमच्या सेवा तुम्हाला कळेपर्यंत बंद करतो.

दैनिक क्रिया

दररोजचे सर्व काम हे पाच आदेशांनी होते, ते प्रोजेक्ट डिरेक्टरीतून चालवा.

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 तुम्हाला अॅपमध्ये शेल देते.

तुमचा डेटा प्रत्यक्षात कुठे साठवला जातो

नाव दिलेल्या व्हॉल्युम्सना प्रकल्प प्रीफिक्स मिळते, म्हणून db-data या डिरेक्टरीत miniflux हे miniflux_db-data होते:

docker volume ls
docker volume inspect miniflux_db-data

inspect आउटपुटमध्ये महत्त्वाची ओळ समाविष्ट असते:

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

ती डिरेक्टरी म्हणजे डेटाबेस आहे — होस्ट फाइलसिस्टमवर रूट मालकीची, आणि ती down, अपग्रेड्स आणि कंटेनर रीबिल्ड्स टिकून राहते. तुमच्या बॅकअप्सने नेमके हेच कॅप्चर करणे आवश्यक आहे.

नाव दिलेले व्हॉल्यूम बॅकअप करा

प्रमाणित पद्धत म्हणजे एक तात्पुरता कंटेनर वापरणे, जो व्हॉल्यूम रीड-ओन्ली मोडमध्ये होस्ट डिरेक्टरीसोबत जोडतो आणि नंतर tar कमांड वापरून डेटा कॉपी करतो:

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 डेटा डिरेक्टरीचे tar काढल्यास, लिहिण्याच्या मधोमधची स्थिती कॅप्चर होऊ शकते, जी योग्यरित्या स्टार्ट होणार नाही. एकतर tar प्रक्रिया होत असलेल्या काही सेकंदांसाठी docker compose stop, किंवा — अधिक चांगले म्हणजे — लॉजिकल डम्प घ्या, जो स्वतःच्या रचनेनुसार सुसंगत असतो:

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

-T हा फ्लॅग Compose ने डीफॉल्ट म्हणून दिलेला प्रतिमान टर्मिनल (pseudo-terminal) बंद करतो — TTY मधून डम्प आउटपुट पास केल्यास तो खराब होऊ शकतो. यापैकी एक कमांड cron मध्ये ठेवा आणि निर्माण झालेला फाइल VPS वरून बाहेर कॉपी करा; ज्या डिस्कवर डेटा साठवला आहे, त्याच डिस्कवर ठेवलेला बॅकअप हा फक्त एक कॉपी असतो, खरा बॅकअप नाही. Nextcloud मार्गदर्शक या दोन्ही पद्धतींवर आधारित संपूर्ण शेड्युल्ड दिनचर्या तयार करतो.

अपयशाचे प्रकार, आणि तुम्हाला दिसणाऱ्या स्ट्रिंग्ज

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 स्वच्छ असेल, तर एखादा नॉन-डॉकर प्रोसेस तो पोर्ट धरून ठेवतो: 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

मला "permission denied while trying to connect to the Docker daemon socket" ही त्रुटी का येते?

तुमचा वापरकर्ता 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 आहे, एक स्वतंत्र Python बायनरी जे 2023 मध्ये वापरातून बाहेर झाले आणि नवीन सर्व्हरवर स्थापित करू नये. 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 चा जुळापाडा हा तपासण्याची पहिली गोष्ट आहे.