ডকার / ওভারলে 2 / পরিষ্কার করা কি নিরাপদ

Question 1

আমি AWS ইসি 2 তে চলমান কিছু ডকার পাত্রে পেয়েছি, / var / lib / ডকার / ওভারলে 2 ফোল্ডারটি ডিস্ক আকারে খুব দ্রুত বৃদ্ধি পায়।

আমি ভাবছি এটির সামগ্রী মুছে ফেলা নিরাপদ কিনা? বা যদি ডকারের কিছু ডিস্কের ব্যবহার মুক্ত করার জন্য একরকম কমান্ড থাকে।

হালনাগাদ:

আমি আসলে docker system prune -aইতিমধ্যে চেষ্টা করেছি , যা 0 কেবি পুনরুদ্ধার করেছে।

এছাড়াও আমার / ডকার / ওভারলে 2 ডিস্কের আকারটি আউটপুট থেকে অনেক বড় docker system df

ডকার ডকুমেন্টেশন এবং বিএমইচের উত্তর পড়ার পরে, আমি বিশ্বাস করি যে এই ফোল্ডারটি স্পর্শ করা বোকামি ধারণা এবং আমি আমার ডিস্কের স্থান পুনরায় দাবি করার জন্য অন্যান্য উপায় চেষ্টা করব।

Question 2

ডকার আপনার চিত্র, পাত্রে এবং স্থানীয় নামযুক্ত ভলিউম সংরক্ষণ করতে / var / lib / ডকার ব্যবহার করে। এটি মোছার ফলে ডেটা হারাতে পারে এবং ইঞ্জিনটি চলমান থেকে থামাতে পারে। ওভারলে 2 সাব-ডিরেক্টরীতে চিত্র এবং ধারকগুলির জন্য বিভিন্ন ফাইল সিস্টেম স্তরগুলি বিশেষত অন্তর্ভুক্ত থাকে।

অব্যবহৃত পাত্রে এবং চিত্রগুলি পরিষ্কার করতে, দেখুন docker system prune। ভলিউম এবং এমনকি ট্যাগযুক্ত চিত্রগুলি সরিয়ে ফেলার বিকল্প রয়েছে, তবে ডেটা ক্ষতি হওয়ার সম্ভাবনার কারণে সেগুলি ডিফল্টরূপে সক্ষম হয় না।

Question 3

আমি এটি আমার জন্য সবচেয়ে ভাল কাজ খুঁজে পেয়েছি:

docker image prune --all

ডিফল্টরূপে ডকার নামযুক্ত চিত্রগুলি অপব্যবহৃত হলেও সরিয়ে ফেলবে না। এই আদেশটি অব্যবহৃত চিত্রগুলি সরিয়ে ফেলবে।

নোট করুন প্রতিটি ইমেজের প্রতিটি স্তর হ'ল ফোল্ডারের ভিতরে একটি /usr/lib/docker/overlay2/ফোল্ডার।

Question 4

আমার এই সমস্যাটি ছিল ... এটি লগই ছিল বিশাল। লগগুলি এখানে রয়েছে:

/var/lib/docker/containers/<container id>/<container id>-json.log

আপনি এটি রান কমান্ড লাইনে বা রচনা ফাইলটিতে পরিচালনা করতে পারেন। সেখানে দেখুন: লগিং ড্রাইভারগুলি কনফিগার করুন

আমি ব্যক্তিগতভাবে এই 3 লাইনগুলি আমার ডকার-কমপোজ.আইএমএল ফাইলটিতে যুক্ত করেছি:

my_container:
  logging:
    options:
      max-size: 10m

Question 5

এছাড়াও দ্রুত বর্ধন সঙ্গে সমস্যা ছিল overlay2

/var/lib/docker/overlay2- এমন একটি ফোল্ডার যেখানে আপনার ধারকটির জন্য ডকারগুলি লিখনযোগ্য স্তরগুলি সঞ্চয় করে। docker system prune -a- কেবলমাত্র ধারক বন্ধ এবং অপসারণ করা হলে কাজ করতে পারে।

আমার মধ্যে আমি overlay2অনুসন্ধানে গিয়ে তদন্ত করে স্থানটি কী খায় তা নির্ধারণ করতে সক্ষম হয়েছি ।

এই ফোল্ডারে অন্যান্য হ্যাশ নামের ফোল্ডার রয়েছে। এর প্রত্যেকটির ফোল্ডার সহ বেশ কয়েকটি ফোল্ডার রয়েছে diff।

diff ফোল্ডার - আপনার ধারক হিসাবে সঠিক ফোল্ডার কাঠামো সহ একটি ধারক দ্বারা লিখিত প্রকৃত পার্থক্য রয়েছে (কমপক্ষে এটি আমার ক্ষেত্রে ছিল - উবুন্টু 18 ...)

সুতরাং আমি du -hsc /var/lib/docker/overlay2/LONGHASHHHHHHH/diff/tmpবুঝতে পেরেছিলাম যে /tmpআমার ধারকটির ভিতরে ফোল্ডারটি দূষিত হয়ে যায় ।

সুতরাং একটি কর্মক্ষেত্র হিসাবে আমি অভ্যন্তরীণ ফোল্ডারটি হোস্ট করতে কমান্ডের জন্য -v /tmp/container-data/tmp:/tmpপরামিতিটি ব্যবহার করেছি এবং সেই ফোল্ডারটি পরিষ্কার করার জন্য হোস্টে একটি ক্রোন সেটআপ করব।docker run/tmp

ক্রোন টাস্ক সহজ ছিল:

sudo nano /etc/crontab
*/30 * * * * root rm -rf /tmp/container-data/tmp/*
save and exit

দ্রষ্টব্য: overlay2এটি সিস্টেম ডকার ফোল্ডার এবং এগুলি যে কোনও সময় এটির কাঠামো পরিবর্তন করতে পারে। উপরে সমস্ত কিছুই আমি সেখানে যা দেখেছি তার উপর ভিত্তি করে। ডকার ফোল্ডার কাঠামোতে যেতে হয়েছিল কারণ কেবল সিস্টেমটি পুরোপুরি জায়গার বাইরে ছিল এবং এমনকি আমাকে ডকারের পাত্রে ফেলে দেওয়ার অনুমতিও দেয় না।

Question 6

ব্যাকগ্রাউড

ইস্যুটির জন্য দোষটি আমাদের ধারক ভলিউমের ভুল কনফিগারেশন এবং ডকারের ফাঁস (রিলিজ করতে ব্যর্থ) এর সাথে এই খণ্ডগুলিতে লেখা অস্থায়ী ডেটার মধ্যে বিভক্ত হতে পারে। আমাদের ম্যাপিং করা উচিত (হয় ফোল্ডার বা অন্য ধ্রুবক স্টোরেজ দাবির হোস্ট করতে) কনটেইনারটির সমস্ত অস্থায়ী / লগস / স্ক্র্যাচ ফোল্ডার যেখানে আমাদের অ্যাপগুলি প্রায়শই এবং / অথবা ভারী লেখেন। ডকার ডিফল্টরূপে অবস্থিত স্বয়ংক্রিয়ভাবে তৈরি তথাকথিত এমপিডায়ার্স সমস্ত পরিষ্কার করার জন্য দায় গ্রহণ করে না /var/lib/docker/overlay2/*/diff/*। কনটেইনার বন্ধ হওয়ার পরে এই "অ-অবিচলিত" ফোল্ডারগুলির সূচিপত্রগুলি স্বয়ংক্রিয়ভাবে ডকারের মাধ্যমে মুছে ফেলা উচিত, তবে দৃশ্যত তা নয় (ধারকটি এখনও চলমান থাকলে তারা হোস্টের পক্ষ থেকে মুছে ফেলাও অসম্ভব হতে পারে - এবং এটি কয়েক মাস ধরে চলতে পারে) একেবারে).

কর্মক্ষেত্র

একটি কর্মক্ষেত্রের সাবধানে ম্যানুয়াল ক্লিনআপ প্রয়োজন, এবং ইতিমধ্যে অন্য কোথাও বর্ণনা করার সময় আপনি এখনও আমার কেস স্টাডি থেকে কিছু ইঙ্গিত পেতে পারেন, যা আমি যতটা সম্ভব শিক্ষামূলক এবং সাধারণকরণযোগ্য করার চেষ্টা করেছি।

সুতরাং যা ঘটেছিল তা হ'ল অপরাধী অ্যাপ্লিকেশনটি (আমার ক্ষেত্রে clair-scanner) /diff/tmpডকারের সাবফোল্ডারে কয়েক মাস ধরে কয়েকশ জিগ ডেটা লিখতে সক্ষম হয়েছিলoverlay2

du -sch /var/lib/docker/overlay2/<long random folder name seen as bloated in df -haT>/diff/tmp

271G total

সুতরাং এই সমস্ত সাবফোল্ডারগুলি যেহেতু /diff/tmpবেশ স্ব-ব্যাখ্যামূলক ছিল (সমস্ত ফর্মের clair-scanner-*ছিল এবং তৈরির অপ্রচলিত তারিখ ছিল), তাই আমি সম্পর্কিত ধারকটি থামিয়ে দিয়েছিলাম ( docker stop clairএবং) এই অপ্রচলিত সাবফোল্ডারগুলি সাবধানতার diff/tmpসাথে একক (প্রাচীনতম) এক দিয়ে বিচক্ষণতার সাথে শুরু করে এবং ডকার ইঞ্জিনের উপর প্রভাব পরীক্ষা করে (যার systemctl restart dockerজন্য ডিস্কের স্থান পুনরায় দাবি করতে পুনরায় আরম্ভ করার প্রয়োজন ছিল ):

rm -rf $(ls -at /var/lib/docker/overlay2/<long random folder name seen as bloated in df -haT>/diff/tmp | grep clair-scanner | tail -1)

আমি ডকার পুনরায় ইনস্টল করার বা এর পুরো ফোল্ডারগুলি পরিষ্কার করার প্রয়োজন ছাড়াই কয়েকশ জিগ ডিস্ক স্পেস পুনরুদ্ধার করেছিলাম। সমস্ত চলমান পাত্রে এক পর্যায়ে থামানো উচিত ছিল, কারণ ডিস্ক স্থানটি পুনরায় দাবি করার জন্য ডকার ডিমন পুনরায় আরম্ভ করার প্রয়োজন ছিল, তাই নিশ্চিত হয়ে নিন যে প্রথমে আপনার ব্যর্থ পাত্রে কোনও / অন্য নোড / গুলি সঠিকভাবে চলছে কিনা)। আমি চাই যদিও docker pruneকমান্ডটি অপ্রচলিত /diff/tmp(বা এমনকি /diff/*) ডেটাও (এখনও অন্য একটি স্যুইচের মাধ্যমে) কভার করতে পারে ।

এটি এখন একটি 3 বছরের পুরানো ইস্যু, আপনি ডকার ফোরামগুলিতে এর সমৃদ্ধ এবং বর্ণময় ইতিহাসটি পড়তে পারেন, যেখানে উপরোক্ত সমাধানটির অ্যাপ্লিকেশন লগগুলির লক্ষ্য অনুসারে একটি বৈকল্পিক 2019 সালে প্রস্তাব করা হয়েছিল এবং এটি বেশ কয়েকটি সেটআপে কাজ করেছে বলে মনে হয়: https: // forums.docker.com/t/some-way-to-clean-up-phanfy-contents-of-var-lib-docker-overlay/30604

Question 7

সতর্কতা: উত্পাদন পদ্ধতিতে ব্যবহার করবেন না

/# df
...
/dev/xvda1      51467016 39384516   9886300  80% /
...

ঠিক আছে, প্রথমে সিস্টেম ছাঁটাই চেষ্টা করা যাক

#/ docker system prune --volumes
...
/# df
...
/dev/xvda1      51467016 38613596  10657220  79% /
...

এত দুর্দান্ত নয়, মনে হচ্ছে এটি কয়েক মেগাবাইট পরিষ্কার করেছে। আসুন এখন পাগল হয়ে যাক:

/# sudo su
/# service docker stop
/# cd /var/lib/docker
/var/lib/docker# rm -rf *
/# service docker start
/var/lib/docker# df
...
/dev/xvda1      51467016 8086924  41183892  17% /
...

সুন্দর! কেবল মনে রাখবেন যে এটি কোনও থ্রো-অ্যাওয়ে সার্ভার ব্যতীত অন্য কোনও ক্ষেত্রেই প্রস্তাবিত নয়। এই মুহুর্তে ডকারের অভ্যন্তরীণ ডাটাবেসগুলি এই ওভারলেগুলির কোনওটিই সন্ধান করতে সক্ষম হবে না এবং এটি অনিচ্ছাকৃত ফলাফলের কারণ হতে পারে।

Question 8

উত্পাদনে এটি করবেন না

@ রবি-লুথার দেওয়া উত্তরটি প্রযুক্তিগতভাবে কাজ করে তবে এতে কিছু সমস্যা আছে!

আমার ক্ষেত্রে, আমি কেবল ডিস্কের জায়গা পুনরুদ্ধার করার চেষ্টা করছিলাম। দ্যlib/docker/overlayফোল্ডারের স্থান 30GB গ্রহণ ছিল এবং আমি মাত্র কয়েক পাত্রে নিয়মিতভাবে চালানো। দেখে মনে হচ্ছে ডকারের ডেটা ফাঁস নিয়ে কিছু সমস্যা আছে এবং ধারকটি বন্ধ হয়ে গেলে কিছু অস্থায়ী ডেটা সাফ হয় না।

তাই আমি এগিয়ে গিয়ে lib/docker/overlayফোল্ডারের সমস্ত সামগ্রী মুছে ফেললাম । এর পরে, আমার ডকার উদাহরণটি ব্যবহারযোগ্য হবে না। আমি যখন কোনও ধারক চালানোর বা নির্মাণ করার চেষ্টা করেছি তখন এটি আমাকে এই ত্রুটি দিয়েছে:

failed to create rwlayer: symlink ../04578d9f8e428b693174c6eb9a80111c907724cc22129761ce14a4c8cb4f1d7c/diff /var/lib/docker/overlay2/l/C3F33OLORAASNIYB3ZDATH2HJ7: no such file or directory

তারপরে কিছু পরীক্ষা এবং ত্রুটি সহ, আমি চালিয়ে এই সমস্যাটি সমাধান করেছি

(সতর্কতা: এটি ডকার ভলিউমের ভিতরে থাকা সমস্ত ডেটা মুছে ফেলবে)

docker system prune --volumes -a

সুতরাং সিস্টেমটি কীভাবে কাজ করে তা আপনি সম্পূর্ণরূপে বুঝতে না পারলে এমন নোংরা ক্লিন আপগুলি করার পরামর্শ দেওয়া হয় না।

Question 9

/ Var / lib / ডকারে থাকা সমস্ত কিছুই পাত্রে ফাইল সিস্টেম। আপনি যদি আপনার সমস্ত পাত্রে থামান এবং ছাঁটাই করেন তবে আপনার ফোল্ডারটি খালি থাকার সাথে শেষ করা উচিত। আপনি সম্ভবত এটি চান না, তাই সেখানে এলোমেলোভাবে জিনিস মুছে ফেলবেন না। / Var / lib / ডকারে জিনিসগুলি সরাসরি মুছবেন না। আপনি কখনও কখনও এটির সাথে পালিয়ে যেতে পারেন তবে এটি অনেক কারণে অবিশ্বাস্য।

পরিবর্তে এটি করুন:

sudo bash
cd /var/lib/docker
find . -type f | xargs du -b  | sort -n

আপনি যা দেখবেন তা হ'ল নীচে দেখানো বৃহত্তম ফাইল। আপনি যদি চান তবে এই ফাইলগুলি কী ধারক রয়েছে তা নির্ধারণ করুন, সেই ধারকগুলি প্রবেশ করুন docker exec -ti containername -- /bin/shএবং কিছু ফাইল মুছুন।

আপনি docker system prune -a -fযতক্ষণ না আপনার যত্ন নেওয়া চারপাশে থামানো পাত্রে এবং ভলিউম ছাড়ছেন না, আপনি দৈনিক / সাপ্তাহিক ক্রোন জবও রাখতে পারেন। এটি কেন বাড়ছে তার কারণগুলি নির্ধারণ করা এবং ধারক স্তরে তাদের সংশোধন করা ভাল।

Question 10

আমার সম্প্রতি একটি অনুরূপ সমস্যা ছিল, ওভারলে 2 আরও বড় এবং বড় হয়ে উঠল, তবে আমি কী পরিমাণ জায়গাগুলি গ্রাস করলাম তা বুঝতে পারি না।

df আমাকে দেখিয়েছে যে ওভারলে 2 প্রায় 24 জিবি আকারের ছিল।

সঙ্গে duআমি জিনিসটা কি স্থান দখল করে ... এবং ব্যর্থ চেষ্টা করে।

পার্থক্যটি আসলে আসল ফাইলগুলি মুছে ফেলা হয়েছে (বেশিরভাগ ক্ষেত্রে আমার ক্ষেত্রে ফাইলগুলি লগ করে) যেখানে এখনও একটি প্রক্রিয়া (ডকার) দ্বারা ব্যবহৃত হচ্ছে। সুতরাং ফাইলটি প্রদর্শিত হবে না duতবে এটি স্থানটি দখল করে withdf ।

হোস্ট মেশিনের একটি রিবুট সাহায্য করেছে। ডকারের ধারকটি পুনরায় চালু করা সম্ভবত ইতিমধ্যে সহায়তা করেছে ... লিনাকসকশনস.আর.এ এই নিবন্ধটি আমাকে তা বুঝতে সাহায্য করেছে।

Question 11

উপরের মন্তব্যে যোগ করা, যাতে লোকেরা স্পষ্ট ঝোলা ভলিউম, চিত্র, প্রস্থান কন্টেনার ইত্যাদির মতো সিস্টেমকে ছাঁটাই করার পরামর্শ দিচ্ছে, আপনার অ্যাপ্লিকেশন অপরাধী হয়ে উঠলে এটি খুব অল্প সময়ে খুব বেশি লগ তৈরি করে এবং যদি আপনি খালি প্রত্যক্ষ ভলিউম (স্থানীয় ভলিউম) ব্যবহার করেন ) এটি / var পার্টিশন পূরণ করুন। সেক্ষেত্রে আমি নীচের কমান্ডটি খুব আকর্ষণীয়ভাবে খুঁজে বের করেছি, আমার / var পার্টিশন ডিস্কে স্থানটি কী খাচ্ছে।

du -ahx / var / lib | সাজানো -আরহ | মাথা -n 30

এই কমান্ডটি শীর্ষ 30 টি তালিকাবদ্ধ করবে যা একক ডিস্কে বেশিরভাগ স্থান ব্যয় করে। এর অর্থ যদি আপনি আপনার ধারকগুলি সহ বাহ্যিক সঞ্চয়স্থান ব্যবহার করছেন তবে এটি ডু কমান্ড চালাতে প্রচুর সময় ব্যয় করে। এই কমান্ডটি মাউন্ট ভলিউম গণনা করবে না। এবং অনেক দ্রুত। আপনি সঠিক ডিরেক্টরি / ফাইল যা স্থান গ্রহণ করছে তা পাবেন। তারপরে আপনি সেই ডিরেক্টরিগুলিতে যেতে পারেন এবং কোন ফাইলগুলি দরকারী কিনা তা পরীক্ষা করতে পারেন। যদি এই ফাইলগুলির প্রয়োজন হয় তবে আপনি সেই জায়গার জন্য অবিরাম স্টোরেজ ব্যবহার করতে বা সেই ফাইলগুলির অবস্থান পরিবর্তন করতে অ্যাপে পরিবর্তন করে এগুলিকে কিছু ধ্রুব স্টোরেজে স্থানান্তর করতে পারেন। এবং বিশ্রামের জন্য আপনি এগুলি সাফ করতে পারেন।

Question 12

আমি "ডকার সিস্টেম প্রুন -এ" ব্যবহার করে এটি সমস্ত ফাইলগুলি ভলিউম এবং ওভারলে 2 এর অধীনে পরিষ্কার করে

    [root@jasontest volumes]# docker system prune -a
    WARNING! This will remove:
            - all stopped containers
            - all networks not used by at least one container
            - all images without at least one container associated to them
            - all build cache
    Are you sure you want to continue? [y/N] y
    Deleted Images:
    untagged: ubuntu:12.04
    untagged: ubuntu@sha256:18305429afa14ea462f810146ba44d4363ae76e4c8dfc38288cf73aa07485005
    deleted: sha256:5b117edd0b767986092e9f721ba2364951b0a271f53f1f41aff9dd1861c2d4fe
    deleted: sha256:8c7f3d7534c80107e3a4155989c3be30b431624c61973d142822b12b0001ece8
    deleted: sha256:969d5a4e73ab4e4b89222136eeef2b09e711653b38266ef99d4e7a1f6ea984f4
    deleted: sha256:871522beabc173098da87018264cf3e63481628c5080bd728b90f268793d9840
    deleted: sha256:f13e8e542cae571644e2f4af25668fadfe094c0854176a725ebf4fdec7dae981
    deleted: sha256:58bcc73dcf4050a4955916a0dcb7e5f9c331bf547d31e22052f1b5fa16cf63f8
    untagged: osixia/openldap:1.2.1
    untagged: osixia/openldap@sha256:6ceb347feb37d421fcabd80f73e3dc6578022d59220cab717172ea69c38582ec
    deleted: sha256:a562f6fd60c7ef2adbea30d6271af8058c859804b2f36c270055344739c06d64
    deleted: sha256:90efa8a88d923fb1723bea8f1082d4741b588f7fbcf3359f38e8583efa53827d
    deleted: sha256:8d77930b93c88d2cdfdab0880f3f0b6b8be191c23b04c61fa1a6960cbeef3fe6
    deleted: sha256:dd9f76264bf3efd36f11c6231a0e1801c80d6b4ca698cd6fa2ff66dbd44c3683
    deleted: sha256:00efc4fb5e8a8e3ce0cb0047e4c697646c88b68388221a6bd7aa697529267554
    deleted: sha256:e64e6259fd63679a3b9ac25728f250c3afe49dbe457a1a80550b7f1ccf68458a
    deleted: sha256:da7d34d626d2758a01afe816a9434e85dffbafbd96eb04b62ec69029dae9665d
    deleted: sha256:b132dace06fa7e22346de5ca1ae0c2bf9acfb49fe9dbec4290a127b80380fe5a
    deleted: sha256:d626a8ad97a1f9c1f2c4db3814751ada64f60aed927764a3f994fcd88363b659
    untagged: centos:centos7
    untagged: centos@sha256:2671f7a3eea36ce43609e9fe7435ade83094291055f1c96d9d1d1d7c0b986a5d
    deleted: sha256:ff426288ea903fcf8d91aca97460c613348f7a27195606b45f19ae91776ca23d
    deleted: sha256:e15afa4858b655f8a5da4c4a41e05b908229f6fab8543434db79207478511ff7

    Total reclaimed space: 533.3MB
    [root@jasontest volumes]# ls -alth
    total 32K
    -rw-------  1 root root  32K May 23 21:14 metadata.db
    drwx------  2 root root 4.0K May 23 21:14 .
    drwx--x--x 14 root root 4.0K May 21 20:26 ..