Հե՜յ Հաբր։ Ձեր ուշադրությանն եմ ներկայացնում հոդվածի թարգմանությունը
Այսօր մենք կխոսենք այն մասին, թե ինչպես է Docker-ն օգտագործում հյուրընկալող մեքենայի սկավառակի տարածությունը, և մենք նաև պարզելու ենք, թե ինչպես ազատել այս տարածքը չօգտագործված պատկերների և բեռնարկղերի մնացորդներից:
Ընդհանուր սպառումը
Docker-ը հիանալի բան է, հավանաբար քչերն են այսօր կասկածում դրան: Ընդամենը մի քանի տարի առաջ այս արտադրանքը մեզ տվեց ցանկացած միջավայր ստեղծելու, մատուցելու և գործարկելու բոլորովին նոր եղանակ՝ թույլ տալով զգալիորեն խնայել պրոցեսորի և RAM-ի ռեսուրսները: Բացի սրանից (և ոմանց համար դա կլինի ամենակարևորը) Docker-ը մեզ թույլ է տվել անհավատալիորեն պարզեցնել և միավորել մեր արտադրական միջավայրերի կյանքի ցիկլի կառավարումը:
Այնուամենայնիվ, ժամանակակից կյանքի այս բոլոր հաճույքներն իրենց գինն ունեն: Երբ մենք գործարկում ենք կոնտեյներներ, ներբեռնում կամ ստեղծում ենք մեր սեփական պատկերները և տեղակայում բարդ էկոհամակարգեր, մենք պետք է վճարենք: Եվ մենք վճարում ենք, ի թիվս այլ բաների, սկավառակի տարածությամբ:
Եթե դուք երբեք չեք մտածել, թե իրականում որքան տեղ է զբաղեցնում Docker-ը ձեր մեքենայի վրա, կարող եք տհաճորեն զարմանալ այս հրամանի արդյունքից.
$ docker system df
Սա ցույց է տալիս Docker-ի սկավառակի օգտագործումը տարբեր համատեքստերում.
- պատկերներ – պատկերների ընդհանուր չափը, որոնք ներբեռնվել են պատկերների պահոցներից և կառուցվել ձեր համակարգում.
- կոնտեյներներ – սկավառակի տարածության ընդհանուր քանակն է, որն օգտագործվում է գործարկվող բեռնարկղերի կողմից (նկատի ունի բոլոր բեռնարկղերի կարդալու-գրելու շերտերի ընդհանուր ծավալը).
- տեղական ծավալներ - բեռնարկղերի վրա տեղադրված տեղական պահեստի ծավալը.
- build cache – ժամանակավոր ֆայլեր, որոնք ստեղծվել են պատկերի կառուցման գործընթացի արդյունքում (օգտագործելով BuildKit գործիքը, որը հասանելի է Docker 18.09 տարբերակից սկսած):
Գրազ կգամ, որ այս պարզ փոխանցումից հետո դուք ցանկանում եք մաքրել ձեր սկավառակը աղբից և կյանքի կոչել թանկարժեք գիգաբայթները (նշեք. հատկապես, եթե դուք ամեն ամիս վարձավճար եք վճարում այս գիգաբայթերի համար):
Սկավառակի օգտագործումը բեռնարկղերի կողմից
Ամեն անգամ, երբ դուք կոնտեյներ եք ստեղծում հյուրընկալող մեքենայի վրա, մի քանի ֆայլեր և գրացուցակներ են ստեղծվում /var/lib/docker գրացուցակում, որոնց թվում պետք է նշել հետևյալը.
- Գրացուցակ /var/lib/docker/containers/container_ID – ստանդարտ գրանցման դրայվերն օգտագործելիս այստեղ է, որ իրադարձությունների մատյանները պահվում են JSON ձևաչափով: Չափազանց մանրամասն տեղեկամատյանները, ինչպես նաև տեղեկամատյանները, որոնք ոչ ոք չի կարդում կամ այլ կերպ չի մշակում, հաճախ ստիպում են սկավառակները լցվել:
- /var/lib/docker/overlay2 գրացուցակը պարունակում է կոնտեյների կարդալ-գրելու շերտեր (overlay2-ը նախընտրելի դրայվերն է Linux բաշխումների մեծ մասում): Եթե բեռնարկղը տվյալները պահում է իր ֆայլային համակարգում, ապա այն կտեղադրվի հենց այս գրացուցակում:
Եկեք պատկերացնենք մի համակարգ, որի վրա տեղադրված է անփոփոխ Docker, որը երբեք չի ներգրավվել կոնտեյներների գործարկման կամ պատկերների կառուցման մեջ: Սկավառակի տարածքի օգտագործման հաշվետվությունը կունենա հետևյալ տեսքը.
$ 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 ՄԲ, սա նույն 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 պարամետրը, ապա երբ այն դադարում է, սկավառակի վրա զբաղեցրած ողջ տարածքը կազատվի:
Օգտագործելով սկավառակի պատկերներ
Մի քանի տարի առաջ մի քանի հարյուր մեգաբայթ պատկերի չափը լրիվ նորմալ էր՝ 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 ենթահրամանը.
$ 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 ենթահրամանը, որն արդեն ծանոթ է մեզ.
$ 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 ֆայլը սահմանում է կախվածությունները, որոնցից միայն expressjs-ն օգտագործվում է 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 .
Եթե մենք հիմա ստուգենք սկավառակի օգտագործումը, կտեսնենք, որ build cache-ը (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 համակարգի մակարդակում, և այն կմաքրի այն ամենը, ինչ կարող է.
$ 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-ով աշխատող մեքենայի վրա, ապա այս հրամանի պարբերաբար գործարկումը պետք է սովորություն դառնա:
Source: www.habr.com