Jak debugować i rozwiązywać problemy z kontenerami Docker?

Question

Accepted Answer

Debugowanie aplikacji w kontenerach obejmuje inspektowanie **logów**, uzyskanie dostępu do **powłoki wewnątrz kontenera**, badanie **konfiguracji i stanu** oraz diagnozę typowych problemów (awarie, problemy sieciowe, zasoby). Umiejętność rozwiązywania problemów jest niezbędnym praktycznym umiejętnością. ## Inspektowanie logów i statusu ```bash docker ps -a # see container status (running? exited? exit code?) docker logs # view the container's output (stdout/stderr) — start here docker logs -f --tail 100 # follow live, last 100 lines docker inspect # full config/state as JSON (env, mounts, network, etc.) docker events # stream Docker daemon events ``` `docker logs` jest zwykle **pierwszym krokiem** — pokazuje dane wyjściowe aplikacji i błędy. `docker ps -a` ujawnia, czy kontener się zakończył (i jego kod wyjścia). ## Uzyskanie dostępu do wnętrza kontenera ```bash # run an interactive shell inside a RUNNING container to investigate docker exec -it 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` daje powłokę wewnątrz działającego kontenera — nieocenione do inspektowania plików, sprawdzania środowiska i testowania łączności z perspektywy kontenera. ## Typowe problemy i diagnoza ```text 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 ``` ## Dlaczego to ważne Umiejętność debugowania i rozwiązywania problemów z kontenerami Docker jest niezbędnym praktycznym umiejętnością, ponieważ aplikacje w kontenerach nieuchronnie mają problemy (awarie, problemy z łącznością, błędy konfiguracji), które muszą być zdiagnozowane, a środowisko konteneryzowane dodaje warstwę wymagającą specjalnych technik debugowania. Umiejętności fundamentalne — inspektowanie **logów** (`docker logs`, zwykle pierwszy krok, pokazujący dane wyjściowe aplikacji i błędy), sprawdzanie **statusu** (`docker ps -a` ujawniające, czy i dlaczego kontener się zakończył, w tym kody wyjścia) oraz badanie **konfiguracji/stanu** (`docker inspect`) — to sposób, w jaki zaczynasz diagnozować większość problemów. Uzyskanie **powłoki wewnątrz kontenera** (`docker exec -it ... bash`) to nieoceniona technika do badania z perspektywy kontenera — inspektowanie plików, sprawdzanie środowiska i testowanie łączności — a umiejętność uzyskania powłoki nawet gdy kontener nie będzie działać (nadpisanie entrypointu) obsługuje trudne przypadki. Zrozumienie **typowych problemów i ich diagnozy** jest szczególnie wartościowe: kontenery kończą się natychmiast (główny proces uległ awarii lub zakończył się — sprawdzenie logów i CMD/ENTRYPOINT), problemy z łącznością między kontenerami (członkostwo w sieci, używanie nazw usług, a nie localhost), porty niedostępne (mapowanie i częsty błąd, że aplikacja musi nasłuchiwać na 0.0.0.0, a nie 127.0.0.1), zabicia z powodu braku pamięci i błędy uprawnień — to rzeczywiste, powtarzające się problemy, których poznanie i naprawa oszczędza znaczną ilość czasu. Ponieważ aplikacje w kontenerach mają problemy, które muszą być debugowane, a ponieważ efektywne rozwiązywanie problemów (logi, exec do kontenerów, inspect i rozpoznawanie typowych wzorców awarii) jest niezbędne do diagnozowania i rozwiązywania ich, umiejętność debugowania kontenerów Docker jest niezbędnym, często stosowanym praktycznym umiejętnością dla każdego, kto uruchamia aplikacje w kontenerach, podstawową kompetencją operacyjną, która zamieniła frustrujące problemy z kontenerami w rozwiązywalne.