VPS-ல் Docker பயன்படுத்தும்போது கவனிக்க வேண்டியவை

VPS-ல் Docker-ஐ இயக்கும்போது ஏற்படும் மாற்றங்கள்

VPS-ல் இயங்கும் Docker, உங்கள் மடிக்கணினியில் இயங்கும் அதே engine மற்றும் images-ஐத்தான் பயன்படுத்துகிறது. எனவே, உங்களுக்குத் தெரிந்த அனைத்து command-களும் இங்கும் வேலை செய்யும். ஆனால், அதைச் சுற்றியுள்ள சூழல் மாறுகிறது. மடிக்கணினியில் போதுமான memory இருக்கும், யாரும் scan செய்யாத firewall இருக்கும், கவனிக்கத் தேவையில்லாத அளவுக்கு பெரிய disk இருக்கும். ஆனால், வாடகைக்கு எடுக்கப்பட்ட server-ல் memory அளவு நிர்ணயிக்கப்பட்டது; boot செய்த சில நிமிடங்களிலேயே public IP address scan செய்யப்படும்; Docker கேட்காமலேயே root filesystem-ஐ நிரப்பிவிடும்.

சிறிய server-களில் பெரும்பாலான சிக்கல்களுக்கு இந்த நான்கு மாற்றங்களே காரணம்:

• Memory அளவு குறைவு. பற்றாக்குறை ஏற்படும்போது, kernel ஏதேனும் ஒரு process-ஐக் கொன்று (kill) சரிசெய்யும்.
• Docker தனது சொந்த firewall விதிகளை எழுதுவதால், publish செய்யப்பட்ட port நேரடியாக UFW (uncomplicated firewall)-ஐத் தாண்டிச் செல்லும்.
• முன்கூட்டியே குறிப்பிடவில்லை என்றால், reboot செய்த பிறகு containers தானாகத் தொடங்காது.
• Images, containers, volumes மற்றும் build cache ஆகியவை disk நிறையும் வரை வளர்ந்துகொண்டே இருக்கும்.

கீழே உள்ள ஒவ்வொரு பகுதியும் ஒரு சிக்கலையும், நீங்கள் திரையில் காணும் பிழைச் செய்தியையும், அதைச் சரிசெய்வதற்கான விரிவான வழிகாட்டியையும் விளக்குகிறது. நீங்கள் இன்னும் compose file எழுதவில்லை என்றால், முதலில் VPS-ல் Docker Compose அடிப்படைகள் என்பதைப் படித்துவிட்டு இங்கே வரவும். இந்த பக்கம், உங்களால் ஏற்கனவே ஒரு stack-ஐ இயக்க முடியும் என்ற அடிப்படையில் எழுதப்பட்டுள்ளது.

Docker container எவ்வளவு RAM-ஐப் பயன்படுத்துகிறது?

பெரும்பாலானோர் எதிர்பார்ப்பதை விட மிகக் குறைவான அளவே. ஒரு container என்பது virtual machine அல்ல, அது cgroup (control group)-ல் இயங்கும் ஒரு process ஆகும். எனவே, இதில் guest kernel கிடையாது, நிலையான ஒதுக்கீடும் (fixed allocation) இல்லை. அந்த process எவற்றையெல்லாம் அணுகுகிறதோ, அதுவே அதன் பயன்பாட்டுச் செலவாகும். இதனால்தான், virtual machine-களைக் கொண்டு கட்டமைக்கப்படும் அதே stack-ஐ விட, ஒரு container stack 2 GB-க்குள் அடங்கிவிடுகிறது.

கீழே உள்ள புள்ளிவிவரங்கள், Ubuntu 24.04-ல் இயல்புநிலை அமைப்புகளுடன் கூடிய stock images-ன் பொதுவான idle பயன்பாட்டு அளவுகள் ஆகும். இவை docker stats மூலம் தொடங்கப்பட்ட சில நிமிடங்களுக்குப் பிறகு எடுக்கப்பட்டவை. இவை திட்டமிடுவதற்கான ஒரு தொடக்கப்புள்ளி மட்டுமே, உங்கள் பணிச்சுமைக்கான (workload) அளவுகோல் அல்ல. எந்தவொரு புள்ளிவிவரத்தையும் நம்புவதற்கு முன், உங்கள் சொந்த 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
  }
]

இந்த இரண்டு நெடுவரிசைகளும் வெவ்வேறு பணிகளைச் செய்கின்றன. idle_mb என்பது container எந்த வேலையும் செய்யாமல் சும்மா இருக்கும்போது பயன்படுத்தும் அளவு. budget_mb என்பது நீங்கள் திட்டமிடும்போது ஒதுக்க வேண்டிய அளவு, ஏனெனில் உண்மையான பயன்பாடு idle நிலையில் இருக்காது. PostgreSQL சும்மா இருக்கும்போது 45 MB-க்கு அருகில் இருக்கும், ஆனால் connections, sorts மற்றும் cache செயல்பாட்டுக்கு வரும்போது 512 MB தேவைப்படும். திட்டமிடும்போது budget நெடுவரிசையைப் பயன்படுத்தவும். பிழைத்திருத்தம் (debug) செய்யும்போது idle நெடுவரிசையைப் பயன்படுத்தவும்.

அந்த 7 வரிசைகளின் அமைப்பைக் கவனிக்கவும். nginx 8 MB-யிலும், Nextcloud 210 MB-யிலும் idle நிலையில் இருக்கும். உங்கள் applications-க்கு முன்னால் இருக்கும் proxy கிட்டத்தட்ட இலவசமாகவே இயங்குகிறது. database மற்றும் PHP application ஆகியவற்றிற்காகவே நீங்கள் server-ன் அளவைத் தீர்மானிக்க வேண்டும்.

docker stats குறித்து ஒரு எச்சரிக்கை: இந்த memory அளவு, container-ன் சொந்த கோப்பு வாசிப்புகளால் (file reads) உருவான page cache-ஐயும் உள்ளடக்கியது. எனவே, தொடங்கிய பிறகு சிறிது நேரம் இந்த அளவு உயர்ந்து, பின் நிலைபெறும். ஏதோ ஒன்று memory leak செய்கிறது என்று முடிவெடுக்கும் முன், ஒரு மணி நேரம் அதைக் கண்காணித்து உறுதிப்படுத்தவும்.

VPS-ன் அளவை தீர்மானித்தல்: 2 GB, 4 GB மற்றும் 8 GB-ல் எவை பொருந்தும்

முதலில் host-ன் பயன்பாட்டிற்கான RAM-ஐ ஒதுக்கிவிட வேண்டும். Kernel, systemd, journald, sshd மற்றும் Docker daemon ஆகிய அனைத்தும் உங்கள் containers இயங்கும் அதே RAM-ல்தான் இயங்குகின்றன. இதில் dockerd மற்றும் containerd ஆகியவை சுமார் 100 MB-ஐ எடுத்துக்கொள்கின்றன. Page cache-க்கும், image build அல்லது database dump போன்ற செயல்களின் போது ஏற்படும் திடீர் சுமைக்கும் போதுமான அளவு free 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 மற்றும் சுமையின் போது server-ன் வேகத்தை பராமரிக்கத் தேவையான headroom ஆகியவற்றைக் குறிக்கிறது. மீதமுள்ளதே container_mb, இதை மட்டுமே நீங்கள் பயன்படுத்த முடியும். இந்த reserve அளவு plan-க்கு ஏற்ப உயரும்; சிறிய server-ல் 768 MB முதல் பெரிய server-ல் 1536 MB வரை இருக்கும். ஏனெனில், பெரிய server-களில் அதிக containers இயங்கும், அதிக logs உருவாகும், மேலும் அதிக page cache தேவைப்படும்.

2 GB plan-ல் containers-க்காக 1280 MB மட்டுமே மீதமிருக்கும். இதில் 512 MB-ஐ PostgreSQL-க்கும், 128 MB-ஐ Traefik-க்கும் ஒதுக்கினால், பாதியளவு முடிந்துவிடும். மீதமுள்ளதில் தலா 256 MB அளவில் இரண்டு சிறிய applications-ஐ மட்டுமே இயக்க முடியும். இது ஒரு பயனுள்ள server-தான், ஆனால் இதில் Nextcloud மற்றும் search cluster ஆகியவற்றை ஒரே நேரத்தில் இயக்க முடியாது.

4 GB plan-ல் 3072 MB மீதமிருக்கும். இதில் ஒரு database, ஒரு reverse proxy, மூன்று applications மற்றும் ஒரு monitoring container ஆகியவற்றை ஒரே நேரத்தில் பொருத்த முடியும். நீங்கள் முக்கியமாகக் கருதும் எதற்கும் இதுவே குறைந்தபட்ச அளவாகும், ஏனெனில் மீதமுள்ள memory-தான் தவறான deployment-ன் போது ஏற்படும் பாதிப்புகளைத் தாங்கும்.

8 GB plan-ல் அதன் 8192 MB-ல் 6656 MB மீதமிருக்கும். இந்த நிலையில், memory-ஐ விட CPU அல்லது disk throughput தான் தடையாக இருக்கும். உங்கள் stack-ன் தேவைக்கு memory போதவில்லை என்றால், அதைச் சரிசெய்ய முயற்சிப்பதை விட பெரிய plan-க்கு மாறுவதே சிறந்தது: VPS-ன் உண்மையான செலவு கூடுதல் gigabytes-ன் மாதந்திர மதிப்பைப் பற்றி விளக்குகிறது.

இந்தக் கணக்கீட்டைச் சரியாக வைத்திருக்க இரண்டு விதிகளைப் பின்பற்றவும். ஒவ்வொரு service-க்கும் memory limit-ஐ அமைக்கவும், அப்போதுதான் ஒரு process கட்டுப்பாட்டை மீறினாலும் அது முழு server-ஐயும் பாதிக்காது. மேலும், budget-ன் ஒரு பகுதியைச் செலவிடாமல் வைத்திருக்கவும், ஏனெனில் docker compose build மற்றும் pg_dump ஆகிய இரண்டும் மிக முக்கியமான தருணங்களில் அதிக memory-ஐக் கோரும். Docker Compose-ல் memory limits பகுதியில் இதற்கான syntax மற்றும் கவனிக்க வேண்டிய விஷயங்கள் உள்ளன.

எனது container ஏன் 137 என்ற code-உடன் வெளியேறுகிறது?

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-ஐப் பாதிக்கும். அப்போது kernel முழு system-லிருந்தும் ஒரு victim-ஐத் தேர்ந்தெடுக்கும். log வரியில் Memory cgroup முன்னொட்டு இருக்காது, அது Out of memory: Killed process 2417 (postgres) என்று காட்டும். அது பெரும்பாலும் உங்கள் database-ஐத் தேர்ந்தெடுக்கும், ஆனால் leak-ஐ ஏற்படுத்திய container தொடர்ந்து இயங்கும். இதனால்தான் எந்தவொரு குறிப்பிட்ட வரம்பை விடவும், ஒவ்வொரு service-க்கும் ஒரு வரம்பை அமைப்பது முக்கியமானது.

Swap என்பது கணக்கீட்டை மாற்றாது, நேரத்தை மட்டுமே மாற்றும். பெரும்பாலான VPS images-ல் swap இருக்காது. swapon --show மூலம் சரிபார்க்கவும்; swap இல்லையெனில் அது எதையும் காட்டாது. ஒரு swap file இருந்தால், kernel பயன்படுத்தப்படாத தரவுகளை (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-ஐ அதிகரிக்காது. தொடர்ச்சியான memory அழுத்தத்தில் உள்ள ஒரு server, உங்களால் SSH செய்ய முடியாத அளவுக்கு மெதுவாகிவிடும். எனவே swap-ஐ ஒரு எச்சரிக்கை buffer-ஆகக் கருதி, memory அளவைச் சரியாகச் சரிசெய்யவும்.

Docker-ல் நான் வெளியிட்ட port-ஐ ஏன் UFW தடுப்பதில்லை?

ஏனெனில், network traffic UFW பாதுகாக்கும் chain-ஐ அடைவதில்லை. நீங்கள் -p 5432:5432 அல்லது compose ports: உள்ளீடு மூலம் ஒரு port-ஐ வெளியிடும்போது, Docker daemon nat table-ல் ஒரு DNAT (destination network address translation) விதியையும், அதன் சொந்த DOCKER chain-ல் ஒரு accept விதியையும் எழுதும். container-ஐ நோக்கிய packet, host-க்கு வழங்கப்படுவதற்குப் பதிலாக நேரடியாக அந்த container-க்கு அனுப்பப்படுகிறது. எனவே, அது FORWARD பாதையில் கையாளப்படுகிறது, UFW எழுதும் INPUT விதிகளின் வழியாக அது செல்வதில்லை.

இது 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 விதி இருக்கும்போது, UFW 5432 DENY IN Anywhere என்று காட்டக்கூடும். மற்றொரு machine-லிருந்து, nc -vz your.server.ip 5432 இன்னும் connect ஆகும். database பொதுவான internet-ல் உள்ளது, ஆனால் firewall அது இல்லை என்று கூறுகிறது.

இதற்கான தீர்வு, குறைவான port-களை வெளியிடுவதுதான். ஒரே compose project-ல் உள்ள containers ஒரு network-ஐப் பகிர்ந்து கொள்கின்றன, மேலும் அவை service name மூலம் ஒன்றையொன்று தொடர்பு கொள்கின்றன. எனவே, அருகில் உள்ள application-க்கு மட்டும் சேவை செய்யும் database-க்கு எந்த ports: உள்ளீடும் தேவையில்லை. உங்களுக்கு 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 ஆகிய port-களில் எதையும் வெளியிடும். Docker வெளியிட்ட ports ஏன் UFW-ஐத் தவிர்க்கின்றன என்ற பகுதி, நீங்கள் ஒரு port-ஐ வெளியிட வேண்டியிருக்கும் அதே வேளையில் அதை filter செய்யவும் வேண்டிய சூழல்களுக்கான DOCKER-USER chain-ஐ விளக்குகிறது. மேலும், UFW firewall அடிப்படைகள் என்ற பகுதி host விதிகளின் செயல்பாட்டை விளக்குகிறது.

Reboot செய்த பிறகு எனது containers ஏன் காணவில்லை?

ஏனெனில், அவை மீண்டும் தொடங்கப்பட வேண்டும் என்று எந்தக் கட்டளையும் இல்லை. நீங்கள் ஒன்றை அமைக்காவிட்டால், ஒரு container இயல்பாகவே no restart policy-உடன் உருவாக்கப்படும்; எனவே, reboot செய்த பிறகு அது நிறுத்தப்பட்ட நிலையிலேயே இருக்கும், Docker daemon அதைப் பற்றி கவலைப்படாது. VPS-களில் reboot என்பது அரிதானது அல்ல: 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 என்பது daemon restart ஆகும்போதெல்லாம் நீங்கள் வேண்டுமென்றே நிறுத்தியவற்றையும் மீண்டும் தொடங்கும், இது debugging செய்யும்போது ஆச்சரியத்தை அளிக்கலாம். கோப்பைத் திருத்துவது மட்டும் போதாது, ஏனெனில் container உருவாக்கப்படும்போதே restart policy நிர்ணயிக்கப்பட்டுவிடும். docker compose up -d கட்டளையை இயக்கினால் அது மீண்டும் உருவாக்கப்படும், பிறகு அதன் தற்போதைய மதிப்பைச் சரிபார்க்கவும்:

docker inspect my-app | grep -A3 RestartPolicy

பிறகு, திட்டமிட்டு server-ஐ reboot செய்து, project directory-ல் docker compose ps கட்டளையை இயக்கவும். திட்டமிட்ட reboot-ல் இயங்கும் stack, திட்டமிடப்படாத reboot-லும் இயங்கும். உங்கள் stack-க்கு boot-ன் போது ஒரு குறிப்பிட்ட வரிசை அல்லது ஒருமுறை மட்டும் இயங்கும் பணி தேவைப்பட்டால், systemd unit சிறந்த கருவியாகும்: Docker Compose-ஐ boot-ல் தொடங்குதல் பகுதியில் unit file உள்ளது. மீண்டும் வந்த container உண்மையில் service வழங்குகிறதா என்பதை அறிய, Compose healthchecks-ஐச் சேர்க்கவும்.

எனது VPS disk ஏன் நிரம்பிவிட்டது?

Docker-ல் நீங்கள் நீக்கும் வரை அனைத்தும் சேமிக்கப்படும் என்பதே இதற்குக் காரணம். நீங்கள் தரவிறக்கம் செய்த ஒவ்வொரு image tag, நிறுத்தப்பட்ட container, recreate செய்யும்போது விடப்பட்ட anonymous volume மற்றும் build cache-ன் ஒவ்வொரு layer-ம் disk-ல் தங்கிவிடும். இந்த அளவிலான plan-களில் பொதுவாக இருக்கும் 40 GB அல்லது 80 GB root filesystem-ல், இது சில ஆண்டுகளில் அல்ல, சில மாதங்களிலேயே outage-ஐ ஏற்படுத்திவிடும்.

Disk நிரம்பியிருப்பது ஒரு crash போலத் தெரியாது. ஒரே மணி நேரத்தில் container-லிருந்து no space left on device, apt, journald மற்றும் docker pull ஆகியவற்றிலிருந்து பிழைகள் வரும். PostgreSQL தரவுகளை எழுதுவதை நிறுத்திவிடும். Server இயங்கிக்கொண்டே இருக்கும் என்பதால், reboot loop-ஐ விட இதைக் கண்டறிவது கடினம்.

நீக்குவதற்கு முன் சரிபார்க்கவும்:

docker system df
df -h /

docker system df மொத்த இடத்தையும் images, containers, local volumes மற்றும் build cache எனப் பிரித்துக் காட்டும், அதனுடன் ஒவ்வொரு வரிசையிலும் RECLAIMABLE என்ற column இருக்கும். சொந்தமாக images உருவாக்கும் server-களில், build cache பொதுவாகவே அதிக இடத்தை ஆக்கிரமித்திருக்கும்.

docker image prune -a
docker builder prune
docker system df

docker image prune -a எந்த container-ஆலும் பயன்படுத்தப்படாத அனைத்து images-களையும் நீக்கும். docker builder prune build cache-ஐ அழிக்கும். இவை இரண்டுமே services இயங்கிக்கொண்டிருக்கும்போது பாதுகாப்பானவை, ஏனெனில் பயன்பாட்டில் உள்ளவை தவிர்க்கப்படும். docker system prune --volumes பாதுகாப்பானது அல்ல, ஏனெனில் இது தற்போது எந்த container-ஆலும் பயன்படுத்தப்படாத அனைத்து volumes-களையும் நீக்கிவிடும். வார இறுதி நாட்களுக்காக நீங்கள் நிறுத்தி வைத்திருக்கும் stack-ன் database volume-ம் இதனுடன் சேர்ந்து அழிந்துவிடும். அந்த flag-ஐப் பயன்படுத்துவதற்கு முன் bind mounts versus named volumes என்பதைப் படித்துவிட்டு, முதலில் backup எடுக்கவும்.

Container logs மெதுவாக வளர்ந்து இடத்தை நிரப்பும். இயல்பான json-file driver-க்கு அளவு வரம்பு இல்லை, எனவே அதிக தகவல்களை எழுதும் ஒரு 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-க்கு மட்டுமே பொருந்தும், எனவே இயங்கிக்கொண்டிருக்கும் containers-ஐ docker compose up -d --force-recreate மூலம் recreate செய்து உறுதிப்படுத்தவும்:

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

Inspect வெளியீட்டில் max-size அமைக்கப்பட்டிருப்பதை உறுதி செய்ய வேண்டும். அது காலியாக இருந்தால், அந்த container மாற்றத்திற்கு முன்பே உருவாக்கப்பட்டது மற்றும் இன்னும் வரம்பின்றி தரவுகளை எழுதிக்கொண்டிருக்கிறது என்று அர்த்தம்.

சிறிய Docker box-ஐ ஆரோக்கியமாக வைத்திருக்கும் பழக்கவழக்கங்கள்

இதற்கு எந்தவொரு dashboard-ஓ அல்லது நீங்கள் புதிதாகக் கற்க வேண்டிய கருவியோ தேவையில்லை.

• ஒவ்வொரு மாதத்தின் முதல் தேதியிலும் docker system df மற்றும் df -h / ஆகியவற்றை இயக்கவும். இரண்டு கட்டளைகள், முப்பது வினாடிகள்; இது ஒரு பெரிய பாதிப்பை ஏற்படுத்தும் முன்பே அதன் போக்கை உங்களுக்குக் காட்டிவிடும்.
• சிறியவை என்று நீங்கள் கருதும் சேவைகள் உட்பட, ஒவ்வொரு சேவைக்கும் ஒரு memory limit-ஐ நிர்ணயிக்கவும். இந்த வரம்பு, முழு host-ம் செயலிழப்பதைத் தடுத்து, பாதிக்கப்பட்ட ஒரு container-ஐ மட்டும் restart செய்ய உதவும்.
• kernel செயல்படும் முன்பே memory அல்லது disk அழுத்தம் குறித்து நீங்கள் அறிந்துகொள்ள, வேறொரு இடத்திலிருந்து உங்கள் box-ஐக் கண்காணிக்கவும். Uptime Kuma ஒரு container-ல் இயங்குகிறது மற்றும் சும்மா இருக்கும்போது சுமார் 95 MB-ஐ மட்டுமே பயன்படுத்துகிறது.
• container-களை அல்ல, volume-களை backup எடுக்கவும். container-ஐ எப்போது வேண்டுமானாலும் நீக்கலாம், ஆனால் volume-ஐ நீக்க முடியாது. restic backups on a VPS என்பது ஒரு கால அட்டவணை மற்றும் restore சோதனையை உள்ளடக்கியது.
• compose file-ல் image tag-களைப் பூட்டி (pin) வைக்கவும், நீங்கள் விரும்பும் நாளில் அவற்றை update செய்யவும். latest-ஐப் பயன்படுத்தினால், அடுத்த docker compose pull-ல் உங்களுக்குக் கிடைக்கும் பதிப்பு, அன்று காலை வெளியிடப்பட்டதாகவே இருக்கும்.

நான்கு விஷயங்களைச் சரியாகக் கவனித்துக்கொண்டால், Docker இயங்கும் ஒரு சிறிய VPS பல ஆண்டுகள் ஆரோக்கியமாக இருக்கும்: memory பட்ஜெட், திறக்கப்பட்ட ports-ன் பட்டியல், ஒவ்வொரு சேவைக்கும் உள்ள restart policy மற்றும் மீதமுள்ள disk அளவு. மற்றபடி, நீங்கள் ஏற்கனவே வீட்டில் பயன்படுத்தும் அதே Docker தான் இதுவும்.

FAQ

VPS-ல் Docker-ஐ இயக்க எனக்கு எவ்வளவு RAM தேவை?

Docker-ன் தேவை குறைவுதான். அதன் daemon மற்றும் containerd ஆகிய இரண்டும் சேர்ந்து சுமார் 100 MB-ஐ மட்டுமே எடுத்துக்கொள்ளும்; மீதமுள்ள தேவை உங்கள் containers-ஐப் பொறுத்தது. முதலில் host-க்கான தேவையை ஒதுக்குங்கள்: 2048 MB அளவுள்ள ஒரு box-ல், operating system, daemon மற்றும் இதர தேவைகளுக்காக 768 MB-ஐ ஒதுக்கிவிட்டு, மீதமுள்ள 1280 MB-ஐ containers-க்காகப் பயன்படுத்தலாம். 512 MB-ல் ஒரு database, 128 MB-ல் ஒரு reverse proxy மற்றும் இரண்டு சிறிய applications ஆகியவற்றை இதற்குள் அடக்க முடியும். எங்கும் குறிப்பிடப்பட்டுள்ள புள்ளிவிவரங்களை நம்புவதை விட, docker stats --no-stream மூலம் உங்கள் stack-ன் பயன்பாட்டை நீங்களே அளவிடுங்கள்.

1 GB RAM கொண்ட VPS-ல் Docker-ஐ இயக்க முடியுமா?

ஆம், ஒன்று அல்லது இரண்டு சிறிய containers-ஐ இயக்க முடியும். தொடங்குவதற்கு முன் ஒரு swap file-ஐச் சேர்த்துக்கொள்ளுங்கள். 1 GB box-ல் operating system மற்றும் Docker daemon இயங்கத் தொடங்கியவுடனேயே பாதி அளவு RAM தீர்ந்துவிடும். மீதமுள்ள இடத்தில் ஒரு சிறிய application மற்றும் reverse proxy-ஐ இயக்கலாம், ஆனால் அதிக சுமை கொண்ட database-ஐ இயக்க முடியாது. இவ்வளவு சிறிய அளவில் images-ஐ build செய்தால், அது தோல்வியடையலாம் அல்லது பிற process-களை முடக்கலாம். எனவே, வேறு இடத்தில் build செய்து, தயாரான image-ஐ மட்டும் pull செய்யுங்கள்.

UFW ஒரு Docker container-ஐப் பாதுகாக்குமா?

நீங்கள் publish செய்யும் ports-க்கு இது பொருந்தாது. Docker தனது சொந்த DNAT மற்றும் forward விதிகளை எழுதும். எனவே, publish செய்யப்பட்ட container port-க்கு வரும் network traffic, host-க்கு வராமல் நேரடியாக container-க்குச் சென்றுவிடும். UFW நிர்வகிக்கும் INPUT விதிகள் இதைக் கவனிக்காது. அந்த port internet-ல் பதிலளிக்கும்போது ufw deny 5432 செயல்பாட்டில் இருக்கலாம். 127.0.0.1:5432:5432 மூலம் loopback-க்கு மட்டும் publish செய்யுங்கள், internal services-ஐ publish செய்யாதீர்கள், அல்லது DOCKER-USER chain-ல் filter செய்யுங்கள்.

VPS reboot செய்யப்பட்ட பிறகு எனது containers மீண்டும் தொடங்குமா?

restart policy-உடன் உருவாக்கப்பட்டிருந்தால் மட்டுமே அவை மீண்டும் தொடங்கும். ஒவ்வொரு service-க்கும் restart: unless-stopped-ஐ அமைத்து, docker compose up -d-ஐ இயக்கினால் மட்டுமே containers அதற்கேற்ப மீண்டும் உருவாக்கப்படும். systemctl is-enabled docker கட்டளையை இயக்கும்போது enabled என்று வருகிறதா என்பதை உறுதிப்படுத்தவும். பிறகு, நீங்களாகவே ஒருமுறை reboot செய்து docker compose ps மூலம் சரிபார்க்கவும். நீங்கள் சோதித்துப் பார்க்காத restart policy, ஒரு உண்மையான policy ஆகாது.

Docker images-ஐ எவ்வளவு அடிக்கடி நீக்க (prune) வேண்டும்?

பெரும்பாலான சிறிய servers-க்கு மாதத்திற்கு ஒருமுறை போதுமானது. அல்லது docker system df மூலம் உங்களுக்குத் தேவையான அளவு இடம் காலியாகிறது என்று தெரிந்தால் அப்போது செய்யலாம். docker image prune -a மற்றும் docker builder prune ஆகியவற்றை services இயங்கும்போது பயன்படுத்துவது பாதுகாப்பானது, ஏனெனில் பயன்பாட்டில் உள்ள images மற்றும் cache தவிர்க்கப்படும். docker system prune --volumes-ஐப் பயன்படுத்துவதைத் தவிர்க்கவும்; எந்தெந்த volumes பயன்பாட்டில் இல்லை என்பது உங்களுக்குத் தெரிந்தால் ஒழிய இதைப் பயன்படுத்த வேண்டாம், ஏனெனில் இது நிறுத்தப்பட்டிருக்கும் எந்தவொரு stack-ன் தரவையும் அழித்துவிடும்.