Плюсы докера

Вот бы щас в 2к25 не знать зачем докер и в чём его плюсы.

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

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

я об этом тоже думал, НО, если хакнут, то в контейнере будет все самое важное и если сопрут, то и рут ваще не нужен. Если только разделять по разным контейнерам сервисы, но такое и правами можно разделить в обычном linux... Так что тоже не очевидный плюс

оно так и должно быть: одно приложение - один контейнер. но есть куча образов, где не следуют этому правилу, например, pgadmin4

Ого, дичь!

Так php живет в отдельной группе, в отдельном пользователе. Что он может то?

Плюс я вижу один, хотя я им не пользуюсь, на любой машине, с любой ОС можно написать docker compose up и запустится все нужное, при этом конфигурацию можно держать в Git, и легко обновлять между машинами.

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

то не вылезут за пределв контейнера

Наличие контейнера этого не гарантирует.

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

Собственно, большинство CI/CD на этом и живут.

Не использую docker, но, как я понимаю, вопрос по контейнерной виртуализации в целом.

Из основных решаемых задач:

1. упрощение управления пакетами и зависимостями (в частности устаревшие/конфликтующие пакеты);
2. среды для экспериментов;
3. работа с несколькими дистрибутивами Linux;
4. легкая миграция между физ. серверами (нет требований по гипервизору и CPU).

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

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

Что бы запускать сервисы, нужно их сначала поставить. Куда они будут ставится на Windows? И какой версии? В Docker версии можно зафиксировать. Как будут обновляться эти сервисы через git? В Docker все просто git pull && docker recreate (команду не помню).

firkax

Ну ты как маленький. Разумеется чтобы запихать все г***о по типу gem hell, C++ и его glibc compatibility и т.п. в докер и не знать эту проблему. Разумеется для каких-нибудь питонов или Java докер сомнителен так как проблем с зависимостями практически нет в разных версиях дистров. Возможно поэтому для тебя полезность докер а несколько ускользает.

Создать образ, нашинковать его барахлом уже настроенным (nginx, mongo, redis в моем случае)

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

Ну пожалуйста. Есть wirenboard 7.4, на нем, помимо остальных микросервисов, надо запускать программу на python, поддерживаемая версия не меньше 3.12. На самом устройстве дебиан bookworm, и мало места на system разделе, и на борту python 3.9. Водрузить python, postgresql и redis оказалось проще через контейнеры, в том числе из-за смены версии необходимого python c requirements, чем каждый раз пилить новую прошивку под необходимый набор по. Будет 8 wirenboard - там будем думать что лучше.

Изоляция приложений — каждое приложение работает в отдельном контейнере, избегая конфликтов зависимостей.
Переносимость — контейнеры работают одинаково на любой ОС с Docker (разработка, тестирование, продакшн), на практике - нет.
Эффективность — меньше ресурсов, чем у виртуальных машин (общее ядро системы).
Быстрое развертывание — секунды для запуска/остановки контейнеров.
Масштабируемость — интеграция с Kubernetes для управления кластерами.
Стандартизация — идентичные среды на всех этапах, упрощение CI/CD.
Экосистема — тысячи готовых образов (Docker Hub) и инструментов.

Тут везде указываются плюсы контейнеров вообще, а не плюсы именно докера

У докера нет плюсов.

Как и для чего вы его используете?

Не использую и тебе не рекомендую.

использую для разработки в связке с distrobox.

docker pull, distrobox enter, и у тебя в нужных местах все нужные зависимости с тулчейнами, таких же версий как на CI. distrobox - чтобы не возиться с докерфайлами, композами и т.п. Причём все это не только у тебя но и у коллег, т.ч. все косяки можно быстро вывести на чистую воду.

На серверах - на работе активно применяется, но лично я не фанат.

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

есть приложухи конфигурация которых огромный трактат. ты месяц будешь это настраивать просто чтобы оно хоть как то запустилось. и рядом лежит докер образ, который docker-compose up и все работает….

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

щас в 2к25

Чем это лучше 2025?

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

из докера МОЖНО вылезти в хостовую систему или в другой контейнер

избегая конфликтов зависимостей

из докера МОЖНО вылезти в хостовую систему или в другой контейнер

Как это сделать?

Не использую и тебе не рекомендую.

Да пошёл ты! Козёл!

из докера МОЖНО вылезти

Как это сделать?

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

Чем это лучше 2025?

Неистово триггерит некоторых людей. Они набрасываются и начинают с пеной у рта доказывать, что 2к25 это 200025. Меня это забавляет.

2к25 это 2,25 кОм

Так это полноценные уязвимости, они не фиксятся?

Чем это лучше 2025?

Ты что!!! Этодругое! Это 2к25! Всем кто пишет 2к, честь, хвала, и слава!

Неистово триггерит некоторых людей. Они набрасываются и начинают с пеной у рта доказывать, что 2к25 это 200025. Меня это забавляет.

Не очень понятно как это у них выходит, ведь 2k == 20 и дальше просто конкатенируется 25. Но мне так же непонятно зачем записывать 2025 таким неистово аутистическим способом?

нужно персистентное хранилище

А что думать? оно в контейнере храниться будет, или в volume

Для более эффективной работы с этим зоопарком

Это тоже напрягает. Вроде уходишь от одних сущностей и приходишь к другой. Уходишь от одних проблем и приходишь к другим )

Принято. + Конфликт версий\старый софт

щас в 2к25

Чем это лучше 2025?

Всё это для неосиляторов MDCCCCLLVVVVIIIII.

Всё это для неосиляторов MDCCCCLLVVVVIIIII.

А ты уверен, что твоя запись вообще валидна?

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

А с Docker оно «просто работает». Вся забота о зависимостях отдана разработчику Dockerfile. А тебе только запустить образ и, возможно, передать ему какие-то параметры.

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

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

Итого:

1) C Docker проще запускать новые экземпляры сервисов

2) С Docker проще обновлять сервисы

3) С Docker проще работать с сервисами имеющие сложные зависимости (всякие библиотеки, утилиты и т. д.)

На все C%.

Вся забота о зависимостях отдана разработчику Dockerfile

ты просто переложил работу на другого человека.

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

apt-get install $SERVICE

cp /myusb/$SERVICE/*.config /etc/$SERVICE/

И готово, никаких проблем, никаких подборов версий, всё автоматом поставится и будет обновляться

А у тебя система засрана докер-инфраструктурой и продуктами её жизнедеятельности.

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

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

Насколько я уверен, что смогу раскатать бекап этой системы в любой момент времени (часто ведь бекапят данные и конфиги приложений + набор пакетов для установки, а не тупо всю ФС)? А могу ли я раскатать бекап частично (например, какой-то сервис начал сбоить ещё до часа Х и нужно восстановить все сервисы, кроме него)?

С Docker вся система может задаваться условно несколькими docker compose файлами или более навороченными конфигами Kubernetes + бекапами данных некоторых контейнеров. Соответственно, гораздо проще быть уверенным и в воспроизводимости бекапов, и в возможности быстро отключить какой-то сервис не трогая другие.

Там вроде бы I больше трёх раз нельзя, а у тебя больше.

результат хрупкого баланса конкретных версий библиотек

ты точно понимаешь в администрировании или ты программист?

Насколько я уверен, что смогу раскатать бекап этой системы в любой момент времени …

Ломается то что меняется, а это данные тех сервисов что бегут в системе или в докере, не важно. В обоих случаях данные хранятся на файловой системе ХОСТА, напрямую или через настройки volume в докере

Так что тут докер не выигрывает

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

Условно, сервису A нужна либа X, сервису B нужна либа Y. При этом авторы либы X решили детектить наличие в системе либы Y и при её наличии включать какое-то дополнительный функционал.

В итоге установка вроде бы независимого сервиса может породить видимое изменение поведения другого сервиса. ВНЕЗАПНОЕ (потому что чтобы узнать о нём надо читать даже не документацию к сервису A или B, а вообще к двум либам, которые они используют).

Или другой пример. Обоим сервисам нужна либа X. Либа X имеет конфиг. В ходе наладки работы сервиса A мы отредактировали этот конфиг. Теперь сервис B работает с этим же нестандартным конфигом. И, во-первых, мы можем не вспомнить об этом и с порога получить неожиданное поведение (которое может поставить в тупик в том числе разработчика сервиса B, к которому мы придём с баг-репортом - на его то машине конфиг не изменён). А, во-вторых, в процессе наладки сервиса B мы можем захотеть снова внести изменения в конфиг и они будут влиять уже на сервис A, хотя он отлично работал со старым конфигом и не факт что будет работать так же хорошо с новым.

Ещё может быть такое, что обоим сервисам нужна либа X, но обязательно разных версий. Без Docker это скорее всего выльеться в пересборку из исходников, а то и их патчинг (потому что, например, у либы может быть конфиг путь к которому одинаков для разных версий).

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

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

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

Docker тут выигрывает тем, что сервисы изолированы. И я могу их бекапить и восстанавливать по отдельности и иметь некие гарантии, что они не влияют друг на друга неучтённым образом (за рамками явно прописанных сетевых связей).

Фронтендщики на винде и маке тоже начинают считать себя белыми людьми тк не нужно разбираться с настройкой LAMP. Им дают готовое.

В СТАБИЛЬНОМ дистрибутиве такого не бывает, а эксперименты это не продакшен