Docker képek, konténerek és kötetek törlése (prune)

A Docker semmit nem töröl magától. Minden letöltött kép (image), minden leállt konténer, minden kötet (volume), a képépítés gyorsítótára (build cache) és a konténerek naplói a lemezen maradnak, a /var/lib/docker mappában. Egy rendszeresen frissített szerveren ez hónapok alatt több tíz gigabájt is lehet, és egy kisebb VPS lemeze egyszer csak betelik.

Ez a cikk megmutatja, hogyan nézheted meg, mi foglalja a helyet, hogyan törölhetsz egyenként és a prune parancsokkal tömegesen, hogyan üríthetsz ki egy elszabadult naplófájlt, és mit ne törölj. A lépéseket 2026 novemberében Ubuntu 26.04, Debian 13 és AlmaLinux 10.2 rendszeren próbáltuk ki, a Docker 29.9.3-as változatával. A Docker telepítéséről a Docker telepítése Ubuntu, Debian és AlmaLinux rendszerre cikk szól.

A példák sudo nélkül szerepelnek; ha a felhasználód nincs a docker csoportban, írd eléjük a sudo szót.

Mennyi helyet foglal a Docker?

docker system df

TOTAL / ACTIVE: hány darab van, és ebből hányat használ konténer.
SIZE: a teljes méret.
RECLAIMABLE: ennyi szabadítható fel a nem használt elemek törlésével.

A docker system df -v elemenként is kiírja a méreteket, például melyik kötet mekkora, és hány konténer használja (LINKS). A Docker egész adatkönyvtárának méretét a sudo du -sh /var/lib/docker mutatja (lásd: A du parancs részletesen).

Dangling és nem használt: mi a különbség?

	Mit jelent	Mi törli
Dangling kép	Címke (név) nélküli kép, például egy újraépítés vagy újraletöltés után megmaradt régi változat (`<none>`)	`docker image prune`
Nem használt kép	Egyetlen konténer sem hivatkozik rá, a leállt konténereket is beleértve	`docker image prune -a`
Névtelen kötet	Hosszú, véletlen azonosítójú kötet, amelyet a Docker egy kép `VOLUME` utasítása vagy a `-v /mappa` kapcsoló miatt hozott létre	`docker volume prune`
Nevesített kötet	Saját névvel létrehozott kötet (`-v adatok:/data`, Compose `volumes:`)	csak `docker volume prune -a` vagy `docker volume rm`

A Docker 29 a friss telepítéseken a containerd képtárolóját használja (a docker info kimenetében: Storage Driver: overlayfs). A teszten ezzel dangling kép egyáltalán nem keletkezett: egy kép újraépítése után a régi változat azonnal eltűnt a listából, a helyét a build cache foglalta. A Docker dokumentációja szerint a régebbi verzióról frissített telepítések megtartják a korábbi tárolót (Storage Driver: overlay2); ott a <none> képek továbbra is megjelennek. A sima docker image prune ezért gyakran semmit nem szabadít fel; a nem használt képeket a -a kapcsoló törli.

Törlés egyenként

Konténerek:

docker ps -a                       # minden konténer, a leálltak is
docker rm nev                      # egy leállt konténer törlése
docker rm -f nev                   # egy futó konténer leállítása és törlése
docker rm -v nev                   # a névtelen köteteivel együtt
docker rm $(docker ps -aq -f status=exited)   # az összes leállt konténer

Futó konténert a -f nélkül nem lehet törölni: cannot remove container "cache": container is running: stop the container before removing or force remove.

Képek:

docker images
docker rmi nginx:alpine            # ugyanaz: docker image rm nginx:alpine

Egy képet addig nem lehet törölni, amíg egy konténer (akár leállt) használja: conflict: unable to delete redis:alpine (must be forced) - container bfa361262ba5 is using its referenced image. Előbb a konténert töröld; a -f kapcsolóval ne erőltesd.

Kötetek és hálózatok:

docker volume ls
docker volume rm regi-adatok
docker network ls
docker network rm tesztnet

A konténerhez csatolt kötetet a Docker nem engedi törölni (volume is in use), akkor sem, ha a konténer csak le van állítva. A kötet törlésével a benne lévő adatok (például egy adatbázis) véglegesen elvesznek.

Compose-projektnél a docker compose down törli a projekt konténereit és hálózatát, a köteteit viszont megtartja; a docker compose down -v a nevesített köteteket is törli. Erről a Docker Compose használata cikk ír bővebben.

Tömeges törlés a prune parancsokkal

Parancs	Mit töröl
`docker container prune`	minden leállt konténert
`docker image prune`	a dangling képeket
`docker image prune -a`	minden képet, amelyet egyetlen konténer sem használ
`docker volume prune`	a konténer nélküli névtelen köteteket
`docker volume prune -a`	minden konténer nélküli kötetet, a nevesítetteket is
`docker network prune`	a saját, konténer nélküli hálózatokat
`docker builder prune`	a dangling (egyetlen képhez sem kötődő) build cache-t
`docker builder prune -a`	a teljes build cache-t
`docker system prune`	leállt konténerek, nem használt hálózatok, dangling képek, fel nem használt build cache
`docker system prune -a`	ugyanez, de minden nem használt képpel és a teljes build cache-sel
`docker system prune --volumes`	ugyanez, a konténer nélküli névtelen kötetekkel együtt

Mindegyik megkérdezi, biztosan folytatod-e ([y/N]), és kiírja, mit fog törölni. A -f (--force) kapcsoló kihagyja a kérdést; ezt csak szkriptben, ellenőrzött paranccsal használd.

A képen jól látszik, hogy a sima docker system prune sokszor alig szabadít fel helyet (itt 53 kB-ot): a leállt konténerek kicsik, a helyet a nem használt képek és a kötetek foglalják. A teszten ugyanezen a gépen a docker image prune -a 492 MB-ot szabadított fel.

Óvatosan: system prune -a és –volumes

A docker system prune először a leállt konténereket törli. Ha egy konténert csak ideiglenesen állítottál le (docker stop, docker compose stop), az is törlődik, és vele a konfigurációja (portok, környezeti változók). Compose-projektnél ez nem gond, mert a docker compose up -d újra létrehozza; egy kézzel, docker run-nal indított konténernél viszont a parancsot újra be kell írnod.
A -a minden olyan képet töröl, amelyhez nincs konténer, így a következő indításkor a Docker újra letölti őket. Ha egy régi változatot visszaállításra tartogattál, az is eltűnik.
A --volumes a névtelen köteteket is törli, ugyanabban a futásban a leállt konténerekkel együtt. A teszten egy leállt konténer és a hozzá tartozó névtelen kötet egyetlen docker system prune --volumes paranccsal törlődött. Ha egy adatbázis-konténer (például a postgres vagy a mariadb képből) kötet megadása nélkül indult, az adatai éppen egy ilyen névtelen kötetben vannak, és egy leállított állapotban futtatott takarítás véglegesen törli őket.

A nevesített köteteket a system prune --volumes sem törli; ehhez a docker volume prune -a kell, amelyet csak akkor futtass, ha biztos vagy benne, hogy egyik kötetre sincs szükséged.

Szűrők: until és label

A --filter kapcsolóval csak a régebbi vagy a megadott címkéjű elemek törlődnek:

# A 24 óránál régebbi, nem használt képek
docker image prune -a --filter "until=24h"
# A 7 napnál régebbi leállt konténerek, hálózatok, képek és build cache
docker system prune -a --filter "until=168h"
# Csak a projekt=demo címkéjű, nem használt képek
docker image prune -a --filter "label=projekt=demo"

Az until értéke lehet időtartam (24h, 30m; napot nem fogad el, ezért 7 nap 168h) vagy dátum (2026-11-01T00:00:00). A teszten a képeknél az until a kép letöltésének idejét vette alapul, nem a kép készítési dátumát: egy 7 hónapja készült, de aznap letöltött kép az until=168h szűrővel megmaradt. A címkét (label) a képek a Dockerfile LABEL sorából kapják.

A kötetek nem ismerik az until szűrőt: a docker volume prune --filter until=24h hibát ad (invalid filter 'until'), és a docker system prune --volumes --filter until=24h sem fut le (The "until" filter is not supported with "--volumes"). A kötetek a label szűrővel szűrhetők.

Elszabadult naplófájlok

A konténerek kimenete alapból egy-egy JSON-fájlba kerül, méretkorlát nélkül. Egy sokat naplózó konténer naplója nagyon gyorsan nő: a teszten egy folyamatosan író konténeré 10 másodperc alatt 1 GB lett. A naplófájl helyét és méretét így nézheted meg:

docker inspect --format '{{.LogPath}}' konténernév
sudo du -h $(docker inspect --format '{{.LogPath}}' konténernév)

Az összes konténer naplójának mérete, a legnagyobbakkal a végén:

sudo sh -c 'du -h /var/lib/docker/containers/*/*-json.log* | sort -h | tail'

A napló kiürítése a konténer leállítása nélkül:

sudo truncate -s 0 $(docker inspect --format '{{.LogPath}}' konténernév)

A naplófájlt ne töröld az rm paranccsal. A teszten a törölt fájlt a dockerd továbbra is nyitva tartotta: a hely nem szabadult fel, a napló láthatatlanul tovább nőtt (a sudo lsof +L1 (deleted) jelöléssel mutatta), a docker logs pedig hibát adott (Error grabbing logs: ... no such file or directory). A helyet a konténer újraindítása (docker restart) vagy törlése szabadította fel. Ezt a jelenséget a Betelt a lemez, de a du nem mutatja cikk részletesen leírja.

A truncate csak tüneti kezelés. A végleges megoldás a naplók méretkorlátja a /etc/docker/daemon.json fájlban ("log-opts": {"max-size": "10m", "max-file": "3"}), amelyet a telepítési cikk mutat be. Ez csak az új konténerekre érvényes; egy meglévő konténer beállítását így ellenőrizheted:

docker inspect --format '{{.HostConfig.LogConfig}}' konténernév

A {json-file map[]} korlát nélküli naplót jelent, a {json-file map[max-file:3 max-size:10m]} korlátozottat. Egyetlen konténernek a docker run parancsban is adhatsz korlátot: --log-opt max-size=10m --log-opt max-file=3.

Rendszeres takarítás systemd időzítővel

Az alábbi szolgáltatás és időzítő minden vasárnap hajnalban törli a 7 napnál régebbi, nem használt képeket, leállt konténereket és hálózatokat, valamint a build cache-t. A köteteket szándékosan nem érinti.

/etc/systemd/system/docker-prune.service:

[Unit]
Description=Nem használt Docker képek, konténerek és build cache törlése
Requires=docker.service
After=docker.service

[Service]
Type=oneshot
ExecStart=/usr/bin/docker system prune --all --force --filter "until=168h"

/etc/systemd/system/docker-prune.timer:

[Unit]
Description=Heti Docker takarítás

[Timer]
OnCalendar=Sun 04:00
RandomizedDelaySec=30min
Persistent=true

[Install]
WantedBy=timers.target

Bekapcsolás és egy próbafuttatás:

sudo systemctl daemon-reload
sudo systemctl enable --now docker-prune.timer
systemctl list-timers docker-prune.timer
sudo systemctl start docker-prune.service
journalctl -u docker-prune.service

A Persistent=true miatt ha a gép a megadott időpontban ki volt kapcsolva, a takarítás a következő induláskor lefut. Ha a cront szereted jobban, a root crontabjába (sudo crontab -e) ugyanez egy sor:

0 4 * * 0 /usr/bin/docker system prune --all --force --filter "until=168h" > /dev/null

A cron szintaxisáról a Crontab szintaxis és ütemezett feladatok cikk ír. Ne feledd: ez a takarítás is törli a leállított konténereket, ha azok 7 napnál régebben készültek. Ha egy konténert hosszabb ideig leállítva tartasz, de meg akarod tartani, ne használd ezt a módszert, vagy szűkítsd a parancsot docker image prune -a --force --filter "until=168h" alakra.

Mit ne törölj?

A /var/lib/docker mappa tartalmát kézzel. A Docker egy adatbázisban tartja nyilván, melyik réteg, kötet és konténer hol van; egy-egy könyvtár kézi törlése ezt összezavarja, és a konténerek vagy képek használhatatlanná válhatnak. Mindig a docker parancsokkal törölj. A mappa egészét csak a Docker eltávolításakor töröld.
Nevesített köteteket, amíg nem tudod, mi van bennük. Az adatbázisok, a feltöltött fájlok és az alkalmazások beállításai jellemzően kötetekben vannak. Egy kötet tartalmát törlés előtt megnézheted: docker run --rm -v kotetnev:/adat alpine ls -la /adat. Fontos adatokról előbb készíts mentést.
Leállított, de még szükséges konténereket. Ilyenkor a system prune helyett a docker image prune -a és a docker builder prune célzottabb.
Visszaállításhoz tartogatott képeket. Ha egy frissítés után vissza szeretnél térni a régi változatra, a régi képet ne töröld, amíg az új nem bizonyult jónak.

Ha a Docker takarítása után is fogy a hely, a lemezhasználat ellenőrzése segít megtalálni, mi foglalja a lemezt a Dockeren kívül.