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

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

Tere Habr! Esitan teie tähelepanu artikli tõlkele "Dokkeri näpunäited: puhastage oma kohalik masin" autor Luc Juggery.

Täna räägime sellest, kuidas Docker hostmasina kettaruumi kasutab, ja mõtleme ka välja, kuidas seda ruumi kasutamata piltide ja konteinerite jääkidest vabastada.


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

Kogutarbimine

Docker on lahe asi, selles kahtlevad täna ilmselt vähesed. Vaid paar aastat tagasi andis see toode meile täiesti uue võimaluse mis tahes keskkonna loomiseks, tarnimiseks ja käitamiseks, võimaldades meil oluliselt säästa protsessori- ja RAM-i ressursse. Lisaks sellele (ja mõne jaoks on see kõige olulisem) on Docker võimaldanud meil tohutult lihtsustada ja ühtlustada meie tootmiskeskkondade elutsükli juhtimist.

Kõigil neil kaasaegse elu naudingutel on aga oma hind. Kui käitame konteinereid, laadime alla või loome oma pilte ja juurutame keerulisi ökosüsteeme, peame maksma. Ja maksame muuhulgas kettaruumiga.

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

$ docker system df

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

See näitab Dockeri kettakasutust erinevates kontekstides:

  • pildid – pildihoidlatest alla laaditud ja teie süsteemi ehitatud piltide kogumaht;
  • konteinerid – töötavate konteinerite poolt kasutatud kettaruumi kogumaht (see tähendab kõigi konteinerite lugemis-kirjutamiskihtide kogumahtu);
  • lokaalsed mahud – konteineritele monteeritud lokaalse lao maht;
  • build vahemälu – pildi loomise protsessiga genereeritud ajutised failid (kasutades BuildKiti tööriista, saadaval alates Dockeri versioonist 18.09).

Vean kihla, et pärast seda lihtsat ülekandmist soovite oma ketast prügist puhastada ja väärtuslikke gigabaite uuesti ellu äratada (märkus: eriti kui maksate nende gigabaidide eest iga kuu renti).

Kettakasutus konteinerite kaupa

Iga kord, kui loote hostmasinas konteineri, luuakse kataloogis /var/lib/docker mitu faili ja kataloogi, mille hulgas tasub märkida järgmist:

  • Kataloog /var/lib/docker/containers/container_ID – standardse logidraiveri kasutamisel salvestatakse siia sündmuste logid JSON-vormingus. Liiga üksikasjalikud logid, aga ka logid, mida keegi ei loe või muul viisil ei töötle, põhjustavad sageli ketaste täitumist.
  • Kataloog /var/lib/docker/overlay2 sisaldab konteineri lugemis-kirjutamise kihte (overlay2 on enamikus Linuxi distributsioonides eelistatud draiver). Kui konteiner salvestab andmed oma failisüsteemi, siis paigutatakse need sellesse kataloogi.

Kujutagem ette süsteemi, millele on paigaldatud puutumatu Docker, mis pole kunagi konteinerite käivitamise ega kujutiste ehitamisega seotud olnud. Selle kettaruumi kasutamise aruanne 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 mõne konteineri, näiteks NGINX:

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

Mis juhtub kettaga:

  • pildid hõivavad 126 MB, see on sama NGINX, mille me konteineris käivitasime;
  • konteinerid 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

Järelduste põhjal otsustades ei ole meil veel ruumi, mida saaksime vabastada. Kuna 2 baiti on täiesti kergemeelne, siis kujutame ette, et meie NGINX kirjutas 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 hosti kettaruumi kasutamist. Näeme, et konteiner (konteinerid) võtab seal 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

Ma arvan, et teie uudishimulik aju mõtleb juba, kus meie test.img fail 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

Detailidesse laskumata võime märkida, et fail test.img asub mugavalt lugemise-kirjutamise tasemel, mida juhib overlay2 draiver. Kui me oma konteineri peatame, ütleb host meile, 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 me saame seda teha? Konteineri kustutamisega, mis tähendab vastava ruumi tühjendamist lugemise ja kirjutamise tasemel.

Järgmise käsuga saate eemaldada kõik installitud konteinerid ühe hoobiga ja tühjendada ketta kõigist nende loodud lugemis- ja kirjutamisfailidest:

$ 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

Seega vabastasime konteineri kustutamisega 104,9 megabaiti. Kuid kuna me ei kasuta enam varem allalaaditud pilti, saab sellest ka kandidaat meie ressursside kustutamiseks ja vabastamiseks:

$ 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

Märkus. Kuni pilti kasutab vähemalt üks konteiner, ei saa te seda nippi kasutada.

Eespool kasutatud pügamise alamkäsk mõjutab ainult peatatud konteinereid. Kui tahame kustutada mitte ainult peatunud, vaid ka töötavaid konteinereid, peaksime kasutama ühte järgmistest käskudest:

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

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

Kõrvalmärkused: kui kasutate konteineri käivitamisel parameetrit -rm, vabastatakse selle peatumisel kogu selle hõivatud kettaruum.

Kettapiltide kasutamine

Mõne aasta eest oli mitmesaja megabaidine pildi suurus täiesti tavaline: Ubuntu pilt kaalus 600 megabaiti ja Microsoft .Neti pilt mitu gigabaiti. Neil segastel päevadel võib ainult ühe pildi allalaadimine teie vabale kettaruumile palju kahju võtta, isegi kui jagate piltide vahel taset. Tänapäeval – kiitus suurtele – kaaluvad pildid palju vähem, kuid isegi sel juhul saate olemasolevaid ressursse kiiresti täita, kui te ettevaatusabinõusid ei võta.

On mitut tüüpi pilte, mida lõppkasutaja ei näe:

  • vahepildid, mille alusel kogutakse teisi pilte - neid ei saa kustutada, kui kasutate nendel “teistel” piltidel põhinevaid konteinereid;
  • rippuvad pildid on vahepealsed pildid, millele ükski töötav konteiner ei viita – neid saab kustutada.
  • Järgmise käsuga saate kontrollida, kas teie süsteemis pole rippuvaid pilte:

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

Saate need eemaldada järgmisel viisil.

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

Võime kasutada ka prune alamkäsku:

$ 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 tahame äkitselt kustutada kõik pildid (ja mitte ainult rippuvad) ühe käsuga, siis saame seda teha:

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

Kettakasutus mahtude järgi

Mahte kasutatakse andmete salvestamiseks väljaspool konteineri failisüsteemi. Näiteks kui soovime mõne rakenduse tulemusi salvestada, et neid muul viisil kasutada. Levinud näide on andmebaasid.

Käivitame MongoDB konteineri, ühendame konteineri välise köite ja taastame sellest andmebaasi varukoopia (see on 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 lugemise-kirjutamise tasemel? Kuna MongoDB kujutise Dockerfile'is on /data/db kataloog (kus MongoDB oma andmed vaikimisi salvestab) määratletud köitena.

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

Kõrvalmärkus: paljud pildid, mis peavad andma andmeid, kasutavad nende andmete salvestamiseks mahtu.

Kui mängime piisavalt MongoDB-ga ja peatame (või võib-olla isegi kustutame) konteineri, siis helitugevust ei kustutata. See võtab meie väärtuslikku kettaruumi seni, kuni me selle selgesõnaliselt kustutame järgmise käsuga:

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

Noh, või saame kasutada meile juba tuttavat prune alamkäsku:

$ 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:~$

Ketta kasutamine pildi koostamise vahemälu jaoks

Dockeri versioonis 18.09 on pildi loomise protsessis tehtud mõned muudatused tänu BuildKiti tööriistale. See asi suurendab protsessi kiirust ja optimeerib andmete salvestamist ja turvahaldust. Siin ei käsitle me selle suurepärase tööriista kõiki üksikasju; keskendume ainult sellele, kuidas see lahendab kettaruumi kasutamise probleeme.

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

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

$ 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"
      }
    }

Pildi koostamise Dockeri fail 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"]

Ehitame pildi tavapärasel viisil, ilma BuildKiti kasutamata:

$ docker build -t app:1.0 .

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

Ehitame BuildKiti abil oma rakenduse teise versiooni. Selleks peame lihtsalt määrama muutuja DOCKER_BUILDKIT väärtuseks 1:

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

Kui me nüüd kettakasutust kontrollime, näeme, et ehituse vahemälu (buid-cache) on nüüd seal kaasatud:

$ 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 kustutamiseks kasutage 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

Kustuta kõik!

Niisiis uurisime konteinerite, piltide ja köidete poolt hõivatud kettaruumi puhastamist. Ploomide alamkäsk aitab meid selles. Kuid seda saab kasutada ka dokkimissüsteemi tasemel ja see puhastab kõik, mis võimalik:

$ 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 Dockerit kasutavas masinas kettaruumi, peaks selle käsu perioodiline käitamine muutuma harjumuseks.

Allikas: www.habr.com

Lisa kommentaar