Здравствуйте, 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). Разделения на "бажных контейнеры" нет.
