а нужны ли мне эти ваши docker-контейнеры?

Как без докера ты сможешь гарантировать, что у тебя тестовое окружение соответствует prod'у?

Тестовое окружение никогда не будет соответствовать проду, если у тебя только не сайт-визитка. Как минимум потому, что на проде другие данные (они тоже могут влиять на баги). Это и тот факт, что на проде тупо другое железо и другие нагрузки, могут внести намного больше разницы в работе, чем выдуманные докеропроблемы. Кстати, не мог бы ты уточнить какие именно?

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

Или как ты изолировать будешь сервисы?

Это у тебя карго-культ такой - «изолировать сервисы»? Что ты под это фразой понимаешь вообще? Если речь о том чтобы один сервис, будучи взломан или из-за бага, не смог испортить файлы другому - то во всех нормальных ОС для этого с начала времён есть такая штука как uid.

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

Нет никаких объективных причин бояться докера на проде. Это давно стабильная технология, которой пользуются очень многие. Дальше - только кубернетес.

Контейнер - это обычный человеческий процесс запущенный в некотором namespace. Его не надо бояться самого по себе.

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

Хочешь ли ты чтобы обновление SQL-сервера обновляло также и Java-приложение? Будут ли оба Java-приложения обновлять зависимости одновременно или одно будет на java 11, а второе на java 13?

Как ты собираешься тестировать каждое из приложений?

Сколько у тебя серверов и что ты будешь делать когда посыпется диск на одном из них?

И много других подобных вопросов.

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

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

на базе одного и того же образа

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

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

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

Это не обязательно, но проще следить за одним базовым образом и своевременно его обновлять. Плюс сэкономишь место локально и при развертывании. Базовый слой будет общим, а разница только в «тонком» слое с кодом и настройками приложения поверх.

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

Зачем так о человеке сразу думать, он же просто вопрос задал, а не про чьё-то раздвоение личности размышляет.
Тут а нужны ли мне эти ваши docker-контейнеры? (комментарий) чётко написано кто что будет делать.

Или здесь принято давать космической глупости советы типа делать одному человеку два приложения самому для себя, одно на яве 11 и второе параллельно тут же на яве 13?
Где учат такому прогрессивно-когнитивно-раздвоенному девелопменту?

А теперь без докера даже nginx никто не поднимает? Тут полтора землекопа сущности описано, и половина из нужного это certbot (который захочет, простигосподи, в снап ну и понеслась, да, жги господь).

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

проще следить за одним базовым образом и своевременно его обновлять

Хороший аргумент.

Плюс сэкономишь место локально и при развертывании. Базовый слой будет общим, а разница только в «тонком» слое с кодом и настройками приложения поверх.

Это тоже плюс, но, мне кажется, в идеале надо стремиться к чему-то типа https://github.com/GoogleContainerTools/distroless Тогда это всё становится не слишком важно.

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

Это давно стабильная технология,

Это просто лишняя сущность (причём выглядящая крайне костыльно). На проде не должно быть лишних сущностей.

А у разработчиков по возможности подстраиваться

Чтобы платить им ещё больше? Одобряю твой подход.

На проде не должно быть лишних сущностей.

Ты их много видел? Kubernetes лезет даже в IoT, с разморозкой.

Ок, предположим я отделил БД от докера и крутится она у меня локально. Есть ли адекватные способы прокинуть локальный порт в докер-контейнер?

Нет, ты не понял концепцию. Ты НЕ заморачиваешься этой ерундой. Надо для для теста базу, ок, сунь докер с базой в docker-compose. Надо для высоконагруженного прода базу, ок, забирай SQL у ,например, гугла. через sidecar sql-proxy. Или с какого-то гипотетического сервера баз данных. Это просто кирпичи, из которых собирается весь сервис. Главное, чтобы твой апп умел кушать конфиг с указанием, куда лезть за базой. База это не часть приложения, это сервис. Так же как и nginx или ssl или еще что-то.

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

Ощущение, что ты не понимаешь , зачем вообще докеры нужны.

но если ты хочешь собрать готовую демку, то да. Надо чтобы была и база и nginx и все такое. Собери docker-compose. Но не пихай let’s encrypt в докер к nginx, и лучше вообще не строй эти вспомогательные докеры сам без надобности. Есть готовые решения, я вот ссылку кинул выше nginx-proxy докер, который работает как ingres в кубах, забирает имя домена из env, и автоматом на лету генерируя конфиг, плюс рядом стоит докер с letencrypt , который тоже жрет переменные из env. Меньше работы - быстрее собраный MVP(minimum viable product).

Docker принято использовать для упрощения развертывания

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

Ты какую-то кашу написал.

Какое слово тебе перевести?

в идеале надо стремиться к чему-то типа https://github.com/GoogleContainerTools/distroless Тогда это всё становится не слишком важно

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

Да, из стандартного линуксового контейнера можно убрать питон убрать и шелл. В fedora-minimal например заменяют dnf на microdnf. Но вещи типа openssl ты из приложения не уберешь, какую-нибудь tzdata не выкинешь, стандартную библиотеку языка свою не напишешь и т.п. И жизненный цикл этих вещей всё равно кто-то должен организовать.

Собственно с помощью buildah можно собрать контейнер from scratch из Fedora не устанавливая в него никакого управления пакетами вообще (dnf –installroot на хосте позволяет поствить всё что нужно в примонтированный образ). Я так пару раз делала. Но потом при первой необходимости что-то в таком контейнере дебажить понимаешь что лучше бы это был стандартный образ с которым понятно что от него ждать.

Просто напиши нормально.

Каким образом разработчикам надо платить больше из-за того что их окружение вторично к проду, и причём тут iot?

У контейнеров 3 основых плюса:

1. Помогают не страдать от хардкоженных кроворукими разрабами портов
2. Упрощают подъем окружений для разработки и тестирования
3. Имеют готовые решения для запуска/перезапуска/наблюдения типа кубернейтеса

1. Бред

2. Все итак нормально устанавливается, без докера

3. Кубернетес без докера ненужен. -1 базворд

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

Но лишь немногие могут внятно объяснить, почему они это делают.

Но лишь немногие могут внятно объяснить, почему они это делают.

А какие альтернативы? У докера есть одно большое преимущество - это простота дублирования окружения.

Я вот щас расскажу страшилку. Есть такой проект. Там БД это Oracle 9i. Чтобы её поставить, нужно установить виртуальную машину (даже если ты на винде) Windows 2003. В ней надо установить этот самый оракл. Установить патчи. При этом важно совершать все действия в инсталляторе и установщике патчей в нужном порядке, выбирая нужные галочки. Шаг в сторону и всё заново (ну первый раз заново, второй раз уже со снапшота). Винду предварительно тоже надо настроить определённым образом. Потом накатываются SQL-файлы со структурой и справочниками. После этого тебе дают 8 виртуалок с Windows XP. В каждой виртуалке дельфи с установленными определёнными компонентами. Каждая виртуалка собирает свою DLL-ку. Отдельные виртуалки т.к. компоненты друг с другом не совместимы, разные версии и тд. Последняя виртуалка собирает приложение. Которое наконец-то можно запустить. Перед этим ещё надо оракловый клиент настроить. В общем если во всём этом разбираешься, на это уходит пару дней.

На текущей работе используется докер. Для поднятия копии всего проекта (5 баз, около 10 сервисов) у меня ушло около получаса. По сути я просто скопировать docker-compose и потом полчаса анализировал, кто кого и куда вызывает. Можно сказать, что ушло 5 минут - на скачивание образов.

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

Но в общем и в целом я бы деплоить стал без докера только очень простое приложение. Ну тупо один гошный бинарник, например, без БД. Тут да, докер лишний, скопировал .service, сделал systemctl enable и всё. Хочешь убрать - удалил два файла (уже надо не забыть удалить .service). Хотя всё равно он будет гадить логами, какими-нибудь файлами конфигурации, которые тоже надо отслеживать… В общем даже тут, скорей всего, будет удобней с докером.

Ну или чисто сервер под конкретную задачу, который меняться не планирует. Но это нынче редкость.

Там БД это Oracle 9i. Чтобы её поставить, нужно установить виртуальную машину (даже если ты на винде) Windows 2003

На текущей работе используется докер. Для поднятия копии всего проекта (5 баз, около 10 сервисов) у меня ушло около получаса

А в нём тоже есть оракл, который нужно поднимать строго под винсервер 2003?

Ну или чисто сервер под конкретную задачу, который меняться не планирует. Но это нынче редкость.

Пардоньте, это сервер, который и почту шлёт, и логи принимает, и странички показывает и ещё БД на полставки сейчас редкость. В моде же VM которая выполняет ровно одну задачу (и никогда не меняется, потому что в случае обновления, её убивают и создают другую VM).

Но лишь немногие могут внятно объяснить, почему они это делают.

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

Хотя всё равно он будет гадить логами, какими-нибудь файлами конфигурации, которые тоже надо отслеживать…

А вот для этого люди придумали пакетирование.

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

Так что например контейнер для runtime + service-файл для systemd + конфиг в /etc и всё это в пакет – это вполне разумная комбинация, без всяких swarm и kubernetes.

Каким образом разработчикам надо платить больше из-за того что их окружение вторично к проду

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

и причём тут iot?

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

Вариантов, в сущности, два:

1. Все разработчики и тестировщики получают от фирмы ноут с преднастроенной системой без права чего-то там серьёзно менять. Тут приходится платить сотрудникам повышенную зарплату. Иначе чем вы собираетесь мотивировать их работать именно в вашем концлагере?

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

Я думаю, вам докер не нужен. Раз вы так спрашиваете, явно в нём не разбираетесь. Проект новый, не взлетел ещё, толпы разработчиков и отдела технического контроля у вас тоже нет. Ну так и нафига козе боян? Лучше сосредоточиться на том, что знаешь. Если проект взлетит, всегда можно будет переписать правильно. А пока это только мешать будет.

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

Ага, в помойку.

Всё-таки докер это больше подход, уже, можно сказать, имя нарицательное, как ксерокс.

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

Ну или чисто сервер под конкретную задачу, который меняться не планирует. Но это нынче редкость.

Сервер и должен быть под конкретную задачу. Если нет - ну я уже писал про шаред-хостинг типа «жрите что дают».

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

Хорошо, ты при выборе между качеством и дешевизной выбираешь второе. И плодишь помойный софт. Гореть тебе в аду за это.

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

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

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

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

Платить вот только за чужие утехи с лобзиком желающих все меньше

Откуда в людях столько жадности?

P.S. Забыл добавить третью возможность: предоставить самописное решение, которое делает то же самое, но в отличие от докера нигде в индустрии не используется:

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

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

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

Почему не нужно от же контейнер запускать на сервере? Потому что контейнер - это считай эмулятор сервера. Незачем на сервере запускать эмулятор сервера, когда можно запустить всё нативно. Тут ещё недавно один тему создавал «хочу настроить на сервере esxi чтобы создать там виртуалку и запустить в ней роутер» (как понял, ничего кроме роутера не планировалось) - это из той же серии.

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

Пардон, он разве постргя — это не самая портабельная софтина во всем линуксе? То есть, она запускается из любого каталога и положение ее файлов настраивается.

Эм, почему что-то должно не работать под арчлинуксом?

Ретроградный меркурий.

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

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

контейнер - это считай эмулятор сервер

Вопиюще безрамотное утверждение. С другой стороны, когда это некомпетентность в Х мешало этот самый Х ругать и поносить самым злостным образом?

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

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

извините, не разобрался в тонкостях вашей религиозной системы.

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

Ладно-хорошо, а у тестировщика тоже будет контейнер серверное окружение эмулировать?

Но лишь немногие могут внятно объяснить, почему они это делают.

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

Почему-то ни в винде, ни в маке таких проблем нет. Очевидно, первопричина заключается в засилии софта, работающего так, будто в этой ОС он единственный. Лидер этого движения — питон. Я пока что не слышал про что-то, что было бы сложнее разворачивать на неизвестный целевой системе. Это вызвано тем, что питону нужно: быть единственным интерпретатором в /usr/bin; иметь в /usr/lib/pythonX.X/site-packages/ библиотеки для себя любимого; иметь рабочий компилятор Си на этой системе либо уже скомпилированные под эту систему бинарники расширений. Как мне дать коллеге «бинарник питона» с моего компа? Да никак.

Кто-то заставлял питон быть таким убогим? Нет. Слава архитекторам CPython. Почему-то бинарники Go по дефолту линкуются статически и им, по сути, не особо нужны эти контейнеры. Почему-то постгрес не держит глобальных конфигов. Хотя лично я — фанат SQLite и BerkleyDB, чтобы даже сервера не нужно было отдельного, а только нужно было слинковать свою прогу с соответствующей либой.

я — фанат SQLite

Он вообще у студентов популярен, я тоже его в свое время любил за портативность и везде тащил.

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

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

Почему-то ни в винде, ни в маке таких проблем нет.

Про мак не знаю, а в винде в прежние времена было принято все зависимости программы или библиотеки таскать в её установщике. Они всё ещё так делают? Опять же, вспоминая буквы «dll hell» это кажется не очень помогало.

Очевидно, первопричина

А разница? Это уже есть и это не изменится никогда, значит нужно как-то пытаться выжить в данной ситуации.

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

Там БД это Oracle 9i. Чтобы её поставить, нужно установить виртуальную машину (даже если ты на винде) Windows 2003. В ней надо установить этот самый оракл

На текущей работе используется докер. Для поднятия копии всего проекта (5 баз, около 10 сервисов) у меня ушло около получаса

Ты хочешь нам сказать, что докер сам за тебя ставит 2003 винду и все действия выполняет в правильно порядке? Хрен там. Проблема ведь не в отсутствии докера, а в черезжопной установке оракла и сборке делфей, в которых традиционно для защиты интелектуальной собственности применяются предкомпилированные модули вместо DLL-ок, из-за чего собирать это говно нужно со строго фиксированной версией компилятора и базовых библиотек, шаг в сторону — и вся сборка разваливается. Я участвовал в проекте, где этот трешак был доведен до идеала, благодаря чему один проект ты мог собирать целый день, угадывая, какая из библиотек у тебя неправильной версии.

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

Ну тупо один гошный бинарник, например, без БД. Тут да, докер лишний, скопировал .service, сделал systemctl enable и всё. Хочешь убрать - удалил два файла (уже надо не забыть удалить .service). Хотя всё равно он будет гадить логами, какими-нибудь файлами конфигурации, которые тоже надо отслеживать

Альфа уже ответила, я лишь уточню: докер не решает проблемы логов — докер ее усугубляет. Если тебе эти логи нужны, то их нужно как-то достать. Если тебе нужны персистентные конфиги-данные, это всё нужно отдельно настраивать-поддерживать. По этой причине, в идеале сервис должен быть container-aware: разворачиваться по конфигурации от кубернета, отправлять логи сразу в централизованный механизм, а не так, чтобы их нужно было потом выковыривать из контейнера.

Причём тут тестировщик? Ему не надо серверную часть вообще давать.

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

Особенно ВЕСЕЛО бывает, когда производится смешение библиотек, которые используют один и тот же API, но разных версий …

УууууууууууууууууууууууууХ, аж дух захватывает ...

Благодарю за внимание и желаю всем успехов в работе и счастья в личной жизни …

Владимир