Hey Habr! Ech presentéieren Iech d'Iwwersetzung vum Artikel Auteur .
Haut schwätze mir iwwer wéi Docker den Disk Space vun der Hostmaschinn benotzt, a mir wäerten och erausfannen wéi Dir dëse Raum vun de Schrott vun onbenotzten Biller a Container befreit.
Gesamtverbrauch
Docker ass eng cool Saach, wahrscheinlech wéineg Leit bezweifelen et haut. Virun e puer Joer huet dëst Produkt eis e komplett neie Wee ginn fir all Ëmfeld ze bauen, ze liwweren an ze bedreiwen, wat eis erlaabt CPU an RAM Ressourcen wesentlech ze spueren. Zousätzlech zu dësem (a fir e puer wäert dëst déi wichtegst Saach sinn) Docker huet eis erlaabt d'Liewenszyklusmanagement vun eise Produktiounsëmfeld onheemlech ze vereinfachen an ze vereenegen.
Wéi och ëmmer, all dës Genoss vum modernen Liewen kommen zu engem Präis. Wa mir Container lafen, eroflueden oder eis eege Biller erstellen, a komplex Ökosystemer ofsetzen, musse mir bezuelen. A mir bezuelen ënner anerem mat Disk Space.
Wann Dir nach ni geduecht hutt wéi vill Plaz Docker tatsächlech op Ärer Maschinn ophëlt, kënnt Dir onangenehm iwwerrascht ginn vum Output vun dësem Kommando:
$ docker system df
Dëst weist dem Docker seng Diskverbrauch a verschiddene Kontexter:
- Biller - d'Gesamtgréisst vun de Biller déi aus Bildrepositories erofgeluede goufen an op Ärem System gebaut goufen;
- Behälter - de Gesamtbetrag vun Disk Space benotzt vu Lafen Container (dat heescht de Gesamtvolumen vu Lies-Schreifschichten vun all Container);
- lokal Bänn - de Volume vun der lokaler Lagerung op Container montéiert;
- bauen Cache - temporär Dateien generéiert vum Bildbauprozess (mat dem BuildKit Tool, verfügbar mat Docker Versioun 18.09).
Ech wetten, datt Dir no dësem einfachen Transfert gär hutt Är Disk vun Dreck ze botzen an wäertvoll Gigabyte erëm an d'Liewen ze bréngen (Notiz: besonnesch wann Dir Loyer fir dës Gigabyte all Mount bezuelt).
Disk Notzung vu Container
All Kéier wann Dir e Container op der Hostmaschinn erstellt, ginn verschidde Dateien a Verzeichnisser am /var/lib/docker Verzeichnis erstallt, dorënner déi folgend ze bemierken:
- Verzeechnes /var/lib/docker/containers/container_ID - wann Dir de Standard Log-Treiber benotzt, ass dat wou Event Logbicher am JSON-Format gespäichert ginn. Ze detailléiert Logbicher, souwéi Logbicher déi kee liest oder soss veraarbecht, verursaache dacks Disken voll ze ginn.
- Den /var/lib/docker/overlay2 Verzeechnes enthält de Container Lies-Schreifschichten (overlay2 ass de bevorzugten Treiber an de meeschte Linux Verdeelungen). Wann de Container Daten a sengem Dateiesystem späichert, dann ass et an dësem Verzeichnis datt se plazéiert ginn.
Loosst eis e System virstellen, op deem e ursprénglechen Docker installéiert ass, deen nach ni an der Start vun Container oder Baubilder involvéiert war. Säin Disk Space Notzungsbericht gesäit esou aus:
$ 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 0BLoosst eis e Container starten, zum Beispill NGINX:
$ docker container run --name www -d -p 8000:80 nginx:1.16Wat geschitt mam Disk:
- Biller besetzen 126 MB, dëst ass déiselwecht NGINX déi mir am Container lancéiert hunn;
- Container huelen eng lächerlech 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 0BNo der Konklusioun ze beurteelen, hu mir nach keng Plaz, déi mir kënne fräi maachen. Well 2 Bytes komplett frivol ass, loosst eis virstellen datt eisen NGINX onerwaart iergendwou 100 Megabytes vun Daten geschriwwen huet an e Fichier Test.img vu genee dëser Gréisst bannen selwer erstallt huet.
$ docker exec -ti www
dd if=/dev/zero of=test.img bs=1024 count=0 seek=$[1024*100]Loosst eis d'Disk Space Notzung um Host nach eng Kéier ënnersichen. Mir wäerte gesinn datt de Container (Container) do 100 Megabytes besetzt.
$ 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 0BEch denken, datt Äre virwëtzeg Gehir sech scho freet, wou eis test.img Datei läit. Loosst eis no kucken:
$ 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.imgOuni an Detailer ze goen, kënne mir feststellen datt d'test.img Datei bequem um Lies-Schreifniveau läit, kontrolléiert vum Overlay2 Chauffer. Wa mir eise Container stoppen, wäert de Host eis soen datt dëse Raum am Prinzip fräigelooss ka ginn:
# 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 0BWéi kënne mir dat maachen? Andeems Dir de Container läscht, wat bedeit datt de entspriechende Raum um Lies-Schreifniveau geläscht gëtt.
Mat dem folgenden Kommando kënnt Dir all installéiert Container an engem Schlag erofhuelen an Är Disk vun all Lies-Schreifdateien erstallt vun hinnen läschen:
$ 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.9MBAlso hu mir 104,9 Megabytes befreit andeems de Container geläscht gëtt. Awer well mir dat virdrun erofgeluede Bild net méi benotzen, gëtt et och e Kandidat fir eis Ressourcen ze läschen an ze befreien:
$ 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 0BBemierkung: Soulaang d'Bild vun op d'mannst ee Container benotzt gëtt, kënnt Dir dësen Trick net benotzen.
De Prune-Subkommando, dee mir uewe benotzt hunn, huet nëmmen en Effekt op gestoppte Container. Wa mir wëllen net nëmmen gestoppt awer och Lafen Container läschen, solle mir ee vun dëse Kommandoen benotzen:
# Historical command
$ docker rm -f $(docker ps –aq)
# More recent command
$ docker container rm -f $(docker container ls -aq)Side Notizen: wann Dir de -rm Parameter benotzt wann Dir e Container start, dann wann et stoppt, gëtt all Disk Space besat, deen en besat huet.
Benotzt Disk Biller
Virun e puer Joer war eng Bildgréisst vun e puer honnert Megabytes ganz normal: en Ubuntu-Bild huet 600 Megabyte gewien, an e Microsoft .Net-Bild huet e puer Gigabyte gewien. An deene shaggy Deeg, nëmmen ee Bild eroflueden kéint e groussen Maut op Ärem fräie Disk Space huelen, och wann Dir Niveauen tëscht Biller deelt. Haut - lueft de Groussen - d'Biller weien vill manner, awer trotzdem kënnt Dir séier déi verfügbar Ressourcen ausfëllen, wann Dir keng Virsiichtsmoossname maacht.
Et gi verschidden Aarte vu Biller déi net direkt fir den Endbenotzer sichtbar sinn:
- Zwëschenbilder, op Basis vun deenen aner Biller gesammelt ginn - si kënnen net geläscht ginn wann Dir Container op Basis vun dësen "aner" Biller benotzt;
- dangling Biller sinn Tëschenzäit Biller déi net vun engem vun de lafen Container referenzéiert sinn - si kënne geläscht ginn.
- Mat dem folgenden Kommando kënnt Dir kucken op dangling Biller op Ärem System:
$ docker image ls -f dangling=true
REPOSITORY TAG IMAGE ID CREATED SIZE
none none 21e658fe5351 12 minutes ago 71.3MBDir kënnt se op déi folgend Manéier ewechhuelen:
$ docker image rm $(docker image ls -f dangling=true -q)Mir kënnen och de Prune Ënnerkommando benotzen:
$ 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.9kBWa mir op eemol all Biller ganz läschen wëllen (an net nëmmen dangelen) mat engem Kommando, da kënne mir dëst maachen:
$ docker image rm $(docker image ls -q)Disk Notzung duerch Bänn
Bänn gi benotzt fir Daten ausserhalb vum Dateiesystem vum Container ze späicheren. Zum Beispill, wa mir d'Resultater vun enger Applikatioun wëllen späicheren fir se op eng aner Manéier ze benotzen. E gemeinsamt Beispill ass Datenbanken.
Loosst eis e MongoDB Container starten, e Volume extern zum Container montéieren, a restauréiert eng Datebankbackup dovun (mir hunn et an der bck.json Datei verfügbar):
# 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
--jsonArrayD'Donnéeën wäerten op der Hostmaschinn am /var/lib/docker/volumes Verzeechnes sinn. Awer firwat net um Lies-Schreifniveau vum Container? Well an der Dockerfile vum MongoDB Bild ass den /data/db Verzeichnis (wou MongoDB seng Donnéeën als Standard späichert) als Volume definéiert.
Säit Notiz: vill Biller déi Donnéeën produzéiere musse benotze Volumen fir dës Donnéeën ze späicheren.
Wa mir genuch mat MongoDB spillen a stoppen (oder vläicht souguer läschen) de Container, gëtt de Volume net geläscht. Et wäert weiderhin eise wäertvollen Disk Space ophuelen bis mir et explizit mat engem Kommando wéi dëst läschen:
$ docker volume rm $(docker volume ls -q)Gutt, oder mir kënnen de Prune Ënnerbefehl benotzen deen eis scho vertraut ass:
$ 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:~$Benotzt Disk fir Bild Build Cache
Am Docker 18.09 huet de Bildkreatiounsprozess e puer Ännerunge gemaach dank dem BuildKit Tool. Dës Saach erhéicht d'Geschwindegkeet vum Prozess an optiméiert Datelagerung a Sécherheetsmanagement. Hei wäerte mir net all d'Detailer vun dësem wonnerbare Tool berücksichtegen; mir konzentréieren eis nëmmen op wéi et Themen vun der Disk Space Notzung adresséiert.
Loosst eis soen datt mir eng komplett einfach Node.Js Applikatioun hunn:
- d'index.js Datei start en einfachen HTTP-Server deen mat enger Zeil op all Empfang reagéiert:
- d'package.json Datei definéiert d'Ofhängegkeeten, vun deenen nëmmen expressjs benotzt gëtt fir den HTTP-Server auszeféieren:
$ 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"
}
}D'Dockerfile fir d'Bild ze bauen gesäit esou aus:
FROM node:13-alpine
COPY package.json /app/package.json
RUN cd /app && npm install
COPY . /app/
WORKDIR /app
EXPOSE 80
CMD ["npm", "start"]Loosst eis d'Bild op déi üblech Manéier bauen, ouni BuildKit ze benotzen:
$ docker build -t app:1.0 .Wa mir d'Disk Space Notzung kontrolléieren, kënne mir gesinn datt nëmmen d'Basisbild (Node: 13-alpine) an d'Zielbild (App: 1.0) Plaz ophuelen:
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 0BLoosst eis déi zweet Versioun vun eiser Applikatioun bauen, mat BuildKit. Fir dëst ze maachen, brauche mir just d'DOCKER_BUILDKIT Variabel op 1 ze setzen:
$ DOCKER_BUILDKIT=1 docker build -t app:2.0 .Wa mir elo d'Disknotzung iwwerpréiwen, gesi mir datt de Build Cache (buid-Cache) elo do involvéiert ass:
$ 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.949kBFir et ze läschen, benotzt de folgende 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 läschen!
Also, mir hu gekuckt d'Botzen vun Disk Space besat vu Container, Biller a Bänn. De Prune-Subkommando hëlleft eis domat. Awer et kann och um Docker Systemniveau benotzt ginn, an et wäert alles botzen wat et kann:
$ 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]Wann Dir aus iergendengem Grond Disk Space op Ärer Docker Maschinn spuert, da sollt periodesch dëse Kommando eng Gewunnecht ginn.
Source: will.com