Feilsøking av containeriserte applikasjoner innebærer å inspisere logger, få tilgang til shell inne i kontainere, undersøke konfigurasjon og tilstand, og diagnostisere vanlige problemer (krasj, nettverk, ressurser). Å kunne feilsøke er en viktig praktisk ferdighet.
docker ps -a
docker logs <container>
docker logs -f -- 100 <container>
docker inspect <container>
docker events
docker logs er vanligvis det første steget — det viser applikasjonens output og feil. docker ps -a avslører om en kontainer avsluttet (og dens avslutningskode).
# run an interactive shell inside a RUNNING container to investigate
docker exec -it <container> bash # or sh (alpine)
# → inspect files, run commands, check the environment, test connectivity from inside
# if the container won't STAY running, override the entrypoint to get a shell
docker run -it --entrypoint sh myimage
docker exec -it ... bash gir deg en shell inne i en kjørende kontainer — uvurderlig for å inspisere filer, sjekke miljøet, og teste tilkobling fra kontainerens perspektiv.
Container EXITS immediately → check `docker logs`; the main process crashed or finished
(a container stops when its main process exits) — check CMD/ENTRYPOINT, errors
CAN'T CONNECT between containers → check they're on the same network; use service NAMES
(not localhost); verify ports; `docker network inspect`
PORT not accessible → check -p mapping; the app must listen on 0.0.0.0 (not 127.0.0.1)
OUT OF MEMORY / killed → check `docker stats`, resource limits (OOMKilled in inspect)
PERMISSION errors → file ownership/user (non-root user vs mounted volume permissions)
IMAGE issues → rebuild without cache (--no-cache); check the build context/.dockerignore
Å kunne debugge og feilsøke Docker-kontainere er en viktig praktisk ferdighet, fordi containeriserte applikasjoner uunngåelig har problemer (krasj, tilkoblingsproblemer, konfigurasjonfeil) som må diagnostiseres, og det containeriserte miljøet legger til et lag som krever spesifikke feilsøkingsteknikker.
De grunnleggende ferdighetene — inspeksjon av logger (docker logs, vanligvis det første steget, som viser applikasjonens output og feil), sjekking av status (docker ps -a som avslører om og hvorfor en kontainer avsluttet, inkludert avslutningskoder), og undersøking av konfigurasjon/tilstand (docker inspect) — er hvordan du starter diagnostiseringen av de fleste problemer.
Å få en shell inne i en kontainer (docker exec -it ... bash) er en uvurderlig teknikk for å undersøke fra kontainerens perspektiv — inspeksjon av filer, sjekking av miljøet, og testing av tilkobling — og å vite hvordan du får en shell selv når en kontainer ikke vil holde seg kjørende (overstyre entrypointen) håndterer vanskelige tilfeller.
Å forstå vanlige problemer og deres diagnose er særlig verdifullt: kontainere som avslutter umiddelbart (hovedprosessen krasjet eller avsluttet — sjekk logger og CMD/ENTRYPOINT), tilkoblingsproblemer mellom kontainere (nettverksmedlemskap, bruk av servicenavn ikke localhost), porter som ikke er tilgjengelige (mapping, og den vanlige fellen at appen må lytte på 0.0.0.0 ikke 127.0.0.1), minnekill, og tillatelsesfeil — disse er de faktiske, gjentakende problemene som å vite hvordan du gjenkjenner og fikser sparer betydelig tid.
Siden containeriserte applikasjoner har problemer som må feilsøkes, og siden effektiv feilsøking (logger, exec inn i kontainere, inspect, og gjenkjennelse av vanlige feilmønstre) er nødvendig for å diagnostisere og løse dem, er å vite hvordan du debugger Docker-kontainere en viktig, hyppig brukt praktisk ferdighet for alle som kjører containeriserte applikasjoner, en kjernekompetanse innen operasjoner som gjør frustrerende kontainerproblemer til løsbare.