Здравствуйте, Слава, Вы писали:
SVZ>>На любое обращение к ИТ отделу ему отвечают, что "корпоративные полиси запрещают что-либо менять на машине".
С>Вот это, знаете ли, придурь в духе "у нас бухгалтерский отдел не умеет с этим работать". Так бухгалтерия служит предприятию, или предприятие бухгалтерии?
Увы, это объективная реальность.
Чтобы простому инженеру поставить нужный ему софт (оплаченный компанией, к слову) приходится заполнять кучу документов с обоснованием.
В итоге, чтобы не просить каждый раз рутовый доступ на установку rpm, сделали вариант поставки в архиве (распакуй себе в каталог и запусти), чтобы сервис запускался из под бесправного пользователя.
Вот такая вот она — американская бюрократия
Тут пришлось удаленно помогать настраивать установку сервера лицензии FlexLM.
Дык сисадмину (хотя какой он, к лешему, сисадмин — сам настроить не может, Шеридан забил бы его сцаной тряпкой и был бы прав) на той стороне для того, чтобы открыть порт в фаерволе для доступа к лицензии, пришлось сперва закоммитить конфиг файл в репозиторий, отправить его на ревью и только после аппрува смогли запустить сервис.
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, Слава, Вы писали:
С>В том, до такого количества микросервисов ещё дорасти надо. И для этого нужно быть кем-то вроде Убера или хотя бы БКС. А пока это так, сферовакуумные обсуждения в духе "а если к нам придёт мильон клиентов?". Да не придут, не беспокойтесь.
Ну мало ли, может это евангелист микросервисов и у него на каждые 2+2 свой микросервис
С>Шеридан, вот ты нашёл с кем разговаривать. Сотни микросервисов ему, ага. Каждое мелкое земноводное вообразило себя Убером.
Ну вот мы не Убер. У нас около 200 микросервисов на четырех разных языках с абсолютно разными требованиями к доступности, масштабируемости и т.п. Хотя все начиналось, как у всех — несколько серверов в датацентре с разворачиванием условным ансиблом и т.п.
Насколько мы «мелкое земноводное», не знаю.Не Спотифай, да, и не Убер. Но 80 программистов могут спокойно делать то, что бизнесу нужно, не оглядываясь друг на друга и ломая друг другу код и прод из-за обновлений и несовместимостей.
Здравствуйте, Michael7, Вы писали:
M>С одной стороны да, с другой все же если делается Продукт, неплохо бы и последить за хотя бы самыми популярными, вроде Ubuntu, Debian, Fedora, CentOS/RHEL. Обычно, если под ними работает, то и под другими дистрами пользователь сможет более-менее легко запустить. Косвенно, переносимость вообще улучшает качество кода.
Ну, как бы да, но тут больше ведь про разнообразие дистрибутивов, нежели про обсуждаемую слежку. Но для этого уже нужна инфраструктура где код будет то ли на них билдится автоматом и быстро, то ли уже запускаться готовый. А если задачи такой нет — то и смысла заморачиваться (держать эту инфраструктуру) — тоже нет.
M>Ну в принципе да, решение проблемы, но в итоге можно прийти к тому, что каждая программа будет в своем снапшоте сидеть.
Где-то был сервис, забыл как называется, и он там ставит пакеты с кучей изолированного окружения. Помню быловался с monodevelop/xamarin studio или как оно там так пробовал ставить. Очень удобно! Запускаешься под отладчиком и понимаешь, что окружение у тебя не твое, а его и ничерта по сути не работает.
Здравствуйте, Sheridan, Вы писали:
MA>> Основная проблема в том, что выяснение всех деталей занимает слишком много времени, а оценка "зацепило ли" требует слишком глубоких знаний о всем проекте сразу (т.е. один девопс с этим не справится). S>Рилли? Запустить приложение в свежем окружении и прогнать уже готовые тесты — непосильная операция? Да с этим даже обезьяна справится.
Не. Это ты предлагал сидеть и выискивать изменения в зависимостях. Как только я подвел к очевидной мысли, что это решается тестированием целевых платформ — ты мне пишешь тестировать легко. Да еще прогнать УЖЕ готовые тесты. Для прогнать уже готовые тесты, девопс не нужен.
S>А знаешь причины этого? Подсказать? Или догадаешься из контекста всего этого срача?
Грубить не надо. Я тебя ни в чем не обвинял, лишь спрашивал как ты себе это все представляешь. Ответ на свой вопрос я получил.
Здравствуйте, Mystic Artifact, Вы писали:
MA>>> Основная проблема в том, что выяснение всех деталей занимает слишком много времени, а оценка "зацепило ли" требует слишком глубоких знаний о всем проекте сразу (т.е. один девопс с этим не справится). S>>Рилли? Запустить приложение в свежем окружении и прогнать уже готовые тесты — непосильная операция? Да с этим даже обезьяна справится. MA> Не. Это ты предлагал сидеть и выискивать изменения в зависимостях. Как только я подвел к очевидной мысли, что это решается тестированием целевых платформ — ты мне пишешь тестировать легко. Да еще прогнать УЖЕ готовые тесты. Для прогнать уже готовые тесты, девопс не нужен.
Ну значит не нагружайте этим девапса
S>>А знаешь причины этого? Подсказать? Или догадаешься из контекста всего этого срача? MA> Грубить не надо. Я тебя ни в чем не обвинял, лишь спрашивал как ты себе это все представляешь. Ответ на свой вопрос я получил.
Извини если грубо. Причины описанной ситуации то понял?
M>> каждая программа будет в своем снапшоте сидеть.
M>В идеале так и нужно. Жалко, unikernels так до вменяемого состояния и не допилились, они бы в теории были бы неплохой альтернативной докеру.
Каждому микросервису по докеру! Даешь 100 микросервисов на 1 узле! У кого нет 128гб рамы под 1 приложение о 100 докеров, тот нищеброт!
K>С этим могу поспорить. Если, напрмиер, какой-то проект, запущенный в продакшен, работает себе и работает, а тут бац — перестал работать, потому что либа обновилась. Даже если разработчики либы хотели как лучше. Или вообще — фичу из либы, которая в проекте использовалась, разработчики либы объявили устаревшей и из очередной версии выкинули.
Или ты обновил свой докер и оно тоже перестало работать. А потому, что надо обновления тестировать прежде чем устанавливать.
K>> а тут бац — перестал работать, потому что либа обновилась. Даже если разработчики либы хотели как лучше.
LK>Даже если разработчики либы нашли и исправили серьёзный баг — и поэтому обновили библиотеку?
Хотя бы даже и так. Но вот, блин, оказалось, что та функция, в которой был этот баг, в проекте вообще не использовалась. А то, что в проекте использовалось — в новой версии ненароком сломали.
Здравствуйте, Mamut, Вы писали:
M> Но 80 программистов могут спокойно делать то, что бизнесу нужно, не оглядываясь друг на друга и ломая друг другу код и прод из-за обновлений и несовместимостей.
Представил себе месилово из 80-ти пограммистов, без оглядки ломающих друг-другу код. Эдакий бой во время празднования масленницы.
Шутка. Я понял, что "не ломая".
K>Хотя бы даже и так. Но вот, блин, оказалось, что та функция, в которой был этот баг, в проекте вообще не использовалась. А то, что в проекте использовалось — в новой версии ненароком сломали.
Для этого есть тестовая среда и программисты, занимающиеся поддержкой старых версий.
Здравствуйте, L.K., Вы писали:
K>>Хотя бы даже и так. Но вот, блин, оказалось, что та функция, в которой был этот баг, в проекте вообще не использовалась. А то, что в проекте использовалось — в новой версии ненароком сломали.
LK>Для этого есть тестовая среда и программисты, занимающиеся поддержкой старых версий.
Тут, насколько я понимаю, речь идёт не о разработке, а о машине, на которой продакшен крутится.
Вот пришел Шеридан и заактуализировал либу на работающем сервере вусмерть.
Как тестирование поможет?
_____________________
С уважением,
Stanislav V. Zudin
SVZ>Когда твой конечный пользователь не имеет рутового доступа к системе, когда ты не знаешь, в каком окружении будет крутиться твоё приложение об актуализации либ можно забыть.
SVZ>Ну т.е. либо для твоего софта выделять отдельную машину ("фигвам, а не отдельная машина", скажет сисадмин), либо поднимать виртуалку, либо докер. SVZ>Либо выкручиваться так, чтобы ни одной dll/so в проекте не использовалось.
Это всё как раз не про несчастный глючный докер. Если у тебя софт -не маленькая программулька aka сайтик на lamp, а целый кластер, то, чтоб энтот кластер в виде кубернетиса на машину вкорячить нужно:
1) отдельная мощная машина, иначе этот глючный хипстерский кубернетис просто не развернётся, будет плеваться кучей ошибок абсолютно непонятного содержания. Ему, например, диски быстрые нужно, видите ли, иначе он обидится и не развернётся.
2) ты должен вычистить с мащины всё: штатные докер вместе со всем его потрохами и зависимостями, раскиданными по всей системе, вычистить и firewall, иначае кубернетис им поперхнётся, отключить selinux. Чтоб вкорячить с кубернетесом именно ту версию докера, на которой ты тестил свой калстер. Если этого не сделать-получишь кучи ошибок абсолютно непонятного содержания
3) для развёртывания всего этого хозяйства нужно писать инстяллятор, это просто невозожно упаковать в rpm/deb
А вот если не использовать докеры и кубернетесы, то достаточно использовать в проге компоненты из штатных реп и паковать прогу в deb/rpm. Тогда будет всё просто и красиво.
Здравствуйте, smeeld, Вы писали:
SVZ>>Когда твой конечный пользователь не имеет рутового доступа к системе, когда ты не знаешь, в каком окружении будет крутиться твоё приложение об актуализации либ можно забыть.
SVZ>>Ну т.е. либо для твоего софта выделять отдельную машину ("фигвам, а не отдельная машина", скажет сисадмин), либо поднимать виртуалку, либо докер. SVZ>>Либо выкручиваться так, чтобы ни одной dll/so в проекте не использовалось.
S>Это всё как раз не про несчастный глючный докер. Если у тебя софт -не маленькая программулька aka сайтик на lamp, а целый кластер, то, чтоб энтот кластер в виде кубернетиса на машину вкорячить...
Ты описываешь сценарий, когда под систему выделяется цельная машина. Тут действительно скрипач не нужен докер не очень понятен. Вся машина в твоём распоряжении — делай что хочешь.
Установочный скрипт или rpm и так накатит всё необходимое. Тут единственное, что нужно отследить — чтобы все компоненты системы между собой не конфликтовали. Но эта проблема как раз разруливается на стороне разработчика.
А вот когда на одной машине крутится дофига всего, что может конфликтовать, то... либо докер, либо виртуалки, либо (не знаю, у меня варианты закончились).
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, Sheridan, Вы писали:
S>Ну мало ли, может это евангелист микросервисов и у него на каждые 2+2 свой микросервис
Я не евангелист, но сторонники такой архитектуры на проекте у нас имеются, сотню мы уже перешагнули
Просто когда настроен конвеер, то там лишний десяток сервисов ничего не меняет.
Фактически, микросервисы — это админские чаяния, когда они могут дотянуться с уровня операционной системы до каждого модуля проекта, обновлять и конфигурировать проект частично либо быстро откатываться.
Здравствуйте, Mamut, Вы писали:
M>В идеале так и нужно. Жалко, unikernels так до вменяемого состояния и не допилились, они бы в теории были бы неплохой альтернативной докеру.
Может быть, я как-то про них вообще мало знаю.
Но стремление все пихать в докеры чудовищно раздувает ресурсы. Собственно об этом уже рядом ответили. Одно дело, когда в докерах одно-два жирных, тяжелых приложения, совсем другое если они чуть не на каждый чих, а так и будет в итоге, если перестать следить, чтобы софт работал хотя бы на самых популярных LTS дистрах. Кроме того, докер все же не панацея, если сильно не повезет, в нем тоже работать не будет.
SVZ>Вот пришел Шеридан и заактуализировал либу на работающем сервере вусмерть. SVZ>Как тестирование поможет?
Очень просто. Шеридан сначала проверяет новую либу на тестовом серваке. Потом исправляет косяки своего кода, связанные с изменившейся либой. Потом всё ещё раз проверяет, отдаёт на проверку кому-то ещё для гарантии, потом обновляет рабочий сервер.
К слову, даже стабильный ("работает-не-трогай") код должен хотя бы иногда просматриваться на предмет косяков.
Здравствуйте, vsb, Вы писали:
K>>С этим могу поспорить. Если, напрмиер, какой-то проект, запущенный в продакшен, работает себе и работает, а тут бац — перестал работать, потому что либа обновилась. Даже если разработчики либы хотели как лучше. Или вообще — фичу из либы, которая в проекте использовалась, разработчики либы объявили устаревшей и из очередной версии выкинули. vsb>Или ты обновил свой докер и оно тоже перестало работать. А потому, что надо обновления тестировать прежде чем устанавливать.
"Обновить Докер" — это как?
Обновить образ приложения — ну так это релиз новой версии, его надо тестировать. Если же обновлять сам Докер — он практически идеально обратно совместим. Я не помню, чтобы с ним были проблемы.
Здравствуйте, smeeld, Вы писали:
S>1) отдельная мощная машина, иначе этот глючный хипстерский кубернетис просто не развернётся, будет плеваться кучей ошибок абсолютно непонятного содержания. Ему, например, диски быстрые нужно, видите ли, иначе он обидится и не развернётся.
У меня K8S работает на Raspberry Pi.
S>2) ты должен вычистить с мащины всё: штатные докер вместе со всем его потрохами и зависимостями, раскиданными по всей системе, вычистить и firewall, иначае кубернетис им поперхнётся, отключить selinux. Чтоб вкорячить с кубернетесом именно ту версию докера, на которой ты тестил свой калстер. Если этого не сделать-получишь кучи ошибок абсолютно непонятного содержания S>3) для развёртывания всего этого хозяйства нужно писать инстяллятор, это просто невозожно упаковать в rpm/deb
Ещё один воинствующий неумеха появился в теме.
