Brisanje slik, vsebnikov in nosilcev Docker (prune)

Docker ničesar ne izbriše sam. Vsaka prenesena slika (image), vsak ustavljen vsebnik, vsak nosilec (volume), predpomnilnik gradnje slik (build cache) in dnevniki vsebnikov ostanejo na disku, v mapi /var/lib/docker. Na redno posodabljanem strežniku je to lahko v nekaj mesecih več deset gigabajtov, disk manjšega VPS pa se nekega dne napolni.

Ta članek pokaže, kako pogledaš, kaj zaseda prostor, kako brišeš posamično in množično z ukazi prune, kako izprazniš podivjano dnevniško datoteko in česa ne brisati. Korake smo novembra 2026 preizkusili v sistemih Ubuntu 26.04, Debian 13 in AlmaLinux 10.2, z različico Docker 29.9.3. O namestitvi Dockerja govori članek Namestitev Dockerja v sisteme Ubuntu, Debian in AlmaLinux.

Primeri so navedeni brez sudo; če tvoj uporabnik ni v skupini docker, pred njih dodaj sudo.

Koliko prostora zaseda Docker?

docker system df

TOTAL / ACTIVE: koliko jih je in koliko od teh uporablja vsebnik.
SIZE: skupna velikost.
RECLAIMABLE: toliko je mogoče sprostiti z brisanjem neuporabljenih elementov.

docker system df -v velikosti izpiše tudi po elementih, na primer kako velik je kateri nosilec in koliko vsebnikov ga uporablja (LINKS). Velikost celotnega podatkovnega imenika Dockerja pokaže sudo du -sh /var/lib/docker (glej: Ukaz du podrobno).

Dangling in neuporabljeno: kakšna je razlika?

	Kaj pomeni	Kaj ga izbriše
Slika dangling	Slika brez oznake (imena), na primer stara različica, ki je ostala po ponovni gradnji ali ponovnem prenosu (`<none>`)	`docker image prune`
Neuporabljena slika	Nanjo se ne sklicuje noben vsebnik, vključno z ustavljenimi	`docker image prune -a`
Neimenovan nosilec	Nosilec z dolgim, naključnim identifikatorjem, ki ga je Docker ustvaril zaradi ukaza `VOLUME` v sliki ali stikala `-v /mappa`	`docker volume prune`
Poimenovan nosilec	Nosilec, ustvarjen z lastnim imenom (`-v adatok:/data`, Compose `volumes:`)	le `docker volume prune -a` ali `docker volume rm`

Docker 29 v novih namestitvah uporablja shrambo slik containerd (v izpisu docker info: Storage Driver: overlayfs). V preizkusu s tem slika dangling sploh ni nastala: po ponovni gradnji slike je stara različica takoj izginila s seznama, njeno mesto pa je zasedel predpomnilnik gradnje. Po dokumentaciji Docker namestitve, posodobljene s starejše različice, ohranijo prejšnjo shrambo (Storage Driver: overlay2); tam se slike <none> še vedno pojavljajo. Navaden docker image prune zato pogosto ne sprosti ničesar; neuporabljene slike izbriše stikalo -a.

Posamično brisanje

Vsebniki:

docker ps -a                       # vsi vsebniki, tudi ustavljeni
docker rm nev                      # brisanje ustavljenega vsebnika
docker rm -f nev                   # ustavitev in brisanje tekočega vsebnika
docker rm -v nev                   # skupaj z njegovimi brezimnimi nosilci
docker rm $(docker ps -aq -f status=exited)   # vsi ustavljeni vsebniki

Tekočega vsebnika brez -f ni mogoče izbrisati: cannot remove container "cache": container is running: stop the container before removing or force remove.

Slike:

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

Slike ni mogoče izbrisati, dokler jo uporablja vsebnik (tudi ustavljen): conflict: unable to delete redis:alpine (must be forced) - container bfa361262ba5 is using its referenced image. Najprej izbriši vsebnik; s stikalom -f ne sili.

Nosilci in omrežja:

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

Nosilca, priklopljenega na vsebnik, Docker ne dovoli izbrisati (volume is in use), tudi če je vsebnik le ustavljen. Z izbrisom nosilca se podatki v njem (na primer podatkovna baza) trajno izgubijo.

Pri projektu Compose docker compose down izbriše vsebnike in omrežje projekta, njegove nosilce pa obdrži; docker compose down -v izbriše tudi poimenovane nosilce. Več o tem piše članek Uporaba Docker Compose.

Množično brisanje z ukazi prune

Ukaz	Kaj izbriše
`docker container prune`	vse ustavljene vsebnike
`docker image prune`	slike dangling
`docker image prune -a`	vse slike, ki jih ne uporablja noben vsebnik
`docker volume prune`	neimenovane nosilce brez vsebnika
`docker volume prune -a`	vse nosilce brez vsebnika, tudi poimenovane
`docker network prune`	lastna omrežja brez vsebnika
`docker builder prune`	predpomnilnik gradnje dangling (ki ni vezan na nobeno sliko)
`docker builder prune -a`	celoten predpomnilnik gradnje
`docker system prune`	ustavljeni vsebniki, neuporabljena omrežja, slike dangling, neuporabljen predpomnilnik gradnje
`docker system prune -a`	enako, vendar z vsemi neuporabljenimi slikami in celotnim predpomnilnikom gradnje
`docker system prune --volumes`	enako, skupaj z neimenovanimi nosilci brez vsebnika

Vsak vpraša, ali res želiš nadaljevati ([y/N]), in izpiše, kaj bo izbrisal. Stikalo -f (--force) vprašanje preskoči; uporabljaj ga le v skripti, s preverjenim ukazom.

Na sliki je lepo vidno, da navaden docker system prune pogosto sprosti komaj kaj prostora (tu 53 kB): ustavljeni vsebniki so majhni, prostor pa zasedajo neuporabljene slike in nosilci. V preizkusu je na istem računalniku docker image prune -a sprostil 492 MB.

Previdno: system prune -a in –volumes

docker system prune najprej izbriše ustavljene vsebnike. Če si vsebnik ustavil le začasno (docker stop, docker compose stop), se izbriše tudi ta, z njim pa njegova konfiguracija (vrata, okoljske spremenljivke). Pri projektu Compose to ni težava, ker ga docker compose up -d ustvari znova; pri vsebniku, ročno zagnanem z docker run, pa moraš ukaz vpisati znova.
-a izbriše vse slike, ki nimajo vsebnika, zato jih Docker ob naslednjem zagonu prenese znova. Če si staro različico hranil za vrnitev, izgine tudi ta.
--volumes izbriše tudi neimenovane nosilce, v istem zagonu skupaj z ustavljenimi vsebniki. V preizkusu sta se ustavljen vsebnik in njegov neimenovan nosilec izbrisala z enim samim ukazom docker system prune --volumes. Če se je vsebnik podatkovne baze (na primer iz slike postgres ali mariadb) zagnal brez navedbe nosilca, so njegovi podatki prav v takem neimenovanem nosilcu, čiščenje v ustavljenem stanju pa jih trajno izbriše.

Poimenovanih nosilcev ne izbriše niti system prune --volumes; za to je potreben docker volume prune -a, ki ga zaženi le, če si prepričan, da ne potrebuješ nobenega nosilca.

Filtri: until in label

S stikalom --filter se izbrišejo le starejši elementi ali elementi z navedeno oznako:

# Neuporabljene slike, starejše od 24 ur
docker image prune -a --filter "until=24h"
# Ustavljeni vsebniki, omrežja, slike in build cache, starejši od 7 dni
docker system prune -a --filter "until=168h"
# Le neuporabljene slike z oznako projekt=demo
docker image prune -a --filter "label=projekt=demo"

Vrednost until je lahko trajanje (24h, 30m; dni ne sprejme, zato je 7 dni 168h) ali datum (2026-11-01T00:00:00). V preizkusu je until pri slikah upošteval čas prenosa slike, ne datuma njene izdelave: slika, izdelana pred 7 meseci, a prenesena isti dan, je s filtrom until=168h ostala. Oznako (label) slike dobijo iz vrstice LABEL v Dockerfile.

Nosilci filtra until ne poznajo: docker volume prune --filter until=24h vrne napako (invalid filter 'until'), tudi docker system prune --volumes --filter until=24h se ne izvede (The "until" filter is not supported with "--volumes"). Nosilce lahko filtriraš s filtrom label.

Podivjane dnevniške datoteke

Izpis vsebnikov privzeto pride v datoteko JSON, brez omejitve velikosti. Dnevnik vsebnika, ki veliko beleži, raste zelo hitro: v preizkusu je dnevnik vsebnika, ki je ves čas pisal, v 10 sekundah dosegel 1 GB. Mesto in velikost dnevniške datoteke pogledaš takole:

docker inspect --format '{{.LogPath}}' imevsebnika
sudo du -h $(docker inspect --format '{{.LogPath}}' imevsebnika)

Velikost dnevnikov vseh vsebnikov, z največjimi na koncu:

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

Praznjenje dnevnika brez ustavitve vsebnika:

sudo truncate -s 0 $(docker inspect --format '{{.LogPath}}' imevsebnika)

Dnevniške datoteke ne briši z ukazom rm. V preizkusu je dockerd izbrisano datoteko še naprej držal odprto: prostor se ni sprostil, dnevnik je nevidno rasel naprej (sudo lsof +L1 ga je pokazal z oznako (deleted)), docker logs pa je vrnil napako (Error grabbing logs: ... no such file or directory). Prostor je sprostil šele ponovni zagon (docker restart) ali izbris vsebnika. Ta pojav podrobno opisuje članek Disk je poln, du pa tega ne pokaže.

truncate je le blažitev simptomov. Trajna rešitev je omejitev velikosti dnevnikov v datoteki /etc/docker/daemon.json ("log-opts": {"max-size": "10m", "max-file": "3"}), ki jo predstavlja članek o namestitvi. To velja le za nove vsebnike; nastavitev obstoječega vsebnika preveriš takole:

docker inspect --format '{{.HostConfig.LogConfig}}' imevsebnika

{json-file map[]} pomeni dnevnik brez omejitve, {json-file map[max-file:3 max-size:10m]} pa omejenega. Posameznemu vsebniku lahko omejitev nastaviš tudi v ukazu docker run: --log-opt max-size=10m --log-opt max-file=3.

Redno čiščenje s časovnikom systemd

Spodnja storitev in časovnik vsako nedeljo zgodaj zjutraj izbrišeta neuporabljene slike, ustavljene vsebnike in omrežja, starejše od 7 dni, ter predpomnilnik gradnje. Nosilcev namenoma ne obravnavata.

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

[Unit]
Description=Brisanje neuporabljenih slik, vsebnikov in build cache Docker
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=Tedensko čiščenje Dockerja

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

[Install]
WantedBy=timers.target

Vklop in poskusni zagon:

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

Zaradi Persistent=true se čiščenje, če je bil računalnik ob navedenem času izklopljen, izvede ob naslednjem zagonu. Če imaš raje cron, je isto v crontab uporabnika root (sudo crontab -e) ena vrstica:

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

O sintaksi crona piše članek Sintaksa crontab in načrtovana opravila. Ne pozabi: tudi to čiščenje izbriše ustavljene vsebnike, če so bili ustvarjeni pred več kot 7 dnevi. Če vsebnik dlje časa držiš ustavljen, a ga želiš obdržati, te metode ne uporabljaj ali ukaz zoži na obliko docker image prune -a --force --filter "until=168h".

Česa ne brisati?

Vsebine mape /var/lib/docker ročno. Docker v podatkovni bazi vodi evidenco, kje je kateri sloj, nosilec in vsebnik; ročni izbris posameznega imenika to zmede, vsebniki ali slike pa lahko postanejo neuporabni. Vedno briši z ukazi docker. Celotno mapo izbriši le ob odstranitvi Dockerja.
Poimenovanih nosilcev, dokler ne veš, kaj je v njih. Podatkovne baze, naložene datoteke in nastavitve aplikacij so običajno v nosilcih. Vsebino nosilca si lahko pred izbrisom ogledaš: docker run --rm -v kotetnev:/adat alpine ls -la /adat. Za pomembne podatke najprej naredi varnostno kopijo.
Ustavljenih, a še potrebnih vsebnikov. Takrat sta namesto system prune bolj ciljana docker image prune -a in docker builder prune.
Slik, shranjenih za vrnitev. Če se želiš po posodobitvi vrniti na staro različico, stare slike ne briši, dokler se nova ne izkaže za dobro.

Če po čiščenju Dockerja prostor še vedno pojenja, ti preverjanje porabe diska pomaga najti, kaj zunaj Dockerja zaseda disk.