Совети за докер: исчистете ја машината од ѓубре

Еј Хабр! Ви го презентирам преводот на статијата „Совети за докер: исчистете ја вашата локална машина“ авторот Лук Југери.

Денес ќе разговараме за тоа како 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 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 при стартување на контејнер, тогаш кога ќе престане, целиот простор на дискот што го зафатил ќе се ослободи.

Користење на слики од дискот

Пред неколку години, големината на сликата од неколку стотици мегабајти беше сосема нормална: сликата на 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. Но, зошто да не на ниво на читање-пишување на контејнерот? Бидејќи во Dockerfile на сликата 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:~$

Користење на диск за кеш за градење слики

Во 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 .

Ако сега ја провериме употребата на дискот, ќе видиме дека кешот за изградба (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