🥇Docker Tips: Rensa din maskin från skräp

Hej, Habr! Jag presenterar översättningen av artikeln "Docker Tips: Rensa upp din lokala maskin" författare Luc Juggery.

Idag ska vi prata om hur Docker använder diskutrymmet på värdmaskinen och också gå igenom hur man kan frigöra detta utrymme från skräp som onödiga bilder och containrar.

Total användning

Docker är en fantastisk grej, idag är det nog få som tvivlar på detta. För bara några år sedan gav denna produkt oss ett helt nytt sätt att bygga, leverera och köra vilken miljö som helst, vilket gör att vi kan spara betydligt på processor- och minnesresurser. Utöver detta (och för vissa är det kanske det viktigaste) har Docker låtit oss förenkla och standardisera hanteringen av livscykeln för de arbetsmiljöer vi använder.

Men för allt detta moderna liv måste man betala. När vi kör containrar, laddar ner eller skapar egna bilder, rullar ut komplexa ekosystem, så betalar vi. Och vi betalar också med diskutrymme.

Om du aldrig har funderat på hur mycket plats som faktiskt är upptagen på din Docker-maskin kan du bli obehagligt överraskad av resultatet från detta kommando:

$ docker system df

Här visas Docker-användningen av disk i olika aspekter:

bilder (images) – den totala storleken av bilder som har laddats ner från bildförråd och skapats i ditt system;
containrar (containers) – den totala mängden diskytan som används av aktiva containrar (det handlar om den totala mängden läs- och skrivlager av alla containrar);
lokala volymer (local volumes) – mängden lokala lagringsutrymmen som är monterade på containrar;
byggcache (build cache) – tillfälliga filer som genereras av processen att bygga bilder (vid användning av verktyget BuildKit, tillgängligt från och med Docker version 18.09).

Jag kan slå vad om att efter denna enkla uppräkning brinner du av längtan att rensa disken från skräp och återfå dina värdefulla gigabyte (anm. övers.: särskilt om du betalar hyra för dessa gigabyte varje månad).

Diskanvändning av containrar

Varje gång en container skapas på värdmaskinen skapas flera filer och kataloger i katalogen /var/lib/docker, bland vilka följande är värda att notera:

Katalogen /var/lib/docker/containers/ID_kontainer – när standard logg-drivrutinen används, sparas loggarna i JSON-format här. Alltför detaljerade loggar, samt loggar som ingen läser eller behandlar på andra sätt, blir ofta en orsak till att diskarna fylls.
Katalogen /var/lib/docker/overlay2 – innehåller skriv- och läslager för containrar (overlay2 – den föredragna drivrutinen i de flesta Linux-distributioner). Om containern sparar data i sitt filsystem kommer de att placeras i denna katalog.

Låt oss föreställa oss ett system där Docker är helt nyinstallerad, utan att ha deltagit i att köra containrar eller bygga bilder. Dess rapport om diskusage skulle se ut så här:

$ 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

Låt oss köra en container, till exempel NGINX:

$ docker container run --name www -d -p 8000:80 nginx:1.16

Vad händer med disken:

bilder (images) tar upp 126 MB, det är just den NGINX vi har startat i containern;
containrar (containers) tar upp löjliga 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

Enligt utskriften har vi fortfarande inget utrymme som vi kan frigöra. Eftersom 2 byte är helt oseriöst, låt oss föreställa oss att vår NGINX oväntat har skrivit 100 Megabyte data någonstans och skapat en fil test.img av just den storleken.

$ docker exec -ti www 
  dd if=/dev/zero of=test.img bs=1024 count=0 seek=$[1024*100]

Vi undersöker igen användningen av diskutrymme på värden. Vi kommer att se att containern (containers) tar upp 100 Megabyte där.

$ 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

Jag tror att din nyfikna hjärna redan undrar var vår fil test.img finns. Låt oss leta efter den:

$ 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

Utan att gå in på detaljer kan vi konstatera att filen test.img är bekvämt placerad på läs- och skrivnivåer som hanteras av overlay2-drivern. Om vi stoppar vår container kommer värden att meddela oss att detta utrymme i princip kan frisättas:

# 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

Hur kan vi åstadkomma detta? Genom att ta bort containern, vilket kommer att rensa det motsvarande utrymmet på läs- och skrivnivå.

Med följande kommando kan du ta bort alla installerade containrar på en gång och rensa din disk från alla filer som de skapat på läs- och skrivnivå:

$ docker container prune
WARNING! Detta kommer att ta bort alla stoppade containrar.
Är du säker på att du vill fortsätta? [y/N] y
Borttagna containrar:
5e7f8e5097ace9ef5518ebf0c6fc2062ff024efb495f11ccc89df21ec9b4dcc2

Totalt återvunnen plats: 104.9MB

Så, vi har frigjort 104,9 megabyte genom att ta bort containern. Men eftersom vi inte längre använder den nedladdade bilden, blir även den kandidat för borttagning och frigör våra resurser:

$ 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

Observera: så länge som bilden används av minst en container kan du inte använda detta trick.

Undersubkommandot prune, som vi använde ovan, ger effekt endast på stoppade containrar. Om vi vill ta bort inte bara stoppade utan även körande containrar, bör vi använda något av dessa kommandon:

# Historical command
$ docker rm -f $(docker ps –aq)

# More recent command
$ docker container rm -f $(docker container ls -aq)

Noter på sidlinjen: om du använder parametern --rm vid start av containern, kommer allt diskutrymme som den använde att frigöras vid nedstängning.

Diskanvändning av bilder

För några år sedan var storleken på en bild på flera hundra megabyte helt normal: Ubuntu-bilden vägde 600 megabyte och Microsoft .Net-bilden flera gigabyte. På den tiden kunde nedladdningen av bara en bild orsaka stor skada på ditt fria utrymme på disken, även om du delade nivåer mellan bilder. Idag – tack och lov – väger bilderna mycket mindre, men även i detta fall kan du snabbt fylla upp befintliga resurser om du inte vidtar vissa försiktighetsåtgärder.

Det finns flera typer av bilder som inte syns direkt för slutanvändaren:

intermediära bilder, som andra bilder är baserade på – de kan inte tas bort om du använder containrar baserade på dessa "andra" bilder;
hängande bilder – dessa är sådana intermediära bilder som ingen av de körande containrarna refererar till – de kan tas bort.
Med följande kommando kan du kontrollera om det finns hängande bilder i ditt system:

$ docker image ls -f dangling=true
REPOSITORY  TAG      IMAGE ID         CREATED             SIZE
none      none   21e658fe5351     12 minutes ago      71.3MB

De kan tas bort på följande sätt:

$ docker image rm $(docker image ls -f dangling=true -q)

Vi kan också använda subkommandot prune:

$ docker image prune
WARNING! Detta kommer att ta bort alla hängande bilder.
Är du säker på att du vill fortsätta? [y/N] y
Raderade bilder:
raderad: sha256:143407a3cb7efa6e95761b8cd6cea25e3f41455be6d5e7cda
raderad: sha256:738010bda9dd34896bac9bbc77b2d60addd7738ad1a95e5cc
raderad: sha256:fa4f0194a1eb829523ecf3bad04b4a7bdce089c8361e2c347
raderad: sha256:c5041938bcb46f78bf2f2a7f0a0df0eea74c4555097cc9197
raderad: sha256:5945bb6e12888cf320828e0fd00728947104da82e3eb4452f

Totalt återvunnen plats: 12.9kB

Om vi plötsligt vill ta bort alla bilder (inte bara hängande) med ett kommando kan vi göra så här:

$ docker image rm $(docker image ls -q)

Användning av disk med volymer

Volymer används för att lagra data utanför containerns filsystem. Till exempel, om vi vill spara resultaten från ett program för att använda dem på något annat sätt. Ett vanligt exempel är databaser.

Låt oss starta en MongoDB-container, montera en extern volym till den, och återställa en databasbackup från en fil (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

Data kommer att befinna sig på värdmaskinen i katalogen /var/lib/docker/volumes. Men varför inte på nivå med läs- och skrivåtkomst hos containern? För att i Dockerfile för MongoDB-bilden definieras katalogen /data/db (där MongoDB vanligtvis lagrar sina data) som en volym.

Noter i marginalen: många bilder, vars resultat ska skapa data, använder volymer för att spara dessa data.

När vi är klara med MongoDB och stoppar (eller kanske till och med raderar) containern, kommer volymen inte att tas bort. Den kommer att fortsätta ta upp vårt värdefulla diskutrymme tills vi uttryckligen tar bort den med följande kommando:

$ docker volume rm $(docker volume ls -q)

Eller så kan vi använda det redan bekanta subkommandot prune:

$ docker volume prune
VARNING! Detta kommer att ta bort alla lokala volymer som inte används av åtminstone en behållare.
Är du säker på att du vill fortsätta? [y/N] y
Borttagna volymer:
d50b6402eb75d09ec17a5f57df4ed7b520c448429f70725fc5707334e5ded4d5
8f7a16e1cf117cdfddb6a38d1f4f02b18d21a485b49037e2670753fa34d115fc
599c3dd48d529b2e105eec38537cd16dac1ae6f899a123e2a62ffac6168b2f5f
...
732e610e435c24f6acae827cd340a60ce4132387cfc512452994bc0728dd66df
9a3f39cc8bd0f9ce54dea3421193f752bda4b8846841b6d36f8ee24358a85bae
045a9b534259ec6c0318cb162b7b4fca75b553d4e86fc93faafd0e7c77c79799
c6283fe9f8d2ca105d30ecaad31868410e809aba0909b3e60d68a26e92a094da

Totalt återvunnen utrymme: 25.82GB
luc@saturn:~$

Användning av disk för cache av bildbyggen

I Docker 18.09 har processen för skapande av bilder genomgått vissa förändringar tack vare verktyget BuildKit. Med hjälp av detta ökar hastigheten på processen, och hantering av datalagring och säkerhet optimeras. Här kommer vi inte att gå in på alla detaljer om detta fantastiska verktyg, utan fokuserar istället på hur det berör användningen av diskutrymme.

Anta att vi har en helt enkel Node.Js-applikation:

filen index.js startar en enkel HTTP-server som svarar med en sträng på varje mottagen begäran:
filen package.json definierar beroenden, där endast expressjs används för att köra HTTP-servern:

$ 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"
      }
    }

Dockerfile för att bygga bilden ser ut så här:

FROM node:13-alpine
COPY package.json /app/package.json
RUN cd /app && npm install
COPY . /app/
WORKDIR /app
EXPOSE 80
CMD ["npm", "start"]

Låt oss bygga bilden på det vanliga sättet, utan att använda BuildKit:

$ docker build -t app:1.0 .

Om vi kontrollerar användningen av diskutrymme kommer vi att se att platsen endast tas av basbilden (node:13-alpine) och den slutgiltiga bilden (app:1.0):

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

Låt oss bygga den andra versionen av vår applikation, nu med användning av BuildKit. För detta behöver vi bara ställa in variabeln DOCKER_BUILDKIT till värdet 1:

$ DOCKER_BUILDKIT=1 docker build -t app:2.0 .

Om vi nu kontrollerar diskutrymmet kommer vi att se att byggcache (build-cache) nu också deltar:

$ 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

För att rensa det, använd följande kommando:

$ docker builder prune
WARNING! Detta kommer att ta bort all överflödig byggcache.
Är du säker på att du vill fortsätta? [y/N] y
Raderade byggcache-objekt:
rffq7b06h9t09xe584rn4f91e
ztexgsz949ci8mx8p5tzgdzhe
3z9jeoqbbmj3eftltawvkiayi

Totalt återvunnen plats: 8.949kB

Rensa allt!

Så vi har sett på att rensa diskhantering utlånat av containrar, bilder och volymer. Detta görs med hjälp av subkommandot prune. Men det kan också användas på systemnivå av Docker, och det kommer att rensa allt som det kan:

$ docker system prune
WARNING! Detta kommer att ta bort:
  - alla stoppade containrar
  - alla nätverk som inte används av minst en container
  - alla överflödiga bilder
  - all överflödig byggcache

Är du säker på att du vill fortsätta? [y/N]

Om du av någon anledning sparar diskutrymme på en maskin med Docker, är det värt att göra det till en vana att köra detta kommando regelbundet.

Källa: habr.com