ارے حبر! مضمون کا ترجمہ آپ کی توجہ میں پیش کرتا ہوں۔ مصنف .
آج ہم اس بارے میں بات کریں گے کہ ڈوکر میزبان مشین کی ڈسک کی جگہ کو کس طرح استعمال کرتا ہے، اور ہم یہ بھی معلوم کریں گے کہ اس جگہ کو غیر استعمال شدہ امیجز اور کنٹینرز کے سکریپ سے کیسے خالی کیا جائے۔
کل کھپت
ڈوکر ایک اچھی چیز ہے، شاید آج بہت کم لوگ اس پر شک کرتے ہیں۔ ابھی چند سال پہلے، اس پروڈکٹ نے ہمیں کسی بھی ماحول کو بنانے، ڈیلیور کرنے اور چلانے کا ایک بالکل نیا طریقہ دیا، جس سے ہمیں CPU اور RAM کے وسائل کو نمایاں طور پر بچانے کی اجازت دی گئی۔ اس کے علاوہ (اور کچھ کے لیے یہ سب سے اہم چیز ہوگی) Docker نے ہمیں اپنے پیداواری ماحول کے لائف سائیکل مینجمنٹ کو ناقابل یقین حد تک آسان اور متحد کرنے کی اجازت دی ہے۔
تاہم، جدید زندگی کی یہ تمام لذتیں قیمت پر آتی ہیں۔ جب ہم کنٹینرز چلاتے ہیں، اپنی تصاویر ڈاؤن لوڈ کرتے ہیں یا تخلیق کرتے ہیں، اور پیچیدہ ماحولیاتی نظام کو تعینات کرتے ہیں، تو ہمیں ادائیگی کرنی پڑتی ہے۔ اور ہم دوسری چیزوں کے علاوہ ڈسک کی جگہ کے ساتھ ادائیگی کرتے ہیں۔
اگر آپ نے کبھی نہیں سوچا کہ ڈوکر آپ کی مشین پر کتنی جگہ لیتا ہے، تو آپ اس کمانڈ کے آؤٹ پٹ سے ناخوشگوار طور پر حیران ہوسکتے ہیں:
$ docker system df
یہ مختلف سیاق و سباق میں ڈوکر کے ڈسک کے استعمال کو ظاہر کرتا ہے:
- امیجز – ان تصاویر کا کل سائز جو امیج ریپوزٹریز سے ڈاؤن لوڈ کی گئی تھیں اور آپ کے سسٹم پر بنائی گئی تھیں۔
- کنٹینرز - کنٹینرز کو چلانے میں استعمال ہونے والی ڈسک کی کل مقدار (یعنی تمام کنٹینرز کی پڑھنے لکھنے کی تہوں کی کل مقدار)؛
- مقامی حجم - کنٹینرز میں نصب مقامی اسٹوریج کا حجم؛
- بلڈ کیش - امیج بنانے کے عمل کے ذریعہ تیار کردہ عارضی فائلیں (BuildKit ٹول کا استعمال کرتے ہوئے، Docker ورژن 18.09 سے شروع ہو کر دستیاب ہے)۔
میں شرط لگاتا ہوں کہ اس سادہ منتقلی کے بعد آپ کوڑے کی اپنی ڈسک کو صاف کرنے اور قیمتی گیگا بائٹس کو دوبارہ زندہ کرنے کے خواہشمند ہیں (نوٹ: خاص طور پر اگر آپ ہر ماہ ان گیگا بائٹس کا کرایہ ادا کرتے ہیں)۔
کنٹینرز کے ذریعہ ڈسک کا استعمال
جب بھی آپ میزبان مشین پر کنٹینر بناتے ہیں، /var/lib/docker ڈائرکٹری میں کئی فائلیں اور ڈائریکٹریز بنتی ہیں، جن میں سے درج ذیل قابل توجہ ہیں:
- ڈائریکٹری /var/lib/docker/containers/container_ID - معیاری لاگنگ ڈرائیور کا استعمال کرتے وقت، یہ وہ جگہ ہے جہاں ایونٹ لاگز JSON فارمیٹ میں محفوظ کیے جاتے ہیں۔ بہت زیادہ تفصیلی لاگز، نیز ایسے لاگز جنہیں کوئی نہیں پڑھتا یا دوسری صورت میں عمل نہیں کرتا، اکثر ڈسکوں کو بھرنے کا سبب بنتے ہیں۔
- /var/lib/docker/overlay2 ڈائرکٹری کنٹینر پڑھنے لکھنے کی تہوں پر مشتمل ہے (زیادہ تر لینکس کی تقسیم میں اوورلے 2 ترجیحی ڈرائیور ہے)۔ اگر کنٹینر اپنے فائل سسٹم میں ڈیٹا کو اسٹور کرتا ہے، تو یہ اس ڈائرکٹری میں ہے جو اسے رکھا جائے گا۔
آئیے ایک ایسے نظام کا تصور کریں جس پر ایک قدیم ڈوکر نصب ہے، جو کنٹینرز کو لانچ کرنے یا تصاویر بنانے میں کبھی شامل نہیں رہا۔ اس کی ڈسک اسپیس کے استعمال کی رپورٹ اس طرح نظر آئے گی:
$ 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 subcommand استعمال کی ہے اس کا اثر صرف رکے ہوئے کنٹینرز پر پڑتا ہے۔ اگر ہم نہ صرف رکے ہوئے بلکہ چلنے والے کنٹینرز کو بھی حذف کرنا چاہتے ہیں تو ہمیں ان میں سے ایک کمانڈ استعمال کرنا چاہئے:
# Historical command
$ docker rm -f $(docker ps –aq)
# More recent command
$ docker container rm -f $(docker container ls -aq)سائیڈ نوٹ: اگر آپ کنٹینر شروع کرتے وقت -rm پیرامیٹر استعمال کرتے ہیں، تو جب یہ رک جاتا ہے، تو ڈسک کی تمام جگہ خالی ہو جائے گی جس پر اس نے قبضہ کیا تھا۔
ڈسک امیجز کا استعمال
چند سال پہلے، کئی سو میگا بائٹس کی ایک تصویر کا سائز مکمل طور پر نارمل تھا: ایک اوبنٹو امیج کا وزن 600 میگا بائٹس، اور ایک مائیکروسافٹ نیٹ امیج کا وزن کئی گیگا بائٹس تھا۔ ان شگفتہ دنوں میں، صرف ایک تصویر کو ڈاؤن لوڈ کرنے سے آپ کی مفت ڈسک کی جگہ پر بہت زیادہ اثر پڑ سکتا ہے، یہاں تک کہ اگر آپ تصاویر کے درمیان لیول کا اشتراک کر رہے ہوں۔ آج - عظیم کی تعریف ہو - تصاویر کا وزن بہت کم ہے، لیکن اس کے باوجود، اگر آپ کچھ احتیاطی تدابیر اختیار نہیں کرتے ہیں تو آپ دستیاب وسائل کو تیزی سے بھر سکتے ہیں۔
تصاویر کی کئی قسمیں ہیں جو آخری صارف کو براہ راست نظر نہیں آتی ہیں:
- انٹرمیڈیٹ امیجز، جن کی بنیاد پر دوسری تصاویر اکٹھی کی جاتی ہیں - اگر آپ ان "دوسری" تصاویر پر مبنی کنٹینرز استعمال کرتے ہیں تو انہیں حذف نہیں کیا جا سکتا۔
- لٹکتی ہوئی تصاویر درمیانی تصاویر ہیں جن کا کسی بھی کنٹینر سے حوالہ نہیں دیا گیا ہے - انہیں حذف کیا جا سکتا ہے۔
- درج ذیل کمانڈ کے ذریعے آپ اپنے سسٹم پر لٹکتی ہوئی تصاویر کو چیک کر سکتے ہیں۔
$ 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 سرور کو چلانے کے لیے صرف 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تمام کو صاف کریں!
لہذا، ہم نے کنٹینرز، تصاویر اور حجموں کے زیر قبضہ ڈسک کی جگہ کو صاف کرنے پر غور کیا۔ 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]اگر کسی وجہ سے آپ Docker چلانے والی مشین پر ڈسک کی جگہ بچا رہے ہیں، تو وقتاً فوقتاً اس کمانڈ کو چلانا عادت بن جانا چاہیے۔
ماخذ: www.habr.com