Скорее всего уже есть образ с bind где нибудь, посмотри как там entrypoint сделан

Cmd named должно хватить

понял,сейчас посмотрю на примере.спасибо

CMD /usr/sbin/named -f с таким запуском сработало!) спасибо огромное за подсказки

а как вы решаете соответсвие в хост системе и в контейнерах id юзеров и групп, под которыми запущены процессы в контейнерах? чтобы корректно отображалось в том же htop

Привет, есть вопрос - мне надо получить из контейнера доступ к сетевым интерфесам хоста (их состояниям), собирать контейнер с опцией -v /sys:/host/sys:ro это очень плохо и не надо так никогда делать, или, в целом, допустимо?

а как вы решаете соответсвие в хост системе и в контейнерах id юзеров и групп, под которыми запущены процессы в контейнерах? чтобы корректно отображалось в том же htop

А не нужно мониторить htop, для этого есть другие инструменты для мониторинга докера)

А не нужно мониторить htop, для этого есть другие инструменты для мониторинга докера)

ну в хост системе может быть не только докер например. и при выводе htop процесс который в контейнере крутится допустим под юзером bind, в хост системе отображается под systemd-network

Так у этих процессов докер родительский из сразу видно

Ну а если хочется эстетики то пересобирать контейнер и в докерфайлах указывать конкретный uid у юзеров

мне чисто эстетически приятно видеть корректное имя под которым процесс запущен в контейнере, а не то что совпало в хост системе)

Ну а если хочется эстетики то пересобирать контейнер и в докерфайлах указывать конкретный uid у юзеров

а если эти юзеры создаются в процессе установки пакета? его же не будет в хост системе

будет id получается

Да

Ну тогда все контейнеры чтобы работали от рута

Он то точно есть

нельзя ли примаунтить /etc/passwd /etc/group к контейнеру с хост системы перед установкой пакета?

чтобы в него юзеры из контейнеров добавлялись

И все это ради эстетики?)

Ну чет такой себе патерн

я просто до докера в чруте так делал)

Мне кажется проще во всех контейнерах указывать user root

При сборке

безопасность не пошатнет? вдруг из контейнера найдут выход на поверхность)

Если ты не будешь прокидывать туда passwd и прочие извращения, то не найдут)

))

Ну и если контейнеры по правильному принципу работают: 1 процесс - 1 контейнер , то никак не должно афектить безопасность, и работу других контейнеров

да, так и делаю

насчет рута понял, спасибо за совет)

пойду извращаться

Омг, как же скучно я живу))

привет ребят

docker run -it —rm —network host alpine ash

почему, я могу делать ping 8.8.8.8

вроде же, host это только only host ?

нет

https://docs.docker.com/network/host/

Как тогда сделать only host?

А что нужно? Сеть общая с хостом но без интернетов?

А что нужно? Сеть общая с хостом но без интернетов?

именно

именно

создай отдельную сетку и запрети из нее ходить наружу

создай отдельную сетку и запрети из нее ходить наружу

а тип сети какйо должен быть ?

честно вообще не сталкивался еще

честно вообще не сталкивался еще

Бридж мне кажется https://docs.docker.com/network/bridge/

Допустим, бридж. Но как я вижу, по дефолту контенеры с ним тоже имеют доступ в интернет

Каким образом запретить доступ в интернет? Возможно, лучше использовать сеть none и прокинуть нужные порты? есть возможность прокинуть не из наружи во внутрь, а наоборот, из нутри контейнера наружу?

такая сеть есть по умолчанию...

такая сеть есть по умолчанию...

какая такая? У вас тут принято общатся односложными предложениями? Я знаю, что есть сеть none, но если спользовать ее то нужно дать ответ на вторую часть вопроса, а именно как дать возможность из контейнера подключится к одному порту на хосте

когда запускаете контейнер - вы какие сети видите на контейнере в ifconfig?

через что запускаете контейнер? не пользуетесь случайно cloud.docker.com?

запускаю просто docker run

потому что если запускать через облако - устанавливается отдельный контейнер и прописывается сеть weave в которой все контейнеры доступны друг другу

если сами запускаете - определите при запуске или в докер-композе сети и будет вам сеть

inet addr:172.17.0.2 Bcast:0.0.0.0 Mask:255.255.0.0 и локал хост

из контейнера будет видна в ifconfig

да, но как запретить доступ в интернет

из контейнера?

да

только хост

это и был вопрос

какая ось в контейнере?

docker run -it —rm —name tmp_default alpine ash

alpine

но в принцепе могу юзать любую

в контейнере запусти ifdown eth0 - посмотри если сеть отключится такой командой

ну и гугл может помочь - https://stackoverflow.com/questions/47001200/restrict-internet-access-to-docker-container

в контейнере запусти ifdown eth0 - посмотри если сеть отключится такой командой

так я смысла не пойму, ну отлючится и че ?я же к хосту тоже не смогу получить доступ

ну и гугл может помочь - https://stackoverflow.com/questions/47001200/restrict-internet-access-to-docker-container

вот, это уже похоже на правду. щас проверю и отпишусь!

Отлично, работает

спасибо всем. Не знаю почему не смог найти этот ответ

покажи ip ro в контейнере, что выводит?

default via 10.1.1.1 dev eth0 10.1.1.0/24 dev eth0 scope link src 10.1.1.2

т.е. дефолтный роут оставляет, а интернет отключает?

т.е. дефолтный роут оставляет, а интернет отключает?

интернета нету на уровен докера

грубо говоря, не происходит nat для пакетов из этой сети

нашел еще решение, если сеть для контейнеров построена через —network host

docker run —network host —cap-add=NET_ADMIN -it debian:stretch bash а потом внутри контейнера просто удалять дефолтный роут ip route del default

docker run —network host —cap-add=NET_ADMIN -it debian:stretch bash а потом внутри контейнера просто удалять дефолтный роут ip route del default

да, это решение приходило мне в голову, но по факту что мешает потом вернуть потом дефаул вей, если нехоерошее приложение захочет в сеть

ну можно рутом только вернуть, а приложение запустить изпод пользователя. или о ком речь, кто может вернуть -я не очень понял

ну можно рутом только вернуть, а приложение запустить изпод пользователя. или о ком речь, кто может вернуть -я не очень понял

ну как вариант тоже сойдет