Hoi Habr! Ik presintearje jo oandacht de oersetting fan it artikel skriuwer .
Hjoed sille wy prate oer hoe't Docker de skiifromte fan 'e hostmasine brûkt, en wy sille ek útfine hoe't jo dizze romte kinne befrije fan 'e kladen fan net brûkte ôfbyldings en konteners.
Totaal konsumpsje
Docker is in cool ding, wierskynlik twifelje in pear minsken hjoed. Krekt in pear jier lyn joech dit produkt ús in folslein nije manier om elke omjouwing te bouwen, te leverjen en út te fieren, wêrtroch't wy CPU- en RAM-boarnen signifikant kinne besparje. Neist dit (en foar guon sil dit it wichtichste ding wêze) hat Docker ús tastien om it libbenssyklusbehear fan ús produksjeomjouwings ongelooflijk ferienfâldigje en te ferienigjen.
Al dizze lekkernijen fan it moderne libben komme lykwols foar in priis. As wy konteners útfiere, ús eigen ôfbyldings downloade of meitsje, en komplekse ekosystemen ynsette, moatte wy betelje. En wy betelje ûnder oare mei skiifromte.
As jo noait tocht hawwe oer hoefolle romte Docker eins op jo masine ynnimt, kinne jo ûnaangenaam ferrast wurde troch de útfier fan dit kommando:
$ docker system df
Dit toant Docker's skiifgebrûk yn ferskate konteksten:
- ôfbyldings - de totale grutte fan ôfbyldings dy't waarden ynladen fan ôfbyldingsrepositories en boud op jo systeem;
- konteners - de totale hoemannichte skiifromte brûkt troch it útfieren fan konteners (dat betsjut it totale folume fan lêzen-skriuwlagen fan alle konteners);
- lokale folumes - it folume fan pleatslike opslach monteard op konteners;
- build cache - tydlike bestannen generearre troch it byldbouproses (mei it BuildKit-ark, beskikber te begjinnen mei Docker ferzje 18.09).
Ik wedde dat jo nei dizze ienfâldige oerdracht entûsjast binne om jo skiif fan jiskefet skjin te meitsjen en kostbere gigabytes wer ta libben te bringen (notysje: foaral as jo elke moanne hier betelje foar dizze gigabytes).
Skiifgebrûk troch konteners
Elke kear as jo in kontener oanmeitsje op 'e hostmasine, wurde ferskate bestannen en mappen oanmakke yn' e /var/lib/docker-map, wêrby't de folgjende opmerklik binne:
- Directory /var/lib/docker/containers/container_ID - by it brûken fan de standert logging-bestjoerder, dit is wêr't barrenslogs wurde bewarre yn JSON-formaat. Te detaillearre logs, lykas logs dy't gjinien lêst of oars ferwurket, feroarsaakje faaks dat skiven fol wurde.
- De map /var/lib/docker/overlay2 befettet de container lês-skriuwlagen (overlay2 is de foarkar stjoerprogramma yn de measte Linux-distribúsjes). As de kontener gegevens yn har bestânsysteem opslacht, dan is it yn dizze map dat it wurdt pleatst.
Litte wy ús in systeem foarstelle wêrop in ûnreplike Docker is ynstalleare, dy't noait belutsen west hat by it lansearjen fan konteners of it bouwen fan ôfbyldings. It rapport oer gebrûk fan skiifromte sil der sa útsjen:
$ 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 0BLitte wy wat kontener lansearje, bygelyks NGINX:
$ docker container run --name www -d -p 8000:80 nginx:1.16Wat bart der mei de skiif:
- ôfbyldings besette 126 MB, dit is deselde NGINX dy't wy yn 'e kontener lansearre hawwe;
- containers nimme up in bespotlik 2 bytes.
$ 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 0BNei de konklúzje te oardieljen hawwe wy noch gjin romte dy't wy frijmeitsje kinne. Sûnt 2 bytes is folslein frivolous, lit ús yntinke dat ús NGINX ûnferwachts skreau earne 100 Megabytes fan gegevens en makke in triem test.img fan krekt dizze grutte yn himsels.
$ docker exec -ti www
dd if=/dev/zero of=test.img bs=1024 count=0 seek=$[1024*100]Litte wy it skiifromtegebrûk op 'e host nochris ûndersykje. Wy sille sjen dat de kontener (containers) dêr 100 Megabytes beslacht.
$ 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 0BIk tink dat jo nijsgjirrige harsens al ôffreegje wêr't ús test.img-bestân leit. Litte wy it sykje:
$ 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.imgSûnder yn details te gean, kinne wy opmerke dat it test.img-bestân handich leit op it lêzen-skriuwnivo, regele troch de overlay2-bestjoerder. As wy ús kontener stopje, sil de host ús fertelle dat dizze romte yn prinsipe frijmakke wurde kin:
# 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 0BHoe kinne wy dit dwaan? Troch it wiskjen fan de kontener, wat sil befetsje it wiskjen fan de oerienkommende romte op it lêzen-skriuwnivo.
Mei it folgjende kommando kinne jo alle ynstalleare konteners yn ien slach fuortsmite en jo skiif wiskje fan alle lês-skriuwbestannen makke troch har:
$ 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.9MBDat, wy hawwe 104,9 Megabytes frijmakke troch de kontener te wiskjen. Mar om't wy de earder downloade ôfbylding net mear brûke, wurdt it ek in kandidaat foar it wiskjen en frijmeitsjen fan ús boarnen:
$ 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 0BOpmerking: salang't de ôfbylding yn gebrûk is troch op syn minst ien kontener, kinne jo dizze trúk net brûke.
It prune-subkommando dat wy hjirboppe brûkten hat allinich effekt op stoppe konteners. As wy net allinich stoppe, mar ek rinnende konteners wolle wiskje, moatte wy ien fan dizze kommando's brûke:
# Historical command
$ docker rm -f $(docker ps –aq)
# More recent command
$ docker container rm -f $(docker container ls -aq)Side-notysjes: as jo de parameter -rm brûke by it starten fan in kontener, as it stopt, sil alle skiifromte dy't it besette wurdt befrijd.
Skiifôfbyldings brûke
In pear jier lyn wie in ôfbyldingsgrutte fan ferskate hûnderten megabytes folslein normaal: in Ubuntu-ôfbylding weage 600 megabytes, en in Microsoft .Net-ôfbylding weage ferskate gigabytes. Yn dy rûge dagen kin it downloaden fan mar ien ôfbylding in grutte tol nimme op jo frije skiifromte, sels as jo nivo's diele tusken ôfbyldings. Hjoed - lof foar de grutte - bylden weagje folle minder, mar sels dan kinne jo de beskikbere boarnen fluch ynfolje as jo gjin foarsoarchsmaatregels nimme.
D'r binne ferskate soarten ôfbyldings dy't net direkt sichtber binne foar de einbrûker:
- tuskenlizzende ôfbyldings, op basis wêrfan oare ôfbyldings wurde sammele - se kinne net wiske wurde as jo konteners brûke basearre op dizze "oare" ôfbyldings;
- Dangling-ôfbyldings binne tuskenbylden dy't net ferwiisd wurde troch ien fan 'e rinnende konteners - se kinne wurde wiske.
- Mei it folgjende kommando kinne jo kontrolearje op hingjende ôfbyldings op jo systeem:
$ docker image ls -f dangling=true
REPOSITORY TAG IMAGE ID CREATED SIZE
none none 21e658fe5351 12 minutes ago 71.3MBJo kinne se op 'e folgjende manier fuortsmite:
$ docker image rm $(docker image ls -f dangling=true -q)Wy kinne ek it subkommando prune brûke:
$ 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.9kBAs wy ynienen alle ôfbyldings hielendal wiskje wolle (en net allinich dangling) mei ien kommando, dan kinne wy dit dwaan:
$ docker image rm $(docker image ls -q)Skiifgebrûk troch folumes
Folumes wurde brûkt om gegevens op te slaan bûten it bestânsysteem fan 'e kontener. As wy bygelyks de resultaten fan in applikaasje wolle bewarje om se op in oare manier te brûken. In mienskiplik foarbyld is databases.
Litte wy in MongoDB-kontener starte, in folume ekstern oan 'e kontener montearje, en in databank-backup derút weromsette (wy hawwe it beskikber yn it bck.json-bestân):
# 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
--jsonArrayDe gegevens sille lizze op 'e hostmasine yn' e map /var/lib/docker/volumes. Mar wêrom net op it lêzen-skriuwnivo fan 'e kontener? Om't yn 'e Dockerfile fan' e MongoDB-ôfbylding, de /data/db-map (wêr't MongoDB syn gegevens standert opslacht) wurdt definiearre as in folume.
Sidenotysje: in protte ôfbyldings dy't gegevens moatte produsearje brûke folumes om dy gegevens op te slaan.
As wy genôch spylje mei MongoDB en stopje (of miskien sels wiskje) de kontener, sil it folume net wiske wurde. It sil trochgean mei it opnimmen fan ús kostbere skiifromte oant wy it eksplisyt wiskje mei in kommando lykas dit:
$ docker volume rm $(docker volume ls -q)No, of wy kinne it prune-subkommando brûke dat ús al bekend is:
$ 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:~$Skiif brûke foar ôfbyldingsbou-cache
Yn Docker 18.09 hat it proses foar it meitsjen fan ôfbyldings wat feroaringen ûndergien troch it BuildKit-ark. Dit ding fergruttet de snelheid fan it proses en optimisearret gegevensopslach en feiligensbehear. Hjir sille wy net alle details fan dit prachtige ark beskôgje; wy sille allinich rjochtsje op hoe't it problemen fan skiifromtegebrûk oanpakt.
Litte wy sizze dat wy in folslein ienfâldige Node.Js-applikaasje hawwe:
- it index.js-bestân begjint in ienfâldige HTTP-tsjinner dy't reagearret mei in rigel op elk ûntfongen fersyk:
- it pakket.json-bestân definiearret de ôfhinklikens, wêrfan allinich expressjs wurdt brûkt om de HTTP-tsjinner út te fieren:
$ 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"
}
}De Dockerfile foar it bouwen fan de ôfbylding sjocht der sa út:
FROM node:13-alpine
COPY package.json /app/package.json
RUN cd /app && npm install
COPY . /app/
WORKDIR /app
EXPOSE 80
CMD ["npm", "start"]Litte wy de ôfbylding op 'e gewoane manier bouwe, sûnder BuildKit te brûken:
$ docker build -t app:1.0 .As wy it gebrûk fan skiifromte kontrolearje, kinne wy sjogge dat allinich de basisôfbylding (knooppunt: 13-alpine) en de bestimmingôfbylding (app: 1.0) romte nimme:
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 0BLitte wy de twadde ferzje fan ús applikaasje bouwe, mei BuildKit. Om dit te dwaan, moatte wy gewoan de DOCKER_BUILDKIT fariabele ynstelle op 1:
$ DOCKER_BUILDKIT=1 docker build -t app:2.0 .As wy no it skiifgebrûk kontrolearje, sille wy sjen dat de build-cache (buid-cache) no belutsen is:
$ 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.949kBOm it te wiskjen, brûk it folgjende kommando:
$ 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.949kBAlles wiskje!
Dat, wy seagen nei it skjinmeitsjen fan skiifromte beset troch konteners, ôfbyldings en folumes. De prune subkommando helpt ús dêrby. Mar it kin ek brûkt wurde op it docker-systeemnivo, en it sil alles skjinmeitsje wat it kin:
$ 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]As jo om ien of oare reden skiifromte besparje op jo Docker-masine, dan moat dit kommando periodyk útfiere in gewoante wurde.
Boarne: www.habr.com