VPS-এ Docker চালালে কী কী বদলে যায়

VPS-এ Docker চালালে কী পরিবর্তন হয়

VPS-এ Docker আপনার ল্যাপটপের Docker-এর মতোই একই engine এবং একই image চালায়। তাই আপনি আগে থেকে জানা প্রতিটি command এখনও কাজ করে। পরিবর্তন হয় Docker-এর চারপাশের সীমাবদ্ধতায়। একটি ল্যাপটপে অতিরিক্ত memory থাকে, এমন firewall থাকে যেটি কেউ scan করছে না, এবং disk এত বড় থাকে যে আপনাকে সেটি পরীক্ষা করতে হয় না। ভাড়া করা server-এ memory-এর নির্দিষ্ট সীমা থাকে, এমন একটি public IP address থাকে যেটি boot করার কয়েক মিনিটের মধ্যেই scan শুরু হয়, এবং এমন root filesystem থাকে যেটি কোনো অনুমতি না নিয়েই Docker পূর্ণ করে ফেলবে।

ছোট server-এ বেশিরভাগ সমস্যার কারণ চারটি পার্থক্য:

• Memory সীমিত, এবং kernel সাধারণত memory ঘাটতি হলে কোনো process বন্ধ করে দেয়।
• Published port সরাসরি UFW (uncomplicated firewall) পেরিয়ে যায়, কারণ Docker নিজস্ব firewall rule লিখে।
• আগে থেকে নির্দেশ না দিলে reboot-এর পরে container আবার চালু হয় না।
• Image, container, volume এবং build cache বাড়তে থাকে, যতক্ষণ না disk পূর্ণ হয়ে যায়।

নিচের প্রতিটি section-এ সমস্যাটির নাম, আপনি বাস্তবে যে string দেখতে পাবেন, এবং সেটি বিস্তারিতভাবে সমাধানকারী guide দেওয়া হয়েছে। আপনি এখনও compose file না লিখে থাকলে, আগে VPS-এ Docker Compose-এর মৌলিক বিষয় পড়ে ফিরে আসুন। এই page ধরে নিচ্ছে যে আপনি ইতিমধ্যে একটি stack চালু করতে পারেন।

Docker container কত RAM ব্যবহার করে?

বেশিরভাগ মানুষ যতটা ভাবেন, তার চেয়ে কম। Container হলো একটি cgroup (control group)-এর মধ্যে চলা process, virtual machine নয়। তাই এর নিজস্ব guest kernel থাকে না এবং RAM-এর কোনো নির্দিষ্ট allocation-ও থাকে না। খরচ নির্ভর করে container-এর ভেতরের process কোন resource ব্যবহার করছে তার ওপর। এ কারণেই virtual machine দিয়ে তৈরি একই stack যেখানে 2 GB-তে চলবে না, সেখানে container-ভিত্তিক পুরো stack 2 GB-তে চলতে পারে।

নিচের পরিমাণগুলো Ubuntu 24.04-এ default configuration-সহ stock image-এর সাধারণ idle usage। এগুলো start হওয়ার কয়েক মিনিট পরে docker stats থেকে নেওয়া হয়েছে। এগুলো workload benchmark নয়; capacity planning-এর প্রাথমিক নির্দেশনা হিসেবে ব্যবহার করুন। কোনো figure, এমনকি এগুলোও, নির্ভরযোগ্য ধরে নেওয়ার আগে নিজের 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
  }
]

দুটি column-এর কাজ আলাদা। idle_mb container নিষ্ক্রিয় অবস্থায় কত RAM ব্যবহার করে তা দেখায়। budget_mb planning-এর সময় কত RAM reserve করতে হবে তা দেখায়, কারণ বাস্তব ব্যবহার idle থাকে না। PostgreSQL idle অবস্থায় প্রায় 45 MB ব্যবহার করে, কিন্তু connection, sort এবং cache সক্রিয় হলে এর জন্য 512 MB দরকার হয়। Planning-এর সময় budget column ব্যবহার করুন। Debugging-এর সময় idle column ব্যবহার করুন।

7টি row-এর ধরণটি লক্ষ্য করুন। nginx idle অবস্থায় 8 MB ব্যবহার করে এবং Nextcloud ব্যবহার করে 210 MB। আপনার application-এর সামনে থাকা proxy-এর RAM usage প্রায় নেই বললেই চলে। Server-এর capacity মূলত database এবং PHP application-এর জন্য নির্ধারণ করতে হবে।

docker stats সম্পর্কে একটি সতর্কতা: এই memory figure-এর মধ্যে page cache-ও অন্তর্ভুক্ত থাকে। Container-এর নিজস্ব file read-এর কারণে এই cache তৈরি হয়। তাই start হওয়ার পর কিছু সময় memory usage বাড়তে পারে এবং পরে স্থিতিশীল হয়। কোনো memory leak আছে কি না সিদ্ধান্ত নেওয়ার আগে এক ঘণ্টা এটি monitor করুন।

VPS-এর আকার নির্ধারণ: 2 GB, 4 GB এবং 8 GB-তে কী রাখা যায়

প্রথমে host-এর অংশ বাদ দিন। Kernel, systemd, journald, sshd এবং Docker daemon আপনার container-গুলোর সঙ্গে একই 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 এবং load-এর সময় box-কে responsive রাখার জন্য প্রয়োজনীয় headroom রয়েছে। অবশিষ্ট অংশ হলো container_mb, এবং খরচ করার জন্য আপনার কাছে এটিই একমাত্র সংখ্যা। সবচেয়ে ছোট box-এ 768 MB থেকে সবচেয়ে বড় box-এ 1536 MB পর্যন্ত reserve বাড়ে, কারণ বড় box-এ বেশি container চলে, বেশি log লেখা হয় এবং বেশি page cache প্রয়োজন হয়।

2 GB plan-এ container-এর জন্য 1280 MB থাকে। এর মধ্যে PostgreSQL-এর জন্য 512 MB এবং Traefik-এর জন্য 128 MB ব্যবহার করলে অর্ধেক memory ইতিমধ্যে শেষ। বাকি memory-তে প্রায় 256 MB করে 2টি ছোট application চালানো যায়। এটি বাস্তবসম্মত এবং কার্যকর একটি server। তবে এর ওপর Nextcloud এবং একটি search cluster চালানোর মতো অতিরিক্ত জায়গা নেই।

4 GB plan-এ 3072 MB থাকে। এতে একটি database, একটি reverse proxy, 3টি application এবং একটি monitoring container একসঙ্গে চালানো যায়। আপনি যে service-গুলোকে গুরুত্বপূর্ণ মনে করেন, সেগুলোর জন্য এটি ব্যবহারযোগ্য সর্বনিম্ন আকার, কারণ অতিরিক্ত memory-ই একটি ত্রুটিপূর্ণ deploy-এর চাপ সামলে নেয়।

8 GB plan-এ মোট 8192 MB-এর মধ্যে 6656 MB থাকে, এবং সীমাবদ্ধতা সাধারণত memory থেকে CPU বা disk throughput-এ চলে যায়। SSD Nodes এর চেয়ে ছোট কিছু বিক্রি করে না: তাদের সর্বনিম্ন plan-এ 8 GB RAM রয়েছে (pricing page 2026-10-11 তারিখে পরীক্ষা করা হয়েছে)। তাই ওই host-এ এই সারিটিই প্রযোজ্য, আর 2 GB ও 4 GB-এর সারিগুলো অন্যান্য provider-এর ছোট box বোঝায়। একটি ধরনের container load-এর পরিবর্তে configuration অনুযায়ী নিজের আকার নির্ধারণ করে: local model server তার context window-এর অনুপাতে KV cache reserve করে। তাই একটি request আসার আগেই Ollama-এর num_ctx বাড়ালে budget-এ gigabytes যোগ হতে পারে। হিসাব অনুযায়ী আপনার stack না ধরলে tuning করে জায়গা বের করার বদলে বড় plan কিনুন: VPS-এর প্রকৃত খরচ প্রতি মাসে অতিরিক্ত gigabytes-এর মূল্য ব্যাখ্যা করে।

2টি নিয়ম মেনে চললে হিসাব বাস্তবসম্মত থাকে। প্রতিটি service-এর জন্য memory limit নির্ধারণ করুন, যাতে একটি runaway process পুরো box-কে অচল করে দিতে না পারে। আর budget-এর একেবারে শেষ অংশ খরচ করবেন না, কারণ docker compose build এবং pg_dump উভয়েরই সবচেয়ে খারাপ সময়ে memory প্রয়োজন হয়। Docker Compose-এ Memory limit-এ syntax এবং সাধারণ সমস্যাগুলো ব্যাখ্যা করা হয়েছে।

আমার container code 137 দিয়ে বন্ধ হয় কেন?

কারণ kernel এটিকে kill করেছে। 137 হলো 128 plus 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-এর মধ্যেই সীমাবদ্ধ থাকে। খারাপ পরিস্থিতি হলো এমন container, যার কোনো limit নেই। Limit না থাকলে তার সর্বোচ্চ সীমা পুরো machine, তাই একটি service-এর memory leak host-এর memory ফুরিয়ে দেয়। এরপর kernel পুরো system-এর process-গুলোর মধ্যে আকারের ভিত্তিতে একটি victim বেছে নেয়। Log line-এ Memory cgroup prefix থাকে না এবং তা Out of memory: Killed process 2417 (postgres) হিসেবে দেখা যায়। Kernel যে process বেছে নেয়, সেটি প্রায়ই আপনার database হয়, অথচ যে container memory leak করেছে সেটি চলতেই থাকে। তাই প্রতিটি service-এর জন্য limit নির্ধারণ করা যেকোনো একটি limit-এর সঠিক value নির্ধারণের চেয়ে বেশি গুরুত্বপূর্ণ।

Swap সময়ের পরিবর্তন ঘটায়, হিসাবের নয়। অধিকাংশ VPS image-এ কোনো swap থাকে না। swapon --show দিয়ে পরীক্ষা করুন; swap না থাকলে এটি একেবারেই কিছু output দেয় না। একটি swap file kernel-কে কম ব্যবহৃত page রাখার জায়গা দেয়। এতে সমস্যা বুঝে ব্যবস্থা নেওয়ার জন্য কয়েক মিনিট অতিরিক্ত সময় পাওয়া যায়।

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-তে non-zero total দেখা যাওয়ার কথা। Swap RAM যোগ করে না। কোনো machine সব সময় memory pressure-এর মধ্যে থাকলে সেটি এত ধীর হয়ে যায় যে সমস্যাটি ঠিক করতে আপনি SSH-তে ঢুকতে পারেন না। তাই swap-কে alarm buffer হিসেবে ব্যবহার করুন এবং memory sizing ঠিক করুন।

UFW কেন প্রকাশিত Docker port ব্লক করে না?

কারণ network 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 path-এ প্রক্রিয়াকৃত হয় এবং UFW যে INPUT rule লেখে, সেগুলোর মধ্য দিয়ে যায় না।

সার্ভারে আপনি এই প্রক্রিয়া দেখতে পারেন:

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

UFW 5432 DENY IN Anywhere দেখাতে পারে, অথচ nat table-এ একই port-এর জন্য DNAT tcp ... to:172.18.0.2:5432 rule থাকতে পারে। অন্য একটি machine থেকে nc -vz your.server.ip 5432 দিয়েও সংযোগ করা যায়। Database public Internet-এ উন্মুক্ত, কিন্তু firewall দেখাচ্ছে যে এটি উন্মুক্ত নয়।

সমাধান হলো কম port publish করা। একই Compose project-এর container-গুলো একটি network share করে এবং service name ব্যবহার করে একে অপরের কাছে পৌঁছাতে পারে। তাই যে database শুধু তার পাশের application-কে service দেয়, তার জন্য কোনো 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 port publish করে। port publish করতেই হবে কিন্তু সেটিতে filter প্রয়োগ করতে হবে—এমন ক্ষেত্রে DOCKER-USER chain সম্পর্কে Docker-এর প্রকাশিত port কীভাবে UFW পাশ কাটায় দেখুন। Host-এর নিচের স্তরের rule সম্পর্কে UFW firewall-এর মৌলিক বিষয় দেখুন।

রিবুটের পরে আমার container-গুলো চলে যায় কেন?

কারণ সেগুলোকে আবার চালু হওয়ার নির্দেশ দেওয়া হয়নি। কোনো restart policy নির্ধারণ না করলে একটি container no policy নিয়ে তৈরি হয়। তাই রিবুটের পরে সেটি stopped অবস্থায় থাকে এবং daemon সেটি নিয়ে কোনো ব্যবস্থা নেয় না। VPS-এ রিবুট অস্বাভাবিক ঘটনা নয়। unattended upgrade-এর kernel update, provider-এর maintenance এবং উপরের OOM sequence—সবই রিবুট ঘটাতে পারে।

দুটি বিষয় নিশ্চিত হতে হবে। রিবুটের সময় daemon-কে অবশ্যই চালু হতে হবে:

systemctl is-enabled docker

সাধারণ Ubuntu install-এ এটি enabled output দেখায়। এরপর প্রতিটি service-এর জন্য একটি policy নির্ধারণ করুন:

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

unless-stopped রিবুটের পরে container-কে আবার চালু করে এবং আপনি ইচ্ছাকৃতভাবে বন্ধ করা container-কে সম্মান করে। always daemon restart হলে ইচ্ছাকৃতভাবে বন্ধ করা container-ও আবার চালু করে। Debugging-এর মাঝখানে এটি অপ্রত্যাশিত আচরণ তৈরি করতে পারে। শুধু file সম্পাদনা করলেই হবে না, কারণ container তৈরি করার সময় restart policy নির্ধারিত হয়। তাই docker compose up -d চালিয়ে container-টি পুনরায় তৈরি করুন। এরপর কার্যকর value পরীক্ষা করুন:

docker inspect my-app | grep -A3 RestartPolicy

এরপর ইচ্ছাকৃতভাবে server-টি রিবুট করুন এবং project directory-তে docker compose ps চালান। পরিকল্পিত রিবুটের পর যে stack চালু থাকে, সেটি অনিয়ন্ত্রিত রিবুটের পরও চালু থাকার কথা। আপনার stack-এর boot-এর সময় নির্দিষ্ট ordering guarantee বা one-shot job প্রয়োজন হলে systemd unit ব্যবহার করাই ভালো: boot-এর সময় Docker Compose চালু করা-এ unit file রয়েছে। পুনরায় চালু হওয়া container সত্যিই service দিচ্ছে কি না জানতে Compose healthcheck যোগ করুন।

আমার VPS-এর disk কেন full হয়ে যাচ্ছে?

কারণ Docker-কে বন্ধ করতে না বললে এটি সবকিছু রেখে দেয়। আপনি কখনো pull করা প্রতিটি image tag, প্রতিটি stopped container, recreate-এর পরে পড়ে থাকা প্রতিটি anonymous volume এবং build cache-এর প্রতিটি layer disk-এ থেকে যায়। বড় disk শুধু আরও কিছু সময় দেয়। SSD Nodes-এর সবচেয়ে ছোট plan-এর 160 GB SSD-ও (pricing page 2026-10-11 তারিখে পরীক্ষা করা হয়েছে) প্রতি সপ্তাহে image pull ও build করা কোনো server-এ একইভাবে full হয়ে যায়। ছোট root filesystem হলে outage আরও দ্রুত শুরু হয়।

Disk full হলে তা সরাসরি crash-এর মতো দেখায় না। একই ঘণ্টায় আপনি কোনো container থেকে, no space left on device থেকে, journald থেকে এবং docker pull থেকে apt পান। PostgreSQL write গ্রহণ বন্ধ করে দেয়। Server চালু থাকে, তাই reboot loop-এর তুলনায় সমস্যাটি শনাক্ত করা কঠিন হয়।

কিছু delete করার আগে অবস্থা দেখুন:

docker system df
df -h /

docker system df মোট disk usage-কে images, containers, local volumes এবং build cache-এ ভাগ করে দেখায়। প্রতিটির পাশে একটি RECLAIMABLE column থাকে। নিজস্ব image build করা server-এ build cache সাধারণত সবচেয়ে বড় অংশ হয়।

docker image prune -a
docker builder prune
docker system df

docker image prune -a এমন প্রতিটি image সরিয়ে দেয় যা কোনো container ব্যবহার করছে না। docker builder prune build cache পরিষ্কার করে। Service চলার সময় দুটিই নিরাপদ, কারণ ব্যবহৃত কোনো resource বাদ দেওয়া হয়। নিরাপদ নয় এমন command হলো docker system prune --volumes। এটি stopped container সরায়। এরপর এমন প্রতিটি anonymous volume সরায় যা কোনো অবশিষ্ট container ব্যবহার করছে না। সপ্তাহান্তের জন্য বন্ধ করা কোনো stack-এর অবস্থা ঠিক এমন হতে পারে। সেই stack-এর database যদি anonymous volume-এ data রাখে, তাহলে data-ও মুছে যাবে। Docker কোনো image-এ volume ঘোষণা করলেও compose file-এ সেখানে কিছু mount না করলে এমন anonymous volume তৈরি হয়। Named volume এই command-এ থেকে যায়। তবে docker volume prune --all অব্যবহৃত named volume-ও সরিয়ে দেয়। কোনো flag ব্যবহার করার আগে bind mount বনাম named volume পড়ুন এবং আগে backup নিন।

Container log ধীরে ধীরে disk usage বাড়ায়। Default json-file driver-এর কোনো size limit নেই। তাই কোনো বেশি log লেখা container /var/lib/docker/containers-এ gigabytes data লিখতে পারে। /etc/docker/daemon.json-এ প্রতিটি container-এর জন্য limit নির্ধারণ করুন:

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

sudo systemctl restart docker দিয়ে এটি প্রয়োগ করুন। এতে আপনার container restart হবে, তাই উপযুক্ত সময় বেছে নিন। এই limit পরিবর্তনের পরে তৈরি হওয়া container-এ প্রযোজ্য হবে। তাই চলমান container-গুলো 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 পরিবর্তনের আগেই তৈরি হয়েছে এবং এখনও কোনো limit ছাড়াই data লিখছে।

ছোট Docker হোস্ট সুস্থ রাখার অভ্যাস

এর কোনোটির জন্য dashboard বা শেখার প্রয়োজন হয় এমন কোনো tool দরকার নেই।

• মাসের প্রথম দিনে docker system df এবং df -h / চালান। দুটি command, ত্রিশ সেকেন্ড, এবং outage হওয়ার অনেক আগেই trend দেখতে পাবেন।
• প্রতিটি service-এর জন্য memory limit নির্ধারণ করুন, যেগুলো ছোট বলে আপনি নিশ্চিত সেগুলোর জন্যও। এই limit পুরো host-এ outage হওয়ার পরিবর্তে শুধু একটি container restart হওয়ার পরিস্থিতি তৈরি করে।
• অন্য কোনো স্থান থেকে host-টি monitor করুন, যাতে kernel ব্যবস্থা নেওয়ার আগেই memory বা disk pressure সম্পর্কে জানতে পারেন। Uptime Kuma একটি container-এ চলে এবং idle অবস্থায় প্রায় 95 MB memory ব্যবহার করে।
• container নয়, volume-এর backup নিন। container অস্থায়ী, কিন্তু volume নয়। VPS-এ restic backup backup schedule এবং restore test—দুটিই কভার করে।
• compose file-এ image tag নির্দিষ্ট করে দিন এবং আপনার পছন্দের দিনে সেগুলো update করুন। latest ব্যবহার করলে পরবর্তী docker compose pull থেকে যে version পাবেন, সেটি হবে সেই সকালে release করা version।

একটি ছোট VPS-এ চলা Docker বহু বছর সুস্থ থাকে, যখন চারটি সংখ্যা নিয়ন্ত্রণে থাকে: memory budget, published port-এর তালিকা, প্রতিটি service-এর restart policy এবং free disk। বাকি সবকিছু আপনার বাড়িতে চালানো আগের Docker-এর মতোই।

FAQ

Docker চালানোর জন্য VPS-এ কত RAM প্রয়োজন?

Docker নিজে খুব কম সম্পদ ব্যবহার করে। daemon এবং containerd মিলিয়ে প্রায় 100 MB লাগে। বাকি প্রয়োজন নির্ভর করে আপনার container-গুলোর ওপর। প্রথমে host-এর জন্য বরাদ্দ নির্ধারণ করুন: 768 MB। এটি 2048 MB-এর একটি সিস্টেমে operating system, daemon এবং অতিরিক্ত headroom-এর জন্য থাকবে। ফলে container-এর জন্য 1280 MB অবশিষ্ট থাকবে। 512 MB-এর একটি database, 128 MB-এর একটি reverse proxy এবং দুটি ছোট application এই সীমার মধ্যে চলতে পারে। প্রকাশিত কোনো হিসাবের ওপর নির্ভর না করে docker stats --no-stream দিয়ে নিজের stack-এর ব্যবহার মাপুন।

আমি কি 1 GB VPS-এ Docker চালাতে পারি?

হ্যাঁ, একটি বা দুটি হালকা container-এর জন্য চালাতে পারেন। শুরু করার আগে একটি swap file যোগ করুন। operating system এবং Docker daemon চালু হলে 1 GB-এর একটি সিস্টেমের প্রায় অর্ধেক memory ব্যবহৃত হয়ে যায়। ফলে একটি ছোট application এবং একটি reverse proxy চালানোর মতো জায়গা থাকে, কিন্তু বাস্তব load-এ database চালানোর মতো জায়গা থাকে না। এই আকারের সিস্টেমে image build করলে তা ব্যর্থ হতে পারে বা অন্য কোনো process বন্ধ হয়ে যেতে পারে। তাই অন্যত্র build করে প্রস্তুত image pull করুন।

UFW কি Docker container সুরক্ষিত করে?

আপনি যে port publish করেন, তার ক্ষেত্রে নয়। Docker নিজস্ব DNAT এবং forward rule তৈরি করে। তাই published container port-এ পাঠানো packet host-এ না গিয়ে container-এ forward হয়। UFW যে INPUT rule পরিচালনা করে, সেগুলো ওই packet দেখতে পায় না। ufw deny 5432 সক্রিয় থাকলেও ওই port Internet থেকে উত্তর দিতে পারে। 127.0.0.1:5432:5432 ব্যবহার করে loopback-এ bind করুন, internal service-গুলো publish না করে রাখুন, অথবা DOCKER-USER chain-এ filter করুন।

VPS reboot হলে কি আমার container-গুলো আবার চালু হবে?

শুধু restart policy দিয়ে তৈরি করা হলে। প্রতিটি service-এ restart: unless-stopped নির্ধারণ করুন। এরপর docker compose up -d চালান, যাতে container-গুলো ওই policy-সহ পুনরায় তৈরি হয়। তারপর নিশ্চিত করুন যে systemctl is-enabled docker, enabled প্রদর্শন করছে। এরপর ইচ্ছাকৃতভাবে reboot করে docker compose ps পরীক্ষা করুন। যে restart policy কখনো পরীক্ষা করা হয়নি, সেটিকে কার্যকর restart policy ধরে নেওয়া যায় না।

কত ঘন ঘন Docker image prune করা উচিত?

বেশিরভাগ ছোট server-এর জন্য মাসে একবার যথেষ্ট। অথবা docker system df যদি এমন reclaimable space দেখায়, যা আপনার প্রয়োজন, তখন prune করুন। service চলার সময় docker image prune -a এবং docker builder prune উভয়ই নিরাপদ। কারণ ব্যবহৃত image এবং cache বাদ দেওয়া হয়। docker system prune --volumes এড়িয়ে চলুন, যদি না কোন volume unreferenced তা আপনি নির্দিষ্টভাবে জানেন। কারণ এটি সাময়িকভাবে বন্ধ থাকা কোনো stack-এর anonymous volume মুছে ফেলতে পারে। এছাড়া docker volume prune --all অব্যবহৃত named volume-ও মুছে ফেলে।