Здравствуйте, Sinclair, Вы писали:
S>>>Способность унести контейнер на другую ноду, не оставив сери на предыдущей — ключ к успеху. Все эти ансиблы — это вообще совсем-совсем другой уровень операционной гибкости. S>>Ну так и тягайте хостами. Или у вас гипервизоры не умеют в миграцию гостей? S>Гипервизорная виртуализация — это дорого. Контейнеры жрут на порядок меньше ресурсов, т.к. позволяют реюзать кернел оси.
Не верю что у вас на железе не гипервизор.
Здравствуйте, Sheridan, Вы писали: S>Я рад за вас. Но при чом тут откат, когда нужен хотфикс?
Детский сад. Нужен не хотфикс, а рабочая система. Если мы поставили "улучшенную версию", и обнаружена регрессия, то откат — это предсказуемый способ получения работающей конфигурации.
Ключевое слово — предсказуемый. Хотфикс — это хорошо, но его поиск и развёртывание занимает заранее неизвестное время.
Нормальные бизнесы не хотят работать в режиме "мы тут всё сломали, но уже чиним, и скоро, наверное, сможем узнать, сколько времени займёт починка".
Бизнес хочет, чтобы "мы тут ставили обнову — она нам всё сломала, уже всё вернули на исходные, разбираемся с регрессией. Следующая попытка апгрейда запланирована на следующие выходные — это если мы найдём и устраним причину".
S>Критические ошибки отлавливаются во время тестирования, некритические лечатся хотфиксами.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sheridan, Вы писали: S>Не верю что у вас на железе не гипервизор.
Гипервизор. Внутри него — один guest, внутри которого — сотни контейнеров. Так делают взрослые дяди, пока детишки радуются "я смог запустить две VM на своём сервере".
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>>А если не будет места даже после очистки мусора? Ну, как себя поведет докер? Купит и добавит еще один винт в рейд? S>Да ну блин опять детский сад. Контейнер атомарен — если нет места, докер просто не сможет его запустить, и всё. И не будет такого, что полконтейнера развёрнуто, а полконтейнера — нет, и для уборки этого говна надо писать ещё один скрипт.
Точно так же и с ансиблом. Он не сможет запустить следующий таск. Добавляем места, запускаем. Ансибл продолжит разворачивать с того места, где остановился.
Здравствуйте, Sheridan, Вы писали:
S>Точно так же и с ансиблом. Он не сможет запустить следующий таск. Добавляем места, запускаем. Ансибл продолжит разворачивать с того места, где остановился.
Не, никаких "точно так же". Берём, и поднимаем контейнер в другой ноде, где есть место. На предыдущей ноде можно развернуть менее требовательный к ресурсам контейнер, без принудительного roll forward ансиблом.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>>Не верю что у вас на железе не гипервизор. S>Гипервизор. Внутри него — один guest, внутри которого — сотни контейнеров. Так делают взрослые дяди, пока детишки радуются "я смог запустить две VM на своём сервере".
Все яйца в одной корзине. Плохая идея.
Здравствуйте, Sinclair, Вы писали:
S>>Я рад за вас. Но при чом тут откат, когда нужен хотфикс? S>Детский сад. Нужен не хотфикс, а рабочая система. Если мы поставили "улучшенную версию", и обнаружена регрессия, то откат — это предсказуемый способ получения работающей конфигурации. S>Ключевое слово — предсказуемый. Хотфикс — это хорошо, но его поиск и развёртывание занимает заранее неизвестное время. S>Нормальные бизнесы не хотят работать в режиме "мы тут всё сломали, но уже чиним, и скоро, наверное, сможем узнать, сколько времени займёт починка". S>Бизнес хочет, чтобы "мы тут ставили обнову — она нам всё сломала, уже всё вернули на исходные, разбираемся с регрессией. Следующая попытка апгрейда запланирована на следующие выходные — это если мы найдём и устраним причину".
Вы что, нетестированный на собственных полигонах софт сразу деплоите заказчикам? о0
S>>Критические ошибки отлавливаются во время тестирования, некритические лечатся хотфиксами. S>
Или вы вообще не тестируете?
Здравствуйте, Sinclair, Вы писали:
S>>Точно так же и с ансиблом. Он не сможет запустить следующий таск. Добавляем места, запускаем. Ансибл продолжит разворачивать с того места, где остановился. S>Не, никаких "точно так же". Берём, и поднимаем контейнер в другой ноде, где есть место. На предыдущей ноде можно развернуть менее требовательный к ресурсам контейнер, без принудительного roll forward ансиблом.
А, оттягивание исправления проблемы. Такое себе решение.
Здравствуйте, Sheridan, Вы писали:
C>>Да, а что? S>Да то что ты путаешь деплой с копированием.
Так стоп, вот тут интересно. Деплой вообще абстракное понятие, которое может означать много чего. Что не так с доплоем копированием?
S>А если не будет места даже после очистки мусора? Ну, как себя поведет докер? Купит и добавит еще один винт в рейд?
Контейнер не развернется, при этом не нагадив вокруг себя.
Здравствуйте, Farsight, Вы писали:
C>>>Да, а что? S>>Да то что ты путаешь деплой с копированием. F>Так стоп, вот тут интересно. Деплой вообще абстракное понятие, которое может означать много чего. Что не так с доплоем копированием?
Программирование это когда на кливиатуре по кнопкам жмешь. Но не любое нажатие на кнопки клавиатуры — программирование.
То, что деплой был до, в контейнеры. А потом контейнеры копируются.
S>>А если не будет места даже после очистки мусора? Ну, как себя поведет докер? Купит и добавит еще один винт в рейд? F>Контейнер не развернется, при этом не нагадив вокруг себя.
Ну так результат ровно тот же — система не развернулсь, сломалась по дороге.
И починка ровно такая же — добавление места/очистка, запуск деплоя.
Здравствуйте, Sinclair, Вы писали:
S>>Все яйца в одной корзине. Плохая идея. S>Отличная идея. Если квакнется хост, то уедут и контейнеры и VM.
И работа.
Здравствуйте, Sheridan, Вы писали:
S>Программирование это когда на кливиатуре по кнопкам жмешь. Но не любое нажатие на кнопки клавиатуры — программирование. S>То, что деплой был до, в контейнеры. А потом контейнеры копируются.
Здравствуйте, Sheridan, Вы писали: S>>Бизнес хочет, чтобы "мы тут ставили обнову — она нам всё сломала, уже всё вернули на исходные, разбираемся с регрессией. Следующая попытка апгрейда запланирована на следующие выходные — это если мы найдём и устраним причину". S>Вы что, нетестированный на собственных полигонах софт сразу деплоите заказчикам? о0
Шеридан, ну вот реально — такой уровень рассуждений для человека с опытом в профессии больше 18 месяцев недопустим.
"Отчего б им не выдумать порох сразу сухим"...
Системы состоят из разных компонентов, произведённых разными командами, с разным уровнем протестированности.
Службе эксплуатации нет никакого резона полагаться на то, что разработчики всё протестировали. Нужны гарантии, а не "зуб даю", и на каждый случай — план Б.
Точно так же можно спрашивать "зачем дизель-генератор — что, энергетики не проверяют свои схемы перед включением?".
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sheridan, Вы писали: S>И работа.
Для избегания таких случаев как раз делается инфраструктура resiliency поверх контейнеров.
Если квакнулся хост — мы просто переподнимаем все упавшие контейнеры на других хостах. Это занимает примерно секунды, и не требует вмешательства человека или исполнения ансибельных плейбуков.
То же самое работает и для VM, но стоимость VM существенно выше контейнера, поэтому см. предыдущий пункт.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sheridan, Вы писали:
S>Оно лежит на тестовом полигоне / stage.
Нет. Оно лежит в продакшене у клиента. И что там наобрушал с твоей стороны нерадивый другой поставщик — фиг его знает и надо будет выяснять.
S>Пока лежит — принимаете решение — тыкать палочкой поставщика
Какого поставщика? Почему мы должны тыкать палочкой поставщика клиента, который обрушил сервер?
S>, отказаться от написанного функционала и откатить коммит, отказаться от либы и реализовать самим.
Какой либы? Ты вообще понимаешь, о чем речь идёт? Речь идет о том, что сторонний софт, установленный параллельно, может обрушить сервак и всё, что на нем крутится. И у тебя над этим контроля не будет, т.к. это крутится у клиента. Ты сам ниже об этом сценарии пишешь.
_AB>>Когда я подхожу к владельцу бизнеса с какой-то новой фичей, он у меня спрашивает первым делом — what is the business value of it, _ABC_? Бывает, что не спрашивает, конечно, но это означает только, что ответ на первый вопрос уже очевиден ему самому или я ответил на него в самом описании новой фичи и ответ его устроил. S>А ты ему такой "easy deployment
Docker is way easier, mate... What is the profit comparing to it?
S>, lack of dependence on mammoth shit
We are not talking emotions, mate. We are talking money and profit. What 'mammoth shit' means? What is the profit? Any proofs of the profit?
S>, which allows the customer to save money by not allocating separate servers for our software"
That is what Docker for, no?
We and our clients have servers where numerous docker containers are running right now. More than that — we also have AWS resources with our Docker images running there and Oracle resources with same images. We can do the same with Azure if we need, BTW. It will take us less than 1 hour from scratch to build new environment if needed. So, what are you talking about, _ABC_? I don't get it.
More than that, if someones else software on the same machine will crash, ours will continue operating thanks to the Docker and we had such cases before.
Will Ansible guarantee that? How?
S>Сильный порыв ветра — и всё, нет теплицы. Нет дохода за текущий сезон, нечем выдавать зарплату
Э-э-э-э... Нет.
Практика показывает, что "сильный порыв ветра и нет грядки с морозоустойчивыми огурцами" куда более частый сценарий. А теплица от ветра защищает получше.
Здравствуйте, Sheridan, Вы писали:
S>Ударит, обязательно.
50 на 50.
S>Даже проект на саппорте нужно время от времени брать и актуализировть.
1. Зачем?
Проект переходит в стадию саппорта, когда все функциональные требования выполнены.
Т.е. активная фаза разработки прекращена, осталась небольшая команда, которая занимается мониторингом и фиксит критические баги.
2. За чей счёт?
Заказчик выделяет бюджет на 3.5 анонимусов и всё.
Нет, я не спорю — это удача, продать заказчику контракт на поддержку, которая будет включать в себя помимо мониторинга и багфикса ещё и обновления библиотек,
но только никто в здравом уме на это не подпишется.
S>Да. Именно так. Принимаете решение о необходимости, оцениваете затраты, согласуете бюджет и работаете. S>У вас проблемы с первым пунктом. У вас нет желания этого делать. Совершенно.
Нет проблем с первым пунктом. Если плюсы от обновления перевешивают стоимость обновления, то я всегда с радостью обновлюсь.
Но обновляться только потому что где-то заинкременчена версия — зачем?
П.С. У меня есть связанный с этим "тарвмирующий" опыт.
В одном проекте слишком много вынесли в common-библиотеку, что приводило к тому, что при обновлении коммона надо было обновлять её во всех проектах.
В какой-то момент научились процесс обновления автоматизировать, но вообще это боль и куча времени.
