docker это не про настройку инфраструктуры, это про "мы не осилили всё вместе, будем делать по отдельности" как правило. Ну, когда на вопрос "зачем тут докер?" поступают ответы в стиле "эээ... ммм...", "потому что умеем!", "почему нет?" — вот как раз оно.
...
А вот для продакшена.... Ну, такое вот. Докер в проде это минус в карму и косые взгляды. Ну, кроме, пожалуй, варианта когда проект гдетотам на сферическом амазоне крутитцца и нужно уметь быстро/автоматически масштабировать мощности в зависимости от нагрузки.
И правда ведь... Docker — он же не бесплатный по ресурсам, верно? Зачем он, если можно и без него?
Всё правильно. Докер — для масштабных "облачных" служб типа Амазона. Где куча софта разных версий, куча конфигураций, и всё это надо автоматически разворачивать на тысячах серверов.
Ну ещё иногда для разработки. Точнее, для автоматического тестирования разрабатываемого софта.
Здравствуйте, Shmj, Вы писали:
S> И правда ведь... Docker — он же не бесплатный по ресурсам, верно? Зачем он, если можно и без него?
Для разработки ресурсоемкость решения не особо принципиальна будь то docker, virtual box, kvm, chroot (и все остальное, что могут использовать для изоляции). Для прода, где нужна стабильность и прочие аттрибуты "зрелости" (а не хипстерское "упало, да и фиг с ним — облако новых нарожает") докер непригоден (но не из за оверхеда конечно же).
S>docker это не про настройку инфраструктуры, это про "мы не осилили всё вместе, будем делать по отдельности" как правило. Ну, когда на вопрос "зачем тут докер?" поступают ответы в стиле "эээ... ммм...", "потому что умеем!", "почему нет?" — вот как раз оно.
S>...
S>А вот для продакшена.... Ну, такое вот. Докер в проде это минус в карму и косые взгляды. Ну, кроме, пожалуй, варианта когда проект гдетотам на сферическом амазоне крутитцца и нужно уметь быстро/автоматически масштабировать мощности в зависимости от нагрузки.
S>И правда ведь... Docker — он же не бесплатный по ресурсам, верно? Зачем он, если можно и без него?
Докер это унифицированный деплой.
Установка сложного приложения без докера выглядит так:
1) Устновить nodejs\веб-сервер\еще какую-нибудь-фигню версии 15.43.442, именно такой, потому что на другом не тестировалось и корректность работы не гарантируется.
2) Поднять базу на mongodb 12.697 и кэш на редис на 3.974, именно на таких, потому что на других не тестировалось и работоспособность не гарантируется.
3) Открыть порты 1234 и 4321.
4) Прописать в переменных окружения нужные параметры, совпадающие с фазой менструального цикла лемура.
Естественно для каждого языка\платформы\базы этот набор магических пассов руками уникален.
Установка с докером — передать образ и запустить пару команд в командной строке. Всю работу по конфигурации берет на себя разработчик.
Конечно шеридану такая ситуация не нравилась, потому что лишает админа власти над этими выскочками-программистами. Программисты с докером могут поставить приложения у заказчика без усилий с снисхождения админа.
А вот в чем профит от "микросервисов" — я до сих пор не понял и даже внятных примеров нет.
S>docker это не про настройку инфраструктуры, это про "мы не осилили всё вместе, будем делать по отдельности" как правило. Ну, когда на вопрос "зачем тут докер?" поступают ответы в стиле "эээ... ммм...", "потому что умеем!", "почему нет?" — вот как раз оно.
S>...
S>А вот для продакшена.... Ну, такое вот. Докер в проде это минус в карму и косые взгляды. Ну, кроме, пожалуй, варианта когда проект гдетотам на сферическом амазоне крутитцца и нужно уметь быстро/автоматически масштабировать мощности в зависимости от нагрузки.
S>И правда ведь... Docker — он же не бесплатный по ресурсам, верно? Зачем он, если можно и без него?
Ну это вопрос по-моему аналогичен вопросу "зачем виртуализация"?
На мой взгляд для максимальной утилизации железа, и упрощения администрирования.
И если говорить о Linux, то cgroups практически бесплатен по сравнению
с настоящей виртуализацией. Там вроде 1-10 процентов деградации по сравнению
с запуском без cgroups. Это ведь по-сути "chroot" на супер стероидах.
Здравствуйте, Shmj, Вы писали:
S>И правда ведь... Docker — он же не бесплатный по ресурсам, верно? Зачем он, если можно и без него?
Docker — практически бесплатный по CPU/RAM. Это же не виртуализация, а контейнеры.
Основной overhead — это в дополнительных копиях системных библиотек в контейнере. Но для типичных условий это совершенно несущественно.
Вообще мне понравилась концепция докера. Но как-то у меня не срастается с практикой. Как ни поставлю, то зависает, то сервер зависает через какое-то время. В общем пока отложил. Но это было несколько лет назад, может уже отладили.
В целом для некоторых юз-кейсов при разработке считаю его просто божественным. Всё хочу внедрить в тестирование. Концепция такая. Есть чистая база, на неё накатываются миграции (SQL-файлы), после всех миграций база становится в чистом актуальном состоянии (без данных). После этого на этой чистой базе прогоняются тесты. При этом каждый тест рассчитывает на то, что база, собственно, чистая. Сейчас это всё делается в полу-ручном состоянии и тесты делают rollback после выполнения, но это не идеальный вариант. С докером я хочу сделать так: каждая миграция это отдельный слой. Т.е. если мы меняем последнюю миграцию (при разработке), то они все не прогоняются заново, а берётся предпоследнее состояние базы, это должно быть куда быстрей. Также для каждого теста берётся последнее состояние базы прям на диске, тест прогоняется, можно делать коммит, а состояние потом выбрасывается. Можно даже пускать несколько тестов параллельно.
Правда пока не осилил так сделать, как-то пытался, но слишком муторно это всё. Но концепция мне очень нравится и когда-нибудь осилю.
Оверхед у докера по идее совсем небольшой. Это же не виртуальная машина.
Здравствуйте, vsb, Вы писали:
vsb>Вообще мне понравилась концепция докера. Но как-то у меня не срастается с практикой. Как ни поставлю, то зависает, то сервер зависает через какое-то время. В общем пока отложил. Но это было несколько лет назад, может уже отладили.
На Винде он как гражданин второго класса, поддержка остаточная, то тут отвалится, то там. Но всё равно удобно. Одновременно иметь пару ораклов и постгрис и никто никуда не посрал, и удалить одной командой можно, как не было. Хочу один Zookeeper и Kafka, хочу — кластер из трёх, посмотреть как оно отказ узлов обрабатывает и как наше приложение реагирует. И опять нигде не насрано, удалил потом как не было.
vsb>Оверхед у докера по идее совсем небольшой. Это же не виртуальная машина.
На винде создаётся виртуальная машина Hyper-V и весь Докер и все контейнеры там крутятся. Но на каждый контейнер не создаётся, да. Но формально всё-таки виртуальная машина.
Здравствуйте, bzig, Вы писали:
vsb>>Вообще мне понравилась концепция докера. Но как-то у меня не срастается с практикой. Как ни поставлю, то зависает, то сервер зависает через какое-то время. В общем пока отложил. Но это было несколько лет назад, может уже отладили.
B>На Винде он как гражданин второго класса, поддержка остаточная, то тут отвалится, то там. Но всё равно удобно. Одновременно иметь пару ораклов и постгрис и никто никуда не посрал, и удалить одной командой можно, как не было. Хочу один Zookeeper и Kafka, хочу — кластер из трёх, посмотреть как оно отказ узлов обрабатывает и как наше приложение реагирует. И опять нигде не насрано, удалил потом как не было.
Зависало у меня как раз в линуксе. В венде, как ни странно, всё работало.
vsb>>Оверхед у докера по идее совсем небольшой. Это же не виртуальная машина.
B>На винде создаётся виртуальная машина Hyper-V и весь Докер и все контейнеры там крутятся. Но на каждый контейнер не создаётся, да. Но формально всё-таки виртуальная машина.
Ну речь о продакшне, думаю, никто в своём уме не будет продакшн в докере крутить на вендовом хосте.
Здравствуйте, gandjustas, Вы писали:
G>Докер это унифицированный деплой.
Унифицированный деплой это ansible.
G>Установка сложного приложения без докера выглядит так: ... G>Установка с докером — передать образ и запустить пару команд в командной строке. Всю работу по конфигурации берет на себя разработчик. ansible-playbook playbook-deploy.yaml и оно может даже само выкачать всё нужное.
G>Конечно шеридану такая ситуация не нравилась, потому что лишает админа власти над этими выскочками-программистами. Программисты с докером могут поставить приложения у заказчика без усилий с снисхождения админа.
У тебя админ что, жену увёл?
Какая нахрен власть? Админ работает параллельно с программистами. Чтобы те не отвлекались от кода и делали то, что они умеют делать с полной отдачей. Админ для программиста это этакий деплой с голосовым управлением. "Чувак, я тут дописал-оттестировал, но нужно чтобы в системе была либа А, пара реверспрокси на эти порты и блекджек вот тут". Нормальный админ уточнит детали, , прикинет возможные проблемы, обсудит с программистом если такие есть и оба два разойдутся пилить каждый свою работу.
Если у вас не такие админы, то я вам сочуствую. Увольняйте их нахрен и нанимайте нормальных.
Если у вас нет админов вообще, то вы — стартап, который еще не дорос до админов. Если конечно дорастёт вообще...
Здравствуйте, gandjustas, Вы писали:
G>А вот в чем профит от "микросервисов" — я до сих пор не понял и даже внятных примеров нет.
Профит микросервисов в их независимости друг от друга:
— можно создавать на разных языках/платформах, упрощается дизайн сервисов
— можно гибко масштабировать — увеличивать количество только нужных сервисов
Здравствуйте, Sheridan, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
G>>Докер это унифицированный деплой. S>Унифицированный деплой это ansible. S>ansible-playbook playbook-deploy.yaml и оно может даже само выкачать всё нужное.
Напоминает диалог и фильма Snatch
— Мне очень не нравится выезжать из своей страны, особенно выезжать не на теплый песчаный пляж, где все ходят в соломенных шляпах и тебе подтаскивают коктейли.
— У нас тут есть песчаные пляжи.
— Да кому они на х*** нужны, эти ваши пляжи?!
Здравствуйте, Буравчик, Вы писали:
Б>Здравствуйте, gandjustas, Вы писали:
G>>А вот в чем профит от "микросервисов" — я до сих пор не понял и даже внятных примеров нет.
Б>Профит микросервисов в их независимости друг от друга:
Я тоже слышал эти лозунги, но преимущества в чем?
Б>- можно создавать на разных языках/платформах, упрощается дизайн сервисов
То есть вместо одного программиста на одном языке для поддержки теперь требуется 10 программистов на 10 языках? Это реально кто-то считает преимуществом?
Б>- можно гибко масштабировать — увеличивать количество только нужных сервисов
Я примерно то же самое слышал про про CORBA 20 лет назал, про WS-* 15 лет назад и про REST — 10 лет назад.
Проблема только в том, что 99,9% проектов не доживают до состояния когда ВСЕ их компоненты не могут уместиться на одной машине.
разговоры про scale out были модными 10 лет назад, примерно когда и rest. Но, внезапно, мощности серверов растут, а scale-out так и не стал дешевле в пересчете не ядро или гигибайт памяти. А вот сетевые задержки не меняются и толщна каналов, даже внутри ДЦ не растет так сильно.
Здравствуйте, gandjustas, Вы писали:
G>Напоминает диалог и фильма Snatch G>
G>— Мне очень не нравится выезжать из своей страны, особенно выезжать не на теплый песчаный пляж, где все ходят в соломенных шляпах и тебе подтаскивают коктейли.
G>— У нас тут есть песчаные пляжи.
G>— Да кому они на х*** нужны, эти ваши пляжи?!
Ну всё верно. Он ж просил теплый песчаный пляж
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, gandjustas, Вы писали:
G>То есть вместо одного программиста на одном языке для поддержки теперь требуется 10 программистов на 10 языках? Это реально кто-то считает преимуществом?
Да, например AI может быть написан на python, сервисы на go, интеграция с enterprise на java.
Ну и упрощение сервисов — маленькую программу написать проще, также как и переписать с нуля при необходимости.
G>Проблема только в том, что 99,9% проектов не доживают до состояния когда ВСЕ их компоненты не могут уместиться на одной машине.
Есть и другие причины для использования нескольких машин. Например, отказоустойчивость.
G>Но, внезапно, мощности серверов растут, а scale-out так и не стал дешевле в пересчете не ядро или гигибайт памяти
Это пока у тебе запросы скромные — 128 Гб и 32 ядра. А если больше, то становится выгоднее взять несколько серверов вместо супермощного.
S>И правда ведь... Docker — он же не бесплатный по ресурсам, верно? Зачем он, если можно и без него?
Без него будет дольше и хуже, чем с ним. Даже несмотря на то, что докер — говно.
Ты получаешь одинаковый environment на всех стадиях: в разработке, при тестировании, на staging'е, в production'е. Безо всяких свистоплясток типа «а вот у девелопера будет докер, а вот на тесте развернем ansible'ом, а в проде тоже развернем ansible'ом, но надо еще извернуться, чтобы куда-то security-sensitive ключи засунуть» (хотя докер, естественно, не решает проблему ключей).
Получить на dev-машине такой же environment, как на prod'е — бесценно. Остальное — мелочи жизни.
Здравствуйте, Буравчик, Вы писали:
Б>Здравствуйте, gandjustas, Вы писали:
G>>То есть вместо одного программиста на одном языке для поддержки теперь требуется 10 программистов на 10 языках? Это реально кто-то считает преимуществом?
Б>Да, например AI может быть написан на python, сервисы на go, интеграция с enterprise на java.
Но дешевле все сделать на одном языке. На той же java.
Б>Ну и упрощение сервисов — маленькую программу написать проще, также как и переписать с нуля при необходимости.
Написать одну большую программу проще, чем кучу маленьких, в сумме дающих функциональность большой.
G>>Проблема только в том, что 99,9% проектов не доживают до состояния когда ВСЕ их компоненты не могут уместиться на одной машине. Б>Есть и другие причины для использования нескольких машин. Например, отказоустойчивость.
Только вот незадача. Если у тебя N сервисов, которые распределны на N*2 машин, то для ганартированного выхода из строя надо N+1 одновременных отказов. Но, внезапно, отказ может случиться при выходе из строя двух машин.
Тогда как у монолитного приложения, распределенного на 2*N узлов, отказ будет наступать при выходе из строя всех узлов кроме одного.
Чтобы победить эту проблему надо микросервсы размещать на всех узлах кластера, но тогда непонятно зачем микросервисы.
G>>Но, внезапно, мощности серверов растут, а scale-out так и не стал дешевле в пересчете не ядро или гигибайт памяти Б>Это пока у тебе запросы скромные — 128 Гб и 32 ядра. А если больше, то становится выгоднее взять несколько серверов вместо супермощного.
128г и 32 это в 100 раз больше, чем необходимо для среднего проекта. Хотя, возможно, при наличии микросервисов это даже мало.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, Буравчик, Вы писали:
Б>>Здравствуйте, gandjustas, Вы писали:
G>>>То есть вместо одного программиста на одном языке для поддержки теперь требуется 10 программистов на 10 языках? Это реально кто-то считает преимуществом?
Б>>Да, например AI может быть написан на python, сервисы на go, интеграция с enterprise на java. G>Но дешевле все сделать на одном языке. На той же java.
так кроме программ там еще БД, прокси, message brokers и куча всего прочего, уже кем-то написанного. Они уже есть и написаны на разных языках
AB>. Для прода, где нужна стабильность и прочие аттрибуты "зрелости" (а не хипстерское "упало, да и фиг с ним — облако новых нарожает") докер непригоден (но не из за оверхеда конечно же).
Это прошлый век.
Тот прод, что нонеча, это как раз "constant partial failure", когда в любой момент времени где-то что-то не работает. Но только у части юзеров, и только часть функциональности. Скажем, не подгружается третья сверху строчка пикселей видеофайла, у жителей Новой Зеландии.
(почему новой зеландии? да потому что они (а) говорят по-английски (б) их не так много (в) они изолированы (г) они уже приучены в случае чего звонить в саппорт )
G>А вот в чем профит от "микросервисов" — я до сих пор не понял и даже внятных примеров нет.
В том, что можно отвязать циклы разработки свистоперделок от ключевой функциональности.
Не работает звук "врруууууум" при запуске двигателя — и фиг бы с ним, голова пусть болит у разработчика сервиса, который этот звук подгружает.
G>То есть вместо одного программиста на одном языке для поддержки теперь требуется 10 программистов на 10 языках? Это реально кто-то считает преимуществом?
Да.
Это очень важное преимущество для "менеджеров среднего звена". Видишь ли, менеджер одного программиста, это... не круто. И денег немного.
То ли дело, менеджер у сотни.
SD>Это прошлый век. SD>Тот прод, что нонеча, это как раз "constant partial failure", когда в любой момент времени где-то что-то не работает. Но только у части юзеров, и только часть функциональности. Скажем, не подгружается третья сверху строчка пикселей видеофайла, у жителей Новой Зеландии.
Скажем, у Скайденса на банковском счету вдруг стало 0 денег, счет за комунальные услуги пришел в двойном размере, а магазинная касса занимается приписками в чеках.
Вопрос в ответственном отношении к работе.
Хотя, для детских проектов с тремя пользователями сойдет.
Здравствуйте, SkyDance, Вы писали:
SD> Тот прод, что нонеча, это как раз "constant partial failure", когда в любой момент времени где-то что-то не работает.
Так в любом проде в любой момент времени где-то что-то не работает. Docker здесь только множит как количество проблем, так и их качество. И если с количеством еще можно как-то бороться, то их качество выводит стоимость эксплуатации на совсем другой уровень.
Здравствуйте, Shmj, Вы писали:
S>И правда ведь... Docker — он же не бесплатный по ресурсам, верно? Зачем он, если можно и без него?
можно вообще без всего, и без этого тоже, и без вопросов зачем можно тоже можно. Это инструмент. Используется тогда, когда необходимо решать задачи, которые он решает — фиксация бинарного окружения для проекта. Шеридана слушать не надо, у него знания уровня селюка-настройщика один-эсс и программиста экселя. Докер очень удобен, я просто тащусь. Никогда деплой не был таким лёгким. Господь расплакался когда увидел докер.
Микросервисы нужны только там где необходимо горизонтальное масштабирование. Во всех других случаях профита меньше чем геморроя.
Здравствуйте, namespace, Вы писали:
N>Вопрос в ответственном отношении к работе.
N>Хотя, для детских проектов с тремя пользователями сойдет.
умение допускать некоторый контролируемый уровень фейлов и за счёт этого иметь гораздо больше архитектурной свободы это гораздо круче умения их вообще не допускать. Но это умение обычно нужно в очень крутых проектах, на миллионы пользователей.
Здравствуйте, Мирный герцог, Вы писали:
N>>Хотя, для детских проектов с тремя пользователями сойдет. МГ>умение допускать некоторый контролируемый уровень фейлов и за счёт этого иметь гораздо больше архитектурной свободы это гораздо круче умения их вообще не допускать. Но это умение обычно нужно в очень крутых проектах, на миллионы пользователей.
Ну да, ну да. Правильно ли я понял, что для проектов с миллионом пользователей нужно стараться, а для всего остального —
?
Б>>Да, например AI может быть написан на python, сервисы на go, интеграция с enterprise на java. G>Но дешевле все сделать на одном языке. На той же java.
Ой не факт.
Например, AI с какой-то хитровывернутой логикой может писать команда, которая с java не дружит, а на python пишет привычно. Какую-нибудь другую логику может писать другая команда уже на java. Попытка же найти, собрать и организовать единую команду, которая пишет именно то, что нужно именно на том, на чем хочется — может вылиться в огромный геморрой.
И может оказаться, что состыковать между собой зоопарк разных технологий (не обязательно именно через микросервисы, а возможно и каким-то другим способом, например через адаптеры) — это меньшее из зол.
Здравствуйте, Vetal_ca, Вы писали:
V_>так кроме программ там еще БД, прокси, message brokers и куча всего прочего, уже кем-то написанного. Они уже есть и написаны на разных языках
Только это НЕ микросервисная ахитектура.
Я же выше писал — делой нужного софта в контейнерах — это хорошо. Разбивать свое приложение на компоненты и деплоить их в контейнерах — не ясно зачем.
Здравствуйте, SkyDance, Вы писали:
G>>А вот в чем профит от "микросервисов" — я до сих пор не понял и даже внятных примеров нет.
SD>В том, что можно отвязать циклы разработки свистоперделок от ключевой функциональности. SD>Не работает звук "врруууууум" при запуске двигателя — и фиг бы с ним, голова пусть болит у разработчика сервиса, который этот звук подгружает.
А что мешает добиться того же в обычной программе? Речь тоько об ингорировании ошибок вызовов некоторых функций.
Б>>>Да, например AI может быть написан на python, сервисы на go, интеграция с enterprise на java. G>>Но дешевле все сделать на одном языке. На той же java.
K>Ой не факт.
Не факт. Но матожидание (красивое слово для "среднего") стоимости монолитной программы на java будет ниже, чем программы на нескольких языках.
K>Например, AI с какой-то хитровывернутой логикой может писать команда, которая с java не дружит, а на python пишет привычно.
В соучае с AI такие проблемы уже решены. Можно создавать и обучать модель на python, а дергаеть её из кода на java. Модель по факту вообще можно зааутсорсить.
K>Какую-нибудь другую логику может писать другая команда уже на java. Попытка же найти, собрать и организовать единую команду, которая пишет именно то, что нужно именно на том, на чем хочется — может вылиться в огромный геморрой.
Попытка насти и собрать команду которая делает то же самое на многих языках это геморой еще больше. У меня есть опыт управления командой в 4 языка, это ад.
K>И может оказаться, что состыковать между собой зоопарк разных технологий (не обязательно именно через микросервисы, а возможно и каким-то другим способом, например через адаптеры) — это меньшее из зол.
Вопрос не в стыковке. Это как раз не сложно.
Вопрос в поддерже и в стоимости взаимодействия, как между людьми в команде, так и между компонентами в разных контейнерах.
Здравствуйте, gandjustas, Вы писали:
Б>>Профит микросервисов в их независимости друг от друга: G>Я тоже слышал эти лозунги, но преимущества в чем?
Преимущество — можно раздуть размер команды на ровном месте, обосновать заказчику и в результате получить с него много денег. Это если массовое применение. Ну а немассовое применение — это когда требуется держать высокую нагрузку и много пользователей, каждый микросервис легко масштабировать в облаке и если у нас наплыв пользователей — тупо поднимаем много инстанцев приложения, пользователи убавились и нет такой нагрузки — тушим лишние. При этом поднятие сервисов и их остановка занимает весьма мало времени.
Здравствуйте, gandjustas, Вы писали:
G>Я же выше писал — делой нужного софта в контейнерах — это хорошо. Разбивать свое приложение на компоненты и деплоить их в контейнерах — не ясно зачем.
Несколько примеров,
— чтобы scale-up/scale-down, в зависимости от нагрузки. Особенно, когда разные части по-разному скейлятся.
Да, можно это сделать в коде, но
1) Зачем, если есть отлаженный инструмент
2) Не упереться в вертикальный лимит
3) разный уровень сервиса или надежность. Что-то работает постоянно, что-то перезагружается/падает.
У нас, например, проблема с одним из powershell модулей ms-online. В нем внутри утечка. Индусы про это "знают" уже годами. Не падать же всему приложению. Вот и работает как набор отдельных Workers, освобождается на уровне процесса по сигналу health check.
Это прекрасно работает. А если бы ждали по заветам Шеридана, то до сих пор бы ждали пока починят, поляна бы заросла продуктами конкурентов. Которые гонят отсталых сельских админов-идеалистов на периферию.
Здравствуйте, elmal, Вы писали:
E>Ну а немассовое применение — это когда требуется держать высокую нагрузку и много пользователей, каждый микросервис легко масштабировать в облаке и если у нас наплыв пользователей — тупо поднимаем много инстанцев приложения, пользователи убавились и нет такой нагрузки — тушим лишние. При этом поднятие сервисов и их остановка занимает весьма мало времени.
А что мешает делать тоже самое с монолитным приложением? В чем смысл именно микросервисов?
Здравствуйте, Vetal_ca, Вы писали:
V_>Здравствуйте, gandjustas, Вы писали:
G>>Я же выше писал — делой нужного софта в контейнерах — это хорошо. Разбивать свое приложение на компоненты и деплоить их в контейнерах — не ясно зачем.
V_>Несколько примеров, V_>- чтобы scale-up/scale-down, в зависимости от нагрузки. Особенно, когда разные части по-разному скейлятся.
Для этого обязательна микросервиная архитектура? Кто-то мешает делать то же самое, когда все приложение сотоит из 2-3 частей: фронтэнда, базы, бекэнда для фоновых назад, который может быть часть фронтэнда?
V_>Да, можно это сделать в коде, но V_>1) Зачем, если есть отлаженный инструмент V_>2) Не упереться в вертикальный лимит V_>3) разный уровень сервиса или надежность. Что-то работает постоянно, что-то перезагружается/падает.
Про какой код речь?
V_>У нас, например, проблема с одним из powershell модулей ms-online. В нем внутри утечка. Индусы про это "знают" уже годами. Не падать же всему приложению. Вот и работает как набор отдельных Workers, освобождается на уровне процесса по сигналу health check. V_>Это прекрасно работает. А если бы ждали по заветам Шеридана, то до сих пор бы ждали пока починят, поляна бы заросла продуктами конкурентов. Которые гонят отсталых сельских админов-идеалистов на периферию.
Как в этом случае поможет микросервисная архитекктура?
Я напомню что речь именно об архитектуре когда разработчики разбивают свое приложение на слабосвязанные сервисы, которые могут работать по-отдельности. Это не тоже самое что деплоить пару-тройку компонентов приложения в контейнерах.
V_>Это пара примеров, причин больше, на самом деле.
К соажлению даже эта пара примеров не является достаточно внятным обоснованием для микросервисов. Имхо конечно.
Здравствуйте, gandjustas, Вы писали:
G>А что мешает делать тоже самое с монолитным приложением? В чем смысл именно микросервисов?
То мешает, что узким местом является определенный код. Соответственно то, что является узким местом, нужно оформлять как микросервис, чтоб там было ничего лишнего, и далее масштабировать. Но вообще, ключевое, даже сейчас умные люди на докладах рассказывают что успешные архитектуры — это сначала монолит, а далее этот монолит, когда скорости не хватает — пилят на микросервисы. Таким образом экономится куча времени и денег. Но сейчас толпы народа сразу хреначат микросервисы, и в результате время разработки, количество команд и стоимость возрастает в разы, а то и десятки раз. Но аутсорсу это выгодно, потому сейчас аутсорс монолиты не предлагает, предлагают сразу микросервисы и огромные команды по 100 человек там, где справились бы и 5 за меньшее время .
Здравствуйте, gandjustas, Вы писали:
E>>Ну а немассовое применение — это когда требуется держать высокую нагрузку и много пользователей, каждый микросервис легко масштабировать в облаке и если у нас наплыв пользователей — тупо поднимаем много инстанцев приложения, пользователи убавились и нет такой нагрузки — тушим лишние. При этом поднятие сервисов и их остановка занимает весьма мало времени. G>А что мешает делать тоже самое с монолитным приложением? В чем смысл именно микросервисов?
1. Микросервисов не существует.
2. Сервисная архитектура позволяет, прежде всего, позволяет очень чисто разделять ответственность между разными командами.
Здравствуйте, gandjustas, Вы писали:
G>Только это НЕ микросервисная ахитектура. G>Я же выше писал — делой нужного софта в контейнерах — это хорошо. Разбивать свое приложение на компоненты и деплоить их в контейнерах — не ясно зачем.
Я вот тут плюсану. Уже на этапе проектирования микросервисов приходишь к выводу, как правило, что нужно просто монолит горизонтально масштабировать... При этом монолит может быть распределен по контейнерам вполне. И наброшу немного: DDD рулит!
Здравствуйте, Буравчик, Вы писали:
Б>Здравствуйте, gandjustas, Вы писали:
G>>А вот в чем профит от "микросервисов" — я до сих пор не понял и даже внятных примеров нет.
Б>Профит микросервисов в их независимости друг от друга:
Полная независимость возможна только если сервисы друг друга не вызывают.
Если кто-то может делить приложение на слабосвязные части, зачем после этого выносить эти части в отдельные процессы?
Б>- можно создавать на разных языках/платформах, упрощается дизайн сервисов
Дизайн приложения как целого, состоящего из множества микросервисов, как раз усложняется.
И кроссервисные рефакторинги в будущем будут на порядок сложнее, чем внутри "мАкросервиса".
Возможность писать на разных языках/платформах на практике нужна примерно никогда, работодатели обычно наоборот стремятся все унифицировать, чтобы сделать разработчиков взаимозаменяемыми.
Б>- можно гибко масштабировать — увеличивать количество только нужных сервисов
На первый взгляд звучит как что-то умное. Но в чем преимущество перед масштабированием "мАкросервиса"?
G>Для этого обязательна микросервиная архитектура? Кто-то мешает делать то же самое, когда все приложение сотоит из 2-3 частей: фронтэнда, базы, бекэнда для фоновых назад, который может быть часть фронтэнда?
Если приложение небольшое, то можно. Если большое, то понимание придет само в процессе преодоления проблем роста и разбивания монолита
G>Про какой код речь?
Приложение и вспомогательные сервисы.
G>Как в этом случае поможет микросервисная архитекктура? G>Я напомню что речь именно об архитектуре когда разработчики разбивают свое приложение на слабосвязанные сервисы, которые могут работать по-отдельности. Это не тоже самое что деплоить пару-тройку компонентов приложения в контейнерах.
Микросервис A работает. А микросервис B, его workers, перегружаются по мере накопления утекшей памяти. Никак не влияя на работоспособность A.
Если бы это был один монолитный процесс, то на момент периодической перезагрузки приложение было бы недоступно.
G>К соажлению даже эта пара примеров не является достаточно внятным обоснованием для микросервисов. Имхо конечно.
Если текущая задача не требует, то переусложнять "на вырост" не нужно.
Здравствуйте, artelk, Вы писали:
G>>>А вот в чем профит от "микросервисов" — я до сих пор не понял и даже внятных примеров нет. Б>>Профит микросервисов в их независимости друг от друга: A>Полная независимость возможна только если сервисы друг друга не вызывают.
"Независимость" подразумевает, что у сервиса есть API. А вот как он реализуется — клиентов не интересует.
N>Скажем, у Скайденса на банковском счету вдруг стало 0 денег, счет за комунальные услуги пришел в двойном размере, а магазинная касса занимается приписками в чеках.
В том и дело, что у Скайденса из Новой Зеландии станет 0 денег, а у остальных будет как было. У Васи в Нью-Васюках снимут коммунальные услуги два раза. У Пети из Питтсбурга припишут в кассе.
Так понятнее стало? Да, где-то что-то всегда сломано. Но только где-то и что-то, а не сразу и у всех. "Большие данные" (С)
N>Вопрос в ответственном отношении к работе.
Бизнес — это про деньги, а не про ответственное отношение.
N>Хотя, для детских проектов с тремя пользователями сойдет.
Не угадал.
Наоборот.
Как раз где три пользователя — там все будет сразу видно и заметно. Такой подход (перманентные частичные отказы) работает только на миллионах и миллиардах. Тогда всегда можно перевести стрелки "у вас интернет плохой". А если три пользователя, и у одного не работает, — это сразу треть (!) всех пользователей, серьезный отказ.
Здравствуйте, SkyDance, Вы писали:
N>>Вопрос в ответственном отношении к работе. SD>Бизнес — это про деньги, а не про ответственное отношение.
Кек, у меня многие вопросы исчезли. Вот оно что оказывается. Тяп-ляп-лишь-бы-работало оказывается это ожидаемый бизнесом результат. А люди то не виноваты, они просто делают то что им приказывают владельцы бизнеса.
Здравствуйте, SkyDance, Вы писали:
SD>В "обычной программе" придется разбираться, у кого что падает. А тут сразу видно.
Всегда сочувствую тем, кому запрещают логи писать и метрики расставлять.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, artelk, Вы писали:
Б>>>Профит микросервисов в их независимости друг от друга: A>>Полная независимость возможна только если сервисы друг друга не вызывают. C>"Независимость" подразумевает, что у сервиса есть API. А вот как он реализуется — клиентов не интересует.
У классов есть API, а как он реализуется — клиентов не интересует.
У библиотек функций есть API, а как он реализуется — клиентов не интересует.
В чем преимущество у микросервисов в данном контексте?
Может в том, что параметры функций\методов передаются по значению, т.е. неявно глубоко клонируются при передаче?
Этого же можно добится и без выноса кода в отдельный процесс — либо через сериализацию+десериализацию (то, что сейчас используется в при вызове удаленного сервиса, но без собственно отправки сообщения по сети), либо путем написания генератора декораторов интерфейсов, которые клонируют параметры и возвращаемые значения каждого метода интерфейса. И в Java и в .Net такой генератор пишется на раз и переиспользуется везде где надо, если надо.
Здравствуйте, Буравчик, Вы писали:
Б>Это пока у тебе запросы скромные — 128 Гб и 32 ядра. А если больше, то становится выгоднее взять несколько серверов вместо супермощного.
Нуууу... У нас запросы 3Тб и не-считал-сколько-ядров. Тем не менее разрабы идут по пути минимизации сетевого трафиика, переключаясь на внутрихостовые протоколы взаимодействия. Потому что МЕДЛЕННО.
Мантры "микосервисы"/"мастубирование" на них как-то не действуют
Здравствуйте, artelk, Вы писали:
A>В чем преимущество у микросервисов в данном контексте?
На самом деле выше уже был дан единственный верный ответ. Микросервисы нужны чтобы максимально разграничить ответственность команд.
Правда в подавляющем большинстве случаев это не нужно.
Здравствуйте, artelk, Вы писали:
C>>"Независимость" подразумевает, что у сервиса есть API. А вот как он реализуется — клиентов не интересует. A>У классов есть API, а как он реализуется — клиентов не интересует. A>У библиотек функций есть API, а как он реализуется — клиентов не интересует. A>В чем преимущество у микросервисов в данном контексте?
Библиотека классов будет на том же самом языке, что и пользователи этих классов. Для сервисов это совсем необязательно.
Далее, в большинстве приложений системы сборки позволяют иметь только одну версию библиотек. Так что если какая-то команда хочет использовать более новую версию зависимости (скажем, взять новую версию OpenSSL), то это будет влиять на все остальные команды. В результате, по мере роста проекта такие обновления становятся всё более болезненными. В случае с API всё просто.
Ну и напоследок, в случае с API обычно легко контролировать кто и как его использует, в отличие от библиотеки классов в монолитном приложении.
Здравствуйте, Cyberax, Вы писали:
C>Далее, в большинстве приложений системы сборки позволяют иметь только одну версию библиотек. Так что если какая-то команда хочет использовать более новую версию зависимости (скажем, взять новую версию OpenSSL), то это будет влиять на все остальные команды. В результате, по мере роста проекта такие обновления становятся всё более болезненными. В случае с API всё просто.
Правильно ли я понял что срач разводится в микросервисах проще и быстрее, чем в монолите?
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, artelk, Вы писали:
A>>В чем преимущество у микросервисов в данном контексте?
G>На самом деле выше уже был дан единственный верный ответ. Микросервисы нужны чтобы максимально разграничить ответственность команд.
Это аргумент в пользу того, что сервисы не должны быть слишком большие, т.е. больше, чем одна команда сможет поддерживать и развивать.
Но у микросервисов декларируемая гранулярность же намного выше.
G>Правда в подавляющем большинстве случаев это не нужно. G>В остальном только недостатки.
Здравствуйте, Sheridan, Вы писали:
G>>Установка сложного приложения без докера выглядит так: ... G>>Установка с докером — передать образ и запустить пару команд в командной строке. Всю работу по конфигурации берет на себя разработчик. S>ansible-playbook playbook-deploy.yaml и оно может даже само выкачать всё нужное.
только какая то старая версия может пропасть с серверов, тогда надо делать ее копии у себя и тд
Здравствуйте, mogadanez, Вы писали:
M>только какая то старая версия может пропасть с серверов, тогда надо делать ее копии у себя и тд
Не распарсил... Старая версия чего? Куда пропасть? Зачем сохранить?
Здравствуйте, Sheridan, Вы писали:
S>Не распарсил... Старая версия чего? Куда пропасть? Зачем сохранить?
1) Устновить nodejs\веб-сервер\еще какую-нибудь-фигню версии 15.43.442, именно такой, потому что на другом не тестировалось и корректность работы не гарантируется.
2) Поднять базу на mongodb 12.697 и кэш на редис на 3.974, именно на таких, потому что на других не тестировалось и работоспособность не гарантируется.
S>ansible-playbook playbook-deploy.yaml и оно может даже само выкачать всё нужное.
M>1) Устновить nodejs\веб-сервер\еще какую-нибудь-фигню версии 15.43.442, именно такой, потому что на другом не тестировалось и корректность работы не гарантируется.
M>2) Поднять базу на mongodb 12.697 и кэш на редис на 3.974, именно на таких, потому что на других не тестировалось и работоспособность не гарантируется.
В чём именно проблема?
M>
S>>ansible-playbook playbook-deploy.yaml и оно может даже само выкачать всё нужное.
А, тебе слова не понравились. А почему ты решил что "выкачать всё нужное" означает "выкачать самые последние версии всего подряд"?
ansible это описание деплоя, код. Как напишешь — так и будет.
Здравствуйте, Sheridan, Вы писали:
C>>Далее, в большинстве приложений системы сборки позволяют иметь только одну версию библиотек. Так что если какая-то команда хочет использовать более новую версию зависимости (скажем, взять новую версию OpenSSL), то это будет влиять на все остальные команды. В результате, по мере роста проекта такие обновления становятся всё более болезненными. В случае с API всё просто. S>Правильно ли я понял что срач разводится в микросервисах проще и быстрее, чем в монолите?
Нет, микросервисы не проще и не быстрее монолита. Они позволяют масштабироваться для очень больших проектов, над которыми работает сотни человек.
Здравствуйте, Mamut, Вы писали:
C>>Ну и напоследок, в случае с API обычно легко контролировать кто и как его использует M>Мммм. Ну, это не совсем так.
Зависит от реализации. В Амазоне для использования API обычно требовалось, чтобы команда добавила разрешения для конкретных клиентов.
Здравствуйте, artelk, Вы писали:
A>Это аргумент в пользу того, что сервисы не должны быть слишком большие, т.е. больше, чем одна команда сможет поддерживать и развивать. A>Но у микросервисов декларируемая гранулярность же намного выше.
Гранулярность для сервисов — это не плюс. Скорее минус.
M>только какая то старая версия может пропасть с серверов, тогда надо делать ее копии у себя и тд
Именно так. Как может и не собраться Dockerfile в конкретный момент времени. Пакет устарел, бинарник переложили в другое место или репозиторий временно не работает
Поэтому саму сборку base image не делают частью pipeline. Условно говоря, закэшированный Image + on-demand (GitHub Webhook) image с артифактом, поверх базового.
S>>И правда ведь... Docker — он же не бесплатный по ресурсам, верно? Зачем он, если можно и без него?
M>Без него будет дольше и хуже, чем с ним. Даже несмотря на то, что докер — говно.
M>Ты получаешь одинаковый environment на всех стадиях: в разработке, при тестировании, на staging'е, в production'е. Безо всяких свистоплясток типа «а вот у девелопера будет докер, а вот на тесте развернем ansible'ом, а в проде тоже развернем ansible'ом, но надо еще извернуться, чтобы куда-то security-sensitive ключи засунуть» (хотя докер, естественно, не решает проблему ключей).
M>Получить на dev-машине такой же environment, как на prod'е — бесценно. Остальное — мелочи жизни.
Одинаковость environments при использовании docker слишком преувеличена
Здравствуйте, Cyberax, Вы писали:
S>>Правильно ли я понял что срач разводится в микросервисах проще и быстрее, чем в монолите? C>Нет, микросервисы не проще и не быстрее монолита. Они позволяют масштабироваться для очень больших проектов, над которыми работает сотни человек.
Или библиотеки.
S>Всегда сочувствую тем, кому запрещают логи писать и метрики расставлять.
Ты всерьез думаешь, что другим командам интересно читать твои логи и изучать твои метрики, чтобы создать тикет на тебя?
Нет, если у твоего сервиса постоянные OOM, это должно быть только твоей проблемой. А не тех, кому ты свой код хочешь подсунуть на деплоймент.
C>>>Ну и напоследок, в случае с API обычно легко контролировать кто и как его использует M>>Мммм. Ну, это не совсем так. C>Зависит от реализации. В Амазоне для использования API обычно требовалось, чтобы команда добавила разрешения для конкретных клиентов.
Заморочки Амазона. Далеко не все так заморачиваются.
M>>Получить на dev-машине такой же environment, как на prod'е — бесценно. Остальное — мелочи жизни.
D>Одинаковость environments при использовании docker слишком преувеличена
Здравствуйте, SkyDance, Вы писали:
S>>Всегда сочувствую тем, кому запрещают логи писать и метрики расставлять. SD>Ты всерьез думаешь, что другим командам интересно читать твои логи и изучать твои метрики, чтобы создать тикет на тебя?
А тебе запрещают добавить опции "err,wrn,nfo,dbg"? Владелец бизнеса тоже против?
Здравствуйте, Sheridan, Вы писали:
S>>>Правильно ли я понял что срач разводится в микросервисах проще и быстрее, чем в монолите? C>>Нет, микросервисы не проще и не быстрее монолита. Они позволяют масштабироваться для очень больших проектов, над которыми работает сотни человек. S>Или библиотеки.
Нет, даже близко так не получается.
Здравствуйте, namespace, Вы писали:
N>Скажем, у Скайденса на банковском счету вдруг стало 0 денег, счет за комунальные услуги пришел в двойном размере, а магазинная касса занимается приписками в чеках.
Ну если ему еще и телефон заблокировать, и условно-досрочное освобождение из базы полиции стереть, то почему бы и нет, никто и не заметит такую ошибку.
Здравствуйте, gandjustas, Вы писали:
Б>>Да, например AI может быть написан на python, сервисы на go, интеграция с enterprise на java. G>Но дешевле все сделать на одном языке. На той же java.
Это если ты с код с нуля пишешь, и команда программистов у тебя профессиональная и сплоченная.
А если у тебя весь твой код свинчен из разнородных запчастей, собраных со всего гитхаба, а в программисты ты записал нищих, которых подобрал у ближайшей церкви, то может оказаться, что у тебя и запчасти все на разных языках написаны, и программисты твои каждый умеет немного на своем каком-то языке, и никто не способен изучить другой язык.
Вот тогда у тебя и получится описанная выше каша.
Б>>Ну и упрощение сервисов — маленькую программу написать проще, также как и переписать с нуля при необходимости. G>Написать одну большую программу проще, чем кучу маленьких, в сумме дающих функциональность большой.
Вот это как раз спорный вопрос. Всякие там классы затем и придумали, чтобы запчасти большой системы не рылись в памяти друг у друга. Разнесение на отдельные процессы помогает этой изоляции еще больше.
легендарный Sheridan:
S>И правда ведь... Docker — он же не бесплатный по ресурсам, верно? Зачем он, если можно и без него?
Как раз-таки для разработки и надо, особенно если делать чисты билд. Без малейшей связи с теми библиотеками, что уже "прописались" на компьютере разработчика.
Dockerfile из минималистичного базового image и есть кристаллизованный-чистый билд. Где четко видны зависимости build-time и runtime
Например, "набросал" свой Dockerfile для FreeSwitch. И вся эта куча доп-пакетов не заполоняет мой Linux сервер. И нет никаких личных readme.md, как я вручную собирал бы этот FreeSwitch
Здравствуйте, Vetal_ca, Вы писали:
V_>Поэтому саму сборку base image не делают частью pipeline. Условно говоря, закэшированный Image + on-demand (GitHub Webhook) image с артифактом, поверх базового.
да именно так. и это большой бонус
тру стори — понадобилось собрать проект который 3 года лежал на полке, много библиотек старых версий было недоступно, под новые местами понадобилось переписывать код, одно тянуло другое, в общем убил дня 3. а потом нашел base-image
S>А, тебе слова не понравились. А почему ты решил что "выкачать всё нужное" означает "выкачать самые последние версии всего подряд"? S>ansible это описание деплоя, код. Как напишешь — так и будет.
нужных версий может не оказаться там где они были спустя год-два-три. как писали выше в случае докера как правило используют base-image со стабильным зафиксированным окружением
Здравствуйте, mogadanez, Вы писали:
S>>А, тебе слова не понравились. А почему ты решил что "выкачать всё нужное" означает "выкачать самые последние версии всего подряд"? S>>ansible это описание деплоя, код. Как напишешь — так и будет.
M> нужных версий может не оказаться там где они были спустя год-два-три. как писали выше в случае докера как правило используют base-image со стабильным зафиксированным окружением
Да, ты прав. Грустно когда запрещают делать локальный кеш и писать код исключительно на древних версиях чегототам
Здравствуйте, mogadanez, Вы писали:
S>>Да, ты прав. Грустно когда запрещают делать локальный кеш M>не запрещают, но это надо делать, или оно из коробки бывает в том же ансибле?
А ты свой код так-же из коробки достаёшь?
S>>и писать код исключительно на древних версиях чегототам M>иногда на новой просто не работает а рук переписать не хватает.
Ой вей, надо работать, а пальчики устали. А если учесть предыдущий пункт, то дважды устали. Какая досада.
Здравствуйте, mogadanez, Вы писали:
M>тру стори — понадобилось собрать проект который 3 года лежал на полке, много библиотек старых версий было недоступно, под новые местами понадобилось переписывать код, одно тянуло другое, в общем убил дня 3. а потом нашел base-image
Аааа, вот оно что. Три дня пришлось гуглить? Теперь понятно почему ты не знаешь что такое ansible и как он работает. Это ж неделю гуглить надо, минимум.
Здравствуйте, Shmj, Вы писали:
S>И правда ведь... Docker — он же не бесплатный по ресурсам, верно? Зачем он, если можно и без него?
Рабсила тестировщиков, разработчиков, девопсов и админов она что, бесплатная?
Небольшая команда 5 человек стоит в год, при зп 1000$ на единицу 60000$
Реальная зп и большая команда гораздо выше, потому год разработки от 1КК и выше.
Соответственно, если доккер экономит вагон времени, то сэкономленые деньги можно потратить и на амазоновский план.
Здравствуйте, Sheridan, Вы писали:
S>Здравствуйте, mogadanez, Вы писали:
M>>тру стори — понадобилось собрать проект который 3 года лежал на полке, много библиотек старых версий было недоступно, под новые местами понадобилось переписывать код, одно тянуло другое, в общем убил дня 3. а потом нашел base-image S>Аааа, вот оно что. Три дня пришлось гуглить? Теперь понятно почему ты не знаешь что такое ansible и как он работает. Это ж неделю гуглить надо, минимум.
почему гуглить? обновлял код/ местами переписывал большие куски
и про ансибл я знаю =)и тераформ и сhef и puppet. в разное время со всеми работал.
никто кстати не мешает пользовать ansible вместе c докером они не взаимоисключающие опции, скорее даже нооборот из разных плоскостей
Здравствуйте, mogadanez, Вы писали:
M>никто кстати не мешает пользовать ansible вместе c докером они не взаимоисключающие опции, скорее даже нооборот из разных плоскостей
Абсолютно верно. И если можно то-же самое сделать ансиблом без контейнеров — то зачем контейнеры? Мода?
Здравствуйте, Sheridan, Вы писали:
S>Здравствуйте, mogadanez, Вы писали:
M>>никто кстати не мешает пользовать ansible вместе c докером они не взаимоисключающие опции, скорее даже нооборот из разных плоскостей S>Абсолютно верно. И если можно то-же самое сделать ансиблом без контейнеров — то зачем контейнеры? Мода?
ну например не зависит от хост машины вообще, не будет разбирательств что на этом сервере не работает потому что libXXX отсутсвует или не той версии
например на разных линукс дистрибутивах может быть systemd, openrc и прочий зоопарк и
можно запустить несколько копий одного и того же, например актуально для ноды чтобы не делать "кластер". Или в случае очень мощного сервера запустить несколько приложений условно независимо, у каждого
запускается быстро. например в случае ансибла либо вся инициализация будет на новом инстансе с нуля довольно продолжительное время либо городить промежуточное создание образов( например с ec2_ami) но по моим воспоминаниям это еще тот геморой
P.S.
больше 5 лет использую докер в продакшене в нагруженных системах
S>А ты свой код так-же из коробки достаёшь?
S>Ой вей, надо работать, а пальчики устали. А если учесть предыдущий пункт, то дважды устали. Какая досада.
Кое где еще Cobol используется. Как ты думаешь, куда были посланы специалисты, далекие от бизнес-реальности?
Поставят старый код со старыми библиотеками, изолируют. Добавят healthchecks, кубернетесы будут подымать и перестартовать, не важно, дефектный код или нет. И будет работать, приносить деньги, вместо того чтобы ждать с моря погоды или пока конкуренты рынок отберут. Надежнее чем полностью "рабочее" на словах.
IT это инструмент для бизнеса. Для решения насущных задач. Сам по себе идеализм никому не уперся и никто за это платить не будет, если выхлопа нет.
Здравствуйте, mogadanez, Вы писали:
M>>>никто кстати не мешает пользовать ansible вместе c докером они не взаимоисключающие опции, скорее даже нооборот из разных плоскостей S>>Абсолютно верно. И если можно то-же самое сделать ансиблом без контейнеров — то зачем контейнеры? Мода?
M>ну например не зависит от хост машины вообще, не будет разбирательств что на этом сервере не работает потому что libXXX отсутсвует или не той версии
Ну так добавить пакет. Это — проблема?
Я, например, вообще под каждый проект деплою сверху ещо репозиторий с нужными проекту пакетами.
M>например на разных линукс дистрибутивах может быть systemd, openrc и прочий зоопарк и
С этим разбирается сам ансибл. Или ты про установку сервиса? Тогда скрипт запуска плюс x тасков на добавление сервиса, по таску на каждый целевой rc...
M>можно запустить несколько копий одного и того же, например актуально для ноды чтобы не делать "кластер". Или в случае очень мощного сервера запустить несколько приложений условно независимо, у каждого
В чём проблема? У меня на одном проекте крутятся три редиса (не спрашивайте зачем). Конфиги деплоятся из единого шаблона, различия небольшие и видимы сразу.
M>запускается быстро. например в случае ансибла либо вся инициализация будет на новом инстансе с нуля довольно продолжительное время либо городить промежуточное создание образов( например с ec2_ami) но по моим воспоминаниям это еще тот геморой
А если выкинуть контейнеры — то деплой ансиблом тоже занимает минуты.
M>P.S. M>больше 5 лет использую докер в продакшене в нагруженных системах
Сочувствую
Здравствуйте, Vetal_ca, Вы писали:
S>>А ты свой код так-же из коробки достаёшь? S>>Ой вей, надо работать, а пальчики устали. А если учесть предыдущий пункт, то дважды устали. Какая досада.
V_>Кое где еще Cobol используется. Как ты думаешь, куда были посланы специалисты, далекие от бизнес-реальности?
Верно, бизнес не гоняется за модой. Бизнесу нужно деньги делать, а не модные ништяки изучать.
Более того, у бизнеса деплой уже давно и никто его даже на ансибл вряд ли будет переводить, не говоря уже про контейнеры.
Или ты про стартапчики?
V_>Поставят старый код со старыми библиотеками, изолируют. Добавят healthchecks, кубернетесы будут подымать и перестартовать, не важно, дефектный код или нет. И будет работать, приносить деньги, вместо того чтобы ждать с моря погоды или пока конкуренты рынок отберут. Надежнее чем полностью "рабочее" на словах.
Почему этого нельзя сделать без контейнеров? Сложна? Ну отдайте задачу специалисту. Ему, в отличии от неспециалистов, будет несложно.
V_>IT это инструмент для бизнеса. Для решения насущных задач. Сам по себе идеализм никому не уперся и никто за это платить не будет, если выхлопа нет.
.* это инструмент для бизнеса. Для решения насущных задач. Сам по себе идеализм никому не уперся и никто за это платить не будет, если выхлопа нет.
Такая себе "мудрость", крч.
S>Верно, бизнес не гоняется за модой. Бизнесу нужно деньги делать, а не модные ништяки изучать. S>Более того, у бизнеса деплой уже давно и никто его даже на ансибл вряд ли будет переводить, не говоря уже про контейнеры. S>Или ты про стартапчики?
Если Google, Microsoft, Bell, Morgan Stanley, Nuance и прочие — стартапчики, то, да.
S>Почему этого нельзя сделать без контейнеров? Сложна? Ну отдайте задачу специалисту. Ему, в отличии от неспециалистов, будет несложно.
Давай, расскажи мне, что будет если накатить 500 разных palybooks на один 128Gb/20 Core инстанс. Зуб даешь, что между зоопарками библиотекам будет взаимный мир и спокойствие?
А как насчет redundancy, unification, self-repairing, unified monitoring и прочим, что не вписывается в твое виденье мира "проще -> надежнее" ?
S>.* это инструмент для бизнеса. Для решения насущных задач. Сам по себе идеализм никому не уперся и никто за это платить не будет, если выхлопа нет. S>Такая себе "мудрость", крч.
Это необходимая мудрость, если хочешь вырасти чуть выше простого исполнителя.
Здравствуйте, Vetal_ca, Вы писали:
S>>Верно, бизнес не гоняется за модой. Бизнесу нужно деньги делать, а не модные ништяки изучать. S>>Более того, у бизнеса деплой уже давно и никто его даже на ансибл вряд ли будет переводить, не говоря уже про контейнеры. S>>Или ты про стартапчики? V_>Если Google, Microsoft, Bell, Morgan Stanley, Nuance и прочие — стартапчики, то, да.
Ну то есть ты имеешь в виду то, о чём я говорил в самом начале. Зачем тогда это принёс если я изначально говорил что есть варианты когда докеры опрадваны?
S>>Почему этого нельзя сделать без контейнеров? Сложна? Ну отдайте задачу специалисту. Ему, в отличии от неспециалистов, будет несложно. V_>Давай, расскажи мне, что будет если накатить 500 разных palybooks на один 128Gb/20 Core инстанс. Зуб даешь, что между зоопарками библиотекам будет взаимный мир и спокойствие?
500 плейбуков? Ты точно уверен что понимаешь как это работает? Я вот вижу что нет.
V_>А как насчет redundancy, unification, self-repairing, unified monitoring и прочим, что не вписывается в твое виденье мира "проще -> надежнее" ?
А в чём проблема?
Здравствуйте, mogadanez, Вы писали:
S>>А если выкинуть контейнеры — то деплой ансиблом тоже занимает минуты. M>докер это секунды а не минуты
Да-да. Рассказывай мне про секундное генерирование образов.
Здравствуйте, Sheridan, Вы писали:
S>Здравствуйте, mogadanez, Вы писали:
S>>>А если выкинуть контейнеры — то деплой ансиблом тоже занимает минуты. M>>докер это секунды а не минуты S>Да-да. Рассказывай мне про секундное генерирование образов.
Здравствуйте, Sheridan, Вы писали:
S>>>Верно, бизнес не гоняется за модой. Бизнесу нужно деньги делать, а не модные ништяки изучать. S>>>Более того, у бизнеса деплой уже давно и никто его даже на ансибл вряд ли будет переводить, не говоря уже про контейнеры. S>>>Или ты про стартапчики? V_>>Если Google, Microsoft, Bell, Morgan Stanley, Nuance и прочие — стартапчики, то, да. S>Ну то есть ты имеешь в виду то, о чём я говорил в самом начале. Зачем тогда это принёс если я изначально говорил что есть варианты когда докеры опрадваны?
Еще раз, по выделенному, четко и ясно:
Не
ансибл вряд ли будет переводить, не говоря уже про контейнеры
— флагманы (не стартапчики) уже перевели. Или отвечай четко или не ссылайся на личные мыслительные процессы — это бессмысленно извне черепной коробки.
S>500 плейбуков? Ты точно уверен что понимаешь как это работает? Я вот вижу что нет.
И как ты будешь обеспечивать ндивидуальные депенденси ? Тот же, OpenSSL? Только не надо повторять вручную (chroot) то, что делает докер изкоробки.
Как ты планируешь изолировать network namespaces? Или, например, поддерживает приложение только bind all или только один интерфейс. А надо 2 специфичных.
Переехало приложение планировщиком (ха-ха, Ансиблом) на другой node — в динамике будешь свой Ansible запускать и старый мусор за собой чистить?
Как будешь сеть сегментировать? Или, например, mTLS, включаемый "по щелчку" (пример). Я уж не говорю, про какой нибудь SRv6 и прочие радости
V_>>А как насчет redundancy, unification, self-repairing, unified monitoring и прочим, что не вписывается в твое виденье мира "проще -> надежнее" ?
S>А в чём проблема?
Ага, дайте мне 2 года и я все сделаю, стамеской и рубанком Не проходит в реальном мире.
Здравствуйте, Sheridan, Вы писали:
S>Я, например, вообще под каждый проект деплою сверху ещо репозиторий с нужными проекту пакетами. S>В чём проблема? У меня на одном проекте крутятся три редиса (не спрашивайте зачем). Конфиги деплоятся из единого шаблона, различия небольшие и видимы сразу.
А если разные версии? Условно, вдруг у них разные зависимости? И весть этот зоопарк вместе с разными зависимостями ставится на бедный хост?
S>А если выкинуть контейнеры — то деплой ансиблом тоже занимает минуты.
Зачем ты противопоставляешь эти инструменты? Не ходи сюда — https://www.ansible.com/integrations/containers/docker. Тебе уже, кстати, писали, что их совместно нормальные люди используют.
M>>P.S. M>>больше 5 лет использую докер в продакшене в нагруженных системах S>Сочувствую
Кто-то: все хорошо, удобно, отлично работает и не кашляет.
Шеридан: сочувствую.
Здравствуйте, mogadanez, Вы писали:
S>>>>А если выкинуть контейнеры — то деплой ансиблом тоже занимает минуты. M>>>докер это секунды а не минуты S>>Да-да. Рассказывай мне про секундное генерирование образов. M>причем тут генерация?
А, то есть вы в прод запихиваете образа сразу с докерхаба? Мо-лод-цы.
Здравствуйте, Vetal_ca, Вы писали:
S>>Ну то есть ты имеешь в виду то, о чём я говорил в самом начале. Зачем тогда это принёс если я изначально говорил что есть варианты когда докеры опрадваны? V_>Еще раз, по выделенному...
Чтото я не понял куда тебя занесло. Я про это
говорил.
S>>500 плейбуков? Ты точно уверен что понимаешь как это работает? Я вот вижу что нет. V_>И как ты будешь обеспечивать ндивидуальные депенденси ? Тот же, OpenSSL? Только не надо повторять вручную (chroot) то, что делает докер изкоробки.
Идеальный вариант — розгами по пальцам разрабочиков.
V_>Как ты планируешь изолировать network namespaces? Или, например, поддерживает приложение только bind all или только один интерфейс. А надо 2 специфичных.
Не уверен что правильно тебя понял... Разработчик заленился и тупо биндит сразу на все интерфейсы? Отрезать лишний трафик стеной. Нужно один на два интерфейса? Да сколько угодно. Навскидку пара способов в голове.
V_>Переехало приложение планировщиком (ха-ха, Ансиблом) на другой node — в динамике будешь свой Ansible запускать и старый мусор за собой чистить?
А при чом тут докер-специфик задача? Это за докером чистить надо. Ансибл сразу чисто делает.
Почему ноду надо чистить? Обратный переезд не планируется, чтоли, когда сервис на другой ноде сделает "ой" и надо будет опять кудато переежжать? Или нода помечается как проклятая и надо после очистки еще и креститься?
V_>Как будешь сеть сегментировать?
Это базовые навыки обычного админа. Непонятно зачем ты это сюда притащил. С этим у докеров сложности? Да вроде не припомню.
V_>Или, например, mTLS, включаемый "по щелчку" (пример).
Я не пойму, ты по площадаям, что ли, начал бить, чтобы хоть куда-то попасть?
Не вижу проблем сделать, даже "по щелчку". ТЗ только дайте.
V_>Я уж не говорю, про какой нибудь SRv6 и прочие радости
В смысле железку за терминал потрогать, маршрутизацию настроить? А в чём проблема?
V_>>>А как насчет redundancy, unification, self-repairing, unified monitoring и прочим, что не вписывается в твое виденье мира "проще -> надежнее" ? S>>А в чём проблема? V_>Ага, дайте мне 2 года и я все сделаю, стамеской и рубанком Не проходит в реальном мире.
Ты на порядок ошибся минимум. Ты себе сроки так же выставляешь?
Здравствуйте, Farsight, Вы писали:
S>>Я, например, вообще под каждый проект деплою сверху ещо репозиторий с нужными проекту пакетами. S>>В чём проблема? У меня на одном проекте крутятся три редиса (не спрашивайте зачем). Конфиги деплоятся из единого шаблона, различия небольшие и видимы сразу. F>А если разные версии? Условно, вдруг у них разные зависимости? И весть этот зоопарк вместе с разными зависимостями ставится на бедный хост?
Я хз как у вас получается, но пока что мне доставались нормаотные программисты, которые умеют в обновление.
Да хоть в лоб — расложить разные версии по разным фолдерам и об лдлибрарипатх разрулить.
S>>А если выкинуть контейнеры — то деплой ансиблом тоже занимает минуты. F>Зачем ты противопоставляешь эти инструменты? Не ходи сюда — https://www.ansible.com/integrations/containers/docker. Тебе уже, кстати, писали, что их совместно нормальные люди используют.
Ансибл это деплой. Чего угодно — от биоса до этих ваших докеров.
Ансиблом можно задеплоить проект в контейнеры. А можно и без контейнеров. А раз можно избавиться от лишней сущности, то почему не избавиться?
Я тебе написал, что требуется, стартапам и не стартапам.
V_>>И как ты будешь обеспечивать ндивидуальные депенденси ? Тот же, OpenSSL? Только не надо повторять вручную (chroot) то, что делает докер изкоробки. S>Идеальный вариант — розгами по пальцам разрабочиков.
Я предлагаю более реалистичный сценарий: нерадивого девопса с замашками наполеона на утилизацию.
С чего я начал докер:
Был личный VPSб Ubuntu 14.04. С настроенным FreeSwitch и еще кучей программ.
Понадобился HTTP/2. Соответственно, круговая зависимость привела к выводу — нужен новый OpenSSL. А этот OpenSSL фиг там без обновления ОС изменишь.
Типичная бизнес-задача, хоть и под себя. Надо запустить а бюджета (времени) на переустановку нет. Кого тут будешь бить?
В общем, запустилось очень хорошо в докере
S>Не уверен что правильно тебя понял... Разработчик заленился и тупо биндит сразу на все интерфейсы? Отрезать лишний трафик стеной. Нужно один на два интерфейса? Да сколько угодно. Навскидку пара способов в голове.
Какая Firewall, сторонник простоты, блин, одна срочка, стандартно и просто. Компоненты должны изолироваться извне и изнутри. Как ты каждому дашь свой localhost, например без Net NS?
S>А при чом тут докер-специфик задача? Это за докером чистить надо. Ансибл сразу чисто делает. S>Почему ноду надо чистить? Обратный переезд не планируется, чтоли, когда сервис на другой ноде сделает "ой" и надо будет опять кудато переежжать? Или нода помечается как проклятая и надо после очистки еще и креститься?
Нормально чистит докер файловую систему. А высокоуровневые объекты чистит Кубернетес. Или "docker system prune"
Пример переезда: приехал более "важный" компонент, контейнер должен переселиться на другой node.
S>Это базовые навыки обычного админа. Непонятно зачем ты это сюда притащил. С этим у докеров сложности? Да вроде не припомню.
На словах, как всегда.
S>Я не пойму, ты по площадаям, что ли, начал бить, чтобы хоть куда-то попасть? S>Не вижу проблем сделать, даже "по щелчку". ТЗ только дайте.
После самоката на вертолет? Ну, типа, видел как летает К исходному тезису, раз любишь возвращаться в начало — какое ТЗ отсеяным?
V_>>Я уж не говорю, про какой нибудь SRv6 и прочие радости S>В смысле железку за терминал потрогать, маршрутизацию настроить? А в чём проблема?
Нет, это не принтер за картридж трогать, это SDN
S>Ты на порядок ошибся минимум. Ты себе сроки так же выставляешь?
Я быстро отсеиваю непригодных.
Непригодные — это не те кто (пока) не знает. А те кто не знает и не поддается обучению.
Здравствуйте, Sheridan, Вы писали:
S>А при чом тут докер-специфик задача? Это за докером чистить надо. Ансибл сразу чисто делает.
ЩИТО? Анзибль — это просто выполнялка команд, он сам ничего не чистит.
В отличие от анзибля, докер гарантирует, что выполняемый контейнер не оставит НИЧЕГО на хосте (если специально не захотеть обратного).
Здравствуйте, Sheridan, Вы писали:
S>Я хз как у вас получается, но пока что мне доставались нормаотные программисты, которые умеют в обновление. S>Да хоть в лоб — расложить разные версии по разным фолдерам и об лдлибрарипатх разрулить.
Не про обновление вопрос. Я могу рядом с боевой версией поставить старую, которая живет на старых версиях компонентов, сделать дела и снести без следа. Зачем мне гемор с установкой всего этого зоопарка на хост???
S>Ансибл это деплой. Чего угодно — от биоса до этих ваших докеров. S>Ансиблом можно задеплоить проект в контейнеры. А можно и без контейнеров. А раз можно избавиться от лишней сущности, то почему не избавиться?
Докер не только деплой. Это еще и одинаковое окружение. Это бесценно.
Ты может хоть что-то кроме теории о надежности предоставишь в качестве аргумента?
говорил. V_>Я тебе написал, что требуется, стартапам и не стартапам.
Тогда читай что писал я и сопоставляй.
V_>>>И как ты будешь обеспечивать ндивидуальные депенденси ? Тот же, OpenSSL? Только не надо повторять вручную (chroot) то, что делает докер изкоробки. S>>Идеальный вариант — розгами по пальцам разрабочиков. V_>Я предлагаю более реалистичный сценарий: нерадивого девопса с замашками наполеона на утилизацию.
Ну да, виноват то в бардаке проекта девапс.
V_>С чего я начал докер: V_>Был личный VPSб Ubuntu 14.04. С настроенным FreeSwitch и еще кучей программ. V_>Понадобился HTTP/2. Соответственно, круговая зависимость привела к выводу — нужен новый OpenSSL. А этот OpenSSL фиг там без обновления ОС изменишь. V_>Типичная бизнес-задача, хоть и под себя. Надо запустить а бюджета (времени) на переустановку нет. Кого тут будешь бить?
Себя конечно. И учиться читать. Я писал что докер для разрабоки — очень круто и удобно.
Добавлю что это ещо круче и удобнее когда не умеешь в админство.
S>>Не уверен что правильно тебя понял... Разработчик заленился и тупо биндит сразу на все интерфейсы? Отрезать лишний трафик стеной. Нужно один на два интерфейса? Да сколько угодно. Навскидку пара способов в голове. V_>Какая Firewall, сторонник простоты, блин, одна срочка, стандартно и просто. Компоненты должны изолироваться извне и изнутри.
Левая рука не доверяет правой? Нахрена изнутри то? Чтобы было?
V_>Как ты каждому дашь свой localhost, например без Net NS?
И не подумаю так желать. Ибо глупость. Не вижу вообще необходимости кроме как исправлять проблему отсутствия у разработчика здравого смысла и захардкоживания порта. Правильным решением будет исправление кода в целях добавления нужной опции.
S>>А при чом тут докер-специфик задача? Это за докером чистить надо. Ансибл сразу чисто делает. S>>Почему ноду надо чистить? Обратный переезд не планируется, чтоли, когда сервис на другой ноде сделает "ой" и надо будет опять кудато переежжать? Или нода помечается как проклятая и надо после очистки еще и креститься? V_>Нормально чистит докер файловую систему. А высокоуровневые объекты чистит Кубернетес. Или "docker system prune"
Вот-вот. Само наличие таких команд говорит о том что мусора там дохрена.
V_>Пример переезда: приехал более "важный" компонент, контейнер должен переселиться на другой node.
И вместо полезной работы будем заниматься копированием образов туда-сюда в рантайме. Кто там говорил что докер разворачивается секунды? Ну-ну.
S>>Это базовые навыки обычного админа. Непонятно зачем ты это сюда притащил. С этим у докеров сложности? Да вроде не припомню. V_>На словах, как всегда.
Ходи голодный.
S>>Я не пойму, ты по площадаям, что ли, начал бить, чтобы хоть куда-то попасть? S>>Не вижу проблем сделать, даже "по щелчку". ТЗ только дайте. V_>После самоката на вертолет? Ну, типа, видел как летает К исходному тезису, раз любишь возвращаться в начало — какое ТЗ отсеяным?
Да, с докера очень сложно в ансибл. После двух колёс наличие двух винтов очень непривычно. Настолько, что продолжаешь думать в 2Д, планируя маршрут.
V_>>>Я уж не говорю, про какой нибудь SRv6 и прочие радости S>>В смысле железку за терминал потрогать, маршрутизацию настроить? А в чём проблема? V_>Нет, это не принтер за картридж трогать,
Извинись.
V_>это SDN
Да нет проблем развернуть ансиблом что угодно. Это не докер же.
S>>Ты на порядок ошибся минимум. Ты себе сроки так же выставляешь? V_>Я быстро отсеиваю непригодных.
Молодец. Так а со сроками себ что?
V_>Непригодные — это не те кто (пока) не знает. А те кто не знает и не поддается обучению.
Отсей себя.
Здравствуйте, Cyberax, Вы писали:
S>>А при чом тут докер-специфик задача? Это за докером чистить надо. Ансибл сразу чисто делает. C>Анзибль — это просто выполнялка команд,
Докер это просто chroot.
C>он сам ничего не чистит.
Чистит за собой он, чистит. Не там и не то что ты думаешь, правда.
C>В отличие от анзибля, докер гарантирует, что выполняемый контейнер не оставит НИЧЕГО на хосте (если специально не захотеть обратного).
Ансибл за собой тоже ничего на хосте не оставляет после деплоя.
Или ты про удаление проекта с хоста? Зачем тогда ставить?
Впрочем насрать. Надо будет — значит будет плейбук и про удаление.
Здравствуйте, Farsight, Вы писали:
S>>Я хз как у вас получается, но пока что мне доставались нормаотные программисты, которые умеют в обновление. S>>Да хоть в лоб — расложить разные версии по разным фолдерам и об лдлибрарипатх разрулить. F>Не про обновление вопрос. Я могу рядом с боевой версией поставить старую, которая живет на старых версиях компонентов, сделать дела и снести без следа.
Ты правда не понимаешь о чём я написал или споришь ради спора?
F>Зачем мне гемор с установкой всего этого зоопарка на хост???
Абсолютно верно, он вообще никому не нужен и я знаю как этого избежать.
S>>Ансибл это деплой. Чего угодно — от биоса до этих ваших докеров. S>>Ансиблом можно задеплоить проект в контейнеры. А можно и без контейнеров. А раз можно избавиться от лишней сущности, то почему не избавиться? F>Докер не только деплой. Это еще и одинаковое окружение. Это бесценно.
Ну так и ансибл приводит хосты к такому-же состоянию. Как деплой опишешь — так и будет.
F>Ты может хоть что-то кроме теории о надежности предоставишь в качестве аргумента?
А что, тебе недостаточно?
Здравствуйте, Sheridan, Вы писали:
S>Ты правда не понимаешь о чём я написал или споришь ради спора?
Расскажи мне про спор ради спора, ага. Еще раз, для особо одаренных: я не спрашивал про обновления, мне надо рядом проставить старую версию, у которой старые зависимости.
S>Абсолютно верно, он вообще никому не нужен и я знаю как этого избежать.
Твои знания связаны с установкой зоопарка на хост, а зачем с чисткой хвостов. Это таки гемор.
S>Ну так и ансибл приводит хосты к такому-же состоянию. Как деплой опишешь — так и будет.
Я разрабатываю на Windows. У одного клиента сервера на линуксе, второй живет в Azure. "ой, а на моем компьютере все работает". Ансибл?
S>А что, тебе недостаточно?
Ээмм, нет... Есть еще практический опыт, которого нет у тебя. Твоя аргументация: докер круто для разработки но в продакшн ни-ни, потому что теория о надежности. Так что да, еще раз расскажи мне про спор ради спора.
Здравствуйте, Farsight, Вы писали:
S>>Ты правда не понимаешь о чём я написал или споришь ради спора? F>Расскажи мне про спор ради спора, ага. Еще раз, для особо одаренных: я не спрашивал про обновления, мне надо рядом проставить старую версию, у которой старые зависимости.
Почему ты решил что это невозможно?
S>>Абсолютно верно, он вообще никому не нужен и я знаю как этого избежать. F>Твои знания связаны с установкой зоопарка на хост, а зачем с чисткой хвостов. Это таки гемор.
Нет.
S>>Ну так и ансибл приводит хосты к такому-же состоянию. Как деплой опишешь — так и будет. F>Я разрабатываю на Windows. У одного клиента сервера на линуксе, второй живет в Azure. "ой, а на моем компьютере все работает". Ансибл? https://docs.ansible.com/ansible/latest/scenario_guides/guide_azure.html
S>>А что, тебе недостаточно? F>Ээмм, нет... Есть еще практический опыт, которого нет у тебя. Твоя аргументация: докер круто для разработки но в продакшн ни-ни, потому что теория о надежности. Так что да, еще раз расскажи мне про спор ради спора.
Твоя аргументация: разрабаам лень разбираться, поэтому докер.
Предотвращая бесполезный спор — разрабы и не должны разбираться. Это должен делать девапс/админ.
Здравствуйте, Sheridan, Вы писали:
S>Почему ты решил что это невозможно?
Я не решал. Все возможно. Но это время и деньги. И гемор. Но, с учетом того что в заказной командной разработке ты не участвовал, тебе не понять. Впрочем, тебе об этом уже столько раз писали, толку ноль.
S>Нет.
Да как-то, особенно когда времени в обрез.
S>https://docs.ansible.com/ansible/latest/scenario_guides/guide_azure.html
Деплой это полбеды. Что с окружением?
S>Твоя аргументация: разрабаам лень разбираться, поэтому докер. S>Предотвращая бесполезный спор — разрабы и не должны разбираться. Это должен делать девапс/админ.
"Разрабам лень разбираться..."... плохие разрабы... и тут же "разрабы и не должны разбираться"... Биполярочка накрыла?
Адним, в случае клиента со своими мощностями должен обеспечивать работоспособность серверов и самого кластера. С разработкой, деплоем, обновлением и мониторингом разберуться без него разрабы и девопсы. А в случае с облаками... У того клиента нет админов .
Здравствуйте, Sheridan, Вы писали:
S>>>А при чом тут докер-специфик задача? Это за докером чистить надо. Ансибл сразу чисто делает. C>>Анзибль — это просто выполнялка команд, S>Докер это просто chroot.
Не совсем. Там ещё композитная файловая система (с оверлеями). Так что изменения, сделанные внутри контейнера, не меняют изображение. Ну и изоляция процессов внутри namespace'ов.
C>>он сам ничего не чистит. S>Чистит за собой он, чистит. Не там и не то что ты думаешь, правда.
И как и что оно будет чистить?
C>>В отличие от анзибля, докер гарантирует, что выполняемый контейнер не оставит НИЧЕГО на хосте (если специально не захотеть обратного). S>Ансибл за собой тоже ничего на хосте не оставляет после деплоя.
Не надо врать.
S>Или ты про удаление проекта с хоста? Зачем тогда ставить? S>Впрочем насрать. Надо будет — значит будет плейбук и про удаление.
Который может не работать. Или работать не так. Или делать случайно "rm -Rf /usr /${PROJECT_PATH}". Да мало ли что.
В то время, как Docker гарантирует, что на хосте ничего не будет. Запускаемые контейнеры будут гарантированно закрыты в своих песочницах.
PS: я Ansible использовал ещё в 2013-м году, так что не надо мне тут небылицы про него сочинять.
Здравствуйте, Farsight, Вы писали:
S>>Почему ты решил что это невозможно? F>Я не решал. Все возможно. Но это время и деньги. И гемор. Но, с учетом того что в заказной командной разработке ты не участвовал, тебе не понять. Впрочем, тебе об этом уже столько раз писали, толку ноль.
Сколько раз "халва" не произноси — слаще во рту не станет.
Участвовал и участвую.
Но ты верь.
S>>Нет. F>Да как-то, особенно когда времени в обрез.
Зачем доводить до такого состояния что времени в обрез?
S>>Твоя аргументация: разрабаам лень разбираться, поэтому докер. S>>Предотвращая бесполезный спор — разрабы и не должны разбираться. Это должен делать девапс/админ. F>"Разрабам лень разбираться..."... плохие разрабы... и тут же "разрабы и не должны разбираться"... Биполярочка накрыла?
Не вижу противоречия. Разрабам лень разбираться в админстве и поэтому они плохие что не хотят спихнуть это на специально обученного человека, так как разбираться в админстве и не должны. Но лезут, бьют шишки себе на ровных местах и в итоге выбирают путь "лишь бы работало".
F>Адним, в случае клиента со своими мощностями должен обеспечивать работоспособность серверов и самого кластера. С разработкой, деплоем, обновлением и мониторингом разберуться без него разрабы и девопсы. А в случае с облаками... У того клиента нет админов .
Значит клиенту админ не нужен. Его роль выполняет ваш девапс, разворачивая клиенту проект в облаке. У вас же не программисты девапсиньем занимаюцца, надеюсь?
Здравствуйте, Sheridan, Вы писали:
S>Зачем доводить до такого состояния что времени в обрез?
S>Участвовал и участвую.
S>Но ты верь.
И всегда все в срок, без дедлайнов. Да, я верю.
S>А что с окружением? invertory написать или ты об чом?
Без контейнеров это будет приложение на винде за IIS в одном случае, на линуксе за nginx в другом и azure web app за Application Gateway в третьем. Окружение несколько разнится. Привет "ой, а на моем компьютере все работает". Контейнеры позволяют большую часть этих проблем убрать, при этом не создают проблем в надежностью, вопреки теории, которая твой единственный аргумент.
S>Не вижу противоречия. Разрабам лень разбираться в админстве и поэтому они плохие что не хотят спихнуть это на специально обученного человека, так как разбираться в админстве и не должны. Но лезут, бьют шишки себе на ровных местах и в итоге выбирают путь "лишь бы работало". S>Значит клиенту админ не нужен. Его роль выполняет ваш девапс, разворачивая клиенту проект в облаке. S>У вас же не программисты девапсиньем занимаюцца, надеюсь?
Мне кажется, ты не не совсем осознаешь, что такое devops.
Здравствуйте, Cyberax, Вы писали:
S>>>>А при чом тут докер-специфик задача? Это за докером чистить надо. Ансибл сразу чисто делает. C>>>Анзибль — это просто выполнялка команд, S>>Докер это просто chroot. C>Не совсем. Там ещё композитная файловая система (с оверлеями). Так что изменения, сделанные внутри контейнера, не меняют изображение. Ну и изоляция процессов внутри namespace'ов.
Вот и ансибл — не совсем.
C>>>он сам ничего не чистит. S>>Чистит за собой он, чистит. Не там и не то что ты думаешь, правда. C>
C>И как и что оно будет чистить?
У тебя команда не выполнится. Ну, разве что /clean это блочное устройство.
Разберись уже как работает ансибл и поймёшь что оно чистит за собой.
C>>>В отличие от анзибля, докер гарантирует, что выполняемый контейнер не оставит НИЧЕГО на хосте (если специально не захотеть обратного). S>>Ансибл за собой тоже ничего на хосте не оставляет после деплоя. C>Не надо врать.
Более того, ансибл не нужен на целевом хосте для деплоя.
S>>Или ты про удаление проекта с хоста? Зачем тогда ставить? S>>Впрочем насрать. Надо будет — значит будет плейбук и про удаление. C>Который может не работать. Или работать не так. Или делать случайно "rm -Rf /usr /${PROJECT_PATH}". Да мало ли что.
О, я смотрю у тебя либо палец вкусный, либо потолок вместимый.
C>В то время, как Docker гарантирует, что на хосте ничего не будет. Запускаемые контейнеры будут гарантированно закрыты в своих песочницах.
Видимо мы по разному воспринимаем назначение песочниц. Ты в них видишь некую круть. А я в них вижу неспособность программиста писать код, который работает не только в тепличных условиях.
Если нужна песочница для работы проекта — то значит в проекте чтото идёт не так.
C>PS: я Ansible использовал ещё в 2013-м году, так что не надо мне тут небылицы про него сочинять.
Видимо использовал-использовал но так и не разобрался. Впрочем, тебе то простительно, ты программист а не админ/девапс.
Здравствуйте, Farsight, Вы писали:
S>>Зачем доводить до такого состояния что времени в обрез? F>
S>>Участвовал и участвую.
S>>Но ты верь.
F>И всегда все в срок, без дедлайнов. Да, я верю.
С дедлайнами, +- в срок. Всё бывало, да. Но никогда не приходил в дедлайн с неготовым проектом. Как правило это были багфиксы, а не "надо срочно половину дописать!!111"
S>>А что с окружением? invertory написать или ты об чом? F>Без контейнеров это будет приложение на винде за IIS в одном случае, на линуксе за nginx в другом и azure web app за Application Gateway в третьем. Окружение несколько разнится. Привет "ой, а на моем компьютере все работает". Контейнеры позволяют большую часть этих проблем убрать, при этом не создают проблем в надежностью, вопреки теории, которая твой единственный аргумент.
И в чём проблема настроить окружение? Вот реально, в чём?
S>>Не вижу противоречия. Разрабам лень разбираться в админстве и поэтому они плохие что не хотят спихнуть это на специально обученного человека, так как разбираться в админстве и не должны. Но лезут, бьют шишки себе на ровных местах и в итоге выбирают путь "лишь бы работало". S>>Значит клиенту админ не нужен. Его роль выполняет ваш девапс, разворачивая клиенту проект в облаке. S>>У вас же не программисты девапсиньем занимаюцца, надеюсь? F>Мне кажется, ты не не совсем осознаешь, что такое devops.
Мне кажется что ты не особо понимаешь кто такие программисты и чем они должны заниматься.
Здравствуйте, Sheridan, Вы писали:
S>Видимо мы по разному воспринимаем назначение песочниц. Ты в них видишь некую круть. А я в них вижу неспособность программиста писать код, который работает не только в тепличных условиях. S>Если нужна песочница для работы проекта — то значит в проекте чтото идёт не так.
Здравствуйте, Sheridan, Вы писали:
S>И в чём проблема настроить окружение? Вот реально, в чём?
Слишком большие и ненужные трудозатраты, вот в чем.
S>Мне кажется что ты не особо понимаешь кто такие программисты и чем они должны заниматься.
Я не особо понимаю, кто такие программисты, админы и девопс-инженере в твоем воображении, это да.
Здравствуйте, Farsight, Вы писали:
S>>Если нужна песочница для работы проекта — то значит в проекте чтото идёт не так. F>Вот это эпик вообще!
Печально если ты так действительно думаешь.
Здравствуйте, Farsight, Вы писали:
S>>И в чём проблема настроить окружение? Вот реально, в чём? F>Слишком большие и ненужные трудозатраты, вот в чем.
Не больше, чем затраты на подготовку контейнеров.
S>>Мне кажется что ты не особо понимаешь кто такие программисты и чем они должны заниматься. F>Я не особо понимаю, кто такие программисты, админы и девопс-инженере в твоем воображении, это да.
Тогда зачем у тебя программисты пытаююцца админить? Конечно для них админство — сложно и трудозатратно. Конечно у них ничего не получается и они скатываются в песочницы.
Здравствуйте, Sheridan, Вы писали:
S>Не больше, чем затраты на подготовку контейнеров.
S>Тогда зачем у тебя программисты пытаююцца админить? Конечно для них админство — сложно и трудозатратно. Конечно у них ничего не получается и они скатываются в песочницы.
Вот оно что . Пойду расскажу всем. Начнем избавляться от контейнеров потихоньку.
Здравствуйте, Farsight, Вы писали:
S>>Не больше, чем затраты на подготовку контейнеров. F>
Вот именно.
S>>Тогда зачем у тебя программисты пытаююцца админить? Конечно для них админство — сложно и трудозатратно. Конечно у них ничего не получается и они скатываются в песочницы. F>Вот оно что . Пойду расскажу всем. Начнем избавляться от контейнеров потихоньку.
Да, верное решение.
S>>>Да-да. Рассказывай мне про секундное генерирование образов. M>>причем тут генерация? S>А, то есть вы в прод запихиваете образа сразу с докерхаба? Мо-лод-цы.
— Шеридан даже близко не представляет, что на докерхабе есть приватные хабы aka docker hub enterprise
— Шеридан даже близко не представляет, что не обязательно все заливать на докерхаб, а можно развернуть собственный приватный реестр
— Шеридан даже близко не представляет, что, например, Google предоставляет собственный приватный реестр aka Google Container Registry
M>- Шеридан даже близко не представляет, что на докерхабе есть приватные хабы aka docker hub enterprise M>- Шеридан даже близко не представляет, что не обязательно все заливать на докерхаб, а можно развернуть собственный приватный реестр M>- Шеридан даже близко не представляет, что, например, Google предоставляет собственный приватный реестр aka Google Container Registry
M>Хотя можно было бы просто остановиться на
M>- Шеридан даже близко не представляет
M>Потому что это стандартная ситуация для Шеридана.
Он на полном серьезе думает, что мы про Ансибл спорим. Который всего лишь еще одна "отвертка" в наборе специалиста. Я встретился с ним в конце 2013-го.
Печальное зрелище вот так человека гонять, чтобы получить ответы на главные вопросы.
Как произошла фиксация и закостенение около 5+ лет назад. Что этому способствовало. И осознает ли он сам, до конца.
Или как трехногий кот, "ощущающий" несуществующую конечность. Хотя, учитывая этот "Розгами этих, розгами тех, розгами-розгами всех", какая-то воспалительная реакция есть. Но, тем не менее, не двигает в продуктивном направлении.
V_>Он на полном серьезе думает, что мы про Ансибл спорим. Который всего лишь еще одна "отвертка" в наборе специалиста. Я встретился с ним в конце 2013-го.
Я лет десять тому назад с ним голосо-чатился, а потом просто чатился. Уже не помню в деталях, про что мы там говорили, он согласился с процентов 90 доводов в итоге Не прошло и пары месяцев, и все пошло по кругу.
V_>>Он на полном серьезе думает, что мы про Ансибл спорим. Который всего лишь еще одна "отвертка" в наборе специалиста. Я встретился с ним в конце 2013-го.
M>Я лет десять тому назад с ним голосо-чатился, а потом просто чатился. Уже не помню в деталях, про что мы там говорили, он согласился с процентов 90 доводов в итоге Не прошло и пары месяцев, и все пошло по кругу.
Здравствуйте, Sheridan, Вы писали:
C>>Не совсем. Там ещё композитная файловая система (с оверлеями). Так что изменения, сделанные внутри контейнера, не меняют изображение. Ну и изоляция процессов внутри namespace'ов. S>Вот и ансибл — не совсем.
Совсем. Анзибль не предоставляет ничего для структуризации исполнения. Это тупо выполнялка команд.
C>>>>он сам ничего не чистит. S>>>Чистит за собой он, чистит. Не там и не то что ты думаешь, правда. C>>
C>>И как и что оно будет чистить? S>У тебя команда не выполнится. Ну, разве что /clean это блочное устройство.
cyberax@CybMac:~/aurora/circleci-slim$ dd if=/dev/urandom bs=10 of=/tmp/clean count=10
10+0 records in
10+0 records out
100 bytes transferred in 0.000142 secs (704925 bytes/sec)
cyberax@CybMac:~/aurora/circleci-slim$ ls -la /tmp/clean
-rw-r--r-- 1 cyberax wheel 100 14 май 10:26 /tmp/clean
Давай поспорим на деньги, скажем на $1000?
S>Разберись уже как работает ансибл и поймёшь что оно чистит за собой.
Разберись уже как работает ансибл, и поймёшь что оно не чистит за собой.
S>>>Ансибл за собой тоже ничего на хосте не оставляет после деплоя. C>>Не надо врать. S>Более того, ансибл не нужен на целевом хосте для деплоя.
Естественно, так как анзибль — это просто выполнялка команд, которая может и через SSH работать.
C>>Который может не работать. Или работать не так. Или делать случайно "rm -Rf /usr /${PROJECT_PATH}". Да мало ли что. S>О, я смотрю у тебя либо палец вкусный, либо потолок вместимый.
Ну так как Ansible будет магически предотвращать мусор после удаления софта?
C>>В то время, как Docker гарантирует, что на хосте ничего не будет. Запускаемые контейнеры будут гарантированно закрыты в своих песочницах. S>Видимо мы по разному воспринимаем назначение песочниц. Ты в них видишь некую круть. А я в них вижу неспособность программиста писать код, который работает не только в тепличных условиях.
Песочница — это гарантия того, что ошибки в приложении не приведут к проблемам в других приложениях.
S>Если нужна песочница для работы проекта — то значит в проекте чтото идёт не так.
Ну так и защита памяти тогда не нужна.
C>>PS: я Ansible использовал ещё в 2013-м году, так что не надо мне тут небылицы про него сочинять. S>Видимо использовал-использовал но так и не разобрался. Впрочем, тебе то простительно, ты программист а не админ/девапс.
Ты не знаешь даже близко что такое "devops". Хватит тут уже играть клоуна.
C>>>Не совсем. Там ещё композитная файловая система (с оверлеями). Так что изменения, сделанные внутри контейнера, не меняют изображение. Ну и изоляция процессов внутри namespace'ов. S>>Вот и ансибл — не совсем. C>Совсем. Анзибль не предоставляет ничего для структуризации исполнения. Это тупо выполнялка команд.
Что ты понимаешь под "структуризации исполнения"? Случайно не роли имеешь в виду?
S>>У тебя команда не выполнится. Ну, разве что /clean это блочное устройство. C>
C>cyberax@CybMac:~/aurora/circleci-slim$ dd if=/dev/urandom bs=10 of=/tmp/clean count=10
C>10+0 records in
C>10+0 records out
C>100 bytes transferred in 0.000142 secs (704925 bytes/sec)
C>cyberax@CybMac:~/aurora/circleci-slim$ ls -la /tmp/clean
C>-rw-r--r-- 1 cyberax wheel 100 14 май 10:26 /tmp/clean
C>
А, clean это файл а не каталог. Мой косяк, не распарсил.
S>>Разберись уже как работает ансибл и поймёшь что оно чистит за собой. C>Разберись уже как работает ансибл, и поймёшь что оно не чистит за собой.
Угу, ага. За собой он очень хорошо чистит.
Ладно, не буду тебя заставлять изучать его, видимо не выйдет. При работе на целевом хосте ансибл создаёт временные файлы — по сути питоноскрипты, которые исполняет. По завершению таска — подчищает.
Так что твои слова про 13й год и знание ансибла выглядят ниочччень.
S>>>>Ансибл за собой тоже ничего на хосте не оставляет после деплоя. C>>>Не надо врать. S>>Более того, ансибл не нужен на целевом хосте для деплоя. C>Естественно, так как анзибль — это просто выполнялка команд, которая может и через SSH работать.
Ну хоть это ты знаешь.
C>>>Который может не работать. Или работать не так. Или делать случайно "rm -Rf /usr /${PROJECT_PATH}". Да мало ли что. S>>О, я смотрю у тебя либо палец вкусный, либо потолок вместимый. C>Ну так как Ansible будет магически предотвращать мусор после удаления софта?
Тасками, друг мой, тасками.
C>>>В то время, как Docker гарантирует, что на хосте ничего не будет. Запускаемые контейнеры будут гарантированно закрыты в своих песочницах. S>>Видимо мы по разному воспринимаем назначение песочниц. Ты в них видишь некую круть. А я в них вижу неспособность программиста писать код, который работает не только в тепличных условиях. C>Песочница — это гарантия того, что ошибки в приложении не приведут к проблемам в других приложениях.
Вот-вот, это я и имею в виду, говоря о неспособности программиста писать код.
S>>Если нужна песочница для работы проекта — то значит в проекте чтото идёт не так. C>Ну так и защита памяти тогда не нужна.
Чего уж ты мелко ходишь, давай уже так: Да и вообще защита не нужна. Выкомпилить секурити и прочие ацл из ядра, затереть ssl!!11
C>>>PS: я Ansible использовал ещё в 2013-м году, так что не надо мне тут небылицы про него сочинять. S>>Видимо использовал-использовал но так и не разобрался. Впрочем, тебе то простительно, ты программист а не админ/девапс. C>Ты не знаешь даже близко что такое "devops". Хватит тут уже играть клоуна.
Знаю, друг мой, знаю. Фактически девопсю уже четвёртый год. И да, я в курсе что это не профессия, а процесс. Поэтому и пишу "админ/девапс" если ты не заметил.
Здравствуйте, Sheridan, Вы писали:
S>>>Вот и ансибл — не совсем. C>>Совсем. Анзибль не предоставляет ничего для структуризации исполнения. Это тупо выполнялка команд. S>Что ты понимаешь под "структуризации исполнения"? Случайно не роли имеешь в виду?
Есть Nix — они там реально гарантируют чистоту исполнения, есть Puppet — там описывается логическая структура и Puppet пытается построить план для достижения этого состояния. Это как пример структурированного исполнения.
S>>>Разберись уже как работает ансибл и поймёшь что оно чистит за собой. C>>Разберись уже как работает ансибл, и поймёшь что оно не чистит за собой. S>Угу, ага. За собой он очень хорошо чистит.
Я уже привёл контр-пример.
S>Ладно, не буду тебя заставлять изучать его, видимо не выйдет. При работе на целевом хосте ансибл создаёт временные файлы — по сути питоноскрипты, которые исполняет. По завершению таска — подчищает. S>Так что твои слова про 13й год и знание ансибла выглядят ниочччень.
Ты реально не понимаешь ничего, ок.
S>>>О, я смотрю у тебя либо палец вкусный, либо потолок вместимый. C>>Ну так как Ansible будет магически предотвращать мусор после удаления софта? S>Тасками, друг мой, тасками.
Как? Я уже привёл пример, когда Ansible не очистит файл.
C>>Песочница — это гарантия того, что ошибки в приложении не приведут к проблемам в других приложениях. S>Вот-вот, это я и имею в виду, говоря о неспособности программиста писать код.
Именно так.
S>>>Если нужна песочница для работы проекта — то значит в проекте чтото идёт не так. C>>Ну так и защита памяти тогда не нужна. S>Чего уж ты мелко ходишь, давай уже так: Да и вообще защита не нужна. Выкомпилить секурити и прочие ацл из ядра, затереть ssl!!11
[quote]
Вот-вот, это я и имею в виду, говоря о неспособности программиста писать код.
[/quote]
C>>Ты не знаешь даже близко что такое "devops". Хватит тут уже играть клоуна. S>Знаю, друг мой, знаю. Фактически девопсю уже четвёртый год. И да, я в курсе что это не профессия, а процесс. Поэтому и пишу "админ/девапс" если ты не заметил.
Т.е. все 4 года не можешь настроить Ansible. Понятно.
Ну ладно, я иду обратно плакать от горя. Я всего-то построил инфраструктуру компании, работающей на 3 континентах. Вся инфраструктура в виде кода, для десятка самых разных приложений. И для этого не нужен был Ansible
Здравствуйте, SkyDance, Вы писали:
N>>Скажем, у Скайденса на банковском счету вдруг стало 0 денег, счет за комунальные услуги пришел в двойном размере, а магазинная касса занимается приписками в чеках.
S>>>>Вот и ансибл — не совсем. C>>>Совсем. Анзибль не предоставляет ничего для структуризации исполнения. Это тупо выполнялка команд. S>>Что ты понимаешь под "структуризации исполнения"? Случайно не роли имеешь в виду? C>Есть Nix — они там реально гарантируют чистоту исполнения, есть Puppet — там описывается логическая структура и Puppet пытается построить план для достижения этого состояния. Это как пример структурированного исполнения.
У ансибла ещё больше свободы. Значит на нём можно добиться чего угодно.
Практика показывает что чем умнее инструмент, тем сложнее реализовывать решение, выходящее за рамки тривиального.
S>>Ладно, не буду тебя заставлять изучать его, видимо не выйдет. При работе на целевом хосте ансибл создаёт временные файлы — по сути питоноскрипты, которые исполняет. По завершению таска — подчищает. S>>Так что твои слова про 13й год и знание ансибла выглядят ниочччень. C>Ты реально не понимаешь ничего, ок.
Это ты привык думать контейнерами и тебе кажется что кроме контейнеров нет ничего и кубернетес пророк их.
S>>>>О, я смотрю у тебя либо палец вкусный, либо потолок вместимый. C>>>Ну так как Ansible будет магически предотвращать мусор после удаления софта? S>>Тасками, друг мой, тасками. C>Как? Я уже привёл пример, когда Ansible не очистит файл.
Пишем таск "очистить файл, вот так". Файл очищается.
При необходимости следом еще пишем таск "а хорошо мы файл очистили, может ещё раз?"
C>>>Песочница — это гарантия того, что ошибки в приложении не приведут к проблемам в других приложениях. S>>Вот-вот, это я и имею в виду, говоря о неспособности программиста писать код. C>Именно так.
Ну хоть в чём-то ты со мной согласился.
C>>>Ты не знаешь даже близко что такое "devops". Хватит тут уже играть клоуна. S>>Знаю, друг мой, знаю. Фактически девопсю уже четвёртый год. И да, я в курсе что это не профессия, а процесс. Поэтому и пишу "админ/девапс" если ты не заметил. C>Т.е. все 4 года не можешь настроить Ansible. Понятно.
Конечно не могу! А что это такое, кстати?...
C>Ну ладно, я иду обратно плакать от горя. Я всего-то построил инфраструктуру компании, работающей на 3 континентах. Вся инфраструктура в виде кода, для десятка самых разных приложений. И для этого не нужен был Ansible
Ну я поменьше наверное... За 4 года реализовал разные хотелки десятка компаний, среди которых в том числе и такие вот "межконтинентальные".
Контейнеры были только для разработки. Но ты продолжай верить.
Здравствуйте, Sheridan, Вы писали:
M>>причем тут генерация? S>А, то есть вы в прод запихиваете образа сразу с докерхаба? Мо-лод-цы.
во первых уже два или три раза тут писали про base-image. который меняется редко
во вторых — опять же причем тут генерация? создание image — это часть билд процедуры а не деплоя, и совершенно не важно сколько он занимает
деплой — это разворачивание докера — и это секунды. при этом требование к хост машине крайне минимальны, ее не нужно "готовить" минутами
Здравствуйте, Sheridan, Вы писали:
S>Твоя аргументация: разрабаам лень разбираться, поэтому докер. S>Предотвращая бесполезный спор — разрабы и не должны разбираться. Это должен делать девапс/админ.
Здравствуйте, mogadanez, Вы писали:
M>во вторых — опять же причем тут генерация? создание image — это часть билд процедуры а не деплоя, и совершенно не важно сколько он занимает M>деплой — это разворачивание докера — и это секунды. при этом требование к хост машине крайне минимальны, ее не нужно "готовить" минутами
Акай, уговорили. Деплой проекта на 95% состоит из времени копирования образа на целевой хост.
Впрочем всё равно неясно где профит. Ну вот подготовили релиз/фикс. Оттестили на stage.
По факту настоящий деплой у вас это создание образов, впулливание туда скомпиленого кода, реструктуризация БД и вот это вот всё. Ну, при очередном релизе/фиксе. Наклепали образов на билд-полигоне, потом раскидали эти файлики по проду и "ребут".
С ансиблом практически то же самое. Только сразу на прод. Всё, дальше это работает там до следующего поворота этого колеса.
Разве что выигрыш будет если прод это 100500 совершенно однотипных машин, в которые грузится один и тот же образ. Впрочем и с ансиблом почти то же самое, только грузим в хосты не всё сразу, а только диффы. То есть может даже и быстрее получиться.
Здравствуйте, mogadanez, Вы писали:
M>докер это быстро, надежно и в сумме дешевле
Окай, давай я тебе задам вопрос: для чего именно тебе нужен докер? Почему без него ты никак не можешь обойтись? Какую киллер-фичу используешь такую, что нигде больше нет и никак не добыть?
Здравствуйте, Sheridan, Вы писали:
S>Здравствуйте, mogadanez, Вы писали:
M>>во вторых — опять же причем тут генерация? создание image — это часть билд процедуры а не деплоя, и совершенно не важно сколько он занимает M>>деплой — это разворачивание докера — и это секунды. при этом требование к хост машине крайне минимальны, ее не нужно "готовить" минутами
S>Акай, уговорили. Деплой проекта на 95% состоит из времени копирования образа на целевой хост.
образы не монолитны, по факту при новой версии копируется только "разница" чаше всего это именно код, при некоторых оптимизациях даже часть кода. остальное в кеше
S>Впрочем всё равно неясно где профит. Ну вот подготовили релиз/фикс. Оттестили на stage. S>По факту настоящий деплой у вас это создание образов, впулливание туда скомпиленого кода, реструктуризация БД и вот это вот всё. Ну, при очередном релизе/фиксе. Наклепали образов на билд-полигоне, потом раскидали эти файлики по проду и "ребут".
нет это ты пытаешься подогнать под свое мировозрение. создание образов это именно билд. причем не факт что он потом вообще кудато пойдет или будет задеплоен
БД с этим вообще никак не связана и лежит в другой плоскости
S>С ансиблом практически то же самое. Только сразу на прод. Всё, дальше это работает там до следующего поворота этого колеса.
S>Окай, давай я тебе задам вопрос: для чего именно тебе нужен докер? Почему без него ты никак не можешь обойтись? Какую киллер-фичу используешь такую, что нигде больше нет и никак не добыть?
для меня — это дешевле чем любым другим способом из тех что я пробовал.
обойтись могу — например фронтенд не в докере лежит
Здравствуйте, Sheridan, Вы писали:
S>С ансиблом практически то же самое. Только сразу на прод. Всё, дальше это работает там до следующего поворота этого колеса.
Основное требование к системе деплоймента — это НАДЁЖНОСТЬ. Она никогда не должна застревать в промежуточных ситуациях. Этого никак нельзя гарантировать с ansible, так как это просто тупая запускалка команд.
А вот Докер даёт такие гарантии — мы точно знаем, что после остановки старого приложения у нас не останется зависших демонов, временных файлов на 99% диска и т.п.
C>А вот Докер даёт такие гарантии — мы точно знаем, что после остановки старого приложения у нас не останется зависших демонов, временных файлов на 99% диска и т.п.
Парни, вы спорите о совсем разных вещах.
Один говорит "вот если бы все программисты в мире понимали, что они делают, то контейнеры для изоляции одних непонимающих программистов от других были бы не нужны". И он прав.
Другой говорит "у меня нет задачи сделать мир во всем мире и научить программистов всего мира думать головой, и понимать, что они делают, а не тупо копировать со стекОверфлоу". И он тоже прав.
Просто каждый о своем. Первого надо ближе к железу, на низкоуровневое системное программирование. Там да, надо делать очень точные, тонкие, надежные и по-своему прекрасные решения. Со скоростью "десять строчек кода в день", если повезет, и ни одной, если нет нужного состояния.
Второй — на передовой продуктового софтостроения. Неважно, что там баг на баге и багом погоняет, важно, что это первый софт такого рода, и его *уже покупают*. Быть первым — это тоже круто, тоже сложно, тоже выгорание, тяжелые мозги и вечная гонка.
Просто разные виды дискомфорта. Кому-то попа, кому-то попадью, кому-то дочку.
SD>Просто каждый о своем. Первого надо ближе к железу, на низкоуровневое системное программирование. Там да, надо делать очень точные, тонкие, надежные и по-своему прекрасные решения. Со скоростью "десять строчек кода в день", если повезет, и ни одной, если нет нужного состояния.
SD>Второй — на передовой продуктового софтостроения. Неважно, что там баг на баге и багом погоняет, важно, что это первый софт такого рода, и его *уже покупают*. Быть первым — это тоже круто, тоже сложно, тоже выгорание, тяжелые мозги и вечная гонка.
SD>Просто разные виды дискомфорта. Кому-то попа, кому-то попадью, кому-то дочку.
С единственной поправкой: Шеридан — это второй, с претензией на первый. Его оппоненты — весь спектр между первым и вторым и почти никогда — строго вторые. Более того, его оппоненты как совокупно так и по отдельности имеют в разы больше опыта. В том числе с теми же инструментами, о которых он высокопарно вещает.
Потому что блин. Тту рядом Шеридан даже понять не может, что ему Киберакс говорит про чистку окружения на хосте в случае чего. Почитай подтред
Здравствуйте, mogadanez, Вы писали:
S>>Акай, уговорили. Деплой проекта на 95% состоит из времени копирования образа на целевой хост. M>образы не монолитны, по факту при новой версии копируется только "разница" чаше всего это именно код, при некоторых оптимизациях даже часть кода. остальное в кеше
Значит от ансибла недалеко ушли.
S>>Впрочем всё равно неясно где профит. Ну вот подготовили релиз/фикс. Оттестили на stage. S>>По факту настоящий деплой у вас это создание образов, впулливание туда скомпиленого кода, реструктуризация БД и вот это вот всё. Ну, при очередном релизе/фиксе. Наклепали образов на билд-полигоне, потом раскидали эти файлики по проду и "ребут".
M>нет это ты пытаешься подогнать под свое мировозрение. создание образов это именно билд. причем не факт что он потом вообще кудато пойдет или будет задеплоен
Билд это код->бинарник, код->другой код. Ну то есть когда берется код, написанный программистами и из него сооружается то, что можно запускать.
А софт->диск (виртульный диск, контейнер) это деплой. То есть когда сбилденый софт укладывается так, чтобы при своём запуске он нашол всё что ему нужно для работы там, где он ожидает это найти.
С языками типа питона шаг сборки отсутствует, сразу идёт шаг деплоя.
M>БД с этим вообще никак не связана и лежит в другой плоскости
Да, тут ты прав. БД на втором шаге деплоя, при разворачивании на прод, после рестарта образа.
S>>С ансиблом практически то же самое. Только сразу на прод. Всё, дальше это работает там до следующего поворота этого колеса. M>хуяк хуяк и в продакшен?
Печально если вы так делаете.
Я для кого, бл, написал "Ну вот подготовили релиз/фикс. Оттестили на stage."?
Здравствуйте, mogadanez, Вы писали:
S>>Окай, давай я тебе задам вопрос: для чего именно тебе нужен докер? Почему без него ты никак не можешь обойтись? Какую киллер-фичу используешь такую, что нигде больше нет и никак не добыть? M>для меня — это дешевле чем любым другим способом из тех что я пробовал.
Дешевле — это...? Ну, понятно что времени меньше на чтототам тратится как правило, но хотелось бы подробностей.
M>обойтись могу — например фронтенд не в докере лежит
А бакенд без докера работает?
Здравствуйте, Cyberax, Вы писали:
S>>С ансиблом практически то же самое. Только сразу на прод. Всё, дальше это работает там до следующего поворота этого колеса. C>
Ещё один, чтающий по диагонали. Я для кого писал что этот шаг после тестов на стейже?
C>Основное требование к системе деплоймента — это НАДЁЖНОСТЬ. Она никогда не должна застревать в промежуточных ситуациях.
Спасибо, кеп.
C>Этого никак нельзя гарантировать с ansible, так как это просто тупая запускалка команд.
А докер это тупой chroot, да?
C>А вот Докер даёт такие гарантии — мы точно знаем, что после остановки старого приложения у нас не останется зависших демонов, временных файлов на 99% диска и т.п.
Я с ансиблом тоже такое гарантировать могу. Достаточно просто знать что программисты вот тут и вот тут мусорят и надо подметать.
Здравствуйте, Mamut, Вы писали:
M>Потому что блин. Тту рядом Шеридан даже понять не может, что ему Киберакс говорит про чистку окружения на хосте в случае чего. Почитай подтред
, весьма показтелен.
Пожалуй изменю разок своему правилу не кормить тебя.
C>он сам (ансибль — прим.) ничего не чистит.
Чистит за собой он, чистит. Не там и не то что ты думаешь, правда.
...
Или ты про удаление проекта с хоста? Зачем тогда ставить?
Впрочем насрать. Надо будет — значит будет плейбук и про удаление.
, весьма показтелен. S>Пожалуй изменю разок своему правилу не кормить тебя.
Единственный, кого кормят тут, — это ты. Удивительно, что народ вообще все еще пытается тебе хоть что-то объяснить.
S>
C>>он сам (ансибль — прим.) ничего не чистит.
S>Чистит за собой он, чистит. Не там и не то что ты думаешь, правда.
Выделенное
S>Но тебе плевать, тебе главное плеснуть так чтобы ложечки остались.
Это тебе плевать. Понимать, что тебе пишут оппоненты ты не способен физиологически
Cyberax: В отличие от анзибля, докер гарантирует, что выполняемый контейнер не оставит НИЧЕГО на хосте
Sheridan: чистит. Не там и не то что ты думаешь
Sheridan: При работе на целевом хосте ансибл создаёт временные файлы — по сути питоноскрипты, которые исполняет. По завершению таска — подчищает.
Опять фигурная резка по цитате. Причом не стесняясь, тут же, сразу.
Приведу полностью опять. Выделю обрезанное тобой.
C>он сам (ансибль — прим.) ничего не чистит.
Чистит за собой он, чистит. Не там и не то что ты думаешь, правда.
... Или ты про удаление проекта с хоста? Зачем тогда ставить?
Впрочем насрать. Надо будет — значит будет плейбук и про удаление.
Здравствуйте, Sheridan, Вы писали:
M>>хуяк хуяк и в продакшен? S>Печально если вы так делаете. S>Я для кого, бл, написал "Ну вот подготовили релиз/фикс. Оттестили на stage."?
"С ансиблом практически то же самое. Только сразу на прод."
Здравствуйте, mogadanez, Вы писали:
M>>>хуяк хуяк и в продакшен? S>>Печально если вы так делаете. S>>Я для кого, бл, написал "Ну вот подготовили релиз/фикс. Оттестили на stage."? M>"С ансиблом практически то же самое. Только сразу на прод."
После прогона на стейже, да. Имелось в виду деплой не в контейнеры с последующим их разворачиванием на проде, а сразу разворачивать на прод.
SD>Второй — на передовой продуктового софтостроения. Неважно, что там баг на баге и багом погоняет, важно, что это первый софт такого рода, и его *уже покупают*. Быть первым — это тоже круто, тоже сложно, тоже выгорание, тяжелые мозги и вечная гонка.
вот это странный вывод — одно из другого никак не вытекает.
Если у меня красивый оттестированый и безбажный код — это не значит что я должен выкинуть докер.
Докер нужен для удобства и низкой стоимости поддержки независимо от качества кода внутри
Здра
S>Окай, давай я тебе задам вопрос: для чего именно тебе нужен докер? Почему без него ты никак не можешь обойтись? Какую киллер-фичу используешь такую, что нигде больше нет и никак не добыть?
1. Стандартизация, единая по всему миру, кроме некоторых маргиналов:
— единый "интерфейс" внутри, для приложения (docker image)
— единый интерфейс снаружи, Docker/ContainerD
— единый подход к daemonization (Pid 0)
— на уровне процессов
— на уровне файловой системы
— на уровне сети
3. Complexity reduction
Docker разделяет сложность на 2 разных domain. Внутри контейнеров и снаружи. DevOp не нужно фокусироваться на особенностях/ошибках в целом. Ошибка локализуется или внутри blackbox (artifact/image/base OS) или снаружи (Orchestration)
Компоненты можно рассматривать как черные ящики, с четко определенным интерфейсом, который можно запросить через API. Т.к. это гарантируется на уровне фреймворка, то получаем огромную пропасть между "возможно соответствует" и "гарантируется"
4. Единообразие environment для компонента, задаваемое создателем Image
Здравствуйте, Vetal_ca, Вы писали:
S>>Окай, давай я тебе задам вопрос: для чего именно тебе нужен докер? Почему без него ты никак не можешь обойтись? Какую киллер-фичу используешь такую, что нигде больше нет и никак не добыть? V_>1. Стандартизация, единая по всему миру, кроме некоторых маргиналов:
V_>- единый "интерфейс" внутри, для приложения (docker image) V_>- единый интерфейс снаружи, Docker/ContainerD V_>- единый подход к daemonization (Pid 0)
Не проще ли выкинуть контейнеры с их интерфейсами и общаться с сервисами напрямую?
Чем не устраивает systemd?
V_>Стандартизация как Deployment так и runtime
Как подготовка к разрушению мира при прилёте дятла — да, годится. Опасно постоянно держать всё в тепличных условиях: изменение этих условий обязательно приведёт к краху. А условия поменяются обязательно. Безошибочной работы не бывает у людей.
V_>2. Инкапсуляция\изоляция, гарантируемая фреймфорком.
Зачем она нужна? Просто для того чтобы программеры могли писать бажный софт, который работает только в песочнице?
V_>Docker разделяет сложность на 2 разных domain. Внутри контейнеров и снаружи. DevOp не нужно фокусироваться на особенностях/ошибках в целом. Ошибка локализуется или внутри blackbox (artifact/image/base OS) или снаружи (Orchestration)
А какая разница откуда ошибка? Её надо изучать, чинить, анализировать где ещё такое может возникнуть. А не разделять на "внутри/снаружи".
V_>Компоненты можно рассматривать как черные ящики, с четко определенным интерфейсом, который можно запросить через API. Т.к. это гарантируется на уровне фреймворка, то получаем огромную пропасть между "возможно соответствует" и "гарантируется"
Ансибл (как впрочем и докер, но с большими возможностями) как раз и предназначен для подъёма на ступеньку "гарантируется".
V_>4. Единообразие environment для компонента, задаваемое создателем Image
С ансиблом разрабу об этом думать вообще не надо. Об этом думает девапс. Он-же и гарантирует ансиблом единообразное окружение.
Разработчик должен писать код, девапс должен автоматизировать деплой. Как он это сделает — разработчику должно быть фиолетово. Но ценой является следование рекомендациям девапса. И не бойтесь, девапс в код не полезет. Рекомендации будут типа "смени порт", "перейди на такую версию библиотеки" и чтото в этом роде.
Если удобно разрабу в докере писать — да велкам, пусть пишет.
Здравствуйте, Sheridan, Вы писали:
S>Дешевле — это...? Ну, понятно что времени меньше на чтототам тратится как правило, но хотелось бы подробностей.
* не нужен специально обученный админ/девопс с завышеным ЧСВ
* за последние 5 лет в сумме на два десятка проектов потрачено сумарно не больше 10 человеко-дней на работу с докером.
до этого когда был ансибл лично потратил несколько месяцев причем был крайне недоволен результатом. после этого наняли "специально обученного человека".
пошло лучше. но очень часто при росте сложности системы запросы на изменения отрабатывались все дольше. потом мифические рефакторинги плейбуков. обновления "версий плагинов", "переход на питон3" за которой бизнес должен платить
параллельная команда потратила не менее 3х человекомесяцев на терраформ и конца и края видно не было
* Я выбираю самый простой способ, это не челендж какой то чтобы для ачивки на ансибле деплой делать и колоться. Если будет чтото еще проще чем докер — уйду туда
M>>обойтись могу — например фронтенд не в докере лежит S>А бакенд без докера работает?
в докере
S>Не проще ли выкинуть контейнеры с их интерфейсами и общаться с сервисами напрямую? S>Чем не устраивает systemd?
сколько ты потратишь времени на то чтобы запустить например 2 одинаковых процесса А параллельно? гарантируешь что это будет работать для вообще любого процесса?
сколько ты потратишь времени на разруливание конфликта версий библиотек для процессов А и Б
S>С ансиблом разрабу об этом думать вообще не надо. Об этом думает девапс. Он-же и гарантирует ансиблом единообразное окружение.
так начинается бардак и проблемы
S>Разработчик должен писать код, девапс должен автоматизировать деплой. Как он это сделает — разработчику должно быть фиолетово. Но ценой является следование рекомендациям девапса. И не бойтесь, девапс в код не полезет. Рекомендации будут типа "смени порт", "перейди на такую версию библиотеки" и чтото в этом роде. S>Если удобно разрабу в докере писать — да велкам, пусть пишет.
а так начнется срач между девопсами и разработчиками. Плюс кто платить за это будет?
Здравствуйте, Sheridan, Вы писали:
S>Здравствуйте, Vetal_ca, Вы писали:
S>Не проще ли выкинуть контейнеры с их интерфейсами и общаться с сервисами напрямую? S>Чем не устраивает systemd?
Я скажу честно, проще отсеять Шеридана с его непониманием. Это не издевательство а очень честный ответ, от самого сердца. Спустить стандартное решение в регионы и не мучаться, дешевле и проще на пособии держать.
Набери в гугле "systemd vs" и читай ниже, стандартизация:
V_>>Стандартизация как Deployment так и runtime S>Как подготовка к разрушению мира при прилёте дятла — да, годится. Опасно постоянно держать всё в тепличных условиях: изменение этих условий обязательно приведёт к краху. А условия поменяются обязательно. Безошибочной работы не бывает у людей.
Понимание, что такое стандартизация и для чего это нужно — базовое для инженера. От международной системы единиц, ГОСТ-ов на гайки и болты, до стандартов на электронику и IT. Если человек этого не понимает, он должен быть отбракован экзаменатором, чтобы не тратить время специалистов. В данном случае, хватило бы, HR или, даже, бота с хорошим AI. ДевОпсов не было, а стандартизация уж точно была в советской инженерной школе, тут путаться — недопустимо.
Утомил, правда, эти "дятлы" — мусор в твоей голове
V_>>2. Инкапсуляция\изоляция, гарантируемая фреймфорком. S>Зачем она нужна? Просто для того чтобы программеры могли писать бажный софт, который работает только в песочнице?
Вне контейнеров/компонентов есть еще очень большой мир, не видимый из твоей песочницы. Чтобы ухватить внимание знающих людей, тебе придется это подтянуть. Не хочешь подтягивать — игнор/кризис/голод и прочие стимуляторы тебе в помощь. В мире миллиарды людей которые не саморазвиваются. Они никому не интересны, кроме как для своих мамы/папы и, в очень малой степени, местным органам власти. Почему ты должен быть исключением?
S>А какая разница откуда ошибка? Её надо изучать, чинить, анализировать где ещё такое может возникнуть. А не разделять на "внутри/снаружи".
Дихотомия. Быстро определить, где ошибка и отдать человеку соответствующей квалификации, направления и ответственности. Чтобы не забивать гвозди микроскопом, каждый раз привлекая дорогостоящего специалиста или team meeting, охватывая весь диапазон для мозгового штурма. Это как вместо механика, каждый раз машину на завод отправлять, главному инженеру, если error domain — это вся машина в целом
V_>>Компоненты можно рассматривать как черные ящики, с четко определенным интерфейсом, который можно запросить через API. Т.к. это гарантируется на уровне фреймворка, то получаем огромную пропасть между "возможно соответствует" и "гарантируется" S>Ансибл (как впрочем и докер, но с большими возможностями) как раз и предназначен для подъёма на ступеньку "гарантируется".
Ансибл не гарантирует правильную работу компонента. Он гарантирует деплой, при условии что playbook написан грамотно.
V_>>4. Единообразие environment для компонента, задаваемое создателем Image S>С ансиблом разрабу об этом думать вообще не надо. Об этом думает девапс. Он-же и гарантирует ансиблом единообразное окружение.
Про стандартизацию уже было — подтянешь, поговорим.
S>Разработчик должен писать код, девапс должен автоматизировать деплой. Как он это сделает — разработчику должно быть фиолетово. Но ценой является следование рекомендациям девапса. И не бойтесь, девапс в код не полезет. Рекомендации будут типа "смени порт", "перейди на такую версию библиотеки" и чтото в этом роде. S>Если удобно разрабу в докере писать — да велкам, пусть пишет.
Про версии библиотеки знает разработчик и/или создатель Docker Image. Читай, натренированный девелопер. DevOps/SecOps ревьювит для соответствия best practices/security standards. Маппинг портов/интерфейсов легко разруливается на уровне DevOps, для этого не нужно лезть внутрь ini/conf файлов компонентов
P.S. В таких беседах очень четко раскрывается притягательность фильмов про зомби. Зомби — медленные, неуклюжие. Но их много и они со своей медленностью и неуклюжестью идут съесть твой мозг.
M>* за последние 5 лет в сумме на два десятка проектов потрачено сумарно не больше 10 человеко-дней на работу с докером. M>до этого когда был ансибл лично потратил несколько месяцев причем был крайне недоволен результатом. после этого наняли "специально обученного человека". M>пошло лучше. но очень часто при росте сложности системы запросы на изменения отрабатывались все дольше. потом мифические рефакторинги плейбуков. обновления "версий плагинов", "переход на питон3" за которой бизнес должен платить M>параллельная команда потратила не менее 3х человекомесяцев на терраформ и конца и края видно не было
Это вы Ансибл иасилили. Взяли бы Шеридана — были бы на тех же недостижимых высотах, как и он.
А так, искреннее сочувствие и все такое прочее. Убер ответ. Там-тарам-тарам-пам — пум
А, вообще, мы халявщики. Работаем с понятными и предсказуемыми железяками и программами.
Я рукоплещу стоя людям, работающим с другими людьми. У которых свои тараканы, странности и виденье мира. Учителям, врачам, психиатрам, сиделкам, нянечкам, HR-ам/кадровикам на "передовой", управляющим персоналом.
Здравствуйте, mogadanez, Вы писали:
S>>Чем не устраивает systemd? M>сколько ты потратишь времени на то чтобы запустить например 2 одинаковых процесса А параллельно? гарантируешь что это будет работать для вообще любого процесса?
Быстрее, чем программер напишет код.
M>сколько ты потратишь времени на разруливание конфликта версий библиотек для процессов А и Б
А вот тут неправильное решение. Правильное решение — добиться чтобы процессы А и Б работали с одинаковыми версиями библиотек.
S>>С ансиблом разрабу об этом думать вообще не надо. Об этом думает девапс. Он-же и гарантирует ансиблом единообразное окружение. M>так начинается бардак и проблемы
Значит плохой девопс. или разраб. Надо выяснять почему они не общаются.
S>>Разработчик должен писать код, девапс должен автоматизировать деплой. Как он это сделает — разработчику должно быть фиолетово. Но ценой является следование рекомендациям девапса. И не бойтесь, девапс в код не полезет. Рекомендации будут типа "смени порт", "перейди на такую версию библиотеки" и чтото в этом роде. S>>Если удобно разрабу в докере писать — да велкам, пусть пишет. M>а так начнется срач между девопсами и разработчиками. Плюс кто платить за это будет?
Значит давать розг обоим пока не начнут работать вместе, а не друг против друга.
Здравствуйте, mogadanez, Вы писали:
S>>Дешевле — это...? Ну, понятно что времени меньше на чтототам тратится как правило, но хотелось бы подробностей. M>* не нужен специально обученный админ/девопс с завышеным ЧСВ
Не нанимайте с завышенным.
M>* за последние 5 лет в сумме на два десятка проектов потрачено сумарно не больше 10 человеко-дней на работу с докером. M>до этого когда был ансибл лично потратил несколько месяцев причем был крайне недоволен результатом. после этого наняли "специально обученного человека". M>пошло лучше. но очень часто при росте сложности системы запросы на изменения отрабатывались все дольше. потом мифические рефакторинги плейбуков. обновления "версий плагинов", "переход на питон3" за которой бизнес должен платить M>параллельная команда потратила не менее 3х человекомесяцев на терраформ и конца и края видно не было
Девопсу не ставились задачи значит. Кинули в воду и смотрели как выплывет. Вот он и заскучал, и начал рефакторинги с переходами.
M>* Я выбираю самый простой способ, это не челендж какой то чтобы для ачивки на ансибле деплой делать и колоться. Если будет чтото еще проще чем докер — уйду туда
Ансибл — проще.
M>>>обойтись могу — например фронтенд не в докере лежит S>>А бакенд без докера работает? M>в докере
То есть работает только в тепличных условиях?
Здравствуйте, Vetal_ca, Вы писали:
V_>Набери в гугле "systemd vs" и читай ниже, стандартизация:
Ансиблом можно добиться стандартного окружения. Не только докером единым.
V_>>>Стандартизация как Deployment так и runtime S>>Как подготовка к разрушению мира при прилёте дятла — да, годится. Опасно постоянно держать всё в тепличных условиях: изменение этих условий обязательно приведёт к краху. А условия поменяются обязательно. Безошибочной работы не бывает у людей.
V_>Вне контейнеров/компонентов есть еще очень большой мир, не видимый из твоей песочницы. Чтобы ухватить внимание знающих людей, тебе придется это подтянуть. Не хочешь подтягивать — игнор/кризис/голод и прочие стимуляторы тебе в помощь. В мире миллиарды людей которые не саморазвиваются. Они никому не интересны, кроме как для своих мамы/папы и, в очень малой степени, местным органам власти. Почему ты должен быть исключением?
Песочница у вас, докер называется.
V_>Дихотомия. Быстро определить, где ошибка и отдать человеку соответствующей квалификации, направления и ответственности. Чтобы не забивать гвозди микроскопом, каждый раз привлекая дорогостоящего специалиста или team meeting, охватывая весь диапазон для мозгового штурма. Это как вместо механика, каждый раз машину на завод отправлять, главному инженеру, если error domain — это вся машина в целом
А, я понял. Ты хочешь нанимать работников низкой квалификации за копейки, согласен получать от них кое-как работающий говнокод, который работает исключительно в тепличных условиях. Ну в таком случае докером проще, да.
V_>Ансибл не гарантирует правильную работу компонента. Он гарантирует деплой, при условии что playbook написан грамотно.
Это и есть гарантия работы компонента.
V_>>>4. Единообразие environment для компонента, задаваемое создателем Image S>>С ансиблом разрабу об этом думать вообще не надо. Об этом думает девапс. Он-же и гарантирует ансиблом единообразное окружение. V_>Про стандартизацию уже было — подтянешь, поговорим.
Еще раз: после деплоя у тебя единообразное окружение. В чём проблема? В том что нанятый за копейки работник не осилит?
S>>Разработчик должен писать код, девапс должен автоматизировать деплой. Как он это сделает — разработчику должно быть фиолетово. Но ценой является следование рекомендациям девапса. И не бойтесь, девапс в код не полезет. Рекомендации будут типа "смени порт", "перейди на такую версию библиотеки" и чтото в этом роде. S>>Если удобно разрабу в докере писать — да велкам, пусть пишет.
V_>Про версии библиотеки знает разработчик и/или создатель Docker Image. Читай, натренированный девелопер. DevOps/SecOps ревьювит для соответствия best practices/security standards. Маппинг портов/интерфейсов легко разруливается на уровне DevOps, для этого не нужно лезть внутрь ini/conf файлов компонентов
Ну то есть по твоему мнению девапс это такой раб, который обязан слушаться программеров иначе розги? Они должны в команде работать. Девапс выступает вдобавок ко всему еще и связующим звеном. Говорит одной команде например что другие уже перешли на новую версию либы и надо бы тоже подтянуться.
И выучи понятия "например", "чтото типа", "в этом роде". А то воспринимаешь всё буквально...
Здравствуйте, Vetal_ca, Вы писали:
V_> Работаем с понятными и предсказуемыми железяками и программами.
Как ни странно я точно так же делаю, но без докера. Магия наверное...
Здравствуйте, Sheridan, Вы писали:
S>>>С ансиблом практически то же самое. Только сразу на прод. Всё, дальше это работает там до следующего поворота этого колеса. C>> S>Ещё один, чтающий по диагонали. Я для кого писал что этот шаг после тестов на стейже?
Нет, я про сборку на проде. У нас есть код, сборка которого занимает почти час. Так и будем на всех серверах компилировать?
C>>Основное требование к системе деплоймента — это НАДЁЖНОСТЬ. Она никогда не должна застревать в промежуточных ситуациях. S>Спасибо, кеп.
Пожалуйста.
C>>Этого никак нельзя гарантировать с ansible, так как это просто тупая запускалка команд. S>А докер это тупой chroot, да?
Да. И благодаря этому он и гарантирует надёжность.
C>>А вот Докер даёт такие гарантии — мы точно знаем, что после остановки старого приложения у нас не останется зависших демонов, временных файлов на 99% диска и т.п. S>Я с ансиблом тоже такое гарантировать могу.
Нет, не можешь. Так как ansible — это тупая запускалка, то там можно забыть добавить очистку временных файлов, например.
M>пошло лучше. но очень часто при росте сложности системы запросы на изменения отрабатывались все дольше. потом мифические рефакторинги плейбуков. обновления "версий плагинов", "переход на питон3" за которой бизнес должен платить M>параллельная команда потратила не менее 3х человекомесяцев на терраформ и конца и края видно не было
Прям история Спотифая. В теории все хорошо: централизированный репозиторий, где плейбуки, где общие части плейбуков вынесены в расшаренные плейбуки, от которых можно наследоваться (или как оно там в ансибле называется).
На практике: сотни плейбуков. Часть с начала создания компании, часть по best practices, которые уже устарели, часть по новым best practices, которые еще не до конца внедрены. Некоторые новые плейбуки ссылаются на «устаревшие» плейбуки, потому что «устаревшие» имеют то, что нет в новых. Одинаковые куски кода раскиданы по десятку разных плейбуков, потому что разным приложениям и сервисам требуются чуть-чуть разные окружения, например. Ну и т.п.
В итоге там (почти) все выкинули нахрен, сделали централизованный сервис, где деплой и развертка делаются по клику одной кнопки (среди прочего. Его медленно кусками опенсорсят тут: https://backstage.io). И постепенно перетаскивают все в кубернетес и докер.
Здравствуйте, Sheridan, Вы писали:
S>Ансиблом можно добиться стандартного окружения. Не только докером единым.
разные distro's?
S>Песочница у вас, докер называется.
Докер (ContainerD), это следующий шаг для тебя, потолок. За ним жизнь только начинается, но ты эту жизнь не видишь.
S>А, я понял. Ты хочешь нанимать работников низкой квалификации за копейки, согласен получать от них кое-как работающий говнокод, который работает исключительно в тепличных условиях. Ну в таком случае докером проще, да.
Дополнительный уровень надежности это не обязательно компенсация ущербности программы. А полезное дополнение. Экономия времени, увеличение надежности сверху. Читай, конкурентное преимущество
V_>>Ансибл не гарантирует правильную работу компонента. Он гарантирует деплой, при условии что playbook написан грамотно. S>Это и есть гарантия работы компонента.
Как ансибл влияет на компонент после деплоймента?
S>Еще раз: после деплоя у тебя единообразное окружение. В чём проблема? В том что нанятый за копейки работник не осилит?
Возьмем любую задачу, случайно. Допустим, накрылся letsencrypt. И мне нужно выдать список всех сертификатов на выбранном кластере.
kubectl get certificate --all-namespaces -o json | jq --raw-output ".....
Точно так же как вывести все поды без healthcheck или получить этот healthcheck и т.п.
Причем:
— сделать это может любой специалист, работавший с кубернетес и умеющий JQ, в том числе если это его первый день на этой работе
— делается для всего кластера. Можно сделать для всех кластеров
— не зависит от внутреннего формата, документации и прочего
Работающей код — это маленькая часть Его поддерживаемость, стандартность, расширяемость — это осязаемые ценности. Чтобы с продуктом жить, легко вводить в курс дела новичков или выгодно перепродать.
А зависеть от местных наполеонов, которые думают про "розгами по пальцам", это риск для бизнеса. Потому и ценность их никакая
Здравствуйте, Sheridan, Вы писали:
S>Не нанимайте с завышенным. S>Девопсу не ставились задачи значит. Кинули в воду и смотрели как выплывет. Вот он и заскучал, и начал рефакторинги с переходами. S>Ансибл — проще.
Есть такие чуваки... Если у бизнеса проблемы, нет роста, застой, их нанимают консультантами и они разруливают сложности. Дико дорого стоят. Не тем ты занят, Шеридан. Мог бы рубить бабло, решать интересные задачи... А ты ансибл теребонькаешь, людям с докером работать мешаешь.
S>То есть работает только в тепличных условиях?
Да, да! Работаем в изолированной среде, не заботясь о том, что там рядом у заказчика крутится, и не сломается ли что-нить, если мы какую-нить свою либу вкорячим на сервант. Да!
Здравствуйте, Farsight, Вы писали:
F>Здравствуйте, Sheridan, Вы писали:
F>Есть такие чуваки... Если у бизнеса проблемы, нет роста, застой, их нанимают консультантами и они разруливают сложности. Дико дорого стоят. Не тем ты занят, Шеридан. Мог бы рубить бабло, решать интересные задачи... А ты ансибл теребонькаешь, людям с докером работать мешаешь.
Уверяю, очень хорошо он живет у себя в провинции. Не надо ему бабло ради бабла рубить в угоду внутреннему дзену.
Комфорт это один из опаснейших причин застоя
И это я могу понять, там, хорошо, спокойно, правильно все. Надо немного, а все что надо, есть. Друзья-знакомые-родственники.
Но то что несет ерунду полную. Да и, перемены, рано или поздно выкинут его из этого дзена на мороз.
Здравствуйте, Sheridan, Вы писали:
M>>* Я выбираю самый простой способ, это не челендж какой то чтобы для ачивки на ансибле деплой делать и колоться. Если будет чтото еще проще чем докер — уйду туда S>Ансибл — проще.
нет
ты дркер пробовал вообще?
M>>>>обойтись могу — например фронтенд не в докере лежит S>>>А бакенд без докера работает? M>>в докере S>То есть работает только в тепличных условиях?
он работает в любых условиях. разворачивать его докером проще и дешевле чем любым другим способом.
Здравствуйте, Sheridan, Вы писали:
V_>>Стандартизация как Deployment так и runtime S>Как подготовка к разрушению мира при прилёте дятла — да, годится. Опасно постоянно держать всё в тепличных условиях: изменение этих условий обязательно приведёт к краху. А условия поменяются обязательно. Безошибочной работы не бывает у людей.
Хватит бредить, а?
Дятел, который разрушит цивилизацию — в твоих Анзиблях. Достаточно в ОДНОМ скрипте кому-то случайно написать "rm -Rf /usr /local/something", и всё, весь production умрёт. При этом, никакой rollback не спасёт, так как production-серверы будут нерабочими. И нет никаких возможностей гарантированно предотвратить такую ситуацию.
В случае с Docker/Kubernetes такая ситуация НЕВОЗМОЖНА в принципе. Код, который может быть ошибочен, специально изолирован и ограничен, так что последствия его отказа тоже будут ограничены и предсказуемы. И это принципиально правильный подход, вообще во всей инженерной науке.
Основная мысль — человеческих ошибок (почти) не бывает. Если система допускает возможность катастрофических "человеческих ошибок" — это проблема системы, а не человеков.
Здравствуйте, Cyberax, Вы писали:
S>>Ещё один, чтающий по диагонали. Я для кого писал что этот шаг после тестов на стейже? C>Нет, я про сборку на проде. У нас есть код, сборка которого занимает почти час. Так и будем на всех серверах компилировать?
Дядя, у тебя цель какая? Доказать что ансибл гавно или что? Вот этот глупый вопрос к чему ты принёс? Ты вроде не глупый человек но пошол по пути "А щас я спрощу какую нибудь херню и понаблюдаю."
Про сборка/деплой я писал раньше. Даже вроде бы тебе.
C>>>Этого никак нельзя гарантировать с ansible, так как это просто тупая запускалка команд. S>>А докер это тупой chroot, да? C>Да. И благодаря этому он и гарантирует надёжность.
chroot это не про надёжность, а про изоляцию. Хоть 20 раз заchroot'ь бажный софт — работать он от этого не начнёт.
C>>>А вот Докер даёт такие гарантии — мы точно знаем, что после остановки старого приложения у нас не останется зависших демонов, временных файлов на 99% диска и т.п. S>>Я с ансиблом тоже такое гарантировать могу. C>Нет, не можешь. Так как ansible — это тупая запускалка, то там можно забыть добавить очистку временных файлов, например.
А можно не забыть, например. Поэтому — смогу.
Здравствуйте, Vetal_ca, Вы писали:
S>>Ансиблом можно добиться стандартного окружения. Не только докером единым. V_>разные distro's?
Зачем себе в колёса пихать палки? Мсье мазохист?
Нахрена на своих серверах для своего проекта городить зоопарк? Или просто в голову больше ничего не приходит в защиту докеров?
S>>Песочница у вас, докер называется. V_>Докер (ContainerD), это следующий шаг для тебя, потолок. За ним жизнь только начинается, но ты эту жизнь не видишь.
Я этот шаг успешно прошёл и научился определять когда контейнеризация нужна, а когда — нет.
S>>А, я понял. Ты хочешь нанимать работников низкой квалификации за копейки, согласен получать от них кое-как работающий говнокод, который работает исключительно в тепличных условиях. Ну в таком случае докером проще, да. V_>Дополнительный уровень надежности это не обязательно компенсация ущербности программы. А полезное дополнение. Экономия времени, увеличение надежности сверху. Читай, конкурентное преимущество
Никогда не поверю, что у вас в мануале нет "рекомендуется использовать дистрибутив Х", что читается техподдержкой как "а, вы на У, тогда ой". А раз так, то тогда и окружение будет нужным.
V_>Возьмем любую задачу, случайно. Допустим, накрылся letsencrypt. И мне нужно выдать список всех сертификатов на выбранном кластере. V_>
V_>kubectl get certificate --all-namespaces -o json | jq --raw-output ".....
V_>Точно так же как вывести все поды без healthcheck или получить этот healthcheck и т.п.
Не нужно ничего выводить, нужно организовывать этот чек. Сразу. Нужен — сделали.
V_>- сделать это может любой специалист, работавший с кубернетес и умеющий JQ, в том числе если это его первый день на этой работе
Для ансибла не нужно спецзнаний. Нужен плейбук и обезьяна.
V_>- делается для всего кластера. Можно сделать для всех кластеров
Никаких проблем. Для всех кластеров сразу.
V_>- не зависит от внутреннего формата, документации и прочего
Абсолютно верно, не зависит.
V_>Работающей код — это маленькая часть Его поддерживаемость, стандартность, расширяемость — это осязаемые ценности. Чтобы с продуктом жить, легко вводить в курс дела новичков или выгодно перепродать. V_>А зависеть от местных наполеонов, которые думают про "розгами по пальцам", это риск для бизнеса. Потому и ценность их никакая
Так не зависьте. Набор плейбуков, мануал про бутстрап деплой и список рекомендаций.
Здравствуйте, Farsight, Вы писали:
F>Есть такие чуваки... Если у бизнеса проблемы, нет роста, застой, их нанимают консультантами и они разруливают сложности. Дико дорого стоят. Не тем ты занят, Шеридан. Мог бы рубить бабло, решать интересные задачи... А ты ансибл теребонькаешь, людям с докером работать мешаешь.
Так случилось что я тепреть не могу человейники. А на удалёнку мало кто согласен.
S>>То есть работает только в тепличных условиях? F>Да, да! Работаем в изолированной среде, не заботясь о том, что там рядом у заказчика крутится, и не сломается ли что-нить, если мы какую-нить свою либу вкорячим на сервант. Да!
А вы не вкорячивайте старые либы а пользуйте те, которые в составе дистрибутива есть.
.
S>>То есть работает только в тепличных условиях? M>он работает в любых условиях. разворачивать его докером проще и дешевле чем любым другим способом.
Ну так если можно без докера, то зачем докер?
Здравствуйте, Cyberax, Вы писали:
V_>>>Стандартизация как Deployment так и runtime S>>Как подготовка к разрушению мира при прилёте дятла — да, годится. Опасно постоянно держать всё в тепличных условиях: изменение этих условий обязательно приведёт к краху. А условия поменяются обязательно. Безошибочной работы не бывает у людей. C>Хватит бредить, а?
Действительно.
C>Дятел, который разрушит цивилизацию — в твоих Анзиблях. Достаточно в ОДНОМ скрипте кому-то случайно написать "rm -Rf /usr /local/something", и всё, весь production умрёт. При этом, никакой rollback не спасёт, так как production-серверы будут нерабочими. И нет никаких возможностей гарантированно предотвратить такую ситуацию.
Достаточно не выдавать нетестированный код в прод.
C>В случае с Docker/Kubernetes такая ситуация НЕВОЗМОЖНА в принципе. Код, который может быть ошибочен, специально изолирован и ограничен, так что последствия его отказа тоже будут ограничены и предсказуемы. И это принципиально правильный подход, вообще во всей инженерной науке.
А у вас отказ кода может привести к краху системы вообще? И докер для того чтобы система не ломалась? Как вам такое удаётся?
C>Я рекомендую почитать книги Сиднея Деккера (Sidney Dekker), особенно книгу "Behind Human Error". Или хотя бы: http://www.humanfactors.lth.se/fileadmin/lusa/Sidney_Dekker/books/DekkersFieldGuide.pdf C>Основная мысль — человеческих ошибок (почти) не бывает. Если система допускает возможность катастрофических "человеческих ошибок" — это проблема системы, а не человеков.
Хорошая теория, только не согласуется с практикой, где автоматика работает так как надо, а ошибки в основном из за действий людей.
Здравствуйте, mogadanez, Вы писали:
S>>Ну так если можно без докера, то зачем докер? M>если можно без ансибла — зачем ансибл
Ну хотя бы потому что руками долго и сложно поддерживать единое окружение.
Здравствуйте, Sheridan, Вы писали:
S>А вы не вкорячивайте старые либы а пользуйте те, которые в составе дистрибутива есть.
Это либы для других приложений от других поставщиков, к коим мы не имеем отношения. Поэтому контенеризация и рулит.
Здравствуйте, Sheridan, Вы писали:
M>>если можно без ансибла — зачем ансибл S>Ну хотя бы потому что руками долго и сложно поддерживать единое окружение.
Здравствуйте, Shmj, Вы писали:
S>И правда ведь... Docker — он же не бесплатный по ресурсам, верно? Зачем он, если можно и без него?
Как без контейнеров деплоить приложение на kubernetes? Никак. Если кубера нет, можно рассматривать варианты. Если принято решение использовать облако в виде контейнерного оркестратора, то других вариантов не остается.
Контейнер это действительно дополнительный уровень абстракции над программой. И как любая абстракция, она в общем случае помогает, а в отдельных начинает сковывать. Поэтому в каждом отдельном случае надо смотреть индивидуально.
Использовать докер без кубера — не совсем понятно зачем это нужно.
Здравствуйте, Sheridan, Вы писали:
S>Здравствуйте, Vetal_ca, Вы писали:
S>Зачем себе в колёса пихать палки? Мсье мазохист? S>Нахрена на своих серверах для своего проекта городить зоопарк? Или просто в голову больше ничего не приходит в защиту докеров?
Я читаю, и начинаю подозревать, что ты прав: у тебя задачи такие, что на VB в Экселе запустить можно. Не нужен ни докер, ни Ансибл ни Шеридан
S>Я этот шаг успешно прошёл и научился определять когда контейнеризация нужна, а когда — нет.
Я такое уже видел. У начинающих. А ты, одновременно, и начинающий и уже все, "остановившийся в начинании".
S>Никогда не поверю, что у вас в мануале нет "рекомендуется использовать дистрибутив Х", что читается техподдержкой как "а, вы на У, тогда ой". А раз так, то тогда и окружение будет нужным.
Не надо верить, надо фокусироваться на насущном. А насущное тебе: еще учиться и пройти отбор. С таким же успехом можешь почитать инструкцию по одеванию скафандра для выхода в открытый космос
Ты даже смысл написанного осилить не можешь. Ближайший пример я видел, это африканцы, которые гайку на болт накрутить не могут. Для нас это интуитивно-понятно, а они никогда не держали в руках и не могут. Ну и советы дают, про другую гайку.
У вас даже на прием на работу чек плохой, дальше и говорить нечего
V_>>- сделать это может любой специалист, работавший с кубернетес и умеющий JQ, в том числе если это его первый день на этой работе S>Для ансибла не нужно спецзнаний. Нужен плейбук и обезьяна.
Подумай, может и на Экселе можно?
V_>>- делается для всего кластера. Можно сделать для всех кластеров S>Никаких проблем. Для всех кластеров сразу.
Весело, включая и твою ошибочную команду, ибо Ansible позволяет записать, все что угодно. Или "задисциплинировали" розгами по рукам так, что гарантия 100% безошибочности?
V_>>- не зависит от внутреннего формата, документации и прочего S>Абсолютно верно, не зависит.
(C) Шериданю Учитывая, что тебя тут уделали ни раз и не два, как бог черепаху, то верность утверждения тут чуть выше чем у игральной кости.
S>Так не зависьте. Набор плейбуков, мануал про бутстрап деплой и список рекомендаций.
Видишь, в чем проблема отставания? В том, что советы твои вызывают только улыбку. Безо всяких кавычек, совершенно искреннюю улыбку, как от ребенка, дающим советы на уровне своего понимания. Только у ребенка есть потенциал.
Здравствуйте, Sheridan, Вы писали:
V_>>>>Стандартизация как Deployment так и runtime S>>>Как подготовка к разрушению мира при прилёте дятла — да, годится. Опасно постоянно держать всё в тепличных условиях: изменение этих условий обязательно приведёт к краху. А условия поменяются обязательно. Безошибочной работы не бывает у людей. C>>Хватит бредить, а? S>Действительно.
Ну вот у меня код с кучей вычислительных библиотек. Как мне сделать его deployment на production? Компилироваться из исходников он будет около часа.
C>>Дятел, который разрушит цивилизацию — в твоих Анзиблях. Достаточно в ОДНОМ скрипте кому-то случайно написать "rm -Rf /usr /local/something", и всё, весь production умрёт. При этом, никакой rollback не спасёт, так как production-серверы будут нерабочими. И нет никаких возможностей гарантированно предотвратить такую ситуацию. S>Достаточно не выдавать нетестированный код в прод.
Тестирование никогда не находит всех ошибок. Пора бы знать уже.
C>>В случае с Docker/Kubernetes такая ситуация НЕВОЗМОЖНА в принципе. Код, который может быть ошибочен, специально изолирован и ограничен, так что последствия его отказа тоже будут ограничены и предсказуемы. И это принципиально правильный подход, вообще во всей инженерной науке. S>А у вас отказ кода может привести к краху системы вообще? И докер для того чтобы система не ломалась? Как вам такое удаётся?
Отказ кода может привести к краху, да. Как и в любой системе. Докер позволяет код структурировать, так что в случае отказа система ведёт себя предсказуемо и гарантированна возможность отката.
C>>Основная мысль — человеческих ошибок (почти) не бывает. Если система допускает возможность катастрофических "человеческих ошибок" — это проблема системы, а не человеков. S>Хорошая теория, только не согласуется с практикой, где автоматика работает так как надо, а ошибки в основном из за действий людей.
Мда. Выделил.
Здравствуйте, Sheridan, Вы писали:
C>>Нет, я про сборку на проде. У нас есть код, сборка которого занимает почти час. Так и будем на всех серверах компилировать? S>Дядя, у тебя цель какая? Доказать что ансибл гавно или что? Вот этот глупый вопрос к чему ты принёс? Ты вроде не глупый человек но пошол по пути "А щас я спрощу какую нибудь херню и понаблюдаю." S>Про сборка/деплой я писал раньше. Даже вроде бы тебе.
Ну так как собирать-то будем?
C>>>>Этого никак нельзя гарантировать с ansible, так как это просто тупая запускалка команд. S>>>А докер это тупой chroot, да? C>>Да. И благодаря этому он и гарантирует надёжность. S>chroot это не про надёжность, а про изоляцию. Хоть 20 раз заchroot'ь бажный софт — работать он от этого не начнёт.
Он так же не станет безбажным, если повторять: "анзибльанзибльанзибльанзибльанзибльанзибль". Только в моём случае баги будут предсказуемы, а в случае "анзибльанзибльанзибльанзибльанзибльанзибль" — они будут ломать всё.
S>>>Я с ансиблом тоже такое гарантировать могу. C>>Нет, не можешь. Так как ansible — это тупая запускалка, то там можно забыть добавить очистку временных файлов, например. S>А можно не забыть, например. Поэтому — смогу.
Нет, забудешь. И напишешь "rm -Rf /", а потом уйдёшь дальше в другие компании ломать.
Замечаем, что если файл /etc/letsencrypt/live/srv/cert.pem существует, то скрипт ничего не сделает.
В частности, такая ситуация возможна, если файл остался от предыдущей версии софта. Так как Ansible ничего сам не чистит, то при удалении playbook'а легко этот файл случайно оставить.
Так же это возможно, если certbot рухнул в промежутке между созданием файла и записью туда. Тогда у нас будет просто пустой файл.
C>>>Основная мысль — человеческих ошибок (почти) не бывает. Если система допускает возможность катастрофических "человеческих ошибок" — это проблема системы, а не человеков. S>>Хорошая теория, только не согласуется с практикой, где автоматика работает так как надо, а ошибки в основном из за действий людей. C>Мда. Выделил.
Выделяй-не выделяй, не добьешься нифига.
Вот слова Шеридана:
Хорошая теория, только не согласуется с практикой, где автоматика работает так как надо
(ансибл потому что) руками долго и сложно поддерживать единое окружение.
И одновременно он топит против докера. Он даже это не способен понять, а ты ему что-то выделяешь.
Здравствуйте, Sheridan, Вы писали:
S>Чем не устраивает systemd?
Что можно сделать с докером, просто глянув мануал:
— выставить лимиты по памяти и cpu для приложения (про control groups в линуксе я вкурсе),
— получить горизонтальное скалирование,
— до кучи ещё балансировку нагрузки,
— виртуальную сеть, чтобы сервисы видели только те сервисы, которые должны видеть,
— мониторинг на примитивном уровне,
— прозрачное логирование в любом формате без этих ваших logrotate, а с использование православного ELK-стека,
— healthcheck и перезапуск, если кто-то в лесу умер.
+ разработку можно вести на чём угодно.
V_>>Стандартизация как Deployment так и runtime S>Как подготовка к разрушению мира при прилёте дятла — да, годится. Опасно постоянно держать всё в тепличных условиях: изменение этих условий обязательно приведёт к краху. А условия поменяются обязательно. Безошибочной работы не бывает у людей.
Чтобы минимизировать последствия ошибок.
V_>>2. Инкапсуляция\изоляция, гарантируемая фреймфорком. S>Зачем она нужна? Просто для того чтобы программеры могли писать бажный софт, который работает только в песочнице?
А где-то уже научились писать софт без багов?
S>А какая разница откуда ошибка? Её надо изучать, чинить, анализировать где ещё такое может возникнуть. А не разделять на "внутри/снаружи".
"Разделяй и властвуй". Ошибка может быть связана:
— с инфраструктурой (место на диске закончилось, кто-то в секьюрити-прокси урл нужный не добавил). Если я разработчик, то это а) не моя головная боль, б) у меня всё равно прав нет.
— с кодом. Если я девопс — это не моя проблема.
Если же все ошибки сваливать в одну кучу, то очень быстро на них все перестанут обращать внимание.
V_>>Компоненты можно рассматривать как черные ящики, с четко определенным интерфейсом, который можно запросить через API. Т.к. это гарантируется на уровне фреймворка, то получаем огромную пропасть между "возможно соответствует" и "гарантируется" S>Ансибл (как впрочем и докер, но с большими возможностями) как раз и предназначен для подъёма на ступеньку "гарантируется".
Ансибл — это такой продвинутый bash.
S>Рекомендации будут типа "смени порт",
Такие вещи на уровне конфигурации, а не кода делаются. В случае с докером вообще параллельно какой там порт или путь, всё можно замапить одной строчкой в конфигурационном файле.
S>"перейди на такую версию библиотеки" и чтото в этом роде.
Варианты ответов на такое предложение:
— Это сторонний софт.
— С текущей версией всё протестировано.
— Времени тупо нет.
M>С единственной поправкой: Шеридан — это второй, с претензией на первый. Его оппоненты — весь спектр между первым и вторым и почти никогда — строго вторые. Более того, его оппоненты как совокупно так и по отдельности имеют в разы больше опыта. В том числе с теми же инструментами, о которых он высокопарно вещает.
Мне сие неизвестно. Я лишь вижу что один хочет от девелоперов, чтобы те сами за собой чистили, а второй говорит "нефиг им на это время тратить, пусть за них чистят докеры". Оба подхода имеют право на жизнь — в конце концов, сами эти докеры кто-то же должен писать, и за самим докером тоже кто-то должен же прибрать.
M>Если у меня красивый оттестированый и безбажный код — это не значит что я должен выкинуть докер.
Если код у тебя красивый, оттестированный и безбажный, но работает только вот в этом контейнере, и только вот с этим железом, и только вот с такой версией ядра на хосте, где запущен этот контейнер, ну и еще версия докера не какая-нибудь, а X.Y.Z, то... это "works on my machine".
И если выход за эти рамки вызывает неправильное функционирование — это и называется "баг на баге и багом погоняет".
Здравствуйте, SkyDance, Вы писали:
SD>Если код у тебя красивый, оттестированный и безбажный, но работает только вот в этом контейнере, и только вот с этим железом, и только вот с такой версией ядра на хосте, где запущен этот контейнер, ну и еще версия докера не какая-нибудь, а X.Y.Z, то... это "works on my machine".
В случае с Докером единственная реальная зависимость, которую я видел — это наличие нужного ядра, если используются продвинутые функции (io_uring, например). Я могу представить теоретически, что софт зависит от каких-то AVX-инструкций, которые есть только на определённом железе, но такого в реальной жизни я не видел.
А вот в случае с неконтейнерным софтом — ошибки из-за версии glibc встречаются чуть менее, чем всегда.
M>В итоге там (почти) все выкинули нахрен, сделали централизованный сервис, где деплой и развертка делаются по клику одной кнопки (среди прочего. Его медленно кусками опенсорсят тут: https://backstage.io). И постепенно перетаскивают все в кубернетес и докер.
ха-ха.
Старая история совместной работы продуктовых и инфраструктурных команд.
Первым надо "некогда учиться, нужно код строчить", а на вторых сваливается настроченный код, и его проще выкинуть, чем использовать ("деплой одной кнопкой").
V_>Не освоили еще. Весьма распространенное явление, все многие всегда находятся в процессе обучения. Это нормально
Кстати, вот тут не согласен.
Любой уровень абстракции (включая кубернетес) есть не более чем еще один уровень абстракции. Если можно избежать добавления уровней абстракции без существенного изменения операционных характеристик, то это обязательно следует сделать. Иными словами, кубернетес нужно вкрячивать только если он реально очень нужен! А не потому что "я научился с ним работать, теперь везде его запихаю".
C>В случае с Докером единственная реальная зависимость, которую я видел — это наличие нужного ядра, если используются продвинутые функции (io_uring, например). Я могу представить теоретически, что софт зависит от каких-то AVX-инструкций, которые есть только на определённом железе, но такого в реальной жизни я не видел.
Скажу честно, изобретательность многих особо одаренных девелоперов рождает такие чудища, где зависимости появляются абсолютно на что угодно начиная от конкретной версии хостовой ОС, и заканчивая, да-да, маской подсети хоста.
Там, конечно, еще и сам докер добавляет, который на разных ОС (скажем, макОС) порой вытворяет неожиданные вещи.
А вообще я еще и другой фактор имел в виду. У меня немало практики работы с людьми разных уровней, и почти всегда те, кто полагаются на конкретную-версию-этой-либы-и-этого-образа попросту не умеют писать надежный софт. И совершенно не умеют его тестировать. Попытки объяснить, как вообще осуществлять тестирование, разбиваются о волну непонимания. Из серии "да как же это так, с чего вдруг мы тестирование случайными запросами называем умным словом property-based testing, да еще и так выходит, что тесты сложнее самого кода, который тестируется".
В общем, перфекционизм, он или есть, или его нет. Надо просто найти правильное применение — перфекционистов вниз к железу и ОС, а тех, кому побыстрее скопипастить со стек-оверфлоу, — на передовую софтовой разработки.
Главное понимать, куда кого применить, и не пытаться от профессора требовать говнокода, а от говнокодеров — чистки и уборки за собой. Первых — в университет, вторых — в Докеры.
Здравствуйте, gandjustas, Вы писали:
G>А вот в чем профит от "микросервисов" — я до сих пор не понял и даже внятных примеров нет.
Ну а как насчёт уменьшить время сборки, тем самым повысив продуктивности разработчиков (локально) и понизив время, которое требуется на релиз новой версии?
Допусти надо срочно сделать какое-то небольшое изменение, протестировать и выкатить его. В случае с монолитом единственный вариант собирать, тестировать и деплоить всё приложение. С отдельным сервисом, если изменение затрагивает только этот сервис, может оказаться быстрее, так как те же действия надо выполнить только для одного сервиса (в некоторых случаях протестировать ещё и зависимые от него сервисы).
Хотя, конечно, зависит от того, что называть "микросервисами". Повсеместно лепить какие-нибудь CustomerService, ProductService, OrderService, OrderItemService это наверное чересчур и создаёт больше проблем, чем решает. Но в то же время отделить, скажем, ProductReportingService от OrderProcessingService теоретически может иметь преимущества вроде описаных выше.
Здравствуйте, SkyDance, Вы писали:
SD>Если код у тебя красивый, оттестированный и безбажный, но работает только вот в этом контейнере, и только вот с этим железом, и только вот с такой версией ядра на хосте, где запущен этот контейнер, ну и еще версия докера не какая-нибудь, а X.Y.Z, то... это "works on my machine".
такие случаи бывают( и как правило это какие то проприетарные 3rd party библиотеки),
но это не необходимое условие для использования докера.
Докер вполне себя оправдывает и с нормальным, чистым кодом который на любой машине
Здравствуйте, SkyDance, Вы писали:
SD>Любой уровень абстракции (включая кубернетес) есть не более чем еще один уровень абстракции. Если можно избежать добавления уровней абстракции без существенного изменения операционных характеристик, то это обязательно следует сделать. Иными словами, кубернетес нужно вкрячивать только если он реально очень нужен! А не потому что "я научился с ним работать, теперь везде его запихаю".
+1
если говорить про AWS, то на небольших и средних проектах вполне работает ECS
Здравствуйте, Farsight, Вы писали:
S>>А вы не вкорячивайте старые либы а пользуйте те, которые в составе дистрибутива есть. F>Это либы для других приложений от других поставщиков, к коим мы не имеем отношения. Поэтому контенеризация и рулит.
Раз они предназначены другим приложениям, вам не нужны, то зачем вы их ставите?
Здравствуйте, mogadanez, Вы писали:
S>>А можно не забыть, например. Поэтому — смогу. M>но это увеличивает стоимость, как создания плейбуков так и их поддержки
А то создание образов и их поддержка не увеличивает стоимость. А там ещо окажется что и за хранение образов надо платить сферическому докерхабу.
Здравствуйте, Vetal_ca, Вы писали:
S>>Зачем себе в колёса пихать палки? Мсье мазохист? S>>Нахрена на своих серверах для своего проекта городить зоопарк? Или просто в голову больше ничего не приходит в защиту докеров? V_>Я читаю, и начинаю подозревать, что ты прав: у тебя задачи такие, что на VB в Экселе запустить можно. Не нужен ни докер, ни Ансибл ни Шеридан
То что ты не умеешь читать я уже давно понял.
S>>Я этот шаг успешно прошёл и научился определять когда контейнеризация нужна, а когда — нет. V_>Я такое уже видел. У начинающих. А ты, одновременно, и начинающий и уже все, "остановившийся в начинании".
Начинающий это ты. Стадию докера так и не прошол, остановился в ней.
S>>Никогда не поверю, что у вас в мануале нет "рекомендуется использовать дистрибутив Х", что читается техподдержкой как "а, вы на У, тогда ой". А раз так, то тогда и окружение будет нужным. V_>Не надо верить, надо фокусироваться на насущном. А насущное тебе: еще учиться и пройти отбор. С таким же успехом можешь почитать инструкцию по одеванию скафандра для выхода в открытый космос
Ну то есть я прав — у вас есть "рекомендации" и шаг в сторону от них будет означать отказ в техподдержке. То есть даже докеры не помогают. Софт работает вообще отвратно.
S>>И ты говоришь о надёжности? Не нужно выводить список. Нужен алерт на "сертификат закончится через Х часов" и реакция на алерт с получением и установкой сертификатов. Ручная или атоматическая — другой вопрос. S>>https://medium.com/@khandelwal12nidhi/automate-letsencrypt-ssl-installation-with-ansible-for-multiple-domains-8453f2c3212d V_>Ты даже смысл написанного осилить не можешь. Ближайший пример я видел, это африканцы, которые гайку на болт накрутить не могут. Для нас это интуитивно-понятно, а они никогда не держали в руках и не могут. Ну и советы дают, про другую гайку.
Повторю твои же слова: ты даже смысл написанного осилить не можешь.
S>>Не нужно ничего выводить, нужно организовывать этот чек. Сразу. Нужен — сделали. V_>У вас даже на прием на работу чек плохой, дальше и говорить нечего
Да уж получше чем у вас, это очевидно.
V_>>>- сделать это может любой специалист, работавший с кубернетес и умеющий JQ, в том числе если это его первый день на этой работе S>>Для ансибла не нужно спецзнаний. Нужен плейбук и обезьяна. V_>Подумай, может и на Экселе можно?
Завидно, что не нужно специальных знаний, да?
V_>>>- делается для всего кластера. Можно сделать для всех кластеров S>>Никаких проблем. Для всех кластеров сразу. V_>Весело, включая и твою ошибочную команду, ибо Ansible позволяет записать, все что угодно. Или "задисциплинировали" розгами по рукам так, что гарантия 100% безошибочности?
Обидно что годные специалисты работают не с тобой, да?
V_>>>- не зависит от внутреннего формата, документации и прочего S>>Абсолютно верно, не зависит. V_>(C) Шериданю Учитывая, что тебя тут уделали ни раз и не два, как бог черепаху, то верность утверждения тут чуть выше чем у игральной кости.
Вера, она такая, совершенно иррациональна.
S>>Так не зависьте. Набор плейбуков, мануал про бутстрап деплой и список рекомендаций. V_>Видишь, в чем проблема отставания? В том, что советы твои вызывают только улыбку. Безо всяких кавычек, совершенно искреннюю улыбку, как от ребенка, дающим советы на уровне своего понимания. Только у ребенка есть потенциал.
Ну то есть вы пишете такой негодный софт, что даже для его деплоя нужно обучать специаличтов? Мде... Ну сочувствую, чо.
Здравствуйте, Cyberax, Вы писали:
C>Ну вот у меня код с кучей вычислительных библиотек. Как мне сделать его deployment на production? Компилироваться из исходников он будет около часа.
Опакетить при сборке проекта, устанавливать пакет при деплое. Ну, первое что в голову пришло.
C>>>Дятел, который разрушит цивилизацию — в твоих Анзиблях. Достаточно в ОДНОМ скрипте кому-то случайно написать "rm -Rf /usr /local/something", и всё, весь production умрёт. При этом, никакой rollback не спасёт, так как production-серверы будут нерабочими. И нет никаких возможностей гарантированно предотвратить такую ситуацию. S>>Достаточно не выдавать нетестированный код в прод. C>Тестирование никогда не находит всех ошибок. Пора бы знать уже.
Это должно как то противоречить моим словам или что? И почему у тебя "все ошибки" это именно "rm -fr /" или чтото типа этого?
S>>А у вас отказ кода может привести к краху системы вообще? И докер для того чтобы система не ломалась? Как вам такое удаётся? C>Отказ кода может привести к краху, да. Как и в любой системе.
Нет. постгрес, мускуль, раббит, бинд, дхцпц и так далее умудряются писать как то так, что их крах не приводит к краху системы. А вы умудряетесь.
C>Докер позволяет код структурировать, так что в случае отказа система ведёт себя предсказуемо и гарантированна возможность отката.
С ансиблом такое тоже возможно.
Только вот на самом деле надо писать код так, чтобы он работал. Тогда и не придётся тратить время на танцы с обеспечением тепличных условий.
C>>>Основная мысль — человеческих ошибок (почти) не бывает. Если система допускает возможность катастрофических "человеческих ошибок" — это проблема системы, а не человеков. S>>Хорошая теория, только не согласуется с практикой, где автоматика работает так как надо, а ошибки в основном из за действий людей. C>Мда. Выделил.
Да хоть три раза выдели — эта теория всё равно не начнёт согласовываться с практикой.
Здравствуйте, Cyberax, Вы писали:
C>>>Нет, я про сборку на проде. У нас есть код, сборка которого занимает почти час. Так и будем на всех серверах компилировать? S>>Дядя, у тебя цель какая? Доказать что ансибл гавно или что? Вот этот глупый вопрос к чему ты принёс? Ты вроде не глупый человек но пошол по пути "А щас я спрощу какую нибудь херню и понаблюдаю." S>>Про сборка/деплой я писал раньше. Даже вроде бы тебе. C>Ну так как собирать-то будем?
программирование->сборка->тесты->деплой->эксплуатация
Догадайся сам — на каком этапе сборка.
C>>>>>Этого никак нельзя гарантировать с ansible, так как это просто тупая запускалка команд. S>>>>А докер это тупой chroot, да? C>>>Да. И благодаря этому он и гарантирует надёжность. S>>chroot это не про надёжность, а про изоляцию. Хоть 20 раз заchroot'ь бажный софт — работать он от этого не начнёт. C>Он так же не станет безбажным, если повторять: "анзибльанзибльанзибльанзибльанзибльанзибль". Только в моём случае баги будут предсказуемы, а в случае "анзибльанзибльанзибльанзибльанзибльанзибль" — они будут ломать всё.
Нет, не будут они более предсказуемы. Хоть трижды возненавидь ансибл и возлюби докер.
S>>>>Я с ансиблом тоже такое гарантировать могу. C>>>Нет, не можешь. Так как ansible — это тупая запускалка, то там можно забыть добавить очистку временных файлов, например. S>>А можно не забыть, например. Поэтому — смогу. C>Нет, забудешь. И напишешь "rm -Rf /", а потом уйдёшь дальше в другие компании ломать.
Подобные ошибки (да и любые другие) отлавливаются на тестах, в приемлемом для бизнеса количестве. Возникающие впоследствии у клиентов баги чинятся уже хотфиксами. И так далее.
Мне правда тебя этому ещё учить надо?
Здравствуйте, Cyberax, Вы писали:
C>Ооочень хороший пример работы кое-какеров, у которых цивилизация рухнет от первого дятла.
Оооочень хороший пример раздувания из мухи слона.
C>
C>Замечаем, что если файл /etc/letsencrypt/live/srv/cert.pem существует, то скрипт ничего не сделает. C>В частности, такая ситуация возможна, если файл остался от предыдущей версии софта. Так как Ansible ничего сам не чистит, то при удалении playbook'а легко этот файл случайно оставить. C>Так же это возможно, если certbot рухнул в промежутке между созданием файла и записью туда. Тогда у нас будет просто пустой файл.
Надо другую проверку? Будет другая. Очевидно что автору этого достаточно. Потому что проще->понятнее->легче поддерживать.
Но ты конечно же будешь продолжать утверждать что ансибл говно.
C>Замечательный пример халтуры, да.
Халтура у тебя в коде, он без контейнеров работать не может.
Здравствуйте, User239, Вы писали:
U>Здравствуйте, gandjustas, Вы писали:
G>>А вот в чем профит от "микросервисов" — я до сих пор не понял и даже внятных примеров нет.
U>Ну а как насчёт уменьшить время сборки, тем самым повысив продуктивности разработчиков (локально) и понизив время, которое требуется на релиз новой версии?
А как насчет увелиения времени сборки если изменение затрагивает более одного компонента? Причем если мы делаем микросервисную архитектуру с начала, то мы платим за призрачную будущую выгоду прямо сейчас.
Здравствуйте, Андрей Бабошин, Вы писали:
S>>Чем не устраивает systemd? АБ>Что можно сделать с докером, просто глянув мануал: АБ> — выставить лимиты по памяти и cpu для приложения (про control groups в линуксе я вкурсе), АБ> — получить горизонтальное скалирование, АБ> — до кучи ещё балансировку нагрузки, АБ> — виртуальную сеть, чтобы сервисы видели только те сервисы, которые должны видеть, АБ> — мониторинг на примитивном уровне, АБ> — прозрачное логирование в любом формате без этих ваших logrotate, а с использование православного ELK-стека, АБ> — healthcheck и перезапуск, если кто-то в лесу умер.
Почему ты уверен, что этого нельзя сделать с systemd с деплоем на ансибле?
АБ>+ разработку можно вести на чём угодно.
А ансибл как то мешает этому?
V_>>>Стандартизация как Deployment так и runtime S>>Как подготовка к разрушению мира при прилёте дятла — да, годится. Опасно постоянно держать всё в тепличных условиях: изменение этих условий обязательно приведёт к краху. А условия поменяются обязательно. Безошибочной работы не бывает у людей. АБ>Чтобы минимизировать последствия ошибок.
Последствия ошибок всегда одинаковы: гдето не работает кусок чегото.
Три базовых подхода: масштабирование, рестарт, починка ошибки.
Последнее относится в программированию. А первые две относятся к деплою и отлично решаются ансиблом.
V_>>>2. Инкапсуляция\изоляция, гарантируемая фреймфорком. S>>Зачем она нужна? Просто для того чтобы программеры могли писать бажный софт, который работает только в песочнице? АБ>А где-то уже научились писать софт без багов?
Настолько чтобы не нужна была песочница? Да, подавляющее большинство программистов так делают.
S>>А какая разница откуда ошибка? Её надо изучать, чинить, анализировать где ещё такое может возникнуть. А не разделять на "внутри/снаружи". АБ>"Разделяй и властвуй". Ошибка может быть связана: АБ> — с инфраструктурой (место на диске закончилось, кто-то в секьюрити-прокси урл нужный не добавил). Если я разработчик, то это а) не моя головная боль, б) у меня всё равно прав нет. АБ> — с кодом. Если я девопс — это не моя проблема.
Это видно и без всяких докеров.
Докер для этого абсолютно не нужен.
АБ>Если же все ошибки сваливать в одну кучу, то очень быстро на них все перестанут обращать внимание.
А их не надо сваливать в кучу, правильно. Более того, нужно поднимать мониторинг и алерты на базовые "кончается место/сертификат/память/сахар в сахарнице".
V_>>>Компоненты можно рассматривать как черные ящики, с четко определенным интерфейсом, который можно запросить через API. Т.к. это гарантируется на уровне фреймворка, то получаем огромную пропасть между "возможно соответствует" и "гарантируется" S>>Ансибл (как впрочем и докер, но с большими возможностями) как раз и предназначен для подъёма на ступеньку "гарантируется". АБ>Ансибл — это такой продвинутый bash.
докер — это такой продвинутый chroot.
S>>Рекомендации будут типа "смени порт", АБ>Такие вещи на уровне конфигурации, а не кода делаются. В случае с докером вообще параллельно какой там порт или путь, всё можно замапить одной строчкой в конфигурационном файле.
Абсолютно верно. Если программер реализовал. Тут гдето пробегало что "докер нужен чтобы приложения другдругу не мешали порты поднимать".
S>>"перейди на такую версию библиотеки" и чтото в этом роде. АБ>Варианты ответов на такое предложение: АБ> — Это сторонний софт.
Что значит "сторонний"? Понтно что не ваш. Чей, откуда взялся?
АБ> — С текущей версией всё протестировано.
Достаточно глупая отмазка. Так можно дойти и до "дальше разрабатывать не надо, текущая версия протестирована" и поувольнять программистов.
АБ> — Времени тупо нет.
Запланируйте. Скажите девапсу что мол "ок, в следующей итреации сделаем, добавь нам таск"
SD>Мне сие неизвестно. Я лишь вижу что один хочет от девелоперов, чтобы те сами за собой чистили,
Вот девелоперы и выбирают инструменты которые позволяют им гарантированно убрать за собой А Шеридан несет чушь (включая пургу типа «девопсы должны говорить программистам, что подчищать и какие версии библиотек использовать»).
SD>а второй говорит "нефиг им на это время тратить, пусть за них чистят докеры". Оба подхода имеют право на жизнь — в конце концов, сами эти докеры кто-то же должен писать, и за самим докером тоже кто-то должен же прибрать.
Да неужели? А ансибл, за который цепляется Шеридан, никто не должен писать?
Здравствуйте, Sheridan, Вы писали:
S>Почему ты уверен, что этого нельзя сделать с systemd с деплоем на ансибле?
Можно, вопрос сколько времени мне надо будет потратить, чтобы соорудить то же самое с помощью systemd+ansible.
А ещё у меня есть привычка уходить в отпуск и отключать телефон, т.е. мне надо будет не только сделать и описать, но и подготовить кого-то, кто в случае чего сможет дополнить и расширить, или починить.
Порог входа с докером существенно ниже.
АБ>>+ разработку можно вести на чём угодно. S>А ансибл как то мешает этому?
У разработчиков могут быть маки, винда и какая-нибудь версия линукса. Ну так исторически сложилось.
Пересадить всех на одну версию ОС нельзя, потому что сейчас бюджета не это нет.
А целевая платформа — линукс конкретной версии.
Варианты:
— поставить докер и взять нужный базовый образ,
— поднять виртуалку и разобраться как запускать этот ansible. На винде он без WSL не работает.
V_>>>>2. Инкапсуляция\изоляция, гарантируемая фреймфорком. S>>>Зачем она нужна? Просто для того чтобы программеры могли писать бажный софт, который работает только в песочнице? АБ>>А где-то уже научились писать софт без багов? S>Настолько чтобы не нужна была песочница? Да, подавляющее большинство программистов так делают.
По отдельности — вполне себе допускаю. А в команде, да ещё и с заказчиками, которые внятные требования родить не могут...
S>докер — это такой продвинутый chroot.
Ну да.
S>Что значит "сторонний"? Понтно что не ваш. Чей, откуда взялся?
Купили, разработан другим отделом.
АБ>> — С текущей версией всё протестировано. S>Достаточно глупая отмазка.
Нормальная отмазка. Разработчику нужно бизнес-требования имплементировать, а не с разными версиями очередной библиотеки сношаться.
Я как разработчик буду обновлять библиотеку только в том случае, если размер плюсов гарантированно перевесит размер головняка.
S>Так можно дойти и до "дальше разрабатывать не надо, текущая версия протестирована" и поувольнять программистов.
"Вы не поверите". В какой-то момент заказчик решает, что текущая версия его удовлетворяет и оставляет только поддержку.
АБ>> — Времени тупо нет. S>Запланируйте. Скажите девапсу что мол "ок, в следующей итреации сделаем, добавь нам таск"
Угу, запланируйте, согласуйте бюджет, договоритесь с заказчиком, что в следующем спринте фич будет меньше, потому что девопсу надо библиотеку обновить.
Здравствуйте, Sheridan, Вы писали:
S>Раз они предназначены другим приложениям, вам не нужны, то зачем вы их ставите?
Мы их не ставим, их ставят другие поставщики. Совсем потерялся?
Здравствуйте, Андрей Бабошин, Вы писали:
АБ>Можно, вопрос сколько времени мне надо будет потратить, чтобы соорудить то же самое с помощью systemd+ansible.
Зависит от задачи. В среднем время сопоставимо.
АБ>А ещё у меня есть привычка уходить в отпуск и отключать телефон, т.е. мне надо будет не только сделать и описать, но и подготовить кого-то, кто в случае чего сможет дополнить и расширить, или починить.
Это валидно для чего угодно. Точно так же и с докером.
АБ>Порог входа с докером существенно ниже.
Я бы не сказад что ансибл сильно сложнее.
АБ>>>+ разработку можно вести на чём угодно. S>>А ансибл как то мешает этому? АБ>У разработчиков могут быть маки, винда и какая-нибудь версия линукса. Ну так исторически сложилось.
А, ты про разработку. Ну так для разработки докеры хороши, я сразу об этом написал
АБ>>>А где-то уже научились писать софт без багов? S>>Настолько чтобы не нужна была песочница? Да, подавляющее большинство программистов так делают. АБ>По отдельности — вполне себе допускаю. А в команде, да ещё и с заказчиками, которые внятные требования родить не могут...
Ну ты сам понимаешь что сдавать софт работающий исключительно в песочнице — такое себе решение.
S>>Что значит "сторонний"? Понтно что не ваш. Чей, откуда взялся? АБ>Купили, разработан другим отделом.
Купили бажный, не работающий софт?
Отдел не может перейти на свежую версию используемой либы?
АБ>>> — С текущей версией всё протестировано. S>>Достаточно глупая отмазка. АБ>Нормальная отмазка. Разработчику нужно бизнес-требования имплементировать, а не с разными версиями очередной библиотеки сношаться. АБ>Я как разработчик буду обновлять библиотеку только в том случае, если размер плюсов гарантированно перевесит размер головняка.
А когда головняк относится к деплою, то "это не моя проблема, у меня всё работает!", я правильно понял?
S>>Так можно дойти и до "дальше разрабатывать не надо, текущая версия протестирована" и поувольнять программистов. АБ>"Вы не поверите". В какой-то момент заказчик решает, что текущая версия его удовлетворяет и оставляет только поддержку.
LTS аббревиатура тебе о чом нибудь говорит?
АБ>>> — Времени тупо нет. S>>Запланируйте. Скажите девапсу что мол "ок, в следующей итреации сделаем, добавь нам таск" АБ>Угу, запланируйте, согласуйте бюджет, договоритесь с заказчиком, что в следующем спринте фич будет меньше, потому что девопсу надо библиотеку обновить.
Да. Иначе заказчик уйдёт к тому поставщику, у которого нет проблем поддерживать актуальность своего софта для того чтобы деплой был без головняка.
Или вы пользуетесь отсуствием конкуренции и считаете что в таком случае можно х..к, х..к и в продакшн.
Здравствуйте, Sheridan, Вы писали:
АБ>>Что можно сделать с докером, просто глянув мануал: АБ>> — выставить лимиты по памяти и cpu для приложения (про control groups в линуксе я вкурсе), АБ>> — получить горизонтальное скалирование, АБ>> — до кучи ещё балансировку нагрузки, АБ>> — виртуальную сеть, чтобы сервисы видели только те сервисы, которые должны видеть, АБ>> — мониторинг на примитивном уровне, АБ>> — прозрачное логирование в любом формате без этих ваших logrotate, а с использование православного ELK-стека, АБ>> — healthcheck и перезапуск, если кто-то в лесу умер. S>Почему ты уверен, что этого нельзя сделать с systemd с деплоем на ансибле?
Так а ты распиши нам по пунктикам. Может мы прозреем, темнота мы такая. Про скалирование в горизонт и балансировку очень интересно. Учти, что кубер + докер умеют это из коробки.
АБ>>+ разработку можно вести на чём угодно. S>А ансибл как то мешает этому?
Опять потерялся. Тут поинт про единое окружение при разработке, тестировании и эксплуатации.
АБ>>Ансибл — это такой продвинутый bash. S>докер — это такой продвинутый chroot.
Ранее ты писал, что это просто chroot, а теперь вот продвинутый. Прогибаешься?
S>Запланируйте. Скажите девапсу что мол "ок, в следующей итреации сделаем, добавь нам таск"
Все таки ты не догоняешь, что такое девопс.
Здравствуйте, Farsight, Вы писали:
S>>Раз они предназначены другим приложениям, вам не нужны, то зачем вы их ставите? F>Мы их не ставим, их ставят другие поставщики. Совсем потерялся?
Тогда это их головная боль. За всем миром все баги не вылечишь. Сначала со своими разберитесть, чтобы софт хотя бы заработал без тепличных условий.
Здравствуйте, Farsight, Вы писали:
АБ>>>Что можно сделать с докером, просто глянув мануал: АБ>>> — выставить лимиты по памяти и cpu для приложения (про control groups в линуксе я вкурсе), https://www.freedesktop.org/software/systemd/man/systemd.resource-control.html
АБ>>> — получить горизонтальное скалирование, АБ>>> — до кучи ещё балансировку нагрузки,
Зависит от приложения. В общем виде — нужно приложению дать такие настройки чтобы оно поняло что оно работает в кластере и нашло соседние ноды.
Ну или, если подходит, пользовать pacemaker/corosync, haproxy.
АБ>>> — виртуальную сеть, чтобы сервисы видели только те сервисы, которые должны видеть,
Множество путей. От iputils с подниманием нужных адресов на сетевухах и описанием маршрутов до поднятия туннелей.
Ну а вообще правило странное. Если сервису не нужно видеть другой сервис — ну так не пишите код, который обнаруживает другой сервис
АБ>>> — мониторинг на примитивном уровне,
Насколько примитивном? systemctl status подойдёт?
АБ>>> — прозрачное логирование в любом формате без этих ваших logrotate, а с использование православного ELK-стека,
Разворачиваем ёлку, на хостах filebeat. В чом проблема?
АБ>>> — healthcheck
Слишком расплывчато. Насколько глубоко надо? Если просто "процесс жив", то ниже написал, системд умеет. Если сложные проверки типа "на тапрос такойто сервис должен вернуть ответ такойто", то без ватчдога не обойтись и нужно писать этот самый отдельний ватчдог-сервис.
АБ>>>и перезапуск, если кто-то в лесу умер.
Restart=on-failure в юнит-файле сервиса.
S>>Почему ты уверен, что этого нельзя сделать с systemd с деплоем на ансибле? F>Так а ты распиши нам по пунктикам. Может мы прозреем, темнота мы такая. Про скалирование в горизонт и балансировку очень интересно. Учти, что кубер + докер умеют это из коробки.
Докеры этого не умеют, их надо учить. Расскажи мне про скалирование в горизонт постгреса об "в докере изкаробки", например.
АБ>>>+ разработку можно вести на чём угодно. S>>А ансибл как то мешает этому? F>Опять потерялся. Тут поинт про единое окружение при разработке, тестировании и эксплуатации.
Я понимаю, что софт ваш кроме тепличных условий нигде работать не может. Ты не понимаешь что подход "у меня всё работает" никуда не годится.
АБ>>>Ансибл — это такой продвинутый bash. S>>докер — это такой продвинутый chroot. F>Ранее ты писал, что это просто chroot, а теперь вот продвинутый. Прогибаешься?
Ранее мне писали что ансибл это просто баш. Следует понимать что вы прогнулись?
S>>Запланируйте. Скажите девапсу что мол "ок, в следующей итреации сделаем, добавь нам таск" F>Все таки ты не догоняешь, что такое девопс.
Это ты не догоняешь что работать надо в команде и слушать что тебе говорят другие специалисты, а не "у меня всё работает!"
Здравствуйте, Sheridan, Вы писали:
S>Тогда это их головная боль. За всем миром все баги не вылечишь. Сначала со своими разберитесть, чтобы софт хотя бы заработал без тепличных условий.
Я не вижу проблем в тепличных условиях. Только пользу и удобство. Появится что-то удобнее, пойду туда.
Здравствуйте, SkyDance, Вы писали:
V_>>Не освоили еще. Весьма распространенное явление, все многие всегда находятся в процессе обучения. Это нормально S>> А не потому что "я научился с ним работать, теперь везде его запихаю".
Выдумал аргумент, и думаешь, "сейчас его запихаю".
Если " А не потому что "я научился с ним работать, теперь везде его запихаю".
Для Шеридана "если" превращается в стейтмент.
А "если" я могу много привести.
Если у вас сбоит память, не стоит использовать Кубернетес
Если у вас нет сети, не стоит ...
Если вы гуманитарий ...
Если у вас нет компьютера ...
В общем, аргумент отклонен как не относящийся к делу.
S>Сначала со своими разберитесть, чтобы софт хотя бы заработал без тепличных условий.
Ладно. Покормлю тебя, потому что твои оппоненты не задают тебе очевидный вопрос. А зачем нужно вот это: «софт хотя бы заработал без тепличных условий.»? То есть понятно, зачем это нужно user-facing софту: приложениям, с которыми работают пользователи.
Зачем это нужно внутреннему софту, который разрабатывается для внутренних изначально тепличных требований (разрабатывается для определенной версии линукса, с определенными версиями библиотек, крупные изменения в окружении не требуются почти никогда, а обновления зависимостей происходят редко и обычно известны заранее)?
И чем плохи «тепличные условия», если ты сам говоришь, что «ансибл нужен, потому что руками долго и сложно поддерживать единое окружение». Чем «единое окружение» не тепличные условия?
Здравствуйте, SkyDance, Вы писали:
M>>Если у меня красивый оттестированый и безбажный код — это не значит что я должен выкинуть докер.
SD>Если код у тебя красивый, оттестированный и безбажный, но работает только вот в этом контейнере, и только вот с этим железом, и только вот с такой версией ядра на хосте, где запущен этот контейнер, ну и еще версия докера не какая-нибудь, а X.Y.Z, то... это "works on my machine". SD>И если выход за эти рамки вызывает неправильное функционирование — это и называется "баг на баге и багом погоняет".
Пришельцы, терроризирующие мирное население, тоже зло. Только, в природе не встречались.
Это, прежде чем развивать тезис, хотелось бы доказательство реальности проблемы. Тем паче, что проблема так детально описана, с привязкой к докеру, его версии и т.п.
S>>>И ты говоришь о надёжности? Не нужно выводить список. Нужен алерт на "сертификат закончится через Х часов" и реакция на алерт с получением и установкой сертификатов. Ручная или атоматическая — другой вопрос. S>>>https://medium.com/@khandelwal12nidhi/automate-letsencrypt-ssl-installation-with-ansible-for-multiple-domains-8453f2c3212d V_>>Ты даже смысл написанного осилить не можешь. Ближайший пример я видел, это африканцы, которые гайку на болт накрутить не могут. Для нас это интуитивно-понятно, а они никогда не держали в руках и не могут. Ну и советы дают, про другую гайку. S>Повторю твои же слова: ты даже смысл написанного осилить не можешь.
Здравствуйте, Sheridan, Вы писали:
S>Ну или, если подходит, пользовать pacemaker/corosync, haproxy.
Т.е. вместо того, чтобы сказать "replicas: xxx", мне надо:
— запустить эти xxx процессов,
— каждому подсунуть свою конфигурацию из-за портов, если на одной машине
— настроить haproxy
— как-то их разбросать по разным серверам.
АБ>>>> — виртуальную сеть, чтобы сервисы видели только те сервисы, которые должны видеть, S>Множество путей. От iputils с подниманием нужных адресов на сетевухах и описанием маршрутов до поднятия туннелей. S>Ну а вообще правило странное. Если сервису не нужно видеть другой сервис — ну так не пишите код, который обнаруживает другой сервис
Т.е. предлагается ещё и самому управлять vlan'ами.
АБ>>>> — healthcheck S>Слишком расплывчато. Насколько глубоко надо? Если просто "процесс жив", то ниже написал, системд умеет. Если сложные проверки типа "на тапрос такойто сервис должен вернуть ответ такойто", то без ватчдога не обойтись и нужно писать этот самый отдельний ватчдог-сервис.
Вот, писать отдельный ватчдог-сервис.
В случае же с предметом обсуждения добавление healthcheck'а выливается в добавлении пары конфигруационных параметров.
АБ>>Я как разработчик буду обновлять библиотеку только в том случае, если размер плюсов гарантированно перевесит размер головняка. S>А когда головняк относится к деплою, то "это не моя проблема, у меня всё работает!", я правильно понял?
Вот с этого момента подробнее, пожалуйста.
Команда разработчиков выбрала версию X некой библиотеки.
В какой-то момент приходит девопс и говорит, что надо обновится до версии X + 1.
В данном случае это проблема девопса обосновать необходимость обновления и согласовать дополнительные сроки.
Понятно, что в чудесном мире с розовыми понями обновление библиотеки должно пройти безболезненно и, может даже, с некоторым удовольствием,
только на практике окажется, что с большой долей вероятности обновление потянет за собой какие-то исправления.
АБ>>>>+ разработку можно вести на чём угодно. S>>>А ансибл как то мешает этому? F>>Опять потерялся. Тут поинт про единое окружение при разработке, тестировании и эксплуатации. S>Я понимаю, что софт ваш кроме тепличных условий нигде работать не может. Ты не понимаешь что подход "у меня всё работает" никуда не годится.
Софт работает у разработчика, софт работает на тестовом стенде, а на проде "вдруг" перестаёт работать, потому что версии библиотек не те.
АБ>>По отдельности — вполне себе допускаю. А в команде, да ещё и с заказчиками, которые внятные требования родить не могут... S>Ну ты сам понимаешь что сдавать софт работающий исключительно в песочнице — такое себе решение.
Песочница выражатеся в том, что даёт гарантированное окружение.
Касаемо про "без багов": всего навсего вопросов выделенных временных и денежных ресурсов.
Если заказчик готов ждать новую версию не две недели, а два месяца (с тем же набором фич), и готов за это платить, то багов будет меньше.
Если готов ждать два года, то багов не будет. или почти не будет.
П.С. Я выделил жирным про единое окружение.
С докером софту абсолютно неважно, где запускаться: на машине ли разрабочика, на внутреннем ли тестовом стенде, в кластере у заказчика или в том же амазоне.
Разработчик может жёстко прописать версии библиотек, с которыми всё точно работает, а не надеятся, что на целевом сервере будет нужная версия. Или не будет, потому что кто-то её обновил.
Т.е. стандартизация и унификация, без необходимости настраивать окружение.
Плюс большое количество вещей уже из коробки, без необходимости погружаться в детали: т.е. низкий порог входа.
Я не говорю, что ansible+systemd далее по списку — это плохо и тьфу-тьфу, но порог входа, последствия ошибок как-то сильно не в его пользу.
Здравствуйте, gandjustas, Вы писали:
U>>Ну а как насчёт уменьшить время сборки, тем самым повысив продуктивности разработчиков (локально) и понизив время, которое требуется на релиз новой версии? G>А как насчет увелиения времени сборки если изменение затрагивает более одного компонента? Причем если мы делаем микросервисную архитектуру с начала, то мы платим за призрачную будущую выгоду прямо сейчас.
Сборку разных компонентов можно запустить параллельно (понятно, конечно, что параллельная сборка одного большого компонента тоже возможна, но это не всегда и не так просто).
G>Причем если мы делаем микросервисную архитектуру с начала, то мы платим за призрачную будущую выгоду прямо сейчас.
В этом согласен. Тут можно провести аналогию с рефакторингом кода. Вместо того чтобы пытаться строить "идеальную" архитектуру, лучше сделать как проще и быстрее и, когда необходимость назреет (из-за слишком долгой сборки или других требований), провести "рефакторинг" архитектуры.
SD>А вообще я еще и другой фактор имел в виду. У меня немало практики работы с людьми разных уровней, и почти всегда те, кто полагаются на конкретную-версию-этой-либы-и-этого-образа попросту не умеют писать надежный софт. И совершенно не умеют его тестировать. Попытки объяснить, как вообще осуществлять тестирование, разбиваются о волну непонимания. Из серии "да как же это так, с чего вдруг мы тестирование случайными запросами называем умным словом property-based testing, да еще и так выходит, что тесты сложнее самого кода, который тестируется".
часто проблемы с версиям бывают из-за third-party библиотек/софта котырые не обновлялись хрен знает сколько или апргрейд стоит кучу денег которые бизнес сейчас не хочет тратить.
Здравствуйте, mogadanez, Вы писали:
S>>А там ещо окажется что и за хранение образов надо платить сферическому докерхабу. M>репозиторий можно иметь свой. вот ты говоришь что пользовался докером — но по тому что ты про него пишешь — не похоже
Я ещё дополню, что докер образы по слоям хранит. Если базовый образ не менять, то накладные расходы пренбрежимо малы.
Здравствуйте, Sheridan, Вы писали:
S>Но ты конечно же будешь продолжать утверждать что ансибл говно.
вообще тебе все говорят что ансибл имеет право на жизнь в каких то сценариях, но докер для нас проще и надежне и мы выбираем его
твоя же позиция совсем ортодоксальна
Здравствуйте, Sheridan, Вы писали:
C>>Ну вот у меня код с кучей вычислительных библиотек. Как мне сделать его deployment на production? Компилироваться из исходников он будет около часа. S>Опакетить при сборке проекта, устанавливать пакет при деплое. Ну, первое что в голову пришло.
Т.е. нужен специальный репозиторий для хранения пакетов, в котором будут лежать несколько версий (для откатов). Так как версий может быть несколько, то нужно уметь ставить определённую из них. Так что нужен какой-то софт, которой будет этим управлять.
Затем ещё несколько итеративных шагов — и получается Docker.
S>>>Достаточно не выдавать нетестированный код в прод. C>>Тестирование никогда не находит всех ошибок. Пора бы знать уже. S>Это должно как то противоречить моим словам или что? И почему у тебя "все ошибки" это именно "rm -fr /" или чтото типа этого?
Да. Если надеяться только на тестирование, то система работать не будет.
C>>Отказ кода может привести к краху, да. Как и в любой системе. S>Нет. постгрес, мускуль, раббит, бинд, дхцпц и так далее умудряются писать как то так, что их крах не приводит к краху системы. А вы умудряетесь.
О! Bind — классный пример. Я как-то вынужден был ночью съездить в дата-центр, чтобы вручную перезагрузить сервер. Из-за того, что Bind при shutdown'е зациклился (из-за ошибки в коде DNSSEC и init.d-скрипте). А отключается bind после ssh. В RabbitMQ я тоже сам находил и патчил ошибки (с пропадающими сообщениями).
Так что нет, НИКТО не может писать надёжный софт. Совсем.
C>>Докер позволяет код структурировать, так что в случае отказа система ведёт себя предсказуемо и гарантированна возможность отката. S>С ансиблом такое тоже возможно.
Нет, как я уже показал.
S>Только вот на самом деле надо писать код так, чтобы он работал. Тогда и не придётся тратить время на танцы с обеспечением тепличных условий.
Я уже показал, что никакой Ansible код не может быть надёжным.
C>>>>Основная мысль — человеческих ошибок (почти) не бывает. Если система допускает возможность катастрофических "человеческих ошибок" — это проблема системы, а не человеков. S>>>Хорошая теория, только не согласуется с практикой, где автоматика работает так как надо, а ошибки в основном из за действий людей. C>>Мда. Выделил. S>Да хоть три раза выдели — эта теория всё равно не начнёт согласовываться с практикой.
Мда. Книжку скачай и прочитай.
Здравствуйте, Sheridan, Вы писали:
S>>>chroot это не про надёжность, а про изоляцию. Хоть 20 раз заchroot'ь бажный софт — работать он от этого не начнёт. C>>Он так же не станет безбажным, если повторять: "анзибльанзибльанзибльанзибльанзибльанзибль". Только в моём случае баги будут предсказуемы, а в случае "анзибльанзибльанзибльанзибльанзибльанзибль" — они будут ломать всё. S>Нет, не будут они более предсказуемы. Хоть трижды возненавидь ансибл и возлюби докер.
Ты уже сам привёл пример скрипта, который даст непредсказуемую ошибку.
C>>Нет, забудешь. И напишешь "rm -Rf /", а потом уйдёшь дальше в другие компании ломать. S>Подобные ошибки (да и любые другие) отлавливаются на тестах, в приемлемом для бизнеса количестве. Возникающие впоследствии у клиентов баги чинятся уже хотфиксами. И так далее.
Нет, такие ошибки не отлавливаются тестами.
Здравствуйте, Sheridan, Вы писали:
C>>Так же это возможно, если certbot рухнул в промежутке между созданием файла и записью туда. Тогда у нас будет просто пустой файл. S>Надо другую проверку? Будет другая. Очевидно что автору этого достаточно. Потому что проще->понятнее->легче поддерживать.
Нет, не будет. Так как админ Sheridan просто берёт первые попавшиеся playbook'и и фигачит в production. То что там в одном из кусочков есть такая мина — админ Sheridan даже не узнает, до тех пор, пока мина не взорвётся.
S>Но ты конечно же будешь продолжать утверждать что ансибл говно.
Да, это именно так.
Здравствуйте, Sheridan, Вы писали:
АБ>>>> — получить горизонтальное скалирование, АБ>>>> — до кучи ещё балансировку нагрузки, S>Зависит от приложения. В общем виде — нужно приложению дать такие настройки чтобы оно поняло что оно работает в кластере и нашло соседние ноды. S>Ну или, если подходит, пользовать pacemaker/corosync, haproxy. АБ>>>> — виртуальную сеть, чтобы сервисы видели только те сервисы, которые должны видеть, S>Множество путей. От iputils с подниманием нужных адресов на сетевухах и описанием маршрутов до поднятия туннелей. S>Ну а вообще правило странное. Если сервису не нужно видеть другой сервис — ну так не пишите код, который обнаруживает другой сервис АБ>>>> — мониторинг на примитивном уровне, S>Насколько примитивном? systemctl status подойдёт? АБ>>>> — прозрачное логирование в любом формате без этих ваших logrotate, а с использование православного ELK-стека, S>Разворачиваем ёлку, на хостах filebeat. В чом проблема? АБ>>>> — healthcheck S>Слишком расплывчато. Насколько глубоко надо? Если просто "процесс жив", то ниже написал, системд умеет. Если сложные проверки типа "на тапрос такойто сервис должен вернуть ответ такойто", то без ватчдога не обойтись и нужно писать этот самый отдельний ватчдог-сервис. АБ>>>>и перезапуск, если кто-то в лесу умер. S>Restart=on-failure в юнит-файле сервиса. S>>>Почему ты уверен, что этого нельзя сделать с systemd с деплоем на ансибле? F>>Так а ты распиши нам по пунктикам. Может мы прозреем, темнота мы такая. Про скалирование в горизонт и балансировку очень интересно. Учти, что кубер + докер умеют это из коробки.
В соседнем сообщении комрад все расписал. Я только еще зачему, что надо еще и ELK разворачивать куда-то.
В общем и целом это выглядит куда как сложнее, чем это можно было бы провернуть с докером и кубером.
S>Докеры этого не умеют, их надо учить. Расскажи мне про скалирование в горизонт постгреса об "в докере изкаробки", например.
Я написал докер + кубер. Ну или сварм на худой конец.
S>Я понимаю, что софт ваш кроме тепличных условий нигде работать не может. Ты не понимаешь что подход "у меня всё работает" никуда не годится.
Докер как раз и снимает этот вопрос.
S>Ранее мне писали что ансибл это просто баш. Следует понимать что вы прогнулись?
Я нет, мне фиолетово что ансибл — запускалка, а докер — чрут. Инструмент помогает решать задачи и не делает мозг (за редким исключением).
S>Это ты не догоняешь что работать надо в команде и слушать что тебе говорят другие специалисты, а не "у меня всё работает!"
Это мне рассказывает человек, никогда не работавший в команде на разработке. Еще раз для сферического админа в вакууме — докер как раз позволяет решить эту проблему.
S>Множество путей. От iputils с подниманием нужных адресов на сетевухах и описанием маршрутов до поднятия туннелей. S>Ну а вообще правило странное. Если сервису не нужно видеть другой сервис — ну так не пишите код, который обнаруживает другой сервис
Tckb допустить, что Шеридан может как в Кубернетес, то получим тот же network plugin
1. Осталось доказать, что он это сможет.
2. найти дурака, который это действо будет спонсировать
S>Насколько примитивном? systemctl status подойдёт?
Нет
АБ>>>> — healthcheck S>Слишком расплывчато. Насколько глубоко надо? Если просто "процесс жив", то ниже написал, системд умеет. Если сложные проверки типа "на тапрос такойто сервис должен вернуть ответ такойто", то без ватчдога не обойтись и нужно писать этот самый отдельний ватчдог-сервис.
И фреймворк для запуска этого сервиса, документацию, стандарт. Вместо того что есть, да это хромой лошади дать. Зачем? Работают целые коллективы над такими системами, а тут некий Шеридан это на коленке слабает.
S>Докеры этого не умеют, их надо учить. Расскажи мне про скалирование в горизонт постгреса об "в докере изкаробки", например.
Persistent state сервисы "из коробки" скалирование в горизонт "изкаробки" не умеют нигде, ни в ансибл, ни в докер ни в кубернетес. Даже сам вопрос показывает неграмотность.
Всегда нужно что-то еще, что поддерживает data mapping для data partitioning/sharding.
Это уже ваши личные споры и проблемы.
Тогда как суть моего утверждения очень проста: если можно избежать лишнего слоя абстракции, его *нужно* избежать, иначе последующие поиски бага и разборки "ну как же так, нас же докер должен был изолировать" затянуться еще на неделю, а то и больше.
Видишь ли, в моей практике хватает случаев, когда через ....дцать уровней абстракции я обнаруживал root cause в железке (материнке, и BIOS, их комбинации, когда level-triggered прерывание обрабатывалось как edge-triggered, а приводило это к внезапному увеличению latency для определенных типов запросов — через примерно десяток разных виртуальых машин, начиная от kernel, и заканчивая home-brew наворотами поверх еще нескольких виртуальных машин, среди которых, однако, был и аналог docker'а, только с чуть иным названием).
V_>Это, прежде чем развивать тезис, хотелось бы доказательство реальности проблемы. Тем паче, что проблема так детально описана, с привязкой к докеру, его версии и т.п.
Реальность проблемы такова: разработчик, который привык к "тепличным условиям", целиком и полностью зависит от тех, кто оные условия создает. Шаг влево, шаг вправо, и этот "тепличный разработчик" из себя представляет вредителя, на которого должна работать еще целая команда. Вот такой бизнес, увы.
C>О! Bind — классный пример. Я как-то вынужден был ночью съездить в дата-центр, чтобы вручную перезагрузить сервер. Из-за того, что Bind при shutdown'е зациклился (из-за ошибки в коде DNSSEC и init.d-скрипте). А отключается bind после ssh.
Это пример катастрофического головотяпства. Даже в моей совершенно нелепой практике подобных дел про KVM over IP я прочитал _перед_ тем, как что-то ставить в датацентр в Мельбурне (откуда из Сиднея лететь пусть и недолго, но все же).
Здравствуйте, Anton Batenev, Вы писали:
AB>Для разработки ресурсоемкость решения не особо принципиальна будь то docker, virtual box, kvm, chroot (и все остальное, что могут использовать для изоляции). Для прода, где нужна стабильность и прочие аттрибуты "зрелости" (а не хипстерское "упало, да и фиг с ним — облако новых нарожает") докер непригоден (но не из за оверхеда конечно же).
А из-за чего непригоден? Что там не так со стабильностью?
Здравствуйте, Sheridan, Вы писали:
G>>Установка сложного приложения без докера выглядит так: ... G>>Установка с докером — передать образ и запустить пару команд в командной строке. Всю работу по конфигурации берет на себя разработчик. S>ansible-playbook playbook-deploy.yaml и оно может даже само выкачать всё нужное.
Представим что мы деплоим то самое приложение на nodejs, нам нужен npm, нам нужны пакеты из разных deb репозиториев чтобы установить монгу и прочую хурму, также нам нужны наши пакеты, которые берутся из нашей инфраструктуры, получается что твой деплой зависит от кучи разных endpoint-ов, часть которых ты не контроллируешь. Захочет npm попятисотить немного и часть твоего приложения не развернется. Получается, что нужно держать свой npm, свой deb репозиторий и тд. Вместо всего этого можно было бы поддерживать artifactory в котором бы лежали все твои docker images. Тупо дешевле и проще.
Еще один момент — cloud nativeness. Деплой ansible плейбуком это хорошо, но не cloud native. Мы сейчас хотим чтобы все было завязано на CI. Мы хотим непрерывный деплой и относительную независимость от клауд провайдера. Это достижимо только за счет автоматизации и непрерывной интеграции. Ты же не будешь каждый раз расчехлять свой плейбук, когда появится CVE с описанием уязвимости в какой-нибудь библиотеке, от которой зависит твое приложение. А CI проследит в том числе за CVE зависимостей и перестроит образы, в том числе.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Sheridan, Вы писали:
C>>>Так же это возможно, если certbot рухнул в промежутке между созданием файла и записью туда. Тогда у нас будет просто пустой файл. S>>Надо другую проверку? Будет другая. Очевидно что автору этого достаточно. Потому что проще->понятнее->легче поддерживать. C>Нет, не будет. Так как админ Sheridan просто берёт первые попавшиеся playbook'и и фигачит в production. То что там в одном из кусочков есть такая мина — админ Sheridan даже не узнает, до тех пор, пока мина не взорвётся.
причем даже если он протестирует это на своем pre-production, то все может вполне нормально отработать, но долбануть потом на проде
Здравствуйте, Андрей Бабошин, Вы писали:
S>>Ну или, если подходит, пользовать pacemaker/corosync, haproxy. АБ>Т.е. вместо того, чтобы сказать "replicas: xxx", мне надо: АБ> — запустить эти xxx процессов, АБ> — каждому подсунуть свою конфигурацию из-за портов, если на одной машине АБ> — настроить haproxy АБ> — как-то их разбросать по разным серверам.
Ну да, ну да. Внутри replicas живёт магия, которая сделает ваши процессы скалабельными. Ну или ваши процессы очень легко скалятся и поэтому трудностей никаких не будет и без докеров.
АБ>>>>> — виртуальную сеть, чтобы сервисы видели только те сервисы, которые должны видеть, S>>Множество путей. От iputils с подниманием нужных адресов на сетевухах и описанием маршрутов до поднятия туннелей. S>>Ну а вообще правило странное. Если сервису не нужно видеть другой сервис — ну так не пишите код, который обнаруживает другой сервис АБ>Т.е. предлагается ещё и самому управлять vlan'ами.
Обязательно вланами? Вообще, для чего это? Если приложение работает без хитрых прижков по сетям, то зачем тогда они? Стоит ли в этот огород тащить ещо одну шестеренку, которая перестанет крутиться? Может достаточно просто огнестену нормально настроить?
АБ>>>>> — healthcheck S>>Слишком расплывчато. Насколько глубоко надо? Если просто "процесс жив", то ниже написал, системд умеет. Если сложные проверки типа "на тапрос такойто сервис должен вернуть ответ такойто", то без ватчдога не обойтись и нужно писать этот самый отдельний ватчдог-сервис. АБ>Вот, писать отдельный ватчдог-сервис. АБ>В случае же с предметом обсуждения добавление healthcheck'а выливается в добавлении пары конфигруационных параметров.
И внутри этих конфигурационных параметров тоже магия, которая сама знает когда считать процесс нежитью?
АБ>>>Я как разработчик буду обновлять библиотеку только в том случае, если размер плюсов гарантированно перевесит размер головняка. S>>А когда головняк относится к деплою, то "это не моя проблема, у меня всё работает!", я правильно понял? АБ>Вот с этого момента подробнее, пожалуйста. АБ>Команда разработчиков выбрала версию X некой библиотеки.
Плохой шаг, негодный. Команда разработчиков при первом принятии либы в проект должна взять последний релиз этой либы. И впоследствии эта команда должна планировать при каждом релизе своего проекта проверять — а не обновились ли используемые библиотеки (это может делать и девапс)? И планировать переход на новые версии если да (это делают программисты).
АБ>В какой-то момент приходит девопс и говорит, что надо обновится до версии X + 1.
Да. Если программисты забыли.
АБ>В данном случае это проблема девопса обосновать необходимость обновления и согласовать дополнительные сроки.
Проблема девопса — добавить баг или таск с его обоснованием. А сроки — это дело программистов (им же программировать), равно как и обоснование этих сроков.
АБ>Понятно, что в чудесном мире с розовыми понями обновление библиотеки должно пройти безболезненно и, может даже, с некоторым удовольствием, АБ>только на практике окажется, что с большой долей вероятности обновление потянет за собой какие-то исправления.
Мне тут постоянно уши жужжат что я в команде не работал. Видимо эти люди сами не работали в командах, ибо там где я работал — дела обстояли +- как я описал сейчас.
И к тому же девапс отчегото воспринимается как лишнее колесо. Ну теперь я понимаю почему — он указывает как правило на проблемы проекта, которые а) "у нас и так работает" и б) лень этим заниматься. И всё это под соусом "бизнесу нинада".
Бизнесу нада. Надо годный код, который будет работать без лишних подпопрок.
АБ>>>>>+ разработку можно вести на чём угодно. S>>>>А ансибл как то мешает этому? F>>>Опять потерялся. Тут поинт про единое окружение при разработке, тестировании и эксплуатации. S>>Я понимаю, что софт ваш кроме тепличных условий нигде работать не может. Ты не понимаешь что подход "у меня всё работает" никуда не годится. АБ>Софт работает у разработчика, софт работает на тестовом стенде, а на проде "вдруг" перестаёт работать, потому что версии библиотек не те.
ВНЕЗАПНО это как раз проблема программистов, которые вовремя не перешли на свежую версию либы.
АБ>>>По отдельности — вполне себе допускаю. А в команде, да ещё и с заказчиками, которые внятные требования родить не могут... S>>Ну ты сам понимаешь что сдавать софт работающий исключительно в песочнице — такое себе решение. АБ>Песочница выражатеся в том, что даёт гарантированное окружение.
Любой дистрибутив даёт гарантированное окружение.
АБ>Касаемо про "без багов": всего навсего вопросов выделенных временных и денежных ресурсов. АБ>Если заказчик готов ждать новую версию не две недели, а два месяца (с тем же набором фич), и готов за это платить, то багов будет меньше. АБ>Если готов ждать два года, то багов не будет. или почти не будет.
Верно. Почему вы тогда придерживаетесь поведения "поэтому совсем не будем за этим следить"?
АБ>П.С. Я выделил жирным про единое окружение. АБ>С докером софту абсолютно неважно, где запускаться: на машине ли разрабочика, на внутреннем ли тестовом стенде, в кластере у заказчика или в том же амазоне.
Это и плохо. Складывается ощущение, что всё хорошо, хотя на самом деле у проекта куча подпорок и без них он не работает никак.
АБ>Разработчик может жёстко прописать версии библиотек, с которыми всё точно работает, а не надеятся, что на целевом сервере будет нужная версия. Или не будет, потому что кто-то её обновил.
Плохой, разработчик. На нужную версию можно надеяться только когда эта версия свежая. На говоно мамонта надеяться нельзя.
АБ>Т.е. стандартизация и унификация, без необходимости настраивать окружение.
Если соблюдать простые правила то ничего настраивать не надо и в любом случае это проблема девапса и он её решать умеет.
АБ>Плюс большое количество вещей уже из коробки, без необходимости погружаться в детали: т.е. низкий порог входа.
Ничего себе низкий — изучить докеры с кубернетисами.
АБ>Я не говорю, что ansible+systemd далее по списку — это плохо и тьфу-тьфу, но порог входа, последствия ошибок как-то сильно не в его пользу.
Я так понимаю что основной камень преткновения это сторонние либы? Ну тогда я всё описал что с этим делать надо.
Здравствуйте, mogadanez, Вы писали:
S>>А то создание образов и их поддержка не увеличивает стоимость. M>сложность имеджа при прочих равных будет ниже
Нет. Она сопоставима с сложностью ансибла потому что нужно будет провернуть +- те же самые вещи. Магии не бывает.
S>>А там ещо окажется что и за хранение образов надо платить сферическому докерхабу. M>репозиторий можно иметь свой. вот ты говоришь что пользовался докером — но по тому что ты про него пишешь — не похоже
Можно и свой — я против что ли? У вас свой?
Здравствуйте, mogadanez, Вы писали:
M>вообще тебе все говорят что ансибл имеет право на жизнь в каких то сценариях, но докер для нас проще и надежне и мы выбираем его M>твоя же позиция совсем ортодоксальна
Не замечаю чегото. В основном говорят что я ничего не понимаю, потому что бизнес а докер, а ансибл, и вообще дурак.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Sheridan, Вы писали:
C>>>Ну вот у меня код с кучей вычислительных библиотек. Как мне сделать его deployment на production? Компилироваться из исходников он будет около часа. S>>Опакетить при сборке проекта, устанавливать пакет при деплое. Ну, первое что в голову пришло. C>Т.е. нужен специальный репозиторий для хранения пакетов, в котором будут лежать несколько версий (для откатов). Так как версий может быть несколько, то нужно уметь ставить определённую из них. Так что нужен какой-то софт, которой будет этим управлять.
Версий не несколько, а одна. Ставить не определённую, а свежую.
Такой сценарий настолько редок, что встречается один-два раза в жизни.
При правильном подходе к проектированию, программированию и планированию вам не придётся мнодить версии либ.
C>Затем ещё несколько итеративных шагов — и получается Docker.
Если для вас докер это инструмент для впулливания говна мамонта к проекту, то да.
S>>>>Достаточно не выдавать нетестированный код в прод. C>>>Тестирование никогда не находит всех ошибок. Пора бы знать уже. S>>Это должно как то противоречить моим словам или что? И почему у тебя "все ошибки" это именно "rm -fr /" или чтото типа этого? C>Да. Если надеяться только на тестирование, то система работать не будет.
А, у вас еще и тестирование никуда не годится? У вас то хоть тестер отдельный есть, ну хоть один? Или когото из программистов от работы отрываете?
C>>>Отказ кода может привести к краху, да. Как и в любой системе. S>>Нет. постгрес, мускуль, раббит, бинд, дхцпц и так далее умудряются писать как то так, что их крах не приводит к краху системы. А вы умудряетесь. C>О! Bind — классный пример. Я как-то вынужден был ночью съездить в дата-центр, чтобы вручную перезагрузить сервер. Из-за того, что Bind при shutdown'е зациклился (из-за ошибки в коде DNSSEC и init.d-скрипте). А отключается bind после ssh. В RabbitMQ я тоже сам находил и патчил ошибки (с пропадающими сообщениями).
Аааа, так у вас денег нет даже на нормальное железо с ilo/ipmi/etc...? И вы прямо на голом железе софт разворачиваете?
Мда. Это последствия отсутствия админа в команде. Ну и конечно докер магическим образом правит ошибки всего софта, который внутри. Сообщения перестают пропадать, да.
C>Так что нет, НИКТО не может писать надёжный софт. Совсем.
И поэтому надо сложить лапки и писать вилами по воде?
C>>>Докер позволяет код структурировать, так что в случае отказа система ведёт себя предсказуемо и гарантированна возможность отката. S>>С ансиблом такое тоже возможно. C>Нет, как я уже показал.
Ничего ты не показал.
S>>Только вот на самом деле надо писать код так, чтобы он работал. Тогда и не придётся тратить время на танцы с обеспечением тепличных условий. C>Я уже показал, что никакой Ansible код не может быть надёжным.
Я не удивлюсь что с вашим подходом к софтописанию и докер перестанет быть надёжным. Я уже почти готов поставить штутку баксов что у вас уже местами с докером возникают сложности и они пока решаются разделением бажного контейнера на два разных контейнера с выносом бажного функционала в более тепличные условия.
Здравствуйте, Cyberax, Вы писали:
S>>>>chroot это не про надёжность, а про изоляцию. Хоть 20 раз заchroot'ь бажный софт — работать он от этого не начнёт. C>>>Он так же не станет безбажным, если повторять: "анзибльанзибльанзибльанзибльанзибльанзибль". Только в моём случае баги будут предсказуемы, а в случае "анзибльанзибльанзибльанзибльанзибльанзибль" — они будут ломать всё. S>>Нет, не будут они более предсказуемы. Хоть трижды возненавидь ансибл и возлюби докер. C>Ты уже сам привёл пример скрипта, который даст непредсказуемую ошибку.
Ты когда строку на печать выводишь — проверяешь наличие \0 в конце? Нет? Не нужно? Вот так и тут. Когда будет нужно — тогда будет и более строгая проверка.
C>>>Нет, забудешь. И напишешь "rm -Rf /", а потом уйдёшь дальше в другие компании ломать. S>>Подобные ошибки (да и любые другие) отлавливаются на тестах, в приемлемом для бизнеса количестве. Возникающие впоследствии у клиентов баги чинятся уже хотфиксами. И так далее. C>Нет, такие ошибки не отлавливаются тестами.
Такие ошибки замечательно отслеживаются тестами.
Здравствуйте, Farsight, Вы писали:
F>>>Так а ты распиши нам по пунктикам. Может мы прозреем, темнота мы такая. Про скалирование в горизонт и балансировку очень интересно. Учти, что кубер + докер умеют это из коробки. F>В соседнем сообщении комрад все расписал. Я только еще зачему, что надо еще и ELK разворачивать куда-то.
я там же и ответил.
Здравствуйте, Vetal_ca, Вы писали:
S>>Множество путей. От iputils с подниманием нужных адресов на сетевухах и описанием маршрутов до поднятия туннелей. S>>Ну а вообще правило странное. Если сервису не нужно видеть другой сервис — ну так не пишите код, который обнаруживает другой сервис V_>Tckb допустить, что Шеридан может как в Кубернетес, то получим тот же network plugin
Я ему про белое, он мне про кислое...
Ещо раз перечитай что я ниписал.
S>>Насколько примитивном? systemctl status подойдёт? V_>Нет
Без ТЗ результат ХЗ. Что нужно от мониторинга?
АБ>>>>> — healthcheck S>>Слишком расплывчато. Насколько глубоко надо? Если просто "процесс жив", то ниже написал, системд умеет. Если сложные проверки типа "на тапрос такойто сервис должен вернуть ответ такойто", то без ватчдога не обойтись и нужно писать этот самый отдельний ватчдог-сервис. V_>И фреймворк для запуска этого сервиса, документацию, стандарт. Вместо того что есть, да это хромой лошади дать. Зачем? Работают целые коллективы над такими системами, а тут некий Шеридан это на коленке слабает.
Нет конечно.
S>>Докеры этого не умеют, их надо учить. Расскажи мне про скалирование в горизонт постгреса об "в докере изкаробки", например. V_>Persistent state сервисы "из коробки" скалирование в горизонт "изкаробки" не умеют нигде, ни в ансибл, ни в докер ни в кубернетес. Даже сам вопрос показывает неграмотность.
Это не ко мне отповедь, а к автору этого вопроса
Здравствуйте, chaotic-kotik, Вы писали:
CK>Представим что мы деплоим то самое приложение на nodejs, нам нужен npm, нам нужны пакеты из разных deb репозиториев чтобы установить монгу и прочую хурму, также нам нужны наши пакеты, которые берутся из нашей инфраструктуры, получается что твой деплой зависит от кучи разных endpoint-ов, часть которых ты не контроллируешь. Захочет npm попятисотить немного и часть твоего приложения не развернется. Получается, что нужно держать свой npm, свой deb репозиторий и тд. Вместо всего этого можно было бы поддерживать artifactory в котором бы лежали все твои docker images. Тупо дешевле и проще.
CK>Еще один момент — cloud nativeness. Деплой ansible плейбуком это хорошо, но не cloud native. Мы сейчас хотим чтобы все было завязано на CI. Мы хотим непрерывный деплой и относительную независимость от клауд провайдера. Это достижимо только за счет автоматизации и непрерывной интеграции. Ты же не будешь каждый раз расчехлять свой плейбук, когда появится CVE с описанием уязвимости в какой-нибудь библиотеке, от которой зависит твое приложение. А CI проследит в том числе за CVE зависимостей и перестроит образы, в том числе.
Я из этого текста понял только что вы не доверяете своему девапсу, но доверяете совершенно неизвестному человеку.
Здравствуйте, SkyDance, Вы писали:
S>> За всем миром все баги не вылечишь. Сначала со своими разберитесть, чтобы софт хотя бы заработал без тепличных условий. SD>Тебе про это и пишут. Мир не научишь быть умнее — увы, он тупой. Поэтому и нужны докеры, чтобы изолировать от тупого мира.
Я топлю за то, чтобы не делать этот мир ещё тупее, чему, увы, докеры только способствуют.
Здравствуйте, mogadanez, Вы писали:
M>часто проблемы с версиям бывают из-за third-party библиотек/софта котырые не обновлялись хрен знает сколько или апргрейд стоит кучу денег которые бизнес сейчас не хочет тратить.
И не захочет, пока не узнает о проблеме.
Здравствуйте, chaotic-kotik, Вы писали:
c> А из-за чего непригоден? Что там не так со стабильностью?
Под нагрузкой теряет логи, может зависнуть так, что снять post-mortem не представляется возможным, проблемы с изоляцией (когда есть возможность "прогуляться" из одного контейнера в другой), проблемы с IPv6 (у нас это критикал, перечеркивающий любые другие достоинства).
Здравствуйте, Sheridan, Вы писали:
S> Команда разработчиков при первом принятии либы в проект должна взять последний релиз этой либы.
Не должна. "Классический" пример — OpenSSL. Помимо этого могут быть еще причины — например, версия библиотеки зафиксирована в корпоративном репозитори и т.д.
S> И впоследствии эта команда должна планировать при каждом релизе своего проекта проверять — а не обновились ли используемые библиотеки (это может делать и девапс)? И планировать переход на новые версии если да (это делают программисты).
Не должна, если плюсы новой версии при детальном рассмотрении не перевешивают минусы старой. Ибо новая версия — это не только новые фитчи, но еще и новые баги.
S> Мне тут постоянно уши жужжат что я в команде не работал.
Тебе намекают на то, что твой опыт отстает лет на 10+ от современных реалий разработки и эксплуатации. Но больше всего намекающих расстраивает тот факт, что ты не хочешь учиться.
SD>Это уже ваши личные споры и проблемы. SD>Тогда как суть моего утверждения очень проста: если можно избежать лишнего слоя абстракции, его *нужно* избежать, иначе последующие поиски бага и разборки "ну как же так, нас же докер должен был изолировать" затянуться еще на неделю, а то и больше.
SD>Видишь ли, в моей практике хватает случаев, когда через ....дцать уровней абстракции я обнаруживал root cause в железке (материнке, и BIOS, их комбинации, когда level-triggered прерывание обрабатывалось как edge-triggered, а приводило это к внезапному увеличению latency для определенных типов запросов — через примерно десяток разных виртуальых машин, начиная от kernel, и заканчивая home-brew наворотами поверх еще нескольких виртуальных машин, среди которых, однако, был и аналог docker'а, только с чуть иным названием).
Я к тому, что существование самой проблемы нуждается в доказательстве. Лишняя сущность плохо. Но есть ли здесь лишние сущности, как задача поставлена? Да, черный XYZ — плохо, но наличие черного XYZ нужно доказать. А так, сама ОС — +1 сущность. Избавимся от ОС?
К слову, лишние сущности в примере начинаются не внутри докера. А снаружи. Например, организовать хранение данных Docker/Kubernetes/.... way. Высокоуровневая структуризация
Вместо того, чтобы писать прямо в /var/someproduct/data приходится прикручивать некие явно описанные сущности (docker volume, PV/PVC, ...) На этих направлениях выявляется дополнительные телодвижения.
Внутри докер, наоборот, помогает выявлять всякие неправильности. Привилегированный доступ, когда не надо. Мусор всякий (docker diff, например, пока над Docker image работаешь). Помогает раскрывать "тайные кладбища" создателя докеризируемого компонента.
Или, просто, вещи, на которые стоило бы обратить внимание
Например, когда-то, когда только начинал, первый сюрприз был, Tomcat очень долго стартовал. Причина описана здесь: SO, Random Entropy. Проблема выявлена в чистом виде, ее можно изучить детально, под микроскопом. И сделать адекватное решение на оснований требований и security risks
Здравствуйте, Anton Batenev, Вы писали:
S>> Команда разработчиков при первом принятии либы в проект должна взять последний релиз этой либы. AB>Не должна. "Классический" пример — OpenSSL.
Это у вас там это классика. У меня нет такого.
AB>Помимо этого могут быть еще причины — например, версия библиотеки зафиксирована в корпоративном репозитори и т.д.
Раз репозиторий ваш, то значит "зафиксировано" читается как "нам лень исправлять".
S>> И впоследствии эта команда должна планировать при каждом релизе своего проекта проверять — а не обновились ли используемые библиотеки (это может делать и девапс)? И планировать переход на новые версии если да (это делают программисты). AB>Не должна, если плюсы новой версии при детальном рассмотрении не перевешивают минусы старой. Ибо новая версия — это не только новые фитчи, но еще и новые баги.
Ну то есть несмотря на утверждения "мы работаем в команде!" — вы плевать хотели на работу админа/девапса.
S>> Мне тут постоянно уши жужжат что я в команде не работал. AB>Тебе намекают на то, что твой опыт отстает лет на 10+ от современных реалий разработки и эксплуатации. Но больше всего намекающих расстраивает тот факт, что ты не хочешь учиться.
Я не гоняюсь за топчик-технологиями, да. Я следую требованиям, как вы говорите?... А, бизнеса, вот.
S>>>Докеры этого не умеют, их надо учить. Расскажи мне про скалирование в горизонт постгреса об "в докере изкаробки", например. V_>>Persistent state сервисы "из коробки" скалирование в горизонт "изкаробки" не умеют нигде, ни в ансибл, ни в докер ни в кубернетес. Даже сам вопрос показывает неграмотность. S>Это не ко мне отповедь, а к автору этого вопроса
. Между собой определитесь, а потом уже и ко мне приходите.
Добавление (Шериданом) "postgres" в вопрос о скалировании неправильный. Потому что ни один продукт не заставит скалироваться горизонтально persistent state сервис, если нужен data partition.
В докере (без Swarm) нет скалирования (scaling + LB), но TC, наверняка, имел в виду Swarm. Про Swarm не скажу, я в нем не компетентен.
V_>>Всегда нужно что-то еще, что поддерживает data mapping для data partitioning/sharding. S>ceph?
Из коробки — нет, сама БД должна поддерживать partitioning/sharding.
В том же кубернетес из коробки идут Stateful sets с strong identity и привязкой к конкретному data mount. Но сам маппинг/sharding/partitioning должен поддерживаться БД. Или приложением, вручную, если cross-shard запросы могут собираться на клиенте. Но все это не "изкоробки"
Здравствуйте, SkyDance, Вы писали:
V_>>Это, прежде чем развивать тезис, хотелось бы доказательство реальности проблемы. Тем паче, что проблема так детально описана, с привязкой к докеру, его версии и т.п.
SD>Реальность проблемы такова: разработчик, который привык к "тепличным условиям", целиком и полностью зависит от тех, кто оные условия создает. Шаг влево, шаг вправо, и этот "тепличный разработчик" из себя представляет вредителя, на которого должна работать еще целая команда. Вот такой бизнес, увы.
Должен, не должен. Это все абстрактные измышления.
На практике постановка задачи несколько другая.
Например, FreeSwitch, для личных нужд. Раньше "крутился" на хосте. "sudo apt install ...", теперь в Кубернетес.
Проблемы с обновлением, хотя бы даже с тем, что переустановить его раз в 3 года при обновлении distro — надо заново пересобирать.
Собирается он через пень колоду, куча всего стороннего. Под себя сделал такой минималистичный Dockerfile, собирается из исходников.
Должен мне этот FreeSwitch (Signalwire) — нет. Идеальный? Нет.
По факту, собрано из исходников. Image, конфигурация (не в этом repo) и deployment структурированы и отделены. Хост OS — отделена. Телефоны для семьи (11 линий) работают и не требуют внимания. Была насущная проблема — проблема решена.
kubectl get pods --namespace freeswitch -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
config-provider-8445f95946-g89lc 1/1 Running 2 83d 10.14.0.76 utility <none> <none>
config-provider-8445f95946-5rq4c 1/1 Running 2 83d 10.14.0.82 utility <none> <none>
fs-64dd9c75df-4v8sw 1/1 Running 2 83d xx.xx.xx.xx utility <none> <none>
Сущностей больше, но структуризация — лучше. Никаких проблем FS работать из контейнера не имеет.
Если надо, влегкую могут быть перенесены на другой VPS
S>>> И впоследствии эта команда должна планировать при каждом релизе своего проекта проверять — а не обновились ли используемые библиотеки (это может делать и девапс)? И планировать переход на новые версии если да (это делают программисты). AB>>Не должна, если плюсы новой версии при детальном рассмотрении не перевешивают минусы старой. Ибо новая версия — это не только новые фитчи, но еще и новые баги. S>Ну то есть несмотря на утверждения "мы работаем в команде!" — вы плевать хотели на работу админа/девапса.
Прийти и сказать, что, утрированно, завтра мы переходим на новую версию либы — это само по себе ортогонально работе в команде.
Если уж мы говорим про работу в команде, то:
— девопс или кто-то ещё приходит и говорит, что есть новая либа, переход на которую нам даст такие-то плюсы,
— после чего команда совещается, решает интересны ли ей эти плюсы,
— если да, то выделяет время на исследование оценки сложности перехода на новую версию,
— после чего ещё раз собирается и принимает решение о необходимости перехода на новую версию.
Подпунктами ещё идут вопросы о выделении времени и бюджета, как на оценку стоимости перехода, так и на сам переход.
П.С. "Я тебе один умный вещь скажу, только ты не обижайся".
Сисадмины — это международное. Один такой немецкий товарищ обновил сегодня без согласования с кем-либо одну из инфраструктурных компонент.
Хотя ему неоднократно было сказано, что:
— нам надо время, чтобы проверить стоимость перехода,
— у нас в бюджете время на это не предусмотрено,
— если ему это очень-очень важно, то пусть идёт и выбивает бюджет.
В результате один рабочий день нескольких человек был потрачен на срочный переход.
Как-то имел я ввиду такую работу в команде.
Здравствуйте, Sheridan, Вы писали:
C>>Т.е. нужен специальный репозиторий для хранения пакетов, в котором будут лежать несколько версий (для откатов). Так как версий может быть несколько, то нужно уметь ставить определённую из них. Так что нужен какой-то софт, которой будет этим управлять. S>Версий не несколько, а одна. Ставить не определённую, а свежую.
Нет. Так делать нельзя, так как необходимость делать откат — это даже не обсуждается.
S>Такой сценарий настолько редок, что встречается один-два раза в жизни. S>При правильном подходе к проектированию, программированию и планированию вам не придётся мнодить версии либ.
C>>Затем ещё несколько итеративных шагов — и получается Docker. S>Если для вас докер это инструмент для впулливания говна мамонта к проекту, то да.
У нас говно мамонта — в чётко ограниченных загонах в зоопарке. А вот вы в нём плаваете.
C>>Да. Если надеяться только на тестирование, то система работать не будет. S>А, у вас еще и тестирование никуда не годится? У вас то хоть тестер отдельный есть, ну хоть один? Или когото из программистов от работы отрываете?
Нет, это практика. Ни одно тестирование не находит всех ошибок.
Так, а я пока жду от админа Sheridan'а плана тестировани того Ansible-скрипта, который он привёл. Интересно, как же у вас находят ошибки?
C>>О! Bind — классный пример. Я как-то вынужден был ночью съездить в дата-центр, чтобы вручную перезагрузить сервер. Из-за того, что Bind при shutdown'е зациклился (из-за ошибки в коде DNSSEC и init.d-скрипте). А отключается bind после ssh. В RabbitMQ я тоже сам находил и патчил ошибки (с пропадающими сообщениями). S>Аааа, так у вас денег нет даже на нормальное железо с ilo/ipmi/etc...? И вы прямо на голом железе софт разворачиваете?
Это было в 2008-м году, тогда IPMI не был ещё так распространён.
Но вот такой вот софт "без ошибок", да.
S>Мда. Это последствия отсутствия админа в команде. Ну и конечно докер магическим образом правит ошибки всего софта, который внутри. Сообщения перестают пропадать, да.
В случае с Докером, кстати, такой проблемы не было бы. Он бы гарантированно убил Bind, и в мониторилке это было бы отмечено.
C>>Так что нет, НИКТО не может писать надёжный софт. Совсем. S>И поэтому надо сложить лапки и писать вилами по воде?
C>>Нет, как я уже показал. S>Ничего ты не показал.
В твоём скрипте — дыра.
C>>Я уже показал, что никакой Ansible код не может быть надёжным. S>Я не удивлюсь что с вашим подходом к софтописанию и докер перестанет быть надёжным.
Докер — тоже ненадёжный, но там основные сценарии тестируются миллионами человек, так что на практике оно работает.
S>Я уже почти готов поставить штутку баксов что у вас уже местами с докером возникают сложности и они пока решаются разделением бажного контейнера на два разных контейнера с выносом бажного функционала в более тепличные условия.
Мимо.
Здравствуйте, Sheridan, Вы писали:
C>>Ты уже сам привёл пример скрипта, который даст непредсказуемую ошибку. S>Ты когда строку на печать выводишь — проверяешь наличие \0 в конце? Нет? Не нужно? Вот так и тут. Когда будет нужно — тогда будет и более строгая проверка.
Что значит "когда нужно"? Этот скрипт прямо сейчас имеет ошибку, которая будет проявляться в редких ситуациях. Причём вполне возможно, что катастрофически.
Так что да, прямо сейчас нужно её править.
S>>>Подобные ошибки (да и любые другие) отлавливаются на тестах, в приемлемом для бизнеса количестве. Возникающие впоследствии у клиентов баги чинятся уже хотфиксами. И так далее. C>>Нет, такие ошибки не отлавливаются тестами. S>Такие ошибки замечательно отслеживаются тестами.
ОК. Жду тестового плана, который помог бы найти указанную мной ошибку (certbot падает между созданием файла и записью в него).
АБ> — девопс или кто-то ещё приходит и говорит, что есть новая либа
У меня вообще возникает вопрос: а какого хрена девопс приходит и говорит про какие-то версии либ? Версии либ выбирают разработчики, а никак не девопсы.
Здравствуйте, Anton Batenev, Вы писали:
AB>Здравствуйте, chaotic-kotik, Вы писали:
c>> А из-за чего непригоден? Что там не так со стабильностью?
AB>Под нагрузкой теряет логи, может зависнуть так, что снять post-mortem не представляется возможным,
Может, содержимое контейнера съедало все ресурсы? Добавить лимиты (CPU/RAM)
AB> проблемы с изоляцией (когда есть возможность "прогуляться" из одного контейнера в другой),
Interprocess или сетевые
AB> проблемы с IPv6 (у нас это критикал, перечеркивающий любые другие достоинства).
Да, сети докера сильно ограничены. Одна из важных причин перехода на Kubernetes.
А зачем нужен был IPv6 на внутренних сетях? Это вопрос а не возражение
Для нас, до IPv6 на внутренних сетях мы не доросли. А вот связанные темы типа SRv6 в списке "на изучение". Для service layering, высокоуровневой network isolation (вместо/вместе с Kubernetes Network policies). Да и просто, для развития, темы интересные
Здравствуйте, Sheridan, Вы писали:
S>Здравствуйте, mogadanez, Вы писали:
S>>>А то создание образов и их поддержка не увеличивает стоимость. M>>сложность имеджа при прочих равных будет ниже S>Нет. Она сопоставима с сложностью ансибла потому что нужно будет провернуть +- те же самые вещи. Магии не бывает.
нет. потому что в ансибле нужно думать/заниматься подчисткой, инвентори и прочей вспомогательной фигней.
да и банально больше буков в плейбуке
сложность докер имеджа сопоставима с настройкой девелоперской машины
S>>>А там ещо окажется что и за хранение образов надо платить сферическому докерхабу. M>>репозиторий можно иметь свой. вот ты говоришь что пользовался докером — но по тому что ты про него пишешь — не похоже S>Можно и свой — я против что ли?
пачиму ты такой злой? у тебя папа мама был?
S>У вас свой?
был и свой (запускается за пару минут)
сейчас ECR за $0.10 per GB-month. за 2 года счет около 20 баксов( примерно 10 имеджей )
Здравствуйте, Mamut, Вы писали:
АБ>> — девопс или кто-то ещё приходит и говорит, что есть новая либа
M>У меня вообще возникает вопрос: а какого хрена девопс приходит и говорит про какие-то версии либ? Версии либ выбирают разработчики, а никак не девопсы.
Я могу себе представить ситуацию (да что представлять, сам с таким сталкивался), когда мониторинг показал, что:
— текущая версия либы течёт,
— лочит и не отпускает ресурсы.
А в новой эти баги пофикшены.
Но:
— выявить такие вещи может не отдельно стоящий девопс, а разрабочик, который ещё функции девопса выполняет. Или девопс должен хорошо разбираться в используемой платформе.
— в любом случае без оценки трудозатрат никакого обновления либы не будет. Вполне по результатам оценки может оказаться, что дешевле запустить пару реплик сервиса и смириться с тем, что они будут время от времени умирать из-за нехватки памяти и рестартоваться.
Здравствуйте, Mamut, Вы писали:
АБ>> — девопс или кто-то ещё приходит и говорит, что есть новая либа
M>У меня вообще возникает вопрос: а какого хрена девопс приходит и говорит про какие-то версии либ? Версии либ выбирают разработчики, а никак не девопсы.
Здравствуйте, Anton Batenev, Вы писали:
c>> А из-за чего непригоден? Что там не так со стабильностью? AB>Под нагрузкой теряет логи, может зависнуть так, что снять post-mortem не представляется возможным, проблемы с изоляцией (когда есть возможность "прогуляться" из одного контейнера в другой)
А тут интересно, есть ли воспроизводимые случаи? Зависания Docker'а я встречал, но в основном из-за железа.
AB>проблемы с IPv6 (у нас это критикал, перечеркивающий любые другие достоинства).
IPv6 в Docker работает, но через пень-колоду. Мы его используем для организации приватной сети между облаками (тупо используем IPv6+Wireguard).
Здравствуйте, Vetal_ca, Вы писали:
AB>> проблемы с IPv6 (у нас это критикал, перечеркивающий любые другие достоинства). V_>Да, сети докера сильно ограничены. Одна из важных причин перехода на Kubernetes.
CNI пока что не сильно лучше.
V_>А зачем нужен был IPv6 на внутренних сетях? Это вопрос а не возражение
Для организации сети сервисов, которые могут жить в разных AWS-аккаунтах, регионах или вообще облаках. Сквозная глобальная адресация позволяет избавиться от жутиков типа VPC peering и сильно ограничить работу через публичный Интернет.
Здравствуйте, Андрей Бабошин, Вы писали:
S>>Нет. Она сопоставима с сложностью ансибла потому что нужно будет провернуть +- те же самые вещи. Магии не бывает. АБ>Если мы всё ещё про образы, то проверить надо будет только один раз, а потом этот образ задеплоить во столько мест, во сколько потребуется.
Предварительно объяснив заказчику какое окружение нужно докеру.
АБ>В случае же с ансиблом надо будет проверять на каждом окружении. И надеятся, что никто другой плейбук не запускал или ручками ничего не поменял.
Нет, если предварительно объяснить заказчику какое окружение нужно... Ой, постойте, вы это уже сделали.
Здравствуйте, Андрей Бабошин, Вы писали:
АБ>Здравствуйте, Sheridan, Вы писали:
S>>>> И впоследствии эта команда должна планировать при каждом релизе своего проекта проверять — а не обновились ли используемые библиотеки (это может делать и девапс)? И планировать переход на новые версии если да (это делают программисты). AB>>>Не должна, если плюсы новой версии при детальном рассмотрении не перевешивают минусы старой. Ибо новая версия — это не только новые фитчи, но еще и новые баги. S>>Ну то есть несмотря на утверждения "мы работаем в команде!" — вы плевать хотели на работу админа/девапса.
АБ>Прийти и сказать, что, утрированно, завтра мы переходим на новую версию либы — это само по себе ортогонально работе в команде. АБ>Если уж мы говорим про работу в команде, то: АБ> — девопс или кто-то ещё приходит и говорит, что есть новая либа, переход на которую нам даст такие-то плюсы,
Глупость. Очень большая глупость, которая всегда больно бьёт по яйцам в будущем. Если плавно не переходить с версии на версию, то когда это действительно станет нужно — у команды не будет ни опыта, ни времени.
АБ>Подпунктами ещё идут вопросы о выделении времени и бюджета, как на оценку стоимости перехода, так и на сам переход.
П — Планирование. Слышал, не?
АБ>Один такой немецкий товарищ обновил сегодня без согласования с кем-либо одну из инфраструктурных компонент. АБ>В результате один рабочий день нескольких человек был потрачен на срочный переход.
1. Гнать ссаными тряпками таких админов. Ну, по крайней мере во второй раз точно, ибо к сожалению люди учатся только когда их собственные действия оказываются торчащими сзади без вазелина.
2. Вот что бывает, когда забиваешь на планирование казалось бы неважных вещей.
АБ>Как-то имел я ввиду такую работу в команде.
Полностью разделяю твоё мнение что это не командная работа.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Vetal_ca, Вы писали:
V_>>А зачем нужен был IPv6 на внутренних сетях? Это вопрос а не возражение C>Для организации сети сервисов, которые могут жить в разных AWS-аккаунтах, регионах или вообще облаках. Сквозная глобальная адресация позволяет избавиться от жутиков типа VPC peering и сильно ограничить работу через публичный Интернет.
Т.е., непосредственно, прямая адресация, то что видно "в лоб" за самим IPv6. До этого мы не доросли (по вышеописанному), IPv6 termination с IPv4 внутри хватает.
SRv6 несколько "ломает" мозг и дает новое виденье.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Sheridan, Вы писали:
C>>>Т.е. нужен специальный репозиторий для хранения пакетов, в котором будут лежать несколько версий (для откатов). Так как версий может быть несколько, то нужно уметь ставить определённую из них. Так что нужен какой-то софт, которой будет этим управлять. S>>Версий не несколько, а одна. Ставить не определённую, а свежую. C>Нет. Так делать нельзя, так как необходимость делать откат — это даже не обсуждается.
Бредовый бред бредящего бредуна. Даже читать такое противно и сразу появляется желание уйти из такой команды несмотря на то что я (к счастью) не в ней.
S>>Такой сценарий настолько редок, что встречается один-два раза в жизни. S>>При правильном подходе к проектированию, программированию и планированию вам не придётся множить версии либ. C>
Стыдно? Ну не прикрывай рукой глаза, все понимают что иногда прозрение приходит поздно.
C>>>Затем ещё несколько итеративных шагов — и получается Docker. S>>Если для вас докер это инструмент для впулливания говна мамонта к проекту, то да. C>У нас говно мамонта — в чётко ограниченных загонах в зоопарке. А вот вы в нём плаваете.
Видел раскадровку нашего мульта как Винни Пух в лужу входит а потом выходит?
Вот это как раз с докером часто. Поэтому и противно.
C>>>Да. Если надеяться только на тестирование, то система работать не будет. S>>А, у вас еще и тестирование никуда не годится? У вас то хоть тестер отдельный есть, ну хоть один? Или когото из программистов от работы отрываете? C>Нет, это практика. Ни одно тестирование не находит всех ошибок.
Не находит, да. Я с этим не спорил. Я спросил — а вы тестируете вообще? Тестирование программистами у себя на конпутерах не считается. Такое тестирование всегда будет "всё ок".
C>Так, а я пока жду от админа Sheridan'а плана тестировани того Ansible-скрипта, который он привёл. Интересно, как же у вас находят ошибки?
У проектов, которым важно качество всегда есть пул виртуалок с различными конфигурациями. В том числе и со снапшотами. Ббскриптовать запуск машин, пулл снапшота, прогон деплоя, сохранение логов — делается в охотку любым админом/девапсом ибо это весело. Анализ логов — тоже не бином ньютона. В итоге — запустили, отработало, почитали результат. Стоит ли мне рассказывать что надо делать если результат не понравился или основы тестирования ты таки знаешь?
S>>Аааа, так у вас денег нет даже на нормальное железо с ilo/ipmi/etc...? И вы прямо на голом железе софт разворачиваете? C>Это было в 2008-м году, тогда IPMI не был ещё так распространён. C>Но вот такой вот софт "без ошибок", да.
Ну что я могу сказать...Хороший опыт для админа. Всем через это надо пройти и плох тот админ который дважды на эти грабли настуапает.
S>>Мда. Это последствия отсутствия админа в команде. Ну и конечно докер магическим образом правит ошибки всего софта, который внутри. Сообщения перестают пропадать, да. C>В случае с Докером, кстати, такой проблемы не было бы. Он бы гарантированно убил Bind, и в мониторилке это было бы отмечено.
В случае с системд тоже.
C>>>Так что нет, НИКТО не может писать надёжный софт. Совсем. S>>И поэтому надо сложить лапки и писать вилами по воде? C>>>Нет, как я уже показал. S>>Ничего ты не показал. C>В твоём скрипте — дыра.
В твоём софте куча дыр, пока ещё прикрытых докером.
C>>>Я уже показал, что никакой Ansible код не может быть надёжным. S>>Я не удивлюсь что с вашим подходом к софтописанию и докер перестанет быть надёжным. C>Докер — тоже ненадёжный, но там основные сценарии тестируются миллионами человек, так что на практике оно работает.
А ансибл использует только шеридан, ага.
Ну, такой себе аргумент, хотя он хорош тем что становится понятно что нормальных аргументов нет.
S>>Я уже почти готов поставить штутку баксов что у вас уже местами с докером возникают сложности и они пока решаются разделением бажного контейнера на два разных контейнера с выносом бажного функционала в более тепличные условия. C>Мимо.
Две штуки баксов.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Sheridan, Вы писали:
C>>>Ты уже сам привёл пример скрипта, который даст непредсказуемую ошибку. S>>Ты когда строку на печать выводишь — проверяешь наличие \0 в конце? Нет? Не нужно? Вот так и тут. Когда будет нужно — тогда будет и более строгая проверка. C>Что значит "когда нужно"? Этот скрипт прямо сейчас имеет ошибку, которая будет проявляться в редких ситуациях. Причём вполне возможно, что катастрофически.
То и значит — когда нужно. Этот код автора устраивает — значит ему не нужно.
S>>>>Подобные ошибки (да и любые другие) отлавливаются на тестах, в приемлемом для бизнеса количестве. Возникающие впоследствии у клиентов баги чинятся уже хотфиксами. И так далее. C>>>Нет, такие ошибки не отлавливаются тестами. S>>Такие ошибки замечательно отслеживаются тестами. C>ОК. Жду тестового плана, который помог бы найти указанную мной ошибку (certbot падает между созданием файла и записью в него).
Статус таска — "провалено". Деплой в таком случае по умолчанию останавливается. Чтобы такое проигнорировать и продолжить деплой с такой ошибкой — нужно дописать немного кода. Но даже с ним в логах и на экране будет красным по чорному "случилась жопа".
Здравствуйте, mogadanez, Вы писали:
S>>>>А то создание образов и их поддержка не увеличивает стоимость. M>>>сложность имеджа при прочих равных будет ниже S>>Нет. Она сопоставима с сложностью ансибла потому что нужно будет провернуть +- те же самые вещи. Магии не бывает. M>нет. потому что в ансибле нужно думать/заниматься подчисткой, инвентори и прочей вспомогательной фигней.
То что надо чистить за докером не означает что за всеми остальными тоже. Цель почти всегда — деплой/обновление. Вэтом случае чистить ничего не надо. Добросить данных/конфигов — да. Реструктуризовать данные — тоже бывает. Чистить — не припомню такого.
M>да и банально больше буков в плейбуке
На порядки меньше там кода как правило чем в любом проекте, который потребовал деплоя таким способом.
M>сложность докер имеджа сопоставима с настройкой девелоперской машины
Ты преувеличиваешь сложность ансибла, очень сильно.
S>>У вас (репозиторий) свой? M>был и свой (запускается за пару минут)
ват? Репозиторий это куча файлов, котрорые хостятся об тот же nginx через тупой автоиндекс. И даже это у вас запускалось пару минут?...
Здравствуйте, Sheridan, Вы писали:
S>То есть магии нет там где она действительно нужна, зато куча разговоров про "изкаробки". S>А простые сервисы скалятся на ура и без докера
Однострочный пример для MongoDB я привел тебе в самом начале. Изкаробки Bitnami charts, но не из Kubernetes
Здравствуйте, Vetal_ca, Вы писали:
V> AB>Под нагрузкой теряет логи, может зависнуть так, что снять post-mortem не представляется возможным, V> Может, содержимое контейнера съедало все ресурсы? Добавить лимиты (CPU/RAM)
Тут закономерностей не было найдено. Правда вот прям особо глубоко никто и не копал, т.к. цели уезжать именно на докер не было.
V> AB> проблемы с изоляцией (когда есть возможность "прогуляться" из одного контейнера в другой), V> Interprocess или сетевые
Сетевые на сколько я знаю, но с этим безопасники работали.
V> AB> проблемы с IPv6 (у нас это критикал, перечеркивающий любые другие достоинства). V> А зачем нужен был IPv6 на внутренних сетях? Это вопрос а не возражение
Здравствуйте, Sheridan, Вы писали:
S> S>> Команда разработчиков при первом принятии либы в проект должна взять последний релиз этой либы. S> AB>Не должна. "Классический" пример — OpenSSL. S> Это у вас там это классика. У меня нет такого.
Нет OpenSSL? Я могу предположить только это, ибо за последние лет 5 по ней оттоптались все, у кого есть TLS хоть чуть чуть.
S> AB>Помимо этого могут быть еще причины — например, версия библиотеки зафиксирована в корпоративном репозитори и т.д. S> Раз репозиторий ваш, то значит "зафиксировано" читается как "нам лень исправлять".
У любого исправления есть цена и принесенная народному хозяйству польза. Если второе меньше первого, то оно никому не нужно.
S> S>> И впоследствии эта команда должна планировать при каждом релизе своего проекта проверять — а не обновились ли используемые библиотеки (это может делать и девапс)? И планировать переход на новые версии если да (это делают программисты). S> AB>Не должна, если плюсы новой версии при детальном рассмотрении не перевешивают минусы старой. Ибо новая версия — это не только новые фитчи, но еще и новые баги. S> Ну то есть несмотря на утверждения "мы работаем в команде!" — вы плевать хотели на работу админа/девапса.
Вот как раз работая в команде можно принять взвешенное решение (а админское правило "работает — не трогай" как никогда актуально).
S> S>> Мне тут постоянно уши жужжат что я в команде не работал. S> AB>Тебе намекают на то, что твой опыт отстает лет на 10+ от современных реалий разработки и эксплуатации. Но больше всего намекающих расстраивает тот факт, что ты не хочешь учиться. S> Я не гоняюсь за топчик-технологиями, да. Я следую требованиям, как вы говорите?... А, бизнеса, вот.
Если бы ты следовал требованиям бизнеса, то у тебя не возникало бы удивления ни про докер, ни про (не)последние версии библиотек, ни про требования работать только на рабочем оборудовании.
Здравствуйте, Sheridan, Вы писали:
АБ>> — девопс или кто-то ещё приходит и говорит, что есть новая либа, переход на которую нам даст такие-то плюсы, S>Глупость. Очень большая глупость, которая всегда больно бьёт по яйцам в будущем. Если плавно не переходить с версии на версию, то когда это действительно станет нужно — у команды не будет ни опыта, ни времени.
Или не ударит, или переходить не придётся, потому что заказчик платит до конца года и переводит проект на саппорт или же текущая версия полностью устраивает.
АБ>>Подпунктами ещё идут вопросы о выделении времени и бюджета, как на оценку стоимости перехода, так и на сам переход. S>П — Планирование. Слышал, не?
Я вообще-то именно о нём родимом, о планировании, и говорю.
Любое изменение пройдёт по цепочке:
— принятие решения о необходимости,
— оценка стоимости изменения (время, сторипойнты),
— согласование бюджета.
V_>Я к тому, что существование самой проблемы нуждается в доказательстве. Лишняя сущность плохо. Но есть ли здесь лишние сущности, как задача поставлена? Да, черный XYZ — плохо, но наличие черного XYZ нужно доказать.
Вот это уже более предметный разговор. Сущность является лишней, если ее применение не ведет к улучшению операционных характеристик, я именно так и написал. Иными словами, не надо забивать гвозди стоуровневым микроскопом.
V_> А так, сама ОС — +1 сущность. Избавимся от ОС?
Если ОС не требуется для операционного функционировани (см. PIC'и всякие) — конечно.
Практика такова, что чем более сложное и "уровневое" решение, тем оно менее надежно, тем дороже его обслуживать, тем больше ошибок и проблем. Стремитесь к простоте.
Хоть, конечно, я и понимаю — сделать сложно может любой. А вот сделать просто, для этого зачастую нужно быть гением.
И, что еще важнее, быть готовым переделать, рефакторить, исправить, улучшить. Большинство это просто не могут, и вместо переработки начинают наворачивать слои абстракции один за другим. Там где их не нужно.
Здравствуйте, SkyDance, Вы писали:
C>>Это было в 2008-м году, тогда IPMI не был ещё так распространён. SD>В какой части мира это было?
Украина, Киев.
SD>В Москве и Австралии IPMI уже был, я б сказал, более чем распространен.
Я уже не помню почему, но IPMI настроен не был. Можно было попросить местных техников сбросить питание, но с моей стороны было непонятно что с сервером.
Здравствуйте, Sheridan, Вы писали:
S>>>Такие ошибки замечательно отслеживаются тестами. C>>ОК. Жду тестового плана, который помог бы найти указанную мной ошибку (certbot падает между созданием файла и записью в него). S>Статус таска — "провалено". Деплой в таком случае по умолчанию останавливается.
Нет. Не так. Как можно эту ошибку найти ДО ТОГО, как она возникнет в production'е?
Ошибка, очевидно, не проявляется каждый раз.
S>Чтобы такое проигнорировать и продолжить деплой с такой ошибкой — нужно дописать немного кода. Но даже с ним в логах и на экране будет красным по чорному "случилась жопа".
У меня деплои проходят без моего вмешательства, под контролем автоматики.
Здравствуйте, Vetal_ca, Вы писали:
C>>Для организации сети сервисов, которые могут жить в разных AWS-аккаунтах, регионах или вообще облаках. Сквозная глобальная адресация позволяет избавиться от жутиков типа VPC peering и сильно ограничить работу через публичный Интернет. V_>Т.е., непосредственно, прямая адресация, то что видно "в лоб" за самим IPv6. До этого мы не доросли (по вышеописанному), IPv6 termination с IPv4 внутри хватает.
Мы примерно так же пока делаем, так как AWS и GCloud не очень ещё поддерживает IPv6 внутри.
V_>SRv6 несколько "ломает" мозг и дает новое виденье. V_>https://fosdem.org/2020/schedule/event/rethinking_kubernetes_networking_with_srv6/attachments/slides/3687/export/events/attachments/rethinking_kubernetes_networking_with_srv6/slides/3687/20200203_FOSDEM_SRv6_K8s.pdf
Это нужно аппаратную поддержку, по-хорошему. Но идея правильная, AWS примерно так внутри и работает.
V_>Интересны вот такие необычные варианты. Out of the (my) box. Если не для непосредственного использования, то для прокачки интуиции.
Ну да, с IPv6 можно очень многое упростить. Но по моим оценкам, это ещё лет 5 нужно для массивного проникновения на рынок.
Здравствуйте, Sheridan, Вы писали:
C>>Нет. Так делать нельзя, так как необходимость делать откат — это даже не обсуждается. S>Бредовый бред бредящего бредуна. Даже читать такое противно и сразу появляется желание уйти из такой команды несмотря на то что я (к счастью) не в ней.
Мальчик, ты никогда не работал нигде серьёзно devops'ом. И даже не хочешь учиться.
Возможность отката нужна из-за того, что бывают ошибки, которые выявляются не сразу. Лично мной найденная, например: https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8189789 — проявляется под сильной нагрузкой, в виде попадающего в бесконечный цикл потока. Как результат, production-серверы постепенно умирают.
Так же было ещё штук 10 подобных историй — third-party библиотека логгирования, которая утекала память, изменившийся порядок шифров в SSL, который ломал клиентский файрвол, ложное срабатывание антивируса на наш WebAssembly-код, и т.д.
S>>>При правильном подходе к проектированию, программированию и планированию вам не придётся множить версии либ. C>> S>Стыдно? Ну не прикрывай рукой глаза, все понимают что иногда прозрение приходит поздно.
Стыдно смотреть на неграмотного идиота. Воинствующе неграмотного.
C>>У нас говно мамонта — в чётко ограниченных загонах в зоопарке. А вот вы в нём плаваете. S>Видел раскадровку нашего мульта как Винни Пух в лужу входит а потом выходит? S>Вот это как раз с докером часто. Поэтому и противно.
Ну я понимаю, вы там предпочитаете дерьмо есть и плавать в нём.
C>>Нет, это практика. Ни одно тестирование не находит всех ошибок. S>Не находит, да. Я с этим не спорил.
Ты только этим и занимаешься.
S>Я спросил — а вы тестируете вообще? Тестирование программистами у себя на конпутерах не считается. Такое тестирование всегда будет "всё ок".
Естественно, тестируем. И имеем "план Б" на случай непредвиденной ситуации — у нас стоят тревожные сигналы, которые при любой аномалии просто откатят код до предыдущей версии.
C>>Так, а я пока жду от админа Sheridan'а плана тестировани того Ansible-скрипта, который он привёл. Интересно, как же у вас находят ошибки? S>У проектов, которым важно качество всегда есть пул виртуалок с различными конфигурациями. В том числе и со снапшотами.
Ой, уже snapshot'ы появились. А кто ими управляет, как происходит развёртывание на кластер? Всё те же 2 строчки в Ansible, да?
Кроме того, как я уже показал, ошибка может возникнуть в любой момент в production. Она не детерминированная.
C>>Но вот такой вот софт "без ошибок", да. S>Ну что я могу сказать...Хороший опыт для админа. Всем через это надо пройти и плох тот админ который дважды на эти грабли настуапает.
Только вот кто-то от этого учится, а кто-то продолжает наступать.
C>>В случае с Докером, кстати, такой проблемы не было бы. Он бы гарантированно убил Bind, и в мониторилке это было бы отмечено. S>В случае с системд тоже.
Настоящий админ должен использовать init.d!
S>>>Ничего ты не показал. C>>В твоём скрипте — дыра. S>В твоём софте куча дыр, пока ещё прикрытых докером.
Тем не менее, я тут не привожу в качестве примера дырявые решета.
C>>Докер — тоже ненадёжный, но там основные сценарии тестируются миллионами человек, так что на практике оно работает. S>А ансибл использует только шеридан, ага.
Примерно так. Или у вас там только playbook'и из example'ов? Ну в это я могу поверить, да.
S>>>Я уже почти готов поставить штутку баксов что у вас уже местами с докером возникают сложности и они пока решаются разделением бажного контейнера на два разных контейнера с выносом бажного функционала в более тепличные условия. C>>Мимо. S>Две штуки баксов.
Ок, принимается. И ты проиграл, у нас Docker используется для асинхронных задач (вычислительных на GPU) и постоянно работающих сервисов (ECS Fargate). Разделения на "бажных контейнеры" нет.
Здравствуйте, Sheridan, Вы писали: S>То что надо чистить за докером не означает что за всеми остальными тоже. Цель почти всегда — деплой/обновление. Вэтом случае чистить ничего не надо. Добросить данных/конфигов — да. Реструктуризовать данные — тоже бывает. Чистить — не припомню такого.
Ну детский сад какой-то.
Речь же идёт об утилизации железа. Когда у тебя десяток серверов типа Dell PowerEdge в максимальной конфигурации, и ты на их основе формируешь парк "виртуальных машин" с потребными тебе функциями.
Сегодня надо так — раскидали так. Завтра надо по-другому — раскидали по другому.
Способность унести контейнер на другую ноду, не оставив сери на предыдущей — ключ к успеху. Все эти ансиблы — это вообще совсем-совсем другой уровень операционной гибкости.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sheridan, Вы писали:
S>Ладно, не буду тебя заставлять изучать его, видимо не выйдет. При работе на целевом хосте ансибл создаёт временные файлы — по сути питоноскрипты, которые исполняет. По завершению таска — подчищает.
Шеридан, ты специально себя полным профаном в деплое выставляешь, неспособным понять суть вопроса и о чем вообще спор идет?
Просто все твои ФИО ты сам же и открыл — какой смысл себя лишать потенциального куска хлеба в случае чего?
P.S. Причем ты отлично понимаешь, саму суть спора, т.к. раньше ты оговорился о том, что ансибл чистит не то, что все ожидают. Т.е., ты осознанно себя профнепригодным выставляешь.
Здравствуйте, SkyDance, Вы писали:
C>>О! Bind — классный пример. Я как-то вынужден был ночью съездить в дата-центр, чтобы вручную перезагрузить сервер. Из-за того, что Bind при shutdown'е зациклился (из-за ошибки в коде DNSSEC и init.d-скрипте). А отключается bind после ssh. SD>Это пример катастрофического головотяпства.
Пусть так. Как это отменяет сам факт ошибки в бинде, приведшей к краху системы?
Здравствуйте, Vetal_ca, Вы писали:
S>>То есть магии нет там где она действительно нужна, зато куча разговоров про "изкаробки". S>>А простые сервисы скалятся на ура и без докера V_>Однострочный пример для MongoDB я привел тебе в самом начале. Изкаробки Bitnami charts, но не из Kubernetes V_>Что еще надо?
Нене, ничего, уже всё понятно.
Здравствуйте, Anton Batenev, Вы писали:
S>> AB>Не должна. "Классический" пример — OpenSSL. S>> Это у вас там это классика. У меня нет такого. AB>Нет OpenSSL? Я могу предположить только это, ибо за последние лет 5 по ней оттоптались все, у кого есть TLS хоть чуть чуть.
Нет проблем с ней.
S>> AB>Помимо этого могут быть еще причины — например, версия библиотеки зафиксирована в корпоративном репозитори и т.д. S>> Раз репозиторий ваш, то значит "зафиксировано" читается как "нам лень исправлять". AB>У любого исправления есть цена и принесенная народному хозяйству польза. Если второе меньше первого, то оно никому не нужно.
А берутся во внимание только трудозатраты программистов? Или всётаки вы командой работаете?
S>> S>> И впоследствии эта команда должна планировать при каждом релизе своего проекта проверять — а не обновились ли используемые библиотеки (это может делать и девапс)? И планировать переход на новые версии если да (это делают программисты). S>> AB>Не должна, если плюсы новой версии при детальном рассмотрении не перевешивают минусы старой. Ибо новая версия — это не только новые фитчи, но еще и новые баги. S>> Ну то есть несмотря на утверждения "мы работаем в команде!" — вы плевать хотели на работу админа/девапса. AB>Вот как раз работая в команде можно принять взвешенное решение (а админское правило "работает — не трогай" как никогда актуально).
То есть — плевать. Хорошая команда, сплочённая.
S>> S>> Мне тут постоянно уши жужжат что я в команде не работал. S>> AB>Тебе намекают на то, что твой опыт отстает лет на 10+ от современных реалий разработки и эксплуатации. Но больше всего намекающих расстраивает тот факт, что ты не хочешь учиться. S>> Я не гоняюсь за топчик-технологиями, да. Я следую требованиям, как вы говорите?... А, бизнеса, вот. AB>Если бы ты следовал требованиям бизнеса, то у тебя не возникало бы удивления ни про докер, ни про (не)последние версии библиотек, ни про требования работать только на рабочем оборудовании.
А это меня не удивляет. Меня удивляет с каким рвением вы бросаетесь доказывать что вот ваше отношение к перечисленному единственно верный путь и других нет.
Я понимаю зачем докер. Я не понимаю почему только докер, исключительно докер, докер докер и кубернетес пророк его.
Я понимаю почему версия библиотеки в проекте может отличаться от актуальной. Я не понимаю почему как только речь о актуализации заходит — начинается выдумывание 1000 и 1 способа почему это не нужно делать.
И так далее.
Здравствуйте, Андрей Бабошин, Вы писали:
АБ>>> — девопс или кто-то ещё приходит и говорит, что есть новая либа, переход на которую нам даст такие-то плюсы, S>>Глупость. Очень большая глупость, которая всегда больно бьёт по яйцам в будущем. Если плавно не переходить с версии на версию, то когда это действительно станет нужно — у команды не будет ни опыта, ни времени. АБ>Или не ударит, или переходить не придётся, потому что заказчик платит до конца года и переводит проект на саппорт или же текущая версия полностью устраивает.
Ударит, обязательно.
Даже проект на саппорте нужно время от времени брать и актуализировть.
АБ>>>Подпунктами ещё идут вопросы о выделении времени и бюджета, как на оценку стоимости перехода, так и на сам переход. S>>П — Планирование. Слышал, не? АБ>Я вообще-то именно о нём родимом, о планировании, и говорю. АБ>Любое изменение пройдёт по цепочке: АБ> — принятие решения о необходимости, АБ> — оценка стоимости изменения (время, сторипойнты), АБ> — согласование бюджета.
Да. Именно так. Принимаете решение о необходимости, оцениваете затраты, согласуете бюджет и работаете.
У вас проблемы с первым пунктом. У вас нет желания этого делать. Совершенно.
Здравствуйте, Sheridan, Вы писали:
S>Тогда это их головная боль. За всем миром все баги не вылечишь.
ОК, это их головная боль. Допустим. Мне-то что делать, пока они свои баги лечат (если вообще лечат)? У меня мой софт лежит всё это время, вообще-то. И когда они его поднимут, мне еще надо будет убедиться, что с моим софтом из-за этого краха системы ничего не произошло — а это уже моя головная боль на ровном месте.
S>Сначала со своими разберитесть, чтобы софт хотя бы заработал без тепличных условий.
Когда я подхожу к владельцу бизнеса с какой-то новой фичей, он у меня спрашивает первым делом — what is the business value of it, _ABC_? Бывает, что не спрашивает, конечно, но это означает только, что ответ на первый вопрос уже очевиден ему самому или я ответил на него в самом описании новой фичи и ответ его устроил.
Так вот — what is the business value работы софта без тепличных условий?
Нафига надо выводить морозоустойчивый сорт огурцов, требующий повышенного внимания и дающий меньше урожая, если тепличный приносит огромный урожай и не требует особого внимания, а сама теплица обходится практически бесплатно? Нафига мне тратить ресурсы агронома на это, вместо того, чтобы он мне выводил еще более урожайный и вкусный тепличный сорт? Покупателю пофиг, в теплице ли выращены эти огурцы, или на морозе. Ему важен вкус, размер, внешний вид и цена.
Здравствуйте, Sheridan, Вы писали:
M>>если можно без ансибла — зачем ансибл S>Ну хотя бы потому что руками долго и сложно поддерживать единое окружение.
По сравнению с докером, ансиблом долго и сложно поддерживать единое окружение. Так зачем ансибл?
Здравствуйте, Cyberax, Вы писали:
S>>>>Такие ошибки замечательно отслеживаются тестами. C>>>ОК. Жду тестового плана, который помог бы найти указанную мной ошибку (certbot падает между созданием файла и записью в него). S>>Статус таска — "провалено". Деплой в таком случае по умолчанию останавливается. C>Нет. Не так. Как можно эту ошибку найти ДО ТОГО, как она возникнет в production'е? C>Ошибка, очевидно, не проявляется каждый раз.
Тестированием. Не за что, ваш кеп.
S>>Чтобы такое проигнорировать и продолжить деплой с такой ошибкой — нужно дописать немного кода. Но даже с ним в логах и на экране будет красным по чорному "случилась жопа". C>У меня деплои проходят без моего вмешательства, под контролем автоматики.
У тебя не деплои, у тебя просто файлики образов копируются. Что работает, кстати, пока место на дисках есть.
Здравствуйте, Sheridan, Вы писали:
C>>Нет. Не так. Как можно эту ошибку найти ДО ТОГО, как она возникнет в production'е? C>>Ошибка, очевидно, не проявляется каждый раз. S>Тестированием. Не за что, ваш кеп.
Ну так как? Как будет выглядеть тестовый план, который найдёт указанную мной ошибку?
C>>У меня деплои проходят без моего вмешательства, под контролем автоматики. S>У тебя не деплои, у тебя просто файлики образов копируются.
Да, а что?
S>Что работает, кстати, пока место на дисках есть.
Мимо. Учим матчасть, в отличие от Ansible, который с песней будет пытаться запустить playbook при нулевом свободном месте, Docker будет автоматически очищать неиспользуемые образы и контейнерные ФС.
Здравствуйте, Cyberax, Вы писали:
C>>>Нет. Так делать нельзя, так как необходимость делать откат — это даже не обсуждается. S>>Бредовый бред бредящего бредуна. Даже читать такое противно и сразу появляется желание уйти из такой команды несмотря на то что я (к счастью) не в ней. C>Мальчик, ты никогда не работал нигде серьёзно devops'ом. И даже не хочешь учиться.
А ты ходить уже научился?
C>Возможность отката нужна из-за того, что бывают ошибки, которые выявляются не сразу. Лично мной найденная, например: https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8189789 — проявляется под сильной нагрузкой, в виде попадающего в бесконечный цикл потока. Как результат, production-серверы постепенно умирают.
Я рад за вас. Но при чом тут откат, когда нужен хотфикс?
C>Так же было ещё штук 10 подобных историй — third-party библиотека логгирования, которая утекала память, изменившийся порядок шифров в SSL, который ломал клиентский файрвол, ложное срабатывание антивируса на наш WebAssembly-код, и т.д.
Критические ошибки отлавливаются во время тестирования, некритические лечатся хотфиксами.
S>>>>При правильном подходе к проектированию, программированию и планированию вам не придётся множить версии либ. C>>> S>>Стыдно? Ну не прикрывай рукой глаза, все понимают что иногда прозрение приходит поздно. C>Стыдно смотреть на неграмотного идиота. Воинствующе неграмотного.
Да, но я не теряю надежды таких обратно на дорогу вернуть из кустов.
C>>>У нас говно мамонта — в чётко ограниченных загонах в зоопарке. А вот вы в нём плаваете. S>>Видел раскадровку нашего мульта как Винни Пух в лужу входит а потом выходит? S>>Вот это как раз с докером часто. Поэтому и противно. C>Ну я понимаю, вы там предпочитаете дерьмо есть и плавать в нём.
Приходится, потому что бывают такие программеры, которые это генерируют и приходится разгребать ибо работа такая.
C>>>Нет, это практика. Ни одно тестирование не находит всех ошибок. S>>Не находит, да. Я с этим не спорил. C>Ты только этим и занимаешься.
Нет. От силы минут 15 в день.
S>>Я спросил — а вы тестируете вообще? Тестирование программистами у себя на конпутерах не считается. Такое тестирование всегда будет "всё ок". C>Естественно, тестируем. И имеем "план Б" на случай непредвиденной ситуации — у нас стоят тревожные сигналы, которые при любой аномалии просто откатят код до предыдущей версии.
Ты не до конца ответил на вопрос.
C>>>Так, а я пока жду от админа Sheridan'а плана тестировани того Ansible-скрипта, который он привёл. Интересно, как же у вас находят ошибки? S>>У проектов, которым важно качество всегда есть пул виртуалок с различными конфигурациями. В том числе и со снапшотами. C>Ой, уже snapshot'ы появились. А кто ими управляет, как происходит развёртывание на кластер? Всё те же 2 строчки в Ansible, да?
Да.
C>Кроме того, как я уже показал, ошибка может возникнуть в любой момент в production. Она не детерминированная.
Ну я так понимаю что ты хочешь спросить смогу ли я перехватить неперехватываемую ошибку, которая никогда категорически не перехватывается на тестах и обязательно рушит прод в ноль.
Плохие новости — такую ошибку я не перхвачу, прод обречён.
Перехватить остальные же вероятность сильно выше, особенно если известно чего ждать.
Такое впечатление что ты не тестировал никогда код перед релизом и не знаешь чего ждать. Глупые вопросы у тебя.
C>>>Но вот такой вот софт "без ошибок", да. S>>Ну что я могу сказать...Хороший опыт для админа. Всем через это надо пройти и плох тот админ который дважды на эти грабли настуапает. C>Только вот кто-то от этого учится, а кто-то продолжает наступать.
Сочувствую таким, да.
C>>>В случае с Докером, кстати, такой проблемы не было бы. Он бы гарантированно убил Bind, и в мониторилке это было бы отмечено. S>>В случае с системд тоже. C>Настоящий админ должен использовать init.d!
Кому должен?
S>>>>Ничего ты не показал. C>>>В твоём скрипте — дыра. S>>В твоём софте куча дыр, пока ещё прикрытых докером. C>Тем не менее, я тут не привожу в качестве примера дырявые решета.
Не приводи, ок.
C>>>Докер — тоже ненадёжный, но там основные сценарии тестируются миллионами человек, так что на практике оно работает. S>>А ансибл использует только шеридан, ага. C>Примерно так. Или у вас там только playbook'и из example'ов? Ну в это я могу поверить, да.
Всё ясно с твоим желанием обучаться. Сочувствую.
S>>>>Я уже почти готов поставить штутку баксов что у вас уже местами с докером возникают сложности и они пока решаются разделением бажного контейнера на два разных контейнера с выносом бажного функционала в более тепличные условия. C>>>Мимо. S>>Две штуки баксов. C>Ок, принимается. И ты проиграл, у нас Docker используется для асинхронных задач (вычислительных на GPU) и постоянно работающих сервисов (ECS Fargate). Разделения на "бажных контейнеры" нет.
Вообще непонятно для чего ты пришол доказывать что не верблюд, ибо ты и так не верблюд
Здравствуйте, Sinclair, Вы писали:
S>Способность унести контейнер на другую ноду, не оставив сери на предыдущей — ключ к успеху. Все эти ансиблы — это вообще совсем-совсем другой уровень операционной гибкости.
Ну так и тягайте хостами. Или у вас гипервизоры не умеют в миграцию гостей?
Здравствуйте, Cyberax, Вы писали:
C>Ну так как? Как будет выглядеть тестовый план, который найдёт указанную мной ошибку?
Подклыдыванием фейкового цертбота например, который валится.
C>>>У меня деплои проходят без моего вмешательства, под контролем автоматики. S>>У тебя не деплои, у тебя просто файлики образов копируются. C>Да, а что?
Да то что ты путаешь деплой с копированием.
S>>Что работает, кстати, пока место на дисках есть. C>Мимо. Учим матчасть, в отличие от Ansible, который с песней будет пытаться запустить playbook при нулевом свободном месте, Docker будет автоматически очищать неиспользуемые образы и контейнерные ФС.
Как у вас так получается — одновременно утверждать что у докера мусора нет и то, что всегда найдется мусор?
А если не будет места даже после очистки мусора? Ну, как себя поведет докер? Купит и добавит еще один винт в рейд?
Здравствуйте, _ABC_, Вы писали:
_AB>Здравствуйте, Sheridan, Вы писали:
S>>Тогда это их головная боль. За всем миром все баги не вылечишь. _AB>ОК, это их головная боль. Допустим. Мне-то что делать, пока они свои баги лечат (если вообще лечат)? У меня мой софт лежит всё это время, вообще-то. И когда они его поднимут, мне еще надо будет убедиться, что с моим софтом из-за этого краха системы ничего не произошло — а это уже моя головная боль на ровном месте.
Оно лежит на тестовом полигоне / stage. Пока лежит — принимаете решение — тыкать палочкой поставщика, отказаться от написанного функционала и откатить коммит, отказаться от либы и реализовать самим. Приняли решение — действуйте в соответствиии с ним.
S>>Сначала со своими разберитесть, чтобы софт хотя бы заработал без тепличных условий. _AB>Когда я подхожу к владельцу бизнеса с какой-то новой фичей, он у меня спрашивает первым делом — what is the business value of it, _ABC_? Бывает, что не спрашивает, конечно, но это означает только, что ответ на первый вопрос уже очевиден ему самому или я ответил на него в самом описании новой фичи и ответ его устроил.
А ты ему такой "easy deployment, lack of dependence on mammoth shit, which allows the customer to save money by not allocating separate servers for our software"
_AB>Нафига надо выводить морозоустойчивый сорт огурцов, требующий повышенного внимания и дающий меньше урожая, если тепличный приносит огромный урожай и не требует особого внимания, а сама теплица обходится практически бесплатно? Нафига мне тратить ресурсы агронома на это, вместо того, чтобы он мне выводил еще более урожайный и вкусный тепличный сорт? Покупателю пофиг, в теплице ли выращены эти огурцы, или на морозе. Ему важен вкус, размер, внешний вид и цена.
Сильный порыв ветра — и всё, нет теплицы. Нет дохода за текущий сезон, нечем выдавать зарплату
Здравствуйте, _ABC_, Вы писали:
M>>>если можно без ансибла — зачем ансибл S>>Ну хотя бы потому что руками долго и сложно поддерживать единое окружение. _AB>По сравнению с докером, ансиблом долго и сложно поддерживать единое окружение. Так зачем ансибл?
Потому что у ансибла гораздо больше возможностей.
Здравствуйте, Sheridan, Вы писали:
S>>Способность унести контейнер на другую ноду, не оставив сери на предыдущей — ключ к успеху. Все эти ансиблы — это вообще совсем-совсем другой уровень операционной гибкости. S>Ну так и тягайте хостами. Или у вас гипервизоры не умеют в миграцию гостей?
Гипервизорная виртуализация — это дорого. Контейнеры жрут на порядок меньше ресурсов, т.к. позволяют реюзать кернел оси.
Для перехода из детского сада в школу надо освоить хотя бы азы современной архитектуры хостинга приложений.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sheridan, Вы писали:
S>>>Что работает, кстати, пока место на дисках есть. C>>Мимо. Учим матчасть, в отличие от Ansible, который с песней будет пытаться запустить playbook при нулевом свободном месте, Docker будет автоматически очищать неиспользуемые образы и контейнерные ФС. S>Как у вас так получается — одновременно утверждать что у докера мусора нет и то, что всегда найдется мусор? S>А если не будет места даже после очистки мусора? Ну, как себя поведет докер? Купит и добавит еще один винт в рейд?
Да ну блин опять детский сад. Контейнер атомарен — если нет места, докер просто не сможет его запустить, и всё. И не будет такого, что полконтейнера развёрнуто, а полконтейнера — нет, и для уборки этого говна надо писать ещё один скрипт.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, 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-библиотеку, что приводило к тому, что при обновлении коммона надо было обновлять её во всех проектах.
В какой-то момент научились процесс обновления автоматизировать, но вообще это боль и куча времени.
Здравствуйте, 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, проще научить свинью играть лунную сонату, нежели что-то втолковать шеридану.
Здравствуйте, Sheridan, Вы писали:
S>Лежит у клиента — большой косяк, сам понимаешь.
S>Надо чтобы у клиента не лежало. А поэтому тестировать у себя на стейжах.
Как я протестирую софт всех других вендоров? Не либу, входящую в мой софт, а софт самостоятельный других вендоров?
S>Почему вы тогда волнуетесь? Пусть волнуется другой поствщик — проблема у него.
Потому, что когда другой поставщик исправит свои косяки, мне нужно будет убедится, что ничего не сломано у меня.
S>Зачем её решаете вы?
Потому, что клиенту пофиг, кто сломал, ему нужна моя работающая программа.
S>Я? Я не пишу об этом сценарии.
Кто писал с твоего аккаунта "allows the customer to save money by not allocating separate servers for our software"?
S>Английский поскипал, не силён в разговорном.
Просто возразить тебе нечего, вот и прикрылся якобы непониманием написанного. Старый прием.
S>От ветра — да. Пока ветер не превышает пределы прочности. S>>>Сильный порыв ветра — и всё, нет теплицы.
Ты там уже у себя в голове определись...
Здравствуйте, Sheridan, Вы писали:
S>Вы что, нетестированный на собственных полигонах софт сразу деплоите заказчикам? о0
Дерьмо случается
хочешь сказать у тебя за всю карьеру не было ни одного факапа, падения всего и вся и тд?
если нет — то ты или врешь или деплоишь ансиблом сайты визитки Вась Пупкиных
Здравствуйте, Sheridan, Вы писали:
C>>Мальчик, ты никогда не работал нигде серьёзно devops'ом. И даже не хочешь учиться. S>А ты ходить уже научился?
Да. А вы там ещё ползаете?
C>>Возможность отката нужна из-за того, что бывают ошибки, которые выявляются не сразу. Лично мной найденная, например: https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8189789 — проявляется под сильной нагрузкой, в виде попадающего в бесконечный цикл потока. Как результат, production-серверы постепенно умирают. S>Я рад за вас. Но при чом тут откат, когда нужен хотфикс?
Хотфикс чего? JDK? Это занимает несколько дней для проведения полного цикла тестов. В таких случаях единственное решение — это откат до предыдущего состояния. А затем в спокойной обстановке уже разбираться со стратегией исправления ошибки.
C>>Так же было ещё штук 10 подобных историй — third-party библиотека логгирования, которая утекала память, изменившийся порядок шифров в SSL, который ломал клиентский файрвол, ложное срабатывание антивируса на наш WebAssembly-код, и т.д. S>Критические ошибки отлавливаются во время тестирования, некритические лечатся хотфиксами.
Ну что могу сказать...
C>>Естественно, тестируем. И имеем "план Б" на случай непредвиденной ситуации — у нас стоят тревожные сигналы, которые при любой аномалии просто откатят код до предыдущей версии. S>Ты не до конца ответил на вопрос.
У нас тестируется весь UI с помощью роботов, API с помощью интеграционных тестов, 85% кода сервисов покрыто unit-тестами. Вычислительные задачи валидируются на массиве тестовых данных и на задачах, которые запускались последние 2 недели. Помимо простого сравнения, используется AI для поиска аномалий (странное потребление памяти, увеличение времени работы и т.п.).
Каждые 6 месяцев мы отсылаем отчёты в правительство нескольких штатов для о результатах мониторинга реальных систем, построенных по нашим планам. Это нужно для поддержки сертифицированного статуса.
S>>>У проектов, которым важно качество всегда есть пул виртуалок с различными конфигурациями. В том числе и со снапшотами. C>>Ой, уже snapshot'ы появились. А кто ими управляет, как происходит развёртывание на кластер? Всё те же 2 строчки в Ansible, да? S>Да.
Не верю.
C>>Кроме того, как я уже показал, ошибка может возникнуть в любой момент в production. Она не детерминированная. S>Ну я так понимаю что ты хочешь спросить смогу ли я перехватить неперехватываемую ошибку, которая никогда категорически не перехватывается на тестах и обязательно рушит прод в ноль.
Именно так, да. Потому, что я так могу делать.
Да-да, Докер позволяет успешно обрабатывать неожиданные ошибки.
C>>Ок, принимается. И ты проиграл, у нас Docker используется для асинхронных задач (вычислительных на GPU) и постоянно работающих сервисов (ECS Fargate). Разделения на "бажных контейнеры" нет. S>Вообще непонятно для чего ты пришол доказывать что не верблюд, ибо ты и так не верблюд
Здравствуйте, Sheridan, Вы писали:
C>>Ну так как? Как будет выглядеть тестовый план, который найдёт указанную мной ошибку? S>Подклыдыванием фейкового цертбота например, который валится.
Именно между созданием и записью файла?
C>>>>У меня деплои проходят без моего вмешательства, под контролем автоматики. S>>>У тебя не деплои, у тебя просто файлики образов копируются. C>>Да, а что? S>Да то что ты путаешь деплой с копированием.
Тут есть целые дистрибутивы Линукса, которые только копированием работают...
C>>Мимо. Учим матчасть, в отличие от Ansible, который с песней будет пытаться запустить playbook при нулевом свободном месте, Docker будет автоматически очищать неиспользуемые образы и контейнерные ФС. S>Как у вас так получается — одновременно утверждать что у докера мусора нет и то, что всегда найдется мусор?
У Докера нет. Он хранит кэш слоёв (компонентов изображений), который автоматически чистится.
S>А если не будет места даже после очистки мусора? Ну, как себя поведет докер? Купит и добавит еще один винт в рейд?
А такого не может быть (если на сервере не порылся админ Sheridan).
Здравствуйте, Sheridan, Вы писали:
АБ>> — девопс или кто-то ещё приходит и говорит, что есть новая либа, переход на которую нам даст такие-то плюсы, S>Глупость. Очень большая глупость, которая всегда больно бьёт по яйцам в будущем. Если плавно не переходить с версии на версию, то когда это действительно станет нужно — у команды не будет ни опыта, ни времени.
типичный пример( правда из фронтенда ) :
либа MOBX
Browser support
MobX >=5 runs on any browser with ES6 proxy support. It will throw an error on startup on older environments such as IE11, Node.js <6 or React Native Android on old JavaScriptCore how-to-upgrade.
MobX 4 runs on any ES5 browser and will be actively maintained. The MobX 4 and 5 api's are the same and semantically can achieve the same, but MobX 4 has some limitations.
IE11 нужен клиенту, значит сидим на MobX 4. они хоть и обещают его своевременное обновление, но по факту это происходит через пень колоду
несколько раз было что minor версия приводила к падениям у клиента, причем трудно воспроизводимого. сейчас версия зафиксирована и никто без особых причин ее менять не будет
на бекенде куча подобного веселья была c PDF SDK от Datalogics
Здравствуйте, _ABC_, Вы писали:
S>>Лежит у клиента — большой косяк, сам понимаешь. _AB>
Именно так. Твой софт слёг на проде. рукилицо.
S>>Надо чтобы у клиента не лежало. А поэтому тестировать у себя на стейжах. _AB>Как я протестирую софт всех других вендоров? Не либу, входящую в мой софт, а софт самостоятельный других вендоров?
Зачем?
А. Теперь понятно почему нет времени ни на что. Ты тестируешь всё со всем. Ясен хрен что не остаётся времени на свой софт.
S>>Почему вы тогда волнуетесь? Пусть волнуется другой поствщик — проблема у него. _AB>Потому, что когда другой поставщик исправит свои косяки, мне нужно будет убедится, что ничего не сломано у меня.
Это должен делать заказчик. Сервера — его. Софт — он купил. Совместимость пусть проверяет сам. А потом вам в саппорт баги шлёт ежели что.
S>>Зачем её решаете вы? _AB>Потому, что клиенту пофиг, кто сломал, ему нужна моя работающая программа.
Твоя программа не работает из за того что ктото левый подгадил твоей программе, подложив говно мамонта вместо нормальной библиотеки, правильно? У вас что, настолько с бюджетом плохо что даже юриста знакомого нет?
Записывай, диктую; "Изучение проблемы выявило тот факт, что устаноленное рядом ПО в своём дистрибутиве имело устаревшую версию библиотеки Х, которую установило без соблюдения общепринятых правл в общесистемный каталог. Исправить проблему с нашим ПО можно, выполнив вот этот (ссылка) скрипт, который приведет наше ПО в рабочее состояние, но вероятно стороннее ПО перестанет работать. Возможные варианты решения проблемы: установить стороннее ПО на отдельный сервер, обратиться к поставщику сторонего ПО с просьбой актуализировать версию используемой библиотеки."
S>>Я? Я не пишу об этом сценарии. _AB> _AB>Кто писал с твоего аккаунта "allows the customer to save money by not allocating separate servers for our software"?
Ты контекст потерял? Это было про "актуализируйте либы и не надо будет плодить сервера/докеры только для того, чтобы иметь возможность две разные версии либы пользовать"
Впрочем ты прав, для этого не надо плодить ни сервера, ни докеры. Можно вполне штатно такую проблему разрулить.
S>>Английский поскипал, не силён в разговорном. _AB>Просто возразить тебе нечего, вот и прикрылся якобы непониманием написанного. Старый прием.
Нет. У меня нет практики в английском. Перепиши по русски и поговорим.
S>>От ветра — да. Пока ветер не превышает пределы прочности. S>>>>Сильный порыв ветра — и всё, нет теплицы. _AB>Ты там уже у себя в голове определись...
Может всётаки ты? Где тут противоречие?
Здравствуйте, mogadanez, Вы писали:
S>>Вы что, нетестированный на собственных полигонах софт сразу деплоите заказчикам? о0 M>Дерьмо случается M>хочешь сказать у тебя за всю карьеру не было ни одного факапа, падения всего и вся и тд?
Было. После одного такого факапа я теперь каждый раз проверяю — на том ли я серваке собрался чтото серьёзное запустить.
Но такие случаи единичны. Как правило совсем немного, штучно. И потом долго приходишь в себя, зато появляется полезная привычка.
F>В смысле кто против? Ты, не? Куче народу безуспешно доказываешь уже несколько дней, что докер на проде нельзя потому что лишняя шестеренка. Тебе реальные кейсы, а ты голую теорию в ответ.
Задайте кто-нибудь Шеридану простой вопрос. Все цитаты по Шеридану.
[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] (с кубернетесом) позволяет автоматические масштабирование и рестарт без скриптования и вмешательства девопса (мечта девопса)
Здравствуйте, Cyberax, Вы писали:
C>>>Мальчик, ты никогда не работал нигде серьёзно devops'ом. И даже не хочешь учиться. S>>А ты ходить уже научился? C>Да. А вы там ещё ползаете?
У нас тут гравитация слабая, поэтому скорее летаем.
C>>>Возможность отката нужна из-за того, что бывают ошибки, которые выявляются не сразу. Лично мной найденная, например: https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8189789 — проявляется под сильной нагрузкой, в виде попадающего в бесконечный цикл потока. Как результат, production-серверы постепенно умирают. S>>Я рад за вас. Но при чом тут откат, когда нужен хотфикс? C>Хотфикс чего? JDK? Это занимает несколько дней для проведения полного цикла тестов. В таких случаях единственное решение — это откат до предыдущего состояния. А затем в спокойной обстановке уже разбираться со стратегией исправления ошибки.
И в чём проблема? Откатили код обратно, сбросили изменения в отдельную ветку, собрали, задеплоили, тестируете. Багфикс пришёл — накатили фикс, накатили ветку. Тестируете.
Но нет, надо обязательно делать прыжок обратно всем продом на всех клиентах, ага.
C>>>Так же было ещё штук 10 подобных историй — third-party библиотека логгирования, которая утекала память, изменившийся порядок шифров в SSL, который ломал клиентский файрвол, ложное срабатывание антивируса на наш WebAssembly-код, и т.д. S>>Критические ошибки отлавливаются во время тестирования, некритические лечатся хотфиксами. C>Ну что могу сказать...
Просто перестань говорить. У тебя постоянно получается что всё критикал прилетает в заказчика. что сразу многое говорит о ваших производственных процессах.
C>>>Естественно, тестируем. И имеем "план Б" на случай непредвиденной ситуации — у нас стоят тревожные сигналы, которые при любой аномалии просто откатят код до предыдущей версии. S>>Ты не до конца ответил на вопрос. C>У нас тестируется весь UI с помощью роботов, API с помощью интеграционных тестов, 85% кода сервисов покрыто unit-тестами. Вычислительные задачи валидируются на массиве тестовых данных и на задачах, которые запускались последние 2 недели. Помимо простого сравнения, используется AI для поиска аномалий (странное потребление памяти, увеличение времени работы и т.п.).
Отлично. Почему тогда у вас так много инцидентов на проде заказчиков?
C>Каждые 6 месяцев мы отсылаем отчёты в правительство нескольких штатов для о результатах мониторинга реальных систем, построенных по нашим планам. Это нужно для поддержки сертифицированного статуса.
Отлично. Почему тогда огромная проблема актуализировать используемые библиотеки?
S>>>>У проектов, которым важно качество всегда есть пул виртуалок с различными конфигурациями. В том числе и со снапшотами. C>>>Ой, уже snapshot'ы появились. А кто ими управляет, как происходит развёртывание на кластер? Всё те же 2 строчки в Ansible, да? S>>Да. C>Не верю.
Не верь.
C>>>Кроме того, как я уже показал, ошибка может возникнуть в любой момент в production. Она не детерминированная. S>>Ну я так понимаю что ты хочешь спросить смогу ли я перехватить неперехватываемую ошибку, которая никогда категорически не перехватывается на тестах и обязательно рушит прод в ноль. C>Именно так, да. Потому, что я так могу делать.
Значит и я могу.
C>Да-да, Докер позволяет успешно обрабатывать неожиданные ошибки.
Приводящие к краху процесса? Системд тоже так умеет.
C>>>Ок, принимается. И ты проиграл, у нас Docker используется для асинхронных задач (вычислительных на GPU) и постоянно работающих сервисов (ECS Fargate). Разделения на "бажных контейнеры" нет. S>>Вообще непонятно для чего ты пришол доказывать что не верблюд, ибо ты и так не верблюд
. C>Где мои $2000? Можно на PayPal: alex.besogonov@gmail.com
Я не проиграл. Ты пропустил вспышку слева и пришёл мне доказывать что докер категорически нужен там где я изначально писал допустимость его использования.
Здравствуйте, Cyberax, Вы писали:
C>>>Ну так как? Как будет выглядеть тестовый план, который найдёт указанную мной ошибку? S>>Подклыдыванием фейкового цертбота например, который валится. C>Именно между созданием и записью файла?
А что изменится? Ну или будет скрипт который создаёт пустой файл и валится. Можно даже разбавить валидный церт мусором и не свалиться. Да что угодно.
C>>>>>У меня деплои проходят без моего вмешательства, под контролем автоматики. S>>>>У тебя не деплои, у тебя просто файлики образов копируются. C>>>Да, а что? S>>Да то что ты путаешь деплой с копированием. C>Тут есть целые дистрибутивы Линукса, которые только копированием работают...
я в курсе что dd чудеса творит, да.
C>>>Мимо. Учим матчасть, в отличие от Ansible, который с песней будет пытаться запустить playbook при нулевом свободном месте, Docker будет автоматически очищать неиспользуемые образы и контейнерные ФС. S>>Как у вас так получается — одновременно утверждать что у докера мусора нет и то, что всегда найдется мусор? C>У Докера нет. Он хранит кэш слоёв (компонентов изображений), который автоматически чистится.
Это и есть мусор.
S>>А если не будет места даже после очистки мусора? Ну, как себя поведет докер? Купит и добавит еще один винт в рейд? C>А такого не может быть (если на сервере не порылся админ Sheridan).
Всмысле? Образ весит Х+1 мегабайт, очистилось Х мегабайт. Места нет.
Здравствуйте, mogadanez, Вы писали:
M>IE11 нужен клиенту, значит сидим на MobX 4. они хоть и обещают его своевременное обновление, но по факту это происходит через пень колоду M>несколько раз было что minor версия приводила к падениям у клиента, причем трудно воспроизводимого. сейчас версия зафиксирована и никто без особых причин ее менять не будет
А что, обязательно нужен фанатизм? У вас вполне нормальный и адекватный повод не обновляться. Как только пофиксят — обновитесь. Я топлю не за фанатизм, а за поддержания актуальных версий либ. Чтобы говна мамонта на серверах не было.
Здравствуйте, mogadanez, Вы писали:
S>>Никак. Деплой прерван, сервисы не запущены. M>сервисы запускаются по очереди? может прерваться когда один запущен а другие еще нет?
Если это важно, то описываем это прямо в зависимостях юнитов системд.
Здравствуйте, Sheridan, Вы писали:
S>Твоя программа не работает из за того что ктото левый подгадил твоей программе, подложив говно мамонта вместо нормальной библиотеки, правильно? У вас что, настолько с бюджетом плохо что даже юриста знакомого нет? S>Записывай, диктую; "Изучение проблемы выявило тот факт, что устаноленное рядом ПО в своём дистрибутиве имело устаревшую версию библиотеки Х, которую установило без соблюдения общепринятых правл в общесистемный каталог*. Исправить проблему с нашим ПО можно, выполнив вот этот (ссылка) скрипт, который приведет наше ПО в рабочее состояние, но вероятно стороннее ПО перестанет работать. Возможные варианты решения проблемы: установить стороннее ПО на отдельный сервер, обратиться к поставщику сторонего ПО с просьбой актуализировать версию используемой библиотеки."
"Артель напрасный труд".
Можно распихать всё по контйнерам и вообще не сталкиваться с проблемой, что кто-то обновил библиотеки, что привело к конфликтам.
А можно обойтись без контейнеров и сталкиваться с описанными проблемами, тратя на решение доп. ресурсы.
П.С. А чем здесь юрист поможет?
— "общепринятых правл в общесистемный каталог" каких таких правил? Субподрядчик с этими правилами в установленном порядке ознакомлен?
— у него вообще в ТЗ и сопроводительных документах версии либ прописаны?
В этом случае субподрядчик берёт своего юриста, который составляет точно такое же письмо.
Результат: задействованно несколько дополнительных людей, потрачена куча времени, проблема не решена.
Здравствуйте, Klikujiskaaan, Вы писали:
K>Здравствуйте, Farsight, Вы писали:
F>>В смысле кто против? Ты, не? Куче народу безуспешно доказываешь уже несколько дней, что докер на проде нельзя потому что лишняя шестеренка. Тебе реальные кейсы, а ты голую теорию в ответ.
K>Не знаю, зачем вы две недели к ряду пытаетесь что-то доказать человеку, у которого отсутствует какое-либо критическое мышление. K>Он все свое существование на этом форуме был местной very special snowflake, проще научить свинью играть лунную сонату, нежели что-то втолковать шеридану.
Понятное дело, что самозатупляться никто не собирается. Но паттерны, ответы, реакция, рассуждения
Чтобы самому не походить в этих тапках. Когда растешь-растешь, потом попадаешь в зону комфорта и отсутствия конкуренции. И, незаметно для себя, превращаешься в самоуверенного самодура. Сравнивая и сопоставляя, можно будет заметить у себя опасные признаки.
Это дополнительный стимулирующий фактор. Например, менять ли хорошее на другое непонятное (регионы -> технологический центр). Как фактор развития, не связанный с деньгами.
Это реальный сценарий, который может случится незаметно с любым из нас. До Ансибла же Шеридан он дорос.
Хотелось бы помереть веселым стариканом с живым умом и не утерянным интересом к жизни. Это реальное качество жизни, которое можно утратить и состариться умом. Когда смотришь на престарелых родителей, понимаешь, что ты не теряешь их внезапно. Понимаешь, что теряешь их постепенно, раньше, вчера, сегодня, завтра- потихоньку. Это важнейшие темы для любого человека.
Здравствуйте, Sheridan, Вы писали:
S>Именно так. Твой софт слёг на проде. рукилицо.
Не прикидывайся идиотом настолько хорошо. Люди же верят...
Слёг мой софт по причине того, что его обрушил чужой софт, над которым у меня контроля нет.
S>А. Теперь понятно почему нет времени ни на что. Ты тестируешь всё со всем. Ясен хрен что не остаётся времени на свой софт.
Продолжай юродствовать, продолжай убеждать людей в том, что ты идиот. Ты достигаешь успеха.
S>Это должен делать заказчик. Сервера — его. Софт — он купил.
Поддержку он тоже купил.
S>Совместимость пусть проверяет сам. А потом вам в саппорт баги шлёт ежели что.
Ну, прислал он в саппорт запрос — "у нас тут кое-что упало и из-за этого ваш софт не работает, у нас есть договор на поддержку, помогите нам, пожалуйста". Легче стало?
S>Записывай, диктую; "Изучение проблемы выявило тот факт, что устаноленное рядом ПО в своём дистрибутиве имело устаревшую версию библиотеки Х, которую установило без соблюдения общепринятых правл в общесистемный каталог. Исправить проблему с нашим ПО можно, выполнив вот этот (ссылка) скрипт, который приведет наше ПО в рабочее состояние, но вероятно стороннее ПО перестанет работать. Возможные варианты решения проблемы: установить стороннее ПО на отдельный сервер, обратиться к поставщику сторонего ПО с просьбой актуализировать версию используемой библиотеки."
А как же "which allows the customer to save money by not allocating separate servers for our software"?
В трубу идет... Ну, никто не сомневался, собственно. Офигеть какая гибкость...
Впрочем, я тебе тоже напишу ответ клиента на это — "Изучение рынка выявило тот факт, что ваши конкуренты умеют изолировать свой софт, а вы нет. С учетом потерь от простоя, нам дешевле заплатить вам неустойку, разорвать контракт на поддержку и перейти к конкурентам".
S>Впрочем ты прав, для этого не надо плодить ни сервера, ни докеры. Можно вполне штатно такую проблему разрулить.
Ага, разведя ПО по разным серверам, как ты предложил выше...
S>Нет. У меня нет практики в английском. Перепиши по русски и поговорим.
Английский — основа для айтишника. Как ты работаешь, если ты понять простые тексты не можешь?
S>Может всётаки ты? Где тут противоречие?
Сильный ветер с куда большей вероятностью погубит твои морозоустойчивые огурцы, нежели те, что защищены теплицей.
Противоречие же в том, что ты сначала утверждал обратное.
Здравствуйте, Sheridan, Вы писали:
S>>>А ты ходить уже научился? C>>Да. А вы там ещё ползаете? S>У нас тут гравитация слабая, поэтому скорее летаем.
Это не гравитация слабая, это вы прямо в дерьме плаваете и дышите им.
C>>Хотфикс чего? JDK? Это занимает несколько дней для проведения полного цикла тестов. В таких случаях единственное решение — это откат до предыдущего состояния. А затем в спокойной обстановке уже разбираться со стратегией исправления ошибки. S>И в чём проблема? Откатили код обратно, сбросили изменения в отдельную ветку, собрали, задеплоили, тестируете. Багфикс пришёл — накатили фикс, накатили ветку. Тестируете.
Ну вот и как откатывать код? Обычные пакетные репозитории Линукса умеют только вперёд накатывать.
S>Но нет, надо обязательно делать прыжок обратно всем продом на всех клиентах, ага.
Именно. Такая возможность должна быть.
S>Просто перестань говорить. У тебя постоянно получается что всё критикал прилетает в заказчика. что сразу многое говорит о ваших производственных процессах.
Критические ошибки — они на то и критические, что появляются у заказчика. Всё что до заказчика не доходит — это всё не критическое по определению. Duh.
C>>У нас тестируется весь UI с помощью роботов, API с помощью интеграционных тестов, 85% кода сервисов покрыто unit-тестами. Вычислительные задачи валидируются на массиве тестовых данных и на задачах, которые запускались последние 2 недели. Помимо простого сравнения, используется AI для поиска аномалий (странное потребление памяти, увеличение времени работы и т.п.). S>Отлично. Почему тогда у вас так много инцидентов на проде заказчиков?
Потому, что реальность — она такая. В любой сложной системе будут непредвиденные взаимодействия и ошибки. Устранить это никак нельзя, но можно смягчить последствия.
C>>Каждые 6 месяцев мы отсылаем отчёты в правительство нескольких штатов для о результатах мониторинга реальных систем, построенных по нашим планам. Это нужно для поддержки сертифицированного статуса. S>Отлично. Почему тогда огромная проблема актуализировать используемые библиотеки?
Мы это делаем, обычно раз в несколько месяцев отдельным deploy'ем (за исключением дыр в безопасности). Как и в любой другой системе — гораздо проще менять только один параметр за раз, особенно если нет ограничений по времени.
S>>>Ну я так понимаю что ты хочешь спросить смогу ли я перехватить неперехватываемую ошибку, которая никогда категорически не перехватывается на тестах и обязательно рушит прод в ноль. C>>Именно так, да. Потому, что я так могу делать. S>Значит и я могу.
Вряд ли.
C>>Да-да, Докер позволяет успешно обрабатывать неожиданные ошибки. S>Приводящие к краху процесса? Системд тоже так умеет.
Systemd умеет многое из того, что делает Docker, так как они построены на тех же технологиях. Но он не умеет, например, бороться с переполнением диска и не умеет сам по себе запускать процессы в своих сетевых namespace'ах.
C>>Где мои $2000? Можно на PayPal: alex.besogonov@gmail.com S>Я не проиграл. Ты пропустил вспышку слева и пришёл мне доказывать что докер категорически нужен там где я изначально писал допустимость его использования.
Где бабки-то?
Здравствуйте, Sheridan, Вы писали:
C>>Именно между созданием и записью файла? S>А что изменится? Ну или будет скрипт который создаёт пустой файл и валится. Можно даже разбавить валидный церт мусором и не свалиться. Да что угодно.
Нет. Ты не понимаешь вообще что тебе говорят.
Для обнаружения этой ошибки нужно, чтобы тестовый протокол включал прерывание всех утилит в промежутке между каждым системным вызовом и проверки работоспособности системы после этого. Я знаю ровно один пакет, который тестируется таким образом (это sqlite).
C>>Тут есть целые дистрибутивы Линукса, которые только копированием работают... S>я в курсе что dd чудеса творит, да.
Я про https://michael.stapelberg.ch/posts/2019-08-17-introducing-distri/
C>>У Докера нет. Он хранит кэш слоёв (компонентов изображений), который автоматически чистится. S>Это и есть мусор.
Нет.
S>>>А если не будет места даже после очистки мусора? Ну, как себя поведет докер? Купит и добавит еще один винт в рейд? C>>А такого не может быть (если на сервере не порылся админ Sheridan). S>Всмысле? Образ весит Х+1 мегабайт, очистилось Х мегабайт. Места нет.
Так не может быть, если только образ не больше всего диска. Иначе Docker просто удалит неиспользуемые слои, пока не наберётся достаточно места.
Здравствуйте, Sheridan, Вы писали:
S>>Не надо париться про то, какие там версии каких библиотек стоят и кто там с кем будет конфликтовать. S>Абсолютно верно, на стадии деплоя не надо. Надо на стадии разработки.
На стадии разработки подготовка софта к тому, чтобы он работал в достаточно любом окружении стоит очень больших денег.
Любой разработчик, кто распространял свой софт более чем одному клиенту об этом осведомлён.
Да, многие годы считалось, что "надо просто сильнее бить разработчиков". Потом была идея что "распространение софта — дело маинтейнеров дистрибутива", а разработчик должен выкласть только исходники.
Всё это в полночь оказалось тыквой — прекрасно работает только в воображении идеалистов.
На практике даже на уровне исходников сделать софт совместимым одновременно с тремя версиями LibSSL — уже тяжело. А маинтейнер дистрибутива выступает хреновым посредником между пользователем и разработчиком, особенно если это касается заказного софта.
Докер вовремя сообразил, что контейнеры, которые изначально позиционировались как легковесные VM, можно довести до логического завершения — "каждому приложению по машине".
S>Не надо, абсолютно верно. После поднятия хоста оно само поднимется.
Ну что за бред. Это даже не детский сад. А если хост вообще не поднимется? Хорошо, если на нём какой-то кратковременный сбой. А если там пожар в DC и вся стойка тово?
S>>Не надо париться с тем, позаботился ли разработчик о том, чтобы на одном хосте могли параллельно работать две версии рендерера, или как обычно "вместе могут работать 3 и 4, и 4 и 2, но не 3 и 2" S>Отучать разрабов от лени и учить читать ТЗ.
Шеридан, разработчиков в мире — миллионы. S>Ну и учиться ставить задачи конечно жэ.
Иди, пиши ТЗ постгресу, апачу, монгодб, и прочим. У тебя реально мышление технички — тебе все уже должны, а ты даже научиться пользоваться контейнерами в стиле "воткнул — заработало" не хочешь.
S>>Безо всех этих "да я щас там заднюю панель сниму, паяльничком чик-чик, и в понедельник уже заработает". S>Странное у тебя представление об ансибле, очень странное.
Ровно как ты рассказал. У тебя на каждый вопрос ответом идёт "да я там плейбук сделаю, если понадобится".
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, XOOIOOX, Вы писали: XOO>Увлекательнейшее чтиво. "Спасение рядового Шеридана".
Не, просто, как известно, всякого человека в других бесят ровно те недостатки, которые есть у него самого.
Так что все эти споры — они не с Шериданом. Тут каждый воюет с внутренним шериданом, который есть у каждого
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Докер вовремя сообразил, что контейнеры, которые изначально позиционировались как легковесные VM, можно довести до логического завершения — "каждому приложению по машине".
Там ещё круче история была — Докер изначально был чисто внутренним инструментом, который выложили в OpenSource, в качестве рекламы компании. А он взял и выстрелил, так как решает практические задачи, которые случаются у всех.
S>Но нет, надо обязательно делать прыжок обратно всем продом на всех клиентах, ага.
Когда каждая минута простоя — это потеря денег, клиентов и репутации, то да, прыжок обратно всем продом на всех клиентах. Людям, которые никогда ни за что не были ответственны и ничего не знают за пределами тепличных условий это неизвестно, да. Людям, у которых мир ограничивается «обскриптуем со всех сторон» так же неизвестно, как можно откатить весь прод.
Здравствуйте, Sheridan, Вы писали:
S> AB>Несовместимость API, разное поведение в рамках одного API, (не)поддержка TLSv1.3, ряд CVE, шаманские танцы с отключением compression/SSLv3, история sha1/sha256, выход BoringSSL/LibreSSL, etc. S> Я слышу это только от вас. На практике никогда не встречался, хотя много где использовалосью
Ну... Печально, конечно, что это все прошло мимо человека, называющего себя системным администратором. Вдвойне печально, что в подтреде про безопасность ты категорически настаивал на безопасности личной домашней системы — дайджесты по базовые системным компонентам ты по долгу службы должен читать хотя бы по диагонали как брокер биржевую сводку.
S> S>> А берутся во внимание только трудозатраты программистов? Или всётаки вы командой работаете? S> AB>Берутся во внимание все затраты, риски и т.д. S> Ну тогда вы должны взять во внимание и трудозатраты девапса/админа на танцы вокруг окаменелостей.
Вне сомнения они так же учитываются. Что часто приводит к решению вида "Ничего не делаем, т.к. окаменелость не приносит столько пользы, сколько на ее обновление будет затрачено ресурсов — лучше займемся (все вместе) чем-то более продуктивным."
В сутках всего 24 часа. У админа есть семья, дети, ипотека, хобби и т.д. и т.п. Занимать его никому не нужной фигней совершенно непродуктивно с любой точки зрения.
S> AB>Из чего ты делаешь такой вывод?! Админу (нормальному) новые проблемы в проде совершенно не нужны, он не хочет просыпаться ночью 1-го января и чинить какой-нибудь внезапный пожар, он точно так же будет вовлечен в процесс принятия решения и рассматривать плюсы-минусы через призму своей области ответственности. S> И на этом этапе нормальный девапс/админ будет настаивать на переходе либ с окаменелостей на текущую версию.
Нормальный будет взвешивать плюсы и минусы подобного перехода с учетом мнения коллег. И если текущая ситуация стабильна, а профита от обновления нет, то и ну его нафиг это обновление ради обновления — работает, не трогай.
S> AB>Другие пути есть, но они на сегодняшний день являются слабо/неэффективными в промышленных масштабах. Ты можешь обрабатывать грядку мотыгой — никто слова не скажет, но в промышленных масштабах люди пользуются специализированной агротехникой и на предложение обработать поле мотыгой пытаются тебе объяснить, что ты неправ. S> Вот как раз ансибл это и есть комбайн, способный с нуля обрабатывать поля. А докер в этой аналогии — теплица, где каждый сам под себя грядки копает.
Ну если продолжать в этом же ключе, то пока ты ансиблом только начинаешь готовить поле, другие уже начинают растить урожай. Очевидно, что у них получится быстрее и с меньшими затратами. Паритет мотыга-комбайн не меняется.
S> S>> Я понимаю зачем докер. Я не понимаю почему только докер, исключительно докер, докер докер и кубернетес пророк его. S> AB>Ты не понимаешь зачем нужна изоляция и/или не принимаешь ее как технологию производства, а не зачем докер. S> Я не понимаю изоляцию ради изоляции.
Нет изоляции ради изоляции. Есть best practice, которые в большинстве случаев (почти всегда) экономят ресурсы на временном отрезке жизни продукта. При этом они сформулированы не просто в стиле "верь мне, я знаю", а под ними есть вполне рациональная база множество раз здесь описанная. Не пользоваться этим знанием — личный выбор. Отвергать его без настолько же рациональных контр-аргументов — невежество.
S> S>> Я понимаю почему версия библиотеки в проекте может отличаться от актуальной. Я не понимаю почему как только речь о актуализации заходит — начинается выдумывание 1000 и 1 способа почему это не нужно делать. S> AB>Потому что ты актуализацию делаешь самоцелью в то время как на практике эта операция относительно редкая (и обычно недешевая). S> Я не делаю её самоцелью. Это реакция на ваши утверждения что менять ничего не надо.
Не было подобных утверждений. Все утверждения были — не меняем без перевешивания плюсов над минусами vs твое меняем всегда.
Здравствуйте, Sinclair, Вы писали:
S>>Не надо, абсолютно верно. После поднятия хоста оно само поднимется. S>Ну что за бред. Это даже не детский сад. А если хост вообще не поднимется? Хорошо, если на нём какой-то кратковременный сбой. А если там пожар в DC и вся стойка тово?
это навело еще на аргумент — универсализация.
с докером плюс минус одинаково запускать что на своих серверах что в AWS что в Azure
S>Докер вовремя сообразил, что контейнеры, которые изначально позиционировались как легковесные VM, можно довести до логического завершения — "каждому приложению по машине".
Справедливости ради, в Microsoft после DLL hell тоже кое-что поняли, и, как бы это помягче, сделали свой вариант. Для .НЕТ.
Здравствуйте, Sheridan, Вы писали:
SD>>Бизнес — это про деньги, а не про ответственное отношение. S>Кек, у меня многие вопросы исчезли. Вот оно что оказывается. Тяп-ляп-лишь-бы-работало
Ты, как обычно, просто не понимаешь о чем речь. Когда у тебя в кластере, к примеру, 100К машин, обязательно что то будет постоянно отказывать, хоть порви свою задницу на британский флаг. И с этим надо уметь жить, а не надеятся что у тебя сбоев не будет потому что ты такой красивый.
Здравствуйте, Ночной Смотрящий, Вы писали:
SD>>>Бизнес — это про деньги, а не про ответственное отношение. S>>Кек, у меня многие вопросы исчезли. Вот оно что оказывается. Тяп-ляп-лишь-бы-работало
НС>Ты, как обычно, просто не понимаешь о чем речь. Когда у тебя в кластере, к примеру, 100К машин, обязательно что то будет постоянно отказывать, хоть порви свою задницу на британский флаг. И с этим надо уметь жить, а не надеятся что у тебя сбоев не будет потому что ты такой красивый.
Сбои будут, да. На такой куче машин я почти уверен что у тебя даже винты будут лететь со скоростью 1-3 в день. Я в курсе.
Но тут не про это. Тут про то что бабло важнее ответственного отношения. Почитай то что я процитировал.
Здравствуйте, Sheridan, Вы писали:
S>Но тут не про это.
Тут именно про это.
S> Тут про то что бабло важнее ответственного отношения.
Что за неведомый зверь — "ответственное отношение" и как его измерить?
Есть вполне конкретная штука — SLA. Каждая чиселка в ней — вполне конкретные и ощутимые бабки. И бизнес выбирает ровно тот уровень, за который он готов платить. И если ты ему предложишь уровень, за который он не хочет платить — ты пойдешь в лес. Никакого "ответственного отношения" же в этом уравнении нет.
Здравствуйте, Ночной Смотрящий, Вы писали:
S>> Тут про то что бабло важнее ответственного отношения.
НС>Что за неведомый зверь — "ответственное отношение" и как его измерить? НС>Есть вполне конкретная штука — SLA. Каждая чиселка в ней — вполне конкретные и ощутимые бабки. И бизнес выбирает ровно тот уровень, за который он готов платить. И если ты ему предложишь уровень, за который он не хочет платить — ты пойдешь в лес. Никакого "ответственного отношения" же в этом уравнении нет.
Здравствуйте, Ночной Смотрящий, Вы писали:
S>>А никто и не агитирует за фанатизм. НС>Это вот твое "ответственное отношение" вопреки потребностям бизнеса — самый настоящий фанатизм и есть.
Вопреки??? С какого это лешего — вопреки? Я вам тут талдоню что помимо программеров в команду нужны админы, чтобы разгрузить программеров от не-их работы (чтобы они больше фич релизили), чтобы помогать программерам деплоить/пакетировать их продукт. В команду, комораде. Не руководителем, не коммандиром, не рабом. В команду, что значит сообща работать.
И ВНЕЗАПНО я чтототам против бизнеса.
Здравствуйте, Sheridan, Вы писали:
S>>>А никто и не агитирует за фанатизм. НС>>Это вот твое "ответственное отношение" вопреки потребностям бизнеса — самый настоящий фанатизм и есть. S>Вопреки???
Вопреки.
S>С какого это лешего — вопреки?
С того что ты ополчился против того чтобы следовать требованиям бизнеса и в альтернативу им вытавляешь непонятное "ответственное отношение".
S> Я вам тут талдоню что помимо программеров в команду нужны админы, чтобы разгрузить программеров от не-их работы (чтобы они больше фич релизили)
Нет, ты тут рассказывал про ответственное отношение, а не про админов. Завилял, да еще и на редкость топорно.
S>И ВНЕЗАПНО я чтототам против бизнеса.
А это что, по твоему?
Но тут не про это. Тут про то что бабло важнее ответственного отношения.
Здравствуйте, Ночной Смотрящий, Вы писали:
S>>>>А никто и не агитирует за фанатизм. НС>>>Это вот твое "ответственное отношение" вопреки потребностям бизнеса — самый настоящий фанатизм и есть. S>>Вопреки??? НС>Вопреки.
S>>С какого это лешего — вопреки? НС>С того что ты ополчился против того чтобы следовать требованиям бизнеса и в альтернативу им вытавляешь непонятное "ответственное отношение".
Требования бизнеса — "пишите хрень, лишь бы абы как работало и нам срать сколько боли будет у юзера при установке наших поделий"?
Хреновый бизнес. Никуда не годный. Позволит сорвать куш на быстром старте такой подход, но постоянно его использовать — глупо.
S>> Я вам тут талдоню что помимо программеров в команду нужны админы, чтобы разгрузить программеров от не-их работы (чтобы они больше фич релизили) НС>Нет, ты тут рассказывал про ответственное отношение, а не про админов. Завилял, да еще и на редкость топорно.
А это и есть про ответственное отношение. Каждый специалист занимается своим делом, а не "а, васян линупс настроит, он его два года назад с лайвсиди смотрел".
S>>И ВНЕЗАПНО я чтототам против бизнеса. НС>А это что, по твоему? НС>
НС>Но тут не про это. Тут про то что бабло важнее ответственного отношения.
Здравствуйте, Sheridan, Вы писали:
НС>>С того что ты ополчился против того чтобы следовать требованиям бизнеса и в альтернативу им вытавляешь непонятное "ответственное отношение". S>Требования бизнеса — "пишите хрень, лишь бы абы как работало и нам срать сколько боли будет у юзера при установке наших поделий"?
Может быть и такое.
S>Хреновый бизнес. Никуда не годный.
Хреновый бизнес это называть бизнес заказчиков хреновым. Смысл коммерческой разработки в удовлетворении требований заказчика, а не в почесывании своих мудей.
НС>>А это что, по твоему? НС>>
НС>>Но тут не про это. Тут про то что бабло важнее ответственного отношения.
Здравствуйте, Ops, Вы писали:
B>>На Винде он как гражданин второго класса, поддержка остаточная, то тут отвалится, то там. Ops>Вот это и останавливает, я помучился и отказался, проще в виртуалке. Сейчас вот может заработает получше на wsl2, будет время — посмотрю.
Для винды оно и без WSL 2 умеет в windows containers
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>>>Бизнесу важнее бабло. Ты против. Сложи 2 и 2. S>>Бабло на говне можно заработать один раз. НС>
Да хоть обфейспальмся, продать гавно можно только один раз. Потом уже будут знать. И всем будет, кстати, насрать что теперь это не говно.
Здравствуйте, Sheridan, Вы писали:
НС>> S>Да хоть обфейспальмся, продать гавно можно только один раз.
Ты, как обычно, демонстрируешь воинствующий дилетантизм и непонимание того, как создаются современные продукты. Твое "гавно" нормальные люди называют MVP и это важная стадия, которую пропускать не рекомендуется. Потому что, еще раз тебе повторю, потребности бизнеса намного важнее почесывания мудей.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>>> S>>Да хоть обфейспальмся, продать гавно можно только один раз.
НС> MVP и это важная стадия, которую пропускать не рекомендуется.
То что не рекомендуется не есть говно не делает говно не говном.
mvp это когда "Пилим хоть что нибудь в сторону идеи а потом придумаем как именно это использовать!!!"? Старт проекта без уверенности будет ли это нравиться/удобно пользователям — такая себе затея.
Здравствуйте, User239, Вы писали:
U>Допусти надо срочно сделать какое-то небольшое изменение, протестировать и выкатить его. В случае с монолитом единственный вариант собирать, тестировать и деплоить всё приложение. С отдельным сервисом, если изменение затрагивает только этот сервис, может оказаться быстрее
Тестировать микросервис без реального окружения и не тестировать весь комплекс — отличный способ пройтись по граблям.
Здравствуйте, SkyDance, Вы писали:
SD>Иными словами, кубернетес нужно вкрячивать только если он реально очень нужен! А не потому что "я научился с ним работать, теперь везде его запихаю".
А еще бывает так:
Заказчик: ваш продукт можно развернуть на моей инфраструктуре с Кубером?
Разработчик: Нет, нам кубер не очень нужен.
Заказчик: Идите в жопу
Здравствуйте, Sheridan, Вы писали:
S>mvp это когда "Пилим хоть что нибудь в сторону идеи а потом придумаем как именно это использовать!!!"?
Нет. Сходи по ссылке и прочти что там написано. Причем не только первую фразу.
S>Старт проекта без уверенности будет ли это нравиться/удобно пользователям — такая себе затея.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>А еще бывает так: НС>
НС>Заказчик: ваш продукт можно развернуть на моей инфраструктуре с Кубером?
НС>Разработчик: Нет, нам кубер не очень нужен.
НС>Заказчик: Идите в жопу
Менеджер уволен.
Правильный диалог:
Заказчик: ваш продукт можно развернуть на моей инфраструктуре с Кубером?
Разработчик: Сделаем, но не так быстро как без кубера — нам надо будет потестировать на окружении, похожем на ваше.
Здравствуйте, Sheridan, Вы писали:
S>Менеджер уволен.
Какой такой менеджер?
S>Правильный диалог: S>[q] S>Заказчик: ваш продукт можно развернуть на моей инфраструктуре с Кубером? S>Разработчик: Сделаем, но не так быстро как без кубера
Заказчик: идите в жопу, у конкурента уже все есть.
Здравствуйте, Sheridan, Вы писали:
S>Здравствуйте, Ночной Смотрящий, Вы писали:
S>
S>Заказчик: ваш продукт можно развернуть на моей инфраструктуре с Кубером?
S>Разработчик: Сделаем, но не так быстро как без кубера — нам надо будет потестировать на окружении, похожем на ваше.
В твоем случае конфликт случится на этапе, когда соберется VP и человек, работающий с клиентами.
И будут обсуждать, в свете современных реалий, можно ли еще куда нибудь приспособить этого чудного админа. Или гнать, чтобы атмосферу не портил.
А атмосфера будет портится, когда придет молодой студент и будет справедливо возмущаться по поводу отсталого админа. Ну а, вышеприведенный диалог придаст, импульс в направлении "Шеридан вовну"
Здравствуйте, Sheridan, Вы писали:
S>С ансиблом практически то же самое. Только сразу на прод. Всё, дальше это работает там до следующего поворота этого колеса.
Здравствуйте, Ночной Смотрящий, Вы писали:
S>>Менеджер уволен. НС>Какой такой менеджер?
Который с заказчиками общается. "По продажам".
S>>Правильный диалог: S>>[q] S>>Заказчик: ваш продукт можно развернуть на моей инфраструктуре с Кубером? S>>Разработчик: Сделаем, но не так быстро как без кубера НС>Заказчик: идите в жопу, у конкурента уже все есть.
Ну идёте в жопу, равно как и при ситуации когда заказчику надо без докеров, а у вас только докеры. Ты сейчас конечно скажешь что заказчику нужно всегда докеры, на что я тебе отвечу — я много с кем работал и докеры у них использовались для разработки но на прод заказчики их не хотели.
Здравствуйте, Sheridan, Вы писали:
НС>>Заказчик: идите в жопу, у конкурента уже все есть. S>Ну идёте в жопу, равно как и при ситуации когда заказчику надо без докеров
Здравствуйте, Vetal_ca, Вы писали:
>>> разговор про общения разработчиков с заказчиками
V_>И будут обсуждать, в свете современных реалий, можно ли еще куда нибудь приспособить этого чудного админа. Или гнать, чтобы атмосферу не портил.
Да я понял что тебе какойто админ дорогу крепко перешёл, травму на всю жизнь оставил. Сочувствую.
Здравствуйте, Ночной Смотрящий, Вы писали:
S>>Ну идёте в жопу, равно как и при ситуации когда заказчику надо без докеров НС>Практика показывает, что таковых практически нет.
Совершенно очевидно что у нас с тобой разная практика.
Здравствуйте, Ночной Смотрящий, Вы писали:
S>>С ансиблом практически то же самое. Только сразу на прод. Всё, дальше это работает там до следующего поворота этого колеса. НС>Автоскейлинг? Не, не слышал. И снова я тебя отправлю почитать откуда это всё началось.
Здравствуйте, Sheridan, Вы писали:
S>Здравствуйте, Vetal_ca, Вы писали:
S>Да я понял что тебе какойто админ дорогу крепко перешёл, травму на всю жизнь оставил. Сочувствую.
Я тебе даже ссылки кинул, что можно глянуть не отходя далеко от твоего Ансибла.
Подрастешь, поймешь, что максимальная жестокость это потакать человеку в его деградации. Чтобы выкинуть на мороз и поржать в итоге когда способность двигаться совсем утрачена.
Здравствуйте, Ночной Смотрящий, Вы писали:
S>>Да я понял что тебе какойто админ дорогу крепко перешёл, травму на всю жизнь оставил. Сочувствую. НС>Пока больше похоже на твои травмы из программерских потуг. Я до сих пор без смеха не могу вспоминать твое участие в RSDN@Home.
У меня нет никаких травм. Сейчас вполне себе работаю с программерами, помогаю им.
Здравствуйте, Vetal_ca, Вы писали:
S>>Да я понял что тебе какойто админ дорогу крепко перешёл, травму на всю жизнь оставил. Сочувствую. V_>Я тебе даже ссылки кинул, что можно глянуть не отходя далеко от твоего Ансибла.
По ссылке было про то как тебе админ дорогу перешол? о0
V_>Подрастешь, поймешь, что максимальная жестокость это потакать человеку в его деградации. Чтобы выкинуть на мороз и поржать в итоге когда способность двигаться совсем утрачена.
Вот я и пытаюсь вас в тепло затащить.
Здравствуйте, Sheridan, Вы писали:
C>>Нет. Так делать нельзя, так как необходимость делать откат — это даже не обсуждается. S>Бредовый бред бредящего бредуна. Даже читать такое противно и сразу появляется желание уйти из такой команды несмотря на то что я (к счастью) не в ней.
Слышал про SOC сертификацию? Там возможность откатов при обновлении — одно из явных требований политики change management. А без SOC сертификации твой софт не пустят ни в одну приличную западную контору. Такой вот бредовый бред.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Слышал про SOC сертификацию? Там возможность откатов при обновлении — одно из явных требований политики change management. А без SOC сертификации твой софт не пустят ни в одну приличную западную контору. Такой вот бредовый бред.
И категорически совершенно невозможно реализовать откат без докера. дадада.
Здравствуйте, Sheridan, Вы писали:
НС>>Слышал про SOC сертификацию? Там возможность откатов при обновлении — одно из явных требований политики change management. А без SOC сертификации твой софт не пустят ни в одну приличную западную контору. Такой вот бредовый бред. S>И категорически совершенно невозможно реализовать откат без докера. дадада.
Возможно, но сложее.
Однако, опять топорная попытка сменить тему. Возможность отката уже не бредовый бред, да?
S>По ссылке было про то как тебе админ дорогу перешол? о0
Н-да, самый тяжелый случай. Сколько тебе до пенсии осталось, Шеридан? Дотянешь?
Может, кризис поможет, голод и неопределенность это базовые чувства, работают и на таких вот, полностью застывших в невежестве.
S>Вот я и пытаюсь вас в тепло затащить.
На самое днище? Чтобы новички смеялись за спиной и пальцем у виска крутили?
Здравствуйте, gandjustas, Вы писали:
V_>>- чтобы scale-up/scale-down, в зависимости от нагрузки. Особенно, когда разные части по-разному скейлятся. G>Для этого обязательна микросервиная архитектура? Кто-то мешает делать то же самое, когда все приложение сотоит из 2-3 частей: фронтэнда, базы, бекэнда для фоновых назад, который может быть часть фронтэнда?
Чем больше размер бэка, тем выше вероятность что отдельные его компоненты создают разнородную нагрузку. И когда у тебя часть бэка жрет CPU, а часть — I/O, нормально ты такое не отскалируешь.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, Sheridan, Вы писали:
НС>>>Слышал про SOC сертификацию? Там возможность откатов при обновлении — одно из явных требований политики change management. А без SOC сертификации твой софт не пустят ни в одну приличную западную контору. Такой вот бредовый бред. S>>И категорически совершенно невозможно реализовать откат без докера. дадада.
НС>Возможно, но сложее.
Не сказал бы что сложнее. Тысячи разработчиков, пакетирующих свой софт могут а вы — нет.
НС>Возможность отката уже не бредовый бред, да?
А я когдато это утверждал? Я говорил о том что тестировать нужно на своих серверах, и хорошо тестровать.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Чем больше размер бэка, тем выше вероятность что отдельные его компоненты создают разнородную нагрузку. И когда у тебя часть бэка жрет CPU, а часть — I/O, нормально ты такое не отскалируешь.
Почему же? Если мы говорим о взрослом ДЦ, то там весь storage масштабируется отдельно от CPU и RAM.
Здравствуйте, Vetal_ca, Вы писали:
S>>По ссылке было про то как тебе админ дорогу перешол? о0 V_>Н-да, самый тяжелый случай. Сколько тебе до пенсии осталось, Шеридан? Дотянешь? V_>Может, кризис поможет, голод и неопределенность это базовые чувства, работают и на таких вот, полностью застывших в невежестве.
Застывать в докере не буду без необходимости.
S>>Вот я и пытаюсь вас в тепло затащить. V_>На самое днище? Чтобы новички смеялись за спиной и пальцем у виска крутили?
А, так ты новичок. Тогда всё ок.
Здравствуйте, gandjustas, Вы писали:
НС>>Чем больше размер бэка, тем выше вероятность что отдельные его компоненты создают разнородную нагрузку. И когда у тебя часть бэка жрет CPU, а часть — I/O, нормально ты такое не отскалируешь. G>Почему же?
Странный вопрос.
G> Если мы говорим о взрослом ДЦ, то там весь storage масштабируется отдельно от CPU и RAM.
I/O это не только внешний сторадж. К примеру, во взрослом ДЦ Azure есть зачем то такие машинки как Ls. Ну и, помимо I/O, есть еще и другие ресурсы, например память или количество одновременных подключений.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, gandjustas, Вы писали:
НС>>>Чем больше размер бэка, тем выше вероятность что отдельные его компоненты создают разнородную нагрузку. И когда у тебя часть бэка жрет CPU, а часть — I/O, нормально ты такое не отскалируешь. G>>Почему же?
НС>Странный вопрос.
G>> Если мы говорим о взрослом ДЦ, то там весь storage масштабируется отдельно от CPU и RAM.
НС>I/O это не только внешний сторадж.
А что еще?
НС>К примеру, во взрослом ДЦ Azure есть зачем то такие машинки как Ls. Ну и, помимо I/O, есть еще и другие ресурсы, например память или количество одновременных подключений.
Использовать public cloud для кастомных микросервисов можно только если у вас очень много лишних денег. Монлитное приложение, использующее ресурсы azure (тот же самый azure storage или azure sqldb\cosmosdb) будет не просто в разы, а на порядки более cost-effective.
Здравствуйте, gandjustas, Вы писали:
G>Попытка насти и собрать команду которая делает то же самое на многих языках это геморой еще больше. У меня есть опыт управления командой в 4 языка, это ад.
Бывают компании чуть побольше, могущие себе позволить 4 команды на разных языках вместо одной на 4.
G>Вопрос в поддерже и в стоимости взаимодействия, как между людьми в команде, так и между компонентами в разных контейнерах.
Если команды разные (а это обычно и подразумевается в случае микросервисов), то стоимость взаимодействия через REST API зачастую даже ниже, чем стоимость взаимодействия через API на богатых языках.
Здравствуйте, gandjustas, Вы писали:
G>А что мешает делать тоже самое с монолитным приложением? В чем смысл именно микросервисов?
Для крупного монолита требуется команда высокого уровня. А для микросервисов достаточно нескольких крутых перцев, занимающихся ядром, а на остальные сервисы можно нанять индусов и не переживать зато что они смогут сломать что то кроме своего микросервиса.
Здравствуйте, gandjustas, Вы писали:
НС>>I/O это не только внешний сторадж. G>А что еще?
Еще локальный сторадж и сеть.
НС>>К примеру, во взрослом ДЦ Azure есть зачем то такие машинки как Ls. Ну и, помимо I/O, есть еще и другие ресурсы, например память или количество одновременных подключений. G>Использовать public cloud для кастомных микросервисов можно только если у вас очень много лишних денег.
Ох как все запущено.
G> Монлитное приложение, использующее ресурсы azure (тот же самый azure storage или azure sqldb\cosmosdb) будет не просто в разы, а на порядки более cost-effective.
С чего бы это? Машина в AKS стоит ровно столько же, сколько standalone VM или VMSS. ACI подороже, но не в разы.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, gandjustas, Вы писали:
G>>Попытка насти и собрать команду которая делает то же самое на многих языках это геморой еще больше. У меня есть опыт управления командой в 4 языка, это ад. НС>Бывают компании чуть побольше, могущие себе позволить 4 команды на разных языках вместо одной на 4.
Таких компаний единицы. Настолько мало, что их практики не применимы к тем кто поменьше.
G>>Вопрос в поддерже и в стоимости взаимодействия, как между людьми в команде, так и между компонентами в разных контейнерах. НС>Если команды разные (а это обычно и подразумевается в случае микросервисов), то стоимость взаимодействия через REST API зачастую даже ниже, чем стоимость взаимодействия через API на богатых языках.
Звучит сказочно. В монолитном приложении один разработчик пойдет и сделает изменение как в вызывающем, так и в вызываемом коде. А если язык нормальный, то компилятор проверит корреткность. Потом задеплоит все одной кнопкой.
Если это разные проекты, то один сделат вызов, второй в это время будет в носу ковыряться со своими задачами, через пару дней поменят вызываемый код, окажется что формат данных у првого и второго не сопадает и вызываемый сервис отдает ошибку. Второй передаст это первому, первый еще пару дней до этого изменения не доберется.
Простая задача в итоге стент большой и сложной.
Я понимаю что есть случаи когда разработка отдельнго приложения дешевле и эффективнее, но это отдельные случаи, их нельзя обобщить до "архитектруного паттерна".
Здравствуйте, Sheridan, Вы писали:
S>>>И категорически совершенно невозможно реализовать откат без докера. дадада. НС>>Возможно, но сложее. S>Не сказал бы что сложнее.
Есть опыт?
S> Тысячи разработчиков, пакетирующих свой софт могут а вы — нет.
Все тысячи умеют в откат? Уверен?
НС>>Возможность отката уже не бредовый бред, да? S>А я когдато это утверждал?
Шеридан, ты совсем уже стыд потерял:
C>>>Т.е. нужен специальный репозиторий для хранения пакетов, в котором будут лежать несколько версий (для откатов). Так как версий может быть несколько, то нужно уметь ставить определённую из них. Так что нужен какой-то софт, которой будет этим управлять.
S>>Версий не несколько, а одна. Ставить не определённую, а свежую.
C>Нет. Так делать нельзя, так как необходимость делать откат — это даже не обсуждается.
Бредовый бред бредящего бредуна. Даже читать такое противно и сразу появляется желание уйти из такой команды несмотря на то что я (к счастью) не в ней.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, gandjustas, Вы писали:
G>>А что мешает делать тоже самое с монолитным приложением? В чем смысл именно микросервисов?
НС>Для крупного монолита требуется команда высокого уровня. А для микросервисов достаточно нескольких крутых перцев, занимающихся ядром, а на остальные сервисы можно нанять индусов и не переживать зато что они смогут сломать что то кроме своего микросервиса.
Это полу-правда.
Там где для монолитного приложения нужно 2-3 человека из 5 чтобы были достаточно скилловыми, то для микросервисов нужно по одному скилловому на каждый микросервис\на каждый язык-платформу. В сумме окажется что скилловых посонов нужно больше.
Здравствуйте, gandjustas, Вы писали:
G>>>Попытка насти и собрать команду которая делает то же самое на многих языках это геморой еще больше. У меня есть опыт управления командой в 4 языка, это ад. НС>>Бывают компании чуть побольше, могущие себе позволить 4 команды на разных языках вместо одной на 4. G>Таких компаний единицы.
Не единицы, даже в РФ. А если еще и в объеме денег и разработчиков посчитать, то как бы не больше половины рынка вышло.
G>Звучит сказочно.
Это не аргумент.
G>Если это разные проекты, то один сделат вызов, второй в это время будет в носу ковыряться со своими задачами, через пару дней поменят вызываемый код, окажется что формат данных у првого и второго не сопадает и вызываемый сервис отдает ошибку. Второй передаст это первому, первый еще пару дней до этого изменения не доберется.
Ситуация с отдельными компонентами одного монолита, разрабатываемыми разными командами, точно такая же. А богатый API делает эту задачу в разы более сложной. В то время как REST принудительно API упрощает и уплощает. Это увеличивает стоимость дизайна API, но снижает потери на взаимодействии команд.
G>Я понимаю что есть случаи когда разработка отдельнго приложения дешевле и эффективнее, но это отдельные случаи
Здравствуйте, gandjustas, Вы писали:
НС>>Для крупного монолита требуется команда высокого уровня. А для микросервисов достаточно нескольких крутых перцев, занимающихся ядром, а на остальные сервисы можно нанять индусов и не переживать зато что они смогут сломать что то кроме своего микросервиса. G>Это полу-правда.
Это наблюдение.
G>Там где для монолитного приложения нужно 2-3 человека из 5 чтобы были достаточно скилловыми,
Нет. Для монолита нужно примерно 100% скилловых. Причем чем больше монолит, тем выше должна быть скилловость. У меня были в команде люди уровня джуна или миддла. в итоге пришлось от них избавиться и на тот же бюджет нанять меньшее количество сеньоров.
G> то для микросервисов нужно по одному скилловому на каждый микросервис\на каждый язык-платформу.
Не нужно. Достаточно одну высококлассную core team.
Здравствуйте, Ночной Смотрящий, Вы писали:
S>>>>И категорически совершенно невозможно реализовать откат без докера. дадада. НС>>>Возможно, но сложее. S>>Не сказал бы что сложнее. НС>Есть опыт?
Да. С БД, правда, нетривиально, нужен diff хотя бы или бэкапы. А в остальном всё сводится к правилу "намусорил — убери за собой".
S>> Тысячи разработчиков, пакетирующих свой софт могут а вы — нет. НС>Все тысячи умеют в откат? Уверен?
При удалении пакетов из системы как правило остаются лишь изменённые конфиги.
НС>>>Возможность отката уже не бредовый бред, да? S>>А я когдато это утверждал? НС>Шеридан, ты совсем уже стыд потерял: НС>
C>>>>Т.е. нужен специальный репозиторий для хранения пакетов, в котором будут лежать несколько версий (для откатов). Так как версий может быть несколько, то нужно уметь ставить определённую из них. Так что нужен какой-то софт, которой будет этим управлять.
S>>>Версий не несколько, а одна. Ставить не определённую, а свежую.
C>>Нет. Так делать нельзя, так как необходимость делать откат — это даже не обсуждается.
НС>Бредовый бред бредящего бредуна. Даже читать такое противно и сразу появляется желание уйти из такой команды несмотря на то что я (к счастью) не в ней.
Это ты стыд потерял. Сказанное мной относится не к откату а к тому что нужно ставить свежую для дистрибутива версию либы из репозитория дистрибутива. Что ты осуждаешь, зачем-то вспоминая про откаты.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Нет. Для монолита нужно примерно 100% скилловых. Причем чем больше монолит, тем выше должна быть скилловость. У меня были в команде люди уровня джуна или миддла. в итоге пришлось от них избавиться и на тот же бюджет нанять меньшее количество сеньоров.
Мы говорим о приложении одинаковой функциональности? Или сравниваем монолитный Netflix и микросервисный hello world?
Функциональность одинаковая, то микросервисы будут требовать больше людских ресурсов (это в кждой второй презентации по микросервисам упоминается). А как показывают наблюдения необходиое соотношение скиловых и не очень людей в команде не зависит от языка и архитектуры, даже исследование на этот счет видел.
G>> то для микросервисов нужно по одному скилловому на каждый микросервис\на каждый язык-платформу. НС>Не нужно. Достаточно одну высококлассную core team.
Я даже погулил этот вопрос. никто нигде не говорил что микросервисы дают возожность набирать менее скилловых людей. Если есть исследования на эту тему — с радостью почитаю.
Здравствуйте, gandjustas, Вы писали:
G>Функциональность одинаковая, то микросервисы будут требовать больше людских ресурсов (это в кждой второй презентации по микросервисам упоминается).
Можно ссылку на такую вторую?
G>А как показывают наблюдения необходиое соотношение скиловых и не очень людей в команде не зависит от языка и архитектуры, даже исследование на этот счет видел.
Тоже ссылку неплохо бы.
G>>> то для микросервисов нужно по одному скилловому на каждый микросервис\на каждый язык-платформу. НС>>Не нужно. Достаточно одну высококлассную core team. G>Я даже погулил этот вопрос.
Википедия:
Modularity: This makes the application easier to understand, develop, test, and become more resilient to architecture erosion. This benefit is often argued in comparison to the complexity of monolithic architectures.
Ну и с гуглингом у тебя не очень.
Team skills:
With microservices, a team can be grouped by skills or location without the associated risksor difficulties involved ...
Ну во-первых вот так прямо в лоб тебе никто этого не скажет, не комильфо делить людей на сорта. Скажут что то вроде: "микросервисы позволяют адаптировать конкретный микросервис под размер и скилл конкретной команды". А во-вторых ты несколько неверно представляешь картинку. Суть не в том что мы внутри компании делим своих FTE на уровни, а в том что через аутстаффинг или аутсорсинг покупаем готовые команды со стороны. Они могут быть вполне неплохого уровня даже, но они точно дешевле команды FTE.
Здравствуйте, Sheridan, Вы писали:
НС>>>>Возможность отката уже не бредовый бред, да? S>>>А я когдато это утверждал? НС>>Шеридан, ты совсем уже стыд потерял: НС>>
C>>>>>Т.е. нужен специальный репозиторий для хранения пакетов, в котором будут лежать несколько версий (для откатов). Так как версий может быть несколько, то нужно уметь ставить определённую из них. Так что нужен какой-то софт, которой будет этим управлять.
S>>>>Версий не несколько, а одна. Ставить не определённую, а свежую.
C>>>Нет. Так делать нельзя, так как необходимость делать откат — это даже не обсуждается.
НС>>Бредовый бред бредящего бредуна. Даже читать такое противно и сразу появляется желание уйти из такой команды несмотря на то что я (к счастью) не в ней.
S>Это ты стыд потерял. Сказанное мной относится не к откату а к тому что нужно ставить свежую для дистрибутива версию либы из репозитория дистрибутива.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, gandjustas, Вы писали:
G>>Функциональность одинаковая, то микросервисы будут требовать больше людских ресурсов (это в кждой второй презентации по микросервисам упоминается). НС>Можно ссылку на такую вторую? https://cloudacademy.com/blog/microservices-architecture-challenge-advantage-drawback/
См disadvantages, там же видео есть
G>>>> то для микросервисов нужно по одному скилловому на каждый микросервис\на каждый язык-платформу. НС>>>Не нужно. Достаточно одну высококлассную core team. G>>Я даже погулил этот вопрос.
НС>Википедия: НС>
НС>Modularity: This makes the application easier to understand, develop, test, and become more resilient to architecture erosion. This benefit is often argued in comparison to the complexity of monolithic architectures.
Easier to understand вовсе не ознаеет что нужно меньше скилловых людей для работы.
НС>Ну и с гуглингом у тебя не очень. НС>
НС>Team skills:
НС>With microservices, a team can be grouped by skills or location without the associated risksor difficulties involved ...
НС>>Modularity: This makes the application easier to understand, develop, test, and become more resilient to architecture erosion. This benefit is often argued in comparison to the complexity of monolithic architectures.
G>Easier to understand вовсе не ознаеет что нужно меньше скилловых людей для работы.
Именно это оно и означает.
НС>>Ну и с гуглингом у тебя не очень. НС>>
НС>>Team skills:
НС>>With microservices, a team can be grouped by skills or location without the associated risksor difficulties involved ...
Еще раз — никто тебе напрямую не скажет что это позволяет нанимать обезьянок. А иносказательно смысл фразы именно такой — микросервисы позволяют иметь меньше рисков при покупке дешевых команд.
Почему тогда у вас так много инцидентов на проде заказчиков?
