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

"В Debian разрешено встраивание зависимостей в пакет Kubernetes"	+/–
Сообщение от opennews (ok), 21-Янв-21, 09:12
Технический комитет Debian (CTTE) одобрил поставку Kubernetes в форме монолитного пакета, включающего зависимости. Kubernetes требует для своей работы большого числа библиотек на языке Go. В соответствии с правилами Debian каждая библиотека должна сопровождаться в отдельном пакете, что в случае единичного использования нецелесообразно и существенно увеличивает трудозатраты.  Кроме того, для крупных проектов наблюдается привязка к версиям библиотек, с которыми гарантируется стабильная работа. Сопровождающий Kubernetes не стал следовать правилам и встроил в пакет около 200 зависимостей на языке Go... Подробнее: https://www.opennet.dev/opennews/art.shtml?num=54444
Ответить | Правка | Cообщить модератору

Сообщения

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

1. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."	+7 +/–
Сообщение от mos87 (ok), 21-Янв-21, 09:12
Вечная борьба между "всё своё ношу с собой" и "у нас тут коммуналка, извольте юзать общее - с пропатченными уязвимостями и вообще работающее в унисон со всем остальным" И второе проигрывает. Правда суть всех дистрибов именно в этом. Так что вот...
Ответить | Правка | Наверх | Cообщить модератору

	27. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."	+2 +/–
	Сообщение от rshadow (ok), 21-Янв-21, 13:08
	Конечно проигрывает. Но в основном для вот таких web-монстров. Культура поставки в дистрибудивах все так же на низком уровне в среде web-программистов. Хуяк-хуяк и в продакшн, ручками разложить. Для пользователей и адекватного софта все так же лучше библиотеки.
	Ответить | Правка | Наверх | Cообщить модератору

	37. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."	–1 +/–
	Сообщение от УшныеРаковиныЛинуса (?), 21-Янв-21, 14:19
	Для Java нужно вводить тоже самое. Теже IDE будет проще поддерживать, а то имеем: Debian 8 Eclipse старый, Debian 9 Eclipse той же версии, что и в Debian 8, а это более 4 лет.
	Ответить | Правка | Наверх | Cообщить модератору

	41. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."	+/–
	Сообщение от mos87 (ok), 21-Янв-21, 15:05
	лучше, когда 1 базовый дистр с циклами смены версий скажем год, 2, 5, 10. а как сейчас - не лучше.
	Ответить | Правка | К родителю #27 | Наверх | Cообщить модератору

2. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."	–3 +/–
Сообщение от FortyTwo (ok), 21-Янв-21, 09:14
А как не прогнуться?  RH сказала, проголосовали.
Ответить | Правка | Наверх | Cообщить модератору

3. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."	+3 +/–
Сообщение от Леголас (ok), 21-Янв-21, 09:18
Golang, Rust, JS... Такие особенные, современные, к ним нужен специальный подход. И если какого-нибудь flatpak им недостаточно, то всё равно будут делать по-своему.
Ответить | Правка | Наверх | Cообщить модератору

	32. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."	+/–
	Сообщение от Аноним (32), 21-Янв-21, 13:26
	Вот тут ты прав, именно особенные и именно современные, потому что заточены под нужды современной инфраструктуры и практик. Большие развесистые системы, которые делают своё дело. Ты много систем управления кластерами на Сях написал с таким же количеством фич как Kubernetes ну или хотя бы унылый Swarm? Мне кажется ответ на вопрос - 0.
	Ответить | Правка | Наверх | Cообщить модератору

	36. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."	+1 +/–
	Сообщение от Леголас (ok), 21-Янв-21, 14:07
	> Ты много систем управления кластерами на Сях написал с таким же количеством фич как ни то что на Сях, а вообще ни на чём, и с любым количеством фич (:
	Ответить | Правка | Наверх | Cообщить модератору

	38. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."	+8 +/–
	Сообщение от Аноним (-), 21-Янв-21, 14:19
	>нужды современной инфраструктуры и практик Хуяк-хуяк и в продакшн
	Ответить | Правка | К родителю #32 | Наверх | Cообщить модератору

	59. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."	–2 +/–
	Сообщение от Аноним (59), 21-Янв-21, 20:25
	> Такие особенные, современные, к ним нужен специальный подход > Golang, Rust, JS Озвученные тобой платформы уже имеют собственный менеджер зависимостей. А дистрибутивный пригождается там, где у языка нет какого-то центрального единого менеджера (C/C++). И то, что дистры наконец в 2021 стали догадываться, что не стоит дублировать репозитории пакетов у себя, не может не радовать.
	Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

	70. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."	+/–
	Сообщение от Аноним (70), 22-Янв-21, 02:54
	Собственный менеджер пакетов языка пригождается когда нужно возиться в своей маленькой песочнице и за её пределы не вылезать, и при этом не страшно скачать троян или сломанный пакет. А дистрибутивы как раз пакетят модули на раз - и ноду, и rust и даже go. Не говоря даже о всяких там питонах. Потому что конечному пользователю должно быть наплевать на каком языке что написано - ему нужно обновить всё установленное ПО централизовано, и особенно чтобы при этом компоненты на разных языках зависящие друг от друга (типа питоновских биндингов к rust либам) не поломались. Конечно же внутриязычковые инфраструктуры этого не умеют и никогда не сумеют. Но вот развесистые деревья зависимостей - это да, беда, и к великому сожалению единственный выход пока - бандлить. Но не волнуйтесь, это быстренько запретят как только выстрелит критическая уязвимость в каком-нибудь модульке который успели несколько десятков проектов забандлить. А потом может быть начнут появляться инструменты интеграции язычкопакетов в нормальные репозитории.
	Ответить | Правка | Наверх | Cообщить модератору

	73. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."	+/–
	Сообщение от J.L. (?), 22-Янв-21, 03:30
	> А потом может быть начнут появляться инструменты интеграции язычкопакетов в нормальные репозитории. да давно появились вот например собрать java-приложение в nixpkg https://discourse.nixos.org/t/help-packaging-a-java-app/3871
	Ответить | Правка | Наверх | Cообщить модератору

	72. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."	+1 +/–
	Сообщение от user (??), 22-Янв-21, 02:57
	Для этих любителей "curl | sh" нужен специальный мусорный бак.
	Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

4. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."	+2 +/–
Сообщение от Аноним (4), 21-Янв-21, 09:18
скатились теперь будет куча дублей пакетов, в разных пакетах
Ответить | Правка | Наверх | Cообщить модератору

	5. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."	+1 +/–
	Сообщение от Zruslan (ok), 21-Янв-21, 09:39
	Ну да, нынче место на дисках дешёвое
	Ответить | Правка | Наверх | Cообщить модератору

	31. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."	+1 +/–
	Сообщение от Аноним (32), 21-Янв-21, 13:24
	И оперативку на помойке можно найти, да? Разные файлы - разные маппинги в память одного и того же кода. Это никак не относится к Kubernetes, конечно, т.к. в Go иная структура приложения. Но ваш поинт...
	Ответить | Правка | Наверх | Cообщить модератору

	34. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."	+/–
	Сообщение от aim (ok), 21-Янв-21, 13:41
	вы, конечно, правы. однако вряд ли существенно сократится количество памяти - вряд ли вы на хосте будете с k8s что-то ещё запускать.
	Ответить | Правка | Наверх | Cообщить модератору

	46. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."	+/–
	Сообщение от Ordu (ok), 21-Янв-21, 17:03
	Эксперименты с compile-time полиморфизмом в стиле темплитов C++, показывают что этот полиморфизм не сильно влияет на расход оперативки. В 90-х я помню переживали из-за того, что много копий кода возникает под разные типы. Данные, с которыми код работает, занимают гораздо больше места, чем сам код. И чем дальше, тем больше разрыв. На сильно low-end системах, типа встраиваемых, где оперативка исчисляется килобайтами или метрами ситуация может быть иной, но туда никто в здравом уме не будет ставить дистрибутив общего назначения. -Os ведь практически не используется, куда ни сунься везде -O2 или -O3. Я подозреваю, что здесь та же ситуация выйдет.
	Ответить | Правка | К родителю #31 | Наверх | Cообщить модератору

	71. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."	+/–
	Сообщение от J.L. (?), 22-Янв-21, 02:54
	> Эксперименты с compile-time полиморфизмом в стиле темплитов C++, показывают что этот полиморфизм > не сильно влияет на расход оперативки. В 90-х я помню переживали > из-за того, что много копий кода возникает под разные типы. Данные, > с которыми код работает, занимают гораздо больше места, чем сам код. > И чем дальше, тем больше разрыв. На сильно low-end системах, типа > встраиваемых, где оперативка исчисляется килобайтами или метрами ситуация может быть иной, > но туда никто в здравом уме не будет ставить дистрибутив общего > назначения. -Os ведь практически не используется, куда ни сунься везде -O2 > или -O3. а кеш проца у вас тоже резиновый? помнится были результаты, что оптимизированый по размеру бинарь обгонял по скорости выполнения оптимизированый по скорости за счёт более частого/полного укладывания кода в кеш
	Ответить | Правка | Наверх | Cообщить модератору

	83. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."	+/–
	Сообщение от Ordu (ok), 22-Янв-21, 11:19
	> а кеш проца у вас тоже резиновый? помнится были результаты, что оптимизированый > по размеру бинарь обгонял по скорости выполнения оптимизированый по скорости за > счёт более частого/полного укладывания кода в кеш Это действительно хорошо работает на тесных циклах, когда тебе за счёт -Os удастся уложить цикл в кеш полностью. Но ты сменишь процессор, там кеша будет чуть меньше или чуть больше, и весь смысл пропадёт. Плюс если речь идёт о разных программах, то есть о разных процессах, там кеш будет очень хорошо слетать при переключении процессов, настолько хорошо, что эффект если и будет, то минимальным, на уровне статистической погрешности.
	Ответить | Правка | Наверх | Cообщить модератору

	92. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."	+/–
	Сообщение от J.L. (?), 24-Янв-21, 04:05
	> там кеш будет очень хорошо слетать при переключении процессов, настолько хорошо, > что эффект если и будет, то минимальным, на уровне статистической погрешности. на сколько я помню - это были реальные результаты тестов фаерфокса лет 10-15 назад - оптимизированый по памяти работал быстрее чем по скорости
	Ответить | Правка | Наверх | Cообщить модератору

	93. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."	+/–
	Сообщение от Ordu (ok), 24-Янв-21, 10:19
	>> там кеш будет очень хорошо слетать при переключении процессов, настолько хорошо, >> что эффект если и будет, то минимальным, на уровне статистической погрешности. > на сколько я помню - это были реальные результаты тестов фаерфокса лет > 10-15 назад - оптимизированый по памяти работал быстрее чем по скорости Очень сложно рассуждать о тестах, не видя методики. Любая статистика в отрыве от методики сбора данных и обработки их -- это та самая статистика, которая за пределами лжи.
	Ответить | Правка | Наверх | Cообщить модератору

	7. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."	–3 +/–
	Сообщение от Аноним (7), 21-Янв-21, 09:49
	Чтобы не было дублей, не используйте эти пакеты. Используйте только те, где дублей нет. Перед установкой, каждого пользователя спрашивают: вы согласны установить эти пакеты, которые займут столько места на вашем диске? Когда вы соглашаетесь, вы несёте ответственность за свой выбор и одобряете подход этого продукта. Если же это не так, то вы можете ответить "нет".
	Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

	10. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."	+/–
	Сообщение от пох. (?), 21-Янв-21, 09:55
	Не будут, их для этого надо все пересобрать в ту же секунду, одновременно. Если пересобрать один на секунду позже - в него притащит новые версии половины зависимостей-зависимостей-от-зависимостей. Модная современная разработка. С разработчиком, сидящим под б-жественной десяточкой, и слыхом не слыхавшего о том что бывает еще какое-то управление пакетами, кроме встроенного в нескучный язычок, скачивающее весь интернет. В основном - состоящий из лефтпадов, разумеется. К тому же, не переживай, модные-современные язычки все равно с трудом умеют в разделяемые библиотеки, и вся эта мусорка в любом случае не будет использована в разделяемом режиме.
	Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

6. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."	+5 +/–
Сообщение от Тов Майор (?), 21-Янв-21, 09:42
Go продукты на столько инклюзивные что требуют монолитной поставки ввиду конфликтов со всеми остальными. Забавно что ровно токая же проблема тотальной нетерпимости наблюдается у их инклюзивных создателей.
Ответить | Правка | Наверх | Cообщить модератору

	20. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."	–1 +/–
	Сообщение от anonymous (??), 21-Янв-21, 11:54
	> требуют монолитной поставки ввиду конфликтов со всеми остальными. Про что речь? Просто компилятор в Go собирает статически, that's it.
	Ответить | Правка | Наверх | Cообщить модератору

	33. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."	+3 +/–
	Сообщение от Аноним (33), 21-Янв-21, 13:40
	Раньше так было, а теперь может и динамически
	Ответить | Правка | Наверх | Cообщить модератору

8. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."	+4 +/–
Сообщение от Аноним (8), 21-Янв-21, 09:54
Зачем? Кому такое говно нужно - пусть пользуются снапом.
Ответить | Правка | Наверх | Cообщить модератору

	11. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."	–1 +/–
	Сообщение от пох. (?), 21-Янв-21, 09:58
	жуто боятся, что донейтов в этом году не будет вообще - "кому он нужен, ваш дерьмиан, там ДАЖЕ k8s нет в поставке дистрибутива, представляете, какя бесполезная хрень!" Поэтому логичнейшая идея переложить поддержку этой поделки на ее особо одаренных и богатых ресурсами разработчиков, увы, не прокатит. > пусть пользуются снапом. ты дистрибутивы перепутал - это к бубунточке, те по другому уже разучились.
	Ответить | Правка | Наверх | Cообщить модератору

	16. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."	+/–
	Сообщение от Иноагент (?), 21-Янв-21, 10:51
	>ты дистрибутивы перепутал - это к бубунточке, те по другому уже разучились. Ну так по топику выходит, что правильно сделали )) Нужно обладать талантом предвидения, что космонавт и продемонстрировал.
	Ответить | Правка | Наверх | Cообщить модератору

	66. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."	+/–
	Сообщение от Аноним (8), 21-Янв-21, 21:53
	>ты дистрибутивы перепутал - это к бубунточке А это что такое? https://packages.debian.org/bullseye/snapd >те по другому уже разучились. У тех большая часть пакетов - из дебиана. >жуто боятся, что донейтов в этом году не будет вообще - "кому он нужен, ваш дерьмиан, там ДАЖЕ k8s нет в поставке дистрибутива, представляете, какя бесполезная хрень!" А в чём проблема при установке апт-пакета для k8s ставить снап и в нём уже ставить говно? Зачем засирать димтр? Ведь снап как раз для таких неосиляторов загон, чтобы дистр не дасирали.
	Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

9. Скрыто модератором	–1 +/–
Сообщение от Аноним (9), 21-Янв-21, 09:54
У Слаки все равно толще.)
Ответить | Правка | Наверх | Cообщить модератору

	18. Скрыто модератором	–1 +/–
	Сообщение от Аноним (18), 21-Янв-21, 11:18
	Что толще? Кубернетец?
	Ответить | Правка | Наверх | Cообщить модератору

12. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."	+/–
Сообщение от Совсем не аноним (?), 21-Янв-21, 10:12
В Убунте давно в snap поставляются части кубера
Ответить | Правка | Наверх | Cообщить модератору

	47. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."	+3 +/–
	Сообщение от Анонии (?), 21-Янв-21, 17:36
	И как оно? За час успевает запуститься?
	Ответить | Правка | Наверх | Cообщить модератору

13. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."	–2 +/–
Сообщение от ryoken (ok), 21-Янв-21, 10:27
Поясните, а что такое вообще, этот ваш Kubernetes? С целью повышения уровня образованности.
Ответить | Правка | Наверх | Cообщить модератору

	15. Скрыто модератором	+/–
	Сообщение от Аноним (15), 21-Янв-21, 10:44
	Иди на гуйгл
	Ответить | Правка | Наверх | Cообщить модератору

	42. Скрыто модератором	+1 +/–
	Сообщение от Аноним (42), 21-Янв-21, 15:13
	гугл - для лохов правильные пацаны сами себе пишут поисковики
	Ответить | Правка | Наверх | Cообщить модератору

	57. Скрыто модератором	+/–
	Сообщение от InuYasha (??), 21-Янв-21, 20:22
	Эластиксёрч несколькими днями ранее сказал "не будьте так уверены что напишете". )
	Ответить | Правка | Наверх | Cообщить модератору

	22. Скрыто модератором	+2 +/–
	Сообщение от Gemorroj (ok), 21-Янв-21, 12:15
	херня, которой можно морочить головы бизнесу и жрать кучи денег на поддержание того пздеца, который там творится
	Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

	58. Скрыто модератором	–1 +/–
	Сообщение от Аноним (59), 21-Янв-21, 20:24
	А вот и пыхеры "редактирую index.php прямиком по ftp, дебажу через var_dump()" подъехали.
	Ответить | Правка | Наверх | Cообщить модератору

	23. Скрыто модератором	+5 +/–
	Сообщение от Штыбель (?), 21-Янв-21, 12:26
	О! Кубер, Энсибл, Терраформ... знание сих магическоих атрибутов автоматически превращает тебя с днище-админа в растянутом свитре, в новомодного набриолиненного ДевОпса и дает +$2000 к ЗП! Сарказм, есличо)
	Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

	25. Скрыто модератором	+3 +/–
	Сообщение от пох. (?), 21-Янв-21, 12:53
	А чо сарказм-то? Я трех таких в прошлом году собеседовал. Даже +2000 к зп были бы, до марта если, поскольку предыдущая у них была к тому моменту ровно 0. Но жадные менеджеры так ни одного и не наняли, видать, галстук был не того фасона.
	Ответить | Правка | Наверх | Cообщить модератору

	26. Скрыто модератором	+/–
	Сообщение от Ketalar (ok), 21-Янв-21, 13:02
	> А чо сарказм-то? Я трех таких в прошлом году собеседовал. > Даже +2000 к зп были бы, до марта если, поскольку предыдущая у > них была к тому моменту ровно 0. А как на сейчас дела обстоят?
	Ответить | Правка | Наверх | Cообщить модератору

	28. Скрыто модератором	+1 +/–
	Сообщение от пох. (?), 21-Янв-21, 13:12
	дык эта, коровавирусный кризис, все дела. Формально вакансия открыта, даже недавно был аукцион невиданной щедрости от hr "излови нам подходящего раба, мы заплатим тебе....25тыщржублей если сразу не сбежит", и она была в списке. А на практике аутсорсеры чего-то там ковыряют. К счастью, клиенты этого не видят, то что в их сторону - в основном немодные-немолодежные немикроархитектурные поделки, половина еще и на винде ажно.
	Ответить | Правка | Наверх | Cообщить модератору

	52. Скрыто модератором	+/–
	Сообщение от freehck (ok), 21-Янв-21, 18:26
	> дык эта, коровавирусный кризис, все дела. Формально вакансия открыта, даже недавно был > аукцион невиданной щедрости от hr "излови нам подходящего раба, мы заплатим > тебе....25тыщржублей если сразу не сбежит", и она была в списке. Невиданной, ага. А сами HR-ы берут от одного оклада обычно.
	Ответить | Правка | Наверх | Cообщить модератору

	78. Скрыто модератором	+/–
	Сообщение от пох. (?), 22-Янв-21, 09:35
	> Невиданной, ага. коровавирус, кризис, нефть по 19, за ржубль дают в морду. Раньше-то тыщ писят-семьдесят предлагали ("чтоб я, да весь отряд, да за какие-то двенадцать косяков сдал?!") > А сами HR-ы берут от одного оклада обычно. да кто ж им дасть? У них в зарплате КПИ как-то завязанный на количество пойманных голов, конечно, но чо-та чо-та личных лексусов и бмв на парковке я не видел. Шифруются, видать, на работу как все, на метро крались. То ли дело у нового ИТ-директора...
	Ответить | Правка | Наверх | Cообщить модератору

	67. Скрыто модератором	+/–
	Сообщение от Аноним (8), 21-Янв-21, 22:18
	Они там совсем о****и, брать деньги сверх оклада за выполнение своей работы?
	Ответить | Правка | К родителю #28 | Наверх | Cообщить модератору

	35. Скрыто модератором	+1 +/–
	Сообщение от Аноним (35), 21-Янв-21, 14:01
	я не против к +2000 грязных зеленых бумажек
	Ответить | Правка | К родителю #23 | Наверх | Cообщить модератору

	48. Скрыто модератором	+1 +/–
	Сообщение от Wilem82 (?), 21-Янв-21, 18:05
	Это интересная херотень, но практически никому не нужная. Как и докер в продакшене.
	Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

	50. Скрыто модератором	+2 +/–
	Сообщение от Аноним (50), 21-Янв-21, 18:21
	Но-но, я бы попросил. Ведь под "прудукшен" толпы модно-молодёжных понимают непременно свои хостинги котиков. Как же там без докеров и куберов? Прудукшен непременно должен быть в докерах и кубере, нужно это или нет. Раз в интернетах написано, что должно быть так, значит будут городить.
	Ответить | Правка | Наверх | Cообщить модератору

	54. Скрыто модератором	–1 +/–
	Сообщение от freehck (ok), 21-Янв-21, 18:35
	> Это интересная херотень, но практически никому не нужная. Как и докер в продакшене. Да. Да. Я очень сомневаюсь, что Ваши слова имеют хоть какое-то отношение к реальности.
	Ответить | Правка | К родителю #48 | Наверх | Cообщить модератору

	55. Скрыто модератором	+2 +/–
	Сообщение от Аноним (50), 21-Янв-21, 18:55
	Если тебе скажут, что есть проды, в которых за предложение применить докер и/или кубер сразу отправлют в школу, в первый класс, подучиться, и что это такие проды, без которых ты даже смузи себе купить не сможешь, поверишь?
	Ответить | Правка | Наверх | Cообщить модератору

	56. Скрыто модератором	+/–
	Сообщение от freehck (ok), 21-Янв-21, 18:57
	Что ж не поверить, я такие проды и сам знаю.
	Ответить | Правка | Наверх | Cообщить модератору

	74. Скрыто модератором	+1 +/–
	Сообщение от Wilem82 (?), 22-Янв-21, 03:32
	Поясни? Где и зачем он нужен? Мне прям интересно - я уже лет 15 занимаюсь живыми серверными приложениями, развёрнутыми от 1 компа до 10000. Но видимо чего-то не понимаю, и сейчас узнаю что-то полезное для своей профессии, прям тут в комментариях Опеннета.
	Ответить | Правка | К родителю #54 | Наверх | Cообщить модератору

	82. Скрыто модератором	+1 +/–
	Сообщение от freehck (ok), 22-Янв-21, 10:43
	> Поясни? Где и зачем он нужен? Мне прям интересно - я уже > лет 15 занимаюсь живыми серверными приложениями, развёрнутыми от 1 компа до > 10000. Но видимо чего-то не понимаю, и сейчас узнаю что-то полезное > для своей профессии, прям тут в комментариях Опеннета. Ну окей, я несколько связан NDA, так что имена компаний не могу называть. Тем не менее, чисто для примера, я могу описать ряд архитектурных решений. Рассмотрим облачного провайдера CI/CD. В кубе держится пул из воркеров. Каждый воркер для запуска пайплайна запускает dind, который менеджит запуск каждого шага в отдельном контейнере. Каждому из этих диндов выделяется Persistent Volume, который закрепляется за ним и может быть использован для хранения кэшей и передачи информации между шагами пайплайна. Чтобы не переплачивать за аренду ресурсов, шедулер тюнится, чтобы заполнять одну ноду до конца, и только потом переходить на следующую. Таким образом провиженер позволяет запрашивать у облака новую ноду только тогда, когда пул текущих нод заполнен полностью ворклоадом. Данная инфраструктура сейчас реально существует и ежедневно поддерживает тысячи клиентов по всему миру. Теперь посмотрим общий подход для организации разработки в произвольной компании. Чтобы протестировать изменения разработчика, берётся его PR, бампается версия чарта, и в тестовом кластере создаётся воркспейс под данную задачу, и туда накатывается стабильная версия всех компонент приложения + изменённый компонент разработчика. Облачная архитектура позволяет легко выделить дополнительные ресурсы и обеспечить непрерывный цикл разработки-тестирования. Парочка российских проектов, связанных с товарооборотом и ЭДО. Эти ребята не используют все преимущества k8s, однако даже они испытывают огромный буст производительности, благодаря миграции в куб. Благодаря концепциям сервиса и ингресс-контроллера, теперь можно не думать о том, чтобы синхронно за увеличением количества реплик, обновлять апстримы условного nginx-а. Куб берёт это на себя. Поэтому, когда им требуется быстро смасштабироваться горизонтально, они просто увеличивают количество реплик. И это только капля в море. Настройка менеджмента сертификатов на условном дедике -- штука крайне кривая по сравнению с cert-manager-ом. Чтобы перевыписывать сертификаты letsencrypt-ом, на дедике нужно корректно настроить веб-сервис для работы с webroot. В кубе -- reissue происходит автоматически, а об ингресс-контроллере думать не нужно совсем. Манифесты и хелм-чарты (читай, пакеты для куба), в кои-то веки обеспечили декларативное описание сложных программных комплексов. Раньше это достигалось прямыми руками, теперь же иначе просто невозможно. Порог вхождения в эту область увеличился, и это хорошо. Я уже не говорю, что Canary и Blue-Green встроены непосредственно в концепцию деплоймента. Я помню, как когда-то реализовывал эти схемы на ansible. Деплоймент маст хэв. В общем, Вам надо зайти на амазон или гугл, и просто попробовать.
	Ответить | Правка | Наверх | Cообщить модератору

	51. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."	+2 +/–
	Сообщение от freehck (ok), 21-Янв-21, 18:22
	> Поясните, а что такое вообще, этот ваш Kubernetes? С целью повышения уровня образованности. Kubernetes aka k8s -- это система управления кластером для контейнеров. По факту -- это протокол, формализующий процессы, происходящие в датацентре. Выглядит примерно следующим образом: ты объединяешь несколько машин в кластер куба, а затем начинаешь работать на более высоком уровне, таком как сервисы, дейплойменты, стейтфулсеты, и так далее. Всё, что ты определишь, будет автоматически зашедулено на произвольную ноду (если ты не прибиваешь к конкретным), будет удобно доступно через CNI, и будет мониториться и поддерживаться в этом состоянии, что бы ни произошло с нодами: то есть если одна из нод приляжет по какой-нибудь причине, твоё добро будет автоматом перераспределено. Это позволяет тебе абстрагироваться от лимитов конкретной системы, и строить HA-аппликации гораздо легче. Особенно в этом помогают то, что многие общепринятые практики уже включены в кубере по умолчанию. Что бы там ни говорили, но основной рынок IT и дальнейшее развитие нашей отрасли постепенно уходят именно туда.
	Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

	62. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."	+2 +/–
	Сообщение от Аноним (50), 21-Янв-21, 21:02
	> но основной рынок IT и дальнейшее развитие нашей отрасли Не основной, а лишь один из сегментов рынка массового потребителя IT, вернее, заказчика вычислительных ресурсов. Это большая толпа мелких, поднимающих нжинксы с апачиками в нескольких vds-ках в облачках. Вот для желающих делать деньги на таких, kuber-ы и docker-ы и существуют. Kuber-это инфраструктура облачного провайдера. Не больше, и не меньше. Глючная шо пипец, требующая команды для поддержания работоспособности. Но упомянутый рынок vds-ок, это, мягко говоря, не есть вся "наша отрасль". Это  один из его многочисленных сегментов. Причём, один из таких сегментов, который "на виду", в который зайти может каждый, хоть провайдером, хоть клиентом. Это такой базарчик в мире IT. В IT есть более интересные отрасли, и более денежные, но это для профи, и войти туда сильно сложнее, чем в мир вебок и облачков.
	Ответить | Правка | Наверх | Cообщить модератору

	77. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."	–1 +/–
	Сообщение от freehck (ok), 22-Янв-21, 09:33
	> Это большая толпа мелких, поднимающих нжинксы с апачиками в нескольких vds-ках в облачках. Ну, что тут сказать. Вы имеете очень превратное представление о том, кто является клиентом этих решений. Именно тем, кого Вы перечислили, куб как собаке третья нога. А используют его рыбы горааааздно крупнее. =)
	Ответить | Правка | Наверх | Cообщить модератору

	85. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."	–1 +/–
	Сообщение от Аноним (50), 22-Янв-21, 14:03
	Рыбы гораздо крупнее используют собственные вещи, вроде nitro system, или майнфремы юзают. А кубер как раз для мелочи пузатой, вроде redhat-а c его openshift.
	Ответить | Правка | Наверх | Cообщить модератору

	86. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."	+/–
	Сообщение от Аноним (50), 22-Янв-21, 14:06
	Бро, поддерживаю. И про небходимость HA логики в самом приложении, и про минимум всякого стороннего дерьма, от которого зависит работа приложения.
	Ответить | Правка | Наверх | Cообщить модератору

	75. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."	+5 +/–
	Сообщение от Wilem82 (?), 22-Янв-21, 03:56
	> Это позволяет тебе абстрагироваться от лимитов конкретной системы, и строить HA-аппликации гораздо легче. В реальности это не облегчает HA. 99% всего HA - это логика самого софта, у которого нет единой точки отказа, который сам умеет ходить на несколько адресов, если один из сервисов недоступен, который использует базу данных умеющую собственный кластер. Если софт этого не умеет, то кубер тебе ничем не поможет. А 1%, про который ты говоришь - это добавление физического сервера или создание виртуалки. На практике никто этим постоянно не жонглирует кроме гуглов и амазонов. Известна нормальная нагрузка, всегда есть запас на случай багов в софте или в случае публичного сервиса на случай подарков от отдела маркетинга. Ну и если тебе раз в месяц понадобилось добавить виртуалку у тебя есть ансибл, который это сделает одной командой. А вот вреда от кубера и докера довольно много. Ты видимо не программист, а админ, и поэтому не знаешь и не понимаешь, что система должна быть максимально простой - минимум абстракций, прослоек. Чем проще технологический стек, тем проще программистам и поддержке предсказывать возможные ситуации на проде, а также чинить поломки. Докер, к примеру, использует overlayfs, который в свою очередь кривой и косой. Если что-то случилось, тебе помимо обычной головной боли о самом приложении надо ещё думать - а не докер ли тут виноват? И такая же ситуация с кубером, только большего масштаба. Это охереть какая сложная система, и каждый раз думать кубер это виноват или докер или проблема где-то ещё лежит - нахера это надо? Кому и зачем? Плюс всё это говно надо обновлять, поддерживать, находить какие-то костыли для ситуаций, когда кубер только мешает и так далее. Не, я понимаю что технология интересная, но любое усложнение системы должно быть очень хорошо обосновано, и если ты не облако мирового масштаба, то обосновать ты ничего не сможешь.
	Ответить | Правка | К родителю #51 | Наверх | Cообщить модератору

	79. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."	+/–
	Сообщение от freehck (ok), 22-Янв-21, 09:41
	> Ты видимо не программист, а админ, и поэтому не знаешь и не понимаешь... Хе =)
	Ответить | Правка | Наверх | Cообщить модератору

	80. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."	+2 +/–
	Сообщение от пох. (?), 22-Янв-21, 09:50
	> А 1%, про который ты говоришь - это добавление физического сервера или > создание виртуалки. На практике никто этим постоянно не жонглирует кроме гуглов В чем проблема-то? Это обычно не автоматизируют сверх меры просто потому что сервер все равно сам в стойку не запрыгивает, и взять его неоткуда. А после кручения двадцати гаек уже можно и пару раз enter нажать, хотя и необязательно. Вариант "переустановить и перезагрузить" обычно для любителей лепки из г-на, у остальных он случается раз в пятилетку, и опять же незачем тратиться на автоматизацию. > А вот вреда от кубера и докера довольно много. Ты видимо не > программист, а админ, и поэтому не знаешь и не понимаешь, что наоборот. Потому что весь смысл там - уволить нахрен админа, и нанять еще больше программистов-на-нодежс. > система должна быть максимально простой - минимум абстракций, прослоек. Чем проще она и есть простая - клик-клик-клик в интуитивно понятненьком междумордии впопеншифта. Любой менеджер справится. А "добавлять в кластер" можно хоть вручную, это и программисту доступно. > Докер, к примеру, использует overlayfs, который в свою очередь кривой и косой. не нравится, используй модную молодежную btrfs. Удалял я тут с нее нагаженных докер-контейнерами пару гигабайт - уже успел забеспокоиться, оно там повисло или чо. Не, все норм, просто остальные системы были с ext4, там это мгновенно. Впрочем, согласно талмуду редбиэма, вроде, полагается raw lvm2 (но там, собственно, и от доскера уже ушли в пользу своих наколенных реализаций OCI). > если ты не облако мирового масштаба, то обосновать ты ничего не сможешь. смари, смари - у облаков мирового масштаба - во! Срочно внедрить у нас! this never fails
	Ответить | Правка | К родителю #75 | Наверх | Cообщить модератору

	84. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."	+/–
	Сообщение от Аноним (-), 22-Янв-21, 13:37
	> Ты видимо не программист, а админ Ожидал такой спич услышать как раз от админа. Прогеры как раз докером обмазываются на раз - насpал в контейнер и готово. А админу потом с этим жить и работать.
	Ответить | Правка | К родителю #75 | Наверх | Cообщить модератору

	87. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."	+1 +/–
	Сообщение от Аноним (50), 22-Янв-21, 14:33
	>Прогеры как раз докером обмазываются Я бы попросил. В приличном обществе за докер можно и в репу схлопотать. Ну модно-молодёжные любят, да. Но у них там ничего серьёзного и нет, так что и докер прокатит.
	Ответить | Правка | Наверх | Cообщить модератору

	88. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."	+/–
	Сообщение от Аноним (50), 22-Янв-21, 14:36
	Бро, поддерживаю. И про небходимость HA логики в самом приложении, и про минимум всякого стороннего дерьма, от которого зависит работа приложения.
	Ответить | Правка | К родителю #75 | Наверх | Cообщить модератору

	89. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."	–1 +/–
	Сообщение от freehck (ok), 22-Янв-21, 18:14
	>> Это позволяет тебе абстрагироваться от лимитов конкретной системы, и строить HA-аппликации гораздо легче. > В реальности это не облегчает HA. 99% всего HA - это логика > самого софта, у которого нет единой точки отказа, который сам умеет > ходить на несколько адресов, если один из сервисов недоступен, который использует > базу данных умеющую собственный кластер. Если софт этого не умеет, то > кубер тебе ничем не поможет. Короче -- софт должен быть интегрирован с service discovery, который вы выбрали при проектировании системы. Ну дык, как будто это какая-то особенная логика. Нынче иначе и не проектируют. Но честное слово, это простая интеграция с zookeeper / etcd (или даже через банальный dns), о каких 99% речь? > А 1%, про который ты говоришь - это добавление физического сервера или > создание виртуалки. На практике никто этим постоянно не жонглирует кроме гуглов > и амазонов. Известна нормальная нагрузка, всегда есть запас на случай багов > в софте или в случае публичного сервиса на случай подарков от > отдела маркетинга. Ну и если тебе раз в месяц понадобилось добавить > виртуалку у тебя есть ансибл, который это сделает одной командой. Клиент идёт в облака за удобством и дешевизной. Вот взгляни на тот же амазон. Если смотреть на их EC2-инстансы, то они выходят дороже vds-ок. Но они предоставляют возможность легко и непринуждённо скейлиться на лету в зависимости от загрузки ворклоада. Так что в итоге получается дешевле, чем vds-ки арендовать или же тем более -- чем держать запас, как Вы предлагаете. > А вот вреда от кубера и докера довольно много. Ты видимо не > программист, а админ, и поэтому не знаешь и не понимаешь, что > система должна быть максимально простой - минимум абстракций, прослоек. Чем проще > технологический стек, тем проще программистам и поддержке предсказывать возможные ситуации > на проде, а также чинить поломки. Да, система должна быть максимально простой. Вот только тут важно понимать, что такое "просто". Абстракции данного уровня упрощают понимание архитектуры приложения, что уменьшает количество ошибок при реализации. Да, добавляется прослойка. Но зато у нас есть чёткое понимание, где что находится, и кто за что отвечает. Плюс к тому, тут важен и социальный аспект. Сейчас уже не начало нулевых, сейчас двадцатые пошли. IT стал массовым явлением. Большинство developers -- из разряда "почему это я не могу создать 10 тысяч файлов в одной директории". Большинство operations engineers -- из разряда "я хз, что там случилось, если рестарт не поможет, то напишу в супорт". Эти абстракции разделяют их уровни ответственности, чтобы бизнес мог поднять сложные HA-решения даже обладая специалистами такого уровня, ибо каждый из них работает со своим уровнем абстракции. > Докер, к примеру, использует overlayfs, который в свою очередь кривой и косой. > Если что-то случилось, тебе помимо обычной головной боли о самом приложении > надо ещё думать - а не докер ли тут виноват? Да, с overlayfs было много косяков в своё врмя. Но во-первых уже давно сделали overlay2, который более стабилен, и меньше удивляет своим поведением, а во-вторых не одним оверлеем докерные storage driver-ы живы. Я держал на zfs например. Слышал, что некоторые на btrfs-е гоняли. Плюс к тому, некоторые вон просто блочное устройство в контейнер прокидывают, и сервис с ним делает что хочет, безо всяких там прослоек fs. Mount-ы из хост-системы работают по схожему принципу, так что в принципе ничто не мешает вам гонять postgresql или ноду btc таким макаром, вообще не связываясь с оверлеем. > И такая же ситуация с кубером, только большего масштаба. Это охереть какая > сложная система, и каждый раз думать кубер это виноват или докер > или проблема где-то ещё лежит - нахера это надо? Кому и > зачем? Ну это тонкий момент, и я с вами даже частично соглашусь. Если нам нужна производительность, то я безусловно за вынос стейтфулов за пределы куба. Но если нам важно удобство эксплуатации и скорость развёртывания -- то за куб. Если мы говорим про стейтлесс, спроектированный как twelve factor app, то в куб однозначно. > Плюс всё это говно надо обновлять, поддерживать, находить какие-то костыли для ситуаций, > когда кубер только мешает и так далее. Вы тут заблуждаетесь. Обновления в кубе как раз гораздо проще. Вы просто прописываете новую версию чарта в helmfile и деплоитесь. Обновить конфигурацию синхронно и без даунтайма -- тоже легче, благодаря операторам. Вот давеча мне потребовалось увеличить message.max.size в кафке. Я просто инкрементировал число в конфиге и применил новую конфигурацию кластера. Kafka-operator это дело подхватил, и сам последовательно применил к каждой ноде, причём по очереди, чтобы не было даунтайма. Операторы вообще сейчас повально для всего пишутся и хорошо поддерживаются. > Не, я понимаю что технология интересная, но любое усложнение системы должно быть > очень хорошо обосновано, и если ты не облако мирового масштаба, то > обосновать ты ничего не сможешь. Я думаю, что мне вполне удалось это сделать. "Не мужчина, а облако в штанах". =) PS: > Ты видимо не программист, а админ, и поэтому не знаешь и не понимаешь 1) Не админ, а опс 2) Перешёл в эту сферу аккурат из разработки =)
	Ответить | Правка | К родителю #75 | Наверх | Cообщить модератору

	90. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."	+1 +/–
	Сообщение от Wilem82 (?), 23-Янв-21, 06:30
	> Короче -- софт должен быть интегрирован с service discovery Не обязательно. Что обязательно, так это механизм повторных запросов. SD может выдать нерабочий адрес, а значит повторы на клиенте всё равно должны быть реализованы - это всё надо запрогать. Кроме того, все компоненты должны иметь избыточность, а значит не могут иметь состояния, влияющего на исход, т.е. должны быть равноправны и взаимозаменяемы - это надо продумывать и прогать наперёд, а то потом устанешь переделывать систему. Плюс все эти компоненты должны уметь останавливаться или наоброт просыпаться, при failover-е на другой DC к примеру. Переодические процессы, обработка входящего трафика и так далее.  Graceful shutdown, выход из standby - самые слабые места, такие вещи всегда задним числом пытаются прикрутить и делают это криво. Плюс все эти компоненты должны уметь backpressure и fail-fast, что бы не умирать под нагрузкой. А это тоже надо отдельно прогать и проектировать. И нет, "все так проектируют" неверный тезис, так проектируют очень немногие, а точнее почти никто. Обычно есть некое говно в котором никогда в жизни не было HA, и вдруг принимают решение HA таки сделать (то есть всё вышеозначенное и больше). Если у тебя приложение уже готово к тому, что все компоненты можно размножить, нет единой точки отказа, работают всевозможные фейловеры - ну, через пару лет, когда ты всё это запрогаешь и протестируешь - вот тогда ты можешь якобы облегчить себе жизнь тем, что деплоить эти компоненты за тебя будет не ансибл, а кубер. И виртуалки он же создавать. Но сначала всё равно придётся перелопатить всю архитектуру продукта, что бы быть к этому готовым. > Если смотреть на их EC2-инстансы, то они выходят дороже vds-ок. Но они предоставляют возможность легко и непринуждённо скейлиться на лету в зависимости от загрузки ворклоада. Если приложение уже к этому готово, если оно вообще может скейлиться - да. Но скейлинг != HA. И этот аргумент работает только там, где нагрузка реально сильно скачет. Если мы говорим о внутренних сервисах компании, то там вся нагрузка известна и стабильна. Если о публичных, то обычно тоже стабильна, правда какая-нибудь особо удачная реклама или промо-акция может создать аномальный пик. Но тут надо осторожно - это может быть и ддос, и чей-то кривой скрипт. Ты не хочешь автоматически скейлится под ддос, ддос всё равно победит. Поэтому нужно ли тут мега-быстрое, автоматическое наращивание серверов - спорный момент, от продукта зависит. Да, админ руками это сделает не так быстро, но всё равно через ансибл. То есть речь только про время принятия человеком решения, остальное всё равно автоматика сделает. > Абстракции данного уровня упрощают понимание архитектуры приложения, что уменьшает количество ошибок при реализации. Кубер никак не связан с архитектурой приложения вообще. Это такая накрутка сверху которая тебе виртуалку создаст и контейнеры запустит. Он по определению вообще ничего про архитектуру приложения не знает и знать не может. То, что запускается под кубером также запускается и без кубера, при этом вообще без изменений кода. Что бы как намекает. > Да, добавляется прослойка. Но зато у нас есть чёткое понимание, где что находится, и кто за что отвечает. У тебя есть продукт, про который ты должен понимать где что находится и кто за что отвечает. От продукта ты избавиться не можешь, эта часть по-любому есть. А потом сверху этого у тебя ещё появляется кубер, который начинает мутить воду с миллионами ресурсов, контроллерами этим ресурсов, кластером etcd, собственными особенностями работы, правилами поведения и так далее. И ещё тебе и сам кубер надо сделать HA.  То есть у тебя будет голова за кластер etcd болеть, за куберовский HA, за все эти манипуляции с сетевым трафиком, за прокси которые сервисы ресолвят и так далее, плюс за весь продукт который внутри этого всего запущен. > Эти абстракции разделяют их уровни ответственности, чтобы бизнес мог поднять сложные HA-решения даже обладая специалистами такого уровня, ибо каждый из них работает со своим уровнем абстракции. Эти разделения существуют и без кубера прекрасно. А специалисты "такого уровня" всё равно ничего толком не сделают, хоть с кубером хоть без.  Только с кубером им будет ещё сложнее разобраться в проблемах на продакшене, т.к. технологий становится больше, сложность понимания всё это внутри устроено возрастает. Ну реально, возьми доку на Кубер, прочитай там всё, потом наберись кучу опыта работы с ним и посмоти на эти накопленные знания. Есть наверно разница - всё это себе в голову заливать, или нет? > Но во-первых уже давно сделали overlay2 Есть у тебя виртуалка - запускай там софт. Докер-то зачем? В тестовом окружении - офигенно удобно. На проде - зачем? > Но если нам важно удобство эксплуатации и скорость развёртывания -- то за куб На продакшене в первую очередь всегда стоит надёжность и скорость решения проблем. Чем короче путь от юзера до бизнес-логики и чем он проще, предсказуемее и понятнее - тем быстрее и легче будет решена проблема.  Кубер делает кучу магии - сам меняет правила iptables, например. Админам и программистам точно нужна эта головная боль? Я понимаю ценность виртуальных адресов, и это действительно одно из возможных решений, но далеко не единственное и не лучшее. Вы, такое ощущение, что рассуждаете о простоте с точки зрения когда всё само собой магически работает. Это-то как раз мало кому интересно - когда всё работает. Вопрос что делать когда оно работать перестало. И именно к такой ситуации продукт должен быть максимально готов. Это как какой-нибудь Hibernate - херак херак он за тебя миллион селектов сгенерил, во как круто. А потом что-то сломалось. И как это чинить непонятно - устанешь понимать все нюансы его работы, что бы вычислить в чём проблема. > Обновления в кубе как раз гораздо проще. Я про обновление самого Кубера. Который зависит от докера. И от каких-то кусков линукса типа iptables. И самого докера. И ядра, от которого зависит докер. > Обновить конфигурацию синхронно и без даунтайма -- тоже легче, благодаря операторам. Не знаю что такое операторы, но если сами приложения не поддерживают конфигурирование через кластер, то непонятно как может быть что-то проще, чем запуск одной команды ansible, которая тоже кусками, последовательно запушит конфиги и перезапустит приложения? Что и зачем тут надо упрощать? :) > Не админ, а опс Да ладно, хипстерская тема какая-то, все знают что Operations - т.е. служба эксплуатации по-русски - это админы. :)
	Ответить | Правка | Наверх | Cообщить модератору

	91. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."	+/–
	Сообщение от freehck (ok), 23-Янв-21, 13:17
	Окей, меня полностью устраивает Ваша позиция. Желаю Вам удачи. Продолжим это столкновение взглядов, когда/если встретимся на рынке. =)
	Ответить | Правка | Наверх | Cообщить модератору

14. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."	+2 +/–
Сообщение от Аноним (14), 21-Янв-21, 10:42
Могли бы просто не паковать это, если там такой бардак. Всё равно будут ставить с сайта разработчика.
Ответить | Правка | Наверх | Cообщить модератору

	29. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."	+/–
	Сообщение от пох. (?), 21-Янв-21, 13:15
	> Могли бы просто не паковать это, если там такой бардак. Всё равно > будут ставить с сайта разработчика. говорят же ж тебе - будет вонь что "дебиан не поддерживает (даже!) модный-современный k8s!", донейт упадет еще ниже.
	Ответить | Правка | Наверх | Cообщить модератору

	40. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."	+1 +/–
	Сообщение от Аноним (40), 21-Янв-21, 14:54
	Сделать метапакет, который скачал install.sh с сайта кубернетиса и запустит )
	Ответить | Правка | Наверх | Cообщить модератору

	45. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."	+/–
	Сообщение от пох. (?), 21-Янв-21, 16:34
	дык такой уже есть, wget называетсо.
	Ответить | Правка | Наверх | Cообщить модератору

	60. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."	–1 +/–
	Сообщение от InuYasha (??), 21-Янв-21, 20:26
	Хотел сперва сказать "да выкиньте этот Пубернетис нахрен", но ваша идея мне очень понравилась. Пусть пубер-клёпщики сами ощутят на себе всю тяжесть своего гомна. )
	Ответить | Правка | К родителю #14 | Наверх | Cообщить модератору

19. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."	+/–
Сообщение от Аноним (19), 21-Янв-21, 11:30
В чем проблема собрать статичный бинарь вместо 200? В Go одним ключом решается
Ответить | Правка | Наверх | Cообщить модератору

	21. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."	+/–
	Сообщение от anonymous (??), 21-Янв-21, 11:59
	В Go и есть статичные бинарии, коих в k8s больше одного. Но как-то сильно сомневаюсь, что их там 200. Возможно речь про пакеты с исходными кодами зависимостей?
	Ответить | Правка | Наверх | Cообщить модератору

	24. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."	+2 +/–
	Сообщение от Анончик (?), 21-Янв-21, 12:43
	Ты зачем такое говоришь? Еще скажи что у разработчиков гугла плохо с зависимостями, на замечательном языке гугла https://github.com/kubernetes/kubernetes/blob/master/go.sum Плебс совсем от рук отбился, нет у них веры в гугл и царя.
	Ответить | Правка | Наверх | Cообщить модератору

	53. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."	+/–
	Сообщение от freehck (ok), 21-Янв-21, 18:28
	> Но как-то сильно сомневаюсь, что их там 200. Ты что, не знаешь, что "kubernetes -- это всего пять бинарей"? =) А по факту, на самом деле достаточно kubeadm, kubectl и kubelet. Остальное один фиг в контейнерах живёт.
	Ответить | Правка | К родителю #21 | Наверх | Cообщить модератору

30. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."	+1 +/–
Сообщение от JL2001 (ok), 21-Янв-21, 13:21
всё, накрылась концепция пакетов в дебиане? а был бы nixpkg - мантейнер Kubernetes прописывал бы нужные версии зависимостей для Kubernetes и сами либы были бы в общем репозитории и каждый мантейнер мог бы для своего пакета указать точные проверенные версии зависимостей, а юзер смог бы легко запустить и с другими версиями
Ответить | Правка | Наверх | Cообщить модератору

39. Скрыто модератором	–1 +/–
Сообщение от Аноним (-), 21-Янв-21, 14:34
Корпорасты продавливают свои продукты на своих условиях в ваш хвалёный опинсорц. Смотрите!
Ответить | Правка | Наверх | Cообщить модератору

43. "забавно было бы если бы они отделили зависимости"	+/–
Сообщение от Аноним (43), 21-Янв-21, 15:28
$ ldd /usr/bin/kubelet         linux-vdso.so.1 (0x00007ffceaaed000)         libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f0a927c3000)         libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f0a925bf000)         libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f0a921ce000)         /lib64/ld-linux-x86-64.so.2 (0x00007f0a929e2000)
Ответить | Правка | Наверх | Cообщить модератору

	64. "забавно было бы если бы они отделили зависимости"	+/–
	Сообщение от Аноним (64), 21-Янв-21, 21:07
	Что сказать пытался? Все остальные зависимости для сборки, они скорее всего включены в результирующий бинарник целиком.
	Ответить | Правка | Наверх | Cообщить модератору

	69. "забавно было бы если бы они отделили зависимости"	+1 +/–
	Сообщение от анончик (?), 22-Янв-21, 01:26
	он хотел намекнуть, что библиотеки на go линкуются статически. их билд-система в виде бинарника с именем go вытаскивает из гита, делает из них .obj, если их ещё нет, и линкует используемые тобой части в твой бинарник. это реально всё так, без преувеличений. так что вытаскивать эти дев-зависимости из файла `go.mod` и затаскивать в apt -- это реальная дурка.
	Ответить | Правка | Наверх | Cообщить модератору

49. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."	+/–
Сообщение от Ан О Ним (?), 21-Янв-21, 18:19
Культура на нуле... Люпмен/быдло кодинг.
Ответить | Правка | Наверх | Cообщить модератору

65. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."	+/–
Сообщение от ano (??), 21-Янв-21, 21:19
Главное чтоб uninstall сделали , а то с такой кучей говна - явно не осилят .
Ответить | Правка | Наверх | Cообщить модератору

	81. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."	+/–
	Сообщение от пох. (?), 22-Янв-21, 09:54
	> Главное чтоб uninstall сделали , а то с такой кучей говна - > явно не осилят . uninstall в развернутом кластере делается с помощью бульдозера. Потому что это означает что либо фирма банкрот, либо DC сгорел к херам. Других причин нет, это не пакетик который ставят на посмотреть. Это то, под что всю инфраструктуру и все IT в конторе прогинают. Дистрибутив и вообще какие-то потуги дебианщиков при этом становятся, естественно, совершенно вообще не нужны.
	Ответить | Правка | Наверх | Cообщить модератору

68. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."	+1 +/–
Сообщение от SubGun (??), 21-Янв-21, 23:38
"У нас стандарты," - говорили они. "У нас принципы," - говорили они. Но стоило поднажать, как тут же "продали" все свои принципы.
Ответить | Правка | Наверх | Cообщить модератору

76. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."	+/–
Сообщение от abu (?), 22-Янв-21, 04:17
Ставил скриптами с сайта, админил, даже работало года полтора с Gitlab и CI в свое время именно на Debian. Обновлять надо если не регулярно, то хотя бы раза два в год, проект динамичный, как это будет выглядеть при установке из пакетов - не знаю. Считаю, что ставить k8s на т.н. bare metal, а потом его настраивать, а потом еще и вменяемо админить, дано не каждому и, как мне кажется, мало кому нужно. Все это, как по мне, должно торчать в облаках и админиться за деньги теми, кто это все придумал (для того оно, видимо, когда-то и затевалось). Ну а для неосиляторов или на посмотреть - можно вообще Rancher накатить и тоже посметься. Так что - что из пакетов, что скриптом с сайта - один чорт.
Ответить | Правка | Наверх | Cообщить модератору

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

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