🥇Docker Tips: Puhastage oma masin prügist

Tere, Habr! Esitan teile artikli tõlke "Dockeri nipet: Puhastage oma kohalik masin" autori Luc Juggery.

Täna räägime sellest, kuidas Docker kasutab hostmasina kettaruumi ning uurime, kuidas vabastada seda ruumi mittevajalikest piltidest ja konteineritest.

Kogutarbimine

Docker on äge asi, kahtlemata pole tänapäeval keegi selles kahtlemas. Veel paar aastat tagasi pakkus see toode meile täiesti uue viisi iga keskkonna loomisel, tarnimisel ja käitamisel, võimaldades oluliselt säästa protsessori ja mälu ressursse. Lisaks sellele (ja mõne jaoks on see isegi kõige tähtsam) aitas Docker meil uskumatult lihtsustada ja ühtlustada kasutatavate töökeskkondade elutsükli haldamist.

Kuid kõigi nende kaasaegsete mugavuste eest tuleb maksta. Kui käitameme konteinerit, allalaadime või loome oma pilte, juurutame keerulisi ökosüsteeme, peame maksma. Ja maksame sealhulgas ketta ruumiga.

Kui te pole kunagi mõelnud, kui palju ruumi teie Docker masinas tegelikult ära võtab, võite selle käsu väljundi tõttu ebameeldivalt üllatuda:

$ docker system df

Siin on näidatud Docker’i diskikasutust erinevates aspektides:

pildid (images) – allalaaditud ja teie süsteemis loodud piltide kogumahu suurus;
konteinerid (containers) – jooksvaid konteinerite kasutatav üldine kettaruumi maht (silmas peetakse kõigi konteinerite kirjutamis- ja lugemistasemete kogumahtu);
kohalikud mahud (local volumes) – kohalikud salvestusruumid, mis on konteineritega ühendatud;
ehituse vahemälu (build cache) – ajutised failid, mis on loodud piltide ehitamise protsessi käigus (kasutades BuildKit tööriista, mis on saadaval alates Docker versioonist 18.09).

Võin kihla vedada, et juba pärast seda lihtsat loetelu tunnete suure soovi puhastada oma ketast prahist ja vabastada kallihinnalised gigabaidid (välja arvatud, kui maksate nende gigabaitide eest igakuiselt rendimaksu).

Konteinerite diskikasutus

Iga kord, kui konteiner luuakse hostimasinas, luuakse kataloogis /var/lib/docker mitu faili ja katalooge, mille hulgas tasub välja tuua järgmised:

Kataloog /var/lib/docker/containers/ID_konteineri – standardse logimisjuhendi kasutamisel salvestatakse just siia sündmuste logid JSON-formaadis. Liigne üksikasjalikkus logides ning logid, mida keegi ei loe ega muul moel töötle, põhjustavad sageli kõvakettaruumi ületäitumise.
Kataloog /var/lib/docker/overlay2 – sisaldab konteinerite kirjutamis- ja lugemiskihti (overlay2 – eelistatud draiver enamikus Linuxi jaotustes). Kui konteiner salvestab andmeid oma failisüsteemi, siis just selles kataloogis need asuvad.

Kujutame ette süsteemi, kuhu on installitud puhas Docker, mis ei ole kunagi osalenud konteinerite käitamise ega imagede koostamises. Tema kettakasutuse raport näeb välja järgmine:

$ 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 konteineri, näiteks NGINX:

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

Mis juhtub diskiga:

pildid (images) võtavad 126 MB, see on see NGINX, mille me konteineris käivitasime;
konteinerid (containers) võtavad naljakad 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

Vaatamata väljundile ei ole meil veel ruumi, mida võiksime vabastada. Kuna 2 baiti on täiesti naljakas, kujutame ette, et meie NGINX kirjutas ootamatult kuhugi 100 Megabaidi andmeid ja lõi endasse faili test.img just sellise suurusega.

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

Uurime taas diskiruumi kasutust hostis. Näeme, et konteiner (containers) võtab seal 100 Megabaidi.

$ 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 uudishimu juba küsib, kus meie fail test.img asub. Otsime seda:

$ 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

Ilma, et fail test.img on mugavalt paigutatud lugemise-kirjutamise tasemele, mida haldab overlay2 juht. Kui me peatame meie konteineri, siis host näitab meile, et see koht on põhimõtteliselt vabastatav:

# 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 me saame seda teha? Kustutades konteineri, mis toob endaga kaasa vastava ruumi puhastamise lugemise-kirjutamise tasemel.

Järgmise käsu abil saate üheskoos eemaldada kõik installitud konteinerid ja puhastada oma ketta kõigist neile sisse loodud lugemise-kirjutamise failidest:

$ docker container prune
WARNING! See eemaldab kõik peatatud konteinerid.
Kas olete kindel, et soovite jätkata? [y/N] y
Kustutatud konteinerid:
5e7f8e5097ace9ef5518ebf0c6fc2062ff024efb495f11ccc89df21ec9b4dcc2

Kokku vabastatud ruum: 104.9MB

Nii et me vabastasime 104,9 megabaiti konteineri eemaldamisega. Kuid kuna me enam ei kasuta varem allalaaditud pilti, muutub see samuti meie ressursside vabastamise kandidaadiks:

$ docker system df
TÜÜP           KOKKU      AKTIIVNE   SUURUS     TAASKONDITSIONITAV
Pildid        1          0          126M       126M (100%)
Konteinerid   0          0          0B         0B
Kohalikud mahtud 0          0          0B         0B
Kogumise vahemälu 0          0          0B         0B

Tähtis: seni, kuni pilt on vähemalt ühe konteineri poolt kasutusel, ei saa te seda nippi kasutada.

Alamkäsk prune, mida me eespool kasutasime, kehtib ainult peatatud konteinerite kohta. Kui soovime eemaldada mitte ainult peatatud, vaid ka töötavaid konteinerite, tuleks kasutada ühte järgmistest käskudest:

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

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

Märkused: kui konteineri käitamisel kasutada parameetrit —rm, siis selle peatamisel vabastatakse kogu ruum, mida see kasutas.

Piltide poolt kasutatav diskiruumi

Mõned aastad tagasi oli mitme sajandi megabaiti suurune pilt täiesti normaalne: Ubuntu pilt kaalub 600 megabaiti ja Microsoft .Net pilt mitu gigabaiti. Tol ajal võis ühe pildi allalaadimine teie vabale kettaruumi korralikult haiget teha, isegi kui jagasite pilte vastavalt nende vahel. Täna – tänu suurele – on pildid palju väiksemad, kuid isegi siis võite kiiresti oma ressursid täis saada, kui te ei võta ette teatud ettevaatusabinõusid.

On mitu pilditüüpi, mis pole lõppkasutajale vahetult nähtavad:

intermediate pildid, mille põhjal on kokku pandud teised pildid – neid ei saa eemaldada, kui kasutate konteynereid, mis põhinevad just nende "teiste" piltide peal;
dangling pildid – need on intermediate pildid, millele ei viita ükski käimasolev konteiner – need võivad olla eemaldatud.
Järgmise käsuga saate kontrollida, kas teie süsteemis on dangling pilte:

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

Nende eemaldamine on võimalik järgmise käsu abil:

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

Me saame kasutada ka käsku prune:

$ docker image prune
WARNING! See kustutab kõik nö. rippuvad pildid.
Kas olete kindel, et soovite jätkata? [y/N] y
Kustutatud pildid:
kustutatud: sha256:143407a3cb7efa6e95761b8cd6cea25e3f41455be6d5e7cda
kustutatud: sha256:738010bda9dd34896bac9bbc77b2d60addd7738ad1a95e5cc
kustutatud: sha256:fa4f0194a1eb829523ecf3bad04b4a7bdce089c8361e2c347
kustutatud: sha256:c5041938bcb46f78bf2f2a7f0a0df0eea74c4555097cc9197
kustutatud: sha256:5945bb6e12888cf320828e0fd00728947104da82e3eb4452f

Kokku taastatud ruum: 12.9kB

Kui me tahame kustutada kõik pildid (mitte ainult rippuvad) ühe käsuga, siis saab seda teha nii:

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

Ketta kasutamine mahudena

Mahud (volumes) kasutatakse andmete salvestamiseks konteineri failisüsteemist väljaspool. Näiteks, kui me soovime salvestada mingi rakenduse töö tulemusi, et neid hiljem kasutada. Sage näide on andmebaasid.

Käivitame MongoDB konteineri, mountime sellele välise mahu 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. Kuid miks mitte konteineri lugemise-kirjutamise tasemel? Sest MongoDB Dockerfile'i pildis on kataloog /data/db (kus MongoDB vaikimisi oma andmeid säilitab) määratletud kui maht (volume).

Märgistusmärkmed: paljud pildid, mille põhjal peaksid andmed tekkima, kasutavad nende andmete salvestamiseks mahuteid (volumes).

Kui oleme MongoDB-ga mänginud ja konteineri peatame (võib-olla isegi kustutame), ei kustutata mahutit. See jätkab meie väärtusliku kettaruumi hõivamist, kuni me selle selgesõnaliselt kustutame järgmise käsuga:

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

Või võime kasutada juba tuttavat alakommandot prune:

$ docker volume prune
WARNING! See eemaldab kõik kohalikud mahutid, mida ei kasutada vähemalt ühe konteineri poolt.
Kas olete kindel, et soovite jätkata? [y/N] y
Kustutatud mahutid:
d50b6402eb75d09ec17a5f57df4ed7b520c448429f70725fc5707334e5ded4d5
8f7a16e1cf117cdfddb6a38d1f4f02b18d21a485b49037e2670753fa34d115fc
599c3dd48d529b2e105eec38537cd16dac1ae6f899a123e2a62ffac6168b2f5f
...
732e610e435c24f6acae827cd340a60ce4132387cfc512452994bc0728dd66df
9a3f39cc8bd0f9ce54dea3421193f752bda4b8846841b6d36f8ee24358a85bae
045a9b534259ec6c0318cb162b7b4fca75b553d4e86fc93faafd0e7c77c79799
c6283fe9f8d2ca105d30ecaad31868410e809aba0909b3e60d68a26e92a094da

Kokku vabastatud ruum: 25.82GB
luc@saturn:~$

Ketta kasutamine piltide kogumise vahemälu jaoks

Docker 18.09-s on piltide loomise protsessis toimusid mõned muutused BuildKit tööriista tõttu. Selle abil suurendatakse protsessi kiirus, optimeeritakse andmete salvestamise ja turvamise haldamist. Siin me ei käsitle kõiki selle suurepärase tööriista üksikasju, vaid keskendume sellele, kuidas see puutub kokku kettaruumi kasutamise probleemidega.

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

fail index.js käivitab lihtsa HTTP serveri, mis vastab igale saadud päringule reaga:
fail package.json määratleb sõltuvused, millest kasutatakse ainult expressjs HTTP serveri käivitamiseks:

$ 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 pildi koostamiseks näeb välja järgmine:

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

Kogume pildi tavalisel viisil, ilma BuildKit'i kasutamata:

$ docker build -t app:1.0 .

Kui vaatame kettaruumi kasutust, näeme, et ruumi võtavad ainult põhikujutis (node:13-alpine) ja lõppkujutis (app:1.0):

TÜÜP          KOKKU      AKTIIVNE  SUURUS      TAASTATAV
Pildid        2           0         109.3MB    109.3MB (100%)
Konteinerid   0           0         0B         0B
Kohalikud mahud 0        0         0B         0B
Build Cache    0          0         0B         0B

Kogume nüüd meie rakenduse teise versiooni, kasutades juba BuildKit'i. Selleks peame vaid seadma muutuja DOCKER_BUILDKIT väärtuseks 1:

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

Kui me nüüd kettaruumi kontrollime, näeme, et seal osaleb nüüd build cache (buid-cache):

$ docker system df
TÜÜP          KOKKU      AKTIIVNE  SUURUS      TAASTATAV
Pildid        2           0         109.3MB    109.3MB (100%)
Konteinerid   0           0         0B         0B
Kohalikud mahud 0        0         0B         0B
Build Cache    11         0         8.949kB    8.949kB

Käesoleva puhastamiseks kasutame järgmist käsku:

$ docker builder prune
HOIATUS! See eemaldab kõik rippuvad build cache'i objektid.
Kas soovite tegelikult jätkata? [y/N] y
Eemaldatud build cache'i objektid:
rffq7b06h9t09xe584rn4f91e
ztexgsz949ci8mx8p5tzgdzhe
3z9jeoqbbmj3eftltawvkiayi

Kokku taastatud ruum: 8.949kB

Puhastage kõik!

Nii, oleme käsitlenud konteinerite, piltide ja mahtude poolt kasutatud kettaruumi puhastamist. Sellega aitab meid prune alammeeskond. Kuid seda saab kasutada ka Docker'i süsteemitasandil, ja see puhastab kõik, mis võimalik:

$ docker system prune
HOIATUS! See eemaldab:
  - kõik peatatud konteinerid
  - kõik võrgud, mida ei kasutata vähemalt ühe konteineri poolt
  - kõik rippuvad pildid
  - kõik rippuvad koostamisvahemälud

Kas olete kindel, et soovite jätkata? [y/N]

Kui te mingil põhjusel säästate kettaruumi Docker'i masinas, siis tasub harjumuseks võtta selle käsu perioodiline käivitamine.

Allikas: habr.com