VPSపై Dockerలో నిజంగా ఏమి మారుతుంది

VPSపై Docker నడిపినప్పుడు ఏమి మారుతుంది

VPSపై Docker, మీ laptopలోని Docker ఉపయోగించే అదే engine మరియు అదే imagesను ఉపయోగిస్తుంది. అందువల్ల మీకు ఇప్పటికే తెలిసిన ప్రతి command ఇప్పటికీ పనిచేస్తుంది. మారేది దాని చుట్టూ ఉన్న వాతావరణం. Laptopలో అదనపు memory ఉంటుంది. ఎవరూ scan చేయని firewall ఉంటుంది. మీరు diskను పరిశీలించాల్సిన అవసరం లేకుండా ఉండేంత పెద్దదిగా అది ఉంటుంది. అద్దెకు తీసుకున్న serverకు memory పరిమితి స్థిరంగా ఉంటుంది. దానికి ఉన్న public IP address boot చేసిన కొద్ది నిమిషాల్లోనే scan చేయబడుతుంది. Docker root filesystemను అనుమతి అడగకుండా నింపుతుంది.

చిన్న serverలో ఎక్కువ సమస్యలకు కారణమయ్యే నాలుగు తేడాలు ఇవి:

• Memory పరిమితమైనది. కొరత ఏర్పడితే kernel ఒక processను terminate చేస్తుంది.
• Published port నేరుగా UFW (uncomplicated firewall)ను దాటి వెళ్తుంది, ఎందుకంటే Docker తన సొంత firewall rulesను రాస్తుంది.
• మీరు ముందుగానే ఆ విధంగా configure చేయకపోతే reboot తర్వాత containers మళ్లీ ప్రారంభం కావు.
• Disk పూర్తిగా నిండే వరకు images, containers, volumes మరియు build cache పెరుగుతూనే ఉంటాయి.

క్రింది ప్రతి sectionలో సమస్య, మీరు వాస్తవంగా చూసే string, అలాగే దాన్ని లోతుగా పరిష్కరించే guide వివరించబడతాయి. మీరు ఇంకా compose file రాయకపోతే, ముందుగా VPSపై Docker Compose ప్రాథమికాలు చదివి తిరిగి రండి. మీరు ఇప్పటికే ఒక stackను ప్రారంభించగలరని ఈ పేజీ భావిస్తుంది.

Docker container ఎంత RAM ఉపయోగిస్తుంది?

చాలామంది ఊహించేదానికంటే తక్కువ. Container అనేది virtual machine కాదు; అది cgroup (control group) లో నడిచే process. అందువల్ల guest kernel ఉండదు, fixed allocation కూడా ఉండదు. Container లోని process తాకే memory మేరకే ఖర్చు ఉంటుంది. అందుకే virtual machines తో నిర్మించిన అదే stack కు సాధ్యం కాని విధంగా, పూర్తి stack 2 GB లో సరిపోవచ్చు.

క్రింది గణాంకాలు Ubuntu 24.04 పై default configuration తో నడిచే stock images కు సంబంధించిన సాధారణ idle సంఖ్యలు. Start చేసిన కొన్ని నిమిషాల తర్వాత docker stats నుంచి ఇవి చదవబడ్డాయి. ఇవి planning కోసం ప్రారంభ అంచనాలు మాత్రమే; మీ workload కు benchmark కావు. ఏ గణాంకాన్నైనా, వీటినీ కలుపుకుని, నమ్మే ముందు మీ స్వంత box పై 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 సమయంలో reserve చేయాల్సిన memory, ఎందుకంటే వాస్తవ వినియోగం idle గా ఉండదు. Connections, sorts మరియు cache active అయిన తర్వాత PostgreSQL idle స్థాయికి సమీపంలోని 45 MB నుంచి 512 MB కోరుతుంది. Planning ను budget column ఆధారంగా చేయండి. Debugging ను idle column ఆధారంగా చేయండి.

ఆ 7 rows నమూనాను గమనించండి. nginx 8 MB వద్ద idle గా ఉంటుంది; Nextcloud 210 MB వద్ద ఉంటుంది. మీ applications ముందు ఉన్న proxy దాదాపు memory ఉపయోగించదు. మీరు box capacity నిర్ణయించేటప్పుడు ప్రధానంగా database మరియు PHP application కోసం memory కేటాయించాలి.

docker stats గురించి ఒక హెచ్చరిక: container స్వంత file reads ద్వారా లోడ్ చేసిన page cache కూడా memory గణాంకంలో ఉంటుంది. అందువల్ల start చేసిన తర్వాత కొంతసేపు memory పెరిగి, తరువాత స్థిరపడుతుంది. ఏదైనా memory leak ఉందని నిర్ణయించే ముందు ఒక గంట పాటు దాన్ని monitor చేయండి.

VPS పరిమాణం: 2 GB, 4 GB మరియు 8 GBలో ఏవి సరిపోతాయి

ముందుగా host వినియోగించే RAMను మొత్తం బడ్జెట్ నుంచి తీసివేయండి. Kernel, systemd, journald, sshd మరియు Docker daemon మీ containers ఉపయోగించే అదే RAMలో నడుస్తాయి. dockerd మరియు containerd కలిసి సుమారు 100 MB RAMను ఉపయోగిస్తాయి. Page cache కోసం, అలాగే image build లేదా database dump నడిచే సమయంలో ఏర్పడే తాత్కాలిక memory spike కోసం కూడా కొంత 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 సమయంలో server స్పందన నిలుపుకునే headroomను కలిగి ఉంటుంది. మిగిలింది container_mb. మీరు ఖర్చు చేయగల ఏకైక memory ఇదే. చిన్నest boxలో ఈ reserve 768 MB నుంచి largest boxలో 1536 MB వరకు పెరుగుతుంది. పెద్ద boxలో ఎక్కువ 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 మిగులుతుంది. ఇందులో database, reverse proxy, మూడు applications మరియు monitoring container ఒకేసారి సరిపోతాయి. మీకు ముఖ్యమైన సేవలకు ఉపయోగించదగిన కనిష్ఠ పరిమాణం ఇదే. ఎందుకంటే అదనంగా మిగిలే memory విఫలమైన deploy వల్ల ఏర్పడే తాత్కాలిక భారాన్ని తట్టుకుంటుంది.

8 GB planలో మొత్తం 8192 MBలో 6656 MB మిగులుతుంది. ఈ పరిమాణంలో పరిమితి సాధారణంగా memory నుంచి CPU లేదా disk throughput వైపు మారుతుంది. కొన్ని containers load ఆధారంగా కాకుండా configuration ఆధారంగా తమ memory పరిమాణాన్ని నిర్ణయించుకుంటాయి. ఉదాహరణకు, local model server తన context windowకు అనుపాతంగా KV cacheను reserve చేస్తుంది. అందువల్ల ఒక్క request కూడా రాకముందే Ollama యొక్క num_ctx పెంచడం memory బడ్జెట్‌కు gigabytesను జోడించవచ్చు. లెక్క ప్రకారం మీ stack సరిపోకపోతే, configurationతో పరిమితులను తప్పించుకునే ప్రయత్నం చేయకుండా పెద్ద planను తీసుకోండి: VPS వాస్తవంగా ఎంత ఖర్చవుతుంది అనే వివరణలో అదనపు gigabytesకు నెలకు చెల్లించే విలువను వివరించారు.

లెక్కలను వాస్తవికంగా ఉంచే రెండు నియమాలు ఉన్నాయి. ప్రతి serviceపై memory limit పెట్టండి. అలా చేస్తే అదుపు తప్పిన ఒక process మొత్తం serverను ప్రభావితం చేయదు. అలాగే బడ్జెట్‌లోని పైభాగాన్ని ఖర్చు చేయకుండా ఉంచండి. ఎందుకంటే docker compose build మరియు pg_dump రెండింటికీ అత్యవసర సమయంలో memory అవసరం కావచ్చు. Docker Composeలో Memory limitsలో syntax మరియు సాధారణ సమస్యలు వివరించబడ్డాయి.

నా container code 137తో ఎందుకు exit అవుతోంది?

Kernel దాన్ని terminate చేసింది. 137 అనేది 128 plus 9. Signal 9 పేరు SIGKILL. Container కు అనుమతించిన memory కంటే ఎక్కువ memory అవసరమైంది. అందువల్ల out of memory (OOM) killer దాన్ని terminate చేసింది.

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 limit ను చేరుకుంది. Kernel log అది ఎంచుకున్న process పేరును చూపిస్తుంది:

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

ఇది మంచి పరిస్థితి. ఎందుకంటే నష్టం ఒకే container కు పరిమితమవుతుంది. Limit అసలు లేని container చెడు పరిస్థితిని కలిగిస్తుంది. Limit లేకపోతే దాని గరిష్ఠ పరిమితి మొత్తం machine memory అవుతుంది. అందువల్ల ఒక service లోని memory leak host లోని memory ని ఖాళీ చేస్తుంది. తరువాత kernel మొత్తం system లో memory పరిమాణం ఆధారంగా ఒక victim ను ఎంచుకుంటుంది. Log line లో Memory cgroup prefix ఉండదు. అది Out of memory: Killed process 2417 (postgres) గా కనిపిస్తుంది. Kernel ఎంచుకునే process తరచుగా మీ database అవుతుంది. అయితే memory leak చేసిన container మాత్రం నడుస్తూనే ఉంటుంది. అందుకే ప్రతి service కు limit పెట్టడం, ఏదైనా ఒక్క limit యొక్క ఖచ్చితమైన విలువ కంటే ముఖ్యమైనది.

Swap సమయాన్ని మార్చుతుంది. లెక్కను మార్చదు. చాలా VPS images లో swap ఉండదు. swapon --show తో తనిఖీ చేయండి. Swap లేకపోతే ఇది ఏ output ను చూపించదు. Swap file ఉంటే cold pages ను ఉంచడానికి kernel కు స్థలం లభిస్తుంది. సమస్యను గుర్తించడానికి ఇది మీకు కొన్ని నిమిషాల సమయం ఇస్తుంది.

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

ఇప్పుడు Swap row లో free -h non-zero total ను చూపించాలి. Swap, RAM ను పెంచదు. నిరంతర memory pressure ఉన్న machine చాలా నెమ్మదిగా మారవచ్చు. అప్పుడు సమస్యను పరిష్కరించడానికి మీరు SSH ద్వారా login కాలేకపోవచ్చు. కాబట్టి swap ను alarm buffer గా పరిగణించి, memory sizing ను సరిచేయండి.

UFW ప్రచురించిన Docker port ను ఎందుకు block చేయదు?

ఎందుకంటే ఆ traffic UFW పర్యవేక్షించే chain కు చేరదు. -p 5432:5432 తో port publish చేసినప్పుడు లేదా compose లో ports: entry ఉపయోగించినప్పుడు, daemon nat table లో DNAT (destination network address translation) rule ను, అలాగే తన స్వంత DOCKER chain లో accept rule ను రాస్తుంది. Container కు ఉద్దేశించిన packet host కు deliver కాకుండా ఆ container కు forward అవుతుంది. అందువల్ల అది FORWARD మార్గంలో handle అవుతుంది, UFW రాసే INPUT rules ను దాటదు.

Server పై ఇది ఎలా జరుగుతుందో చూడవచ్చు:

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

nat table లో అదే port కోసం DNAT tcp ... to:172.18.0.2:5432 rule ఉన్నప్పటికీ, UFW 5432 DENY IN Anywhere ను print చేయవచ్చు. మరో machine నుంచి nc -vz your.server.ip 5432 ఇప్పటికీ connect అవుతుంది. Database public internet కు అందుబాటులో ఉంటుంది, కానీ firewall అది అందుబాటులో లేదని చెబుతుంది.

దీనికి పరిష్కారం తక్కువ ports ను publish చేయడం. ఒకే compose project లోని containers ఒక network ను share చేసుకుంటాయి. అవి service name ద్వారా ఒకదానితో ఒకటి connect అవుతాయి. కాబట్టి పక్కనే ఉన్న 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 ఇప్పటికీ పనిచేస్తుంది. సక్రమంగా అమర్చిన చిన్న stack లో reverse proxy మాత్రమే 80 మరియు 443 పై ఏదైనా publish చేస్తుంది. Port తప్పనిసరిగా publish చేసి, దానిపై filtering చేయాల్సిన సందర్భాల కోసం Docker published ports UFW ను ఎలా bypass చేస్తాయి లో DOCKER-USER chain గురించి వివరించారు. దిగువ host rules కోసం UFW firewall ప్రాథమికాలు చూడండి.

నా containers reboot తర్వాత ఎందుకు కనిపించకుండా పోయాయి?

వాటిని తిరిగి ప్రారంభించమని ఏదీ చెప్పలేదు. మీరు restart policy సెట్ చేయకపోతే, container no policyతో సృష్టించబడుతుంది. అందువల్ల reboot తర్వాత అది stopped స్థితిలోనే ఉంటుంది. daemon కూడా దీనిని పట్టించుకోదు. VPSలో reboots అరుదు కావు. unattended upgrades ద్వారా వచ్చే kernel updates, provider maintenance, అలాగే పై వివరించిన OOM sequence ఇవన్నీ rebootకు దారితీయవచ్చు.

రెండు విషయాలు తప్పనిసరిగా నిజం కావాలి. daemon boot సమయంలో ప్రారంభం కావాలి:

systemctl is-enabled docker

సాధారణ Ubuntu installలో ఇది enabled ను చూపిస్తుంది. తరువాత ప్రతి serviceకు ఒక policy అవసరం:

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

unless-stopped reboot తర్వాత containerను తిరిగి ప్రారంభిస్తుంది. మీరు ఉద్దేశపూర్వకంగా ఆపిన containerను ఇది గౌరవిస్తుంది. always మీరు ఉద్దేశపూర్వకంగా ఆపిన containersను కూడా daemon restart అయిన ప్రతిసారి తిరిగి ప్రారంభిస్తుంది. Debugging మధ్యలో ఇది అనుకోని ప్రవర్తన కావచ్చు. Fileను మార్చడం మాత్రమే సరిపోదు. Container సృష్టించబడిన సమయంలోనే restart policy సెట్ అవుతుంది. అందువల్ల దాన్ని మళ్లీ సృష్టించేందుకు docker compose up -d అమలు చేయండి. తరువాత ప్రస్తుత valueను పరిశీలించండి:

docker inspect my-app | grep -A3 RestartPolicy

తరువాత ఉద్దేశపూర్వకంగా serverను reboot చేసి, project directoryలో docker compose ps అమలు చేయండి. Planned rebootను తట్టుకునే stack, unplanned rebootను కూడా తట్టుకుంటుంది. మీ stackకు startup order హామీ లేదా boot సమయంలో ఒకసారి మాత్రమే నడిచే job అవసరమైతే, systemd unit మెరుగైన సాధనం. boot సమయంలో Docker Compose ప్రారంభించడంలో unit file ఉంది. తిరిగి ప్రారంభమైన container నిజంగా service అందిస్తుందో తెలుసుకోవడానికి Compose healthchecks జోడించండి.

నా VPS డిస్క్ ఎందుకు నిండిపోయింది?

మీరు నిలిపివేయమని చెప్పే వరకు Docker ప్రతిదీ ఉంచుతుంది. మీరు ఎప్పుడైనా pull చేసిన ప్రతి image tag, ఆపివేసిన ప్రతి container, recreate చేసినప్పుడు మిగిలిపోయిన ప్రతి anonymous volume, అలాగే build cache లోని ప్రతి layer డిస్క్‌లోనే ఉంటుంది. ఈ plan పరిమాణాల్లో 40 GB లేదా 80 GB root filesystem సాధారణమే. అలాంటి పరిమితిలో సమస్య సంవత్సరాల తర్వాత కాకుండా కొన్ని నెలల్లోనే outage కు దారితీయవచ్చు.

డిస్క్ పూర్తిగా నిండితే అది crash లాగా కనిపించదు. అదే గంటలో container నుంచి, no space left on device నుంచి, journald నుంచి, అలాగే docker pull నుంచి apt లభిస్తాయి. PostgreSQL writes ను స్వీకరించడం ఆపేస్తుంది. box ఇంకా పనిచేస్తూనే ఉంటుంది. అందువల్ల reboot loop కంటే ఈ సమస్యను గుర్తించడం కష్టం.

తొలగించే ముందు పరిశీలించండి:

docker system df
df -h /

docker system df మొత్తం వినియోగాన్ని images, containers, local volumes మరియు build cache గా విభజిస్తుంది. ప్రతి విభాగం పక్కన RECLAIMABLE column ఉంటుంది. స్వయంగా images build చేసే box లో build cache సాధారణంగా అతిపెద్ద విభాగంగా ఉంటుంది.

docker image prune -a
docker builder prune
docker system df

ఏ container ఉపయోగించని ప్రతి image ను docker image prune -a తొలగిస్తుంది. docker builder prune build cache ను ఖాళీ చేస్తుంది. ఉపయోగంలో ఉన్న వాటిని ఇవి దాటవేస్తాయి కాబట్టి services నడుస్తున్న సమయంలో రెండూ సురక్షితమే. అయితే docker system prune --volumes సురక్షితం కాదు. ప్రస్తుతం ఏ container reference చేయని ప్రతి volume ను ఇది తొలగిస్తుంది. Weekend కోసం ఆపిన stack కూడా ఇలాంటి స్థితిలో ఉంటుంది. దానితో పాటు దాని database volume కూడా తొలగిపోతుంది. ఆ flag ను ఉపయోగించే ముందు bind mounts మరియు named volumes మధ్య తేడాలు చదవండి. ముందుగా backup తీసుకోండి.

Container logs వల్ల డిస్క్ వినియోగం నెమ్మదిగా పెరుగుతుంది. Default json-file driver కు size limit ఉండదు. అందువల్ల ఒక chatty container, /var/lib/docker/containers లో gigabytes పరిమాణంలో data రాయవచ్చు. ప్రతి 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 మార్పుకు ముందే సృష్టించబడింది. అది ఇప్పటికీ ఎలాంటి పరిమితి లేకుండా data రాస్తోంది.

చిన్న Docker హోస్ట్‌ను ఆరోగ్యంగా ఉంచే అలవాట్లు

వీటిలో దేనికీ dashboard లేదా మీరు నేర్చుకోవాల్సిన tool అవసరం లేదు.

• నెలలో మొదటి రోజున docker system df మరియు df -h / ను అమలు చేయండి. రెండు commands, ముప్పై seconds. outage గా మారకముందే trend కనిపిస్తుంది.
• మీరు చిన్నవే అని నమ్మే services తో సహా ప్రతి service కు memory limit ఇవ్వండి. ఈ limit host-wide outage ను ఒక container restart కు పరిమితం చేస్తుంది.
• ఆ box ను వేరే చోటు నుంచి monitor చేయండి. అప్పుడు kernel చర్య తీసుకునేలోపు memory లేదా disk pressure గురించి తెలుసుకుంటారు. Uptime Kuma ఒక container లో నడుస్తుంది. ఇది idle సమయంలో సుమారు 95 MB memory ఉపయోగిస్తుంది.
• containers ను కాదు, volumes ను backup చేయండి. container ను తొలగించి మళ్లీ సృష్టించవచ్చు. volume ను అలా పరిగణించకూడదు. VPS పై restic backups schedule మరియు restore test రెండింటినీ కవర్ చేస్తుంది.
• compose file లో image tags ను pin చేయండి. మీరు ఎంచుకున్న రోజున వాటిని update చేయండి. latest ను ఉపయోగిస్తే, తదుపరి docker compose pull నుంచి పొందే version ఆ ఉదయం విడుదలైనదే అవుతుంది.

నాలుగు సంఖ్యలు నియంత్రణలో ఉన్నంతకాలం Docker నడుస్తున్న చిన్న VPS సంవత్సరాల పాటు ఆరోగ్యంగా ఉంటుంది: memory budget, published ports జాబితా, ప్రతి service కు restart policy, మరియు ఖాళీ disk స్థలం. మిగతావన్నీ మీరు ఇప్పటికే ఇంట్లో నడుపుతున్న అదే Docker.

FAQ

VPSపై Docker నడపడానికి ఎంత RAM అవసరం?

Docker కు స్వయంగా ఎక్కువ వనరులు అవసరం ఉండవు. daemon మరియు containerd కలిపి సుమారు 100 MB ఉపయోగిస్తాయి; మిగతా అవసరం మీ containers పై ఆధారపడి ఉంటుంది. ముందుగా host కోసం అవసరమైన భాగాన్ని కేటాయించండి: 768 MB ను 2048 MB వ్యవస్థలో operating system, daemon మరియు headroom కోసం ఉంచాలి. అప్పుడు containers కోసం 1280 MB మిగులుతుంది. 512 MB ఉపయోగించే database, 128 MB ఉపయోగించే reverse proxy మరియు రెండు చిన్న applications అందులో నడుస్తాయి. ప్రచురించిన గణాంకాలను మాత్రమే నమ్మకుండా, docker stats --no-stream తో మీ స్వంత stack ను కొలవండి.

1 GB VPSపై Docker నడపవచ్చా?

అవును, ఒకటి లేదా రెండు తక్కువ వనరులు ఉపయోగించే containers కోసం నడపవచ్చు. ప్రారంభించే ముందు swap file ను జోడించండి. operating system మరియు Docker daemon నడిచిన తర్వాత 1 GB వ్యవస్థలో సుమారు సగం మెమరీ ఇప్పటికే వినియోగంలో ఉంటుంది. అందువల్ల ఒక చిన్న application మరియు reverse proxy కోసం స్థలం ఉంటుంది, కానీ వాస్తవ load లో database కోసం సరిపోదు. అంత తక్కువ వనరులున్న వ్యవస్థలో images build చేస్తే అది విఫలమవచ్చు లేదా మరొక సేవను నిలిపివేయవచ్చు. కాబట్టి images ను వేరే చోట build చేసి, పూర్తైన image ను pull చేయండి.

UFW Docker container ను రక్షిస్తుందా?

మీరు publish చేసిన ports విషయంలో కాదు. Docker స్వంత DNAT మరియు forward rules ను రాస్తుంది. అందువల్ల publish చేసిన container port కు వచ్చిన packet host కు అందకుండా container కు forward అవుతుంది. UFW నిర్వహించే INPUT rules దాన్ని చూడవు. ufw deny 5432 active గా ఉన్నప్పటికీ, ఆ port internet నుంచి సమాధానం ఇవ్వవచ్చు. 127.0.0.1:5432:5432 తో loopback కు మాత్రమే publish చేయండి, అంతర్గత services ను unpublished గా ఉంచండి లేదా DOCKER-USER chain లో filtering చేయండి.

VPS reboot తర్వాత నా containers మళ్లీ ప్రారంభమవుతాయా?

అవి restart policy తో సృష్టించబడితే మాత్రమే. ప్రతి service పై restart: unless-stopped ను సెట్ చేయండి. ఆ policy తో containers మళ్లీ సృష్టించడానికి docker compose up -d ను అమలు చేయండి. తరువాత systemctl is-enabled docker, enabled ను ప్రదర్శిస్తుందని నిర్ధారించండి. ఆపై ఉద్దేశపూర్వకంగా reboot చేసి docker compose ps ను తనిఖీ చేయండి. ఎప్పుడూ పరీక్షించని restart policy ను నిజమైన restart policyగా పరిగణించకండి.

Docker images ను ఎంత తరచుగా prune చేయాలి?

చాలా చిన్న servers కు నెలకు ఒకసారి సరిపోతుంది. లేదా docker system df reclaim చేయగల స్థలాన్ని చూపించినప్పుడు prune చేయండి. services నడుస్తున్న సమయంలో docker image prune -a మరియు docker builder prune రెండూ సురక్షితమే, ఎందుకంటే ఉపయోగంలో ఉన్న images మరియు cache ను అవి దాటవేస్తాయి. ఏ volumes కు reference లేదో ఖచ్చితంగా తెలియకపోతే docker system prune --volumes ను నివారించండి. ఆ command ప్రస్తుతం ఆపివేయబడి ఉన్న stack కు చెందిన data ను తొలగించవచ్చు.