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 চলার সময় তৈরি হওয়া সাময়িক চাপ সামলানোর জন্যও কিছু 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-এর সময় সার্ভারকে responsive রাখার জন্য প্রয়োজনীয় অতিরিক্ত memory অন্তর্ভুক্ত করে। বাকি অংশ হলো container_mb, এবং খরচ করার জন্য আপনি কেবল এই সংখ্যাটিই পান। ছোট plan-এ reserve 768 MB থেকে শুরু করে সবচেয়ে বড় plan-এ 1536 MB হয়, কারণ বড় server-এ বেশি container চলে, বেশি log লেখা হয় এবং বেশি page cache প্রয়োজন হয়।

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

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

8 GB plan-এ মোট 8192 MB-এর মধ্যে 6656 MB থাকে। এই পর্যায়ে সীমাবদ্ধতা সাধারণত memory থেকে CPU বা disk throughput-এ চলে যায়। কিছু container load অনুযায়ী নয়, configuration অনুযায়ী memory নির্ধারণ করে। যেমন, একটি local model server context window-এর অনুপাতে KV cache reserve করে। তাই Ollama-এর num_ctx বাড়ালে কোনো request আসার আগেই budget-এ কয়েক GB যোগ হতে পারে। হিসাব অনুযায়ী stack না ধরলে tuning করে সীমা এড়ানোর পরিবর্তে বড় plan নিন: VPS-এর প্রকৃত খরচ-এ অতিরিক্ত gigabyte-এর মাসিক মূল্য ব্যাখ্যা করা হয়েছে।

দুটি নিয়ম মানলে হিসাব সঠিক থাকে। প্রতিটি service-এর জন্য memory limit নির্ধারণ করুন, যাতে কোনো নিয়ন্ত্রণহীন process পুরো server অচল করে দিতে না পারে। এছাড়া 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-এ থেকে যায়। এই plan size-এ 40 GB বা 80 GB-এর root filesystem স্বাভাবিক। তাই কয়েক বছরের বদলে কয়েক মাসের মধ্যেই এটি outage তৈরি করতে পারে।

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

মুছে ফেলার আগে অবস্থা দেখুন:

docker system df
df -h /

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

docker image prune -a
docker builder prune
docker system df

docker image prune -a এমন সব image মুছে দেয়, যেগুলো কোনো container ব্যবহার করছে না। docker builder prune build cache পরিষ্কার করে। Service চলার সময় উভয় command-ই নিরাপদ, কারণ ব্যবহৃত কোনো কিছু বাদ দেওয়া হয়। তবে docker system prune --volumes নিরাপদ নয়। এটি এমন সব volume মুছে দেয়, যেগুলোর কোনো container এখন reference করছে না। সপ্তাহান্তের জন্য বন্ধ রাখা stack-এর volume-এর ক্ষেত্রেও ঠিক এই অবস্থা হয়। ফলে তার database volume-ও মুছে যাবে। ওই flag দেওয়ার আগে bind mount এবং named volume-এর পার্থক্য পড়ুন এবং আগে backup নিন।

Container log ধীরে ধীরে disk ব্যবহারের আরেকটি কারণ। 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 দিয়ে এটি প্রয়োগ করুন। এতে আপনার containers restart হবে, তাই উপযুক্ত সময় বেছে নিন। এই limit পরিবর্তনের পরে তৈরি করা 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 সেট করা দেখা উচিত। এটি খালি থাকলে ওই 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

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

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

1 GB VPS-এ কি Docker চালানো যাবে?

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

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

আপনি publish করা port-এর ক্ষেত্রে নয়। Docker নিজস্ব DNAT এবং forward rule লেখে। তাই publish করা container port-এ আসা packet host-এ deliver না হয়ে container-এ forward হয়। UFW যে INPUT rule পরিচালনা করে, সেগুলো সেই packet দেখতে পায় না। ufw deny 5432 সক্রিয় থাকলেও ওই port Internet থেকে response দিতে পারে। 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 output দিচ্ছে। এরপর ইচ্ছাকৃতভাবে 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 এগুলো এড়িয়ে যায়। কোন volume unreferenced তা সম্পূর্ণ নিশ্চিত না হলে docker system prune --volumes ব্যবহার করবেন না। এটি বন্ধ থাকা কোনো stack-এর data মুছে দিতে পারে।