SSD Nodes Learn 🎉 VPS $5.50/মাস থেকে
নির্দেশিকা Matt Connorদ্বারা Matt Connor

VPS-এ Docker prune করে disk space খালি করার উপায়

VPS-এর disk full হলে আগে images, containers, build cache ও volumes-এর ব্যবহার দেখুন। সঠিক prune command বেছে নিয়ে data না হারিয়ে space reclaim করুন।

প্রুন করার আগে কোনটি disk space ব্যবহার করছে তা নির্ধারণ করুন

একটি VPS-এ Docker চারটি জায়গায় disk space ব্যবহার করে: images, stopped containers, build cache এবং local volumes। কোনটি space দখল করে আছে তা জানতে প্রথমে docker system df চালান। এরপর যে অংশটি পরিষ্কার করতে হবে, তার জন্য সবচেয়ে সীমিত prune command চালান। ক্রমটি গুরুত্বপূর্ণ, কারণ এই গাইডের শেষ command docker volume prune -a data মুছে দেয় এবং তা undo করা যায় না।

Docker দিয়ে শুরু করবেন না। আগে filesystem পরীক্ষা করুন।

df -h /
sudo du -xh --max-depth=1 /var/lib/docker | sort -h

df আপনাকে সমস্যার মাত্রা জানায়। du দেখায় space কোথায় গেছে। -x flag-এর কারণে du শুধু একটি filesystem-এ কাজ করে। তাই এটি mount অনুসরণ করে আলাদা volume-এ যায় না এবং একই data দুবার গণনা করে না। এখানে পাঁচটি directory গুরুত্বপূর্ণ: overlay2-এ image ও container layer থাকে, volumes-এ volume data থাকে, containers-এ container metadata ও log file থাকে, buildkit-এ build cache থাকে, এবং image-এ layer metadata থাকে।

sudo এবং shell wildcard নিয়ে একটি গুরুত্বপূর্ণ কথা আছে, কারণ এগুলো অনেক সময় অপ্রয়োজনীয় সমস্যা তৈরি করে। /var/lib/docker root-এর মালিকানাধীন এবং আপনার সাধারণ user এটি পড়তে পারে না। তাই ls /var/lib/docker, Permission denied ফেরত দেয়। sudo du -sh /var/lib/docker/*-এর মতো command-ও ব্যর্থ হয়, কারণ sudo চালানোর আগেই আপনার shell * প্রসারিত করে, কিন্তু আপনার shell ওই directory পড়তে পারে না। এই কারণেই নিচের প্রতিটি command wildcard-এর পরিবর্তে find অথবা --max-depth ব্যবহার করে।

এবার Docker-এর নিজস্ব হিসাব দেখুন।

docker system df
TYPE            TOTAL     ACTIVE    SIZE      RECLAIMABLE
Images          24        6         12.4GB    8.91GB (71%)
Containers      31        6         1.42GB    1.39GB (97%)
Local Volumes   14        5         6.03GB    4.11GB (68%)
Build Cache     212       0         9.87GB    9.87GB

এই সংখ্যাগুলো একটি machine থেকে নেওয়া এবং আপনার machine সম্পর্কে কিছুই বলে না। বরং ফলাফলের ধরনটি দেখুন। TOTAL object-এর সংখ্যা গণনা করে, ACTIVE বর্তমানে ব্যবহৃত object-এর সংখ্যা গণনা করে, এবং RECLAIMABLE দেখায় ওই row থেকে prune করলে Docker আনুমানিক কত space মুক্ত করতে পারে।

RECLAIMABLE নিয়ে দুটি বিষয় অনেককে বিভ্রান্ত করে। এটি shared image layer ব্যবহারকারী প্রতিটি image-এর জন্য layer-টি একবার করে গণনা করে। তাই image row সাধারণত বাস্তবে যতটা space মুক্ত হবে তার চেয়ে বেশি দেখায়। এছাড়া এটি কখনো container log file অন্তর্ভুক্ত করে না, কারণ Docker log file-কে reclaimable object হিসেবে গণনা করে না। du কোনো directory-র আকার docker system df-এর দেখানো আকারের চেয়ে অনেক বেশি দেখালে তার কারণ সাধারণত log file। এ বিষয়ে নিচে একটি আলাদা section আছে।

প্রতিটি object-এর বিস্তারিত বিভাজন দেখতে -v যোগ করুন।

docker system df -v

এটি summary-কে প্রতিটি object type-এর জন্য আলাদা section-এ ভাগ করে। Image section-এ SHARED SIZE এবং UNIQUE SIZE column যোগ হয়। ফলে একটি image আসলে কত space ব্যবহার করছে তা দেখা যায়। Volume section-এ LINKS count যোগ হয়। এটি ওই volume-এ সংযুক্ত container-এর সংখ্যা। LINKS মনে রাখুন, কারণ 0 মান হল volume prune command প্রয়োগের সম্পূর্ণ পরীক্ষাটি।

Dangling image এবং unused image

এই দুটি শব্দের অর্থ একই নয়। Object আলাদা হওয়ায় filter-এর আচরণও আলাদা।

Dangling image হলো এমন image যার কোনো tag নেই। এটি docker images-এ <none> হিসেবে দেখা যায়। প্রতিবার rebuild করলে একটি dangling image তৈরি হয়: docker build -t myapp:latest . নতুন image-এ myapp:latest tag সরিয়ে দেয়, আর পুরোনো image তার সব layer রেখে নাম হারায়। কোনো কিছু এটিকে reference করে না, এবং নিজে থেকে কোনো কিছু এটিকে পরিষ্কার করে না।

Unused image হলো এমন যেকোনো image, tagged হোক বা না হোক, যেটিকে কোনো container বর্তমানে reference করে না। গত মাসে pull করা এবং বর্তমানে না চালানো একটি postgres:16 unused, কিন্তু এটি dangling নয়।

docker image prune        # dangling images only
docker image prune -a     # every image no container refers to

দ্বিতীয় কমান্ডটি প্রথমে confirmation চায়।

WARNING! This will remove all images without at least one container associated to them.
Are you sure you want to continue? [y/N]

এই prompt-টি ভালোভাবে পড়ুন। "Associated to them" বলতে running বা stopped—উভয় ধরনের existing container object বোঝায়। আপনি যদি docker compose down চালান, container-গুলো মুছে যাবে। ফলে ওই service-গুলো যে সব image ব্যবহার করেছিল, সেগুলো এখন unused হবে, এবং -a সেগুলো সব মুছে দেবে। এমন কিছু হারাবে না যা পুনরুদ্ধার করা যায় না। তবে পরের docker compose up -d-এ সব image আবার pull বা rebuild করতে হবে, যা ছোট VPS-এ bandwidth এবং build time ব্যয় করে। Prune করার আগে docker compose down কী মুছে দেয় এবং stop কী চালু রাখে জানা তাই বাস্তবভাবে গুরুত্বপূর্ণ।

একটি filter সাম্প্রতিক image-গুলোকে scope-এর বাইরে রাখে।

docker image prune -a --filter "until=240h"

এটি 240 ঘণ্টা (10 দিন)-এর বেশি আগে তৈরি হওয়া unused image মুছে দেয় এবং নতুন image-গুলো রেখে দেয়। until value-তে 240h-এর মতো Go duration string অথবা 2026-08-01T00:00:00-এর মতো absolute timestamp ব্যবহার করা যায়।

Build cache কী এবং এটি সীমাহীনভাবে কেন বাড়ে

Docker Engine 23.0 থেকে BuildKit হলো docker build এবং docker compose build-এর জন্য Docker-এর ডিফল্ট builder। এটি চালানো প্রতিটি Dockerfile-এর প্রতিটি ধাপের ফলাফল cache করে এবং সেই cache /var/lib/docker/buildkit-এ সংরক্ষণ করে। দ্বিতীয়বার build কয়েক সেকেন্ডে শেষ হওয়ার কারণ এই cache; অর্থাৎ এটি সঠিকভাবে কাজ করছে। সমস্যা হলো, ডিফল্টভাবে পুরোনো entry-গুলোর মেয়াদ শেষ করার কোনো ব্যবস্থা নেই। প্রতিবার পরিবর্তিত হয় এমন COPY step-সহ একই image পঞ্চাশবার build করলে পঞ্চাশ সেট layer জমে থাকে।

Build cache docker image prune-এর কাছে দৃশ্যমান নয়। এটি নিজস্ব command-সহ আলাদা object type।

docker builder prune                        # dangling cache
docker builder prune -a                     # all unused cache
docker builder prune --filter until=168h    # cache untouched for 7 days

এগুলোর কোনোটিই আপনার image বা data-তে প্রভাব ফেলে না। Build cache মুছে ফেলার একমাত্র খরচ হলো পরবর্তী build একবার ধীরগতিতে চলবে। নিয়মিত image rebuild করে এমন VPS-এ Build Cache প্রায়ই docker system df-এর সবচেয়ে বড় row হয়। তাই এটি মুছে ফেলার জন্য সবচেয়ে নিরাপদ বড় উপাদান।

নিরাপদ থেকে ধ্বংসাত্মক ক্রমানুসারে prune command

এই তালিকা ওপর থেকে নিচে অনুসরণ করুন এবং df -h / আবার স্বাভাবিক দেখালেই থামুন। প্রতিটি command শেষ হলে একটি Total reclaimed space: line দেখায়।

  1. docker container prune বন্ধ থাকা container সরিয়ে দেয়। এগুলোর writable layer-ও সরানো হয়। তাই volume-এর বাইরে container যা লিখেছিল, সেটিও container-এর সঙ্গে মুছে যায়। Volume-এ কোনো পরিবর্তন করা হয় না।
  2. docker image prune শুধু dangling image সরিয়ে দেয়। এটি image সরানোর সবচেয়ে নিরাপদ command।
  3. docker builder prune dangling build cache সরিয়ে দেয়। এর ফল হলো পরবর্তী একটি build ধীর হবে।
  4. docker image prune -a এমন সব image সরিয়ে দেয়, যেগুলো কোনো container ব্যবহার করে না। পরে image আবার pull করতে বা rebuild করতে হবে।
  5. docker system prune প্রথম তিনটি কাজ একসঙ্গে করে এবং unused network-ও সরিয়ে দেয়।
  6. docker volume prune unused anonymous volume সরিয়ে দেয়।
  7. docker volume prune -a named volume-সহ সব unused volume সরিয়ে দেয়। Database মুছে ফেলার জন্য এই command-ই দায়ী।

চালানোর আগে docker system prune নিজেই তার scope জানায়।

WARNING! This will remove:
        - all stopped containers
        - all networks not used by at least one container
        - all dangling images
        - unused build cache
Are you sure you want to continue? [y/N]

এই তালিকা থেকে volume ইচ্ছাকৃতভাবে বাদ দেওয়া হয়েছে। --volumes যোগ করলে anonymous volume-ও scope-এর মধ্যে আসে। -a যোগ করলে image ধাপটি dangling image থেকে সব unused image পর্যন্ত বিস্তৃত হয়। Production host-এ সম্পূর্ণ docker system prune -a --volumes -f চালালে space খালি করার চেষ্টা করতে গিয়ে data হারানোর ঝুঁকি থাকে।

ভলিউম prune করলে আপনার database কেন মুছে যায়

এই section-টি দুবার পড়ুন।

কোনো container-এর সঙ্গে সংযুক্ত না থাকলে একটি volume-কে unused ধরা হয়। এটিই সম্পূর্ণ পরীক্ষা। volume খালি কি না, কোনো compose file-এ সেটি এখনও declare করা আছে কি না, অথবা সেখানে আপনার database-এর একমাত্র copy আছে কি না—Docker এসব পরীক্ষা করে না। LINKS 0-এ docker system df -v থাকলে সেটিকে prunable ধরা হয়; এর অর্থ শুধু এটুকুই।

এখন পরপর দুটি সাধারণ কাজ বিবেচনা করুন। stack পরিষ্কারভাবে restart করতে আপনি docker compose down চালান। এতে container-গুলো সরানো হয় এবং named volume-গুলো আগের মতো রাখা হয়—documented behavior ঠিক এটাই। আপনার Postgres volume এখন কোনো কিছুর সঙ্গে সংযুক্ত নেই। দশ মিনিট পরে space খালি করতে আপনি docker volume prune -a চালান, এবং database মুছে যায়। উভয় command-ই সঠিকভাবে কাজ করেছে। কিন্তু এই sequence data ধ্বংস করেছে।

Docker Engine 23.0 (API version 1.42) থেকে সাধারণ command-টি আগের তুলনায় আরও সীমিত।

WARNING! This will remove anonymous local volumes not used by at least one container.

Anonymous volume হলো এমন volume, যা Docker আপনার জন্য তৈরি করে। সাধারণত কোনো image-এ VOLUME declare করা থাকলেও আপনি volume-এর নাম দেননি বলে এটি তৈরি হয়। এগুলোতে সাধারণত এমন data থাকে, যা আপনি সংরক্ষণ করতে বলেননি। Named volume—যেটি আপনি compose file-এ লিখেছেন—শুধু -a যোগ করলে সরানো হয়। পুরোনো Docker version-গুলো সাধারণ command দিয়ে উভয় ধরনের volume সরিয়ে দিত। তাই upgrade করা server-এ আগের অভ্যাসের ওপর নির্ভর করবেন না। এই পার্থক্য বোঝার জন্য আগে named volume ও bind mount-এর পার্থক্য জানতে হবে। কারণ bind mount আসলে Docker volume নয়, এবং কোনো prune command-ই সেটিকে স্পর্শ করবে না।

মুছে ফেলার আগে পরীক্ষা করুন। যে volume পরীক্ষা করছেন, তার নাম দিয়ে myapp_pgdata প্রতিস্থাপন করুন।

docker volume ls -f dangling=true
docker volume inspect myapp_pgdata
sudo ls -la /var/lib/docker/volumes/myapp_pgdata/_data

কোনো volume-এ dangling=true filter-এর অর্থ হলো unreferenced, empty নয়। ভেতরে আসলে কী আছে তা দেখতে _data ব্যবহার করুন। সেখানে pgdata বা mysql directory পেলে থামুন এবং আর কিছু করার আগে একটি copy নিন। docker compose down -v-এর মাধ্যমেও একই ধরনের ধ্বংস ঘটতে পারে। এটি compose file-এ declare করা প্রতিটি volume সরিয়ে দেয় এবং আগে কোনো confirmation চায় না।

Docker host-এ rebuild করে যে একমাত্র জিনিস পুনরায় তৈরি করা যায় না, সেটি হলো volume। তাই volume data server-এর বাইরে চলা একটি restic backup-এ রাখা উচিত। এতে ভুল করে কোনো flag ব্যবহার করলেও backup-এর বাইরে থাকা data-তে তার প্রভাব পড়বে না।

যখন কিছুই prune হয় না: container log file

আপনি সবকিছু prune করেছেন, docker system df-এ reclaim করার মতো প্রায় কিছুই দেখাচ্ছে না, কিন্তু disk এখনও full। Log পরীক্ষা করুন।

sudo find /var/lib/docker/containers -name '*-json.log' -exec du -h {} + | sort -h | tail -10

প্রতিটি container তার standard output এবং standard error /var/lib/docker/containers/-এর অধীনে একটি JSON file-এ লেখে। Default install-এ max-size unset থাকে, যার অর্থ কোনো limit নেই। ফলে crash loop-এ আটকে থাকা একটি container partition full না হওয়া পর্যন্ত লিখতে থাকে। কোনো prune command এই file সরায় না, কারণ এগুলো তৈরি করা container-গুলো চলছে। সংজ্ঞা অনুযায়ী তাই এগুলো prunable নয়।

Fileটি delete করবেন না। কোনো open log file-এর ওপর rm চালালে কিছুই free হয় না, কারণ Docker daemon এখনও একটি open file descriptor ধরে রাখে এবং সেই handle বন্ধ না হওয়া পর্যন্ত kernel block-গুলো allocated রাখে। df একটুও কমবে না। এর বদলে truncate করুন। এতে একই inode বজায় থাকে এবং daemon লেখা চালিয়ে যেতে পারে।

sudo find /var/lib/docker/containers -name '*-json.log' -exec truncate -s 0 {} +
df -h /

এটি একটি অস্থায়ী সমাধান। ওই container-গুলোর জন্য এখন docker logs কিছুই ফেরত দেয় না, এবং file-গুলো সঙ্গে সঙ্গে আবার বড় হতে শুরু করে। প্রকৃত সমাধান হলো rotation, যা পরের section-এ আলোচনা করা হয়েছে।

প্রতিবার কাজের আগে ও পরে পরিমাপ করুন

prune কী করেছে তা কখনো অনুমান করবেন না। একটি পরিমাপ নিন, একটি কমান্ড চালান, তারপর আবার পরিমাপ নিন।

df -h /
docker system df
docker builder prune -f --filter until=168h
docker image prune -f
docker system df
df -h /

দুটি df output তুলনা করুন। আপনার server এখনও service দিচ্ছে কি না, তা নির্ধারণ করে একমাত্র এই number। এরপর docker system df দেখায় আসলে কোন row পরিবর্তিত হয়েছে, এবং প্রতিটি prune নিজস্ব Total reclaimed space: figure দেখায়।

df পরিবর্তিত না হলেও docker system df যদি দেখায় যে space মুক্ত হয়েছে, তাহলে একটি open file handle deleted blocks ধরে রেখেছে। উপরের log file সমস্যাটি এ কারণেই হয়। উভয়ই পরিবর্তিত হওয়ার পরও disk যদি এক দিনের মধ্যে আবার পূর্ণ হয়ে যায়, তাহলে এটি cleanup সমস্যা নয়, growth সমস্যা। এর সমাধান হলো rotation এবং একটি scheduled job।

ডিস্ক আবার ভরে যাওয়া কীভাবে বন্ধ করবেন

লগের আকার সীমিত করুন। /etc/docker/daemon.json তৈরি করুন বা সম্পাদনা করুন।

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

এতে প্রতিটি container-এর লগের আকার 30 MB-এ সীমাবদ্ধ থাকবে। log-opts-এর অধীনে থাকা প্রতিটি value string হতে হবে, numeric value-সহ। restart করার আগে file-টি parse হচ্ছে কি না পরীক্ষা করুন। কারণ ভুলভাবে লেখা daemon.json daemon-এর শুরু হওয়া সম্পূর্ণভাবে বন্ধ করে দিতে পারে এবং এর সঙ্গে সব container-ও বন্ধ হয়ে যেতে পারে।

python3 -m json.tool /etc/docker/daemon.json
sudo systemctl restart docker
docker info | grep -i 'logging driver'

এখন docker info-এ Logging Driver: json-file দেখানোর কথা। restart-এর পরে তৈরি করা container-এর docker inspect-এর LogConfig section-এ limit-গুলো দেখা যাবে। গুরুত্বপূর্ণ বিষয় হলো, এই setting শুধু নতুন container-এর ক্ষেত্রে প্রযোজ্য। বিদ্যমান container-গুলো তৈরির সময়কার configuration ধরে রাখে। তাই সেগুলো recreate করুন।

docker compose up -d --force-recreate

একই limit compose file-এ service-ভিত্তিকভাবেও নির্ধারণ করা যায়। কোনো একটি বেশি লগ তৈরি করা service-এর জন্য আলাদা limit প্রয়োজন হলে এটি ভালো পদ্ধতি।

services:
  app:
    logging:
      driver: json-file
      options:
        max-size: "10m"
        max-file: "3"

সীমিত পরিসরে prune schedule করুন। প্রতি সপ্তাহে শুধু dangling image এবং পুরনো build cache-এর ক্ষেত্রে এটি চালান। Scheduled job-এ কখনো -a বা --volumes ব্যবহার করবেন না। কারণ stack বন্ধ থাকা অবস্থায় job চললে সেটি ওই stack-এর image মুছে দেবে, আর --volumes থাকলে আপনার data-তেও কাজ শুরু করবে।

sudo tee /etc/cron.weekly/docker-prune >/dev/null <<'EOF'
#!/bin/sh
docker image prune -f
docker builder prune -f --filter until=168h
EOF
sudo chmod +x /etc/cron.weekly/docker-prune
sudo /etc/cron.weekly/docker-prune

শেষের line-টি script-টি unattended অবস্থায় চালানোর আগে হাতে একবার চালায়, যাতে এর output দেখতে পারেন। File-টি executable হতে হবে। এর name-এ dot থাকা যাবে না, কারণ run-parts non-executable file এবং extension-যুক্ত file এড়িয়ে যায়।

Free space-এর ওপর alert দিন। ডিস্ক ভরে যাওয়ার পরে চালানো prune হলো recovery ব্যবস্থা। 80 percent-এ alert দেওয়া হলো prevention ব্যবস্থা।

usage=$(df --output=pcent / | tr -dc '0-9')
[ "$usage" -ge 80 ] && echo "root filesystem at ${usage} percent full"

আপনি ইতিমধ্যে যে notifier ব্যবহার করেন, সেটি দিয়ে এটিকে cron-এ যুক্ত করুন। Free space বিষয়টির অর্ধেক মাত্র। তাই alert-এর সঙ্গে আপনার VPS-এ disk health monitoring যুক্ত করুন। Failing disk এবং full disk—উভয়ই আপনার container বন্ধ করে দেয়, তবে দুটির সমাধান আলাদা।

উপরের সবকিছু ধরে নেয় যে data root /var/lib/docker-এ থাকা standard install ব্যবহার করা হয়েছে। daemon.json-এর data-root key ব্যবহার করে এটি সরিয়ে থাকলে প্রতিটি command-এ আপনার path বসান। নতুন server-এ এই layout সঠিকভাবে নির্ধারণ করা VPS-এ Docker setup করা-র অংশ। 40 GB container ভুল partition-এ জমা হওয়ার আগেই সিদ্ধান্ত নেওয়া অনেক সহজ।

FAQ

docker system prune কি আমার volume মুছে দেয়?

না। সাধারণ command-টি stopped container, unused network, dangling image এবং unused build cache মুছে দেয়। এর confirmation prompt-এ ঠিক এই উপাদানগুলোর তালিকাই থাকে। আপনি --volumes যোগ করলে তবেই volume-এর আওতায় আসে। Docker Engine 23.0 থেকে ওই flag named volume নয়, anonymous volume-এর ক্ষেত্রে প্রযোজ্য। Named volume docker volume prune -a এবং docker compose down -v দিয়ে মুছে ফেলা হয়। এই দুটি command ব্যবহারের সময় সতর্ক থাকুন।

docker prune চালানোর পরও আমার disk পূর্ণ কেন?

সাধারণত দুটি কারণ থাকে। প্রথমটি হলো /var/lib/docker/containers/-এর অধীনে থাকা container log file। কোনো prune command এগুলো স্পর্শ করে না। max-size সেট না করা পর্যন্ত এগুলোর আকার সীমাহীনভাবে বাড়তে থাকে। দ্বিতীয়টি হলো কোনো deleted file, যেটি একটি process এখনও open অবস্থায় ধরে রেখেছে। Container চালু থাকা অবস্থায় rm দিয়ে কোনো log মুছে ফেললে daemon file descriptor ধরে রাখে। Kernel তখন block-গুলো release করে না। তাই df-এ কোনো পরিবর্তন দেখা যায় না। আপনার ক্ষেত্রে কোন কারণটি প্রযোজ্য তা দেখতে sudo du -xh --max-depth=1 /var/lib/docker এবং docker system df-এর ফলাফল তুলনা করুন।

docker image prune এবং docker image prune -a-এর মধ্যে পার্থক্য কী?

সাধারণ command-টি শুধু dangling image মুছে দেয়। অর্থাৎ যেসব image-এর tag হারিয়ে গেছে, সাধারণত rebuild-এর কারণে। -a form এমন সব image মুছে দেয়, যেগুলোকে কোনো existing container refer করে না। এর মধ্যে আপনি ইচ্ছাকৃতভাবে pull করা tagged image-ও অন্তর্ভুক্ত। docker compose down চালানোর পর container-গুলো চলে যায়। তাই -a ওই stack-এর image-গুলোও মুছে ফেলবে। স্থায়ীভাবে কিছু হারায় না, কারণ পরবর্তী start-এর সময় image আবার pull বা rebuild করা হয়। তবে ধীর link হলে এতে দীর্ঘ সময় লাগতে পারে।

Docker log যাতে disk পূর্ণ না করে, তার জন্য কী করব?

/etc/docker/daemon.json-এ log-opts-এর অধীনে max-size এবং max-file সেট করুন। এরপর sudo systemctl restart docker দিয়ে daemon restart করুন। এই setting শুধু restart-এর পরে তৈরি করা container-এ প্রযোজ্য। তাই চলমান container-গুলো docker compose up -d --force-recreate দিয়ে recreate করুন। একটি compose file-এ logging key-এর অধীনে প্রতিটি service-এর জন্য একই দুটি option সেট করা যায়। কোনো একটি service অন্যগুলোর তুলনায় অনেক বেশি log তৈরি করলে এই পদ্ধতিই ব্যবহার করুন।

Cron job-এ docker system prune চালানো কি নিরাপদ?

প্রতিটি stack সচল থাকা host-এ সাধারণ docker system prune -f নিরাপদ। তবে এটি stopped container মুছে দেয়। ফলে আপনি ইচ্ছাকৃতভাবে থামিয়ে পরে restart করার জন্য রাখা container-ও মুছে যাবে। নির্ধারিত সময়ে চালানোর জন্য নিরাপদ job হলো docker image prune -f এবং docker builder prune -f --filter until=168h। এটি দ্রুত বাড়তে থাকা দুটি resource পরিষ্কার করে এবং কোনো volume-এ প্রভাব ফেলতে পারে না। কখনও -a বা --volumes নির্ধারিত job হিসেবে চালাবেন না।

#docker#disk-space#prune#volumes#maintenance