.
Надо ложить на актуализацию используемых в проекте либ -> глупость. Либы в проекта должны быть свежими. Их актуализацию надо планировать. Даже в проектах, ушедших с разработки в саппорт.
Изоляция строго необходима -> глупость. Изоляция нужна при запуске опасных процессов, способных развалить систему. Например, при экспериментах с вирусами. Либо для ещё одного слоя усложнения доступа к важным данным из соседних процессов. Например, к персональным данным. В остальных случаях можно обойтись.
. S>Надо ложить на актуализацию используемых в проекте либ -> глупость. Либы в проекта должны быть свежими. Их актуализацию надо планировать. Даже в проектах, ушедших с разработки в саппорт. S>Изоляция строго необходима -> глупость. Изоляция нужна при запуске опасных процессов, способных развалить систему. Например, при экспериментах с вирусами. Либо для ещё одного слоя усложнения доступа к важным данным из соседних процессов. Например, к персональным данным. В остальных случаях можно обойтись.
Эээ... я правильно понимаю, что ты не участвуешь в разработке коробочных продуктов?
_____________________
С уважением,
Stanislav V. Zudin
S>Надо ложить на актуализацию используемых в проекте либ -> глупость. Либы в проекта должны быть свежими. Их актуализацию надо планировать. Даже в проектах, ушедших с разработки в саппорт.
С этим могу поспорить. Если, напрмиер, какой-то проект, запущенный в продакшен, работает себе и работает, а тут бац — перестал работать, потому что либа обновилась. Даже если разработчики либы хотели как лучше. Или вообще — фичу из либы, которая в проекте использовалась, разработчики либы объявили устаревшей и из очередной версии выкинули.
Конечно, в общем случае актуализация либ это хорошо. Но возводить ее в абсолют я бы не стал
Здравствуйте, Sheridan, Вы писали:
SVZ>>Эээ... я правильно понимаю, что ты не участвуешь в разработке коробочных продуктов? S>Не вижу разницы.
Когда твой конечный пользователь не имеет рутового доступа к системе, когда ты не знаешь, в каком окружении будет крутиться твоё приложение об актуализации либ можно забыть.
Ну т.е. либо для твоего софта выделять отдельную машину ("фигвам, а не отдельная машина", скажет сисадмин), либо поднимать виртуалку, либо докер.
Либо выкручиваться так, чтобы ни одной dll/so в проекте не использовалось.
Ничего плохого в докере не вижу. Для меня это тупо решение проблемы dll hell.
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, klopodav, Вы писали:
K>Конечно, в общем случае актуализация либ это хорошо. Но возводить ее в абсолют я бы не стал
Фанатизм плох всегда. В абсолют возводить не надо. Надо следить хотя бы за LTS дистрибутивами и актуализировать либы в соответствии с ними.
Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>Когда твой конечный пользователь не имеет рутового доступа к системе, когда ты не знаешь, в каком окружении будет крутиться твоё приложение об актуализации либ можно забыть.
Нет. Ориентируйся не на пользователя, а на актуальные дистрибутивы.
SVZ>Ничего плохого в докере не вижу. Для меня это тупо решение проблемы dll hell.
Такой проблемы нет, когда либы актуальные.
Здравствуйте, Sheridan, Вы писали:
S>Фанатизм плох всегда. В абсолют возводить не надо. Надо следить хотя бы за LTS дистрибутивами и актуализировать либы в соответствии с ними.
Разработчикам делать нехер как следить за всякими дистрибутивами. Нормальному приложению должно быть пофигу на либы в дистрибутиве, настолько, насколько это возможно. Именно так достигается переносимость между пачками дистрибутивов да еще в одном бинарнике.
Здравствуйте, Sheridan, Вы писали:
SVZ>>Когда твой конечный пользователь не имеет рутового доступа к системе, когда ты не знаешь, в каком окружении будет крутиться твоё приложение об актуализации либ можно забыть. S>Нет. Ориентируйся не на пользователя, а на актуальные дистрибутивы.
"...про каких, к черту, заек..."(с)
Какие, к бесу, "актуальные дистрибутивы"???
Половина пользователей до сих пор сидит на RHEL6.6, другая половина — на Убунте 18.04.
У конечного пользователя на машине зоопарк. На личной или на корпоративном сервере — без разницы.
На любое обращение к ИТ отделу ему отвечают, что "корпоративные полиси запрещают что-либо менять на машине".
Все эти пакетные манагеры, когда для установки одной приблуды надо выкачать десять других, хорошо работают на девелоперских машинах, ибо см.выше.
Вот такая вот реальность, в которой мы живём. И в ней внезапно оказалось, что Винду обслуживать гораздо проще и удобнее, чем Линюх (но это уже повод для другого срача).
SVZ>>Ничего плохого в докере не вижу. Для меня это тупо решение проблемы dll hell. S>Такой проблемы нет, когда либы актуальные.
Если ты и сисадмин, и разработчик, и всё происходит в одной компании, тогда да.
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, Mystic Artifact, Вы писали:
MA>Здравствуйте, Sheridan, Вы писали:
S>>Фанатизм плох всегда. В абсолют возводить не надо. Надо следить хотя бы за LTS дистрибутивами и актуализировать либы в соответствии с ними. MA> Разработчикам делать нехер как следить за всякими дистрибутивами.
Именно так. За этим должен следить девапс/админ или кто у вас там деплой подготавливает. Он же должен таски генерировать на обноление либ при необходимости.
Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>Половина пользователей до сих пор сидит на RHEL6.6, другая половина — на Убунте 18.04.
Вам не повезло. Нужно поддерживать все эти дистрибутивы.
Здравствуйте, Sheridan, Вы писали:
S>Надо ложить на актуализацию используемых в проекте либ -> глупость. Либы в проекта должны быть свежими. Их актуализацию надо планировать. Даже в проектах, ушедших с разработки в саппорт.
Здравствуйте, Sheridan, Вы писали:
S>>>Фанатизм плох всегда. В абсолют возводить не надо. Надо следить хотя бы за LTS дистрибутивами и актуализировать либы в соответствии с ними. MA>> Разработчикам делать нехер как следить за всякими дистрибутивами. S>Именно так. За этим должен следить девапс/админ или кто у вас там деплой подготавливает. Он же должен таски генерировать на обноление либ при необходимости.
Боюсь себе представить, но все таки интересно, на основании чего этот лысый хрен будет ставить задачи?
Здравствуйте, chaotic-kotik, Вы писали:
S>>Надо ложить на актуализацию используемых в проекте либ -> глупость. Либы в проекта должны быть свежими. Их актуализацию надо планировать. Даже в проектах, ушедших с разработки в саппорт. CK>а разве докер мешает тебе это делать? Мне — нет.
Здравствуйте, Mystic Artifact, Вы писали:
MA> Боюсь себе представить, но все таки интересно, на основании чего этот лысый хрен будет ставить задачи?
На основании должностных обязанностей.
Чёрт побери, да вы же просто обязаны быть заинтересованы в выпуске качественного продукта! А о каком нахрен качестве можно говорить если его инсталляция превращается в квест с установкой докеров/окаменелых либ?
Если софт — коробка, то это просто обязан быть пакет. (deb, rpm итд), который должен ставиться штатными средствами.
Если софт сложный (куча вспомогательного ПО, множество серверов), то должна быть полноценная инструкция и деплой с проверкой "а всё ли сейчас задеплоено ок?". Нужен ли тут докер? Зависит от ситуации, но с уверенностья могу сказать что в большинстве случаев — нет.
. S>Надо ложить на актуализацию используемых в проекте либ -> глупость. Либы в проекта должны быть свежими. Их актуализацию надо планировать. Даже в проектах, ушедших с разработки в саппорт. S>Изоляция строго необходима -> глупость. Изоляция нужна при запуске опасных процессов, способных развалить систему. Например, при экспериментах с вирусами. Либо для ещё одного слоя усложнения доступа к важным данным из соседних процессов. Например, к персональным данным. В остальных случаях можно обойтись.
Как ты собираешься без докера устанавливать и обновлять сотни сервисов в каком-нибудь микросервисном проекте?
Для сервисов с состоянием, типа баз данных, еще можно рассмотреть варианты.
DevOps, контейнеризация, оркестрация — это все микросервисная тема.
[1] Шеридан: «берутся во внимание только трудозатраты программистов? Или всётаки вы командой работаете?»
[2] Алсо Шеридан: «руками долго и сложно поддерживать единое окружение.»
[3] Алсо Шеридан: «Если квакнулся хост, то нагрузка должна уходить на соседние тут же. »
[4] Алсо Шеридан: "easy deployment, lack of dependence on mammoth shit, which allows the customer to save money by not allocating separate servers for our software"
[5] Асло Шеридан: «Разработчик должен писать код, девапс должен автоматизировать деплой.»
[6] Алсо Шеридан: «Три базовых подхода: масштабирование, рестарт, починка ошибки.»
Почему он против докера, который:
— [1] снижает трудозатраты и программистов и девопсов
— [2] обеспечивает легкость в поддержке единого окружения
— [3] (с кубернетесом) обеспечивает моментальный re-scaling/запуск нужных нод в случае, если нода навернулась, например
— [4] позволяет easy deployment, lack of dependence on mammoth shit, which allows the customer to save money by not allocating separate servers for our software
— [5] позволяет девопсу автоматизировать деплой так, что там ничего не надо «обскриптовывать» и не городить огород из « pacemaker/corosync, haproxy, от iputils с подниманием нужных адресов на сетевухах и описанием маршрутов до поднятия туннелей, systemctl status, разворачиваем ёлку, на хостах filebeat, без ватчдога не обойтись и нужно писать этот самый отдельний ватчдог-сервис» для развертывания, мониторинга и масштабирования
— [6] (с кубернетесом) позволяет автоматические масштабирование и рестарт без скриптования и вмешательства девопса (мечта девопса)
