Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Проект etcd-await-election для запуска процессов с учётом выбора лидирующего экземпляра"	+/–
Сообщение от opennews (??), 11-Июл-24, 09:27
Команда Ænix представила новый проект etcd-await-election, который позволяет выполнять операцию "leader election" на нескольких узлах с помощью распределённого хранилища etcd, для того чтобы гарантировать выполнение только одного экземпляра процесса в кластерных окружениях. Проект продолжает развитие идеи k8s-await-election, гарантируя эксклюзивный запуск пользовательского процесса, только после проведения выборов лидирующего экземпляра сервиса, но в отличие от него не требует наличия Kubernetes и работает напрямую с etcd. Код написан на языке Go и распространяется под лицензией Apache 2.0... Подробнее: https://www.opennet.dev/opennews/art.shtml?num=61522
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по ответам | RSS]

1. Сообщение от Аноним (1), 11-Июл-24, 09:27	+6 +/–
Сначала думал, что за сложную логистику штука должна делать, потом вижу - кубернетес. Всё, ясно, спасибо. Я до сих пор не понимаю, почему Kubernetes нужен.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #6, #8, #9, #18

2. Сообщение от Аноним (2), 11-Июл-24, 09:42    Скрыто ботом-модератором	+2 +/–
Скоро баш скрипты на 20 строк будут новостью
Ответить | Правка | Наверх | Cообщить модератору

3. Сообщение от Аноним ww (?), 11-Июл-24, 09:52	+1 +/–
А зачем оно нужно на практике? Сможет ли оно, к примеру, решить проблему, когда нужно запустить сервис-шедулер отказоустойчиво? Чтобы суммарно они отрабатывали не чаще раз в N времени, в независимости от того, упал ли кто-то или нет
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #12

6. Сообщение от penetrator (?), 11-Июл-24, 10:21	+2 +/–
> Я до сих пор не понимаю, почему Kubernetes нужен. Потому что существует огромное количество разработчиков, выдресированных на облака. И как только они столкнулись с реальностью, а не с cloud-native маркетингом, у них стало 2 проблемы. - Огромная стоимость облачных ресурсов. - Необходимость хоть как-то этот шлак масштабировать с учетом первого пункта. Смысла без облаков в нем нет, но даже там по своей сути у них получился костыль по всем фронтам. В качестве плюсов можно выделить автоматический деплоймент из коробки (такое же ущербное решение, но зато можно прикрутить тыц тыц и в продакшен). Называется это всё вместе с микросервисами (которые не нужны в 80-90% проектов, но которые упорно пытаются распихать по разным инстансам в том числе в k8s) - modern stack, что по сути все равно вертикальное масштабирование, а не горизонтальное. Но на весь этот маразматический прон наяривают модно-молодежные парни. Вот так и живем.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #7, #14

7. Сообщение от Аноним (1), 11-Июл-24, 10:37	+3 +/–
Спасибо за развёрнутый ответ. Я только видел пыжашихся и сопящих админов, ненавидщих эту штуку, а пользы - никакой.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #10, #15

8. Сообщение от Видимо (?), 11-Июл-24, 11:19	+/–
"но в отличие от него не требует наличия Kubernetes" Та, в тексте это есть...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

9. Сообщение от Аноним (9), 11-Июл-24, 12:04	+5 +/–
>Я до сих пор не понимаю, почему Kubernetes нужен. Для того чтобы упростить эксплуатацию приложений для которых нужна масштабируемость и отказоустойчивость. Если тебе такие слова неведомы или у тебя одно приложение релиз которого делается раз в месяц - он тебе не нужен, а если ты каждый день релизишь по несколько приложений каждое из которых должно быть запущено в десятке экземлпяров - кубернетес это один из способов упросить себе жизнь.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #11

10. Сообщение от Аноним (10), 11-Июл-24, 12:57	+7 +/–
Но ведь в этом "развёрнутом ответе" опять только пыжащийся и сопящий админ.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7

11. Сообщение от penetrator (?), 11-Июл-24, 13:00	–2 +/–
>  для которых нужна масштабируемость и отказоустойчивость бла-бла-бла > Если тебе такие слова неведомы корону не урони > если ты каждый день релизишь автоматизация не требует использования исключительно k8s вопрос, а если у тебя в каждом релизе есть DDL, а СУБД - это распределенный кластер, ты его деплоймент как собрался автоматизировать? а если неудачно прошло? откатывать как будешь? особенно на успешно обновленных инстансах? а если упадет во время отката? там столько нюансов, что тема точно не для опеннета а веб приложение может доставить встроенный в гитлаб пайплайн или ансинбл или еще что, и это не требует исключительно кубера > каждое из которых должно быть запущено в десятке экземлпяров прям должно? десяток виртуализированных сред с 2-4 vCPU в каждом? а может еще они у тебя все или часть на одном и том же физическом хосте? ))) с единой точкой входа извне (aka балансировщик)? ОК, в облачной среде ты переложишь балансировщик на плечи гиперскейлера. А если тебе твое решение надо on-premise? Вот это масштабируемость технического решения  )))) не, конечно какую-то часть вертикального и даже горизонтального масштабирования он на себя возьмет, например выделение новых ресурсов под веб приложение, добавив новый инстанс, но как я и говорил, это имеет смысл только в облаках, где всю миграцию на себя берет гиперскейлер за дорого, потому что у него есть огромный пул оборудования, и за эту сомнительную (потому что у нее есть и минусы) "магию" ты 10-ти кратно переплатишь а что делать с масштабированием СУБД? если твое приложение не числодробилка, то основная нагрузка это данные, а не веб-сервер, конечно очень часто код кривой и тормознутый, но тогда проблема точно не в инфраструктуре в общем кубер может предложить только Chupa Chups в большинстве оговоренных кейсов
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9 Ответы: #20

12. Сообщение от Аноним (10), 11-Июл-24, 13:04	+/–
Именно для таких задач и сделано.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3

14. Сообщение от Аноним (14), 11-Июл-24, 13:06	+1 +/–
все должны быть заняты работой, иначе начнут грабить караваны
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #30

15. Сообщение от gvf (??), 11-Июл-24, 13:33	–3 +/–
Кубер был спроектирован в точности под нужды гугла и мало кому нужен вне самого гугла. Гугл это десятки тысяч крайне дешевых компов, растыканных по всему Миру. Управлением всем этим становится жутким гемром. Итого. Кубер нужен тогда когда у вас есть инфраструктура стоимость  которой меньше затрат на оплату труда админов которые ее содержат. Любой вклад в уменьшение фонда з\п этой категории лиц становится прибыльным. Если же инфраструктура стоит больше стоимости труда админов - кубер это зло. Вот и вся экономика. -- Следует отметить, что на Западе стоимость труда человеков квалифицированных относительно выше стоимости железа, у нас же ситуация отличается из-за заниженного курса рубля - импорт дороже стоимости рабочей силы внутри страны, а контор которым таки надо масштабировать в таких широких пределах... кроме Платформы Госуслуг и банков..... я даже припомнить не могу. Но у этих ребят свои датацентры, Селектелом они не пользуются ))).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #21, #24, #32, #38

16. Сообщение от Аноним (16), 11-Июл-24, 13:42	+1 +/–
Напомните, что такое etcd? Это что-то типа реестра Windows?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #19

18. Сообщение от Аноним (18), 11-Июл-24, 15:21	+2 +/–
Попробуй на него посмотреть как на стандтизованый апи от инфрасктуры
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

19. Сообщение от Аноним (10), 11-Июл-24, 15:52	+/–
Это что-то типа redis, но персистентно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16

20. Сообщение от Аноним (10), 11-Июл-24, 16:13	+/–
>> масштабируемость и отказоустойчивость > бла-бла-бла Вы же понимаете, что только что признали, что делаете проекты уровня сайта-визитки? Раз уж для вас масштабируемость и отказоустойчивость — это "бла-бла-бла". > автоматизация не требует использования исключительно k8s Тем не менее, кубик — очень удобный инструмент автоматизации. > вопрос, а если у тебя в каждом релизе есть DDL, а СУБД - это распределенный кластер, ты его деплоймент как собрался автоматизировать? а если неудачно прошло? откатывать как будешь? особенно на успешно обновленных инстансах? а если упадет во время отката? там столько нюансов, что тема точно не для опеннета Ой-ой-ой, изнеженные девляпсы точно не справятся с такой задачей! Они, когда услышат про "распределенный кластер", сразу убегут (но кубик — тоже распределённый кластер? wait, oh shi~). Если серьезно, есть различные методы реализации миграций, от встроенного flyway до k8s native решений типа atlas operator. > если твое приложение не числодробилка, то основная нагрузка это данные, а не веб-сервер, > конечно очень часто код кривой и тормознутый, но тогда проблема точно не в инфраструктуре Ну да, точно. У 50-летних фуллстеков с оленями на свитерах и в голове ещё часто бизнес-логика выносится в хранимки, чтобы СУБД уж точно стала затыком. И уж точно не используются никакие кэширующие хранилища типа редиса, и бигдата не выносится в OLAP. Тут не только кубик бессилен, но и медицина. Таблеток для повышения IQ пока не придумали. А уж если версия N+1 накатывает миграцию, которая ломает версию N — тут только одминов в свитерах с оленями и звать :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11 Ответы: #25

21. Сообщение от Аноним (10), 11-Июл-24, 16:19	+3 +/–
> Кубер был спроектирован в точности под нужды гугла и мало кому нужен вне самого гугла. И действительно, с чего бы гугл передал его фонду CNCF? Наверное, чтобы усложнить себе жизнь, ведь из-за его возможности влиять на "нужный только гуглу" продукт резко ограничились. Хотя, если все остальные компании-спонсоры CNCF — виртуалы гугла... > Кубер нужен тогда когда у вас есть инфраструктура стоимость  которой меньше затрат на оплату труда админов которые ее содержат. Кубер нужен тогда, когда у админов IQ>80. Таким людям становится скучно выполнять руками рутинные операции (обновление, масштабирование, миграции) и т.д., и они начинают размышлять в духе "либо мы это автоматизируем, либо валю нафиг из этого цирка".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15 Ответы: #31

24. Сообщение от YetAnotherOnanym (ok), 11-Июл-24, 18:09	+/–
> крайне дешевых компов, Ну-ка, ну-ка, с этого момента поподробнее.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15

25. Сообщение от penetrator (?), 11-Июл-24, 18:29	+/–
> Вы же понимаете, что только что признали, что делаете проекты уровня сайта-визитки? Раз уж для вас масштабируемость и отказоустойчивость — это "бла-бла-бла". у тебя проблемы с логикой, никде не написано что масштабируемость и отказоустойчивость — это "бла-бла-бла", написано что ты бла-бла-бла со своими стандатными штампами про масштабируемость и отказоустойчивость, о которой понятия не имеешь, ведь тебе мерещатся вокруг только сайты визитки ))) > Ой-ой-ой, изнеженные девляпсы точно не справятся с такой задачей! Они, когда услышат про "распределенный кластер", сразу убегут (но кубик — тоже распределённый кластер? wait, oh shi~). это словесный понос, который показывает что тебе сказать по сути нечего > от встроенного flyway до k8s native решений типа atlas operator это всего лишь улучшенная версия обычного апдейт скрипта аналогичного вручному написанному для единичного(!) инстанса, притом точно также твой Atlas не решит проблему, как и твои вымышленные девляпсы, как и ты сам, но даже если предположить, что мы вдруг захотели использовать Atlas по какой-то неведомой причине, то это не значит что нам надо теперь кубер, у атласа просто есть для него оператор, это рассчитано на хомячков, заметь все решения что ты привел платные и стоят дополнительных денег > Ну да, точно. У 50-летних фуллстеков с оленями на свитерах и в голове ещё часто бизнес-логика выносится в хранимки, чтобы СУБД уж точно стала затыком. И уж точно не используются никакие кэширующие хранилища типа редиса, и бигдата не выносится в OLAP. никогда не выносил бизнес логику в СУБД, это же как минимум привязка к вендору (не говоря уже о DDD), а учитывая все что я выше написал, можно было догадаться, что это не про меня, хотя о чем это я, ты только о бородатых админах в свитере и мечтаешь (кстати я не бородатый админ в свитере, так что опять мимо) просто твоя серверная логика безбожно тупит поэтому, от этого попытки обмазаться in-memory кешами, которые не всегда актуальны и когерентны, а еще добавляют свои ограничения и открывают новый вектор аттак, как любой дополнительный продукт в стеке технологий, но пжлста кушайте, если очень нужно > Тут не только кубик бессилен, но и медицина. Таблеток для повышения IQ пока не придумали. фигово тебе > А уж если версия N+1 накатывает миграцию, которая ломает версию N — тут только одминов в свитерах с оленями и звать :) очередное твое бла бла, сказать по делу нечего, понтов два мешка, а в реальности полный 0
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20 Ответы: #28

28. Сообщение от Аноним (10), 11-Июл-24, 18:56	+/–
> у тебя проблемы с логикой, никде не написано что масштабируемость и отказоустойчивость — это "бла-бла-бла" Вы оправдываетесь. Это мне нравится :) > это словесный понос, который показывает что тебе сказать по сути нечего Да, адаптируюсь под ваш стиль общения. > это всего лишь улучшенная версия обычного апдейт скрипта аналогичного вручному написанному для единичного(!) инстанса, притом точно также твой Atlas не решит проблему Ну да, действительно, мигратор схем БД не решает проблемы миграции схем БД. Как же никто ещё не догадался до столь очевидного вывода! > заметь все решения что ты привел платные и стоят дополнительных денег https://github.com/flyway/flyway https://github.com/ariga/atlas-operator С вам 100500 миллионов за эти секретные ссылки. > просто твоя серверная логика безбожно тупит поэтому, от этого попытки обмазаться in-memory кешами, которые не всегда актуальны и когерентны, а еще добавляют свои ограничения и открывают новый вектор аттак, как любой дополнительный продукт в стеке технологий, но пжлста кушайте, если очень нужно Да и про эти ваши компьютеры можно то же самое сказать. Одни сложности от них, а толку ноль. Лучше на бумажке писать и считать. В общем, типичные "аргументы" неосилятора. > очередное твое бла бла, сказать по делу нечего, понтов два мешка, а в реальности полный 0 Это ответ на вопрос, что делать, если миграция новой версии ломает работу старой. Переформулирую — уволить разработчиков, пусть получат шанс начать карьеру в качестве дворников.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25 Ответы: #34

30. Сообщение от Аноним (10), 11-Июл-24, 19:09	+/–
Ну, тогда кубик надо запретить. Из-за него то, что раньше делали десять бородатых одминов, теперь непринужденно выполняет один девляпс. Итого плюс девять корованеров.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14

31. Сообщение от noc101 (ok), 11-Июл-24, 20:32	+/–
>Кубер нужен тогда, когда у админов IQ>80. Таким людям становится скучно выполнять руками рутинные операции (обновление, масштабирование, миграции) и т.д., и они начинают размышлять в духе "либо мы это автоматизируем, либо валю нафиг из этого цирка". Было бы правильно сказать. Кубер нужен когда у тебя куча серверов, которыми надо управлять в сжатые сроки за минимальное количество деняг. И для этого нужен админ с айкю любого ренджа.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21 Ответы: #36

32. Сообщение от Аноним (32), 11-Июл-24, 21:26	+/–
> Кубер был спроектирован в точности под нужды гугла и мало кому нужен вне самого гугла. Довольно забавно такое слышать, поскольку в гугле кубер никогда не крутился, весь их прод работает на системе Borg. Какие задачи гугла решает кубер -- неясно
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15 Ответы: #33

33. Сообщение от Аноним (33), 11-Июл-24, 22:24	+/–
Borg это всего лишь mapreduce - не деплой, не оркестрация и не управление ресурсами.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32

34. Сообщение от penetrator (?), 12-Июл-24, 00:28	+/–
> Вы оправдываетесь. Это мне нравится :) > Да, адаптируюсь под ваш стиль общения. банальное инвертирование фактов высосанное из среднего пальца > С вам 100500 миллионов за эти секретные ссылки. на и тебе магических линков https://www.red-gate.com/products/flyway/editions https://atlasgo.io/pricing https://atlasgo.io/features#database-support то что есть коммунити версия это понятно и без клоунов, надо же вас как-то подсадить на иглу... продукт > Ну да, действительно, мигратор схем БД не решает проблемы миграции схем БД. Как же никто ещё не догадался до столь очевидного вывода! прикинь не решает, ты не сможешь обновить атомарно даже master-slave setup, а уж тем более сделать это онлайн, все зависит от фич самой СУБД либо твоих кастомных решений для конкретных приложений а если тебе еще и запроцессить данные надо в процессе апдейта, и ты не можешь обойтись plan SQL и уж тем более декларативным языком твоих менеджеров - то все еще сложнее, потому что если код у тебя на C#, то хендлеры ты писать будешь на Java, что бесполезно для реального применения а если это полноценный multimaster, вот тогда начинается самое настоящее веселье, что с Galera, что с NDB решения есть, и все они частные, и заметь про кубер уже разговор не идет ВООБЩЕ )))) потому что понторез ты обыкновенный > Да и про эти ваши компьютеры можно то же самое сказать. Одни сложности от них, а толку ноль. Лучше на бумажке писать и считать. В общем, типичные "аргументы" неосилятора. т.е. ты не осилил писать качественный быстрый код, и твое поделие тупит, и приходится его скейлить еще за долго до того как узким местом становится СУДБ, чтобы хоть как-то это все ворочалось, ты его пичкаешь стероидами, а не осиллятор я? )) и все потому что мои решения работают без твоих костылей? )) ОК ))) > Это ответ на вопрос, что делать, если миграция новой версии ломает работу старой. Переформулирую — уволить разработчиков, пусть получат шанс начать карьеру в качестве дворников. ты даже не понял, что существует ошибка миграции, она рано или поздно возникнет, и существуют несовместимые на уровне БД версии, продукт эволюционирует, а ты мне про свой дерижабль опять поешь )))) в общем твой уровень понятен, жду какую-нибудь бессмысленную каку в ответ (нет), продолжать разговор не буду )))
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28 Ответы: #37

35. Сообщение от Аноним (35), 12-Июл-24, 08:09	+/–
чем оно лучше pacemaker?
Ответить | Правка | Наверх | Cообщить модератору

36. Сообщение от Аноним (10), 13-Июл-24, 09:57	+/–
Боюсь, совсем уж табуреткоголовые с кубиком не справятся. Им проще shell-скриптов написать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31

37. Сообщение от Аноним (10), 13-Июл-24, 10:12	–1 +/–
> банальное инвертирование фактов высосанное из среднего пальца Продолжайте оправдываться :) > то что есть коммунити версия это понятно и без клоунов, надо же вас как-то подсадить на иглу... продукт А с этими серверными линуксами, например, разве не так? RHEL, Ubuntu? Бесплатно — одно, за деньги — побольше. И так везде в этом нашем IT, ой вей. > прикинь не решает, ты не сможешь обновить атомарно даже master-slave setup, а уж тем более сделать это онлайн Слышу страдания счастливого (нет) пользователя мускуля. И это, кстати, одна из причин, почему WordpressDB практически не используется в серьёзных проектах. > а если тебе еще и запроцессить данные надо в процессе апдейта То я увольняю того разработчика, который это предложил. У здоровых людей при обновлении создаются новые поля, в фоновом режиме идет преобразование и синхронизация данных, в следующем релизе переключение на новые поля, и в ещё следующем — удаление старых. Это азы профессии, как версионирование API. Если "разработчик" такого не знает — это не разработчик, а вчерашний (и, скорее всего, завтрашний) курьер. > т.е. ты не осилил писать качественный быстрый код, и твое поделие тупит, и приходится его скейлить еще за долго до того как узким местом становится СУДБ, чтобы хоть как-то это все ворочалось, ты его пичкаешь стероидами, а не осиллятор я? Именно. Классика неосиляторства — написать код, который укладывает СУБД. > ы даже не понял, что существует ошибка миграции, она рано или поздно возникнет, и существуют несовместимые на уровне БД версии, продукт эволюционирует Неудивительно, что для вас масштабируемость и отказоустойчивость — пустые слова (зато "эволюция продукта" — нет, заметим). У вас такая динамично развивающаяся компания, что даже QA нет. И процесса проведения изменений через тестовые среды перед их попаданием на прод. > в общем твой уровень понятен, жду какую-нибудь бессмысленную каку в ответ (нет), продолжать разговор не буду ))) Приятно было пообщаться :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34

38. Сообщение от yurikoles (ok), 14-Июл-24, 01:53	+/–
> Гугл это десятки тысяч крайне дешевых компов, растыканных по всему Миру. Привет! Как дела в 99-м? В самом начале, Google действительно работал на самопальном кластере из дешёвого десктопного железа, которое часто умирало и покупалось оно по принципу: заменить проще, чем чинить. Но сейчас они имеют тонны кастомного железа в нескольких десятках собственных датацентров по всему миру.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15 Ответы: #39

39. Сообщение от нах. (?), 14-Июл-24, 19:49	–1 +/–
и собирают его сами по тому же самому принципу - дешевле выкинуть чем чинить. кастомное железо гугля - это картонка от обувной коробки и плата на ней на соплях и скотче. собственные датацентры тоже такие же - склад морских контейнеров (возможно купленных вместе с обанкротившимся складом) Во всяком случае это - засветилось на видео рабов гугля. А вот рядов современных стоек с современным железом никто никогда не показывал. (оно может где-то там и есть, в небольших количествах для обслуживания собственных нужд)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #38 Ответы: #40

40. Сообщение от scriptkiddis (?), 15-Июл-24, 18:36	+1 +/–
Откуда вы все это знаете? Вам лично гугель рассказывает? Пруфы?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема