Felsökning av containeriserade applikationer innebär att inspektera loggar, få en shell inuti behållare, undersöka konfiguration och tillstånd, och diagnostisera vanliga problem (krascher, nätverk, resurser). Att kunna felsöka är en väsentlig praktisk färdighet.
docker ps -a
docker logs <container>
docker logs -f -- 100 <container>
docker inspect <container>
docker events
docker logs är vanligtvis det första steget — det visar programmets utmatning och fel. docker ps -a avslöjar om en behållare avslutades (och dess avslutningskod).
# 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 ger en shell inuti en körande behållare — ovärderlig för att inspektera filer, kontrollera miljön och testa anslutningen från behållarens 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
Att veta hur man felsöker och löser problem med Docker-behållare är en väsentlig praktisk färdighet, eftersom containeriserade applikationer oundvikligen har problem (krascher, anslutningsproblem, konfigurationsfel) som måste diagnostiseras, och miljön för containerisering lägger till ett lager som kräver specifika felsökningstekniker.
De grundläggande färdigheterna — att inspektera loggar (docker logs, vanligtvis det första steget, som visar programmets utmatning och fel), kontrollera status (docker ps -a som avslöjar om och varför en behållare avslutades, inklusive avslutningskoder), och undersöka konfiguration/tillstånd (docker inspect) — är hur du börjar diagnostisera de flesta problem.
Att få en shell inuti en behållare (docker exec -it ... bash) är en ovärderlig teknik för att undersöka från behållarens perspektiv — inspektera filer, kontrollera miljön och testa anslutningen — och att veta hur du får en shell även när en behållare inte förblir igång (åsidosätta entrypoint) hanterar knepiga fall.
Att förstå vanliga problem och deras diagnos är särskilt värdefullt: behållare som avslutas omedelbar (huvudprocessen kraschade eller slutfördes — kontrollera loggar och CMD/ENTRYPOINT), problem med inter-behållarkonnektivitet (nätverksmedlemskap, använd tjänstnamn inte localhost), portar som inte är tillgängliga (mappning, och det vanliga problemet att appen måste lyssna på 0.0.0.0 inte 127.0.0.1), OOM-avslutningar och behörighetsproblem — dessa är de verkliga, återkommande problemen som att veta hur man identifierar och åtgärdar sparar betydande tid.
Eftersom containeriserade applikationer har problem som måste felsökas, och eftersom effektiv felsökning (loggar, exec in i behållare, inspect och att känna igen vanliga felsmönster) är nödvändig för att diagnostisera och lösa dem, är det väsentligt att veta hur man felsöker Docker-behållare, en ofta tillämpad praktisk färdighet för alla som kör containeriserade applikationer, en grundläggande operativ kompetens som gör frustrerande behållarproblem till lösbara.