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

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

VPS वर Docker चालवताना तुमच्या laptop वरील Docker प्रमाणेच engine आणि images वापरले जातात. त्यामुळे तुम्हाला माहीत असलेली प्रत्येक command अजूनही कार्य करते. बदल होतो तो त्याच्या सभोवतालच्या संसाधनांमध्ये. Laptop मध्ये अतिरिक्त memory असते, कोणीही scan करत नसलेला firewall असतो आणि disk इतकी मोठी असते की तिच्याकडे लक्ष देण्याची गरज पडत नाही. भाड्याने घेतलेल्या server मध्ये memory ची निश्चित मर्यादा असते, boot केल्यानंतर काही मिनिटांत scan होणारा public IP address असतो आणि Docker ची root filesystem परवानगी न घेता भरत जाते.

लहान server वर बहुतेक समस्या या चार फरकांमुळे होतात:

• Memory मर्यादित असते आणि तिची कमतरता भरून काढण्यासाठी kernel एखादी process बंद करते.
• Published port थेट UFW (uncomplicated firewall) मधून बाहेर जातो, कारण Docker स्वतःचे firewall rules लिहितो.
• आधीपासून तसे configure केले नसेल, तर reboot नंतर containers पुन्हा सुरू होत नाहीत.
• Images, containers, volumes आणि build cache वाढत जातात आणि शेवटी disk पूर्ण भरते.

खालील प्रत्येक section मध्ये समस्या, प्रत्यक्ष दिसणारा string आणि ती सविस्तरपणे सोडवणारा guide दिला आहे. तुम्ही अजून compose file लिहिली नसेल, तर आधी VPS वर Docker Compose ची मूलभूत माहिती वाचा आणि नंतर येथे परत या. हा page तुम्ही stack आधीच सुरू करू शकता असे गृहीत धरतो.

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

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

खालील आकडे default configuration असलेल्या Ubuntu 24.04 वरील stock images साठीचे सामान्य idle आकडे आहेत. हे आकडे सुरू केल्यानंतर काही मिनिटांनी docker stats मधून घेतले आहेत. ते planning साठीचा प्रारंभबिंदू आहेत; तुमच्या workload साठीचा benchmark नाहीत. कोणत्याही आकड्यावर, यांसह, विश्वास ठेवण्यापूर्वी स्वतःच्या मशीनवर 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
  }
]

दोन्ही columns ची कामे वेगवेगळी आहेत. idle_mb म्हणजे काहीही काम न करता container वापरत असलेली memory. budget_mb म्हणजे planning करताना राखून ठेवायची memory, कारण प्रत्यक्ष वापर idle नसतो. PostgreSQL idle अवस्थेत 45 MB च्या आसपास वापरतो. Connections, sorts आणि cache सक्रिय झाल्यावर त्याला 512 MB आवश्यक असतात. Planning करताना budget column वापरा. Debugging करताना idle column वापरा.

त्या 7 rows चे स्वरूप लक्षात घ्या. nginx idle अवस्थेत 8 MB वापरतो, तर Nextcloud 210 MB वापरतो. तुमच्या applications समोरील proxy जवळजवळ कोणतीही अतिरिक्त memory घेत नाही. Server ची क्षमता ठरवताना database आणि PHP application महत्त्वाचे असतात.

docker stats बाबत एक सूचना: memory च्या आकड्यात container ने केलेल्या file reads मुळे वापरात आलेला page cache समाविष्ट असतो. त्यामुळे start केल्यानंतर हा आकडा काही काळ वाढतो आणि नंतर स्थिर होतो. काहीतरी memory leak होत आहे असा निष्कर्ष काढण्यापूर्वी तो एक तास monitor करा.

VPS चे sizing: 2 GB, 4 GB आणि 8 GB मध्ये काय बसते

सुरुवातीला host चा हिस्सा वजा करा. Kernel, systemd, journald, sshd आणि Docker daemon हे सर्व तुमच्या containers प्रमाणेच त्याच RAM मध्ये चालतात आणि dockerd वरील containerd मिळून सुमारे 100 MB RAM वापरतात. Page cache साठी आणि image build किंवा database dump चालू असताना येणाऱ्या अचानक वाढीसाठीही काही memory मोकळी ठेवावी लागते.

[
  {
    "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 मध्ये operating system, Docker daemon आणि load असतानाही मशीन प्रतिसादक्षम ठेवणारी अतिरिक्त memory समाविष्ट असते. उरलेली memory म्हणजे container_mb; खर्च करण्यासाठी उपलब्ध असलेली हीच एकूण संख्या आहे. सर्वात लहान plan मधील 768 MB पासून सर्वात मोठ्या plan मधील 1536 MB पर्यंत हा राखीव हिस्सा वाढतो, कारण मोठ्या मशीनवर अधिक containers चालतात, अधिक logs लिहिले जातात आणि अधिक page cache आवश्यक असतो.

2 GB plan मध्ये containers साठी 1280 MB उरतात. त्यापैकी 512 MB PostgreSQL साठी आणि 128 MB Traefik साठी वापरल्यावर निम्मी memory आधीच खर्च होते. उरलेल्या memory मध्ये प्रत्येकी सुमारे 256 MB वापरणारे दोन छोटे applications चालू शकतात. हा प्रत्यक्ष उपयोगी server आहे. मात्र त्यावर Nextcloud आणि search cluster दोन्ही चालवण्यासाठी पुरेशी जागा नाही.

4 GB plan मध्ये 3072 MB उरतात. या memory मध्ये database, reverse proxy, तीन applications आणि monitoring container एकाच वेळी चालू शकतात. तुम्हाला महत्त्वाची कोणतीही सेवा चालवण्यासाठी हा किमान उपयुक्त आकार आहे, कारण अतिरिक्त memory खराब deploy मुळे निर्माण होणारा तात्पुरता भार सांभाळते.

8 GB plan मध्ये त्याच्या 8192 MB पैकी 6656 MB उरतात. या आकारात मर्यादा सामान्यतः memory ऐवजी CPU किंवा disk throughput ठरवते. तुमचा stack बसत नाही असे गणितातून दिसत असल्यास त्यानुसार configuration बदलत राहण्याऐवजी मोठा plan घ्या: VPS ची प्रत्यक्ष किंमत अतिरिक्त gigabytes साठी दरमहा किती खर्च योग्य आहे हे स्पष्ट करते.

गणित अचूक ठेवण्यासाठी दोन नियम पाळा. प्रत्येक service वर memory limit ठेवा, म्हणजे एखादी अनियंत्रित process संपूर्ण मशीनची memory संपवू शकणार नाही. तसेच budget मधील काही हिस्सा न वापरता ठेवा, कारण docker compose build आणि pg_dump दोन्हींना सर्वाधिक गरज असते तेव्हा memory आवश्यक असते. Docker Compose मधील memory limits मध्ये syntax आणि त्यातील अडचणी दिल्या आहेत.

माझा container code 137 सह का बंद होतो?

कारण kernel ने तो बंद केला. 137 म्हणजे 128 अधिक 9, आणि signal 9 म्हणजे SIGKILL. container ला त्याला अनुमती असलेल्या मर्यादेपेक्षा जास्त memory हवी होती. त्यामुळे 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 याचा अर्थ container ने स्वतःची cgroup मर्यादा गाठली. kernel log मध्ये निवडलेल्या process चे नाव दिसते:

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

ही चांगली परिस्थिती आहे, कारण नुकसान एका containerपुरते मर्यादित राहते. मर्यादाच नसलेला container ही वाईट परिस्थिती आहे. मर्यादा नसल्यास त्याची कमाल मर्यादा संपूर्ण machine इतकी असते. त्यामुळे एका service मधील memory leak मुळे host वरील memory कमी होते. त्यानंतर kernel संपूर्ण system मधील आकारानुसार एखादा victim निवडतो. Log line मधील Memory cgroup prefix नसतो आणि ती Out of memory: Killed process 2417 (postgres) अशी दिसते. Kernel अनेकदा तुमचा database निवडतो, तर memory leak करणारा container चालूच राहतो. म्हणून प्रत्येक service वर मर्यादा असणे, कोणत्याही एका मर्यादेची अचूक value ठरवण्यापेक्षा अधिक महत्त्वाचे आहे.

Swap मुळे वेळ बदलतो; गणित बदलत नाही. बहुतेक VPS images मध्ये swap नसतो. swapon --show वापरून तपासा. swap नसल्यास हा command काहीही output देत नाही. Swap file मुळे kernel ला सध्या आवश्यक नसलेली 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 row मध्ये शून्यापेक्षा अधिक total दिसायला हवा. Swap मुळे RAM वाढत नाही. सतत memory pressure असलेल्या box ची गती इतकी कमी होऊ शकते की समस्या दुरुस्त करण्यासाठी तुम्ही SSH ने प्रवेश करू शकत नाही. त्यामुळे swap कडे alarm buffer म्हणून पाहा आणि sizing योग्य करा.

UFW प्रकाशित Docker पोर्ट का अवरोध का करत नाही?

कारण हे network traffic UFW ज्या chain चे संरक्षण करते तिथे पोहोचतच नाही. `-p 5432:5432 वापरून किंवा compose मधील ports: entry द्वारे पोर्ट प्रकाशित केल्यावर daemon nat table मध्ये DNAT (destination network address translation) rule आणि स्वतःच्या DOCKER chain मध्ये accept rule लिहितो. Container कडे निर्देशित केलेले packet host कडे deliver होण्याऐवजी त्या container कडे forward केले जाते. त्यामुळे ते FORWARD path मधून हाताळले जाते आणि UFW लिहित असलेल्या INPUT` rules मधून जात नाही.

हे server वर पुढीलप्रमाणे पाहता येते:

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

UFW `5432 DENY IN Anywhere दाखवू शकतो, तर nat table मध्ये त्याच पोर्टसाठी DNAT tcp ... to:172.18.0.2:5432 rule असतो. दुसऱ्या machine वरून nc -vz your.server.ip 5432` अजूनही connect होते. Database सार्वजनिक internet वर उपलब्ध असतो, पण firewall तो उपलब्ध नसल्याचे दर्शवतो.

यावर उपाय म्हणजे कमी ports publish करणे. एकाच compose project मधील containers network share करतात आणि service name द्वारे एकमेकांपर्यंत पोहोचतात. त्यामुळे फक्त त्याच्या शेजारील application ला सेवा देणाऱ्या database साठी `ports:` entry ची गरज नसते. Local access आवश्यक असल्यास publish loopback ला bind करा:

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

`docker compose up -d केल्यानंतर बाहेरून nc -vz your.server.ip 5432 अयशस्वी होते आणि box वर psql -h 127.0.0.1 -p 5432` अजूनही कार्य करते. व्यवस्थित small stack मध्ये फक्त reverse proxy काही publish करतो, तेही 80 आणि 443 वर. पोर्ट publish करणे आवश्यक असताना त्यावर filter कसे लावायचे यासाठी Docker प्रकाशित ports UFW ला कसे bypass करतात मधील DOCKER-USER chain वाचा. त्याखालील host rules साठी UFW firewall ची मूलभूत माहिती वाचा.

रीबूटनंतर माझे containers का नाहीसे झाले?

त्यांना पुन्हा सुरू करण्याची कोणतीही सूचना दिली नव्हती. restart policy सेट केली नसेल, तर container no सह तयार होतो. त्यामुळे रीबूटनंतर तो stopped स्थितीत राहतो आणि daemon त्याची काळजी घेत नाही. VPS वर रीबूट क्वचित होत नाहीत: unattended upgrades मधील kernel updates, provider maintenance आणि वरील OOM sequence या सर्वांचा शेवट रीबूटमध्ये होऊ शकतो.

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

systemctl is-enabled docker

Stock Ubuntu install वर यामुळे enabled दिसते. त्यानंतर प्रत्येक service साठी policy आवश्यक आहे:

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

unless-stopped रीबूटनंतर container पुन्हा सुरू करते आणि तुम्ही मुद्दाम थांबवलेल्या container चा manual stop आदरते. always daemon पुन्हा सुरू झाल्यावर तुम्ही जाणीवपूर्वक थांबवलेले containers देखील सुरू करते. Debugging दरम्यान हे अनपेक्षित ठरू शकते. फाइलमध्ये बदल करणे पुरेसे नाही, कारण restart policy container तयार करताना सेट केली जाते. Container पुन्हा तयार करण्यासाठी docker compose up -d चालवा. त्यानंतर प्रत्यक्ष लागू असलेली value तपासा:

docker inspect my-app | grep -A3 RestartPolicy

त्यानंतर मशीनचा रीबूट मुद्दाम करा आणि project directory मध्ये docker compose ps चालवा. नियोजित रीबूटनंतर टिकणारा stack अनियोजित रीबूटनंतरही टिकतो. तुमच्या stack ला सेवांच्या क्रमाची हमी किंवा boot वेळी one-shot job आवश्यक असल्यास, systemd unit हे अधिक योग्य साधन आहे: boot वेळी Docker Compose सुरू करणे येथे unit file आहे. पुन्हा सुरू झालेला container प्रत्यक्षात service देत आहे का हे तपासण्यासाठी Compose healthchecks जोडा.

माझ्या VPS ची disk full का झाली?

तुम्ही Docker ला तसे करण्यास सांगत नाही तोपर्यंत Docker सर्व काही साठवून ठेवतो. तुम्ही कधी pull केलेला प्रत्येक image tag, थांबवलेला प्रत्येक container, recreate नंतर मागे राहिलेला प्रत्येक anonymous volume आणि build cache मधील प्रत्येक layer disk वरच राहतो. या plan sizes मध्ये 40 GB किंवा 80 GB ची root filesystem सामान्य असते. त्यामुळे समस्या वर्षांऐवजी काही महिन्यांत outage मध्ये रूपांतरित होते.

Disk full झाल्याचे crash सारखे दिसत नाही. त्याच तासात container कडून, no space left on device कडून, journald कडून आणि docker pull कडून तुम्हाला apt मिळतो. PostgreSQL writes स्वीकारणे थांबवतो. मशीन अजूनही सुरू असते. त्यामुळे reboot loop पेक्षा ही समस्या लक्षात येणे कठीण असते.

Delete करण्यापूर्वी तपासा:

docker system df
df -h /

docker system df एकूण वापर images, containers, local volumes आणि build cache यांच्यात विभागतो. प्रत्येकाच्या शेजारी RECLAIMABLE column असतो. स्वतःचे images build करणाऱ्या मशीनवर build cache ही सहसा सर्वात मोठी नोंद असते.

docker image prune -a
docker builder prune
docker system df

docker image prune -a सध्या कोणताही container वापरत नसलेला प्रत्येक image काढतो. docker builder prune build cache साफ करतो. सेवा सुरू असतानाही दोन्ही सुरक्षित आहेत, कारण वापरात असलेल्या गोष्टी वगळल्या जातात. सुरक्षित नसलेला command म्हणजे docker system prune --volumes. तो सध्या कोणताही container reference करत नसलेला प्रत्येक volume delete करतो. Weekend साठी थांबवलेल्या stack ची स्थिती नेमकी अशीच असते आणि त्याच्यासोबत त्याचा database volume देखील delete होतो. तो flag वापरण्यापूर्वी bind mounts आणि named volumes यांमधील फरक वाचा आणि आधी backup घ्या.

Container logs मुळे disk हळूहळू भरते. Default json-file driver ला size limit नसते. त्यामुळे एखादा जास्त logs लिहिणारा container /var/lib/docker/containers मध्ये gigabytes साठवू शकतो. प्रत्येक container साठी /etc/docker/daemon.json मध्ये त्याची मर्यादा निश्चित करा:

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

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

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

Inspect output मध्ये max-size set असल्याचे दिसले पाहिजे. ते रिकामे असल्यास तो container बदल लागू होण्यापूर्वी तयार झाला आहे आणि अजूनही कोणत्याही मर्यादेशिवाय लिहित आहे.

लहान Docker बॉक्स निरोगी ठेवणाऱ्या सवयी

यापैकी कोणत्याही गोष्टीसाठी dashboard किंवा शिकावे लागणारे tool आवश्यक नाही.

• महिन्याच्या पहिल्या दिवशी docker system df आणि df -h / चालवा. दोन commands, तीस seconds आणि outage होण्याच्या बराच आधी trend दिसतो.
• प्रत्येक service साठी memory limit द्या. लहान असल्याची खात्री असलेल्या services साठीही हे करा. या limit मुळे संपूर्ण host बंद पडण्याऐवजी एक container restart होतो.
• बॉक्सचे monitoring दुसऱ्या ठिकाणाहून करा, म्हणजे kernel कारवाई करण्यापूर्वी memory किंवा disk pressure बद्दल माहिती मिळेल. Uptime Kuma container मध्ये चालते आणि idle स्थितीत सुमारे 95 MB memory वापरते.
• containers चा नाही, तर volumes चा backup घ्या. Container disposable असतो, पण volume disposable नसतो. VPS वरील restic backups schedule आणि restore test या दोन्हींचा समावेश करते.
• compose file मध्ये image tags निश्चित करा आणि तुमच्या निवडलेल्या दिवशी त्यांचे update करा. latest वापरल्यास, पुढील docker compose pull मधून तुम्हाला मिळणारी version त्या सकाळी release झालेली कोणतीही version असू शकते.

चार numbers मर्यादेत राहिल्यास Docker चालवणारा छोटा VPS अनेक वर्षे निरोगी राहतो: memory budget, published ports ची यादी, प्रत्येक service वरील restart policy आणि free disk. बाकी सर्व तुम्ही घरी आधीपासून चालवत असलेल्या Docker सारखेच असते.

FAQ

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

Docker स्वतः कमी संसाधने वापरतो. daemon आणि containerd मिळून साधारण 100 MB RAM वापरतात; उर्वरित गरज तुमच्या containers ची असते. आधी host साठी आवश्यक RAM राखून ठेवा: 768 MB असलेल्या 2048 MB सर्व्हरमध्ये operating system, daemon आणि headroom साठी 1280 MB राखा. त्यामुळे containers साठी 1280 MB उरतात. 512 MB वापरणारा database, 128 MB वापरणारा reverse proxy आणि दोन लहान applications यामध्ये चालू शकतात. प्रकाशित केलेल्या कोणत्याही आकड्यावर अवलंबून न राहता तुमचा stack docker stats --no-stream ने मोजा.

1 GB VPS वर Docker चालवता येईल का?

होय, एक किंवा दोन हलके containers चालवता येतात. सुरू करण्यापूर्वी swap file तयार करा. operating system आणि Docker daemon सुरू झाल्यानंतर 1 GB सर्व्हरच्या साधारण निम्मी RAM वापरली जाते. त्यामुळे एक लहान application आणि reverse proxy साठी जागा उरते; परंतु प्रत्यक्ष भार असलेला database चालवता येणार नाही. एवढ्या आकाराच्या सर्व्हरवर images build केल्यास प्रक्रिया अयशस्वी होऊ शकते किंवा दुसरी सेवा बंद होऊ शकते. त्यामुळे images दुसऱ्या ठिकाणी build करून तयार image pull करा.

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

तुम्ही publish केलेल्या ports साठी नाही. Docker स्वतःचे DNAT आणि forward rules लिहितो. त्यामुळे published container port कडे आलेले packet host कडे न जाता container कडे forward केले जाते आणि UFW व्यवस्थापित करत असलेल्या INPUT rules पर्यंत ते पोहोचत नाही. त्या port वरून इंटरनेटवरील विनंत्यांना उत्तर मिळत असतानाही ufw deny 5432 सक्रिय असू शकते. 127.0.0.1:5432:5432 वापरून loopback वर publish करा, internal services unpublished ठेवा किंवा DOCKER-USER chain मध्ये filtering करा.

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

ते restart policy सह तयार केले असतील तरच. प्रत्येक service वर restart: unless-stopped सेट करा, containers त्या policy सह पुन्हा तयार करण्यासाठी docker compose up -d चालवा आणि systemctl is-enabled docker चा output enabled आहे याची खात्री करा. त्यानंतर जाणूनबुजून reboot करून docker compose ps तपासा. तुम्ही कधीही तपासलेली नसलेली restart policy प्रत्यक्षात विश्वसनीय restart policy नाही.

Docker images किती वेळाने prune कराव्यात?

बहुतेक लहान सर्व्हरसाठी महिन्यातून एकदा पुरेसे आहे. तसेच docker system df अशा reclaimable space ची नोंद करत असेल, ज्याची तुम्हाला गरज आहे, तेव्हाही prune करा. Services चालू असताना docker image prune -a आणि docker builder prune दोन्ही सुरक्षित आहेत, कारण वापरात असलेल्या images आणि cache वगळले जातात. नेमके कोणते volumes unreferenced आहेत हे माहीत नसल्यास docker system prune --volumes टाळा. कारण त्या वेळी बंद असलेल्या कोणत्याही stack मधील data ते delete करू शकते.