Да, в том числе. Но всё таки Gitlab это делает довольно медленно, тот же phpcs-security-audit до недавнего времени использовался по умолчанию для PHP и только 5 месяцев назад миграцию на Semgrep сделали (и то ещё не полноценно) https://gitlab.com/gitlab-org/gitlab/-/issues/364060
Если прочитаете предыдущую статью, станет понятно, что одна из целей - сделать максимально простое и универсальное решение, которое будет покрывать все стадии DevSecOps на любом Gitlab. Если для каждого инструмента делать свои образы, то это лишние заморочки.
в alpine нету bash, в alpine ash
Bash ставился как раз для того, чтобы использовать один и тот же скрипт для обработки артефакта.
(тут скрин с обновлениями Semgrep в Gitlab)
То, что обновления происходят часто - не значит что это актуальные изменения. К тому же, кроме Semgrep там ещё много других внешних инструментов. К тому же, вспоминаем кейс выше с phpcs-security-audit, issue висел 2 года до того, как начали делать миграцию. В любом случае, до конечных пользователей изменения будут приходить с задержкой. Где-то больше, где-то меньше, но задержка будет.
Я понимаю, что тут учебный пример, туториал, но вот прям не хватает описания, а для чего это делается? Вот раннер - это что такое? А для чего? А стадии в CI/CD - это что? В общем, после прочтения статьи останется много вопросов у начинающих.
Я даже сразу решил попробовать на своей убунте, но кажется что-то пошло не так( Не работают подсказки для команд. Возможно конфликтует с tabnine, но в любом случае кроме tabnine других подсказок нет (ни локально, ни по ssh) Ещё в локальном режиме не работает панель с файлами, падает с ошибкой Failed to load file list. По SSH всё работает (не считая подсказок) и в целом выглядит очень круто, как минимум ради этого функционала стоит юзать.
Как человек, который часто работает через консоль, скажу что очень крутая задумка. И почему никто ранее такого не сделал?)) Обязательно испробую функционал
С обновлением контента да, мы тоже долго думали как лучше делать. Пришли к выводу, что бэкенд при изменении сущностей - передаёт информацию, что обновилось. Далее фронт ищет вхождение и перегенерирует кэш для них
Вот согласен. Особенно "порадовало", что в статье Self-Hosted решение подаётся как волшебная пилюля: и надёжно, и без санкций, и дешевле. Забывая про то, что нужно уметь его администрировать: если активно использовать Registry и CI/CD, то гитлаб ест место на диске как не в себя (+ всякие прометеусы там), нужно уметь настраивать раннеров, постоянно обновлять версию гитлаба, т.к. довольно часто находят критичные уязвимости, ну и про бэкапы не забываем.
Олег, привет! Начал читать статью, увидел про tramvai, понял, что уже видел эту статью у тебя в ТГ) Есть такой вопросик: допустим есть сайт с динамикой, но без какой-то персонализации. Есть ли вариант использования SSG в этом случае, или хватанём больше проблем, чем профита?
Вот я тоже прочитал и первым делом подумал, а как это можно внедрить на проекте? Вот у меня есть уже БД, как это сделать на ней? Или можно тестировать только в дебаг режиме?
У вас по сути за всё это и должен отвечать API Gateway. Сейчас же RabbitMQ используется ради того, чтобы был RabbitMQ, каких-то плюсов в такой реализации нет, более того, сильно увеличивается время ответа
Да, планирую выложить 4 часть на следующей неделе
Спасибо за проявленный интерес к статье и за комментарий!
Возможно, но нельзя сказать со 100% уверенностью. К тому же, главная цель статьи, показать существующие возможности.
Да, в том числе. Но всё таки Gitlab это делает довольно медленно, тот же phpcs-security-audit до недавнего времени использовался по умолчанию для PHP и только 5 месяцев назад миграцию на Semgrep сделали (и то ещё не полноценно) https://gitlab.com/gitlab-org/gitlab/-/issues/364060
Если прочитаете предыдущую статью, станет понятно, что одна из целей - сделать максимально простое и универсальное решение, которое будет покрывать все стадии DevSecOps на любом Gitlab. Если для каждого инструмента делать свои образы, то это лишние заморочки.
Bash ставился как раз для того, чтобы использовать один и тот же скрипт для обработки артефакта.
То, что обновления происходят часто - не значит что это актуальные изменения.
К тому же, кроме Semgrep там ещё много других внешних инструментов.
К тому же, вспоминаем кейс выше с phpcs-security-audit, issue висел 2 года до того, как начали делать миграцию.
В любом случае, до конечных пользователей изменения будут приходить с задержкой. Где-то больше, где-то меньше, но задержка будет.
Опять же, я рассказываю про то, какие инструменты есть. Использовать их или нет - решает каждый сам для себя :)
Рекомендую всё таки прочитать (в том числе другие части), чтобы была более целостная картина, надеюсь будет полезно
Спасибо за то, что поделились мнением)
Я понимаю, что тут учебный пример, туториал, но вот прям не хватает описания, а для чего это делается? Вот раннер - это что такое? А для чего? А стадии в CI/CD - это что? В общем, после прочтения статьи останется много вопросов у начинающих.
Да, ошибка есть, вот скрин: https://ok-scr.ru/0210c03a.png
Я даже сразу решил попробовать на своей убунте, но кажется что-то пошло не так(
Не работают подсказки для команд. Возможно конфликтует с tabnine, но в любом случае кроме tabnine других подсказок нет (ни локально, ни по ssh)
Ещё в локальном режиме не работает панель с файлами, падает с ошибкой Failed to load file list.
По SSH всё работает (не считая подсказок) и в целом выглядит очень круто, как минимум ради этого функционала стоит юзать.
Как человек, который часто работает через консоль, скажу что очень крутая задумка. И почему никто ранее такого не сделал?)) Обязательно испробую функционал
Интересно, спасибо за ответ)
Только мне кажется ручной запуск утомляет немного (слишком часто приходится лезть в пайплайны)
С обновлением контента да, мы тоже долго думали как лучше делать. Пришли к выводу, что бэкенд при изменении сущностей - передаёт информацию, что обновилось. Далее фронт ищет вхождение и перегенерирует кэш для них
Вот согласен. Особенно "порадовало", что в статье Self-Hosted решение подаётся как волшебная пилюля: и надёжно, и без санкций, и дешевле. Забывая про то, что нужно уметь его администрировать: если активно использовать Registry и CI/CD, то гитлаб ест место на диске как не в себя (+ всякие прометеусы там), нужно уметь настраивать раннеров, постоянно обновлять версию гитлаба, т.к. довольно часто находят критичные уязвимости, ну и про бэкапы не забываем.
Олег, привет!
Начал читать статью, увидел про tramvai, понял, что уже видел эту статью у тебя в ТГ)
Есть такой вопросик: допустим есть сайт с динамикой, но без какой-то персонализации. Есть ли вариант использования SSG в этом случае, или хватанём больше проблем, чем профита?
Вот я тоже прочитал и первым делом подумал, а как это можно внедрить на проекте? Вот у меня есть уже БД, как это сделать на ней? Или можно тестировать только в дебаг режиме?
Подскажите, а как именно вы боретесь с этой проблемой?
То что нужно, чтобы работать в Google Chrome :)
Как минимум способы становятся всё более изощрёнными, недолго и параноиком стать :)
У вас по сути за всё это и должен отвечать API Gateway. Сейчас же RabbitMQ используется ради того, чтобы был RabbitMQ, каких-то плюсов в такой реализации нет, более того, сильно увеличивается время ответа