Як я можу налагоджувати ініціалізацію контейнера докер?

У мене виникла проблема з контейнером, навіть якщо він ідеально створений, він не запускається належним чином. Причина - це вирішення, яке я додав до Dockerfile (для самостійної конфігурації / 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

Очевидно, там є якась помилка, але мені цікаво, як я можу отримати більше інформації про те, що докер робить під час роботи. наприклад, це працює:

$ docker run image ls
usr bin ...

Але це не так:

$ docker run image ls -l
$

У журналах немає нічого, і я також не можу викликати інтерактивну оболонку. Я можу використовувати strace, щоб побачити, що відбувається, але я сподівався, що там буде кращий шлях.

Чи є спосіб, щоб я встановив, що докер буде більш детальним?

EDIT : Завдяки Ендрю Д. Я тепер знаю, що не так з кодом, що вказаний вище (я залишив його, щоб його відповідь можна було зрозуміти). Тепер питання все ще полягає в тому, як я можу налагодити щось подібне або отримати всередині, чому ls -l не вдалося, чому ls цього не зробили.

EDIT : -D = true може дати більше результатів, але не в моєму випадку ...

eventsКоманда Docker може допомогти, і команда Docker logs може отримати журнали навіть після того, як зображення не вдалося запустити.

Спочатку почніть docker eventsна задньому плані, щоб побачити, що відбувається.

docker events&

Потім запустіть свою неспроможну docker run ...команду. Тоді ви повинні побачити щось подібне на екрані:

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

Тоді ви можете отримати шістнадцятковий ідентифікатор запуску з попереднього повідомлення або вихід команди запуску. Тоді ви можете використовувати його за допомогою команди logs:

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

Тепер ви повинні побачити деякий вихід із невдалого запуску зображення.

Як @alexkb запропонував у коментарі: docker events&може бути проблематично, якщо ваш контейнер постійно перезавантажується з чогось типу служби AWS ECS. У цьому випадку може бути простіше вивести шестигранний ідентифікатор контейнера з журналів /var/log/ecs/ecs-agent.log.<DATE>. Потім використовуйте докер logs <hex id>.

Що ж, найкраще, що я дізнався поки що:

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

Тільки запускайте клієнта з нової оболонки. Помилковою думкою було думати, що клієнт насправді робить щось взагалі ... ну це просто спілкування з демоном, тому ви не хочете налагоджувати клієнта, а сам демон (як правило).

У моєму випадку -aпрапор (прикріпити до 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

Він показав помилку при запуску (у нашому випадку - відсутній шлях журналу, який використовує supervisord). Я припускаю, що і більшість помилок при запуску контейнера відображатиметься і тут.

Я не можу відповісти на ваше запитання про те, як зробити випуск докера більш повним, але можу сказати вам, що на місці повторного вираження, що замінює рядок у файлі .so, трохи божевільно: у рядку лише виділяється стільки місця, і якщо змінити компенсацію файлу інших записів, файл ельфу пошкоджується. Спробуйте запустити objdump або readelf у вашому файлі .so після запуску команди perl ( до зміни LD_LIBRARY_PATH ) поза контейнером - долари, щоб пончики зараз пошкоджені.

Причина, по якій це працює в цьому сумно необхідному злому, полягає в тому, що "tmp" і "etc" мають однакову довжину рядка, тому жодних зрушень не змінюється. Розгляньте каталог / dkr або подібне, якщо ви не бажаєте використовувати / tmp.

Якщо ви ОБОВ'ЯЗКОВО прийняти такий підхід і бажані шляхи незмінні, відновіть бібліотеку та змініть шлях за замовчуванням для / etc / hosts у вихідному коді. А ще краще, будуючи модифікований libnss_files.soперейменуйте його на щось на зразок libnss_altfiles.soі змініть nsswitch.confдля використання hosts: altfilesпід час запуску контейнера докера (якщо докер також не прив’язаний до nsswitch.conf, його ви не можете змінити). Це дозволить вам мати libnss_altfiles.so паралельно з вашими звичайними бібліотеками в базовій системі. Якщо докер виконує прив'язку nsswitch.conf, залиште копію відновленого libnss_files.so у каталозі / lib-override, готовому до завантаження LD_LIBRARY_PATH.

Як підголовки, бічні файли suid / sgid ігнорують LD_LIBRARY_PATH та LD_PRELOAD, тому деякі речі будуть порушені (читайте: поверніться до використання типових / etc / hosts), якщо ви використовуєте ці змінні.

Іноді ви можете знайти корисні повідомлення про помилки, натиснувши в вузол, на якому працює демон-докер, і виконайте такі дії:

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

У версії "Docker Community Edition" на Mac OS ви можете підключитися до docker vm, виконавши:

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