я не до конца понял что хотел автор в статье где " джоб сразу после запуска ручной джобы." но помоему это решается "needs:", который требует успешной джобы для своего старта.
Я например пока не понял точно чем заменить try из дженкинса в gitlab ci
Главный пайпы в корне проекта, а вот его дочерние это например api и rabbitmq, запускаются вместе, но можно и раздельно если надо. Депсов может быть много, rabbitmq, redis, redis-insight, db - каждому свой пайп, и все объединены
У нас подключаемый темплейт на сотни строк, а в каждом проекте лежит gitlab-ci.yaml только с нужными для разрабов переменным. Залог того, что никто не накосячит в ci
Я тоже изначально начал просто писать в обсидиан, потом начал раскладывать по папкам. Потом создал шаблон для заметки, каждый день создаю новую заметку с датой в теме (с помощью плагина), в заметке пишу все в течение дня и ставлю теги (линукс, еластиксерч, кейс, факап и тд). В конце дня стараюсь (но не всегда получается) делаю ревизию и добавляю теги, кладу в папку "работы". Отдельные заметки со своими темами создаю с тегами и раскладывать по папкам. Стараюсь не усложнять схему, все работает интуитивно...
Отличная статья, спасибо! Дала пищу для размышления и натолкнула на подход оптимизации. Не все способы мне подошли, но часть я применил. Например у меня есть куча полей в логе от k8s, и других, которые не используются в полнотекстовом поиске, так как они состоят в основном из 1 слова - я их превратил в keyword. Оставил только одно поле в формате text с длинным текстом, откуда парсится вся оснавная инфа. Числовые поля, типа версии, замапил в байт (хотя можно и в version). Так прошелся по всем полям, выбрал им оптимальные типы, и логи в среднем стали меньше на 25%. Это все можно делать в разных индекс темплейтах для плавного перехода или для диффиренциации логов.
Если использовать хелм для деплоя, то можно использовать buildArgs и deployArgs в values.yaml для передачи переменных в контейнер, а там уже забирать их из окружения и подменять ими переменные объявленные в application.yaml.
Таким образом можно передеплоивать приложение изменяя deployArgs без нужды пересборки образа, например передавая их из cicd или gitlab variables.
Привет, мы тоже используем шаблоны CI/CD gitlab с helm, есть базовый шаблон, который подключён в gitlab-ci.yaml, где перезаписываются некоторые параметры базового шаблона.
Основные стадии: build, deploy в разное окружение, post-deploy и rollback.
Там много плюшек, но главное достоинство этого пайплайна - на нем можно запустить любой проект на любом языке, хоть самописные на java, python, js, хоть готовые redis, rabbitmq и тд.
я не до конца понял что хотел автор в статье где " джоб сразу после запуска ручной джобы." но помоему это решается "needs:", который требует успешной джобы для своего старта.
Я например пока не понял точно чем заменить try из дженкинса в gitlab ci
полностью поддерживаю, это абсолютно рабочий подход, возможно даже более гибкий чем интеграция
Главный пайпы в корне проекта, а вот его дочерние это например api и rabbitmq, запускаются вместе, но можно и раздельно если надо. Депсов может быть много, rabbitmq, redis, redis-insight, db - каждому свой пайп, и все объединены
Хорошее решение это темплейт, один для всех, а дебажить придётся только то, что конкретно в приложении
У нас подключаемый темплейт на сотни строк, а в каждом проекте лежит gitlab-ci.yaml только с нужными для разрабов переменным. Залог того, что никто не накосячит в ci
Я тоже изначально начал просто писать в обсидиан, потом начал раскладывать по папкам. Потом создал шаблон для заметки, каждый день создаю новую заметку с датой в теме (с помощью плагина), в заметке пишу все в течение дня и ставлю теги (линукс, еластиксерч, кейс, факап и тд). В конце дня стараюсь (но не всегда получается) делаю ревизию и добавляю теги, кладу в папку "работы". Отдельные заметки со своими темами создаю с тегами и раскладывать по папкам. Стараюсь не усложнять схему, все работает интуитивно...
Отличная статья, спасибо! Дала пищу для размышления и натолкнула на подход оптимизации. Не все способы мне подошли, но часть я применил. Например у меня есть куча полей в логе от k8s, и других, которые не используются в полнотекстовом поиске, так как они состоят в основном из 1 слова - я их превратил в keyword. Оставил только одно поле в формате text с длинным текстом, откуда парсится вся оснавная инфа. Числовые поля, типа версии, замапил в байт (хотя можно и в version). Так прошелся по всем полям, выбрал им оптимальные типы, и логи в среднем стали меньше на 25%. Это все можно делать в разных индекс темплейтах для плавного перехода или для диффиренциации логов.
Если использовать хелм для деплоя, то можно использовать buildArgs и deployArgs в values.yaml для передачи переменных в контейнер, а там уже забирать их из окружения и подменять ими переменные объявленные в application.yaml.
Таким образом можно передеплоивать приложение изменяя deployArgs без нужды пересборки образа, например передавая их из cicd или gitlab variables.
Привет, мы тоже используем шаблоны CI/CD gitlab с helm, есть базовый шаблон, который подключён в gitlab-ci.yaml, где перезаписываются некоторые параметры базового шаблона.
Основные стадии: build, deploy в разное окружение, post-deploy и rollback.
Там много плюшек, но главное достоинство этого пайплайна - на нем можно запустить любой проект на любом языке, хоть самописные на java, python, js, хоть готовые redis, rabbitmq и тд.
Также используем шаблонизированный хелм чарт.