Jak mogę debugować inicjalizację kontenera dokowanego?

Miałem problem z kontenerem, mimo że buduje się doskonale, nie uruchamia się poprawnie. Przyczyną jest obejście, które dodałem do pliku Docker (za samodzielne skonfigurowanie routingu / etc / hosts)

RUN mkdir -p -- /lib-override /etc-override && cp /lib/libnss_files.so.2 /lib-override
ADD hosts.template /etc-override/hosts
RUN perl -pi -e 's:/etc/hosts:/etc-override/hosts:g' /lib-override/libnss_files.so.2
ENV LD_LIBRARY_PATH /lib-override

Oczywiście jest tam jakiś błąd, ale zastanawiam się, jak mogę uzyskać więcej informacji o tym, co robi doker podczas pracy. na przykład to działa:

$ docker run image ls
usr bin ...

Ale to nie:

$ docker run image ls -l
$

W dziennikach nie ma nic i nie mogę też wywołać interaktywnej powłoki. Mogę użyć strace, aby zobaczyć, co się dzieje, ale miałem nadzieję, że jest lepszy sposób.

Czy jest jakiś sposób, aby ustawić dokera tak, aby był bardziej szczegółowy?

EDYCJA : Dzięki Andrew D. Teraz wiem, co jest nie tak z powyższym kodem (zostawiłem go, aby jego odpowiedź była zrozumiała). Problem wciąż polega na tym, jak mogę debugować coś takiego lub dowiedzieć się, dlaczego ls -l nie powiodło się, dlaczego ls nie.

EDYCJA : -D = prawda może dać więcej wyników, choć nie w moim przypadku ...

eventsPolecenie Docker może pomóc, a polecenie Docker logs może pobierać dzienniki nawet po nieudanym uruchomieniu obrazu.

Najpierw zacznij docker eventsw tle, aby zobaczyć, co się dzieje.

docker events&

Następnie uruchom swoje nieudane docker run ...polecenie. Następnie powinieneś zobaczyć na ekranie coś takiego:

2015-12-22T15:13:05.503402713+02:00 xxxxxxxacd8ca86df9eac5fd5466884c0b42a06293ccff0b5101b5987f5da07d: (from xxx/xxx:latest) die

Następnie możesz uzyskać startowy identyfikator szesnastkowy z poprzedniego komunikatu lub danych wyjściowych polecenia uruchamiania. Następnie możesz użyć go z poleceniem logs:

docker logs <copy the instance id from docker events messages on screen>

Powinieneś teraz zobaczyć wyjście z nieudanego uruchomienia obrazu.

Jak sugeruje @alexkb w komentarzu: docker events&może być kłopotliwy, jeśli kontener jest ciągle restartowany z czegoś takiego jak usługa ECS AWS. W tym scenariuszu łatwiejsze może być pobranie identyfikatora szesnastkowego kontenera z dzienników /var/log/ecs/ecs-agent.log.<DATE>. Następnie użyj dokera logs <hex id>.

Cóż, jak do tej pory dowiedziałem się:

#stop the current demon and start it in debug modus
sudo service docker stop
dockerd -D # --debug

Wystarczy uruchomić klienta z nowej powłoki. Błędnym założeniem było myślenie, że klient faktycznie robi cokolwiek ... cóż, to po prostu komunikuje się z demonem, więc nie chcesz debugować klienta, ale sam demon (normalnie).

W moim przypadku -awystarczyło (dołączyć do STDOUT / STDERR):

user@machine:~$ docker start -a server_name
Error: The directory named as part of the path /log/log_path/app.log does not exist.
For help, use /usr/bin/supervisord -h

Pokazał błąd uruchamiania (w naszym przypadku brakującą ścieżkę dziennika używaną przez supervisord). Zakładam, że pojawi się tutaj także większość błędów uruchamiania kontenera.

Nie mogę odpowiedzieć na twoje pytanie, jak sprawić, by dane wyjściowe dokera były bardziej kompletne, ale mogę powiedzieć, że wyrażenie regularne zastępujące ciąg w pliku .so jest nieco szalone: ​​ciąg ma tylko tyle miejsca na to, i jeśli zmienisz przesunięcie pliku innych wpisów, plik elfa zostanie uszkodzony. Spróbuj uruchomić objdump lub readelf w pliku .so po uruchomieniu komendy perl ( przed zmianą LD_LIBRARY_PATH ) poza kontenerem - dolary na pączki są teraz uszkodzone.

Powodem, dla którego działa w tym niestety niezbędnym hacku, jest to, że „tmp” i „etc” mają taką samą długość łańcucha, więc żadne przesunięcia się nie zmieniają. Rozważ katalog / dkr lub podobny, jeśli wolisz nie używać / tmp.

Jeśli MUSISZ zastosować to podejście, a żądane ścieżki są niezmienne, przebuduj bibliotekę i zmień domyślną ścieżkę dla / etc / hosts w źródle. Lub lepiej, gdy budujesz zmodyfikowaną libnss_files.sonazwę, zmień jej nazwę na coś podobnego libnss_altfiles.soi zmień ją, nsswitch.confaby użyć hosts: altfilespodczas uruchamiania kontenera dokowania (chyba że doker wiąże również zamontowany plik nsswitch.conf, to nie możesz go zmienić). To pozwoli ci mieć plik libnss_altfiles.so równolegle z normalnymi bibliotekami w systemie podstawowym. Jeśli doker dokona instalacji pliku nsswitch.conf z plikiem bind, pozostaw kopię odbudowanego pliku libnss_files.so w katalogu / lib-override gotowym do załadowania przez LD_LIBRARY_PATH.

Jako heads up, pliki binarne suid / sgid ignorują LD_LIBRARY_PATH i LD_PRELOAD, więc niektóre rzeczy się zepsują (czytaj: wróć do korzystania z domyślnego / etc / hosts), jeśli użyjesz tych zmiennych.

Czasami przydatne komunikaty o błędach można znaleźć, wysyłając ssh do węzła uruchamiającego demona dokera, a następnie:

$ tail -f /var/log/containers/* /var/log/docker.log 2>&1

W wersji „Docker Community Edition” w systemie Mac OS można połączyć się z vm dokera, wykonując:

$  screen ~/Library/Containers/com.docker.docker/Data/vms/0/tty