Почему файл/etc/hosts пуст в контейнере для докеров?

Question

Я создал минимальный контейнер для докеров, следующий за https://github.com/snoyberg/haskell-scratch, содержащий одно приложение Haskell. При запуске приложение работает отлично, за исключением того, что оно не может разрешать хосты от /etc/hosts, потому что оно пустое, что означает, что ссылка не работает правильно (или, по крайней мере, мне нужно использовать числовые адреса, которые непрактичны ...).

Я вижу файл, указанный в HostsPath в конфигурации контейнера, правильно заполнен, но кажется, что он перезаписывается в какой-то момент, когда начинается контейнер.

версия для докеров 1.6.2 на Mac OS X Yosemite.

Контейнер построен в несколько этапов. Первый этап строит контейнер со специально заселенной файловой системы:

FROM ubuntu:trusty 
MAINTAINER arnaud@capital-match.com 

RUN apt-get install -qqy libgmp-dev netbase 

ADD ./

RUN chmod +x /create_rootfs.sh 
RUN /create_rootfs.sh 

файл create_rootfs.sh содержит следующее:

#!/bin/sh 

ROOTFS=/rootfs 

echo "Creating directories" 

mkdir -p /rootfs/bin 
mkdir -p /rootfs/lib 
mkdir /rootfs/lib/x86_64-linux-gnu 
mkdir /rootfs/lib64 
mkdir -p /rootfs/usr/lib/x86_64-linux-gnu/gconv 
# mkdir -p /rootfs/etc 

echo "Copying library files" 

cp -L /bin/sh /rootfs/bin/ 
#cp -L /etc/protocols /rootfs/etc 
#cp -L /etc/services /rootfs/etc 
cp -L /lib/x86_64-linux-gnu/libc.so.6 /rootfs/lib/x86_64-linux-gnu/ 
cp -L /lib/x86_64-linux-gnu/libdl.so.2 /rootfs/lib/x86_64-linux-gnu/ 
cp -L /lib/x86_64-linux-gnu/libm.so.6 /rootfs/lib/x86_64-linux-gnu/ 
cp -L /lib/x86_64-linux-gnu/libpthread.so.0 /rootfs/lib/x86_64-linux-gnu/ 
cp -L /lib/x86_64-linux-gnu/libutil.so.1 /rootfs/lib/x86_64-linux-gnu/ 
cp -L /lib/x86_64-linux-gnu/librt.so.1 /rootfs/lib/x86_64-linux-gnu/ 
cp -L /lib/x86_64-linux-gnu/libz.so.1 /rootfs/lib/x86_64-linux-gnu/ 
cp -L /lib/x86_64-linux-gnu/libnss_files.so.2 /rootfs/lib/x86_64-linux-gnu/ 
cp -L /lib/x86_64-linux-gnu/libnss_dns.so.2 /rootfs/lib/x86_64-linux-gnu/ 
cp -L /lib/x86_64-linux-gnu/libresolv.so.2 /rootfs/lib/x86_64-linux-gnu/ 
cp -L /lib64/ld-linux-x86-64.so.2 /rootfs/lib64/ 
cp -L /usr/lib/x86_64-linux-gnu/gconv/UTF-16.so /rootfs/usr/lib/x86_64-linux-gnu/gconv/ 
cp -L /usr/lib/x86_64-linux-gnu/gconv/UTF-32.so /rootfs/usr/lib/x86_64-linux-gnu/gconv/ 
cp -L /usr/lib/x86_64-linux-gnu/gconv/UTF-7.so /rootfs/usr/lib/x86_64-linux-gnu/gconv/ 
cp -L /usr/lib/x86_64-linux-gnu/gconv/gconv-modules /rootfs/usr/lib/x86_64-linux-gnu/gconv/ 
cp -L /usr/lib/x86_64-linux-gnu/gconv/gconv-modules.cache /rootfs/usr/lib/x86_64-linux-gnu/gconv/ 
cp -L /usr/lib/x86_64-linux-gnu/libgmp.so.10 /rootfs/usr/lib/x86_64-linux-gnu/ 

Затем экспортировать содержимое этой файловой системы построения запустить capitalmatch в

Docker/tinybuilder tar -cC/rootfs. | docker import - capitalmatch/tiny

Окончательный контейнер построен из «крошечного», добавив некоторые файлы .tar.gz. Затем запускается следующим образом:

docker run --link stunnel:monitor capitalmatch/app 

stunnel контейнер работает как:

docker run --name=stunnel -p 5555:5555 -v $(pwd)/stunnel:/etc/stunnel capitalmatch/stunnel 

Я ожидаю, что /etc/hosts содержит запись для monitor, который действительно имеет место, прежде чем он будет установлен. Когда я запускаю другой контейнер, построенный более «классическим» способом, например. основанный на файле ubuntu:trusty, I found the/etc/hosts`, который будет правильно заполнен, и все работает нормально, поэтому я подозреваю, что именно так создается контейнер, который мешает.

Answer 1

У меня нет ответа, но у меня есть обходной путь: использовать

FROM busybox 
... 

и все работает нормально.

Answer 2

/etc/hosts восстанавливается каждый раз, когда вы используете свой контейнер.

Кроме того, если вы поместите что-то в этот файл в файл Dockerfile, это продлится до конца процесса построения всех слоев, но будет уничтожено, когда контейнер будет запущен.

Редактирование сетевых конфигурационных файлов

Начиная с Докер v.1.2.0, теперь вы можете редактировать/и т.д./хосты,/и т.д./имя хоста и /etc/resolve.conf в запущенном контейнере. Это полезно, если вам нужно установить bind или другие службы, которые могут переопределить один из этих файлов.

Обратите внимание, что изменения этих файлов не будут сохраняться при фиксации докеров и не будут сохраняться во время выполнения докеры. Это означает, что они не будут сохранены в изображении и не будут сохраняться при перезапуске контейнера; они будут «вставлять» в запущенный контейнер.

источник: https://docs.docker.com/articles/networking/#editing-networking-config-files

Если ваш /etc/hosts файл в контейнере не содержит ожидаемых записей, это означает, что, вероятно, вы не инициализировать контейнер правильно.

Просьба предоставить информацию о том, как вы фактически запускаете свои контейнеры или для упрощения, только что подготовленный файл docker-compose.yml.