Здравствуйте, 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>У меня вообще возникает вопрос: а какого хрена девопс приходит и говорит про какие-то версии либ? Версии либ выбирают разработчики, а никак не девопсы.
Я могу себе представить ситуацию (да что представлять, сам с таким сталкивался), когда мониторинг показал, что:
— текущая версия либы течёт,
— лочит и не отпускает ресурсы.
А в новой эти баги пофикшены.
Но:
— выявить такие вещи может не отдельно стоящий девопс, а разрабочик, который ещё функции девопса выполняет. Или девопс должен хорошо разбираться в используемой платформе.
— в любом случае без оценки трудозатрат никакого обновления либы не будет. Вполне по результатам оценки может оказаться, что дешевле запустить пару реплик сервиса и смириться с тем, что они будут время от времени умирать из-за нехватки памяти и рестартоваться.
