Ubuntu 24.04 वर Docker Compose कसे वापरावे

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

या साइटवरील जवळजवळ सर्व गोष्टींसाठी Docker Compose हा पाया आहे. Nextcloud, Vaultwarden, n8n, Immich, Rocket.Chat, या प्रत्येक मार्गदर्शिकेची सुरुवात "ही compose फाईल लिहा" अशी होते आणि ही फाईल नक्की काय आहे हे या पानावर स्पष्ट केले आहे. तुम्ही Ubuntu 24.04 वर Docker च्या अधिकृत apt रिपॉझिटरीमधून Docker Engine आणि Compose v2 प्लगइन इंस्टॉल कराल. त्यानंतर, तुम्ही Miniflux (एक छोटा RSS रीडर) आणि PostgreSQL यांचा समावेश असलेला एक दोन-सर्व्हिस स्टॅक तयार कराल. ही जोडी मोठ्या ॲप्समध्ये वापरल्या जाणाऱ्या सर्व पद्धतींचा सराव करून घेते: पिन केलेल्या इमेजेस, हेल्थचेक असलेली डेटाबेस सेवा, नेमड व्हॉल्यूम, .env फाईलमधील सीक्रेट्स आणि फक्त localhost वर पब्लिश केलेले पोर्ट.

हे इंस्टॉलेशन पाच मिनिटांत पूर्ण होते. या मार्गदर्शिकेचा उर्वरित भाग नंतर त्रासदायक ठरू शकणाऱ्या गोष्टींवर लक्ष केंद्रित करतो: docker ग्रुप म्हणजे दुसरे-नाव असलेला root, तुमच्या ufw नियमांना बगल देऊन थेट उघडले जाणारे पोर्ट्स आणि docker compose down वरील तो एक फ्लॅग जो कोणत्याही पुष्टीकरणाशिवाय तुमचा डेटाबेस हटवू शकतो.

पूर्वअटी: एक नवीन Ubuntu 24.04 KVM VPS, sudo अधिकार असलेला युजर आणि किमान एक गिगाबाइट RAM. जर तुमच्याकडे आधीच Docker इंस्टॉल असेल तर तेही चालेल, पहिल्या भागात काय काढून टाकायचे हे सांगितले आहे.

Ubuntu च्या रिपॉझिटरीऐवजी Docker च्या रिपॉझिटरीवरून इन्स्टॉल करा

पहिली कमांड चालवण्यापूर्वी दोन चुकीच्या पद्धती टाळणे आवश्यक आहे. Ubuntu चे स्वतःचे docker.io पॅकेज काम करते, परंतु ते Docker च्या नवीन releases च्या मागे असते आणि त्यात प्लगइन लेआउटचा अभाव असतो, ज्यावर इतर सर्व गोष्टी अवलंबून असतात. तसेच, हायफन असलेले स्वतंत्र docker-compose बायनरी म्हणजे Compose v1 आहे; हे Python वर आधारित असून 2023 पासून बंद (end-of-life) झाले आहे. जुन्या ट्युटोरियल्समधील त्रुटींचे हेच मुख्य कारण आहे. सध्याचे 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 मधील सर्वात जास्त शोधली जाणारी त्रुटी (error) मिळते:

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 चालवू शकते आणि संपूर्ण फाइलसिस्टमची मालकी घेऊ शकते, त्यासाठी कोणताही पासवर्ड विचारला जात नाही. हा ग्रुप सोयीसाठी आहे, सुरक्षिततेसाठी (containment) नाही.

Docker चा rootless mode हा खरा पर्याय आहे, ज्यामध्ये डेमन स्वतः तुमच्या अनप्रिव्हिलेज्ड (unprivileged) युजर म्हणून चालतो. याचे काही तोटे आहेत: 1024 च्या खालील पोर्ट्ससाठी अतिरिक्त सेटअपची गरज लागते, नेटवर्किंग एका युजरस्पेस शिम (userspace shim) द्वारे चालते ज्याचा काही प्रमाणात परफॉर्मन्सवर परिणाम होतो, आणि काही इमेजेस खऱ्या root शिवाय नीट चालत नाहीत. एकाच ॲडमिन असलेल्या VPS वर, जिथे लॉग-इन असलेल्या व्यक्तीकडे आधीच sudo अधिकार आहेत, तिथे ग्रुप बदलल्याने व्यवहारात काहीही फरक पडत नाही. या मार्गदर्शिकेतील सर्व सूचना याच गृहितकावर आधारित आहेत, परंतु हे अधिकार देताना ते sudo पेक्षा कमी आहेत असे कधीही समजू नका.

Compose फाईलची रचना

प्रत्येक स्टॅकसाठी स्वतंत्र डिरेक्टरी ठेवा. डिरेक्टरीचे नाव हेच प्रोजेक्टचे नाव बनते, जे कंटेनर, नेटवर्क आणि व्हॉल्यूमसाठी प्रीफिक्स म्हणून वापरले जाते:

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:

वरील प्रत्येक ओळ हा एक निर्णय आहे. प्रत्येक निर्णयाकडे स्वतंत्रपणे लक्ष द्या.

इमेज व्हर्जन पिन करा, :latest आणि pull म्हणजे अनअटेंडेड अपग्रेड

postgres:16-alpine वापरा, postgres:latest नको. टॅग स्थिर नसतो: प्रत्येक वेळी तुम्ही pull करता तेव्हा :latest हे मेंटेनर्सनी नुकत्याच पुश केलेल्या इमेजवर पुन्हा रिझॉल्व्ह होते. हे आणि तुम्ही शिकणार असलेली नियमित अपग्रेडची सवय, म्हणजेच docker compose pull && docker compose up -d, एकत्र आल्यास :latest मुळे जेव्हा जेव्हा अपस्ट्रीम नवीन व्हर्जन रिलीज करेल, तेव्हा ते आपोआप अपडेट होईल. PostgreSQL च्या बाबतीत हे केवळ गृहितक नाही: अचानक 16 वरून 17 वर अपग्रेड झाल्यामुळे कंटेनर क्रॅश-लूपमध्ये अडकू शकतो, कारण Postgres च्या मोठ्या अपग्रेडसाठी डेटाबेस डंप आणि रिस्टोर करणे आवश्यक असते, केवळ रिस्टार्ट करून चालत नाही.

किमान मेजर व्हर्जन पिन करा (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 मार्गाने जाते आणि कधीही INPUT ला स्पर्श करत नाही, जिथे तुमचे ufw नियम असतात. 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 ने 127.0.0.1:8080 दाखवले पाहिजे, 0.0.0.0:8080 किंवा *:8080 नाही.

नेमड व्हॉल्यूम्स विरुद्ध बाइंड माउंट्स

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

व्यावहारिकदृष्ट्या हे विभाजन लक्षात ठेवा: केवळ कंटेनर ज्या डेटाला स्पर्श करतात, त्यासाठी नेमड व्हॉल्यूम्स वापरा, विशेषतः डेटाबेससाठी, कारण Docker इमेजला अपेक्षित असलेल्या मालकी हक्कांसह (ownership) व्हॉल्यूम इनिशिअलाइज करतो आणि फाईल परमिशन व्यवस्थित काम करतात. होस्टवरून तुम्ही ज्या फाईल्सना स्पर्श करता, त्यासाठी बाइंड माउंट्स वापरा, जसे की तुम्ही टेक्स्ट एडिटरने एडिट केलेल्या कॉन्फिगरेशन फाईल्स किंवा मीडिया लायब्ररी. बाइंड-माउंटमध्ये सहसा मालकी हक्काची (ownership) समस्या येते: कंटेनर 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 ओळ पहिल्या कमिटच्या आधी टाका: compose फाईल पब्लिश करणे सुरक्षित आहे, पण .env फाईल कधीही नाही. जर एखादे सिक्रेट git हिस्ट्रीमध्ये गेले असेल, तर ते सिक्रेट बदलून टाका. जर तुम्ही एखादा व्हेरिएबल न देता स्टॅक सुरू केला, तर Compose जोरात चेतावणी देते आणि रिकाम्या स्ट्रिंगसह पुढे जाते, ज्याचा अर्थ Postgres पासवर्डसाठी डिप्लॉयमेंट अयशस्वी होणे असा होतो:

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

docker compose config पूर्णपणे इंटरपोलेट केलेली फाईल प्रिंट करते, कंटेनरला नक्की काय मिळेल हे तपासण्याचा हा सर्वात जलद मार्ग आहे; लक्षात ठेवा की याच्या आउटपुटमध्ये तुमचे सिक्रेट्स समाविष्ट असतात.

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

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

विश्वासार्ह आवृत्ती म्हणजे वरील फाईलमध्ये वापरलेली पद्धत: db सर्व्हिस एक healthcheck डिफाइन करते (Postgres यासाठी 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 वाजता होणारा कर्नल-अपडेट रिबूट तुमच्या सेवा शांतपणे बंद करेल, जोपर्यंत तुम्ही ते स्वतः पाहत नाही.

दैनंदिन क्रिया

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

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 कमांड नामनिर्देशित व्हॉल्यूम्सना देखील हटवते. तुमचा डेटाबेस त्वरित नष्ट होतो, यासाठी कोणतीही खात्री विचारली जात नाही आणि पूर्ववत (undo) करण्याचा पर्याय नसतो. -v फ्लॅगचा वापर प्रयोगात्मक सेटअप काढून टाकण्यासाठी केला जातो; प्रत्यक्ष डेटा असलेल्या स्टॅकवर काम करताना, याला rm -rf प्रमाणेच हाताळा. /var/lib/docker/volumes/ मध्ये कोणतीही 'ट्रॅश कॅन' नसते.

चालू असलेल्या कंटेनरमध्ये वन-ऑफ शेल मिळवण्यासाठी: docker compose exec db psql -U miniflux तुम्हाला डेटाबेसमध्ये प्रवेश देते आणि docker compose exec miniflux sh तुम्हाला ॲपमध्ये शेल मिळवून देते.

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

Named volumes ला प्रोजेक्टचा उपसर्ग (prefix) लागतो, त्यामुळे 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"

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

named volume चा बॅकअप घेणे

यासाठी एक सामान्य पद्धत म्हणजे एक तात्पुरता (throwaway) कंटेनर वापरणे, जो volume ला read-only मोडमध्ये होस्ट डिरेक्टरीसोबत माउंट करतो आणि 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 .

यामध्ये कशाचीही स्थापना (install) करावी लागत नाही, कोणतीही सेवा बॅकग्राउंडला चालू राहत नाही आणि रिस्टोर करण्याची प्रक्रिया अगदी उलट असते, जिथे tar xzf वापरून रिकाम्या volume मध्ये डेटा पुन्हा लिहिला जातो.

डेटाबेससाठी एक महत्त्वाची सूचना: चालू असलेल्या Postgres डेटा डिरेक्टरीचा tar घेतल्यास तो अर्धवट लिहिलेल्या (mid-write) स्थितीत असू शकतो, ज्यामुळे डेटाबेस पुन्हा सुरू होताना समस्या येऊ शकते. यासाठी एकतर tar प्रक्रिया सुरू असताना docker compose stop वापरा, किंवा त्यापेक्षा उत्तम पर्याय म्हणजे logical dump घेणे, जो नेहमी सुसंगत (consistent) असतो:

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

येथील -T हा फ्लॅग Compose द्वारे डीफॉल्टनुसार मिळणारा pseudo-terminal बंद करतो, कारण dump आउटपुट TTY मधून पाइप केल्यास ते खराब (corrupt) होऊ शकते. यापैकी एक कमांड 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?, ही एक वेगळी समस्या आहे: daemon स्वतः बंद आहे. 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 फॉरमॅटमध्ये असतात: दोन-स्पेस इंडेंटेशन वापरा, फक्त स्पेस वापरा आणि टॅब कॅरेक्टर वापरल्यास एरर येते. docker compose config कोणतीही सेवा सुरू न करता फाइलची वैधता तपासते, प्रत्येक बदलांनंतर ही कमांड चालवणे ही एक चांगली सवय आहे.

ufw सरप्राईज मध्ये कोणतीही एरर दिसत नाही, ज्यामुळे हे धोकादायक ठरते: डिप्लॉयमेंट यशस्वी होते, ufw status बरोबर दिसते, तरीही बाहेरून पोर्ट स्कॅन केल्यास तुमचा डेटाबेस उघड दिसतो. वरील पोर्ट्स विभाग पुन्हा वाचा, प्रत्येक ports: एन्ट्रीमध्ये 127.0.0.1: प्रीफिक्स आहे का ते तपासा आणि दुसऱ्या मशीनवरून curl http://your-vps-ip:8080 वापरून खात्री करा, 'connection refused' हाच अपेक्षित प्रतिसाद आहे.

येथून, Traefik मार्गदर्शक या सिंगल स्टॅकचे रूपांतर एका HTTPS एन्ट्री पॉईंटमागील अनेक ॲप्समध्ये करते, आणि 2026 मध्ये काय self-host करावे ही त्याद्वारे चालवण्यासाठी उपयुक्त साधनांची यादी आहे. जेव्हा असे अनेक स्टॅक्स चालू होतात आणि प्रत्येकाचे स्वतःचे लॉगिन फॉर्म असतात, तेव्हा Authentik सारखा self-hosted SSO सर्व्हर त्या सर्वांना एकाच प्रॉक्सीमागील एका खात्यात एकत्रित करतो.

VPS वरील Minecraft server सारखा game server हा पहिल्या Compose project साठी सराव करण्यास योग्य पर्याय आहे. तुम्ही दररोज उघडता अशा सेवेसह शिकणे पसंत करत असाल, तर openGym, self-hosted workout tracker हा image tag ऐवजी git tag ला pinned असलेला छोटा stack आहे. पहिला passkey register करण्यापूर्वी त्यासमोर TLS आवश्यक आहे. स्वतःच्या cloud मधून परत आणायची इच्छा असलेली पहिली गोष्ट बहुतेकदा photos असतात. PhotoPrism आणि Immich ची तुलना केल्यास एखाद्या volume साठी commit करण्यापूर्वी आवश्यक RAM आणि backup routine स्पष्ट होते. दोन services अपुऱ्या वाटू लागल्यावर, Notion-style workspace म्हणून AFFiNE उभारणे हे चार containers मध्ये त्याच patterns चा वापर करते. वरील pinned tags, healthchecks आणि named volumes आता सवयीत आले आहेत का, याची ही योग्य चाचणी आहे.

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 डेटा डिलीट करत नाही, ते फक्त कंटेनर आणि प्रोजेक्ट नेटवर्क काढून टाकते; named volumes सुरक्षित राहतात आणि पुढील up -d त्यांना पुन्हा जोडते. docker compose down -v हे विनाशकारी स्वरूप आहे: ते named volumes डिलीट करते, म्हणजेच तुमचा डेटाबेस कायमचा नष्ट होतो, ज्यासाठी कोणतीही पुष्टी विचारली जात नाही किंवा ती कृती मागे घेता येत नाही. जर तुमच्याकडे पडताळणी केलेला बॅकअप नसेल, तर प्रत्यक्ष डेटा असलेल्या स्टॅकवर कधीही -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 मार्गाने जातात. त्यामुळे ते कधीही INPUT चेनपर्यंत पोहोचत नाहीत जिथे ufw चे नियम लागू होतात. म्हणूनच, प्रकाशित कंटेनर पोर्टवर ufw deny 8080 चा काहीही परिणाम होत नाही. हे मूळातून दुरुस्त करा: पोर्ट्सना 127.0.0.1: वर प्रकाशित करा आणि सेवांना reverse proxy द्वारे उपलब्ध करून द्या.

मी named volume वापरावे की bind mount?

केवळ कंटेनर ज्या डेटाचा वापर करतो, विशेषतः डेटाबेससाठी, named volumes वापरा; कारण Docker इमेजला अपेक्षित असलेली मालकी (ownership) आणि परवानग्या आपोआप सेट करते. ज्या फाईल्स तुम्ही होस्टवरून हाताळता, जसे की तुम्ही एडिट करत असलेल्या कॉन्फिगरेशन फाईल्स, अपलोड केलेले मीडिया किंवा ज्यांचा पाथ तुम्हाला स्पष्ट हवा आहे, अशा गोष्टींसाठी bind mounts वापरा. जर एखादा कंटेनर bind mount वर permission denied त्रुटीमुळे सुरू होत नसेल, तर होस्ट आणि कंटेनरमधील UID मधील विसंगती (mismatch) ही पहिली तपासणी असावी.