10 gyakori Docker hiba és hogyan kerüld el őket

A Docker tanulása közben mindenki belefut ugyanabba a néhány hibába és buktatóba — ez teljesen természetes. A jó hír, hogy ezek jól ismertek, és többségük pár perc alatt orvosolható, ha tudod, hol keresd a gyökerét. Ebben a cikkben összeszedtem a tíz leggyakoribb Docker-hibát: mindegyiknél elmondom, mi az oka, és pontosan hogyan javítsd ki. Tedd el könyvjelzőnek — előbb-utóbb mind a tízbe belefutsz.

1. “Cannot connect to the Docker daemon”

A klasszikus kezdő hibaüzenet:

Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?

Ok: a Docker démon (Engine) nem fut, vagy a felhasználódnak nincs jogosultsága hozzá. A Docker kliens-szerver architektúrájú: a docker parancs csak egy kliens, ami egy futó démonnal beszélget.

Megoldás: indítsd el a démont. Linuxon:

sudo systemctl start docker

Asztali gépen indítsd el a Docker Desktopot. Ha állandóan sudo-t kell írnod, add magad a docker csoporthoz (majd jelentkezz ki-be):

sudo usermod -aG docker $USER

2. “port is already allocated”

Error: bind: address already in use

Ok: a hoston, amelyre publikálni próbálsz, már fut valami azon a porton — vagy egy másik konténer, vagy egy natív szolgáltatás.

Megoldás: keresd meg, mi foglalja, vagy válassz másik host-portot:

docker ps                       # fut-e már konténer ezen a porton?
docker run -p 8081:80 nginx     # másik host-port (8081) a konténer 80-as portjához

A -p HOST:KONTÉNER formátumban csak a bal oldali, host-portot kell szabaddá tenned.

3. Óriási image-ek

Ha az image-ed több gigabájt, lassú lesz a push, a pull és a deploy is.

Ok: teljes (nem slim/alpine) alapkép, felesleges build-eszközök benne hagyva, és a rétegek rossz kihasználása.

Megoldás: válassz karcsú alapot, és használj multi-stage buildet, hogy a fordítóeszközök ne kerüljenek a végső image-be:

FROM node:20-alpine AS build
WORKDIR /app
COPY . .
RUN npm ci && npm run build

FROM nginx:alpine
COPY --from=build /app/dist /usr/share/nginx/html

Az image méretét a docker images paranccsal ellenőrizheted.

4. Adatvesztés volume nélkül

Leállítod és törlöd a PostgreSQL konténered — és eltűnt minden adat. Ismerős?

Ok: a konténer fájlrendszere efemer: amikor a konténer megszűnik, az írható rétege is vele vész.

Megoldás: a tartós adatot named volume-ban tárold:

docker run -d \
  -v pgdata:/var/lib/postgresql/data \
  -e POSTGRES_PASSWORD=titok \
  postgres:16

💡 Tipp: A named volume (pgdata) túléli a konténer törlését. Akkor is megmarad, ha a konténert eldobod és újat indítasz ugyanazzal a volume-mal — pontosan ezt akarod adatbázisoknál.

5. A latest tag csapdája

A latest kényelmesnek tűnik, de alattomos.

Ok: a latest nem egy verzió, hanem csak egy mozgó mutató. Ma az 1.2-re mutathat, holnap az 1.3-ra — a buildjeid nem reprodukálhatók, és nem tudod biztosan, mi fut élesben.

Megoldás: mindig rögzíts konkrét verziót:

FROM postgres:16.3   # NEM: FROM postgres:latest

A saját image-eidet pedig tageld a git commit SHA-jával vagy semverrel — erről bővebben a Docker a CI/CD-ben cikkben olvashatsz.

6. Root-ként futtatott konténerek

Alapból a konténerben a folyamatok root-ként futnak.

Ok: ha senki nem mond mást, a Docker root-ot használ — egy esetleges betörésnél ez jóval nagyobb mozgásteret ad a támadónak.

Megoldás: hozz létre és válts egy jogosultság nélküli felhasználóra a Dockerfile-ban:

RUN useradd --create-home appuser
USER appuser

7. Titkok beégetése az image-be

Soha ne tegyél jelszót vagy API-kulcsot az image-be.

Ok: ha ENV API_KEY=... vagy egy .env fájl bekerül az image rétegeibe, az ott marad, és bárki kibányászhatja a docker history paranccsal — még akkor is, ha egy későbbi rétegben “törlöd”.

Megoldás: a titkokat futásidőben add át, ne build-időben:

docker run -e API_KEY=titok my-app
docker run --env-file .env my-app

Compose-ban environment vagy secrets használatával — erről a Docker Compose bevezető is segít.

8. Hiányzó .dockerignore

COPY . .

— és vele bemásolod a node_modules-t, a .git-et és a titkaidat is.

Ok: .dockerignore nélkül a teljes könyvtár bekerül a build kontextusba: lassabb build, nagyobb image, és potenciálisan kiszivárgó érzékeny fájlok.

Megoldás: hozz létre egy .dockerignore fájlt:

node_modules
.git
.env
__pycache__
*.log

⚠️ Figyelem: A .dockerignore hiánya nemcsak méret kérdése — biztonsági kockázat is. Egy bemásolt .env vagy .git/config valódi titkokat szivárogtathat ki. Ezt a fájlt mindig hozd létre, mielőtt először buildelsz.

9. Megtelt lemez — nincs takarítás

Egy idő után a no space left on device üzenet fogad.

Ok: a leállított konténerek, a használaton kívüli image-ek, a lógó rétegek és a build cache mind helyet foglalnak, és nem tűnnek el maguktól.

Megoldás: időnként takaríts. Először nézd meg, mi mennyit foglal, majd takaríts célzottan:

docker system df              # mi mennyi helyet foglal
docker system prune           # leállított konténerek + lógó image-ek + hálózatok
docker system prune -a --volumes   # agresszívabb: használaton kívüli minden

A -a --volumes óvatosan kezelendő, mert a nem használt volume-okat is törli.

10. COPY cache-invalidáció rossz sorrendnél

A buildjeid mindig nulláról telepítik a függőségeket, percekig tart minden apró kódváltozás után.

Ok: ha a COPY . . a függőségtelepítés elé kerül, akkor bármely forrásfájl módosítása érvényteleníti a telepítés rétegét is — a Docker mindent újraépít.

Megoldás: előbb csak a függőséglistát másold, telepíts, és csak utána a teljes forrást:

COPY package*.json ./
RUN npm ci          # ez a réteg cache-elhető, amíg a package.json nem változik
COPY . .            # a gyakran változó forrás csak ezt a réteget invalidálja

A rétegek és a cache működéséről részletesen ír a Dockerfile írása lépésről lépésre cikk.

Gyors áttekintő táblázat

Hiba	Egymondatos megoldás
Daemon nem elérhető	Indítsd a démont / docker csoport
Port foglalt	Másik host-port vagy a foglaló leállítása
Óriási image	slim/alpine + multi-stage
Adatvesztés	Named volume
latest tag	Rögzített verzió / SHA
Root user	USER appuser
Beégetett titok	Futásidős -e / --env-file
Nincs .dockerignore	Hozd létre
Megtelt lemez	docker system prune
Lassú build	Függőség a forrás elé

Összefoglalás

A leggyakoribb Docker-hibák szinte mind ugyanabból a néhány elvből vezethetők le: a démon kliens-szerver architektúrája, a konténer efemer fájlrendszere, a rétegek és a build cache működése, valamint az alapvető biztonsági higiénia (nem root, titkok kint, .dockerignore). Ha ezeket az elveket megérted, nemcsak ezt a tíz hibát kerülöd el, hanem a következő tizet is magabiztosan megoldod majd.

Ha még az alapokat építgeted, nézd meg a Kezdő lépések útmutatót és a Mi az a Docker? cikket — egy szilárd alap a legjobb védekezés a hibák ellen. Aztán fogd a saját projekted, és fuss végig ezen a listán: garantáltan találsz benne legalább egy javítanivalót!