Nie można zapisać do pliku / etc / hosts z Dockerfile za pomocą RUN

9

Tworzę obraz dokera przy użyciu dość prostego pliku Docker. Wewnątrz pliku Docker mam następujące polecenie:

RUN printf "192.92.13.243 www.hahaha.com \n" >> /etc/hosts

Samo polecenie wydaje się być w porządku, ponieważ tworzenie obrazu nie zatrzymuje się w tym momencie.

Problem w tym, że: Podczas uruchamiania obrazu nie ma tam wiersza, który powinien zostać wstawiony do „/ etc / hosts”.

Teraz rozejrzałem się i odkryłem, że przed wersją 1.2 dokera pojawił się problem z plikiem hosts w kontenerach. W moim przypadku używam najnowszej wersji 1.5.

Czy coś brakuje?

AKTUALIZACJA 1:

Wydaje się, że jest wiele problemów, zarówno otwartych, jak i zamkniętych, na stronach github w oknie dokera.

dlyk1988
źródło

Odpowiedzi:

12

Działa to w oknie dokowanym 1.7.0

RUN echo "192.168.11.112 myhost" >> /etc/hosts && wget http://myhost

Sztuką jest dodanie nazwy hosta w tym samym wierszu, w którym jest używana, w przeciwnym razie plik hosts zostanie zresetowany, ponieważ każda komenda RUN uruchamia nowy kontener pośredni. Na przykład to nie zadziała :

RUN echo "192.168.11.112 myhost" >> /etc/hosts
RUN wget http://myhost
jonatan
źródło
1
Dzięki za wgląd! Mimo że jest poprawny (sprawdziłem) i ogólnie przydatny, w tym przypadku nie ma dla mnie większego znaczenia. Potrzebuję wypełnić plik „hosts” podczas działania kontenera.
dlyk1988
2
+1 za uruchamianie poleceń w tym samym wierszu
myol
7

Po napisaniu aktualizacji do mojego pytania postanowiłem jeszcze raz rzucić okiem na „problemy” otwarte w github. Okazuje się, że zastosowano obejście:

docker run ... --add-host='server:0.0.0.0' ...

Za pomocą argumentu „--add-host ...” podczas uruchamiania kontenera można zmodyfikować plik hosts.

dlyk1988
źródło
5
Chcę jednak móc to zrobić w kompilacji. Osoba prowadząca kontener nie powinna wiedzieć o hostach wewnętrznych. Ma zero sensu!
samsamm777,
I echo @ samsamm777. Zastanawiasz się, czy jest na to dobry sposób?
Jonathan
To naprawdę bardzo zaskakujące zachowanie, które nigdy nie jest dobrym pomysłem w systemach IT.
Torsten Bronger,