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

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

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

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

• Memory সীমিত। ঘাটতি হলে kernel একটি 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 থাকে না এবং নির্দিষ্ট memory allocation-ও থাকে না। ভেতরের process যে memory ব্যবহার করে, খরচ মূলত সেটিই। এই কারণে virtual machine দিয়ে তৈরি একই stack যেখানে চলবে না, সেখানে 2 GB RAM-এ একটি সম্পূর্ণ stack চলতে পারে।

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

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

7টি row-এর ধরন লক্ষ্য করুন। nginx idle অবস্থায় 8 MB ব্যবহার করে, আর Nextcloud ব্যবহার করে 210 MB। আপনার application-গুলোর সামনে থাকা proxy প্রায় কোনো অতিরিক্ত memory ব্যবহার করে না। server-এর আকার নির্ধারণের সময় মূল বিবেচনা হলো database এবং PHP application।

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

2 GB, 4 GB এবং 8 GB-তে VPS-এ কী চালানো যায়

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

2 GB plan-এ container-গুলোর জন্য 1280 MB থাকে। এর মধ্যে 512 MB PostgreSQL এবং 128 MB Traefik-এ দিলে অর্ধেক 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-এ চলে যায়। হিসাব অনুযায়ী stack না ধরলে সেটি সামঞ্জস্য করতে অতিরিক্ত tuning না করে বড় plan নিন: VPS-এর প্রকৃত খরচ-এ অতিরিক্ত gigabyte-এর মাসিক মূল্য ব্যাখ্যা করা হয়েছে।

দুটি নিয়ম মেনে চললে হিসাব বাস্তবসম্মত থাকে। প্রতিটি service-এ memory limit দিন, যাতে নিয়ন্ত্রণহীন কোনো process পুরো server-এর memory শেষ করে না ফেলে। Budget-এর পুরোটা খরচ করবেন না। কারণ docker compose build এবং pg_dump—দুটিরই সবচেয়ে খারাপ সময়ে memory দরকার হয়। Docker Compose-এ memory limit-এ syntax এবং সাধারণ সমস্যাগুলো দেখানো হয়েছে।

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

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

Swap সময়ের পরিবর্তন ঘটায়, হিসাবের নয়। অধিকাংশ VPS image-এ swap থাকে না। swapon --show দিয়ে তা পরীক্ষা করুন। swap না থাকলে এই command কিছুই প্রদর্শন করে না। একটি 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-তে একটি শূন্যের চেয়ে বড় মোট মান দেখা উচিত। Swap RAM বাড়ায় না। কোনো machine-এ ক্রমাগত memory pressure থাকলে সেটি এত ধীর হয়ে যেতে পারে যে সমস্যাটি ঠিক করার জন্য SSH-তে সংযোগ করাও সম্ভব হবে না। তাই swap-কে alarm buffer হিসেবে ব্যবহার করুন এবং memory sizing ঠিক করুন।

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

কারণ 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

nat table-এ একই port-এর জন্য DNAT tcp ... to:172.18.0.2:5432 rule থাকা সত্ত্বেও UFW 5432 DENY IN Anywhere দেখাতে পারে। অন্য একটি 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 প্রয়োজন হয় না। স্থানীয় 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-এর মৌলিক বিষয় দেখুন।

কেন reboot-এর পরে আমার container-গুলো আর নেই?

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

দুটি বিষয় নিশ্চিত করতে হবে। Boot-এর সময় daemon-কে start হতে হবে:

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-এর মাঝখানে এটি অপ্রত্যাশিত আচরণ তৈরি করতে পারে। শুধু file সম্পাদনা করলেই যথেষ্ট নয়, কারণ container তৈরি করার সময় restart policy নির্ধারিত হয়। এটি পুনরায় তৈরি করতে docker compose up -d চালান। এরপর কার্যকর value যাচাই করুন:

docker inspect my-app | grep -A3 RestartPolicy

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

আমার VPS-এর disk কেন full?

কারণ আপনি বন্ধ না করা পর্যন্ত Docker সবকিছু সংরক্ষণ করে। আপনি কখনও pull করা প্রতিটি image tag, বন্ধ থাকা প্রতিটি container, recreate করার পরে পড়ে থাকা প্রতিটি anonymous volume এবং build cache-এর প্রতিটি layer disk-এ থেকে যায়। 40 GB বা 80 GB-এর root filesystem-এ, যা এই ধরনের plan size-এ স্বাভাবিক, এর ফলে কয়েক বছরের বদলে কয়েক মাসের মধ্যেই outage হতে পারে।

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

মুছে ফেলার আগে পরীক্ষা করুন:

docker system df
df -h /

docker system df মোট disk usage-কে images, containers, local volumes এবং build cache-এ ভাগ করে দেখায়। প্রতিটির পাশে RECLAIMABLE column থাকে। যে সার্ভারে নিজস্ব image 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 চলার সময়ও দুটিই নিরাপদ, কারণ ব্যবহৃত কোনো উপাদান বাদ দেওয়া হয় না। তবে 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-এর জন্য সীমা নির্ধারণ করুন:

{
  "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 দিয়ে recreate করুন এবং যাচাই করুন:

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

Inspect output-এ max-size সেট করা দেখা উচিত। এটি খালি থাকলে বুঝবেন, ওই container পরিবর্তনের আগেই তৈরি হয়েছিল এবং এখনও কোনো সীমা ছাড়াই log লিখছে।

একটি ছোট Docker box সুস্থ রাখার অভ্যাস

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

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

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

FAQ

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

Docker নিজে খুব কম resource ব্যবহার করে। daemon এবং containerd মিলে প্রায় 100 MB ব্যবহার করে; বাকি প্রয়োজন নির্ভর করে আপনার container-গুলোর ওপর। আগে host-এর জন্য বরাদ্দ নির্ধারণ করুন: 768 MB, একটি 2048 MB VPS-এ 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 VPS-এর প্রায় অর্ধেক memory ব্যবহৃত হয়ে যায়। ফলে একটি ছোট application এবং একটি reverse proxy চালানোর মতো জায়গা থাকে, কিন্তু বাস্তব load-এর অধীনে database চালানোর মতো যথেষ্ট জায়গা থাকে না। এই আকারের VPS-এ 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-এ publish করুন, internal service-গুলো unpublished রাখুন, অথবা 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-এর data মুছে দিতে পারে।