@ldv я так понял по объяснению Миши, что в докер-контейнере невозможно при каждом запуске делать update_chrooted.

Соответственно остаётся только один вариант - это опционально вытащить резолвер из чрута.

Может быть такая настройка уже есть ? я просто не в курсе.

хотя не работает в любом официальном докер контейнере.

(In reply to Anton Farygin from comment #1)
> @ldv я так понял по объяснению Миши, что в докер-контейнере невозможно при
> каждом запуске делать update_chrooted.

Каждый, кто может поменять /etc/resolv.conf в контейнере, может запустить update_chrooted в нём.

может, но он про это никогда не узнает, т.к. в докере запускается приложение, а не скрипты.

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

т.е. - остаётся только патчить сам докер на этот предмет, но проблема в том, что врятли такой alt-specific патч попадёт в апстрим, а хостом для альта может быть не только альт.

(In reply to Anton Farygin from comment #4)
> может, но он про это никогда не узнает, т.к. в докере запускается
> приложение, а не скрипты.

То же самое касается и обычной системы: если приложение меняет /etc/resolv.conf, то оно должно выполнить update_chrooted conf.
Единственное, чем обычная система отличается от докера в лучшую сторону - при старте системы на всякий случай выполняется update_chrooted, а в случае с docker, как ты написал, этого не происходит.

> есть ENTRYPOINTS, но для официального образа их делать бесмысленно, т.к.
> выполняется только последний и будет перезаписан первым же Dockerfile.

Получается, что приложение, которое меняет /etc/resolv.conf, обязано выполнить update_chrooted conf самостоятельно.

Я не понимаю, как связаны nginx и update_chrooted. Может кто-нибудь объяснить?

(In reply to Alexey Shabalin from comment #7)
> Я не понимаю, как связаны nginx и update_chrooted. Может кто-нибудь
> объяснить?

update_chrooted связан с ping'ом.
Если nginx запускает ping, то nginx связан с update_chrooted, если нет, то нет.

я тоже не понимаю, но резолвинг имён uplink'ов в nginx не работает, пока не сделать update_chrooted.

А не работает он по простой причине:
/var/resolv/etc/resolv.conf - пустой.

(In reply to Anton Farygin from comment #9)
> я тоже не понимаю, но резолвинг имён uplink'ов в nginx не работает, пока не
> сделать update_chrooted.
> 
> А не работает он по простой причине:
> /var/resolv/etc/resolv.conf - пустой.

Может, спросить мантейнера nginx, каким образом nginx использует /var/resolv/etc/resolv.conf?

Можно ведь и update_chrooted conf выполнять на старте nginx, если это действительно нужно.

nginx заработал, Миша что-то поправил в образе докера для nginx.
Но ping всё ещё не работает.

Сделал для nginx специальный образ, который с помощью специального entrypoint.sh перед запуском самого nginx, запускает update_chrooted all. Но в базовом образе это безполезно делать, так как при построении новых образов от него поля ENTRYPOINT и CMD не наследуются. А напрямую задаются тем, кто делает производный образ.

да, ping у меня тоже работает с новым образом nginx.

Но проблема с базовым образом остаётся - все наши пользователи должны не забыть написать правильный entrypoint

Сделал для nginx специальный образ, который с помощью специального entrypoint.sh перед запуском самого nginx, запускает update_chrooted all. Но в базовом образе это безполезно делать, так как при построении новых образов от него поля ENTRYPOINT и CMD не наследуются. А напрямую задаются тем, кто делает производный образ.

(In reply to obirvalger@altlinux.org from comment #14)
> Сделал для nginx специальный образ, который с помощью специального
> entrypoint.sh перед запуском самого nginx, запускает update_chrooted all.

Кто-нибудь знает, зачем это нужно для самого nginx?
Мне очень не нравится, что вы вносите какие-то изменения, не понимая природы явления.

> в базовом образе это безполезно делать, так как при построении новых образов
> от него поля ENTRYPOINT и CMD не наследуются. А напрямую задаются тем, кто
> делает производный образ.

А кто, когда, и зачем меняет /etc/resolv.conf?

Дима, nginx использует обычный gethostbyname для резолвинга хостов по имени из pool'а.

(In reply to Anton Farygin from comment #16)
> Дима, nginx использует обычный gethostbyname для резолвинга хостов по имени
> из pool'а.

Обычный gethostbyname смотрит в обычные /etc/nsswitch.conf и /etc/resolv.conf,
а не в /var/resolv/.

Поэтому я и спрашиваю, что такого необычного делает nginx, что ему важно содержимое /var/resolv/.

я посмотрю попозже, сейчас мне некогда. По коду ничего такого специального не видно, надо его погонять под отладкой.

> А кто, когда, и зачем меняет /etc/resolv.conf?

Докер при запуске контейнера задает /etc/resolv.conf. Вся сеть настраивается докером снаружи, в самом контейнере не происходит настройки сети.

(In reply to obirvalger@altlinux.org from comment #19)
> > А кто, когда, и зачем меняет /etc/resolv.conf?
> 
> Докер при запуске контейнера задает /etc/resolv.conf. Вся сеть настраивается
> докером снаружи, в самом контейнере не происходит настройки сети.

Т.е. докер тупо несовместим с ALT с момента появления docker и по настоящий день?

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

(это не объясняет таинственный эффект nginx, но объясняет эффект ping)

(Ответ для Dmitry V. Levin на комментарий #20)
> Т.е. докер тупо несовместим с ALT с момента появления docker и по настоящий
> день?

Да.

я допускаю что с nginx была какая-то ещё одна проблема, не связанная с ping. Но т.к. в нашем докер контейнере есть только ping из инструментов для диагностики резолвинга, а он не работает, то я и подумал что проблема с резолвингом.

Это не отменяет необходимости сделать альт совместимым с докером. а так же с другими типами контейнеров, у которых нет процесса иникиализации и приложение запускается в изолированном окружении.