Haai Habr! Ek bied die vertaling van die artikel aan u aandag die skrywer .
Vandag sal ons praat oor hoe Docker die skyfspasie van die gasheermasjien gebruik, en ons sal ook uitvind hoe om hierdie spasie te bevry van die stukkies ongebruikte beelde en houers.
Totale verbruik
Docker is 'n gawe ding, waarskynlik twyfel min mense vandag daaraan. Net 'n paar jaar gelede het hierdie produk ons 'n heeltemal nuwe manier gegee om enige omgewing te bou, te lewer en te bestuur, wat ons in staat gestel het om SVE- en RAM-hulpbronne aansienlik te bespaar. Benewens hierdie (en vir sommige sal dit die belangrikste ding wees) het Docker ons toegelaat om die lewensiklusbestuur van ons produksie-omgewings ongelooflik te vereenvoudig en te verenig.
Al hierdie lekkernye van die moderne lewe het egter 'n prys. Wanneer ons houers bestuur, ons eie beelde aflaai of skep, en komplekse ekosisteme ontplooi, moet ons betaal. En ons betaal onder meer met skyfspasie.
As jy nog nooit gedink het oor hoeveel spasie Docker werklik op jou masjien in beslag neem nie, sal jy dalk onaangenaam verras word deur die uitvoer van hierdie opdrag:
$ docker system df
Dit wys Docker se skyfgebruik in verskillende kontekste:
- beelde – die totale grootte van beelde wat van beeldbewaarplekke afgelaai is en op jou stelsel gebou is;
- houers – die totale hoeveelheid skyfspasie wat gebruik word deur lopende houers (wat beteken die totale volume lees-skryflae van alle houers);
- plaaslike volumes – die volume van plaaslike berging wat op houers gemonteer is;
- bou kas – tydelike lêers wat deur die beeldbouproses gegenereer word (met die BuildKit-nutsding, beskikbaar vanaf Docker-weergawe 18.09).
Ek wed dat jy na hierdie eenvoudige oordrag gretig is om jou skyf van vullis skoon te maak en kosbare gigagrepe weer lewendig te maak (let wel: veral as jy elke maand huur vir hierdie gigagrepe betaal).
Skyfgebruik deur houers
Elke keer as jy 'n houer op die gasheermasjien skep, word verskeie lêers en gidse in die /var/lib/docker-gids geskep, waaronder die volgende opmerklik is:
- Gids /var/lib/docker/containers/container_ID – wanneer die standaard aantekenbestuurder gebruik word, is dit waar gebeurtenislogboeke in JSON-formaat gestoor word. Te gedetailleerde logs, sowel as logs wat niemand lees of andersins verwerk nie, veroorsaak dikwels dat skywe vol raak.
- Die /var/lib/docker/overlay2 gids bevat die houer lees-skryf lae (overlay2 is die voorkeurbestuurder in die meeste Linux-verspreidings). As die houer data in sy lêerstelsel stoor, dan is dit in hierdie gids wat dit geplaas sal word.
Kom ons stel ons 'n stelsel voor waarop 'n ongerepte Docker geïnstalleer is, wat nog nooit betrokke was by die bekendstelling van houers of die bou van beelde nie. Sy skyfspasiegebruikverslag sal soos volg lyk:
$ 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 0BKom ons begin 'n houer, byvoorbeeld NGINX:
$ docker container run --name www -d -p 8000:80 nginx:1.16Wat gebeur met die skyf:
- beelde beslaan 126 MB, dit is dieselfde NGINX wat ons in die houer bekendgestel het;
- houers neem 'n belaglike 2 grepe op.
$ 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 0BTe oordeel aan die gevolgtrekking het ons nog geen spasie wat ons kan vrymaak nie. Aangesien 2 grepe heeltemal ligsinnig is, laat ons ons voorstel dat ons NGINX onverwags iewers 100 Megagrepe data geskryf het en 'n lêer test.img van presies hierdie grootte in homself geskep het.
$ docker exec -ti www
dd if=/dev/zero of=test.img bs=1024 count=0 seek=$[1024*100]Kom ons ondersoek weer die gebruik van skyfspasie op die gasheer. Ons sal sien dat die houer (houers) 100 Megagrepe daar beslaan.
$ 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 0BEk dink jou nuuskierige brein wonder al waar ons test.img-lêer geleë is. Kom ons soek dit:
$ 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.imgSonder om in besonderhede in te gaan, kan ons daarop let dat die test.img-lêer gerieflik geleë is op die lees-skryf-vlak, beheer deur die overlay2-bestuurder. As ons ons houer stop, sal die gasheer vir ons sê dat hierdie spasie in beginsel vrygestel kan word:
# 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 kan ons dit doen? Deur die houer uit te vee, wat sal behels dat die ooreenstemmende spasie op die lees-skryfvlak skoongemaak word.
Met die volgende opdrag kan jy alle geïnstalleerde houers in een klap verwyder en jou skyf uitvee van alle lees-skryf-lêers wat deur hulle geskep is:
$ 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.9MBDus, ons het 104,9 megagrepe vrygemaak deur die houer uit te vee. Maar aangesien ons nie meer die voorheen afgelaaide prent gebruik nie, word dit ook 'n kandidaat om ons hulpbronne uit te vee en vry te maak:
$ 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 0BLet wel: Solank die prent deur ten minste een houer gebruik word, sal jy nie hierdie truuk kan gebruik nie.
Die snoei-subopdrag wat ons hierbo gebruik het, het slegs 'n effek op gestopte houers. As ons nie net gestopte, maar ook lopende houers wil uitvee, moet ons een van hierdie opdragte gebruik:
# Historical command
$ docker rm -f $(docker ps –aq)
# More recent command
$ docker container rm -f $(docker container ls -aq)Kantaantekeninge: as jy die -rm-parameter gebruik wanneer jy 'n houer begin, en wanneer dit stop, sal al die skyfspasie wat dit beset bevry word.
Gebruik skyfbeelde
'n Paar jaar gelede was 'n beeldgrootte van etlike honderde megagrepe heeltemal normaal: 'n Ubuntu-prent het 600 megagrepe geweeg, en 'n Microsoft .Net-beeld het etlike gigagrepe geweeg. In daardie ruige dae kan die aflaai van net een prent 'n groot tol op jou vrye skyfspasie eis, selfs al het jy vlakke tussen beelde gedeel. Vandag – lof aan die grootmense – weeg beelde baie minder, maar desondanks kan jy vinnig die beskikbare hulpbronne vul as jy nie sekere voorsorgmaatreëls tref nie.
Daar is verskeie tipes beelde wat nie direk vir die eindgebruiker sigbaar is nie:
- intermediêre beelde, op grond waarvan ander beelde versamel word - hulle kan nie uitgevee word as jy houers gebruik wat op hierdie "ander" beelde gebaseer is nie;
- hangende beelde is tussenbeelde wat nie deur enige van die lopende houers verwys word nie - hulle kan uitgevee word.
- Met die volgende opdrag kan jy kyk vir hangende beelde op jou stelsel:
$ docker image ls -f dangling=true
REPOSITORY TAG IMAGE ID CREATED SIZE
none none 21e658fe5351 12 minutes ago 71.3MBU kan hulle op die volgende manier verwyder:
$ docker image rm $(docker image ls -f dangling=true -q)Ons kan ook die snoei-subopdrag gebruik:
$ 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 ons skielik alle beelde heeltemal wil uitvee (en nie net hangende nie) met een opdrag, dan kan ons dit doen:
$ docker image rm $(docker image ls -q)Skyfgebruik volgens volumes
Volumes word gebruik om data buite die houer se lêerstelsel te stoor. Byvoorbeeld, as ons die resultate van 'n toepassing wil stoor om dit op 'n ander manier te gebruik. 'n Algemene voorbeeld is databasisse.
Kom ons begin 'n MongoDB-houer, monteer 'n volume buite die houer, en herstel 'n databasisrugsteun daaruit (ons het dit beskikbaar in die bck.json-lêer):
# 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
--jsonArrayDie data sal op die gasheermasjien in die /var/lib/docker/volumes-gids geleë wees. Maar hoekom nie op die lees-skryfvlak van die houer nie? Want in die Dockerfile van die MongoDB-beeld word die /data/db-gids (waar MongoDB sy data by verstek stoor) as 'n volume gedefinieer.
Kantnota: baie beelde wat data moet produseer, gebruik volumes om daardie data te stoor.
Wanneer ons genoeg met MongoDB speel en die houer stop (of dalk selfs uitvee), sal die volume nie uitgevee word nie. Dit sal aanhou om ons kosbare skyfspasie op te neem totdat ons dit uitdruklik uitvee met 'n opdrag soos hierdie:
$ docker volume rm $(docker volume ls -q)Wel, of ons kan die snoei-subopdrag gebruik wat reeds aan ons 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:~$Gebruik skyf vir beeldboukas
In Docker 18.09 het die beeldskeppingsproses 'n paar veranderinge ondergaan danksy die BuildKit-nutsding. Hierdie ding verhoog die spoed van die proses en optimaliseer databerging en sekuriteitsbestuur. Hier sal ons nie al die besonderhede van hierdie wonderlike hulpmiddel oorweeg nie; ons sal slegs fokus op hoe dit kwessies van skyfspasiegebruik aanspreek.
Kom ons sê ons het 'n heeltemal eenvoudige Node.Js-toepassing:
- die index.js-lêer begin 'n eenvoudige HTTP-bediener wat met 'n reël reageer op elke versoek wat ontvang word:
- die package.json-lêer definieer die afhanklikhede, waarvan slegs expressjs gebruik word om die HTTP-bediener te laat loop:
$ 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"
}
}Die Dockerfile vir die bou van die beeld lyk soos volg:
FROM node:13-alpine
COPY package.json /app/package.json
RUN cd /app && npm install
COPY . /app/
WORKDIR /app
EXPOSE 80
CMD ["npm", "start"]Kom ons bou die prent op die gewone manier, sonder om BuildKit te gebruik:
$ docker build -t app:1.0 .As ons die gebruik van skyfspasie nagaan, kan ons sien dat slegs die basisbeeld (node:13-alpiene) en die teikenbeeld (app:1.0) spasie opneem:
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 0BKom ons bou die tweede weergawe van ons toepassing met BuildKit. Om dit te doen, moet ons net die DOCKER_BUILDKIT veranderlike op 1 stel:
$ DOCKER_BUILDKIT=1 docker build -t app:2.0 .As ons nou die skyfgebruik nagaan, sal ons sien dat die boukas (buid-cache) nou daar betrokke 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 dit skoon te maak, gebruik die volgende opdrag:
$ 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.949kBVee alles uit!
Dus, ons het gekyk na die skoonmaak van skyfspasie wat deur houers, beelde en volumes beset word. Die snoei-subopdrag help ons hiermee. Maar dit kan ook op die dokstelselvlak gebruik word, en dit sal alles skoonmaak wat dit kan:
$ 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 jy om een of ander rede skyfspasie op jou Docker-masjien spaar, moet dit 'n gewoonte word om hierdie opdrag gereeld uit te voer.
Bron: will.com