Container Debugging

Excerpt:
Container debugging je proces pronalaženja problema u Docker servisima kroz logove, status container-a, mreže, portove, environment vrednosti, volume-e i samu aplikaciju koja radi unutar container-a.

Container Debugging

Container debugging počinje proverom osnovnog stanja: da li container radi, da li se stalno restartuje, da li je ugašen ili uopšte nije uspešno kreiran. Komande kao što su docker ps, docker ps -a i docker compose ps daju prvi uvid u to šta se zaista dešava.

Logovi su sledeći najvažniji korak. docker logs ili docker compose logs često odmah pokažu da li aplikacija puca zbog pogrešne konfiguracije, nedostajuće environment promenljive, problema sa bazom, zauzetog porta ili greške u samom kodu.

Kod Compose sistema korisno je gledati logove po konkretnom servisu. Ako stack ima aplikaciju, bazu, reverse proxy i worker, nije dovoljno znati da “sistem ne radi”. Potrebno je izolovati koji container pravi problem i u kom trenutku se greška javlja.

Mreža je čest izvor problema. Aplikacija možda radi, ali ne može da dođe do baze ili drugog servisa. Tada treba proveriti da li su container-i na istoj Docker mreži, da li se koriste ispravni service name-ovi i da li aplikacija pokušava da se poveže na pogrešan host ili port.

Environment promenljive često izazivaju greške koje nisu odmah očigledne. Pogrešan database URL, secret key, API token, domen, webhook URL ili production flag može napraviti problem koji izgleda kao aplikacioni bug, a zapravo je konfiguracioni problem.

Port mapping treba proveriti pažljivo. Važno je razlikovati port koji aplikacija koristi unutar container-a od porta koji je mapiran na host server. U produkcionom setup-u često nije potrebno javno izlagati aplikacioni port, već je dovoljno da ga vidi reverse proxy.

Volume-i i permisije takođe mogu izazvati probleme. Aplikacija može raditi, ali ne može da upiše fajl, pristupi upload folderu, pročita konfiguraciju ili koristi data directory baze. U takvim slučajevima problem nije u kodu, već u storage ili permission sloju.

Ponekad je potrebno ući direktno u container. Komande kao što su docker exec -it container_name sh ili bash omogućavaju proveru fajlova, environment vrednosti, mrežnih konekcija i procesa iznutra. To je korisno kada spoljašnji logovi nisu dovoljni.

Kod reverse proxy problema treba proveriti i proxy i aplikaciju. Greška 502 često znači da proxy radi, ali ne može da dođe do internog servisa. Tada treba proveriti da li je aplikacija pokrenuta, da li sluša pravi port, da li je na pravoj mreži i da li proxy ruta pokazuje na ispravan service name.

Dobar container debugging nije nasumično restartovanje svega, već sistematsko sužavanje problema. Kada se redom provere status, logovi, mreža, portovi, environment vrednosti, volume-i i aplikacioni sloj, Docker problemi postaju mnogo lakši za razumevanje i stabilno rešavanje.