Dockeri näpunäited: Puhastage oma masin prügist

Tere, Habr! Esitlen teile tõlget artiklist "Dockeri nõuanded: puhastage oma kohalik masin" autor Luc Juggery.

Täna räägime sellest, kuidas Docker kasutab hostmasina kettaruumi, ning vaatame, kuidas vabastada seda ruumi kasutamata image'ite ja konteinerite jääkidest.

Kogutarbimine

Docker on suurepärane tööriist ja ilmselt kahtlevad selles tänapäeval vähesed. Vaid mõni aasta tagasi tõi see toode meieni täiesti uue viisi mis tahes keskkonna loomiseks, juurutamiseks ja käivitamiseks, aidates märgatavalt säästa protsessori- ja RAM-ressursse. Lisaks sellele — ja mõne jaoks on see isegi kõige olulisem — muutis Docker kasutatavate töökeskkondade elutsükli halduse uskumatult lihtsaks ja ühtseks.

Kuid kõigi nende tänapäevaste mugavuste eest tuleb maksta. Kui käivitame konteinereid, laadime alla või loome oma image'eid või juurutame keerukaid ökosüsteeme, maksame selle eest muu hulgas kettaruumiga.

Kui te pole kunagi mõelnud, kui palju ruumi Docker teie masinas tegelikult hõivab, siis võib selle käsu väljund teid ebameeldivalt üllatada:

$ docker system df

Siin on näidatud Dockeri kettakasutus eri lõigetes:

• image'id (images) – image'ite kogumaht, mis on image-hoidlatest alla laaditud või teie süsteemis loodud;
• konteinerid (containers) – töötavate konteinerite kasutatav kettaruumi kogumaht (st kõigi konteinerite lugemis-kirjutamiskihi kogumaht);
• kohalikud köited (local volumes) – konteineritesse ühendatud kohalike andmemahtude maht;
• build cache – image'ite loomise protsessi käigus genereeritud ajutised failid (BuildKit tööriista kasutamisel, mis on saadaval alates Dockeri versioonist 18.09).

Võin kihla vedada, et juba pärast seda lihtsat loetelu tahate ketta prügist puhastada ja väärtuslikud gigabaidid tagasi saada.

Konteinerite kettakasutus

Iga kord, kui konteiner luuakse, tekitatakse hostmasinas kataloogi /var/lib/docker mitu faili ja kataloogi, millest tasub esile tõsta järgmisi:

• Kataloog /var/lib/docker/containers/ID_контейнера – standardse logidraiveri kasutamisel salvestatakse sündmuste logid JSON-vormingus just siia. Liiga detailsed logid, samuti logid, mida keegi ei loe ega töötle muul viisil, põhjustavad sageli ketaste täitumist.
• Kataloog /var/lib/docker/overlay2 – sisaldab konteinerite kirjutatavaid kihte (overlay2 on enamikus Linuxi distributsioonides eelistatud draiver). Kui konteiner salvestab andmeid oma failisüsteemi, paigutatakse need just sellesse kataloogi.

Kujutame ette süsteemi, kuhu on paigaldatud täiesti puhas Docker, mida pole kordagi kasutatud konteinerite käivitamiseks ega image'ite ehitamiseks. Selle kettakasutuse aruanne näeb välja selline:

$ 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

Käivitame mõne konteineri, näiteks NGINX-i:

$ docker container run --name www -d -p 8000:80 nginx:1.16

Mis kettaga toimub:

• Image'id (images) võtavad enda alla 126 MB – see on seesama NGINX, mille konteineris käivitasime;
• Konteinerid (containers) võtavad enda alla naeruväärsed 2 baiti.

$ 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

Väljundi järgi otsustades pole meil veel ruumi, mida saaks vabastada. Kuna 2 baiti pole üldse tõsiseltvõetav, kujutame ette, et meie NGINX kirjutas täiesti ootamatult kuhugi 100 megabaiti andmeid ja lõi enda sisse täpselt sellise suurusega faili test.img.

$ docker exec -ti www 
  dd if=/dev/zero of=test.img bs=1024 count=0 seek=$[1024*100]

Uurime uuesti kettakasutust hostis. Näeme, et konteiner (containers) võtab seal enda alla 100 megabaiti.

$ 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

Arvan, et teie uudishimulik mõistus küsib juba, kus meie fail test.img asub. Otsime selle üles:

$ 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

Üksikasjadesse laskumata võib märkida, et fail test.img paikneb mugavalt overlay2 draiveri hallataval lugemis-kirjutamiskihil. Kui aga konteineri peatame, annab host meile märku, et selle ruumi saab põhimõtteliselt vabastada:

# 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

Kuidas seda teha? Kustutades konteineri, mille tulemusel puhastatakse vastav ruum lugemis-kirjutamiskihil.

Järgmise käsuga saate kõik installitud konteinerid ühe korraga eemaldada ja puhastada ketta kõigist nende loodud lugemis-kirjutamiskihi failidest:

$ 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

Niisiis vabastasime konteineri kustutamisega 104,9 megabaiti. Kuid kuna me varem allalaaditud image’it enam ei kasuta, on ka see nüüd eemaldamise ja ressursside vabastamise kandidaat:

$ 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

Tähelepanu: seni kuni image on kasutusel vähemalt ühe konteineri poolt, ei saa te seda võtet kasutada.

Alamkäsk prune, mida eespool kasutasime, toimib ainult peatatud konteinerite puhul. Kui soovime eemaldada mitte ainult peatatud, vaid ka töötavad konteinerid, tuleks kasutada üht neist käskudest:

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

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

Märkus: kui kasutada konteineri käivitamisel parameetrit —rm, vabastatakse selle peatamisel kogu kettaruum, mida see hõivas.

Image’ite kettakasutus

Mõni aasta tagasi oli mitmesaja megabaidine image täiesti tavapärane: Ubuntu image kaalus 600 megabaiti ja Microsoft .Neti image mitu gigabaiti. Neil vanadel aegadel võis juba ainuüksi ühe image’i allalaadimine teie vaba kettaruumi tõsiselt vähendada, isegi kui jagasite kihte image’ite vahel. Tänapäeval, õnneks, on image’id palju väiksemad, kuid ka sel juhul võib olemasolevad ressursid kiiresti täis kulutada, kui mitte rakendada mõningaid ettevaatusabinõusid.

On olemas mitut tüüpi image’eid, mis lõppkasutajale otseselt nähtavad ei ole:

• intermediate image'id, mille põhjal on koostatud teised image'id — neid ei saa eemaldada, kui kasutate konteinereid, mis põhinevad neil samadel „teistel” image'idel;
• dangling image'id on intermediate image'id, millele ei viita ükski töötav konteiner — need saab eemaldada.
• Järgmise käsuga saate kontrollida, kas teie süsteemis leidub dangling image'e:

$ docker image ls -f dangling=true
REPOSITORY  TAG      IMAGE ID         CREATED             SIZE
none      none   21e658fe5351     12 minutes ago      71.3MB

Neid saab eemaldada järgmiselt:

$ docker image rm $(docker image ls -f dangling=true -q)

Võime kasutada ka alamkäsku 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

Kui soovime ühe käsuga eemaldada üldse kõik image'id (mitte ainult dangling image'id), siis saab seda teha nii:

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

Kettaruumi kasutamine volume'ite poolt

Volume'e kasutatakse andmete salvestamiseks väljaspool konteineri failisüsteemi. Näiteks siis, kui soovime mõne rakenduse töö tulemused alles hoida, et neid hiljem muul viisil kasutada. Tüüpiline näide on andmebaasid.

Käivitame MongoDB konteineri, mount'ime sellele konteinerivälise volume'i ja taastame sellest andmebaasi varukoopia (meil on see saadaval failis 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

Andmed asuvad hostmasinas kataloogis /var/lib/docker/volumes. Aga miks mitte konteineri lugemis-kirjutamiskihi tasemel? Sest MongoDB image'i Dockerfile'is on kataloog /data/db (kus MongoDB vaikimisi oma andmeid hoiab) määratletud volume'ina.

Märkus: paljud image'id, mille töö tulemusena andmeid luuakse, kasutavad nende andmete säilitamiseks volume'e.

Kui oleme MongoDB-ga lõpetanud ning peatame (või isegi eemaldame) konteineri, siis volume'it ei kustutata. See jätkab meie väärtusliku kettaruumi hõivamist seni, kuni eemaldame selle käsitsi järgmise käsuga:

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

Või saame kasutada juba tuttavat alamkäsku prune:

$ docker volume prune
WARNING! See eemaldab kõik kohalikud köited, mida ei kasuta vähemalt üks konteiner.
Kas soovite kindlasti jätkata? [y/N] y
Deleted Volumes:
d50b6402eb75d09ec17a5f57df4ed7b520c448429f70725fc5707334e5ded4d5
8f7a16e1cf117cdfddb6a38d1f4f02b18d21a485b49037e2670753fa34d115fc
599c3dd48d529b2e105eec38537cd16dac1ae6f899a123e2a62ffac6168b2f5f
...
732e610e435c24f6acae827cd340a60ce4132387cfc512452994bc0728dd66df
9a3f39cc8bd0f9ce54dea3421193f752bda4b8846841b6d36f8ee24358a85bae
045a9b534259ec6c0318cb162b7b4fca75b553d4e86fc93faafd0e7c77c79799
c6283fe9f8d2ca105d30ecaad31868410e809aba0909b3e60d68a26e92a094da

Total reclaimed space: 25.82GB
luc@saturn:~$

Kettakasutus image'i build-cache'i jaoks

Docker 18.09-s tehti image'ite loomise protsessis mõningaid muudatusi tänu BuildKitile. Selle tööriista abil suureneb koostamise kiirus ning paraneb andmesalvestuse ja turvalisuse haldus. Siin ei käsitle me selle suurepärase tööriista kõiki üksikasju, vaid vaatame ainult seda, kuidas see mõjutab kettaruumi kasutust.

Oletame, et meil on täiesti lihtne Node.Js-i rakendus:

• Fail index.js käivitab lihtsa HTTP serveri, mis vastab igale saabunud päringule tekstireaga:
• Fail package.json määrab sõltuvused, millest HTTP serveri käivitamiseks kasutatakse ainult expressjs-i:

$ 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 image'i koostamiseks näeb välja selline:

FROM node:13-alpine
COPY package.json /app/package.json
RUN cd /app && npm install
COPY . /app/
WORKDIR /app
EXPOSE 80
CMD ["npm", "start"]

Koostame image'i tavalisel viisil, ilma BuildKiti kasutamata:

$ docker build -t app:1.0 .

Kui kontrollime kettaruumi kasutust, näeme, et ruumi võtavad ainult baasimage (node:13-alpine) ja lõppimage (app: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

Koostame nüüd meie rakenduse teise versiooni, kasutades juba BuildKiti. Selleks tuleb vaid määrata muutuja DOCKER_BUILDKIT väärtuseks 1:

$ DOCKER_BUILDKIT=1 docker build -t app:2.0 .

Kui kontrollime nüüd kettakasutust, näeme, et nüüd osaleb selles ka build-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

Selle puhastamiseks kasutame järgmist käsku:

$ 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

Puhasta kõik!

Vaatasime nüüd, kuidas puhastada konteinerite, image'ite ja volume'ite kasutatavat kettaruumi. Selleks aitab subkäsk prune. Kuid seda saab kasutada ka Dockeri süsteemitasemel ning siis puhastab see kõik, mida vähegi saab:

$ 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]

Kui säästate mingil põhjusel Dockeriga masinas kettaruumi, tasub selle käsu perioodiline käivitamine harjumuseks muuta.

Allikas: habr.com