VPS वर Docker वापरताना येणाऱ्या समस्या आणि उपाय

VPS वर Docker चालवताना काय बदलते

VPS वर चालणारे Docker हे तुमच्या लॅपटॉपवरील Docker प्रमाणेच इंजिन आणि इमेजेस वापरते, त्यामुळे तुम्हाला माहित असलेल्या सर्व कमांड्स तिथेही काम करतात. बदल होतो तो त्याच्या सभोवतालच्या वातावरणात. लॅपटॉपमध्ये अतिरिक्त मेमरी असते, असा फायरवॉल असतो ज्याला कोणीही स्कॅन करत नाही आणि डिस्क इतकी मोठी असते की तुम्हाला तिची काळजी करण्याची गरज नसते. भाड्याने घेतलेल्या सर्व्हरमध्ये मेमरीची मर्यादा निश्चित असते, एक पब्लिक IP ॲड्रेस असतो जो बूट झाल्यानंतर काही मिनिटांतच स्कॅन केला जातो आणि एक root फाइलसिस्टम असते जी Docker विचार न करता भरून टाकते.

लहान सर्व्हरवर खालील चार फरकांमुळे बहुतेक समस्या उद्भवतात:

• मेमरी मर्यादित असते आणि कमतरता भासल्यास कर्नल एखादी प्रोसेस बंद (kill) करून ती भरून काढते.
• पब्लिश केलेला पोर्ट थेट UFW (uncomplicated firewall) मधून जातो, कारण Docker स्वतःचे फायरवॉल नियम स्वतः लिहिते.
• जोपर्यंत तुम्ही आधीच तशी सूचना दिली नसेल, तोपर्यंत रीबूटनंतर कंटेनर आपोआप सुरू होत नाहीत.
• इमेजेस, कंटेनर, व्हॉल्यूम्स आणि बिल्ड कॅशे डिस्क पूर्ण भरेपर्यंत वाढत राहतात.

खालील प्रत्येक विभागात त्रुटीचे नाव, तुम्हाला दिसणारी नेमकी स्ट्रिंग आणि ती सविस्तरपणे सोडवण्यासाठी मार्गदर्शक दिले आहे. जर तुम्ही अजून compose फाइल लिहिली नसेल, तर आधी Docker Compose basics on a VPS वाचा आणि मग परत या. हे पान असे गृहीत धरते की तुम्ही आधीच एक स्टॅक सुरू करण्यास सक्षम आहात.

Docker कंटेनर किती RAM वापरतो?

बहुतेक लोकांच्या अपेक्षेपेक्षा खूप कमी. कंटेनर हे cgroup (control group) मधील एक process असते, virtual machine नसते. त्यामुळे यात guest kernel किंवा निश्चित मेमरी वाटप (fixed allocation) नसते. कंटेनरचा मेमरी वापर त्यातील process किती मेमरी वापरते यावर अवलंबून असतो. म्हणूनच, virtual machines वापरून जेवढी मेमरी लागते, त्यापेक्षा कमी मेमरीमध्ये पूर्ण stack 2 GB मध्ये मावू शकतो.

खालील आकडेवारी Ubuntu 24.04 वरील stock images साठी, default configuration सह, सुरू झाल्यानंतर काही मिनिटांनी docker stats द्वारे घेतलेली आहे. ही आकडेवारी नियोजनासाठी एक सुरुवात आहे, तुमच्या कामाच्या स्वरूपाचे (workload) बेंचमार्क नाही. कोणत्याही आकड्यावर विश्वास ठेवण्यापूर्वी तुमच्या स्वतःच्या सर्व्हरवर docker stats --no-stream चालवून पहा.

[
  {
    "label": "nginx",
    "idle_mb": 8,
    "budget_mb": 64
  },
  {
    "label": "Redis 7",
    "idle_mb": 12,
    "budget_mb": 128
  },
  {
    "label": "Traefik v3",
    "idle_mb": 40,
    "budget_mb": 128
  },
  {
    "label": "PostgreSQL 16",
    "idle_mb": 45,
    "budget_mb": 512
  },
  {
    "label": "Uptime Kuma",
    "idle_mb": 95,
    "budget_mb": 256
  },
  {
    "label": "MariaDB 11",
    "idle_mb": 190,
    "budget_mb": 512
  },
  {
    "label": "Nextcloud (Apache)",
    "idle_mb": 210,
    "budget_mb": 768
  }
]

हे दोन स्तंभ वेगवेगळी कामे करतात. idle_mb म्हणजे कंटेनर काहीही काम करत नसताना वापरत असलेली मेमरी. budget_mb म्हणजे नियोजन करताना राखून ठेवायची मेमरी, कारण प्रत्यक्ष वापरामध्ये कंटेनर रिकामी नसतो. PostgreSQL साधारण 45 MB वर idle राहते, पण connections, sorts आणि cache सक्रिय झाल्यावर त्याला 512 MB ची गरज लागते. नियोजनासाठी budget स्तंभाचा वापर करा. त्रुटी शोधण्यासाठी (debug) idle स्तंभाचा वापर करा.

7 ओळींचे स्वरूप पहा. nginx 8 MB वर आणि Nextcloud 210 MB वर idle राहते. तुमच्या ॲप्लिकेशन्सच्या समोर असलेला proxy जवळजवळ मोफतच काम करतो. सर्व्हरचा आकार ठरवताना database आणि PHP ॲप्लिकेशनचा विचार करणे महत्त्वाचे असते.

docker stats बद्दल एक सूचना: मेमरीच्या आकड्यामध्ये कंटेनरने वाचलेल्या फाईल्सचा page cache देखील समाविष्ट असतो. त्यामुळे सुरू झाल्यानंतर काही काळ हा आकडा वाढतो आणि नंतर स्थिर होतो. काहीतरी मेमरी लीक होत आहे असे ठरवण्यापूर्वी किमान एक तास त्याचे निरीक्षण करा.

VPS चा आकार ठरवणे: 2 GB, 4 GB आणि 8 GB मध्ये काय मावते

सर्वात आधी होस्टचा हिस्सा वजा करा. कर्नल, systemd, journald, sshd आणि Docker daemon हे सर्व त्याच RAM मध्ये राहतात जिथे तुमचे कंटेनर असतात, आणि dockerd सह containerd त्यातील सुमारे 100 MB जागा व्यापतात. तुम्हाला पेज कॅशेसाठी आणि इमेज बिल्ड किंवा डेटाबेस डंप चालताना लागणाऱ्या अतिरिक्त मेमरीसाठी (spike) मोकळी जागा ठेवणे आवश्यक आहे.

[
  {
    "plan": "2 GB VPS",
    "total_mb": 2048,
    "host_reserve_mb": 768,
    "container_mb": 1280
  },
  {
    "plan": "4 GB VPS",
    "total_mb": 4096,
    "host_reserve_mb": 1024,
    "container_mb": 3072
  },
  {
    "plan": "8 GB VPS",
    "total_mb": 8192,
    "host_reserve_mb": 1536,
    "container_mb": 6656
  }
]

host_reserve_mb मध्ये ऑपरेटिंग सिस्टम, Docker daemon आणि लोड असताना सर्व्हरची कार्यक्षमता टिकवून ठेवणारी अतिरिक्त मेमरी (headroom) समाविष्ट असते. जे उरते ती container_mb असते आणि तीच मेमरी तुम्ही प्रत्यक्ष वापरू शकता. हा राखीव साठा प्लॅननुसार वाढत जातो, लहान बॉक्ससाठी 768 MB पासून मोठ्या बॉक्ससाठी 1536 MB पर्यंत, कारण मोठा बॉक्स जास्त कंटेनर चालवतो, जास्त लॉग्स लिहितो आणि त्याला अधिक पेज कॅशेची गरज असते.

2 GB चा प्लॅन कंटेनरसाठी 1280 MB जागा शिल्लक ठेवतो. त्यातील 512 MB PostgreSQL साठी आणि 128 MB Traefik साठी वापरले, तर अर्धी मेमरी संपते. उरलेल्या मेमरीमध्ये प्रत्येकी सुमारे 256 MB ची दोन छोटी ॲप्लिकेशन्स चालू शकतात. हा एक वास्तववादी आणि उपयुक्त सर्व्हर आहे. यामध्ये Nextcloud आणि सर्च क्लस्टर एकाच वेळी चालवण्यासाठी पुरेशी जागा नसते.

4 GB चा प्लॅन 3072 MB जागा शिल्लक ठेवतो, जिथे डेटाबेस, रिव्हर्स प्रॉक्सी, तीन ॲप्लिकेशन्स आणि एक मॉनिटरिंग कंटेनर हे सर्व एकाच वेळी मावू शकतात. महत्त्वाच्या कामांसाठी हा सर्वात लहान आकाराचा सर्व्हर आहे, कारण अतिरिक्त मेमरीमुळे चुकीच्या डिप्लॉयमेंटचा फटका बसत नाही.

8 GB चा प्लॅन त्याच्या 8192 MB पैकी 6656 MB जागा शिल्लक ठेवतो आणि अशा वेळी मर्यादा सहसा मेमरीकडून CPU किंवा डिस्क थ्रूपुटवर सरकते. काही कंटेनर लोडनुसार नाही तर त्यांच्या कॉन्फिगरेशननुसार मेमरी घेतात: उदाहरणार्थ, लोकल मॉडेल सर्व्हर त्याच्या कॉन्टेक्स्ट विंडोच्या प्रमाणात KV कॅशे राखून ठेवतो, त्यामुळे Ollama ची num_ctx वाढवणे एकही विनंती येण्याआधीच बजेटमध्ये काही GB ची भर घालू शकते. जर गणितानुसार तुमचा स्टॅक बसत नसेल, तर ट्युनिंग करण्याऐवजी मोठा प्लॅन घ्या: VPS चा प्रत्यक्ष खर्च यामध्ये अतिरिक्त GB चे मासिक मूल्य स्पष्ट केले आहे.

दोन नियम गणिताची अचूकता राखतात. प्रत्येक सर्व्हिसवर मेमरी मर्यादा (memory limit) सेट करा, जेणेकरून एखादी अनियंत्रित प्रोसेस संपूर्ण सर्व्हरला पाडू शकणार नाही. आणि बजेटमधील काही भाग न वापरता शिल्लक ठेवा, कारण docker compose build आणि pg_dump या दोन्ही गोष्टींना सर्वात कठीण प्रसंगी मेमरीची गरज असते. Docker Compose मधील मेमरी मर्यादा यामध्ये याचे सिंटॅक्स आणि धोके दिले आहेत.

माझा कंटेनर exit code 137 सह का बंद होतो?

कारण कर्नलने त्याला बंद केले आहे. 137 म्हणजे 128 अधिक 9, आणि signal 9 म्हणजे SIGKILL. कंटेनरने त्याला दिलेल्या मर्यादेपेक्षा जास्त मेमरीची मागणी केली आणि out of memory (OOM) killer ने त्याला बंद केले.

CONTAINER ID   IMAGE         STATUS
9f2c1a4d7b3e   postgres:16   Exited (137) 4 minutes ago

अंदाज लावण्याऐवजी कारणाची खात्री करा:

docker inspect my-db | grep -i oomkilled
sudo journalctl -k | grep -i "out of memory"

"OOMKilled": true चा अर्थ असा आहे की कंटेनरने त्याच्या स्वतःच्या cgroup मर्यादेला गाठले आहे, आणि कर्नल लॉगमध्ये त्याने निवडलेल्या प्रक्रियेचे नाव दिसते:

Memory cgroup out of memory: Killed process 2417 (postgres) total-vm:1284416kB

ही चांगली स्थिती आहे, कारण नुकसान फक्त एका कंटेनरपुरते मर्यादित राहिले. वाईट स्थिती म्हणजे अशी, जिथे कंटेनरवर कोणतीही मर्यादा नसते. मर्यादेशिवाय त्याची कमाल क्षमता संपूर्ण मशीनइतकी असते, त्यामुळे एका सेवेतील मेमरी लीक संपूर्ण होस्टला अडचणीत आणते आणि कर्नल संपूर्ण सिस्टममधून आकाराच्या आधारावर कोणा एकाला बळी म्हणून निवडते. लॉग लाईनवरून Memory cgroup हा उपसर्ग निघून जातो आणि तिथे Out of memory: Killed process 2417 (postgres) असे दिसते. कर्नल अनेकदा तुमच्या डेटाबेसची निवड करते, तर ज्या कंटेनरमध्ये लीक आहे तो चालूच राहतो. म्हणूनच कोणत्याही एका मर्यादेच्या अचूक मूल्यापेक्षा प्रत्येक सेवेवर मर्यादा असणे अधिक महत्त्वाचे आहे.

Swap मुळे वेळेत बदल होतो, गणितात नाही. बहुतेक VPS इमेजेसमध्ये swap नसते. swapon --show ने तपासा, जर swap नसेल तर ते काहीही आउटपुट देत नाही. Swap फाईल कर्नलला 'cold pages' ठेवण्यासाठी जागा देते, ज्यामुळे तुम्हाला समस्या लक्षात येण्यासाठी काही मिनिटांचा वेळ मिळतो.

sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab
free -h

free -h मध्ये आता Swap ओळीत शून्य नसलेली एकूण संख्या दिसली पाहिजे. Swap मुळे RAM वाढत नाही. सतत मेमरीच्या दबावाखाली असलेले मशीन इतके संथ होते की तुम्ही SSH करून ती समस्या सोडवू शकत नाही, म्हणून swap ला एक 'अलार्म बफर' समजा आणि मेमरीचे आकारमान नीट निश्चित करा.

UFW माझे पब्लिश केलेले Docker पोर्ट का ब्लॉक करत नाही?

कारण हे ट्रॅफिक UFW ज्या साखळीचे (chain) रक्षण करते, तिथे कधीच पोहोचत नाही. जेव्हा तुम्ही -p 5432:5432 किंवा compose मधील ports: एन्ट्री वापरून पोर्ट पब्लिश करता, तेव्हा Docker डेमन nat टेबलमध्ये एक DNAT (destination network address translation) नियम आणि स्वतःच्या DOCKER साखळीमध्ये एक accept नियम लिहितो. कंटेनरसाठी आलेले पॅकेट होस्टला न देता थेट त्या कंटेनरकडे फॉरवर्ड केले जाते. त्यामुळे ते FORWARD पाथमध्ये हाताळले जाते आणि UFW ने लिहिलेल्या INPUT नियमांमधून कधीच जात नाही.

तुम्ही सर्व्हरवर हे घडताना पाहू शकता:

sudo ufw status | grep 5432
sudo iptables -t nat -L DOCKER -n | grep 5432

UFW मध्ये 5432 DENY IN Anywhere दिसत असतानाही nat टेबलमध्ये त्याच पोर्टसाठी DNAT tcp ... to:172.18.0.2:5432 नियम असू शकतो. दुसऱ्या मशीनवरून nc -vz your.server.ip 5432 केल्यास कनेक्शन अजूनही यशस्वी होते. डेटाबेस सार्वजनिक इंटरनेटवर उघडा असतो आणि फायरवॉलच्या मते तो सुरक्षित असतो.

यावर उपाय म्हणजे कमी पोर्ट पब्लिश करणे. एकाच compose प्रोजेक्टमधील कंटेनर एक नेटवर्क शेअर करतात आणि सर्व्हिस नावावरून एकमेकांशी संपर्क साधू शकतात. त्यामुळे जो डेटाबेस फक्त त्याच्या शेजारील ॲप्लिकेशनला सेवा देतो, त्याला कोणत्याही ports: एन्ट्रीची गरज नसते. जेव्हा तुम्हाला स्थानिक ॲक्सेस हवा असेल, तेव्हा पब्लिशिंग loopback वर बाइंड करा:

services:
  db:
    image: postgres:16
    ports:
      - "127.0.0.1:5432:5432"

docker compose up -d नंतर, बाहेरून येणारे nc -vz your.server.ip 5432 अयशस्वी होते आणि सर्व्हरवरील psql -h 127.0.0.1 -p 5432 अजूनही काम करते. एका सुव्यवस्थित छोट्या स्टॅकमध्ये फक्त रिव्हर्स प्रॉक्सी 80 आणि 443 पोर्टवर सेवा पब्लिश करते. Docker पब्लिश केलेले पोर्ट UFW ला का बायपास करतात या लेखात DOCKER-USER साखळीबद्दल माहिती दिली आहे, जी अशा वेळी उपयुक्त ठरते जेव्हा तुम्हाला पोर्ट पब्लिश करणे अनिवार्य असते आणि तरीही ते फिल्टर करायचे असते. तसेच UFW फायरवॉलची मूलभूत माहिती या लेखात होस्ट नियमांची माहिती दिली आहे.

रीबूटनंतर माझे कंटेनर्स का गायब होतात?

कारण त्यांना पुन्हा सुरू होण्यास कोणीही सांगितलेले नसते. जोपर्यंत तुम्ही एखादे धोरण (policy) सेट करत नाही, तोपर्यंत कंटेनर no या डिफॉल्ट रिस्टार्ट पॉलिसीसह तयार होतो, त्यामुळे रीबूटनंतर तो थांबलेलाच राहतो आणि Docker daemon त्याकडे लक्ष देत नाही. VPS वर रीबूट होणे ही दुर्मिळ गोष्ट नाही: unattended upgrades मुळे होणारे kernel updates, सर्व्हर प्रोव्हायडरची देखभाल आणि वर नमूद केलेली OOM sequence या सर्वांचा शेवट रीबूटमध्येच होतो.

दोन गोष्टींची पूर्तता होणे आवश्यक आहे. बूट होताना daemon सुरू झाला पाहिजे:

systemctl is-enabled docker

हे कमांड स्टँडर्ड Ubuntu इन्स्टॉलवर enabled असे आउटपुट देते. त्यानंतर प्रत्येक सेवेसाठी एक पॉलिसी असणे आवश्यक आहे:

services:
  app:
    image: ghcr.io/example/app:1.4
    restart: unless-stopped

unless-stopped हे रीबूटनंतर कंटेनरला पुन्हा सुरू करते आणि तुम्ही मुद्दाम थांबवलेल्या कंटेनरचा मान राखते. always हे तुम्ही मुद्दाम थांबवलेले कंटेनर देखील daemon रीस्टार्ट होताच पुन्हा सुरू करते, जे डीबगिंग करताना अनपेक्षित ठरू शकते. फक्त फाईल एडिट करणे पुरेसे नाही, कारण रिस्टार्ट पॉलिसी कंटेनर तयार करतानाच सेट केली जाते. कंटेनर पुन्हा तयार करण्यासाठी docker compose up -d रन करा आणि त्यानंतर त्याची सध्याची व्हॅल्यू तपासा:

docker inspect my-app | grep -A3 RestartPolicy

त्यानंतर सर्व्हर मुद्दाम रीबूट करा आणि प्रोजेक्ट डिरेक्टरीमध्ये docker compose ps रन करा. जो स्टॅक नियोजित रीबूटनंतर टिकतो, तो अनियोजित रीबूटनंतरही टिकतो. जर तुमच्या स्टॅकला बूट होताना विशिष्ट क्रमाने सुरू होण्याची गरज असेल किंवा एकदाच चालवायचे काम (one-shot job) असेल, तर systemd unit हे अधिक चांगले साधन आहे: starting Docker Compose on boot मध्ये युनिट फाईल दिली आहे. पुन्हा सुरू झालेला कंटेनर खरोखर सेवा देत आहे की नाही हे जाणून घेण्यासाठी, Compose healthchecks चा वापर करा.

माझ्या VPS ची डिस्क पूर्ण का भरली आहे?

कारण जोपर्यंत तुम्ही सांगत नाही, तोपर्यंत Docker सर्व काही साठवून ठेवते. तुम्ही पुल (pull) केलेली प्रत्येक इमेज टॅग, थांबवलेले प्रत्येक कंटेनर, पुन्हा तयार केल्यामुळे (recreate) मागे राहिलेले प्रत्येक अनामिक व्हॉल्यूम आणि बिल्ड कॅशेचे प्रत्येक लेयर डिस्कवर तसेच राहते. 40 GB किंवा 80 GB च्या रूट फाइलसिस्टमवर, जे या प्लॅनच्या आकारानुसार सामान्य आहे, हे काही वर्षांऐवजी काही महिन्यांतच सर्व्हर बंद पडण्याचे (outage) कारण बनते.

डिस्क पूर्ण भरल्यामुळे सर्व्हर क्रॅश झाल्यासारखे वाटत नाही. तुम्हाला त्याच तासात कंटेनरकडून no space left on device, apt कडून, journald कडून आणि docker pull कडून एरर मिळतात. PostgreSQL डेटा लिहिणे थांबवते. सर्व्हर चालूच असतो, ज्यामुळे रीबूट लूपपेक्षा हे ओळखणे अधिक कठीण होते.

डिलीट करण्यापूर्वी तपासा:

docker system df
df -h /

docker system df एकूण जागा इमेजेस, कंटेनर, स्थानिक व्हॉल्यूम्स आणि बिल्ड कॅशेमध्ये विभागते, ज्याच्या बाजूला RECLAIMABLE कॉलम असतो. जो सर्व्हर स्वतःच्या इमेजेस बिल्ड करतो, तिथे बिल्ड कॅशे सहसा सर्वात मोठी जागा व्यापते.

docker image prune -a
docker builder prune
docker system df

docker image prune -a अशी प्रत्येक इमेज काढून टाकते जी कोणताही कंटेनर वापरत नाही. docker builder prune बिल्ड कॅशे साफ करते. सेवा चालू असताना या दोन्ही क्रिया सुरक्षित आहेत, कारण वापरात असलेली कोणतीही गोष्ट वगळली जाते. docker system prune --volumes सुरक्षित नाही, कारण ते असे प्रत्येक व्हॉल्यूम डिलीट करते ज्याचा सध्या कोणताही कंटेनर संदर्भ देत नाही. तुम्ही विकेंडसाठी थांबवलेली स्टॅक नेमकी याच स्थितीत असते आणि तिचे डेटाबेस व्हॉल्यूम त्यासोबत डिलीट होते. हा फ्लॅग वापरण्यापूर्वी bind mounts versus named volumes वाचा आणि आधी बॅकअप घ्या.

कंटेनर लॉग्स ही शांतपणे वाढणारी समस्या आहे. डीफॉल्ट json-file ड्रायव्हरला आकाराची कोणतीही मर्यादा नसते, त्यामुळे एक जास्त लॉग लिहिणारा कंटेनर /var/lib/docker/containers मध्ये अनेक GB डेटा लिहितो. /etc/docker/daemon.json मध्ये प्रत्येक कंटेनरसाठी याची मर्यादा निश्चित करा:

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  }
}

हे sudo systemctl restart docker वापरून लागू करा, ज्यामुळे तुमचे कंटेनर रीस्टार्ट होतात, म्हणून योग्य वेळ निवडा. ही मर्यादा बदल केल्यानंतर तयार केलेल्या कंटेनरना लागू होते, म्हणून चालू असलेले कंटेनर docker compose up -d --force-recreate ने पुन्हा तयार करा आणि खात्री करा:

docker inspect my-app | grep -A5 LogConfig
sudo du -sh /var/lib/docker/containers

inspect आउटपुटमध्ये max-size सेट केलेले दिसले पाहिजे. जर ते रिकामे असेल, तर तो कंटेनर बदलापूर्वीचा आहे आणि अजूनही मर्यादेशिवाय डेटा लिहित आहे.

लहान Docker सर्व्हर सुस्थितीत ठेवण्याच्या सवयी

यासाठी कोणत्याही डॅशबोर्डची किंवा नवीन टूल शिकण्याची गरज नाही.

• महिन्याच्या पहिल्या तारखेला docker system df आणि df -h / चालवा. केवळ दोन कमांड्स आणि तीस सेकंदांचा वेळ, ज्यामुळे सर्व्हर बंद पडण्यापूर्वीच तुम्हाला कल (trend) लक्षात येईल.
• प्रत्येक सर्व्हिसला मेमरी लिमिट सेट करा, अगदी लहान वाटणाऱ्या सर्व्हिसेसना सुद्धा. या लिमिटमुळे संपूर्ण सर्व्हर बंद पडण्याऐवजी फक्त संबंधित कंटेनर रीस्टार्ट होतो.
• सर्व्हरवर बाहेरून लक्ष ठेवा, जेणेकरून कर्नलने कारवाई करण्यापूर्वीच तुम्हाला मेमरी किंवा डिस्कवरील ताणाबद्दल माहिती मिळेल. Uptime Kuma एका कंटेनरमध्ये चालते आणि साधारण 95 MB मेमरी वापरते.
• कंटेनरचा नाही, तर व्हॉल्यूम्सचा बॅकअप घ्या. कंटेनर कधीही पुन्हा तयार करता येतो, पण व्हॉल्यूम नाही. restic backups on a VPS मध्ये बॅकअपचे वेळापत्रक आणि रिस्टोर चाचणी कशी करावी, हे दिले आहे.
• compose फाईलमध्ये इमेज टॅग्स पिन करा आणि तुमच्या सोयीच्या दिवशी ते अपडेट करा. latest वापरल्यास, पुढच्या docker compose pull वेळी तुम्हाला कोणतीही नवीन आवृत्ती मिळू शकते जी त्या दिवशी सकाळीच रिलीज झाली असेल.

जेव्हा मेमरी बजेट, पब्लिश केलेल्या पोर्ट्सची यादी, प्रत्येक सर्व्हिसचे रीस्टार्ट धोरण आणि मोकळी डिस्क हे चार घटक मर्यादेत असतात, तेव्हा Docker चालवणारा लहान VPS वर्षानुवर्षे सुस्थितीत राहतो. बाकी सर्व गोष्टी तुम्ही घरी वापरता तशाच Docker च्या आहेत.

FAQ

Docker VPS वर चालवण्यासाठी मला किती RAM ची आवश्यकता आहे?

Docker स्वतः खूप कमी मेमरी वापरते. daemon आणि containerd मिळून साधारण 100 MB मेमरी घेतात, उर्वरित गरज तुमच्या कंटेनर्सवर अवलंबून असते. आधी होस्टसाठी मेमरी राखून ठेवा: 2048 MB च्या सर्व्हरवर ऑपरेटिंग सिस्टम, daemon आणि इतर गरजांसाठी 768 MB बाजूला ठेवा, ज्यामुळे तुमच्याकडे 1280 MB मेमरी उपलब्ध राहील. 512 MB चा डेटाबेस, 128 MB चा रिव्हर्स प्रॉक्सी आणि दोन लहान ॲप्लिकेशन्स यामध्ये सहज बसू शकतात. कोणत्याही प्रकाशित आकड्यांवर विश्वास ठेवण्यापेक्षा docker stats --no-stream वापरून तुमच्या स्वतःच्या स्टॅकची मेमरी वापराची मोजणी करा.

मी 1 GB च्या VPS वर Docker चालवू शकतो का?

हो, एक किंवा दोन हलक्या कंटेनर्ससाठी हे शक्य आहे, पण सुरुवात करण्यापूर्वी swap file तयार करा. 1 GB च्या सर्व्हरवर ऑपरेटिंग सिस्टम आणि Docker daemon सुरू झाल्यावर साधारण अर्धी मेमरी संपते. त्यामुळे एक लहान ॲप्लिकेशन आणि रिव्हर्स प्रॉक्सीसाठी जागा उरते, पण मोठ्या लोडखालील डेटाबेससाठी ती पुरेशी नाही. अशा आकाराच्या सर्व्हरवर इमेज बिल्ड केल्यास ती अपयशी ठरेल किंवा इतर प्रक्रिया बंद पडतील, त्यामुळे इमेज दुसऱ्या ठिकाणी बिल्ड करून ती pull करा.

UFW Docker कंटेनरचे संरक्षण करते का?

तुम्ही पब्लिश केलेल्या पोर्ट्ससाठी नाही. Docker स्वतःचे DNAT आणि forward नियम तयार करते, त्यामुळे पब्लिश केलेल्या कंटेनर पोर्टवर येणारी पॅकेट थेट कंटेनरकडे पाठवली जातात. ती होस्टकडे येत नाहीत, त्यामुळे UFW चे INPUT नियम त्यांना रोखू शकत नाहीत. जरी ufw deny 5432 सक्रिय असले, तरी ते पोर्ट इंटरनेटवरून उघडे राहू शकते. पोर्ट्सना 127.0.0.1:5432:5432 वापरून loopback वर पब्लिश करा, अंतर्गत सेवा पब्लिश करू नका किंवा DOCKER-USER chain मध्ये फिल्टरिंग करा.

VPS रीबूट झाल्यानंतर माझे कंटेनर्स पुन्हा सुरू होतील का?

केवळ जर ते restart policy सह तयार केले असतील तरच. प्रत्येक सर्व्हिसवर restart: unless-stopped सेट करा, कंटेनर्स पुन्हा तयार करण्यासाठी docker compose up -d चालवा आणि systemctl is-enabled docker कमांडने enabled आउटपुट मिळते का ते तपासा. त्यानंतर मुद्दाम रीबूट करून docker compose ps तपासा. ज्या restart policy ची तुम्ही चाचणी घेतलेली नाही, ती विश्वासार्ह नसते.

मी Docker इमेजेस किती वेळा prune केल्या पाहिजेत?

बहुतेक लहान सर्व्हर्ससाठी महिन्यातून एकदा पुरेसे आहे, किंवा जेव्हा docker system df तुम्हाला रिकामी करता येण्याजोगी जागा दाखवते तेव्हा करा. docker image prune -a आणि docker builder prune वापरणे सुरक्षित आहे कारण चालू असलेल्या सेवांच्या इमेजेस आणि कॅशे वगळले जातात. docker system prune --volumes वापरणे टाळा, जोपर्यंत तुम्हाला नक्की माहित नसेल की कोणते volumes वापरात नाहीत, कारण यामुळे बंद असलेल्या कोणत्याही स्टॅकचा डेटा कायमचा नष्ट होऊ शकतो.