Комментарии 10
Если честно, мне этот синтаксис до сих пор взрывает мозг
Да вроде норм, в других языках похожие вещи есть.
В ruby например примерно такое-же называется блоками:def example
yield 101
end
example do |i|
# any code
# i будет равен 101
puts i * 10
end
example {|i| puts i * 100}
Результат:
1010
10100
P.S. не могу понять как нормально оформить код в новом редакторе хабра, сори =(
Я ruby не знаю и даже наверно не сожалею об этом, судя по примеру кода :)
Когда то давно меня в университете учили С, и пример
function (var1, var2, var3){
somebody
}больше похож на объявление функции, чем на её вызов.
В groovy можно вызывать функции без () и такой пример кстати будет меньше вызывать вопросов.
function var1: value1, var2: value2, body: { my_clousure_body }
Update:
Пока искал ссылку на опускание круглых скобок в документации groovy нашел и наконец то одну строку про такой синтаксис и в документации наконец то. https://groovy-lang.org/style-guide.html в 6-ом пункте Omitting parentheses.
прям стесняюсь спросить, а зачем весь этот секс с добавлением слейвов или вы про jenkins helm chart не слышали и cluster-autoscaler pipeline{agent{any{}}} ?
Нет, не слышали. Это всё в k8s, мы в этом направлении только делаем свои первые шаги. Исторически наша экосистема развивалась без него. И вот только несколько причин этого:
Наши продукты мало подходят под запуск в кубере, не все, но в большинстве своём.
У нас есть есть свои плагины для pytest основывающиеся на докере, сами понимаете эспертиза написать что то на докере << запустить все нужные сущности в k8s и потом прибить их. На докере у нас работает все очень быстро. И разработчик может локально тесты запустить без k8s или аналога у себя на машине. Хотя задача использовать в процессе кубер чтобы размазать нагрузку по кластеру, а не на одной ноде jenkins, что в свою очередь позволит добавить параллелизма на CI и сократить время выполнения есть и это ближайшие перспективы.
У нас пока что нет прода который можно было бы засунуть в кубер и для нас это решило бы какие то проблемы.
Засунуть все в куберо не панацея, ноды кубера нужно туда добавлять, хотя кубер как сервис в облаках с этим должен справляться, но что делать если под перерос вашу самую жирную ноду ? Что делать понятно, в общем-то :) В любом случае это не серебрянная пуля, где мозгов не надо, просто спускаешь курок и сразу пожинаешь плоды.
Kубер потребует эволюция экосистемы. Мы еще молодая компания и без кубера стартуется гораздо продуктивнее чем с ним. А уж про найм специалистов которые научились писать ямл для кубера и просят зп выше 300, но на вопросы про ЯП начинают говорить, что для этого есть разработчки, а код писать это не работа девопса, я вообще промолчу.
Спасибо за ссылки, добавим в roadmap команды посмотреть на них.
вы пишите "мы работаем в облаке" - kubernetes это самый что ни на есть cloud native, странно, что вместо него вы поднимаете какие-то виртуалки и тратите кучу сил чтобы изобрести свой собственный велосипед
Тоесть 4 пунтов почему не kubernetes вам не хватило? Сам kubernetes cloud native замечательно, что это меняет ? Нашей нагрузке и процессам лучше на виртуалках чем на подах, поэтому виртуалки.
Статья про идею, а не про велосипед, хотите облако, велком, хотите свои гипервизоры без облака (например как у нас получилось с libvirtd на powerpc), тоже пожалуйcта, прочитайте, используйте, cэкономите время, там правда еще прийдется подумать над парочкой проблем - но все решаемо.
В четвёртых, почитайте про HPA и для чего он нужен
Во-вторых, в чём проблема разрабатывать так как привык devteam в своём докер-компосе, а тестить и релизиться в хелм чартах? helm create слишком сложен для вас?
Во-первых и в третьих, ваш проект менеджер скорее всего просто соглашается с теми решениями которые вы ему продаёте
PS: справедливости ради сказать, ваш скил в Groovy достоин лучшего применения
Во-первых и в третьих, ваш проект менеджер скорее всего просто соглашается с теми решениями которые вы ему продаёте.
Это точно? откуда вы такие выводы сделали? @Sunchezzz я с Антоном оказывается обманываю тебя все это время. Надо hadoop с greenplam в кубер засовывать. Это решает все проблемы.
В четвёртых, почитайте про HPA и для чего он нужен
Я вам про Фому, вы мне про Ерему. Кубер молодец, разве я с этим спорил? Главное чтобы и все остальные вокруг были достаточно умны чтобы с этим дальше жить. Я году в 18-ом когда еще ходил на конференции послушать умных людей, слышал только про то, как люди пилили монолиты, мигрировали в k8s, кололись и продолжали есть кактус. Про гонки за ресурсы ядра, утилиты из разряда ebpf, чтобы дебажить эти проблемы. До сих пор по ночам просыпаюсь в холодном поту когда вспоминаю это, если для вас это детский лепет, я опладирую вам стоя - скиньте ссылку на своё резюме :)
Во-вторых, в чём проблема разрабатывать так как привык devteam в своём докер-компосе, а тестить и релизиться в хелм чартах?
helm createслишком сложен для вас?
Причем тут heml create с разницой запустить все на докер демоне или все пихнуть в комбайм под названием k8s ? На докере проще закодить, автоматизировать, проще девопс, проще для qa, проще для всех кто с этим кодом работает и поддерживает. А в прочем https://github.com/arenadata/adcm_pytest_plugin welcome, всё открыто, можете запилить нам новый pull request с драйвером на k8s вместо докера.
В k8s мы прийдем, но надо идти от простого к сложному.
Я бегло посмотрел,
This chart installs a Jenkins server which spawns agents on Kubernetes utilizing the Jenkins Kubernetes plugin.
Так у нас в статье тоже есть ссылка на этот плагин, наверно я не достаточно расписал про него. Мы его так же используем и запускаем нагрузку которая живет в поде нормально именно в небольшом кластере k8s.
Правильно я понимаю что если если jenkins master переместить в k8s тогда достаточно pipeline{agent{any{}}} вместо podTemplate { node(POD_LABEL) {stage('Run shell') {sh 'echo hello world'}}} ? Немного проще, но если нужен не дефолтный pod то скорей всего any{} не подойдет и надо будет объявлять кастомный темплейт в конфиге для heml, по сути просто перенос описания из одного места в другое.
В общем то да, если есть подходящая нагрузка то этот плагин делает тоже самое, что и "весь это секс" но на виртуалках.
Опять же, https://plugins.jenkins.io/kubernetes/ написан на java, умеете java, написать такой же плагин под compute engine облака которое вам надо не составит труда. Умеете java вообще не читайте эту статью :) Она не для вас :)
Балансируем нагрузку в Jenkins