Здравствуйте, 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>А если не будет места даже после очистки мусора? Ну, как себя поведет докер? Купит и добавит еще один винт в рейд?
Да ну блин опять детский сад. Контейнер атомарен — если нет места, докер просто не сможет его запустить, и всё. И не будет такого, что полконтейнера развёрнуто, а полконтейнера — нет, и для уборки этого говна надо писать ещё один скрипт.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
