Bagaimana saya bisa men-debug inisialisasi wadah buruh pelabuhan?

Saya punya masalah dengan wadah, meskipun itu membangun dengan sempurna itu tidak dimulai dengan benar. Penyebabnya adalah solusi yang saya tambahkan ke Dockerfile (karena memiliki routing / etc / hosts yang dikonfigurasi sendiri)

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

Jelas ada beberapa kesalahan di sana, tapi saya bertanya-tanya bagaimana saya bisa mendapatkan lebih banyak info tentang apa yang dilakukan buruh pelabuhan saat berjalan. misalnya, ini berfungsi:

$ docker run image ls
usr bin ...

Tetapi ini tidak:

$ docker run image ls -l
$

Tidak ada apa pun di log dan saya juga tidak dapat memanggil shell interaktif. Saya dapat menggunakan strace untuk melihat apa yang terjadi tetapi saya berharap ada cara yang lebih baik.

Apakah ada cara saya bisa mengatur buruh pelabuhan menjadi lebih verbose?

EDIT : Terima kasih kepada Andrew D. Saya sekarang tahu apa yang salah dengan kode di atas (saya meninggalkannya sehingga jawabannya dapat dipahami). Sekarang masalahnya masih bagaimana saya bisa men-debug sesuatu seperti ini atau mendapatkan bagian dalam mengapa ls-l gagal mengapa ls tidak.

EDIT : -D = true mungkin memberikan lebih banyak output, meskipun tidak dalam kasus saya ...

eventsPerintah Docker dapat membantu dan perintah Docker log dapat mengambil log bahkan setelah gambar gagal memulai.

Pertama mulai docker eventsdi latar belakang untuk melihat apa yang terjadi.

docker events&

Kemudian jalankan docker run ...perintah gagal Anda . Maka Anda akan melihat sesuatu seperti yang berikut di layar:

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

Kemudian Anda bisa mendapatkan id hex startup dari pesan sebelumnya atau output dari perintah run. Kemudian Anda bisa menggunakannya dengan perintah log:

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

Anda sekarang akan melihat beberapa output dari startup gambar yang gagal.

Seperti yang disarankan @alexkb dalam komentar: docker events&dapat menyusahkan jika wadah Anda terus-menerus dimulai kembali dari sesuatu seperti layanan AWS ECS. Dalam skenario ini, mungkin lebih mudah untuk mengeluarkan hex ID wadah dari log /var/log/ecs/ecs-agent.log.<DATE>. Kemudian gunakan buruh pelabuhan logs <hex id>.

Nah yang terbaik yang saya temukan sejauh ini adalah:

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

Mulai saja klien dari shell baru. Kesalahpahaman adalah berpikir bahwa klien benar-benar melakukan apa saja ... yah itu hanya berkomunikasi dengan daemon, jadi Anda tidak ingin men - debug klien tetapi daemon itu sendiri (biasanya).

Dalam kasus saya, -abendera (lampirkan ke STDOUT / STDERR) sudah cukup:

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

Ini menunjukkan kesalahan startup (dalam kasus kami, jalur log yang hilang digunakan oleh supervisord). Saya berasumsi sebagian besar kesalahan startup kontainer akan muncul di sini juga.

Saya tidak bisa menjawab pertanyaan Anda tentang bagaimana membuat output buruh pelabuhan lebih lengkap tetapi saya dapat memberi tahu Anda bahwa regex di tempat mengganti string dalam file .so agak gila: string hanya memiliki begitu banyak ruang yang dialokasikan untuk itu, dan jika Anda mengubah offset file dari entri lain, file elf menjadi rusak. Coba jalankan objdump atau langsung pada file .so Anda setelah menjalankan perintah perl ( sebelum LD_LIBRARY_PATH berubah ) di luar wadah - dolar untuk donat sekarang rusak.

Alasan kerjanya dalam peretasan yang sangat diperlukan ini adalah karena "tmp" dan "dll" memiliki panjang string yang sama sehingga tidak ada perubahan offset. Pertimbangkan direktori / dkr atau sejenisnya jika Anda memilih untuk tidak menggunakan / tmp.

Jika Anda HARUS mengambil pendekatan ini dan jalur yang Anda inginkan tidak dapat diubah, buat kembali pustaka dan ubah jalur default untuk / etc / hosts di sumber. Atau lebih baik, ketika membangun modifikasi Anda ubah libnss_files.sonama menjadi sesuatu seperti libnss_altfiles.sodan ubah nsswitch.confuntuk digunakan hosts: altfilesketika memulai wadah buruh pelabuhan Anda (kecuali buruh pelabuhan telah mengikat mount nsswitch.conf juga, maka Anda tidak dapat mengubahnya). Ini akan membiarkan Anda memiliki libnss_altfiles.so secara paralel dengan perpustakaan normal Anda di sistem basis. Jika buruh pelabuhan melakukan bind-mount nsswitch.conf, tinggalkan salinan libnss_files.so yang telah Anda bangun kembali di direktori / lib-override Anda yang siap dimuat oleh LD_LIBRARY_PATH.

Sebagai kepala, binari suid / sgid mengabaikan LD_LIBRARY_PATH dan LD_PRELOAD, jadi beberapa hal akan rusak (baca: kembali menggunakan default / etc / hosts) jika Anda menggunakan variabel tersebut.

Kadang-kadang, Anda dapat menemukan pesan kesalahan yang berguna dengan menghisap simpul yang menjalankan daemon buruh pelabuhan dan kemudian melakukan:

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

Pada 'Edisi Komunitas Docker' di Mac OS, Anda dapat terhubung ke docker vm dengan melakukan:

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