Есть комьюнити гитлаб, который можно установить на свои сервера.
Наговнокодить можно на чём угодно, но на некоторых это сделать проще. Язык си например заточен под то чтобы как можно проще и качественнее стрелять себе в ногу.
Ну в смысле в статье стоило бы сравнить важные фичи этих систем. Какие источники действий и триггеры они могут обслуживать, возможности по построению и управлению пайплайнами, возможности организации интерфейса для работы с пользователями/управления пайплайнами, ролевую модель доступа, интеграцию с внешними системами (от sonarqube до jira и kubernetes). В этой же статье, сравнивается скорее ваш опыт работы с этими системами. И поскольку с гитлаб он кажется не велик, тут идёт очевидный перекос...
По большому счету, что должна делать CI/CD система? Она должна определить наступление какого-то события, запустить действие, соответствующее этому событию, понять успешно ли оно завершилось, сохранить логи выполнения действия и, возможно, какой-то артефакт.
Событием может быть комит в гит, ручное действие, внешний триггер, завершение другого пайплайна, и обе эти системы +/- с этим справляются.
Но! Gitlab это opinionated система. Тоесть у неё есть своё мнение как хорошо и правильно делать CI/CD. На гитлаб довольно не просто сделать плохо. Гитлаб это пайплайны как код, который лежит фактически совместно с вашим репозиторием и является его частью.
Jenkins же это одна большая головная боль. Большинство инсталляций дженкинса превращаются со временем в помойку, где намешаны какие-то горе-плагины, кривые дженкинсфайлы и куски говнокода на груви (на котором наговнокодить почему-то легче чем на том же баше).
Я не знаю, каких возможностей гитлаб не хватает любителям дженкинса. Скорее всего это от того что они либо не разобрались в гитлаб, либо хотят странного.
Ну например это заявление в статье: гитлпб поддерживает только баш. В гитлаб ты можешь задать свой экзекутор - от пауэршелл до кастомного бинаря. Но я не понимаю людей, которые пишут гигантские портянки на баше или груви в CI/CD. 10 строк кода на джоб - всё что нужно в 99% при правильно спроектированном процессе CI/CD. Ну максимум 20. Если вы не можете убраться в этот предел, возможно написание пайплайнов не для вас?
По большому счету, программисту программисту нужно знать только место где можно описать свой параметр, и чтобы он при сборке попал в приложение. Что-то наподобие .env файла.
В случае хелма, values.yaml с разбивкой по энвайрментам с блоком кода для динамического формирования секции env, аналогичным тому который я привёл в пункте 2.3 первой части статьи, на 90% решают эту задачу (я даже сделал ремарку в статье: Этот способ описания очень любят разработчики, поскольку оно достаточно простое и наглядное.). Остальные 10% это секретные переменные, с которыми нужно чуть больше телодвижений.
Также хочу заметить что отдельный values.yaml для каждой среды, на мой взгляд, не очень хорошо. В этом случае теряется наглядность. В прошлой статье (https://habr.com/ru/company/dataart/blog/588258/) я давал пример каким образом можно создать один values.yaml для всех окружений при помощи go templates (см. 2.3. Хорошие практики values.yaml).
Прошу прощения, но этот вариант описан буквально в следующем примере. (см. Впрочем, подобные конструкции можно оптимизировать при помощи функции toYaml)
К сожалению, возможности разметки на хабре не позволяют расставлять акценты в коде так как мне бы этого хотелось. В дисклеймере к статье это указано. Также там дана ссылка на репозиторий на гитхабе где эти примеры содержатся в текстовом виде, доступном для поиска.
Нужно отделять мух от котлет, а секьюрность от деплоя. Программист может не иметь доступа к cd системе и кластеру и не видеть ни её защищённое хранилище, ни нутрянку кластера, и при этом легко вытащить пароли, потомучто в контейнерах крутится его код и выложить содержимое переменных окружения на отдельный локейшен например - как два байта п. Совет "не используйте пароли из вэльюс" в общем случае очень наивный.
Egress IP доступен из коробки в OpenShift уже много лет как. Стейтфул в кубе использовать не проблема, была бы хорошая сетевая хранилка. Не очень понимаю большинство описанных болей.
Не обязательно. Всё зависит от того как в данном конкретном случае организована работа с секретами. Они могут передаваться из защищенного хранилища ci системы через директиву set или лежать в зашифрованном виде в values в репозитории.
Go templates очень мощный и гибкий инструмент если умеешь им пользоваться. Этому собственно и посвещена статья. В ошибках апгрейда хелм как правило не виноват. Там либо чарт кривой(иммутабельные поля правятся например), либо выкат (включен трекинг и выкат сфэйлился по таймауту). Про отладку чартов в следубщей части.
С несколькими кластерами чего?
Есть комьюнити гитлаб, который можно установить на свои сервера.
Наговнокодить можно на чём угодно, но на некоторых это сделать проще. Язык си например заточен под то чтобы как можно проще и качественнее стрелять себе в ногу.
Я примерно это и имел в виду. Не можем принять запрос = не можем обработать.
Ну в смысле в статье стоило бы сравнить важные фичи этих систем. Какие источники действий и триггеры они могут обслуживать, возможности по построению и управлению пайплайнами, возможности организации интерфейса для работы с пользователями/управления пайплайнами, ролевую модель доступа, интеграцию с внешними системами (от sonarqube до jira и kubernetes). В этой же статье, сравнивается скорее ваш опыт работы с этими системами. И поскольку с гитлаб он кажется не велик, тут идёт очевидный перекос...
Статья ни о чем.
По большому счету, что должна делать CI/CD система? Она должна определить наступление какого-то события, запустить действие, соответствующее этому событию, понять успешно ли оно завершилось, сохранить логи выполнения действия и, возможно, какой-то артефакт.
Событием может быть комит в гит, ручное действие, внешний триггер, завершение другого пайплайна, и обе эти системы +/- с этим справляются.
Но! Gitlab это opinionated система. Тоесть у неё есть своё мнение как хорошо и правильно делать CI/CD. На гитлаб довольно не просто сделать плохо. Гитлаб это пайплайны как код, который лежит фактически совместно с вашим репозиторием и является его частью.
Jenkins же это одна большая головная боль. Большинство инсталляций дженкинса превращаются со временем в помойку, где намешаны какие-то горе-плагины, кривые дженкинсфайлы и куски говнокода на груви (на котором наговнокодить почему-то легче чем на том же баше).
Я не знаю, каких возможностей гитлаб не хватает любителям дженкинса. Скорее всего это от того что они либо не разобрались в гитлаб, либо хотят странного.
Ну например это заявление в статье: гитлпб поддерживает только баш. В гитлаб ты можешь задать свой экзекутор - от пауэршелл до кастомного бинаря. Но я не понимаю людей, которые пишут гигантские портянки на баше или груви в CI/CD. 10 строк кода на джоб - всё что нужно в 99% при правильно спроектированном процессе CI/CD. Ну максимум 20. Если вы не можете убраться в этот предел, возможно написание пайплайнов не для вас?
Статья по итогам доклада на Highload++
https://youtu.be/y8diUsNPc6w
По большому счету, программисту программисту нужно знать только место где можно описать свой параметр, и чтобы он при сборке попал в приложение. Что-то наподобие .env файла.
В случае хелма, values.yaml с разбивкой по энвайрментам с блоком кода для динамического формирования секции env, аналогичным тому который я привёл в пункте 2.3 первой части статьи, на 90% решают эту задачу (я даже сделал ремарку в статье: Этот способ описания очень любят разработчики, поскольку оно достаточно простое и наглядное.). Остальные 10% это секретные переменные, с которыми нужно чуть больше телодвижений.
Также хочу заметить что отдельный values.yaml для каждой среды, на мой взгляд, не очень хорошо. В этом случае теряется наглядность. В прошлой статье (https://habr.com/ru/company/dataart/blog/588258/) я давал пример каким образом можно создать один values.yaml для всех окружений при помощи go templates (см. 2.3. Хорошие практики values.yaml).
Прошу прощения, но этот вариант описан буквально в следующем примере. (см. Впрочем, подобные конструкции можно оптимизировать при помощи функции toYaml)
К сожалению, возможности разметки на хабре не позволяют расставлять акценты в коде так как мне бы этого хотелось. В дисклеймере к статье это указано. Также там дана ссылка на репозиторий на гитхабе где эти примеры содержатся в текстовом виде, доступном для поиска.
Нужно отделять мух от котлет, а секьюрность от деплоя. Программист может не иметь доступа к cd системе и кластеру и не видеть ни её защищённое хранилище, ни нутрянку кластера, и при этом легко вытащить пароли, потомучто в контейнерах крутится его код и выложить содержимое переменных окружения на отдельный локейшен например - как два байта п. Совет "не используйте пароли из вэльюс" в общем случае очень наивный.
Egress IP доступен из коробки в OpenShift уже много лет как. Стейтфул в кубе использовать не проблема, была бы хорошая сетевая хранилка. Не очень понимаю большинство описанных болей.
А в yaml чего он должен светиться?
Не обязательно. Всё зависит от того как в данном конкретном случае организована работа с секретами. Они могут передаваться из защищенного хранилища ci системы через директиву set или лежать в зашифрованном виде в values в репозитории.
Go templates очень мощный и гибкий инструмент если умеешь им пользоваться. Этому собственно и посвещена статья. В ошибках апгрейда хелм как правило не виноват. Там либо чарт кривой(иммутабельные поля правятся например), либо выкат (включен трекинг и выкат сфэйлился по таймауту). Про отладку чартов в следубщей части.