sudo без пароля в docker

Судя по Dockerfile ты хочешь чего-то странного от докера. Объясни, что ты хочешь реализовать в докере?

Ну ты недалёк от истины: задача в случае, если контейнер запущен от обычного пользователя от него же запустить демона sshd или от рута запустить процесс sshd, а потом опять вернуться в обычного юзера.

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

Eще раз перечитал stackoverflow. В общем, чел там тебе все правильно написал.

Это какое-то учебное задание или реальная задача? Просто, если нужно изолированное окружение, куда люди будут удаленно заходить лучше использовать виртуалки или LXC/LXD.

Реальная задача.

Решение непринципиально, как таковое. Главное, мне объяснить почему это невозможно в рамках архитектуры докера.

Суть в том, что контейнеры запускаются от обычного юзера.

А sshd без рут привилегий запустить нельзя, т.е. нужно или прыгнуть в рута, или забить. Но главный вопрос не как сделать, а почему нельзя сделать.

Вот.

контейнеры запускаются от обычного юзера

Щитоа?

Ну и да, буханочное троллейбусостроение итт. Ваш диагноз — человек с молотком, который теперь везде видит только гвозди. Выкинь докер, он не для этого.

Ваня, привет!

Я имел ввиду это docker exec -it -u userdev:userdev container_name /bin/bash не совсем точно выразился.

Согласен, НО, если ты читал выше с тем, что придётся выкинуть я уже смирился и осознал. Но не понял почему, где ограничение?

Именно поэтому появился данный топик.

И далее вопрос: почему при логине ssh судо отрабатывает как ожидается, а при exec - запрашивает пароль?

Разбирайся с тем, что происходит при логине по ssh и через exec. Вангую, что отличаются или параметры запуска bash, или переменные среды, или еще что-то.

Об этом я как бы сам догадываюсь, думал, что может кто-то уже сталкивался, вот в чем смысл)

Контейнер (то бишь его корневой процесс) запускается у тебя от рута. Это ты «заходишь» в него (то бишь запускаешь в нём дополнительный процесс в интерактивном режиме) от обычного юзера.

Ну и да:

1. так верстают только мудаки Dockerfile написан максимально кривожопно, 18 слоёв, 11 вызовов пакетного менеджера. ЗОЧЕМ? http://ix.io/4aLG
2. ты модифицируешь sshd_config при сборке контейнера, а потом монтируешь sshd_config при запуске. Определись.
3. УМВР, проблема неясна.

IT такое IT я уею )

а что там с PAM в контейнере? а чего ты ожидаешь?

OpenSSH в Alpine собран без PAM.

sshd в Alpine собран без PAM.

а sudo ?

1. Спасибо за замечание, ну кхм, у нас «синьор-программист» пытается пихать докер во все поля, как волшебную пилюлю, кхм… кросплатформенности (да можно гонять на arm64 докер контейнеры имиджи собранные на amd64)… мне дальше продолжать или ты сам все понял? ))

2. Так сложилось исторически, но ты прав. См. №1

3. Значит и у меня заработает. ЛОРчик все еще вдохновляет, иногда.

*докер образы, разумеется.

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

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

Иногда надо и понять, чтобы не быть похожими на «синьёров» которые… пихают докер, пихают… был бы жив Делириум сказал бы куда именно)

Спасибо за зацепки на SO, я бы это объяснял долго и нудно)

Тут еще есть такой момент, что рулится все это через docker-compose а конфигурация вида

services:
    my_api:
        user: "www-data:www-data"

Несмотря на то, что юзер www-data тоже в группе wheel при docker exec и sudo от имени веб-юзера все равно запрашивается пароль.

Не надо рыться в помойке чтоб понять что это помойка. Лучше просто обходить её стороной чтоб не заляпаться.

Неудобно, что нельзя править сообщения - это наши новые спец(!) ограничения!

sshd в докере это bad practice. Если ты так делаешь, то это грубая ошибка

кросплатформенности (да можно гонять на arm64 докер контейнеры имиджи собранные на amd64)

Это как? Кмк, вы или не поняли своего синьора или одно из двух - на x86_64 вы собираете образ для arm64? Так это нормально.

Главное, мне объяснить почему это невозможно в рамках архитектуры докера.

Возможно, но нельзя так делать. Контейнер докера должен содержать один процесс. Изредка добавляют что-то вспомогательное, но это НЕ хост. Логи вытягиваются наружу, метрики вытягиваются наружу

На него не нужно заходить по ssh, для этого есть docker exec и kubectl exec. Контейнер - это вообще короткоживущий расходник, запускается и удаляется в процессе деплоя

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

Ну на маке докер запускает qemu в режиме эмуляции. Оно тормозит дичайше, но формально работает.

Я не знаю про синьора-программиста, но то, что написано на StackOverflow - это какая-то каша, явно получившаяся из-за полного непонимания, что такое докер, и как его надо использовать.

Разработка в докере не подразумевает, что в нем запускается ssh, разрабочик входит в контейнер по ssh, и делает там свое хк-хк и в продакшн.

Это противоречит идеологии докера и тому, как с ним взаимодействуют все инструменты. Такое насилие над ним можно сделать при помощи ножа, костылей и изоленты, но это будет неудобно, и непонятно для любого человека, привыкшего работать в докере.

По хорошему, пишутся докерфайлы под каждый сервис. Один контейнер - один процесс! Например, nginx - один контейнер, Django/FastAPI - один контейнер. Как там оно в PHP, не знаю, но, наверное, php-fpm - отдельный контейнер.

Конфигурация docker-compose собирает вместе nginx, твой код, и всё остальное (postgres, там, rabbitmq или kafka, и т.д.).

При разработке используется override файл, который использует bind mount, чтобы прокинуть каталог с исходниками в контейнер, для того, чтобы можно было в своём редакторе/IDE менять файлы, и эти изменения сразу же появлялись в контейнере.

Как-то так, лень писать подробную понятную инструкцию, потому что это будет материал для статьи, и готовить его придётся несколько часов.

Короче, проблема у тебя не в докере, а в том, что ты его неправильно используешь.

Для того, что ты хочешь, надо использовать systemd-nspawn контейнеры или lxc/lxd.

На него не нужно заходить по ssh, для этого есть docker exec и kubectl exec. Контейнер - это вообще короткоживущий расходник, запускается и удаляется в процессе деплоя.

Знаю и согласен, НО на практике, у нас контейнеры могут находится на разных VPS и обычный разраб с правами на php и npm (читай веб-макака) должен в него попасть без docker exec.

В качестве возможного решения я попробовал ssh на разных портах (для каждого компонента системы), но вылез сабж)

This

Короче, проблема у тебя не в докере, а в том, что ты его неправильно используешь.

Нет, проблема именно в докере. Его вообще никак не надо использовать. Так называемая «идеология докера» изначально дефективна и представляет из себя кашу из костылей.

lxc

Это получше.

Нет, именно, что собираем arm64 на arm64, офтопик, да.

Хотя главную ошибку, что докер используется как ВМ это не устраняет… и да… я, скорей всего, буду оттудова валить, но спросить было интересно.

на практике, у нас контейнеры могут находится на разных VPS и обычный разраб с правами на php и npm (читай веб-макака) должен в него попасть без docker exec.

И это, как ни странно, снова дерьмовая практика. «Обычный разраб» должен смотреть в Git-репозиторий и работать через CI, а не ковыряться руками в рабочем окружении.

Ты не поверишь, но после облома с сабжем кто-то это понял)

Да, и это тоже совершенно неверная практика. Разраб не должен ходить в контейнеры при правильном подходе. Ни у себя на машине, ни в стейджинге, ни в проде.

Да он при любом подходе не должен ходить в них.

С самого начала видно, что есть конкретное непонимание того, как ведется разработка с использованием контейнеров. При этом, я знаю, что несмотря на то, что Docker уже около 10 лет, по нему до сих пор мало написано толковых статей, чтобы просто прочитать одну, и сразу въехать.

Но это не значит, что надо насиловать концепцию и делать всё неправильно, т.к. это хорошего результата всё равно не даст.

На самом деле, даже если отбросить докер вообще. Разработчик не должен ходить на какие-то машины по ssh и что-то там править. Это и до докера было неверным подходом к разработке.

А, действительно, хороших статей не посоветуешь?

Ну, весь мир использует, и что - все ошибаются? Лично я поработов много лет задолго до появления докера, оцениваю его как шаг вперёд. По крайней мере, для разработчиков.

Потому что вот это вот всё «Установить node версии строго 10.11, ни раньше, ни позже. Если у вас Mac OS - то ни в коем случае не через brew! Если у вас Linux, поройтесь в говне мамонта и установите строго Cent OS 7 - на более новых компилироваться не будет!» уже давно набило оскомину, и вызывает в масштабах компании огромные потери времени просто на развертывание и поддержание в рабочем состоянии окружения разработчика.

lxc вообще о другом, я не знаю, для чего он применяется, но в разработке они почти бесполезны, мне кажется.

Статьи не нужны, это ж ещё не кубер. Достаточно посмотреть на докер-файлы от популярных проектов, периодичнески справляясь в официальной документации.

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

Можно ли запустить в докере sshd от обычного пользователя?

Не для прода, а для понимания :-)

lxc… я не знаю, для чего он применяется

Как продвинутая замента chroot, билд-контейнеры и т.п.

Ну лично, я документацию Докера, в отличие от Ansible или GitLab не перевариваю… не знаю почему так)

Я тоже, но приходится обращаться к ней иногда.

Прямо хороших не знаю. Сам думаю написать, но всё как-то не хватает времени и мотивации. При этом, из IT сайтов и соц. сетей я зарегистрирован только здесь, а у LOR аудитория ничтожно маленькая.

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

В общем, да, возможно лучший способ, который не первый раз слышу - сходить на cs.github.com (новый поиск GitHub) и поискать Dockerfile и docker-compose.yml.

Я сам так делал не раз. К сожалению, надо иметь в виду, что на github также встречаются и примеры плохих Dockerfile, а чтобы отличить плохой от хорошего надо уже хорошо понимать docker. Получается замкнутый круг. Но другого способа действительно нет.

Или найти хорошего ментора, например, шарящего коллегу. У меня такой был. Ваш сеньор, если он не помог со всем этим, в докере не шарит. Или, рискну заочно предположить, не сеньор.

Ну, Вы не поняли)

Он не сеньор-девопс, он - пхп разраб, понахватался с других проектов, что если систему, бабло приносящую засунуть в докер, а докер засунуть в лямбду, а лямбду засунуть в Амазон… то можно нихера не делать и стричь денежные купоны.

За ответ спасибо!

если систему, бабло приносящую засунуть в докер, а докер засунуть в лямбду, а лямбду засунуть в Амазон… то

То это неплохой план, на самом деле.

Когда система к этому готова, то да, в теории.

А там обыкновенный говнокод на Ларавеле со всеми обвязками, кроном, supervisord и т.д.

Придётся менять подход. Например, будет соблазн запихнуть supervisord в докер, но это будет неправильно. Каждый сервис должен быть в отдельном контейнере, docker будет выполнять роль supervisord.

Уточняю, потому что видел примеры, когда впихивали supervisord в докер, увы.

И засунуть в докер большой старый проект - это отдельная нелегкая задача. Особенно, если там не использовался 12-factor подход, например, используются файлы конфигурации вместо чтения конфигурации из окруженя.

Да, Вы просто смотрите в хрустальный шар)

Но суть тут не в технологиях, а в человеческих отношениях: когда прибыль от проекта превышает некоторое пороговое психологическое значение у руководства начинается жадность + звёздная болезнь… что печально.

Называется - хачу и всё тут!!!1