Здравствуйте, Sinclair, Вы писали:
S>Если квакнулся хост — мы просто переподнимаем все упавшие контейнеры на других хостах.
Если квакнулся хост, то нагрузка должна уходить на соседние тут же. Без вот этого вот "ща контейнеры скопируем, поднимем..."
Здравствуйте, Sheridan, Вы писали:
S> S>> AB>Не должна. "Классический" пример — OpenSSL. S> S>> Это у вас там это классика. У меня нет такого. S> AB>Нет OpenSSL? Я могу предположить только это, ибо за последние лет 5 по ней оттоптались все, у кого есть TLS хоть чуть чуть. S> Нет проблем с ней.
Несовместимость API, разное поведение в рамках одного API, (не)поддержка TLSv1.3, ряд CVE, шаманские танцы с отключением compression/SSLv3, история sha1/sha256, выход BoringSSL/LibreSSL, etc.
Т.е. ни о каком "используем последнюю версию" или "обновляем всегда до последней версии" речи быть просто не могло — даже если очень повезет и везде все взлетит, то клиентов растеряете как минимум.
Отсутствие у тебя проблем говорит либо о неиспользовании (что было бы достаточно странно), либо о незнании, либо о том, что ты говоришь неправду.
S> AB>У любого исправления есть цена и принесенная народному хозяйству польза. Если второе меньше первого, то оно никому не нужно. S> А берутся во внимание только трудозатраты программистов? Или всётаки вы командой работаете?
Берутся во внимание все затраты, риски и т.д.
S> S>> AB>Не должна, если плюсы новой версии при детальном рассмотрении не перевешивают минусы старой. Ибо новая версия — это не только новые фитчи, но еще и новые баги. S> S>> Ну то есть несмотря на утверждения "мы работаем в команде!" — вы плевать хотели на работу админа/девапса.
Из чего ты делаешь такой вывод?! Админу (нормальному) новые проблемы в проде совершенно не нужны, он не хочет просыпаться ночью 1-го января и чинить какой-нибудь внезапный пожар, он точно так же будет вовлечен в процесс принятия решения и рассматривать плюсы-минусы через призму своей области ответственности.
S> AB>Если бы ты следовал требованиям бизнеса, то у тебя не возникало бы удивления ни про докер, ни про (не)последние версии библиотек, ни про требования работать только на рабочем оборудовании. S> А это меня не удивляет. Меня удивляет с каким рвением вы бросаетесь доказывать что вот ваше отношение к перечисленному единственно верный путь и других нет.
Другие пути есть, но они на сегодняшний день являются слабо/неэффективными в промышленных масштабах. Ты можешь обрабатывать грядку мотыгой — никто слова не скажет, но в промышленных масштабах люди пользуются специализированной агротехникой и на предложение обработать поле мотыгой пытаются тебе объяснить, что ты неправ.
S> Я понимаю зачем докер. Я не понимаю почему только докер, исключительно докер, докер докер и кубернетес пророк его.
Ты не понимаешь зачем нужна изоляция и/или не принимаешь ее как технологию производства, а не зачем докер.
S> Я понимаю почему версия библиотеки в проекте может отличаться от актуальной. Я не понимаю почему как только речь о актуализации заходит — начинается выдумывание 1000 и 1 способа почему это не нужно делать.
Потому что ты актуализацию делаешь самоцелью в то время как на практике эта операция относительно редкая (и обычно недешевая).
Здравствуйте, Sheridan, Вы писали: S>Если квакнулся хост, то нагрузка должна уходить на соседние тут же. Без вот этого вот "ща контейнеры скопируем, поднимем..."
Совершенно необязательно. Если у нас требования к availability — пять девяток, то да — ферма, ноды фермы разбросаны по разным хостам в разных стойках разных этажей.
А если у меня там рендерится рекламный ролик — то нахрена мне это всё? Ну, упал хост — переподняли и дальше поехали.
Главное — чтобы никто не вскакивал среди ночи всё это чинить.
Ну и ключевой момент: вопрос не в том, как обеспечить availability, а в том, что VM не даёт преимуществ перед контейнером.
Зато имеет недостатки — причём такие, что никто в здравом уме не предлагает распилить приложение на десяток VMок без веской причины, типа "пока погоняете на одном хосте, а как требования вырастут — смигрируетесь".
Потому что оверхед будет такой, что эта кунсткамера на 1 хосте умрёт при 10% нагрузки от той, что завалит тот же хост в "монолитном" развёртывании.
А у контейнеров оверхед околонулевой. Ресурсопотребление у приложения, все запчасти которого притащены в host os пакетным менеджером и заботливо сконфигурированы ансиблем, почти такое же, как и у приложения, которое распилено на десять контейнеров на том же хосте.
Зато когда мне потребуется отодвинуть одну из этих десяти частей на другой хост, мне не нужно вызванивать шеридана для переписывания плейбуков. PROFIT.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, _ABC_, Вы писали:
S>>Оно лежит на тестовом полигоне / stage. _AB>Нет. Оно лежит в продакшене у клиента.
Лежит у клиента — большой косяк, сам понимаешь. Надо чтобы у клиента не лежало. А поэтому тестировать у себя на стейжах.
S>>Пока лежит — принимаете решение — тыкать палочкой поставщика _AB>Какого поставщика? Почему мы должны тыкать палочкой поставщика клиента, который обрушил сервер?
Почему вы тогда волнуетесь? Пусть волнуется другой поствщик — проблема у него. Зачем её решаете вы?
S>>, отказаться от написанного функционала и откатить коммит, отказаться от либы и реализовать самим. _AB>Какой либы? Ты вообще понимаешь, о чем речь идёт? Речь идет о том, что сторонний софт, установленный параллельно, может обрушить сервак и всё, что на нем крутится. И у тебя над этим контроля не будет, т.к. это крутится у клиента. Ты сам ниже об этом сценарии пишешь.
Я? Я не пишу об этом сценарии.
_AB>>>Когда я подхожу к владельцу бизнеса с какой-то новой фичей, он у меня спрашивает первым делом — what is the business value of it, _ABC_? Бывает, что не спрашивает, конечно, но это означает только, что ответ на первый вопрос уже очевиден ему самому или я ответил на него в самом описании новой фичи и ответ его устроил. S>>А ты ему такой "easy deployment _AB>Docker is way easier, mate... What is the profit comparing to it?
Английский поскипал, не силён в разговорном.
S>>Сильный порыв ветра — и всё, нет теплицы. Нет дохода за текущий сезон, нечем выдавать зарплату _AB>Э-э-э-э... Нет. _AB>Практика показывает, что "сильный порыв ветра и нет грядки с морозоустойчивыми огурцами" куда более частый сценарий. А теплица от ветра защищает получше.
От ветра — да. Пока ветер не превышает пределы прочности.
Здравствуйте, Андрей Бабошин, Вы писали:
S>>Ударит, обязательно. АБ>50 на 50.
Это и означает что обязательно ударит.
S>>Даже проект на саппорте нужно время от времени брать и актуализировть. АБ>1. Зачем?
Я даже не понимаю почему все так противятся этому. Продукт должен быть качественным, а когда продукт пользует в бэкграунде говно мамонта, то и качество такое-же. Любой адекватный админ выкинет на помоечку и возьмёт у конкурентов, которые осилили.
АБ>Проект переходит в стадию саппорта, когда все функциональные требования выполнены. АБ>Т.е. активная фаза разработки прекращена, осталась небольшая команда, которая занимается мониторингом и фиксит критические баги.
Вот эта-же команда и проапгредит версии либы
АБ>2. За чей счёт?
За тот же что и всегда, исключая вариант когда бизнесу насрать на качество.
АБ>Заказчик выделяет бюджет на 3.5 анонимусов и всё.
Этого достаточно.
АБ>Нет, я не спорю — это удача, продать заказчику контракт на поддержку, которая будет включать в себя помимо мониторинга и багфикса ещё и обновления библиотек, АБ>но только никто в здравом уме на это не подпишется.
Как будто обновление библиотек это такой бином ньютона, который неразрешим категорически.
S>>Да. Именно так. Принимаете решение о необходимости, оцениваете затраты, согласуете бюджет и работаете. S>>У вас проблемы с первым пунктом. У вас нет желания этого делать. Совершенно. АБ>Нет проблем с первым пунктом. Если плюсы от обновления перевешивают стоимость обновления, то я всегда с радостью обновлюсь. АБ>Но обновляться только потому что где-то заинкременчена версия — зачем?
Не потому что заинкрементирована а потому что её уже вообще нет в репозиториях.
АБ>П.С. У меня есть связанный с этим "тарвмирующий" опыт. АБ>В одном проекте слишком много вынесли в common-библиотеку, что приводило к тому, что при обновлении коммона надо было обновлять её во всех проектах. АБ>В какой-то момент научились процесс обновления автоматизировать, но вообще это боль и куча времени.
Первый опыт он всегда болезненный.
Здравствуйте, Farsight, Вы писали:
S>>Потому что это копирование? F>Нет. Опять потерялся? Ок, что такой деплой?
Разворачивание окружения, разворачивание вспомогательных сервисов, разворачивание целевого софта. Всё это в докере выполняется на этапе сборки образов.
Здравствуйте, Anton Batenev, Вы писали:
S>> AB>Нет OpenSSL? Я могу предположить только это, ибо за последние лет 5 по ней оттоптались все, у кого есть TLS хоть чуть чуть. S>> Нет проблем с ней. AB>Несовместимость API, разное поведение в рамках одного API, (не)поддержка TLSv1.3, ряд CVE, шаманские танцы с отключением compression/SSLv3, история sha1/sha256, выход BoringSSL/LibreSSL, etc.
Я слышу это только от вас. На практике никогда не встречался, хотя много где использовалосью
S>> AB>У любого исправления есть цена и принесенная народному хозяйству польза. Если второе меньше первого, то оно никому не нужно. S>> А берутся во внимание только трудозатраты программистов? Или всётаки вы командой работаете? AB>Берутся во внимание все затраты, риски и т.д.
Ну тогда вы должны взять во внимание и трудозатраты девапса/админа на танцы вокруг окаменелостей.
S>> S>> Ну то есть несмотря на утверждения "мы работаем в команде!" — вы плевать хотели на работу админа/девапса. AB>Из чего ты делаешь такой вывод?! Админу (нормальному) новые проблемы в проде совершенно не нужны, он не хочет просыпаться ночью 1-го января и чинить какой-нибудь внезапный пожар, он точно так же будет вовлечен в процесс принятия решения и рассматривать плюсы-минусы через призму своей области ответственности.
И на этом этапе нормальный девапс/админ будет настаивать на переходе либ с окаменелостей на текущую версию.
S>> А это меня не удивляет. Меня удивляет с каким рвением вы бросаетесь доказывать что вот ваше отношение к перечисленному единственно верный путь и других нет. AB>Другие пути есть, но они на сегодняшний день являются слабо/неэффективными в промышленных масштабах. Ты можешь обрабатывать грядку мотыгой — никто слова не скажет, но в промышленных масштабах люди пользуются специализированной агротехникой и на предложение обработать поле мотыгой пытаются тебе объяснить, что ты неправ.
Вот как раз ансибл это и есть комбайн, способный с нуля обрабатывать поля. А докер в этой аналогии — теплица, где каждый сам под себя грядки копает.
S>> Я понимаю зачем докер. Я не понимаю почему только докер, исключительно докер, докер докер и кубернетес пророк его. AB>Ты не понимаешь зачем нужна изоляция и/или не принимаешь ее как технологию производства, а не зачем докер.
Я не понимаю изоляцию ради изоляции.
S>> Я понимаю почему версия библиотеки в проекте может отличаться от актуальной. Я не понимаю почему как только речь о актуализации заходит — начинается выдумывание 1000 и 1 способа почему это не нужно делать. AB>Потому что ты актуализацию делаешь самоцелью в то время как на практике эта операция относительно редкая (и обычно недешевая).
Я не делаю её самоцелью. Это реакция на ваши утверждения что менять ничего не надо.
Здравствуйте, Sinclair, Вы писали:
S>>Если квакнулся хост, то нагрузка должна уходить на соседние тут же. Без вот этого вот "ща контейнеры скопируем, поднимем..." S>Совершенно необязательно. Если у нас требования к availability — пять девяток, то да — ферма, ноды фермы разбросаны по разным хостам в разных стойках разных этажей. S>А если у меня там рендерится рекламный ролик — то нахрена мне это всё? Ну, упал хост — переподняли и дальше поехали. S>Главное — чтобы никто не вскакивал среди ночи всё это чинить.
Это можно и без докера сделать.
S>Ну и ключевой момент: вопрос не в том, как обеспечить availability, а в том, что VM не даёт преимуществ перед контейнером.\
Да я не прошу переходить с контейнеров в вм. Я не понимаю зачем по каждому чиху плодить контейнеры. Почему, например, не запустить Х экземпляров рендера рекламных роликов без докера? Пусть ходят в очередь за тасками, обрабатывают и так по кругу. Почему обязательно докер и кубернетес пророк его?
Здравствуйте, Sheridan, Вы писали:
S>Точно так же и с ансиблом. Он не сможет запустить следующий таск. Добавляем места, запускаем. Ансибл продолжит разворачивать с того места, где остановился.
ох бля...
т вообще хер знает как оно полуразвернутое будет работать все это время пока добавляешь ноды? с совершенно непредсказуемыми эффектами?
это просто космические технологии
Здравствуйте, mogadanez, Вы писали:
S>>Точно так же и с ансиблом. Он не сможет запустить следующий таск. Добавляем места, запускаем. Ансибл продолжит разворачивать с того места, где остановился. M>ох бля... M>т вообще хер знает как оно полуразвернутое будет работать все это время пока добавляешь ноды? с совершенно непредсказуемыми эффектами?
Никак. Деплой прерван, сервисы не запущены.
Здравствуйте, Sheridan, Вы писали: S>>Ну и ключевой момент: вопрос не в том, как обеспечить availability, а в том, что VM не даёт преимуществ перед контейнером.\ S>Да я не прошу переходить с контейнеров в вм. Я не понимаю зачем по каждому чиху плодить контейнеры. Почему, например, не запустить Х экземпляров рендера рекламных роликов без докера? Пусть ходят в очередь за тасками, обрабатывают и так по кругу. Почему обязательно докер и кубернетес пророк его?
Потому что это занимает минуты, а не часы. Не надо париться про то, какие там версии каких библиотек стоят и кто там с кем будет конфликтовать. Не надо париться с тем, чтобы заново задеплоить рендерер после падения хоста, на котором он был поднят. Не надо париться с тем, позаботился ли разработчик о том, чтобы на одном хосте могли параллельно работать две версии рендерера, или как обычно "вместе могут работать 3 и 4, и 4 и 2, но не 3 и 2"
То, что ты предлагаешь — это девелопмент на каждый чих. А людям это всё не надо. Надо чтобы как телевизор — притащил в гостиную, воткнул — заработало. Надо звук получше — воткнул колонки 7.1, заработало.
Безо всех этих "да я щас там заднюю панель сниму, паяльничком чик-чик, и в понедельник уже заработает".
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sheridan, Вы писали:
_AB>>По сравнению с докером, ансиблом долго и сложно поддерживать единое окружение. Так зачем ансибл? S>Потому что у ансибла гораздо больше возможностей.
YAGNI. И я хочу крутить свое решение в песочнице. Проблемс?
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Sheridan, Вы писали: S>>>Ну и ключевой момент: вопрос не в том, как обеспечить availability, а в том, что VM не даёт преимуществ перед контейнером.\ S>>Да я не прошу переходить с контейнеров в вм. Я не понимаю зачем по каждому чиху плодить контейнеры. Почему, например, не запустить Х экземпляров рендера рекламных роликов без докера? Пусть ходят в очередь за тасками, обрабатывают и так по кругу. Почему обязательно докер и кубернетес пророк его? S>Потому что это занимает минуты, а не часы.
Да, минуты.
S>Не надо париться про то, какие там версии каких библиотек стоят и кто там с кем будет конфликтовать.
Абсолютно верно, на стадии деплоя не надо. Надо на стадии разработки.
S>Не надо париться с тем, чтобы заново задеплоить рендерер после падения хоста, на котором он был поднят.
Не надо, абсолютно верно. После поднятия хоста оно само поднимется.
S>Не надо париться с тем, позаботился ли разработчик о том, чтобы на одном хосте могли параллельно работать две версии рендерера, или как обычно "вместе могут работать 3 и 4, и 4 и 2, но не 3 и 2"
Отучать разрабов от лени и учить читать ТЗ.
Ну и учиться ставить задачи конечно жэ.
S>То, что ты предлагаешь — это девелопмент на каждый чих. А людям это всё не надо. Надо чтобы как телевизор — притащил в гостиную, воткнул — заработало. Надо звук получше — воткнул колонки 7.1, заработало. S>Безо всех этих "да я щас там заднюю панель сниму, паяльничком чик-чик, и в понедельник уже заработает".
Странное у тебя представление об ансибле, очень странное.
Здравствуйте, Farsight, Вы писали:
_AB>>>По сравнению с докером, ансиблом долго и сложно поддерживать единое окружение. Так зачем ансибл? S>>Потому что у ансибла гораздо больше возможностей. F>YAGNI. И я хочу крутить свое решение в песочнице. Проблемс?
Да крути, кто ж против. Сколько угодно. Но очень желательно не на проде.
Здравствуйте, Sheridan, Вы писали:
F>>YAGNI. И я хочу крутить свое решение в песочнице. Проблемс? S>Да крути, кто ж против. Сколько угодно. Но очень желательно не на проде.
В смысле кто против? Ты, не? Куче народу безуспешно доказываешь уже несколько дней, что докер на проде нельзя потому что лишняя шестеренка. Тебе реальные кейсы, а ты голую теорию в ответ.
Здравствуйте, Farsight, Вы писали:
F>В смысле кто против? Ты, не? Куче народу безуспешно доказываешь уже несколько дней, что докер на проде нельзя потому что лишняя шестеренка. Тебе реальные кейсы, а ты голую теорию в ответ. https://rsdn.org/forum/flame.comp/7723816.1
F>>>YAGNI. И я хочу крутить свое решение в песочнице. Проблемс? S>>Да крути, кто ж против. Сколько угодно. Но очень желательно не на проде. F>В смысле кто против? Ты, не? Куче народу безуспешно доказываешь уже несколько дней, что докер на проде нельзя потому что лишняя шестеренка. Тебе реальные кейсы, а ты голую теорию в ответ.
Здравствуйте, Farsight, Вы писали:
F>В смысле кто против? Ты, не? Куче народу безуспешно доказываешь уже несколько дней, что докер на проде нельзя потому что лишняя шестеренка. Тебе реальные кейсы, а ты голую теорию в ответ.
Не знаю, зачем вы две недели к ряду пытаетесь что-то доказать человеку, у которого отсутствует какое-либо критическое мышление.
Он все свое существование на этом форуме был местной very special snowflake, проще научить свинью играть лунную сонату, нежели что-то втолковать шеридану.
