Мы буквально на днях обновляли кластер PG и после обновления ММ стартовал порядка 35 минут.
P.S. для точности, контейнер/под то создается, от начала создания то момента когда сервер начинает слушать порт и отвечать на полезную нагрузку проходит неприлично много времени. Ну и если быть честными не исследовался этот вопрос как следует, видимо какая-то наша проблема и не является wellknow ошибкой.
Немного офтопный вопрос, ММ стартует какое-то неприличное количество времени, поэтому есть некоторые опасения втыкать его в такую динамичную среду как k8s. Не сталкивались с подобным?
Компании тоже имеют свой жизненный цикл. Когда еще состояние стартапа, человек не так много, тимлид и техлид в одном флаконе отличный вариант, все плюшки перечислены в статье выше, в том числе и платить меньше.
В какой части у gitlab функционал богаче? Облако ничем не уступает, а во многом и сильно лучше, тот же менеджент команд сделан куда более пряморуко, github actions выглядят очень перспективно, имхо, лучше чем CI в gitlab. Единственная проблема, что в selfhosted решение github сильно отстаёт от функционала в облаке, по крайней мере так было год назад, когда я заглядывал в описание.
У трекера не подразумевается наличие клиенткого портала. И это если честно большой минус, например, у них у самих весь саппорт вокрут трекера. У я360 все тикеты как в черную дыру уходят, потому что только через письмо или через яндекс форму(ИМХО которую они тоже пихают везде куда надо и не надо, отказываясь делать нормальный функционал, потому то уже сделан какой то воркэраунд на базе форм).
Есть накапливающееся недовольство, а возможности оценить адекватно, кажется ли это или нет, нету, от слова совсем, потому что нет портала и ретроспективно посмореть нельзя.
П.С. я не сотрудник саппорта, просто мимо проходил.
rocket.chat не смотрели. Не смотря на то что необходимости менять стек уже почти 3 месяца, на текущий момент еще много вопросов висит в воздухе. И mattermost был самым быстрым решением, что мы приняли. Он похож на слак, есть какой никакой импорт сообщений, а дальше мы погрузились вот во все те вопросы, что вы описали у себя в исходном сообщении. Переезд почты/файлов/календарей мне еще будет долго сниться в кошмарах.
В результате получилось действительное хорошее решение для SSO, mkdocs неплохое решение для технической документации, а все остальное так или иначе в первом приближении с потерей функционала.
Дальше еще предстоит адаптироваться самим под инструменты, на которые мы переехали или адаптировать инструменты под наши нужды.
С точки зрения такс трекинга я знаю, что коллеги из разработки смотрят еще на платные варианты которые нам доступны внутри страны, но нашему департаменту хватило gitlab. Хотя мы еще ведем дискуссии, как там работать.
Во-первых и в третьих, ваш проект менеджер скорее всего просто соглашается с теми решениями которые вы ему продаёте.
Это точно? откуда вы такие выводы сделали? @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 мы прийдем, но надо идти от простого к сложному.
Так у нас в статье тоже есть ссылка на этот плагин, наверно я не достаточно расписал про него. Мы его так же используем и запускаем нагрузку которая живет в поде нормально именно в небольшом кластере 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 вообще не читайте эту статью :) Она не для вас :)
Тоесть 4 пунтов почему не kubernetes вам не хватило? Сам kubernetes cloud native замечательно, что это меняет ? Нашей нагрузке и процессам лучше на виртуалках чем на подах, поэтому виртуалки.
Статья про идею, а не про велосипед, хотите облако, велком, хотите свои гипервизоры без облака (например как у нас получилось с libvirtd на powerpc), тоже пожалуйcта, прочитайте, используйте, cэкономите время, там правда еще прийдется подумать над парочкой проблем - но все решаемо.
Нет, не слышали. Это всё в k8s, мы в этом направлении только делаем свои первые шаги. Исторически наша экосистема развивалась без него. И вот только несколько причин этого:
Наши продукты мало подходят под запуск в кубере, не все, но в большинстве своём.
У нас есть есть свои плагины для pytest основывающиеся на докере, сами понимаете эспертиза написать что то на докере << запустить все нужные сущности в k8s и потом прибить их. На докере у нас работает все очень быстро. И разработчик может локально тесты запустить без k8s или аналога у себя на машине. Хотя задача использовать в процессе кубер чтобы размазать нагрузку по кластеру, а не на одной ноде jenkins, что в свою очередь позволит добавить параллелизма на CI и сократить время выполнения есть и это ближайшие перспективы.
У нас пока что нет прода который можно было бы засунуть в кубер и для нас это решило бы какие то проблемы.
Засунуть все в куберо не панацея, ноды кубера нужно туда добавлять, хотя кубер как сервис в облаках с этим должен справляться, но что делать если под перерос вашу самую жирную ноду ? Что делать понятно, в общем-то :) В любом случае это не серебрянная пуля, где мозгов не надо, просто спускаешь курок и сразу пожинаешь плоды.
Kубер потребует эволюция экосистемы. Мы еще молодая компания и без кубера стартуется гораздо продуктивнее чем с ним. А уж про найм специалистов которые научились писать ямл для кубера и просят зп выше 300, но на вопросы про ЯП начинают говорить, что для этого есть разработчки, а код писать это не работа девопса, я вообще промолчу.
Спасибо за ссылки, добавим в roadmap команды посмотреть на них.
Я 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.
Мы буквально на днях обновляли кластер PG и после обновления ММ стартовал порядка 35 минут.
P.S. для точности, контейнер/под то создается, от начала создания то момента когда сервер начинает слушать порт и отвечать на полезную нагрузку проходит неприлично много времени. Ну и если быть честными не исследовался этот вопрос как следует, видимо какая-то наша проблема и не является wellknow ошибкой.
Немного офтопный вопрос, ММ стартует какое-то неприличное количество времени, поэтому есть некоторые опасения втыкать его в такую динамичную среду как k8s. Не сталкивались с подобным?
А можно рассказать, что там по разнице? Интересуюсь исключительно из академического интереса.
Компании тоже имеют свой жизненный цикл. Когда еще состояние стартапа, человек не так много, тимлид и техлид в одном флаконе отличный вариант, все плюшки перечислены в статье выше, в том числе и платить меньше.
Можно, но GH предлагает уже рабочий dsl для yaml разработчиков, зачем платить больше в таком случае?
В какой части у gitlab функционал богаче? Облако ничем не уступает, а во многом и сильно лучше, тот же менеджент команд сделан куда более пряморуко, github actions выглядят очень перспективно, имхо, лучше чем CI в gitlab. Единственная проблема, что в selfhosted решение github сильно отстаёт от функционала в облаке, по крайней мере так было год назад, когда я заглядывал в описание.
У трекера не подразумевается наличие клиенткого портала. И это если честно большой минус, например, у них у самих весь саппорт вокрут трекера.
У я360 все тикеты как в черную дыру уходят, потому что только через письмо или через яндекс форму(ИМХО которую они тоже пихают везде куда надо и не надо, отказываясь делать нормальный функционал, потому то уже сделан какой то воркэраунд на базе форм).
Есть накапливающееся недовольство, а возможности оценить адекватно, кажется ли это или нет, нету, от слова совсем, потому что нет портала и ретроспективно посмореть нельзя.
П.С. я не сотрудник саппорта, просто мимо проходил.
rocket.chat не смотрели. Не смотря на то что необходимости менять стек уже почти 3 месяца, на текущий момент еще много вопросов висит в воздухе. И mattermost был самым быстрым решением, что мы приняли. Он похож на слак, есть какой никакой импорт сообщений, а дальше мы погрузились вот во все те вопросы, что вы описали у себя в исходном сообщении. Переезд почты/файлов/календарей мне еще будет долго сниться в кошмарах.
В результате получилось действительное хорошее решение для SSO, mkdocs неплохое решение для технической документации, а все остальное так или иначе в первом приближении с потерей функционала.
Дальше еще предстоит адаптироваться самим под инструменты, на которые мы переехали или адаптировать инструменты под наши нужды.
С точки зрения такс трекинга я знаю, что коллеги из разработки смотрят еще на платные варианты которые нам доступны внутри страны, но нашему департаменту хватило gitlab. Хотя мы еще ведем дискуссии, как там работать.
Это точно? откуда вы такие выводы сделали? @Sunchezzz я с Антоном оказывается обманываю тебя все это время. Надо hadoop с greenplam в кубер засовывать. Это решает все проблемы.
Я вам про Фому, вы мне про Ерему. Кубер молодец, разве я с этим спорил? Главное чтобы и все остальные вокруг были достаточно умны чтобы с этим дальше жить. Я году в 18-ом когда еще ходил на конференции послушать умных людей, слышал только про то, как люди пилили монолиты, мигрировали в k8s, кололись и продолжали есть кактус. Про гонки за ресурсы ядра, утилиты из разряда ebpf, чтобы дебажить эти проблемы. До сих пор по ночам просыпаюсь в холодном поту когда вспоминаю это, если для вас это детский лепет, я опладирую вам стоя - скиньте ссылку на своё резюме :)
Причем тут
heml createс разницой запустить все на докер демоне или все пихнуть в комбайм под названием k8s ? На докере проще закодить, автоматизировать, проще девопс, проще для qa, проще для всех кто с этим кодом работает и поддерживает. А в прочем https://github.com/arenadata/adcm_pytest_plugin welcome, всё открыто, можете запилить нам новый pull request с драйвером на k8s вместо докера.В k8s мы прийдем, но надо идти от простого к сложному.
Я бегло посмотрел,
Так у нас в статье тоже есть ссылка на этот плагин, наверно я не достаточно расписал про него. Мы его так же используем и запускаем нагрузку которая живет в поде нормально именно в небольшом кластере 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 вообще не читайте эту статью :) Она не для вас :)
Тоесть 4 пунтов почему не kubernetes вам не хватило? Сам kubernetes cloud native замечательно, что это меняет ? Нашей нагрузке и процессам лучше на виртуалках чем на подах, поэтому виртуалки.
Статья про идею, а не про велосипед, хотите облако, велком, хотите свои гипервизоры без облака (например как у нас получилось с libvirtd на powerpc), тоже пожалуйcта, прочитайте, используйте, cэкономите время, там правда еще прийдется подумать над парочкой проблем - но все решаемо.
Нет, не слышали. Это всё в k8s, мы в этом направлении только делаем свои первые шаги. Исторически наша экосистема развивалась без него. И вот только несколько причин этого:
Наши продукты мало подходят под запуск в кубере, не все, но в большинстве своём.
У нас есть есть свои плагины для pytest основывающиеся на докере, сами понимаете эспертиза написать что то на докере << запустить все нужные сущности в k8s и потом прибить их. На докере у нас работает все очень быстро. И разработчик может локально тесты запустить без k8s или аналога у себя на машине. Хотя задача использовать в процессе кубер чтобы размазать нагрузку по кластеру, а не на одной ноде jenkins, что в свою очередь позволит добавить параллелизма на CI и сократить время выполнения есть и это ближайшие перспективы.
У нас пока что нет прода который можно было бы засунуть в кубер и для нас это решило бы какие то проблемы.
Засунуть все в куберо не панацея, ноды кубера нужно туда добавлять, хотя кубер как сервис в облаках с этим должен справляться, но что делать если под перерос вашу самую жирную ноду ? Что делать понятно, в общем-то :) В любом случае это не серебрянная пуля, где мозгов не надо, просто спускаешь курок и сразу пожинаешь плоды.
Kубер потребует эволюция экосистемы. Мы еще молодая компания и без кубера стартуется гораздо продуктивнее чем с ним. А уж про найм специалистов которые научились писать ямл для кубера и просят зп выше 300, но на вопросы про ЯП начинают говорить, что для этого есть разработчки, а код писать это не работа девопса, я вообще промолчу.
Спасибо за ссылки, добавим в roadmap команды посмотреть на них.
Я ruby не знаю и даже наверно не сожалею об этом, судя по примеру кода :)
Когда то давно меня в университете учили С, и пример
больше похож на объявление функции, чем на её вызов.
В groovy можно вызывать функции без
()и такой пример кстати будет меньше вызывать вопросов.function var1: value1, var2: value2, body: { my_clousure_body }Update:
Пока искал ссылку на опускание круглых скобок в документации groovy нашел и наконец то одну строку про такой синтаксис и в документации наконец то. https://groovy-lang.org/style-guide.html в 6-ом пункте Omitting parentheses.