Ehi Habr! Prestu à a vostra attenzione a traduzzione di l'articulu
Oghje parlemu di cumu Docker usa u spaziu di discu di a macchina d'ospiti, è avemu da capisce ancu cumu per liberà stu spaziu da i scraps d'imaghjini è cuntenituri inutilizati.
Cunsumu tutale
Docker hè una cosa fantastica, probabilmente poche persone dubitanu oghje. Uni pochi anni fà, stu pruduttu ci hà datu un modu completamente novu per custruisce, furnisce è eseguisce qualsiasi ambiente, chì ci permette di salvà significativamente risorse di CPU è RAM. In più di questu (è per alcuni questu serà u più impurtante) Docker ci hà permessu di simplificà incredibbilmente è unificà a gestione di u ciclu di vita di i nostri ambienti di produzzione.
Tuttavia, tutti questi piacè di a vita muderna venenu à un prezzu. Quandu eseguimu cuntenituri, scarichemu o creemu e nostre proprie imagine, è implementemu ecosistemi cumplessi, avemu da pagà. E paghemu, frà altre cose, cù u spaziu di discu.
Se ùn avete mai pensatu à quantu spaziu Docker occupa veramente nantu à a vostra macchina, pudete esse sgradamente sorpresu da l'output di stu cumandamentu:
$ docker system df
Questu mostra l'usu di u discu di Docker in diversi cuntesti:
- images - a dimensione tutale di l'imaghjini chì sò stati scaricati da i repositori di l'imaghjini è custruitu nantu à u vostru sistema;
- containers - a quantità tutale di spaziu di discu utilizatu da i cuntenituri esecutivi (chì significa u voluminu tutale di strati di lettura-scrittura di tutti i cuntenituri);
- volumi lucali - u voluminu di l'almacenamiento lucale muntatu à i cuntenituri;
- build cache - fugliali tempurane generati da u prucessu di creazione di l'imaghjini (aduprendu l'uttellu BuildKit, dispunibule da a versione Docker 18.09).
Aghju scumessa chì, dopu à stu trasferimentu simplice, site ansiosu di pulizziari u vostru discu di basura è di rinvià i preziosi gigabyte à a vita (nota: soprattuttu s'ellu paghete un affittu per questi gigabyte ogni mese).
L'usu di u discu da cuntenituri
Ogni volta chì create un cuntinuu nantu à a macchina d'ospiti, parechji schedari è cartulari sò creati in u cartulare /var/lib/docker, trà i quali vale a pena nutà:
- Directory /var/lib/docker/containers/container_ID - quandu si usa u driver di logging standard, hè quì chì i logs di l'avvenimenti sò salvati in formatu JSON. I logs troppu detallati, è ancu i logs chì nimu leghje o altrimenti prucessi, spessu causanu i dischi per esse pieni.
- U cartulare /var/lib/docker/overlay2 cuntene i strati di lettura-scrittura di u containeru (overlay2 hè u driver preferitu in a maiò parte di e distribuzioni Linux). Se u cuntinuu guarda dati in u so sistema di schedari, allora hè in questu repertoriu chì serà postu.
Imaginemu un sistema nantu à quale hè stallatu un Docker pristine, chì ùn hè mai statu implicatu in u lanciamentu di cuntenituri o in a custruzzione d'imaghjini. U so rapportu di usu di u spaziu di discu sarà cusì cusì:
$ 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
Lancemu qualchì containeru, per esempiu, NGINX:
$ docker container run --name www -d -p 8000:80 nginx:1.16
Cosa succede à u discu:
- l'imaghjini occupanu 126 MB, questu hè u stessu NGINX chì avemu lanciatu in u cuntinuu;
- i cuntenituri piglianu un ridiculu 2 byte.
$ 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
A ghjudicà da a cunclusione, ùn avemu micca ancu spaziu chì pudemu liberà. Siccomu 2 bytes hè cumplettamente frivulu, imaginemu chì u nostru NGINX hà scrittu inaspettatamente in un locu 100 Megabytes di dati è hà creatu un schedariu test.img di esattamente questa dimensione in sè stessu.
$ docker exec -ti www
dd if=/dev/zero of=test.img bs=1024 count=0 seek=$[1024*100]
Esaminemu di novu l'usu di u spaziu di discu nantu à l'ospite. Videremu chì u cuntinuu (containers) occupa 100 Megabytes quì.
$ 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
Pensu chì u vostru cervellu curiosu si dumanda digià induve u nostru schedariu test.img hè situatu. Circhemu :
$ 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
Senza entre in i dettagli, pudemu nutà chì u schedariu test.img hè convenientemente situatu à u livellu di lettura-scrittura, cuntrullatu da u driver overlay2. Se fermamu u nostru cuntinuu, l'ospitu ci dicerà chì stu spaziu pò esse liberatu in principiu:
# 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
Cumu pudemu fà questu? Sguassendu u cuntinuu, chì implicarà u spaziu currispundente à u livellu di lettura-scrittura.
Cù u cumandimu seguitu, pudete caccià tutti i cuntenituri installati in un colpu è sguassate u vostru discu di tutti i fugliali di lettura-scrittura creati da elli:
$ 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
Dunque, avemu liberatu 104,9 Megabytes eliminendu u containeru. Ma postu chì ùn usemu più l'imaghjini scaricati prima, diventa ancu un candidatu per sguassà è liberà e nostre risorse:
$ 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
Nota: Sempre chì l'imaghjini hè in usu di almenu un containeru, ùn puderà micca aduprà stu truccu.
U subcumandamentu prune chì avemu usatu sopra solu hà un effettu nantu à i cuntenituri fermati. Se vulemu sguassà micca solu cuntenituri fermati, ma ancu in esecuzione, duvemu aduprà unu di sti cumandamenti:
# Historical command
$ docker rm -f $(docker ps –aq)
# More recent command
$ docker container rm -f $(docker container ls -aq)
Note laterali: se utilizate u paràmetru -rm quandu principia un cuntinuu, quandu si ferma, tuttu u spaziu di discu chì occupava serà liberatu.
Utilizà l'imaghjini di discu
Qualchi anni fà, una grandezza di l'imaghjini di parechji cintunari di megabyte era cumplettamente normale: una maghjina Ubuntu pesava 600 megabyte, è una maghjina Microsoft .Net pesava parechji gigabytes. In quelli ghjorni shaggy, a scaricazione di una sola imaghjina puderia piglià un grande peghju nantu à u vostru spaziu di discu liberu, ancu s'è vo avete sparte livelli trà l'imaghjini. Oghje - elogi à i grandi - l'imaghjini pesanu assai menu, ma ancu cusì, pudete riempie rapidamente e risorse dispunibuli s'ellu ùn pigliate micca alcune precautions.
Ci sò parechji tippi d'imaghjini chì ùn sò micca visibili direttamente à l'utilizatori finali:
- l'imaghjini intermedii, nantu à a basa di quale altre imagine sò cullate - ùn ponu micca esse sguassate si utilizate cuntenituri basati nantu à sti "altri" imagine;
- L'imaghjini dangling sò imaghjini intermedi chì ùn sò micca riferiti da alcunu di i cuntenituri in esecuzione - ponu esse sguassati.
- Cù u cumandimu seguitu pudete verificà l'imaghjini pendenti in u vostru sistema:
$ docker image ls -f dangling=true
REPOSITORY TAG IMAGE ID CREATED SIZE
none none 21e658fe5351 12 minutes ago 71.3MB
Pudete caccià elli in a manera seguente:
$ docker image rm $(docker image ls -f dangling=true -q)
Pudemu ancu aduprà u subcumandamentu prune:
$ 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
Se vulemu di colpu sguassate tutte l'imaghjini in tuttu (è micca solu dangling) cù un cumandamentu, allora pudemu fà questu:
$ docker image rm $(docker image ls -q)
Usu di discu per volumi
I volumi sò usati per almacenà dati fora di u sistema di fugliale di u containeru. Per esempiu, s'è no vulemu salvà i risultati di una applicazione in ordine per usà in qualchì altru modu. Un esempiu cumuni hè a basa di dati.
Lanciamu un cuntainer MongoDB, muntemu un voluminu esternu à u cuntinuu, è restaurà una copia di salvezza di basa di dati da ellu (avemu dispunibule in u schedariu 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
I dati seranu situati nantu à a macchina host in u cartulare /var/lib/docker/volumes. Ma perchè micca à u livellu di lettura-scrittura di u cuntinuu? Perchè in u Dockerfile di l'imaghjini MongoDB, u repertoriu /data/db (induve MongoDB guarda i so dati per difettu) hè definitu cum'è un voluminu.
Nota laterale: parechje imagine chì deve pruduce dati usanu volumi per almacenà quella dati.
Quandu avemu ghjucatu abbastanza cù MongoDB è ferma (o forse ancu sguassate) u cuntinuu, u voluminu ùn serà micca sguassatu. Continuerà à piglià u nostru preziosu spaziu di discu finu à chì l'eliminemu esplicitamente cù un cumandamentu cum'è questu:
$ docker volume rm $(docker volume ls -q)
Ebbè, o pudemu usà u subcumandamentu prune chì hè digià familiarizatu per noi:
$ 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:~$
Utilizà u discu per a cache di creazione di l'imaghjini
In Docker 18.09, u prucessu di creazione di l'imaghjini hà subitu qualchi cambiamenti grazia à l'uttellu BuildKit. Questa cosa aumenta a vitezza di u prucessu è ottimisimu u almacenamentu di dati è a gestione di a sicurità. Quì ùn cunsideremu micca tutti i ditagli di sta maravigliosa strumentu; ci concentreremu solu nantu à cumu si tratta di prublemi di usu di u spaziu di discu.
Diciamu chì avemu una applicazione Node.Js cumplettamente simplice:
- u schedariu index.js principia un servitore HTTP simplice chì risponde cù una linea à ogni dumanda ricevuta:
- u schedariu package.json definisce e dipendenze, di quale solu expressjs hè utilizatu per eseguisce u servitore HTTP:
$ 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"
}
}
U Dockerfile per custruisce l'imaghjini s'assumiglia cusì:
FROM node:13-alpine
COPY package.json /app/package.json
RUN cd /app && npm install
COPY . /app/
WORKDIR /app
EXPOSE 80
CMD ["npm", "start"]
Custruemu l'imaghjini in u modu di solitu, senza aduprà BuildKit:
$ docker build -t app:1.0 .
Se cuntrollemu l'usu di u spaziu di discu, pudemu vede chì solu l'imaghjini di basa (node: 13-alpine) è l'imaghjini di destinazione (app: 1.0) occupanu spaziu:
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
Custruemu a seconda versione di a nostra applicazione, usendu BuildKit. Per fà questu, avemu bisognu di stabilisce a variabile DOCKER_BUILDKIT à 1:
$ DOCKER_BUILDKIT=1 docker build -t app:2.0 .
Se avà verificate l'usu di u discu, videremu chì a cache di creazione (buid-cache) hè avà implicata quì:
$ 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
Per sguassà, utilizate u cumandimu seguitu:
$ 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
Pulisce tuttu!
Dunque, avemu vistu a pulizia di u spaziu di discu occupatu da cuntenituri, imagine è volumi. U prune subcommand ci aiuta cun questu. Ma pò ancu esse aduprata à u nivellu di u sistema docker, è purificà tuttu ciò chì pò:
$ 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]
Se per una certa ragione stai risparmiendu spaziu di discu in a vostra macchina Docker, allora eseguisce periodicamente stu cumandamentu deve diventà un abitudine.
Source: www.habr.com