ڊڪر جا طريقا: پنھنجي مشين کي ردي جي صاف ڪريو

ڊڪر جا طريقا: پنھنجي مشين کي ردي جي صاف ڪريو

اي حبر! مان توهان جي ڌيان ۾ مضمون جو ترجمو پيش ڪريان ٿو "ڊاڪر ٽوٽڪا: پنھنجي مقامي مشين کي صاف ڪريو" ليکڪ لوڪ جوڳي.

اڄ اسين ڳالهائينداسين ته ڊاڪر ميزبان مشين جي ڊسڪ اسپيس کي ڪيئن استعمال ڪري ٿو، ۽ اسان اهو پڻ معلوم ڪنداسين ته هن اسپيس کي غير استعمال ٿيل تصويرن ۽ ڪنٽينرز جي اسڪريپ کان ڪيئن آزاد ڪجي.


ڊڪر جا طريقا: پنھنجي مشين کي ردي جي صاف ڪريو

کل واپرائڻ

ڊاڪر هڪ سٺي شيء آهي، شايد ڪجهه ماڻهو اڄ شڪ ڪن ٿا. صرف چند سال اڳ، هي پراڊڪٽ اسان کي ڪنهن به ماحول جي تعمير، پهچائڻ ۽ هلائڻ لاء هڪ مڪمل طور تي نئون طريقو ڏنو، اسان کي سي پي يو ۽ رام وسيلن کي خاص طور تي محفوظ ڪرڻ جي اجازت ڏني. ان کان علاوه (۽ ڪجهه لاءِ اهو سڀ کان اهم شيءِ هوندو) ڊڪر اسان کي اجازت ڏني آهي ناقابل يقين حد تائين آسان ۽ متحد ڪرڻ جي زندگي جي انتظام کي اسان جي پيداوار ماحول جي.

بهرحال، جديد زندگي جا اهي سڀئي نعمتون قيمت تي اچن ٿيون. جڏهن اسان ڪنٽينرز کي هلائيندا آهيون، ڊائون لوڊ يا پنهنجون تصويرون ٺاهيندا آهيون، ۽ پيچيده ماحولياتي نظام کي ترتيب ڏيو، اسان کي ادا ڪرڻو پوندو. ۽ اسان ادا ڪندا آهيون، ٻين شين جي وچ ۾، ڊسڪ اسپيس سان.

جيڪڏهن توهان ڪڏهن به اهو نه سوچيو آهي ته ڊاکر اصل ۾ توهان جي مشين تي ڪيترو جاء وٺندو آهي، توهان شايد هن حڪم جي پيداوار کان ناپسنديده حيران ٿي سگهو ٿا:

$ docker system df

ڊڪر جا طريقا: پنھنجي مشين کي ردي جي صاف ڪريو

هي ڏيکاري ٿو ڊڪر جي ڊسڪ استعمال کي مختلف مقصدن ۾:

  • تصويرون - تصويرن جو ڪل سائيز جيڪي تصويري ذخيرن مان ڊائون لوڊ ڪيا ويا ۽ توھان جي سسٽم تي ٺاھيا ويا.
  • ڪنٽينر - ڊسڪ اسپيس جو ڪل مقدار جيڪو ڪنٽينرز کي هلائڻ ۾ استعمال ڪيو ويو آهي (مطلب سڀني ڪنٽينرز جي پڙهڻ-لکڻ جي تہن جو ڪل مقدار)؛
  • مقامي حجم - ڪنٽينرز تي لڳل مقامي اسٽوريج جو مقدار؛
  • تعمير ڪيش - عارضي فائلون ٺاهيل تصويرون بلڊنگ جي عمل طرفان (استعمال ڪندي BuildKit اوزار، موجود آهي ڊڪر ورزن 18.09 سان شروع ٿيندي).

مان شرط ٿو چوان ته هن سادي منتقلي کان پوءِ توهان خواهشمند آهيو ته توهان جي ڊسڪ جي گندگي کي صاف ڪرڻ ۽ قيمتي گيگا بائيٽس کي ٻيهر زنده ڪرڻ لاءِ (نوٽ: خاص طور تي جيڪڏهن توهان هر مهيني انهن گيگا بائيٽ جو کرايه ادا ڪريو).

ڪنٽينرز ذريعي ڊسڪ جو استعمال

هر دفعي توهان ميزبان مشين تي هڪ ڪنٽينر ٺاهي رهيا آهيو، /var/lib/docker ڊاريڪٽري ۾ ڪيتريون ئي فائلون ۽ ڊائريڪٽريون ٺاهي وينديون آهن، جن مان هيٺيان قابل ذڪر آهن:

  • ڊاريڪٽري /var/lib/docker/containers/container_ID - جڏهن معياري لاگنگ ڊرائيور استعمال ڪندي، اهو آهي جتي واقعا لاگ محفوظ ڪيا ويا آهن JSON فارميٽ ۾. تمام تفصيلي لاگ، گڏوگڏ لاگز جيڪي ڪو به نه پڙهي ٿو يا ٻي صورت ۾ پروسيس ڪري ٿو، اڪثر ڪري ڊسڪ مڪمل ٿيڻ جو سبب بڻن ٿا.
  • /var/lib/docker/overlay2 ڊاريڪٽري ۾ ڪنٽينر پڙهڻ-لکڻ جي تہن تي مشتمل آهي (overlay2 اڪثر لينڪس جي تقسيم ۾ ترجيح ڊرائيور آهي). جيڪڏهن ڪنٽينر پنهنجي فائل سسٽم ۾ ڊيٽا کي ذخيرو ڪري ٿو، پوء اهو هن ڊاريڪٽري ۾ آهي ته اهو رکيو ويندو.

اچو ته هڪ سسٽم جو تصور ڪريو جنهن تي هڪ پراڻي ڊاکر نصب ٿيل آهي، جيڪو ڪڏهن به ڪنٽينرز کي لانچ ڪرڻ يا تصويرون ٺاهڻ ۾ شامل نه ڪيو ويو آهي. ان جي ڊسڪ اسپيس استعمال جي رپورٽ هن طرح نظر ايندي:

$ docker system df
TYPE           TOTAL      ACTIVE     SIZE       RECLAIMABLE
Images         0          0          0B         0B
Containers     0          0          0B         0B
Local Volumes  0          0          0B         0B
Build Cache    0          0          0B         0B

اچو ته ڪجھ ڪنٽينر شروع ڪريون، مثال طور، NGINX:

$ docker container run --name www -d -p 8000:80 nginx:1.16

ڊسڪ کي ڇا ٿيندو:

  • تصويرون 126 MB تي قبضو ڪن ٿيون، اهو ساڳيو NGINX آهي جيڪو اسان ڪنٽينر ۾ شروع ڪيو.
  • ڪنٽينر هڪ مضحکہ خیز 2 بائيٽ کڻندا آهن.

$ docker system df
TYPE           TOTAL      ACTIVE     SIZE       RECLAIMABLE
Images         1          1          126M       0B (0%)
Containers     1          1          2B         0B (0%)
Local Volumes  0          0          0B         0B
Build Cache    0          0          0B         0B

نتيجي تي غور ڪندي، اسان وٽ اڃا تائين ڪا به جاء ناهي جيڪا اسان آزاد ڪري سگهون ٿا. جيئن ته 2 بائيٽ مڪمل طور تي بيڪار آهي، اچو ته تصور ڪريون ته اسان جي NGINX اڻڄاتل طور تي 100 ميگا بائيٽ جي ڊيٽا کي ڪٿي لکيو ۽ پنهنجي اندر بلڪل هن سائيز جي هڪ فائل test.img ٺاهي.

$ docker exec -ti www 
  dd if=/dev/zero of=test.img bs=1024 count=0 seek=$[1024*100]

اچو ته ٻيهر ميزبان تي ڊسڪ اسپيس استعمال جي جانچ ڪريون. اسان ڏسنداسين ته ڪنٽينر (ڪنٽينر) اتي 100 ميگا بائيٽ تي قبضو ڪري ٿو.

$ docker system df
TYPE           TOTAL      ACTIVE     SIZE       RECLAIMABLE
Images         1          1          126M       0B (0%)
Containers     1          1          104.9MB    0B (0%)
Local Volumes  0          0          0B         0B
Build Cache    0          0          0B         0B

منهنجو خيال آهي ته توهان جو جستجو ڪندڙ دماغ اڳ ۾ ئي حيران آهي ته اسان جي test.img فائل ڪٿي آهي. اچو ته ان کي ڳوليون:

$ find /var/lib/docker -type f -name test.img
/var/lib/docker/overlay2/83f177...630078/merged/test.img
/var/lib/docker/overlay2/83f177...630078/diff/test.img

تفصيل ۾ وڃڻ کان سواءِ، اسان نوٽ ڪري سگھون ٿا ته test.img فائل آسانيءَ سان پڙھي لکڻ واري سطح تي موجود آھي، overlay2 ڊرائيور جي ڪنٽرول ۾ آھي. جيڪڏهن اسان اسان جي ڪنٽينر کي روڪيو، ميزبان اسان کي ٻڌائي ٿو ته هي جڳهه، اصول ۾، آزاد ٿي سگهي ٿو:

# Stopping the www container
$ docker stop www

# Visualizing the impact on the disk usage
$ docker system df
TYPE           TOTAL      ACTIVE     SIZE       RECLAIMABLE
Images         1          1          126M       0B (0%)
Containers     1          0          104.9MB    104.9MB (100%)
Local Volumes  0          0          0B         0B
Build Cache    0          0          0B         0B

اسان اهو ڪيئن ڪري سگهون ٿا؟ ڪنٽينر کي ختم ڪرڻ سان، جيڪو پڙهڻ-لکڻ جي سطح تي لاڳاپيل جڳهه کي صاف ڪرڻ ۾ شامل ٿيندو.

ھيٺ ڏنل حڪم سان، توھان ھٽائي سگھو ٿا سڀئي نصب ٿيل ڪنٽينرز ھڪڙي ھڪڙي جھلي ۾ ۽ پنھنجي ڊسڪ کي صاف ڪري سگھوٿا انھن پاران ٺاھيل سڀني پڙھڻ واري فائلن جي.

$ docker container prune
WARNING! This will remove all stopped containers.
Are you sure you want to continue? [y/N] y
Deleted Containers:
5e7f8e5097ace9ef5518ebf0c6fc2062ff024efb495f11ccc89df21ec9b4dcc2

Total reclaimed space: 104.9MB

تنهن ڪري، اسان ڪنٽينر کي ختم ڪندي 104,9 ميگا بائيٽ کي آزاد ڪيو. پر جيئن ته اسان هاڻي اڳ ۾ ڊائون لوڊ ڪيل تصوير استعمال نٿا ڪريون، اهو پڻ اسان جي وسيلن کي حذف ڪرڻ ۽ آزاد ڪرڻ لاء اميدوار بڻجي ٿو:

$ docker system df
TYPE           TOTAL      ACTIVE     SIZE       RECLAIMABLE
Images         1          0          126M       126M (100%)
Containers     0          0          0B         0B
Local Volumes  0          0          0B         0B
Build Cache    0          0          0B         0B

نوٽ: جيستائين تصوير گهٽ ۾ گهٽ هڪ ڪنٽينر جي استعمال ۾ آهي، توهان هن چال کي استعمال ڪرڻ جي قابل نه هوندا.

prune ذيلي ڪمانڊ جيڪو اسان مٿي استعمال ڪيو آهي صرف بند ٿيل ڪنٽينرز تي اثر آهي. جيڪڏهن اسان نه رڳو ختم ڪرڻ چاهيون ٿا، پر هلندڙ ڪنٽينر پڻ، اسان کي انهن مان هڪ حڪم استعمال ڪرڻ گهرجي:

# Historical command
$ docker rm -f $(docker ps –aq)

# More recent command
$ docker container rm -f $(docker container ls -aq)

پاسي جا نوٽس: جيڪڏهن توهان استعمال ڪريو ٿا -rm پيٽرولر جڏهن هڪ ڪنٽينر شروع ڪيو، پوء جڏهن اهو بند ٿي ويندو، سڀني ڊسڪ اسپيس جيڪا ان تي قبضو ڪيو ويندو آزاد ڪيو ويندو.

ڊسڪ تصويرون استعمال ڪندي

ڪجھ سال اڳ، ڪيترن ئي سو ميگا بائيٽ جي تصوير جي سائيز مڪمل طور تي عام هئي: هڪ Ubuntu تصوير جو وزن 600 ميگا بائيٽ، ۽ هڪ Microsoft .Net تصوير ڪيترن ئي گيگا بائيٽ وزن هئي. انهن خراب ڏينهن ۾، صرف هڪ تصوير ڊائون لوڊ ڪرڻ توهان جي مفت ڊسڪ اسپيس تي وڏو ٽولو وٺي سگهي ٿو، جيتوڻيڪ توهان تصويرن جي وچ ۾ سطح حصيداري ڪري رهيا آهيو. اڄ - وڏي ساراهه آهي - تصويرن جو وزن تمام گهٽ آهي، پر ان جي باوجود، توهان جلدي دستياب وسيلن کي ڀري سگهو ٿا جيڪڏهن توهان ڪجهه احتياط نه ڪريو.

تصويرون جا ڪيترائي قسم آھن جيڪي سڌي طرح آخري استعمال ڪندڙ کي نظر نه اينديون آھن:

  • وچولي تصويرون، جن جي بنياد تي ٻيون تصويرون گڏ ڪيون ويون آهن - اهي ختم نه ٿي سگهن ٿيون جيڪڏهن توهان انهن "ٻين" تصويرن جي بنياد تي ڪنٽينر استعمال ڪندا آهيو؛
  • ڊانگنگ تصويرون وچولي تصويرون آهن جيڪي ڪنهن به هلندڙ ڪنٽينر جي حوالي سان نه آهن - انهن کي ختم ڪري سگهجي ٿو.
  • ھيٺ ڏنل حڪم سان توھان چيڪ ڪري سگھو ٿا پنھنجي سسٽم تي ڊنگنگ تصويرون لاءِ:

$ docker image ls -f dangling=true
REPOSITORY  TAG      IMAGE ID         CREATED             SIZE
none      none   21e658fe5351     12 minutes ago      71.3MB

توھان انھن کي ھيٺ ڏنل طريقي سان ختم ڪري سگھو ٿا:

$ docker image rm $(docker image ls -f dangling=true -q)

اسان پڻ استعمال ڪري سگھون ٿا prune subcommand:

$ docker image prune
WARNING! This will remove all dangling images.
Are you sure you want to continue? [y/N] y
Deleted Images:
deleted: sha256:143407a3cb7efa6e95761b8cd6cea25e3f41455be6d5e7cda
deleted: sha256:738010bda9dd34896bac9bbc77b2d60addd7738ad1a95e5cc
deleted: sha256:fa4f0194a1eb829523ecf3bad04b4a7bdce089c8361e2c347
deleted: sha256:c5041938bcb46f78bf2f2a7f0a0df0eea74c4555097cc9197
deleted: sha256:5945bb6e12888cf320828e0fd00728947104da82e3eb4452f

Total reclaimed space: 12.9kB

جيڪڏهن اسان اوچتو هڪ حڪم سان سڀني تصويرن کي مڪمل طور تي ختم ڪرڻ چاهيون ٿا (۽ نه رڳو ڊبل)، پوء اسان اهو ڪري سگهون ٿا:

$ docker image rm $(docker image ls -q)

حجم جي حساب سان ڊسڪ استعمال

حجم ڪنٽينر جي فائل سسٽم کان ٻاهر ڊيٽا کي ذخيرو ڪرڻ لاء استعمال ڪيا ويا آهن. مثال طور، جيڪڏهن اسان ڪنهن ايپليڪيشن جا نتيجا محفوظ ڪرڻ چاهيون ٿا ته جيئن انهن کي ڪنهن ٻئي طريقي سان استعمال ڪيو وڃي. ھڪڙو عام مثال ڊيٽابيس آھي.

اچو ته هڪ MongoDB ڪنٽينر شروع ڪريون، ڪنٽينر تي هڪ حجم ٻاهران لڳايو، ۽ ان مان ڊيٽابيس بيڪ اپ بحال ڪريو (اسان وٽ bck.json فائل ۾ موجود آهي):

# Running a mongo container
$ docker run --name db -v $PWD:/tmp -p 27017:27017 -d mongo:4.0

# Importing an existing backup (from a huge bck.json file)
$ docker exec -ti db mongoimport 
  --db 'test' 
  --collection 'demo' 
  --file /tmp/bck.json 
  --jsonArray

ڊيٽا ميزبان مشين تي /var/lib/docker/volumes ڊاريڪٽري ۾ واقع ٿيندي. پر ڪنٽينر جي پڙهڻ-لکڻ جي سطح تي ڇو نه؟ ڇو ته MongoDB تصوير جي Dockerfile ۾، /data/db ڊاريڪٽري (جتي MongoDB ان جي ڊيٽا کي ڊفالٽ طور محفوظ ڪري ٿو) کي حجم طور بيان ڪيو ويو آھي.

ڊڪر جا طريقا: پنھنجي مشين کي ردي جي صاف ڪريو

پاسي جو نوٽ: ڪيتريون ئي تصويرون جيڪي ڊيٽا پيدا ڪن ٿيون انهن ڊيٽا کي ذخيرو ڪرڻ لاء حجم استعمال ڪن ٿيون.

جڏهن اسان MongoDB سان ڪافي راند ڪندا آهيون ۽ ڪنٽينر کي روڪيو (يا شايد حذف به)، حجم ختم نه ڪيو ويندو. اهو اسان جي قيمتي ڊسڪ اسپيس کي کڻڻ جاري رکندو جيستائين اسان ان کي واضح طور تي هن طرح جي حڪم سان حذف نه ڪندا آهيون:

$ docker volume rm $(docker volume ls -q)

خير، يا اسان استعمال ڪري سگهون ٿا prune subcommand جيڪو اڳ ۾ ئي اسان کان واقف آهي:

$ docker volume prune
WARNING! This will remove all local volumes not used by at least one container.
Are you sure you want to continue? [y/N] y
Deleted Volumes:
d50b6402eb75d09ec17a5f57df4ed7b520c448429f70725fc5707334e5ded4d5
8f7a16e1cf117cdfddb6a38d1f4f02b18d21a485b49037e2670753fa34d115fc
599c3dd48d529b2e105eec38537cd16dac1ae6f899a123e2a62ffac6168b2f5f
...
732e610e435c24f6acae827cd340a60ce4132387cfc512452994bc0728dd66df
9a3f39cc8bd0f9ce54dea3421193f752bda4b8846841b6d36f8ee24358a85bae
045a9b534259ec6c0318cb162b7b4fca75b553d4e86fc93faafd0e7c77c79799
c6283fe9f8d2ca105d30ecaad31868410e809aba0909b3e60d68a26e92a094da

Total reclaimed space: 25.82GB
luc@saturn:~$

تصوير ٺاهڻ واري ڪيش لاءِ ڊسڪ استعمال ڪندي

Docker 18.09 ۾، تصوير ٺاهڻ واري عمل ۾ ڪجهه تبديليون آيون آهن BuildKit اوزار جي مهرباني. اها شيءِ پروسيس جي رفتار کي وڌائي ٿي ۽ ڊيٽا اسٽوريج ۽ سيڪيورٽي انتظام کي بهتر بڻائي ٿي. هتي اسان هن شاندار اوزار جي سڀني تفصيلن تي غور نه ڪنداسين؛ اسان صرف ان ڳالهه تي ڌيان ڏينداسين ته اهو ڪيئن ڊسڪ اسپيس استعمال جي مسئلن کي حل ڪري ٿو.

اچو ته اسان وٽ هڪ مڪمل طور تي سادي Node.Js ايپليڪيشن آهي:

  • index.js فائل هڪ سادي HTTP سرور شروع ڪري ٿو جيڪو هر هڪ حاصل ڪيل درخواست تي هڪ لائن سان جواب ڏئي ٿو:
  • package.json فائل انحصار کي بيان ڪري ٿو، جن مان صرف ايڪسپريس استعمال ڪيو ويندو آهي HTTP سرور کي هلائڻ لاء:

$ cat index.js
var express = require('express');
var util    = require('util');
var app = express();
app.get('/', function(req, res) {
  res.setHeader('Content-Type', 'text/plain');
  res.end(util.format("%s - %s", new Date(), 'Got Request'));
});
app.listen(process.env.PORT || 80);

$ cat package.json
    {
      "name": "testnode",
      "version": "0.0.1",
      "main": "index.js",
      "scripts": {
        "start": "node index.js"
      },
      "dependencies": {
        "express": "^4.14.0"
      }
    }

تصوير جي تعمير لاء Dockerfile هن طرح ڏسڻ ۾ اچي ٿو:

FROM node:13-alpine
COPY package.json /app/package.json
RUN cd /app && npm install
COPY . /app/
WORKDIR /app
EXPOSE 80
CMD ["npm", "start"]

اچو ته تصوير کي معمولي طريقي سان ٺاهيون، بغير استعمال ڪرڻ جي BuildKit:

$ docker build -t app:1.0 .

جيڪڏهن اسان ڊسڪ اسپيس جي استعمال جي جانچ ڪريون ٿا، اسان ڏسي سگهون ٿا ته صرف بنيادي تصوير (نوڊ: 13-الپائن) ۽ ٽارگيٽ تصوير (ايپ: 1.0) جاء وٺي رهيا آهن:

TYPE           TOTAL      ACTIVE     SIZE       RECLAIMABLE
Images         2          0          109.3MB    109.3MB (100%)
Containers     0          0          0B         0B
Local Volumes  0          0          0B         0B
Build Cache    0          0          0B         0B

اچو ته اسان جي ايپليڪيشن جو ٻيو نسخو ٺاهيو، BuildKit استعمال ڪندي. هن کي ڪرڻ لاء، اسان کي صرف DOCKER_BUILDKIT متغير کي 1 تي سيٽ ڪرڻ جي ضرورت آهي:

$ DOCKER_BUILDKIT=1 docker build -t app:2.0 .

جيڪڏهن اسان هاڻي ڊسڪ جي استعمال کي چيڪ ڪنداسين، اسان ڏسنداسين ته تعمير ڪيش (buid-cache) هاڻي اتي شامل آهي:

$ docker system df
TYPE           TOTAL      ACTIVE     SIZE       RECLAIMABLE
Images         2          0          109.3MB    109.3MB (100%)
Containers     0          0          0B         0B
Local Volumes  0          0          0B         0B
Build Cache    11         0          8.949kB    8.949kB

ان کي صاف ڪرڻ لاء، ھيٺ ڏنل حڪم استعمال ڪريو:

$ docker builder prune
WARNING! This will remove all dangling build cache.
Are you sure you want to continue? [y/N] y
Deleted build cache objects:
rffq7b06h9t09xe584rn4f91e
ztexgsz949ci8mx8p5tzgdzhe
3z9jeoqbbmj3eftltawvkiayi

Total reclaimed space: 8.949kB

سڀ صاف ڪريو!

تنهن ڪري، اسان ڊسڪ اسپيس کي صاف ڪرڻ تي غور ڪيو جيڪو ڪنٽينرز، تصويرن ۽ حجمن تي قبضو ڪيو. prune subcommand اسان کي هن سان مدد ڪري ٿي. پر اهو پڻ ڊاکر سسٽم جي سطح تي استعمال ڪري سگهجي ٿو، ۽ اهو هر شيء کي صاف ڪري ڇڏيندو جيڪو اهو ڪري سگهي ٿو:

$ docker system prune
WARNING! This will remove:
  - all stopped containers
  - all networks not used by at least one container
  - all dangling images
  - all dangling build cache

Are you sure you want to continue? [y/N]

جيڪڏهن ڪنهن سبب جي ڪري توهان ڊڪر هلائيندڙ مشين تي ڊسڪ اسپيس بچائي رهيا آهيو، ته پوءِ وقتي طور تي هن حڪم کي هلائڻ هڪ عادت بڻجي وڃي.

جو ذريعو: www.habr.com

تبصرو شامل ڪريو