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

Нет, как замена линукс-виртуалкам на линукс-хосте.

Ну, весь мир использует, и что - все ошибаются?

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

Потому что вот это вот всё

Во-первых, подобные требования уже признак дефективного процесса. Во-вторых, если от дефективного процесса, ломающегося от шага в сторону, не деться (ну, наняли дешёвую рабочую силу, а на больше денег не выделяют), то упомянутые проблемы с версиями решаются как раз таки одним бинарным контейнером, в котором всё предсобрано компетентными людьми. Обновлять его можно централизованно инкрементально. Ну, а если нет денег даже на тех кто это сделает, то да - остаётся абы как, копипастя гайды из интернета, хоть докером хоть чем ещё (про что первая статья найдётся) пытаться привети всё в рабочее состояние.

Во-первых, подобные требования уже признак дефективного процесса. Во-вторых, если от дефективного процесса, ломающегося от шага в сторону, не деться (ну, наняли дешёвую рабочую силу, а на больше денег не выделяют)

Не всё так просто. В реальном мире существует масса реальных ограничений. У разработчиков и клиентов зоопарк разных версий ОС и разного софта в них. При этом централизованно заставить всех сидеть в одной и той же ОС с одним и тем же окружением невозможно. Даже у маководов есть две версии ОС: для Intel и для Mac, в которых многое между собой несовместимо.

Потом, мы делаем софт для реального мира, в котором есть свои требования. Например, современные протоколы, современные системы развертывания, мониторинга. Мы можем их всех ненавидеть за косорукость и писать мир с нуля, как fossil (у которого даже название говорящее), но нам за эти колоссальные усилия никто не заплатит.

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

Ну и до кучи: про наняли дешевую рабочую силу, очень высокомерно и оторвано от жизни звучит. А где ее взять на всех, квалифицированную? Она на улице не валяется, а обычно очень хорошо пристроена и хочет за переход таких денег, которые, наверное, сделают бизнес нерентабельным. И в любом случае, опыт показывает, что хорошие разработчики/админы - очень малочисленный конечный ресурс. На всех его в любом случае не хватит, и его всегда сможет высосать пылесосом условный FAANG, сидящий на печатном станке, и благодаря этому имеющий возможность скупить все сливки разрабов cо всего мира.

Но остальным бизнесам тоже жить хочется. И остальным, менее квалифицированным разработчикам, тоже хочется кушать.

Реальные ограничения и «ломаться от шага в сторону по минорной версии чего-то» это разные вещи. Второе это именно результат чьей-то некомпетентности. Либо того, что написал ворох костылей, рассыпающийся от малейшего шага в сторону, либо того, кто выбрал использовать библиотеку, авторы которой не имеют понятия о поддержке хоть какой-то совместимости между минорными версиями.

А где ее взять на всех, квалифицированную?

Я бы предпочёл, чтобы никакую нигде не брали, чем плодили подобные проекты. Разумеется, есть эти факторы

тоже жить хочется

тоже хочется кушать

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

-----------

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

Что мусорного в докере? Чем аккуратно предсобранный и обновляемый файл docker-compose.yml хуже твоего варианта?

Тем что он предполагает

1) выполнение кучи ненужных действий на стороне конечного пользователя (а ещё от синтаксиса Dockerfile несёт костылями за километр, но это уже эстетическое)

2) накладывает идеологические ограничения на то, как именно всё собирать

3) всё это поддерживается софтом который без нужды раздут

Да, пункты 1 и 2 можно нейтрализовать, просто собрав готовый архив и дав его в виде образа, выкинув таким образом весь функционал Dockerfile и почти весь docker-compose (т.к. образ всего один и их не надо друг с другом собирать), но: 1) зачем нужен весь этот софт если мы им не пользуемся? 2) набегут всякие «ты неправильно используешь докер», что вобщем-то справедливо, он предполагался не для этого а для сборки блоатварей

Кстати, насколько правильно гонять cron в докере?

От крон-задач тоже тяжело избавиться, какие есть альтернативы?

Вообще неправильно. Я не знаю, как к этому подходят в PHP. В python мире традиционно используют очередь задач и celerybeat, который дергает эти задачи по расписанию. Есть и более простые аналоги celerybeat.

Думаю, что общее решение:

1. Написать/использовать какое-то кастомное решение, дергающее задачи с заданной периодичностью. Судя по тому, что для Python таких написано несколько, потребность есть, и они используются.
2. Если одна периодическая задача, то просто сделать контейнер, в котором она дергается псевдокодом вида while true; do task && sleep 1h; done
3. Можно из cron/systemd timer дергать задачу в докере (docker run --rm smth)
4. В Kubernetes вроде бы есть встроенные таймеры, но я в kubernetes почти не шарю.

Кстати, насколько правильно гонять cron в докере?

Выше ответили.

Просто ремарка, утрированно, относитесь к докер-контейнеру (естественно с его полезной нагрузкой) как к «простому» приложению или сервису. Это снимет многие вопросы.

В Kubernetes вроде бы есть встроенные таймеры

Есть СronJob’ы, которые по таймеру создают экземпляры контейнеров, цель которых отработать и закрыться.

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

Конечно можно, хоть в докере докера докера под lxc )

Главное чтоб процессу прав хватило, на конфиг, порт, логи, etc

От крон-задач тоже тяжело избавиться, какие есть альтернативы?

сменить архитектора )

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

а что такое вкусное в этой лямбде? oversell by design?

за те же деньги можно брать в 10 раз более мощные vps в dc tier-1

ну или десяток в dc tier 3/4 )

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

Почему? В чем проблема если разраб для отладки прямо на проде идет через хост + exec sh? Для скриптовых языков это даёт возможность добавлять вызовы логера (printf-отладка). Можно запускать внутриконтейнерные утилиты вручную, чтобы понять, почему не работает. Можно сделать curl оттуда (и будет использоваться его ip-адрес). Можно смотреть содержание логов, которые не вынесены из writable layer, работать с кешем оставленным во writable layer.

Локальный полученный из того же образа контейнер запущен с другим env и может вести себя иначе. Кроме того, он натравлен на другую БД, другие URL-веб-сервисов, другие учетные записи, он имеет другой ip исходящих из него запросов, у него другое состояние writable layer.

В чем проблема если разраб для отладки прямо на проде идет через хост + exec sh?

похоже, в менеджменте )

Почему?

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

Именно.

Хотя, похоже, что я нашел ошибку. Тестить пока мне лень)