د ډاکر لارښوونې: خپل ماشین له کثافاتو پاک کړئ

د ډاکر لارښوونې: خپل ماشین له کثافاتو پاک کړئ

اې حبره! زه ستاسو پام ته د مقالې ژباړه وړاندې کوم "د ډاکر لارښوونې: خپل سیمه ایز ماشین پاک کړئ" لیکوال لوک جوګري.

نن ورځ موږ به پدې اړه وغږیږو چې څنګه ډاکر د کوربه ماشین ډیسک ځای کاروي ، او موږ به دا هم معلومه کړو چې دا ځای څنګه د غیر کارول شوي عکسونو او کانټینرونو سکریپ څخه خلاص کړو.


د ډاکر لارښوونې: خپل ماشین له کثافاتو پاک کړئ

ټول مصرف

ډاکر یو ښه شی دی، شاید نن ورځ لږ خلک شک لري. یوازې یو څو کاله دمخه ، دې محصول موږ ته د هر چاپیریال رامینځته کولو ، تحویلولو او چلولو لپاره په بشپړ ډول نوې لاره راکړه ، موږ ته اجازه راکوي د پام وړ د CPU او رام سرچینې خوندي کړو. سربیره پردې (او د ځینو لپاره دا به خورا مهم شی وي) ډاکر موږ ته اجازه راکړه چې زموږ د تولید چاپیریال د ژوند دورې مدیریت په حیرانونکي ډول ساده او متحد کړو.

په هرصورت، د عصري ژوند دا ټولې خوښۍ په قیمت کې راځي. کله چې موږ کانټینر چلوو، خپل عکسونه ډاونلوډ یا جوړ کړو، او پیچلي ایکوسیستمونه ځای په ځای کړو، موږ باید پیسې ورکړو. او موږ د نورو شیانو په مینځ کې ، د ډیسک ځای سره تادیه کوو.

که تاسو هیڅکله فکر نه دی کړی چې ډاکر واقعیا ستاسو په ماشین کې څومره ځای نیسي ، نو تاسو ممکن د دې قوماندې له محصول څخه په ناخوښۍ سره حیران شئ:

$ docker system df

د ډاکر لارښوونې: خپل ماشین له کثافاتو پاک کړئ

دا په مختلفو شرایطو کې د ډاکر ډیسک کارول ښیې:

  • انځورونه - د انځورونو ټوله اندازه چې د عکس ذخیره کولو څخه ډاونلوډ شوي او ستاسو په سیسټم کې جوړ شوي؛
  • کانټینرونه - د ډیسک ځای ټول مقدار چې د چلولو کانټینرونو لخوا کارول کیږي (د ټولو کانټینرونو د لوستلو لیکلو پرتونو ټول حجم)؛
  • محلي حجم - د محلي ذخیرې حجم چې په کانتینرونو کې ایښودل شوی؛
  • کیچ جوړ کړئ - لنډمهاله فایلونه چې د عکس جوړولو پروسې لخوا رامینځته شوي (د BuildKit وسیلې په کارولو سره ، د ډاکر نسخه 18.09 سره پیل کې شتون لري).

زه شرط لرم چې د دې ساده لیږد وروسته تاسو لیواله یاست چې خپل ډیسک د کثافاتو څخه پاک کړئ او قیمتي ګیګابایټ بیرته ژوند ته راوړو (یادونه: په ځانګړي توګه که تاسو هره میاشت د دې ګیګابایټ کرایه ورکوئ).

د کانتینرونو لخوا د ډیسک کارول

هرکله چې تاسو په کوربه ماشین کې کانټینر رامینځته کوئ ، ډیری فایلونه او لارښودونه په /var/lib/docker ډایرکټر کې رامینځته کیږي ، چې لاندې یې د پام وړ دي:

  • لارښود /var/lib/docker/containers/container_ID - کله چې د معیاري لاګینګ ډرایور کاروئ ، دا هغه ځای دی چیرې چې د پیښې لاګونه د JSON ب formatه کې خوندي کیږي. ډیر مفصل لاګونه، او همدارنګه هغه لاګونه چې هیڅوک یې نه لوستل یا بل ډول پروسس کوي، ډیری وختونه د ډیسکونو ډکیدو لامل کیږي.
  • /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

یادونه: تر هغه چې عکس لږترلږه د یو کانټینر لخوا کارول کیږي، تاسو به نشئ کولی دا چل وکاروئ.

د پریون فرعي کمانډ چې موږ پورته کارولی یوازې په بند شوي کانټینرونو اغیزه لري. که موږ غواړو چې نه یوازې بند شوي بلکه د چلولو کانټینرونه هم حذف کړو، موږ باید د دې کمانډونو څخه یو وکاروو:

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

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

اړخ یادښتونه: که تاسو د کانټینر پیل کولو پرمهال -rm پیرامیټر وکاروئ ، نو کله چې ودریږي ، د ډیسک ټول ځای چې دا یې نیولی وي خلاص شي.

د ډیسک عکسونو کارول

څو کاله دمخه، د څو سوه میګابایټ عکس اندازه په بشپړه توګه نورمال وه: د اوبنټو عکس 600 میګابایټ وزن درلود، او د مایکروسافټ .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 فرعي کمانډ هم وکاروو:

$ 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 عکس په ډاکر فایل کې ، /data/db لارښود (چیرې چې MongoDB خپل ډیټا په ډیفالټ ذخیره کوي) د حجم په توګه تعریف شوی.

د ډاکر لارښوونې: خپل ماشین له کثافاتو پاک کړئ

اړخ یادونه: ډیری عکسونه چې باید ډیټا تولید کړي د دې معلوماتو ذخیره کولو لپاره حجمونه کاروي.

کله چې موږ د MongoDB سره کافي لوبه وکړو او کانټینر ودروو (یا شاید حتی حذف کړئ) ، حجم به حذف نشي. دا به زموږ د قیمتي ډیسک ځای نیولو ته دوام ورکړي تر هغه چې موږ دا په واضح ډول د داسې قوماندې سره حذف نه کړو:

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

ښه، یا موږ کولی شو د prune فرعي کمانډ وکاروو چې دمخه موږ ته پیژندل شوی دی:

$ 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:~$

د عکس جوړونې کیچ لپاره ډیسک کارول

په ډاکر 18.09 کې ، د عکس رامینځته کولو پروسه د BuildKit وسیلې څخه مننه ځینې بدلونونه تیر کړي. دا شی د پروسې سرعت زیاتوي او د معلوماتو ذخیره کولو او امنیت مدیریت ته وده ورکوي. دلته به موږ د دې په زړه پورې وسیلې ټول توضیحات په پام کې ونیسو؛ موږ به یوازې په دې تمرکز وکړو چې دا څنګه د ډیسک ځای کارولو مسلې حل کوي.

راځئ چې ووایو موږ په بشپړ ډول ساده Node.Js غوښتنلیک لرو:

  • د index.js فایل یو ساده HTTP سرور پیل کوي چې هرې غوښتنې ته د یوې کرښې سره ځواب ورکوي:
  • د package.json فایل انحصار تعریفوي، چې یوازې د HTTP سرور چلولو لپاره expressjs کارول کیږي:

$ 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"
      }
    }

د عکس جوړولو لپاره ډاکر فایل داسې ښکاري:

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

ټول پاک کړه!

نو ، موږ د ډیسک ځای پاکولو ته ګورو چې د کانټینرونو ، عکسونو او حجمونو لخوا نیول شوي. د پریون فرعي کمانډ له موږ سره پدې کې مرسته کوي. مګر دا د ډاکر سیسټم په کچه هم کارول کیدی شي ، او دا به هرڅه پاک کړي چې دا یې کولی شي:

$ 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

Add a comment