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 పరిమితమైనది. Memory కొరతను kernel ఒక process ను kill చేయడం ద్వారా పరిష్కరిస్తుంది.
• Published port UFW (uncomplicated firewall)ను నేరుగా దాటుతుంది, ఎందుకంటే Docker తన స్వంత firewall rules ను రాస్తుంది.
• ముందుగానే అందుకు configuration చేయకపోతే reboot తర్వాత containers తిరిగి ప్రారంభం కావు.
• Disk పూర్తిగా నిండే వరకు images, containers, volumes మరియు build cache పెరుగుతూనే ఉంటాయి.

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

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

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

క్రింది సంఖ్యలు default configurationతో Ubuntu 24.04లోని stock images కోసం సాధారణ idle విలువలు. Start చేసిన కొన్ని నిమిషాల తర్వాత docker stats నుంచి వీటిని చదివాం. ఇవి planning కోసం ప్రారంభ అంచనాలు మాత్రమే; మీ workloadకు benchmark కావు. ఏ విలువనైనా, వీటినీ కలుపుకుని, నమ్మే ముందు మీ స్వంత serverలో 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గా ఉండదు. 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 capacity నిర్ణయించేటప్పుడు ప్రధానంగా database మరియు PHP applicationను పరిగణనలోకి తీసుకోవాలి.

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

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

ముందుగా host వినియోగించే memoryని తీసివేయండి. Kernel, systemd, journald, sshd మరియు Docker daemon అన్నీ మీ containers ఉపయోగించే అదే RAMలోనే నడుస్తాయి. dockerd మరియు containerd కలిసి సుమారు 100 MB memoryని ఉపయోగిస్తాయి. Page cache కోసం, అలాగే image build లేదా database dump నడిచే సమయంలో వచ్చే memory పెరుగుదల కోసం కూడా కొంత 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 ఇదొక్కటే. చిన్న planలో reserve 768 MB నుంచి, పెద్ద planలో 1536 MB వరకు పెరుగుతుంది. కారణం, పెద్ద serverలో ఎక్కువ 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 ఒకేసారి సరిపోతాయి. మీకు ముఖ్యమైన workloads కోసం ఉపయోగించదగిన కనిష్ఠ పరిమాణం ఇదే. కారణం, చెడు deploy సమయంలో అదనపు memoryనే లోడ్‌ను తట్టుకుంటుంది.

8 GB planలోని 8192 MBలో containers కోసం 6656 MB మిగులుతుంది. ఈ పరిమాణంలో పరిమితి సాధారణంగా memory నుంచి CPU లేదా disk throughputకు మారుతుంది. మీ stack సరిపోదని లెక్కలు చూపిస్తే, దాన్ని పరిమితుల్లో ఇమిడేలా tuning చేయడం కంటే పెద్ద plan కొనండి: VPS వాస్తవంగా ఎంత ఖర్చవుతుంది అదనపు gigabytesకు నెలకు చెల్లించే మొత్తానికి లభించే విలువను వివరిస్తుంది.

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

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

దాన్ని kernel kill చేసింది. 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 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 timingను మారుస్తుంది, arithmeticను కాదు. చాలా VPS imagesలో swap ఉండదు. swapon --showతో తనిఖీ చేయండి. Swap లేనప్పుడు ఇది ఏ 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

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

UFW నా public చేసిన Docker port ను ఎందుకు block చేయదు?

ట్రాఫిక్ 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 మార్గంలో నిర్వహించబడుతుంది. 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 ను చూపించవచ్చు. మరో machine నుంచి nc -vz your.server.ip 5432 ఇప్పటికీ connect అవుతుంది. Database public internet లో అందుబాటులో ఉంది, కానీ firewall అది అందుబాటులో లేదని చెబుతోంది.

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

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

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

రెండు విషయాలు తప్పనిసరిగా ఉండాలి. 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 reboot తర్వాత containerను తిరిగి ప్రారంభిస్తుంది. మీరు ఉద్దేశపూర్వకంగా ఆపిన containerను ఇది గౌరవిస్తుంది. always మీరు కావాలనే ఆపిన containersను కూడా daemon తిరిగి ప్రారంభమైన ప్రతిసారి మళ్లీ ప్రారంభిస్తుంది. Debugging మధ్యలో ఇది ఊహించని ప్రవర్తనకు కారణమవుతుంది. Fileను సవరించడం మాత్రమే సరిపోదు. Restart policy container సృష్టించిన సమయంలో సెట్ అవుతుంది. Containerను మళ్లీ సృష్టించడానికి docker compose up -d అమలు చేయండి. తరువాత అమలులో ఉన్న valueను తనిఖీ చేయండి:

docker inspect my-app | grep -A3 RestartPolicy

తరువాత ఉద్దేశపూర్వకంగా boxను reboot చేసి, project directoryలో docker compose ps అమలు చేయండి. Planned reboot తర్వాత కూడా పనిచేసే stack, unplanned reboot తర్వాత కూడా పనిచేస్తుంది. మీ stackకు ordering guarantee లేదా boot సమయంలో one-shot 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 నుంచి, apt నుంచి, journald నుంచి, docker pull నుంచి no space left on device కనిపించవచ్చు. PostgreSQL writes స్వీకరించడం ఆపివేస్తుంది. సిస్టమ్ ఇంకా అందుబాటులోనే ఉంటుంది. అందువల్ల reboot loop కంటే సమస్యను గుర్తించడం కష్టమవుతుంది.

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

docker system df
df -h /

docker system df మొత్తం వినియోగాన్ని images, containers, local volumes, build cache గా విభజిస్తుంది. ప్రతి విభాగం పక్కన RECLAIMABLE column ఉంటుంది. స్వయంగా images build చేసే serverలో 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 ను తొలగిస్తుంది. వారాంతం కోసం ఆపివేసిన stack కు ఇదే పరిస్థితి ఉంటుంది. దానితో పాటు దాని database volume కూడా తొలగిపోతుంది. ఆ flag ను type చేయడానికి ముందు bind mounts మరియు named volumes మధ్య తేడా చదవండి. ముందుగా backup తీసుకోండి.

Container logs నెమ్మదిగా పెరుగుతాయి. Default json-file driver కు size limit ఉండదు. అందువల్ల అధికంగా messages రాసే ఒక container, /var/lib/docker/containers లోకి gigabytes డేటాను రాయగలదు. /etc/docker/daemon.json లో ప్రతి container కు పరిమితి విధించండి:

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

sudo systemctl restart docker తో ఈ మార్పును అమలు చేయండి. ఇది మీ containers ను restart చేస్తుంది కాబట్టి సరైన సమయాన్ని ఎంచుకోండి. ఈ పరిమితి మార్పు చేసిన తర్వాత సృష్టించే 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 సెట్ అయి ఉండాలి. అది ఖాళీగా ఉంటే, ఆ container ఈ మార్పుకు ముందు సృష్టించబడింది. అందువల్ల అది ఇంకా ఎలాంటి పరిమితి లేకుండా డేటాను రాస్తోంది.

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

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

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

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

FAQ

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

Docker స్వయంగా తక్కువ వనరులు ఉపయోగిస్తుంది. Daemon మరియు containerd కలిపి సుమారు 100 MB ఉపయోగిస్తాయి. మిగిలిన అవసరం మీ containers పై ఆధారపడి ఉంటుంది. ముందుగా host కోసం అవసరమైన భాగాన్ని కేటాయించండి: 768 MB మొత్తం 2048 MB ఉన్న systemలో operating system, daemon మరియు headroom కోసం ఉంచాలి. అప్పుడు 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 system లో సుమారు సగం memory వినియోగమవుతుంది. మిగిలిన memory ఒక చిన్న application మరియు reverse proxy కి సరిపోతుంది. అయితే నిజమైన load లో database కు సరిపోదు. ఆ పరిమాణం ఉన్న system పై images build చేస్తే అది విఫలమవచ్చు లేదా మరొక process ను ఆపివేయవచ్చు. అందువల్ల images ను వేరే చోట build చేసి, సిద్ధమైన image ను pull చేయండి.

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

మీరు publish చేసిన ports విషయంలో కాదు. Docker తన సొంత DNAT మరియు forward rules ను రాస్తుంది. అందువల్ల publish చేసిన container port కు వచ్చిన packet host కు అందకుండా container కు forward అవుతుంది. UFW నిర్వహించే INPUT rules దాన్ని చూడవు. ఆ port internet నుండి స్పందిస్తున్నప్పటికీ ufw deny 5432 active గా ఉండవచ్చు. 127.0.0.1:5432:5432 తో loopback కు publish చేయండి, internal 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 తిరిగి పొందగల space ను చూపించినప్పుడు prune చేయండి, కానీ ఆ space మీకు అవసరమైతే చేయవద్దు. Services నడుస్తున్నప్పటికీ docker image prune -a మరియు docker builder prune రెండూ సురక్షితమే, ఎందుకంటే ఉపయోగంలో ఉన్న images మరియు cache ను అవి దాటవేస్తాయి. docker system prune --volumes ను నివారించండి. ఏ volumes ను ఎవరూ ఉపయోగించడం లేదో మీకు ఖచ్చితంగా తెలిసినప్పుడు మాత్రమే దాన్ని అమలు చేయండి. లేకపోతే ఆ సమయంలో ఆపి ఉన్న ఏ stack కు చెందిన data అయినా తొలగించబడుతుంది.