დოკერის რჩევები: გაასუფთავეთ თქვენი მანქანა უსარგებლო მასალისგან

ჰეი ჰაბრ! თქვენს ყურადღებას წარმოგიდგენთ სტატიის თარგმანს "დოკერის რჩევები: გაასუფთავეთ თქვენი ადგილობრივი მანქანა" ავტორი ლუკ იუგერი.

დღეს ჩვენ ვისაუბრებთ იმაზე, თუ როგორ იყენებს Docker მასპინძელი აპარატის დისკის ადგილს და ასევე გავარკვევთ, თუ როგორ გავათავისუფლოთ ეს სივრცე გამოუყენებელი სურათებისა და კონტეინერების ნარჩენებისგან.

მთლიანი მოხმარება

დოკერი მაგარი რამეა, დღეს ალბათ ცოტას ეპარება ეჭვი. სულ რამდენიმე წლის წინ, ამ პროდუქტმა მოგვცა სრულიად ახალი გზა ნებისმიერი გარემოს შესაქმნელად, მიწოდებისა და გაშვებისთვის, რაც საშუალებას გვაძლევს მნიშვნელოვნად დავზოგოთ CPU და 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

Ყველაფრის გასუფთავება!

ასე რომ, ჩვენ გადავხედეთ დისკის სივრცის გაწმენდას, რომელიც დაკავებულია კონტეინერებით, სურათებით და ტომებით. ამაში გვეხმარება prune ქვებრძანება. მაგრამ ის ასევე შეიძლება გამოყენებულ იქნას დოკერის სისტემის დონეზე და გაასუფთავებს ყველაფერს, რაც შეუძლია:

$ 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