Стоит, для всего стоит, нужна база для разработки docker pull <называние>, можно любую версию получить в контейнере, а не быть привязанным к поставке дистрибутива. Можно готовые сервисы быстро развернуть из готовых образов, хотя бы чтоб потыкать, как то nexcloud, Gitea и т.д. Можно развернуть несколько контейнеров и наладить их взаимодействие на девелоперской машине, а потом сконфигурированное перенести на целевой сервер.
«а не быть привязанным к поставке дистрибутива» - т.е. по сути разработать что-то поверх unstable версий?)) с точки зрения админа вы считаете это плюсом?
Я не с точки зрения админа, я с точки зрения программера написал. Обычная ситуация когда скажем серверы на smartos а девелоперские комы под linux, и разница в версиях присутствует. Плюс девелопер'у бывает приходится иметь дело и с легаси, в контейнере можно конкретную версию поставить и не саботировать работу все прочих проектов которые работают с другой версией.
Если есть задача массово решать типовые задачи, то однозначно нужен. Например, у меня почти все виртхосты LEMP под Docker. Плюс к этому всякие готовые приложения, чтобы не ломать голову с установкой и настройкой.
Стоит только если собираешься автоматизировать процесс. Если сравнивать с традиционным подходом, то для того, чтобы сделать все правильно телодвижений будет больше, но все они будут легко и однотипно заскриптовываться. Из плюсов, что я нашел для себя: не просто легко, а очень легко откатить неудачный релиз, если у тебя приложение stateless и сделано по заветам https://12factor.net/, то легко масштабировать. Из минусов: куча всего, которое надо админить в нагрузку к проду, надо дополнительно изучать твой стек технологий на особенности докеризации (тут best practices может быть совершенно не такой, как по старинке). Из моих религиозных убеждений: боюсь я в докер совать большие нагруженные реляционные СУБД даже несмотря на то, что технология своими детскими болячками вроде как переболела.
Под «правильно сделать Docker» я понимаю:
1)Поднятие VCS(если не было)
2)Поднятие СВОЕГО docker registry.
3)Разработка, сборка и регулярное обновление СВОИХ базовых образов. И разработчики, БЛЖДЖАД, используют только их. Другое в прод не принимается.
4)Опционально: автоматизированная сборка образов с приложениями. Да, теперь чтобы поставить обновления безопасности надо пересобрать базовый образ/ы, а потом образы всех тех 10/50/100 с лишним «микросервисов в контейнерах», что тебе дали разработчики.
Вот если ты всё это выстроишь, сделаешь себе по вкусу web ui какого нибудь Jenkins-а или набор удобных скриптиков для управления всей этой бодягой, то начнешь чувствовать пользу и удобство от контейнеров, а до этого будет только пот и слёзы.
Ну и моё ИМХО: реальный толк, а не понт от докера только на околокровавоинтерпрайзных проектах где даже runtime выкатить уже подвиг. А на маленьком проекте у тебя из плюсов будет только унификация поставки и, может бы, тебе пригодится возможность шейпинга ресурсов на каждый конкретный экземпляр приложения.
Вопрос - насколько docker+phpfpm vs phpfpm добавляет сложностей в администрировании?
Скорее, упрощает. Поэтому и использую :) Разворачиваешь типовой docker-compose.yml + необходимые конфиги и делаешь docker-compose up. Даже на фронте NginX не надо настраивать, там итак всё заворачивается в контейнер nginx-proxy, который разруливает виртхосты по контейнерам, соответствующим доменам.
Вопрос - насколько docker+phpfpm vs phpfpm добавляет сложностей в администрировании?
ИМХО ни сколько. Когда сгородил всё впервые и наломал всех грабель по одному (или по два дело личного вкуса), дальше разница если не в пользу docker+, то как минимум паритетно. Аналогично юзаю все виртхосты LEMP под Docker. Мне нравится. Проблем практически ноль.
Я не думаю, а изучаю. Зачем думать, надо что-то делать. Потом можно будет и подумать, если будет нечем заняться. Меня Docker заинтересовал удобством разработки приложений, состоящих из компонент, связанных по сети.
Ещё возможностью что-то испытывать. Так, у меня есть намерение поизучать MS SQL Server для Linux. Он есть для Ubuntu 16.04, но у меня 18.04. Можно конечно прикрутить. А если бы это была вообще не Ubuntu? Тут и оказывается, что существует Docker-образ с ним.
Сейчас все дрочат на kubernetes. А вообще, если ФС ZFS то лучше не брать докер ни при каких условиях. Да и настройка контейнеров иногда бывает сложнее настройки нативно установленного пакета, да ещё и ОЗУ жрёт как не в себя. Так что докер будет полезен, наверное, только для устаревшего или люто конфликтующего ПО.
Ну в моем случае мне нужен был программный Raid5, но mdadm на дисках по 3 тб крайне тухло работал, ну я и накатил ZFS с RaidZ и мои волосы снова стали пушистые и шелковистые.
Далее много чего было установлено без докера, в том числе и NextCloud. А вот для редактирования *.docx и *.xls онлайн нужно было поднять докер контейнер collabora или onlyoffice. Вот тут то и началась боль, а тут продолжилась.
Задумка хорошая, реализация треш и угар. Баги, обратная несовместимость, какие то вечные переезды, переименования, даунтаймы, и конца этому не видно. Вечная альфа.
Конечно стоит. Это будет замечательная строчка в резюме.
Удваиваю.
2ТС: В резюме вообще, чем больше модных базвордов, тем лучше. Девушки из эйчар отделов просто обожают продвинутые, позитивные базвордики! Будь в тренде! Будь на позитиве! Пиши в резюме «Docker containers»! Серьёзно.
Докер слишком большой, он в одном проекте содержит рантайм для запуска, менеджмент образов, взаимодействие с registry, пользовательский интерфейс, сворм и ещё кучу всего.
А новые рантаймы делают именно рантаймами. Это небольшая компактная реализация только тех функций которые нужны платформам типа kubernetes. Ну и качеством получше поскольку пилится уже под более менее реальный production с понятными требованиями.
А докер типа не продакшен? И разве эту задачу не решили ещё в containerd?
Кстати, ещё вопрос, а как там обстоит дело с фичами, интроспекцией и прочим? Это ведь как с пищевыми цепочками — каждая прослойка между интерфейсами уменьшает количество доступных свойств на порядок :)
Докер - это стартап. Со всеми прилагающимся болезнями, включая попытку монетизироваться на lock-in.
Он взлетел за счет маководов-разработчиков, а при попытке запихать его в прод возникла куча проблем. Собственно в самом Докере уже тоже решили его распилить на модули (см moby). Но уже поздно, потому что альтернативные рантаймы уже появились и Kubernetes пошел по пути совместимости с открытым стандартом, а не завязки на конкретную технологию с неадекватными владельцами.
Для запуска в нем всякого старого типа php 5.2 который уже нигде не поставить даже
Если для таких целей - среда разработки, - то, как тут уже говорилось выше, очень даже полезно. Можно наклепать себе всяких нужных контейнеров и запускать их по мере необходимости не загаживая «родную» операционку. Для этого достаточно изучить базовые возможности, плюс, docker-compose (не лезть в swarm-режим и далее). Вот пример такого использования - laradock.io.
Что касается использования на production, то на текущий момент как-то сомнительно - слишком «сырой» софт. Для кластеров runtime-среда должна производить более солидное впечатление. Но это мое чисто субъективное впечатление.
Есть еще один такой момент: Docker в процессе работы меняет правила Netfilter, что делает его мягко говоря «не совсем совместимым» со всякими файрвольными frontend-оболочками, заточенными на автономное владение настройками Netfilter. Ну и конфигурирование Netfilter напрямую - через iptables — тоже усложняется. Это дело надо учитывать, если собираетесь крутить Docker на компе, открытом в Интернет.
Почитай announcement про moby, там весь текст про модуляризацию. Ну то есть переименовали для того чтобы распилить, а энтерпрайзную версию собирать из блоков.
Правда я что-то не помню новостей из этой области, не знаю чем они там занимаются на самом деле теперь.