Kaixo, Habr! Artikuluaren itzulpena aurkezten dizuet egilea .
Gaur Docker-ek ostalari-makinaren disko-espazioa nola erabiltzen duen hitz egingo dugu, eta espazio hori erabiltzen ez diren irudi eta edukiontzien hondakinetatik nola askatu ere asmatuko dugu.
Kontsumo osoa
Docker gauza polita da, ziurrenik inork gutxik jartzen du zalantzan gaur egun. Duela urte batzuk, produktu honek edozein ingurune eraiki, entregatu eta exekutatzeko modu guztiz berria eman zigun, CPU eta RAM baliabideak nabarmen aurrezteko aukera emanez. Honetaz gain (eta batzuentzat hori izango da garrantzitsuena) Docker-ek gure ekoizpen-inguruneen bizi-zikloaren kudeaketa izugarri sinplifikatzeko eta bateratzeko aukera eman digu.
Hala ere, bizitza modernoko gozamen horiek guztiak prezioa dute. Ontziak exekutatzen ditugunean, gure irudiak deskargatu edo sortzen ditugunean eta ekosistema konplexuak zabaltzen ditugunean, ordaindu egin behar dugu. Eta, besteak beste, diskoko espazioarekin ordaintzen dugu.
Inoiz pentsatu ez baduzu Docker-ek benetan zenbat espazio hartzen duen zure makinan, baliteke komando honen irteerarekin desatsegina harritzea:
$ docker system df
Honek Docker-en diskoaren erabilera testuinguru ezberdinetan erakusten du:
- irudiak - irudi-biltegietatik deskargatu eta zure sisteman eraikitako irudien tamaina osoa;
- edukiontziak - exekutatzen ari diren edukiontziak erabilitako disko-espazio osoa (edukiontzi guztien irakurketa-idazketa geruzen bolumen osoa alegia);
- tokiko bolumenak - edukiontzietan muntatutako tokiko biltegiratze-bolumena;
- eraiki cachea - irudiak eraikitzeko prozesuak sortutako aldi baterako fitxategiak (BuildKit tresna erabiliz, Docker 18.09 bertsioarekin hasita eskuragarri).
Apustu egiten dut transferentzia sinple honen ondoren zure diskoa zaborrez garbitzeko eta gigabyte preziatuak itzultzeko gogoz zaudela (oharra: batez ere hilero gigabyte horien alokairua ordaintzen baduzu).
Diskoen erabilera edukiontziek
Ostalari makinan edukiontzi bat sortzen duzun bakoitzean, hainbat fitxategi eta direktorio sortzen dira /var/lib/docker direktorioa, eta horien artean aipagarriak dira honako hauek:
- Directory /var/lib/docker/containers/container_ID - erregistro-gidari estandarra erabiltzean, gertaeren erregistroak JSON formatuan gordetzen dira. Erregistro zehatzegiek, baita inork irakurtzen edo bestela prozesatzen ez dituen erregistroek ere, askotan diskoak betetzea eragiten dute.
- /var/lib/docker/overlay2 direktorioak edukiontzien irakurketa-idazketa geruzak ditu (overlay2 da Linux banaketa gehienetan hobetsitako kontrolatzailea). Edukiontziek datuak bere fitxategi-sisteman gordetzen baditu, direktorio horretan kokatuko da.
Imajina dezagun Docker pristine bat instalatuta dagoen sistema bat, inoiz edukiontziak abiaraztean edo irudiak eraikitzen parte hartu ez duena. Bere diskoko espazioaren erabilera-txostenak honela izango du:
$ 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 0BAbiarazi dezagun edukiontziren bat, adibidez, NGINX:
$ docker container run --name www -d -p 8000:80 nginx:1.16Zer gertatzen zaio diskoari:
- irudiek 126 MB hartzen dute, edukiontzian abiarazi genuen NGINX bera da;
- edukiontziek 2 byte barregarriak hartzen dituzte.
$ 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 0BOndorioa ikusita, oraindik ez dugu askatu genezakeen espaziorik. 2 byte guztiz friboloak direnez, pentsa dezagun gure NGINX-ek ustekabean 100 Megabyte datu idatzi zituela nonbait eta bere baitan tamaina horretako test.img fitxategi bat sortu zuela.
$ docker exec -ti www
dd if=/dev/zero of=test.img bs=1024 count=0 seek=$[1024*100]Azter dezagun berriro ostalariaren diskoko espazioaren erabilera. Ikusiko dugu edukiontziak (edukiontziak) 100 Megabyte hartzen dituela bertan.
$ 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 0BUste dut zure burmuin kuriosoak gure test.img fitxategia non dagoen galdetzen ari dela. Bila dezagun:
$ 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.imgXehetasunetan sartu gabe, test.img fitxategia irakurketa-idazketa mailan kokatuta dagoela ohar gaitezke, overlay2 kontrolatzaileak kontrolatuta. Gure edukiontzia gelditzen badugu, ostalariak esango digu espazio hori, printzipioz, askatu daitekeela:
# 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 0BNola egin dezakegu hau? Edukiontzia ezabatuz, irakurketa-idazketa mailan dagokion espazioa garbitzea ekarriko du.
Hurrengo komandoarekin, instalatutako edukiontzi guztiak kolpe bakarrean ken ditzakezu eta diskoa garbitu dezakezu haiek sortutako irakurketa-idazketa fitxategi guztiak:
$ 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.9MBBeraz, 104,9 Megabyte askatu genituen edukiontzia ezabatuz. Baina jada deskargatutako irudia erabiltzen ez dugunez, gure baliabideak ezabatu eta askatzeko hautagai ere bihurtzen da:
$ 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 0BOharra: irudia gutxienez edukiontzi batek erabiltzen badu, ezin izango duzu trikimailu hau erabili.
Goian erabili dugun prune azpikomandoak gelditutako ontzietan bakarrik du eragina. Gelditu diren edukiontziak ez ezik martxan dauden edukiontziak ere ezabatu nahi baditugu, komando hauetako bat erabili beharko genuke:
# Historical command
$ docker rm -f $(docker ps –aq)
# More recent command
$ docker container rm -f $(docker container ls -aq)Alboko oharrak: edukiontzi bat abiaraztean -rm parametroa erabiltzen baduzu, gelditzen denean, okupatzen zuen diskoko espazio guztia askatuko da.
Disko irudiak erabiltzea
Duela urte batzuk, ehunka megabyteko irudiaren tamaina guztiz normala zen: Ubunturen irudi batek 600 megabyte pisatzen zituen, eta Microsoft .Net irudi batek hainbat gigabyte pisatzen zituen. Egun larri haietan, irudi bakarra deskargatzeak eragin handia izan zezakeen diskoko espazio librean, nahiz eta irudien artean mailak partekatu. Gaur egun - goraipatu handia izan - irudiek askoz gutxiago pisatzen dute, baina hala ere, eskuragarri dauden baliabideak azkar bete ditzakezu neurri batzuk hartzen ez badituzu.
Azken erabiltzaileak zuzenean ikusten ez dituen hainbat irudi mota daude:
- tarteko irudiak, zeinen arabera biltzen diren beste irudi batzuk - ezin dira ezabatu "beste" irudi horietan oinarritutako edukiontziak erabiltzen badituzu;
- zintzilik dauden irudiak tarteko irudiak dira, martxan dauden edukiontziren batek erreferentziarik ez duena - ezaba daitezke.
- Hurrengo komandoarekin zure sisteman zintzilik dauden irudiak egiaztatu ditzakezu:
$ docker image ls -f dangling=true
REPOSITORY TAG IMAGE ID CREATED SIZE
none none 21e658fe5351 12 minutes ago 71.3MBModu honetan ken ditzakezu:
$ docker image rm $(docker image ls -f dangling=true -q)Prune azpikomandoa ere erabil dezakegu:
$ 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.9kBBat-batean irudi guztiak guztiz ezabatu nahi baditugu (eta ez bakarrik zintzilik) komando batekin, orduan hau egin dezakegu:
$ docker image rm $(docker image ls -q)Diskoaren erabilera bolumenen arabera
Bolumenak edukiontziaren fitxategi-sistematik kanpo datuak gordetzeko erabiltzen dira. Adibidez, aplikazio baten emaitzak gorde nahi baditugu, beste modu batean erabiltzeko. Adibide arrunta datu-baseak dira.
Abiarazi dezagun MongoDB edukiontzi bat, munta dezagun edukiontzitik kanpoko bolumen bat eta bertatik bertatik datu-basearen babeskopia (eskuragarri dugu bck.json fitxategian):
# 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
--jsonArrayDatuak ostalari makinan kokatuko dira /var/lib/docker/volumes direktorioan. Baina zergatik ez edukiontziaren irakurketa-idazketa mailan? MongoDB irudiaren Dockerfile-n, /data/db direktorioa (non MongoDB-k bere datuak gordetzen dituen lehenespenez) bolumen gisa definitzen da.
Oharra: datuak sortu behar dituzten irudi askok bolumenak erabiltzen dituzte datu horiek gordetzeko.
MongoDB-rekin nahikoa jolasten dugunean eta edukiontzia gelditzen dugunean (edo agian ezabatzen dugunean), bolumena ez da ezabatuko. Gure diskoko espazio preziatua hartzen jarraituko du esplizituki honelako komando batekin ezabatzen dugun arte:
$ docker volume rm $(docker volume ls -q)Beno, edo dagoeneko ezaguna zaigun prune azpikomandoa erabil dezakegu:
$ 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:~$Diskoa erabiliz irudiak eraikitzeko cacherako
Docker 18.09-n, irudiak sortzeko prozesuak aldaketa batzuk izan ditu BuildKit tresnari esker. Gauza honek prozesuaren abiadura handitzen du eta datuak biltegiratzea eta segurtasunaren kudeaketa optimizatzen ditu. Hemen ez ditugu tresna zoragarri honen xehetasun guztiak kontuan hartuko; diskoko espazioaren erabilera-gaiak nola konpontzen dituen bakarrik zentratuko gara.
Demagun Node.Js aplikazio guztiz sinplea dugula:
- index.js fitxategiak HTTP zerbitzari soil bat abiarazten du, jasotako eskaera bakoitzari lerro batekin erantzuten diona:
- package.json fitxategiak menpekotasunak definitzen ditu, eta horietatik expressjs bakarrik erabiltzen da HTTP zerbitzaria exekutatzeko:
$ 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"
}
}Irudia eraikitzeko Dockerfile-k itxura hau du:
FROM node:13-alpine
COPY package.json /app/package.json
RUN cd /app && npm install
COPY . /app/
WORKDIR /app
EXPOSE 80
CMD ["npm", "start"]Eraiki dezagun irudia ohiko moduan, BuildKit erabili gabe:
$ docker build -t app:1.0 .Diskoko espazioaren erabilera egiaztatzen badugu, oinarrizko irudiak (nodoa:13-alpine) eta helburuko irudiak (app:1.0) baino ez dutela tokia hartzen ikusiko dugu:
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 0BEraiki dezagun gure aplikazioaren bigarren bertsioa, BuildKit erabiliz. Horretarako, DOCKER_BUILDKIT aldagaia 1ean ezarri behar dugu:
$ DOCKER_BUILDKIT=1 docker build -t app:2.0 .Orain diskoaren erabilera egiaztatzen badugu, ikusiko dugu eraikitzeko cachea (buid-cache) hor parte hartzen duela:
$ 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.949kBGarbitzeko, erabili komando hau:
$ 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.949kBGarbitu dena!
Beraz, edukiontziek, irudiek eta bolumenek okupatzen duten diskoko espazioa garbitzea aztertu dugu. Prune azpikomandoak horretan laguntzen digu. Baina docker sistema mailan ere erabil daiteke, eta ahal duen guztia garbituko du:
$ 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]Arrazoiren batengatik Docker exekutatzen ari den makina batean diskoko tokia aurrezten ari bazara, komando hau aldian-aldian exekutatzen ari zaren ohitura bihurtu beharko litzateke.
Iturria: www.habr.com