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 விதிகளை எழுதுவதால், published port-கள் UFW (uncomplicated firewall)-ஐத் தாண்டி நேரடியாகச் செயல்படும்.
• நீங்கள் முன்கூட்டியே குறிப்பிடவில்லை என்றால், reboot செய்த பிறகு containers தானாகத் தொடங்காது.
• Images, containers, volumes மற்றும் build cache ஆகியவை disk முழுமையாக நிறையும் வரை வளர்ந்துகொண்டே இருக்கும்.

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

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

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

கீழே உள்ள புள்ளிவிவரங்கள், Ubuntu 24.04-ல் இயல்புநிலை அமைப்புகளுடன் கூடிய stock images-ன் பொதுவான idle நிலைக் கணக்கீடுகள் ஆகும். இவை 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 என்பது container எந்த வேலையும் செய்யாமல் சும்மா இருக்கும்போது பயன்படுத்தும் அளவு. budget_mb என்பது நீங்கள் திட்டமிடும்போது ஒதுக்க வேண்டிய அளவு, ஏனெனில் உண்மையான பயன்பாடு idle நிலையில் இருக்காது. PostgreSQL சும்மா இருக்கும்போது 45 MB அளவில் இருக்கும், ஆனால் இணைப்புகள், வரிசைப்படுத்துதல் (sorts) மற்றும் cache ஆகியவை செயல்படத் தொடங்கும்போது 512 MB தேவைப்படும். பட்ஜெட் நெடுவரிசையைக் கொண்டு திட்டமிடுங்கள். Idle நெடுவரிசையைக் கொண்டு பிழைத்திருத்தம் (debug) செய்யுங்கள்.

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

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

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 போன்ற செயல்பாடுகளின் போது ஏற்படும் திடீர் சுமைக்காகவும் போதிய அளவு 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-க்கு ஏற்ப அதிகரிக்கும். சிறிய box-ல் 768 MB முதல் பெரிய box-ல் 1536 MB வரை இது இருக்கும். ஏனெனில் பெரிய box-ல் அதிக 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-தான் ஏதேனும் ஒரு deploy தோல்வியடையும் போது server-ஐப் பாதுகாக்கும்.

8 GB plan-ல் அதன் 8192 MB-ல் 6656 MB மீதமிருக்கும். இந்த அளவில் memory-ஐ விட CPU அல்லது disk throughput தான் முக்கிய தடையாக இருக்கும். சில containers சுமையைப் பொறுத்து அல்லாமல், அவற்றின் configuration-ஐப் பொறுத்து memory-ஐ எடுத்துக்கொள்ளும். உதாரணமாக, ஒரு local model server அதன் context window-க்கு ஏற்ப KV cache-ஐ ஒதுக்கும். எனவே, Ollama-ன் num_ctx-ஐ அதிகரிப்பது ஒரு request வருவதற்கு முன்பே பல gigabytes-ஐப் பயன்படுத்தக்கூடும். உங்கள் stack பொருந்தவில்லை என்றால், அதைச் சரிசெய்ய முயற்சிப்பதை விட பெரிய plan-க்கு மாறுவதே சிறந்தது: VPS-ன் உண்மையான செலவு என்பது கூடுதல் gigabytes-க்கு மாதந்தோறும் எவ்வளவு செலவாகும் என்பதை விளக்குகிறது.

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

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

Swap நேரத்தை மாற்றும், கணக்கீட்டை அல்ல. பெரும்பாலான VPS images-ல் swap இருப்பதில்லை. swapon --show மூலம் சரிபார்க்கவும், swap இல்லையெனில் அது எதையும் காட்டாது. ஒரு 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

free -h இப்போது Swap வரிசையில் பூஜ்ஜியமற்ற மொத்த மதிப்பைக் காட்ட வேண்டும். Swap என்பது RAM-ஐ அதிகரிக்காது. தொடர்ச்சியான நினைவக அழுத்தத்தில் உள்ள ஒரு இயந்திரம், நீங்கள் SSH மூலம் உள்ளே சென்று சரிசெய்ய முடியாத அளவுக்கு மெதுவாகிவிடும், எனவே swap-ஐ ஒரு எச்சரிக்கை இடையகமாக (alarm buffer) கருதி, அதன் அளவைச் சரியாக அமைக்கவும்.

எனது Docker port-ஐ UFW ஏன் தடுப்பதில்லை?

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

சர்வரில் இது எவ்வாறு நடக்கிறது என்பதை நீங்கள் கவனிக்கலாம்:

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

UFW-ல் 5432 DENY IN Anywhere என்று காட்டினாலும், அதே port-க்காக nat table-ல் ஒரு DNAT tcp ... to:172.18.0.2:5432 விதி இருக்கலாம். மற்றொரு கணினியிலிருந்து, nc -vz your.server.ip 5432 மூலம் இன்னும் இணைக்க முடியும். Database பொது இணையத்தில் (public internet) உள்ளது, ஆனால் firewall அது இல்லை என்று கூறுகிறது.

இதற்கான தீர்வு, குறைவான port-களை publish செய்வதாகும். ஒரே 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-களில் எதையும் publish செய்யும். நீங்கள் ஒரு port-ஐ publish செய்து, அதை filter செய்ய வேண்டிய சூழலில் DOCKER-USER chain-ஐப் பயன்படுத்துவது குறித்து Docker publish செய்த port-கள் ஏன் UFW-ஐத் தவிர்க்கின்றன விளக்குகிறது. மேலும், host விதிகளின் அடிப்படை குறித்து UFW firewall அடிப்படைகள் பகுதியில் காணலாம்.

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

ஏனெனில் அவை மீண்டும் தொடங்கப்பட வேண்டும் என்று எந்தக் கட்டளையும் இல்லை. நீங்கள் எதையும் அமைக்கவில்லை என்றால், ஒரு container இயல்பாகவே no restart policy-உடன் உருவாக்கப்படும். எனவே, reboot செய்யும்போது அது நிறுத்தப்பட்ட நிலையிலேயே இருக்கும், Docker daemon அதைப் பற்றி கவலைப்படாது. VPS-களில் reboot என்பது அரிதானது அல்ல: unattended upgrades மூலம் வரும் kernel updates, provider maintenance, மற்றும் மேலே குறிப்பிட்ட OOM sequence ஆகிய அனைத்தும் reboot-க்கு வழிவகுக்கும்.

இரண்டு விஷயங்கள் சரியாக இருக்க வேண்டும். முதலில், boot ஆகும்போது daemon தொடங்கப்பட வேண்டும்:

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 என்பது, daemon restart ஆகும்போது நீங்கள் வேண்டுமென்றே நிறுத்திய container-களையும் மீண்டும் தொடங்கிவிடும், இது 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 ஆகும்போது ஒரு குறிப்பிட்ட வரிசைமுறை அல்லது ஒருமுறை மட்டும் இயங்கும் job தேவைப்பட்டால், systemd unit சிறந்த கருவியாகும்: starting Docker Compose on boot பகுதியில் அதற்கான unit file உள்ளது. மீண்டும் வந்த container உண்மையில் இயங்குகிறதா என்பதை அறிய, Compose healthchecks-ஐச் சேர்க்கவும்.

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

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

வட்டு நிரம்புவது ஒரு 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 (மீட்கக்கூடிய) அளவு இருக்கும். சொந்தமாக 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-ஐ அழிக்கும். சேவைகள் இயங்கிக்கொண்டிருக்கும்போது இவை இரண்டையும் செய்வது பாதுகாப்பானது, ஏனெனில் பயன்பாட்டில் உள்ளவை தவிர்க்கப்படும். docker system prune --volumes கட்டளையைப் பயன்படுத்துவது பாதுகாப்பானது அல்ல, ஏனெனில் இது எந்த container-ஆலும் தற்போது பயன்படுத்தப்படாத அனைத்து volumes-களையும் நீக்கிவிடும். வார இறுதி நாட்களில் நீங்கள் நிறுத்தி வைக்கும் stack-களும் இந்த நிலையில்தான் இருக்கும், எனவே அதன் database volume-ம் நீக்கப்பட்டுவிடும். அந்த flag-ஐப் பயன்படுத்தும் முன் bind mounts மற்றும் 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 மூலம் செயல்படுத்தவும்; இது உங்கள் container-களை restart செய்யும், எனவே சரியான நேரத்தைத் தேர்வு செய்யவும். இந்த வரம்பு மாற்றத்திற்குப் பிறகு உருவாக்கப்படும் container-களுக்கு மட்டுமே பொருந்தும், எனவே இயங்கிக்கொண்டிருக்கும் container-களை docker compose up -d --force-recreate மூலம் மறு உருவாக்கம் செய்து உறுதிப்படுத்தவும்:

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

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

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

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

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

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

FAQ

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

Docker-ன் பயன்பாடு குறைவானது. அதன் daemon மற்றும் containerd ஆகிய இரண்டும் சேர்ந்து சுமார் 100 MB-ஐ மட்டுமே எடுத்துக்கொள்ளும்; மீதமுள்ள தேவை உங்கள் containers-ஐப் பொறுத்தது. முதலில் host-க்கான தேவையை ஒதுக்குங்கள்: 2048 MB அளவுள்ள ஒரு box-ல், operating system, daemon மற்றும் இதர தேவைகளுக்காக 768 MB-ஐ ஒதுக்கிவிட்டு, மீதமுள்ள 1280 MB-ஐப் பயன்படுத்தலாம். 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 விதிகளை எழுதும்; எனவே, ஒரு container port-க்கு வரும் network packet, host-க்கு வராமல் நேரடியாக container-க்கு அனுப்பப்படும். UFW நிர்வகிக்கும் INPUT விதிகள் இதைக் கவனிக்காது. அந்த port internet-ல் பதிலளிக்கும்போது ufw deny 5432 செயல்பாட்டில் இருக்கலாம். 127.0.0.1:5432:5432 மூலம் loopback-க்கு மட்டும் publish செய்யுங்கள், internal services-ஐ publish செய்யாமல் விடுங்கள், அல்லது DOCKER-USER chain-ல் வடிகட்டுங்கள்.

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-ன் தரவையும் நீக்கிவிடும்.