Давно присматривался к GitHub Pages, но руки никак не доходили.

Внезапно решил навести порядок на площадках, где публикую статьи и заметки, и решился-таки на статику (как доп. площадку).

Всякие разные Pages

GitHub Pages нативно поддерживает Jekyll — пушнул в репозиторий, и сайт сам собрался. Никаких докеров, никаких CI/CD (ну почти), никаких серверов.

А чтобы было совсем хорошо, решил поддерживать и GitLab Pages — для симметрии. Чтоб не привязываться к одной платформе и чтоб было куда переключиться, если что. Но тут без CI/CD никак.

Структура репозитория и настройки

Репозиторий называется как положено — kinnalru.github.io - тогда он будет доступен по этому доменному имени. Gemfile:

gem "github-pages", group: :jekyll_pluginsgroup :jekyll_plugins do  gem "jekyll-feed"  gem "jekyll-sitemap"end

Обратите внимание на github-pages — это мета-гем, который тянет Jekyll и все нужные плагины в совместимых версиях. Никаких “а у меня работает”, потому что GitHub Pages собирает ровно тем же набором.

Заполняем конфигурацию _config.yml где выбираем тему, плагины, и всякие настройки. Тема minima — адаптивная под светлую/темную тему. И сразу же в конфиге ссылочки на все свои ресурсы: GitLab , GitHub , Teletype , Telegram , Dev.to. Чтоб гость зашел и сразу понял, где меня искать, а то вдруг нигде раньше не нашел ссылок :)

GitLab Pages — симметрия ради симметрии

Для GitLab Pages пришлось чуть заморочиться. GitHub Pages собирает Jekyll сам, а GitLab — нет, нужен .gitlab-ci.yml:

image: ruby:3.2-slimbuild:  script:    - apt-get update -y; apt-get install -y build-essential    - bundle    - JEKYLL_ENV=production bundle exec jekyll build --config _config.yml,_config.gitlab.yml -d ./public/  pages:    publish: public  rules:    - if: ($CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH) && ($CI_PIPELINE_SOURCE != "schedule")

И отдельный _config.gitlab.yml — переопределяем только url :

url: https://kinnalru.gitlab.io

Jekyll умеет мержить конфиги при сборке: --config _config.yml,_config.gitlab.yml. Всё, что идет справа, переопределяет то, что слева.

Чтоб было “хорошо” — намазал сверху RSS и Sitemap

Просто собирать HTML — это скучно. Мне нужно, чтоб поисковики индексировали, а читатели подписывались. Поэтому сверху еще и:

• ставим плагин jekyll-sitemap, и он автоматически генерирует /sitemap.xml. Но я не доверяю автоматике до конца, поэтому в _includes/custom-head.html добавил явную ссылку:

  <link rel="sitemap" type="application/xml" title="Sitemap" href="/sitemap.xml" />

• ставим плагин jekyll-feed — он генерирует базовый /feed.xml
• но я решил, что хочу RSS с полным контентом статей и расширенными настройками, поэтому написал свой шаблон feed.xml

Кастомные шаблоны

Стандартная minima хороша, но мне хотелось, чтоб на каждом посте была ссылка на оригинальную публикацию. Переопределил _layouts/post.html и _layouts/home.html — добавил canonical_url и пометку “Моя публикация на …“. Теперь зеркало не выглядит как украденный контент, а как полноценный агрегатор.

Что в итоге?

В результате мы имеем:

• Статический сайт на Jekyll, который собирается автоматически
• Зеркало на GitHub Pages — kinnalru.github.io
• Зеркало на GitLab Pages — kinnalru.gitlab.io
• RSS с полным контентом для подписчиков и дальнейшей обработки
• Sitemap для поисковиков
• Все ссылки на мои ресурсы в одном месте

Keep it simple, stupid — но при этом всё должно работать.

Иногда хочется, чтобы всё было просто. Взял Rails-приложение, завернул в Docker, запустил — и оно работает. Без отдельной СУБД, без монтирования хранилища для картинок и пр.

Но вот незадача: если взять SQLite, положить её в контейнер и запустить — при docker rm ваша база улетает в никуда. Навсегда. Вместе с пользователями, настройками и всем, что вы так старательно назаполняли.

Сегодня расскажу, как я в pet-проекте RuNiT решил эту проблему с помощью Litestream — и просто кайфую.

Проблема

Классический путь деплоя pet-проекта выглядит так:

1. Поднять PostgreSQL в отдельном контейнере (найти под него постоянное хранилище и сервак)
2. Прокинуть volume
3. Понять, что вы тратите больше времени на администрирование СУБД, и хранилище картинок, чем на разработку фич

Для pet-проекта это ощутимый оверхед. SQLite решает первый пункт, но создаёт два других:

• файл базы живёт внутри контейнера и при пересоздании исчезает
• бэкапов нет, и если сервер упал — всё, приплыли.

Тут бы и сказать “ну, SQLite не для продакшена”, но мне как-то попадался проект Litestream - Streaming SQLite Replication

Litestream

Litestream — это standalone-утилита (написана на Go, ~14k stars на GitHub) для потоковой репликации SQLite. Она следит за WAL (Write-Ahead Log) вашей базы и в реальном времени отправляет изменения в S3-совместимое хранилище: Yandex Object Storage, MinIO, RustFS и многие другие.

Умеет:

• Continuous backup — каждая транзакция стримится в облако почти мгновенно
• Restore при старте — при пересоздании контейнера база автоматически восстанавливается из реплики
• Point-in-time recovery — можно откатиться к состоянию на конкретную секунду.
• Ноль изменений в коде приложения — Litestream работает как отдельный процесс.
• Дёшево — object storage стоит копейки.

Звучит как магия? По сути — да. Но магия очень простая и надёжная - разработчик говорит что работает в проде стабильно.

Как запустить

Тыкать надо тут следующее:

Устанавливаем Litestream прямо в образ:

#DockerfileRUN set -ex  && curl -sL https://github.com/benbjohnson/litestream/releases/download/v0.5.9/litestream-0.5.9-linux-x86_64.deb -o litestream.deb \  && dpkg -i litestream.deb \  && rm litestream.deb

Передаём credentials для S3 и URL реплики:

services:  app:    environment:      - LITESTREAM_ACCESS_KEY_ID=${LITESTREAM_ACCESS_KEY_ID-key}      - LITESTREAM_SECRET_ACCESS_KEY=${LITESTREAM_SECRET_ACCESS_KEY-secret}      - REMOTE_S3_FILE=${REMOTE_S3_FILE-s3://11.11.11.11:9000/}

Главный трюк — в docker/start_service.sh, который является CMD в Dockerfile:

set -ex# 1. Восстановить базу из S3, если она не существует локальноlitestream restore  -o storage/${RAILS_ENV}.sqlite3  -if-replica-exists  -if-db-not-exists  ${REMOTE_S3_FILE}/${RAILS_ENV}.sqlite3# 2. Стандартные Rails шаги (idempotent — безопасны для существующей базы)bundle exec rails db:createbundle exec rails db:migratebundle exec rails db:seed# 3. Запускаем Rails ПОД управлением Litestreamexec bundle exec litestream replicate  -exec "rails s"  storage/${RAILS_ENV}.sqlite3  ${REMOTE_S3_FILE}/${RAILS_ENV}.sqlite3

Что здесь происходит:

1. litestream restore — если локального файла storage/production.sqlite3 нет, а в S3 есть бэкап, база скачивается. Флаги -if-replica-exists и -if-db-not-exists делают команду безопасной: она не упадёт, если бэкапа ещё нет (первый деплой), и не перезапишет существующую базу если она есть

2. db:create db:migrate db:seed — классика Rails

3. litestream replicate -exec “rails s” — Litestream запускается как supervisor. Он начинает реплицировать WAL в S3 и одновременно запускает дочерний процесс rails s. Если Rails упадёт, Litestream тоже завершится.

Результат: контейнер можно остановить, удалить, пересоздать на другом хосте — база восстановится из S3 и продолжит реплицироваться. Красота!

Профит и подводные камни

Плюсы:

• Минимальная инфраструктура — один контейнер, без отдельной СУБД
• Персистентность — данные не пропадают при удалении контейнера
• Бэкап “из коробки” — каждая транзакция летит в S3, RPO стремится к нулю
• Простое восстановление — litestream restore или автовосстановление при старте
• Дёшево — SQLite бесплатна, object storage стоит копейки
• Не требует изменений в коде приложения
• Point-in-time recovery — можно восстановить базу на конкретный момент времени

Минусы:

• Только один writer — SQLite поддерживает только одного писателя. Это значит, что приложение должно работать в единственном экземпляре (single-node). Ни о каком горизонтальном масштабировании речи не идёт, но в списке ссылок будет сюрприз :)
• Зависимость от object storage — если S3 недоступен, Litestream накапливает WAL локально, но при длительном отключении может потребоваться внимание
• Не замена PostgreSQL для высоконагруженных систем — для pet-проекта и небольших сервисов подходит идеально, для HA — нет, но можно посмотреть в ссылочки в конце статьи…

SQLite + Litestream — это мощная комбинация для «лёгкого» деплоя. Вы получаете полноценную реляционную базу данных в одном файле, непрерывный backup в S3 и автоматическое восстановление при перезапуске контейнера — без необходимости поднимать и обслуживать отдельную СУБД.

Для pet-проекта это часто идеальный баланс между простотой и надёжностью.

Пользуйтесь на здоровье! 🤝

Мои любимые ссылки, которые стоит почитать:

• Litestream и GitHub — официальный сайт и исходники
• Вот он сюрприз: LiteFS - Distributed SQLite - как сделать, горизонтальное масштабирование с SQLite. Говорят, работает в проде :)
• Ну и ссылочка на сам проект Беговой Клуб -=БеГиМ=-

Иногда, чтобы решить свою проблему, приходится написать инструмент. А иногда — чтобы написать инструмент, приходится решить свою проблему. Короче, как обычно, всё началось не с идеи сделать утилиту, а с того, что добавилась пара важных документов (по иппотке) к существующему зоопарку данных, которые надо хранить.

Как я к этому пришел

У меня давно назрела проблема: синхронизировать разные файлы с разных рабочих мест — по крайней мере дома и на работе. Документы (важные), сохранения из игр, книги для читалки. Ну и надёжный архив всего этого добра, потому что терять даже что-то незначительное это боль 🤕.

Просто положить всё в одно облако — хорошо, но нужен ещё постоянный процесс актуализации. Яндекс Диск работает, Google Drive может изменить условия, Dropbox может внезапно ограничить доступ. Поэтому идея была простая: хранить копии везде. Яндекс Диск, Google Drive, Mail.ru Cloud, Dropbox — чем больше, тем надёжнее. Только файлы, только хардкор!

Раньше я обходился консольным демоном yandex-disk — он работал, но только с Яндексом. Потом перешёл на самописные bash-скрипты, которые вызывали rclone напрямую. Это работало… до поры до времени. Конфигурация разрасталась, порядок синхронизации был важен (нельзя синкать из пустого облака в другое до того, как туда прилетели файлы) и всякое подобное. Проблема!

Когда появились нормальные ИИ-ассистенты для кодинга, я решил, что пора пробовать, а мне нужен нормальный инструмент. Declarative configuration, predictable order, automatic error handling и пр. Так родился Syncerman.

Из говна и палок архитектура и технологии

Syncerman написан на Go — выбрал его только за простоту распространения (один бинарник).

В основе лежит rclone bisync — двусторонняя синхронизация с сохранением метаданных. Syncerman не пытается переизобрести колесо синхронизации, а выступает оркестратором над rclone, предоставляя удобный CLI и YAML-конфигурацию. Никаких серверов и БД.

YAML-конфигурация

Вместо папок с ссылками на bash-скрипты — чёткая структура:

jobs:  important:    name: "Важное"    priority: 10    tasks:      - from: "local:/home/jerry/cloud/mirror/Documents"        to:          - path: "gdrive:folders/Documents"          - path: "ydisk:folders/Documents"      - from: local:Наследие        to:          - path: gdrive:Наследие/            args: ["--force"]          - path: ydisk:Наследие/            args: ["--force"]          - path: mailru:Наследие/            args: ["--force"]  games:    name: "игрули"    priority: 20    tasks:      - from: "local:games_sync"        to:          - path: "ydisk:folders/games_sync"

Порядок tasks и to внутри массивов сохраняется строго. Это критично для цепочек: local → Google Drive → Yandex Disk. Без этого — катастрофа.

Проблемасики

rclone bisync требует state-файлы для работы (они лежат где-то в папке пользователя). При первом запуске на новой паре путей он падает с ошибкой “cannot find prior Path1 or Path2 listings”. Syncerman детектирует это по двум паттернам в выводе и автоматически перезапускает синхронизацию с флагом --resync. Пользователь даже не замечает проблемы. Раньше делал руками.

На ранних этапах обнаружился критический баг: из-за использования map в Go порядок выполнения целей был недетерминированным. Для линейных цепочек это катастрофа: если сначала синкать из пустого Yandex в Google, а потом из локальной папки в Google — быть беде. Проблема! Так появились массивы.

Результат

Syncerman версии **0.3.6** сейчас работает в production — то есть на моих машинах :) Само собой нужны пруфы, и их есть у меня!

• бинарники для Linux и Windows (сборка сразу подо всё)
• GitLab CI как в лучших домах
• Покрытие тестами - самому было бы лень писать а тут юнит-тесты для всех ключевых пакетов (config, rclone, sync), интеграционные тесты (не просто интеграционные а целые bash-сценарии с десятком шагов ).

Публичные репозитории (это мой фетиш):

• Gitlab https://gitlab.com/kinnalru/syncerman
• Github https://github.com/kinnalru/syncerman
• Gitflic https://gitflic.ru/project/kinnalru/syncerman
• Gitverse https://gitverse.ru/kinnalru/syncerman

Использование

Мой crontab выглядит так:

# Синхронизация документов и сохранений 2 рааз в час и лог для ручной проверки10,30 * * * * /bin/sh -lc "cd /home/jerry/cloud/mirror && syncerman sync 2>&1 | tee ./lastrun.log"

Конфигурация зеркалирует локальные папки во все облака (настроенные в rclone) одновременно, а затем синхронизирует облака между собой. Если одно облако отвалится — данные остаются в остальных. Если rclone выдаст first-run ошибку — Syncerman сам всё починит.

Вместо вывода

Появление ИИ-ассистентов снизило порог входа для написания таких инструментов. Раньше мне было лень писать то, что и так работает с помощью пары строк на bash. А сейчас это делаю не я :) — разбор выхлопов rclone, обработка edge cases и тестирование делаются очень легко. Я могу заняться решением проблем (архитектурой и требованиями), а рутина “делается сама”.

Второй фетиш это ссылочки:

• rclone bisync - это база
• unison - еще одна классная штука по теме синхронизации, она прочно заняла место в моём сердце, но об это в другой раз

DevSecOps уверенно шагает по нашей индустрии, и горе тому, кто попадёт под его поступь… Эта статья про ультимативную сборку базовых образов для Ruby для удовлетворения самых параноидальных потребностей ИБ. Да, именно об этом мы и расскажем - что такое “инсталляция ruby”, где, что, почему лежит и как с этим жить нашему пайплайну сборки и самому приложению.

Как было до?

С самого начала появления docker мы в RNDSOFT использовали парадигму “всё включено”. Для нас это означало, что в образ мы включаем всё, что нам надо не только для продуктовой эксплуатации, но и для проведения всех тестов. При прохождении CI пайплайна на следующие стадии продвигался образ целиком и, в конце концов, выкатывался на прод.

Это было очень удобно и позволяло быть максимально (насколько это вообще возможно) уверенным в работоспособности, однако имело ряд серьёзных минусов, с которыми мы прекрасно жили достаточно долгое время:

• размер образа был большим - от 1 ГБ;
• образ включал большое количество неиспользуемого (в проде) ПО.

Сканеры сканировали, сканировали, да не высканировали…

И вот однажды один (на данный момент уже далеко не один) наш клиент захотел устранения всех замечаний, которые смог выявить сканнер Trivy. А их, как не трудно догадаться, было достаточно много. И главная проблема заключается в том, что большая часть замечаний никак не связана с непосредственными зависимостями вашего приложения (теми, которые фиксируются в Gemfile.lock).
Так откуда же они берутся?

Если коротко отвечать - отовсюду :) При сборке проекта необходимо поставить его зависимости - это план минимум. Кроме того, часто появляется необходимость установить bundle определенной версии или даже обновить ruby целиком, выполнив команду gem update –system. В результате этих действий в ваш образ в разнообразные папки ставятся разнообразные гемы, но

И еще два слова о том, что же именно сканирует Trivy (касательно ruby конечно):

• сканирует .gemspec файлы на всей файловой системе и не важно, установлен гем или нет - если в .gemspec указана версия “с уязвимостью” - алярм;
• сканирует .gem файлы на всей файловой системе и не важно, установлен гем, лежит просто в папке cache, используется или нет в вашем приложении.

Значит для удовлетворения хотелок сканера, надо сделать так, чтоб нигде не лежало ничего лишнего или не используемого, включая stdlib - стандартную библиотеку ruby.

Проблема ясна, задача очевидна - можно приступать к решению и начинать надо с базовых образов. Их надо собрать так, чтобы сами базовые образы уже не содержали никаких уязвимостей.

Немного удручающее зрелище, особенно для ИБ клиента

Что такое инсталляция ruby?

Если мы возьмём любой дистрибутив с установленным там ruby, то увидим, что само ruby будет находиться где-то в районе:

• /usr/lib/ruby - например в alpine после apk add ruby
• /usr/local/lib/ruby - например в ruby:alpine, где руби собирается отдельно от apk

А дальше начинается интересное. Если посмотреть в финальный образ, в котором сделано много различных операций (обновление ruby, установка гемов через gem install, установка через bundle install), то в корневой папке ruby обнаружится несколько папок, по которым тем или иным способом будут распределены установленные вами гемы:

/usr/local/lib/ruby├── 3.2.0├── gems/3.2.0├── site_ruby/3.2.0└── vendor_ruby/3.2.0

Сразу добавим к этому списку другие папки (которые можно посмотреть в выводе команды gem env):

 - INSTALLATION DIRECTORY: /usr/local/bundle - USER INSTALLATION DIRECTORY: /root/.local/share/gem/ruby/3.3.0 - SPEC CACHE DIRECTORY: /root/.cache/gem/specs - GEM PATHS:    - /usr/lib/ruby/gems/3.3.0    - /root/.local/share/gem/ruby/3.3.0

И вишенкой на торте будет настройка вашего bundle, если вы используете кеширование сборки (bundle cache или bundle config set cache_path vendor/cache), и используемые в этом зоопарке переменные окружения GEM_HOME, BUNDLE_CACHE_PATH, BUNDLE_PATH и скорее всего еще какие-то скрытые в глубинах экосистемы ruby.

Немного путано и в результате беспорядочных связей установок и обновлений во всех этих папках могут (и будут) появляться гемы. Надо исправить!

Постараюсь дать верхнеуровневое описание, что же именно это за папочки, не углубляясь в подробности и исключения:

/usr/local/lib/ruby/3.3.0

Именно в этой папке установлены основные файлы ruby и stdlib, а также компилируемые расширения в папке x86_64-linux-musl (в нашем случае собранные alpine для x86_64). Эти файлы принадлежат условной “системе” и никак не будут изменяться при дальнейших модификациях, например при установке или обновлении гемов через gem install. Вместо этого библиотеки будут ставиться в папку /usr/local/lib/ruby/gems/3.3.0

/usr/local/lib/ruby/gems/3.3.0

Тут собрано всё, что вы ставите (без модификации GEM_PATH) командами gem install, включая компилируемые расширения.

/usr/local/lib/ruby/vendor_ruby/3.3.0

Сюда должны ставиться дополнительные гемы и/или патчи от команды мейнтейнеров дистрибутива. Об этом сложно найти информацию, но несколько слов есть в книге The Ruby Programming Language или, что интереснее, в changelog для NEWS for Ruby 1.8.7 (да, окаменелое…):

/usr/local/lib/ruby/site_ruby/3.3.0

Сюда будут ставиться “системные” файлы, но не от OS, а от самого ruby, например после выполнения gem update –system:

site_ruby/└── 3.4.0   ├── bundler   ├── rubygems   └── x86_64-linux-musl

/usr/local/lib/ruby/gems/3.3.0/specifications/

…а также INSTALLATION DIRECTORY /usr/local/bundle/specifications…
…а также USER INSTALLATION DIRECTORY: /root/.local/share/gem/ruby/3.3.0…
…а также SPEC CACHE DIRECTORY /root/.cache/gem/specs…
…а также BUNDLE_CACHE_PATH …

Сюда ставятся .gemspec файлы, которые собственно и говорят пакетному менеджеру ruby (gem и bundle), какие именно версии каких гемов установлены.

/usr/local/lib/ruby/gems/3.3.0/specifications/default

Default, Карл… Default - это особое состояние гема, и эти гемы нельзя удалить. Если вы обновили гем до новой версии, то старая всё равно останется, и Trivy вам этого не простит. Весьма вредная папка с точки зрения сканирования.

/usr/local/lib/ruby/gems/3.3.0/cache/

…а также INSTALLATION DIRECTORY /usr/local/bundle/cache…
…а также BUNDLE_PATH …

Сюда пакетный менеджер ruby (gem или bundle) скачивает гемы (допустим вы ставите faraday.gem) перед установкой. Этот кеш очень часто используется для ускорения сборки, например в вашем Gitlab.

Что здесь у вас происходит?!

После того как мы в процессе исследования детально разобрались и увидели всё это многообразие мест, где могут находиться файлы, вызывающие панические атаки у Trivy, мы решили радикально решить эту проблему: свести все файлы, все гемы и все спеки (.gemspec) в одно место. Это позволит легко следить за всеми (всеми!) фактическими зависимостями и эффективно пользоваться командами gem cleanup и bundle clean. Тут надо отметить, что для вашей рабочей OS (системы общего назначения) такое решение приведёт к поломке системного пакетного менеджера (Gentoo Portage, dpkg/apt, rpm/zypper и пр.), но мы ведь говорим о конкретной сборке ruby под ваш конкретный проект - и тут никаких проблем не будет.

Но это еще не всё. Остаётся еще проблема с default gemspec, но её относительно легко решить:

mv /usr/local/lib/ruby/gems/3.3.0/specifications/default/* /usr/local/lib/ruby/gems/3.3.0/specifications/

Теперь мы можем сформулировать План:

• Все дороги ведут в Рим - делаем ссылочки для vendor_ruby, site_ruby и пр. Также явно прописываем системные переменные GEM_HOME и BUNDLE_APP_CONFIG.
• Разбираемся с default gems.
• Обновляем ruby (имеется в виду stdlib) до последней требуемой версии.
• Обновляем bundle до нужной версии.
• Удаляем лишние гемы (например rdoc).
• Переставляем (!) системные (на текущий момент сборки базового образа - все ) гемы, потому что, как оказалось, mv для default gemspec имеет не очень хорошие последствия.
• profit!

Сказано - сделано, и добро пожаловать под кат!

ARG BASE_RUBY=3.2ARG BASE_ALPINE=alpine3.16ARG BASE_IMAGE=ruby:${BASE_RUBY}-${BASE_ALPINE}FROM ${BASE_IMAGE}ARG BASE_RUBY=3.2ARG RUBYGEMS_VERSION=3.5.20ARG BUNDLER_VERSION=2.5.20# эта переменная есть в старом alpine но нет в debian и новом# добавляем потому что она очень нужна для работы с папочкамиENV RUBY_MAJOR=${BASE_RUBY}ENV RUBYGEMS_VERSION=${RUBYGEMS_VERSION} \    BUNDLER_VERSION=${BUNDLER_VERSION}RUN apk update && apk upgrade# Это наш костыльный скрипт который удаляет всякие лишние кеши,# man-файлы и прочий мусор. COPY common/scripts/cleanallbuilds.sh /usr/bin/# dumb-init всегда используем как PID-1 но это немного другая историяRUN set -ex \ && apk add dumb-init \ && cleanallbuilds.sh###### # Надругиваемся над диструбутивом, чтоб иметь строго# одну версию руби в систему и управлять ею целиком через gem/bundle# все пути ведут в РимENV GEM_HOME=/usr/local/lib/ruby/gems/${RUBY_MAJOR}.0/ENV BUNDLE_APP_CONFIG=/usr/local/lib/ruby/gems/${RUBY_MAJOR}.0/# Сводим vendor_ruby, site_ruby и GEM_HOME в одно местоRUN set -ex \ && rm -rf /usr/local/lib/ruby/site_ruby /usr/local/lib/ruby/vendor_ruby \ && ln -sf /usr/local/lib/ruby /usr/local/lib/ruby/site_ruby \ && ln -sf /usr/local/lib/ruby /usr/local/lib/ruby/vendor_ruby \ && mkdir -p /root/.local/share/gem/ruby/ \ && ln -sf ${GEM_HOME} /root/.local/share/gem/ruby/${RUBY_MAJOR}.0# Чутка тюним bundle config чтоб в дальнейшем не забытьRUN set -ex \ && bundle config --local disable_version_check true \ && bundle config --local clean false \ && bundle config --local no_prune false \ && bundle config --local disable_local_branch_check true \ && bundle config --local jobs 2 \ && bundle config --local allow_offline_install true# настраиваем .gemrc чтоб не было ничего лишнего, вклюячая rdocRUN set -ex \ && echo 'gem: --no-document' > /usr/local/etc/gemrc \ && echo 'update_sources: false' >> /usr/local/etc/gemrc \ && echo 'verbose: false' >> /usr/local/etc/gemrc \ && echo 'update: --no-suggestions' >> /usr/local/etc/gemrc \ && echo 'install: --no-suggestions --conservative' >> /usr/local/etc/gemrc# пытаемся удалить ненужные гемы с самого начала - попытка не пыткаRUN set -ex \ && gem uninstall -a -x --quiet --force `gem list | cut -f 1 -d " "` \ && gem cleanupRUN set -ex \ && apk add --virtual .build-deps \   autoconf \   bison \   bzip2 \   bzip2-dev \   coreutils \   curl-dev \   dpkg-dev dpkg \   g++ \   gcc \   gdbm-dev \   git \   glib-dev \   libc-dev \   libffi-dev \   libxml2-dev \   libxslt-dev \   linux-headers \   make \   ncurses-dev \   procps \   readline-dev \   tar \   xz \   yaml-dev \   zlib-dev \   shared-mime-info \ && mv /usr/local/lib/ruby/gems/${RUBY_MAJOR}.0/specifications/default/* /usr/local/lib/ruby/gems/${RUBY_MAJOR}.0/specifications/ \ && gem cleanup \ && gem update --system "${RUBYGEMS_VERSION}" \ && gem uninstall bundler --all --silent || true \ && gem install bundler -v "${BUNDLER_VERSION}" \ && gem uninstall rdoc --all --silent || true \ && GMS=`gem list | sed s/default:\ // | sed -E 's/\ \((.*)\)/:\1/' | sort` \ && DEBUG_FLAGS="-Wno-calloc-transposed-args" gem pristine --all --extensions \ && commands=$(for x in $GMS; do \   g=$(echo "$x" | cut -f 1 -d ":"); \   v=$(echo "$x" | cut -f 2 -d ":"); \   echo gem pristine $g --version "$v"; \ done) \ && echo -e "$commands" | xargs -I CMD -P 3 bash -c CMD\ && gem cleanup \ && rm -rf root/.local/share/gem/specs \ && apk del .build-deps \ && cleanallbuilds.shWORKDIR /home/appRUN set -ex \ && adduser -D -s /sbin/nologin app \ && chown -R app:app /home/appENTRYPOINT ["/usr/bin/entrypoint.sh"]SHELL ["/bin/sh", "-c"] 

Самое интересное, конечно, находится в одном слое самого пухленького RUN, и по некоторым командам надо дать пояснения:

• GMS=gem list

  sed s/default:\ //

  sed -E ‘s/\ ((.*))/:\1/’

  sort`` - получаем список установленных гемов с версиями в формате “yaml:0.4.0 zlib:3.2.1”. Это нам потребуется дальше из-за странного поведения gem pristine

• gem pristine --all --extensions - должен для всех установленных гемов сделать “чистовую” установку, включая скачивание и перекомпиляцию расширений. Но нет. На самом деле он делает не для всех и не всё :(
• DEBUG_FLAGS="-Wno-calloc-transposed-args" - мы используем один Dockerfile для сборки базовых образов ruby 2.7, 3.0, 3.1, 3.2, и по умолчанию все расширения должны компилироваться без единого разрыва ворнинга компиляции, но для некоторых версий руби (кажется 3.0) это не так, и именно этот ворнинг всё портит, поэтому его подавляем без затей.
• commands=$(for x in $GMS; do … - а вы знали, что в bash тоже есть пул потоков? Строго говоря, он пул процессов, и не в баше, а в xargs, но это не важно. В общем тут список $GMS в виде “yaml:0.4.0 zlib:3.2.1” трансформируется в список $commands, потому что в такой форме gem pristine работает именно так как надо:

gem pristine yaml --version "0.4.0"gem pristine zlib --version "3.2.1"...

• echo -e "$commands" | xargs -I CMD -P 3 bash -c CMD - отправляем $commands в пул из трех процессов для одновременной установки гемов.
• cleanallbuilds.sh - зовём в самом конце кустарный скрипт, который удаляет всякий мусор из системы:

#!/bin/sh# ruby (alpine + debian)# Скрипт единый идля debian и для alpine, поэтому ошибки,# возникающие из-за разницы дистрибутивов просто игнорируемrm -rf /usr/src/ruby/ || truerm -rf /root/.local/share/gem/specs/ || truerm -rf /root/.local/state/ || truerm -rf /root/.cache/gem/ || truerm -rf /usr/local/lib/ruby/gems/3.2.0/cache/ || truerm -rf /root/.bundle/cache/ || truegem cleanup || true# alpineapk cache clean || true# debianapt-get clean autoclean || trueapt-get autoclean --yes || trueapt-get autoremove --yes || truefind /var/log/ -type f -delete || truefind /var/lib/log/ -type f -delete || truefind /usr/share/doc/ -type f -delete || true

Результат

Старый образ занимал 900MB, новый - 152MB (не спрашивайте…)

Значительно лучше. Особенно для базового образа

Что дальше?

Теперь эти базовые образы надо начать использовать непосредственно в CI пайплайнах боевых сервисов и, конечно, процедуру сборки и тестирования придётся поменять. Точнее, мы уже перешли на новые образы и сборку уже пару недель назад - дело теперь только за статьёй. А в качестве приманки приведу результаты перехода для одного из самых “толстых” наших сервисов:

image:old size:1.49GB vulns:255image:new-prod size:259MB vulns:1 (Вчерашняя!! СVE-2025-25186)image:new-test size:269MB vulns:1 (СVE-2025-25186)

Если взглянуть ретроспективно, то совсем не весело - так что:

Попросите любого программиста просмотреть ключевые участки продуктового кода, и он обязательно укажет на несколько моментов, требующих рефакторинга. Почему же так много плохого, ненадежного или непонятного кода продолжает работать в продуктовом окружении?

Ответ прост: инженеры боятся его трогать. Задачи для рефакторинга обнаруживаются и добавляются в бэклог, но редко попадают в текущий спринт.

Для этого есть множество причин. Код мог быть написан программистом, давно покинувшим команду и теперь в нём никто не разбирается. Бывает что этот код имеет решающее значение для бизнеса и из-за этого никто не хочет нести ответственность за потенциальный сбой или потерю дохода.

В данном посте мы рассмотрим, как можно использовать гем Scientist для уверенной миграции, рефакторинга и изменения критического продуктового Ruby-кода.

Но сначала вы спросите — а нельзя ли использовать тесты для поиска ошибок?

Это ведь то самое для чего нужны тесты в Rails, верно?

И да и нет. Часто бывает трудно получить полную уверенность в новых изменениях до развертывания. Допустим модульные (Unit) и системные тесты проходят. Этого достаточно?

Реальность такова, что ничто не может заменить реальный мир, то есть продуктовую эксплуатацию. А если качество тестовых данных плохое или тесты отсутствуют? А будет ли новое ПО работать достаточно хорошо, чтобы справляться с нагрузкой?

Команды с публичными сервисами иногда обнаруживают, что им нужно решать проблемы «совместимости с ошибками» (bugwards compatibility). Когда ошибка существует в рабочей среде некоторое время, клиенты могут обходить её таким способом, который зависит от привычного неправильного поведения. Клиенты часто используют ваш софт неожиданным образом.

с Scientist можно следить за правками в в Ruby и Rails сразу в боевом окружении

Если продуктовое окружение это лучшее место, где можно обрести уверенность в своих правках, можно подумать о том, чтобы понаблюдать за поведением кода именно там. Поначалу это может показаться пугающим, ведь идея «тестирования в бою» противоречит классическим методам разработки программного обеспечения.

Однако хорошая новость заключается в том, что это можно легко и безопасно сделать в Ruby и Rails с помощью гема Scientist. Название утилиты основано на научном методе проведения экспериментов для проверки гипотез. В данном случае наша гипотеза состоит в том, что новый код работает, а его использование это “эксперимент”.

Причина, по которой мы можем безопасно использовать этот подход, заключается в том, что в экспериментах по-прежнему используется результат существующего кода. Новый код оценивается только в целях наблюдения и сравнения, как на точность, так и на производительность. Мы уменьшаем проблемы с тестовым покрытием, которые обсуждались ранее, оценивая производительность с использованием реальных данных и параметров в боевом окружении. Эксперименты обычно проводят с определённой частотой, чтобы свести к минимуму влияние на производительность. Однако при желании можно оценить и каждый вызов.

Давайте теперь кратко рассмотрим, как Scientist работает с техникой “Branch by Abstraction”.

Паттерн “Branch by Abstraction” в геме Scientist

Работа Scientist начинается с паттерна Branch by Abstraction, описанного Мартином Фаулером как «постепенное крупномасштабное изменение программной системы».

Мы вводим уровень абстракции, чтобы изолировать обновляемый код. Этот уровень решает, какую реализацию использовать, чтобы эксперимент был прозрачен для остальной части системы. Данный метод связан с использованием флага (feature flag), который определяет какая из ветвей кода будет исполнена.

Гем Scientist, созданный в Github, реализует этот паттерн с помощью “эксперимента”. Существующий код называется “контрольным”, а новая реализация — “кандидатом”. Обе части кода выполняются в случайном порядке, но клиенту возвращается только результат ”контрольной” части.

Использование Scientist для рефакторинга сервиса в Ruby

Рассмотрим Ruby-сервис, который возвращает наибольший простой множитель для заданного числа. Предположим, мы определили способы оптимизации для сокращения необходимого набора кандидатов, что ускорит работу сервиса.

Однако владельцы сервиса хотят быть уверены, что при оптимизации не вкралась ошибка. Они также хотят увидеть все улучшения производительности. Давайте напишем следующий код, для вызова этого метода:

require 'scientist' def largest_prime_factor(number)  science "prime-factors" do |experiment|    experiment.use { find_largest_prime_factor(number) } # old way    experiment.try { improved_largest_prime_factor(number) } # new way  end # returns the control valueend

В этот момент вызывается только выражение use (контрольное). Но чтобы сделать эксперимент полезным, надо определить пользовательский класс Experiment, чтобы включить его и опубликовать результаты (в данном случае просто логирование). Scientist генерирует очень полезные данные, но по умолчанию ничего с ними не делает. Эта часть остается на ваше усмотрение.

require 'scientist/experiment'require 'pp' class MyExperiment  include Scientist::Experiment   attr_accessor :name   def initialize(name)    @name = name  end   def enabled?    true  end   def raised(operation, error)    p "Operation '#{operation}' failed with error '#{error.inspect}'"    super # will re-raise  end   def publish(result)    pp result  endend

Результаты эксперимента будут зарегистрированы, и мы сможем со временем вносить улучшения на основе анализа. Как только новый код будет соответствовать требованиям и доверие к нему станет высоким, осуществим переход на новую реализацию, просто заменив код делегированием в новую реализацию.

LabTech для упрощения использования Scientist в Ruby on Rails

Есть гем LabTech, который может помочь настроить Scientist в Rails приложении и удобнее обрабатывать результаты.

Приложения, использующие AppSignal, могут использовать вспомогательный инструментарий Appsignal.instrument, чтобы отслеживать, сколько времени требуется для выполнения событий Scientist. Обернув в него код эксперимента, можно увидеть, как события появляются в AppSIgnal.

Теперь вернемся к LabTech — пример ниже просто принимает число для разложения.

Приступить к работе легко, если у вас есть доступ к консоли. Сначала надо добавить гем LabTech в Gemfile и запустить bundle install.

gem 'lab_tech'

Результаты и конфигурация эксперимента хранятся в БД, поэтому требуется миграция.

rails lab_tech:install:migrations db:migrate

Уровень абстракции тот же, за исключением того, что используется модуль LabTech. Полный код доступен на GitHub.

def largest_prime_factor(number)    LabTech.science "prime-factors" do |experiment|      ...    endend

На данный момент эксперимент отключен, поэтому воспользуемся консолью, чтобы включить его во всех случаях или настроить процент исполнения.

bin/rails consoleLabTech.enable "prime-factors"LabTech.enable "prime-factors", percent: 5

Теперь можно запустить тесты, и эксперимент будет выполнен. Для текстового представления результатов есть следующие команды в консоли Rails.

LabTech.summarize_results "prime-factors"LabTech.summarize_errors "prime-factors"

После нескольких успешных прогонов и одной синтетической ошибки получим пример того, как выглядит сводка результатов. Существует обзор успехов и ошибок, а также диаграмма ASCII, показывающая различия в производительности.

-Earliest results: 2022-04-27T02:42:45ZLatest result: 2022-05-01T17:27:39Z (5 days) 3 of 4 (75.00%) correct1 of 4 (25.00%) mismatched Median time delta: +0.000s (90% of observations between +0.000s and +0.000s) Speedups (by percentiles):      0% [· █] +2.4x faster      5% [· █] +2.4x faster     10% [· █] +2.4x faster     15% [· █] +2.4x faster     20% [· █] +2.4x faster     25% [· █] +2.4x faster     30% [· █] +2.4x faster     35% [· █] +2.4x faster     40% [· █] +2.4x faster     45% [· █] +2.4x faster     50% [· · · · · · ·· · · · · · · · · █ ·· · · · · ·] +2.4x faster     55% [· █] +2.4x faster     60% [· █] +2.4x faster     65% [· █] +2.4x faster     70% [· █] +6.9x faster     75% [· █] +6.9x faster     80% [· █] +6.9x faster     85% [· █] +6.9x faster     90% [· █] +6.9x faster     95% [· █] +6.9x faster    100% [· █] +6.9x faster----

Для лёгкого и удобного анализа результатов есть гем Blazer. Он прост в установке и позволяет выполнять SQL-запросы. Запрос здесь показывает, что реализация-кандидат значительно быстрее оригинала.

В примере нашего сервиса, возвращающего наибольший простой делитель, ускорение в улучшенной реализации происходит за счет эвристики, исключающей некоторые возможные факторы, которые необходимо учитывать. Поскольку мы рассматриваем большие числа и находим простой множитель, мы можем прекратить поиск после того, как доберемся до целевого числа, делённого на этот множитель. Новый код добавляет только одну инструкцию для достижения этой цели.

Мы также можем увидеть сокращение времени выполнения используя Blazer.

Варианты использования и ограничения Scientist

Оптимальное использование Scientist включает задачи поиска, вычисления и код, который не имеет побочных эффектов. Код, включающий транзакционные обновления или внешние интеграции, такие как электронная почта, не совсем вписывается в модель, поскольку изменяемое действие выполняется дважды (как в старой, так и в новой реализации).

Это не тривиальное ограничение. Оно блокирует несколько вариантов использования. Однако есть обходные пути, если эксперимент очень важен. Стоит подумать имеют ли значение побочные эффекты или дублирование или они не являются проблемой. Например, в некоторых случаях может не иметь значения, будут ли отправлены два электронных письма во время оценки. Другой вариант — сделать так, чтобы новый код определял результат, но не сохранял его. Это не позволит сравнить производительность, но позволит проверить точность.

Другие ограничения проистекают из того, что Scientist фокусируется на возвращаемых значениях. В некоторых случаях действительные результаты могут отличаться с течением времени, независимо от того, включают ли они просто временные метки в ответ или изменяются сторонние факторы. Во многих случаях мы можем написать пользовательскую логику сравнения в эксперименте, чтобы проверить точность, выходящую за рамки обычного сравнения строк.

Наконец, ограничение LabTech заключается в том, что он не был портирован на Rails 7 на момент написания.

Лучшие практики для эффективных Scientist-экспериментов в Rails

При проведении экспериментов стоит учитывать следующие моменты:

• В Rails-проектах Scientist может быть настроен либо в инициализаторе, либо в оболочке, такой как гем Rails LabTech. Большинство приложений Rails уже имеют базу данных, поэтому LabTech использует ActiveRecord для хранения результатов.
• Чтобы не замедлять разработку и тестирование, включайте эксперимент только в промежуточной (staging) и продуктовой средах.
• Чтобы свести к минимуму любое потенциальное влияние на продуктовую среду, запускайте эксперимент только для некоторого процента запросов. LabTech поддерживает это из коробки как необязательный параметр при включении эксперимента (изначально он отключен по умолчанию). Используя чистый Scientist, эту логику легко реализовать через enabled? метод.
• Некоторая логика требует больших ресурсов, поэтому хорошей отправной точкой может быть низкая частота дискретизации. По мере того, как вы обретете уверенность в результатах, увеличивайте процент оцениваемых запросов.
• Вы можете добавить атрибуты контекста, чтобы получить максимальную отдачу от результатов. В качестве контекста эксперимента может быть задан хэш с параметрами, который затем становится доступным в опубликованных результатах, например:

experiment.context :user => user

Подводя итоги: наблюдайте и контролируйте свое приложение Ruby с помощью Scientist

В этом посте мы рассмотрели, как использовать гем Scientist для изменения, переноса и рефакторинга кода Ruby в продуктовой среде.

Мы рассмотрели место Scientist в паттерне Branch by Abstraction, и погрузились в рефакторинг. Затем увидели, как LabTech помогает со сбором результатов и конфигурацией Scientist.

Мы коснулись некоторых ограничений Scientist, прежде чем, наконец, изложить несколько лучших практик.

Вам необходимо наблюдать и контролировать то, что происходит в системе. Интегрируйте Scientist в процесс разработки, чтобы с большей уверенностью вносить критические изменения в код Ruby.

Happy coding!

Перевод статьи “Using Scientist to Refactor Critical Ruby on Rails Code”
Darren Broemmer от 18 мая 2022 года.

Оригинал: https://blog.rnds.pro/030-gitlab-janitor

Спешим поделиться с вами нашим инструментом для поддержания чистоты и порядка на наших (RNDSOFT) сборочных серверах gitlab-janitor. О том, как мы к нему пришли, и каков первый опыт - далее по тексту.

С каждым годом инфраструктура RNDSOFT, обеспечивающая процессы CI/CD, растёт. Появляются новые проекты, усложняются процессы (pipelines) сборки и тестирования, растет количество сборщиков (build agents), и всё это приносит дополнительные накладные расходы. Сегодня мы рассмотрим конкретную проблему - чистку/освобождение ресурсов на самих сборочных серверах. Мы используем Gitlab и несколько Gitlab runners с докером (docker executor) под капотом. Вот с проблем и начнём.

Проблемы

Вся терминология будет опираться на Gitlab, но всё это применимо и к другим решениям, опирающимся на docker.

Типовой процесс сборки и доставки состоит из 4х больших этапов (stages), по несколько задач (jobs) в каждом:

• сборка docker-образа (обычно одного на проект, но бывает и больше).
• тестирование. Тут мы используем подход, когда тестируем не сам код, а весь контейнер. Конечно, есть юнит-тесты, интеграционные, графические и прочие, но запускаем мы их непосредственно внутри боевого контейнера. А что? У нас ruby - можем себе позволить 💎 :)
• тэгирование (image promoting). Этап в зависимости от результатов тестов и QA перетегируется во что-то вроде stable или release, или как-то еще, в зависимости от конкретного проекта, команды и принятых процессов.
• доставка (deploy). Тут всё как обычно - дев/тест стенды, QA-стенды, динамические стенды для MR и всякое разное вроде документации.

В результате описанных выше процессов (особенно тестирования) на сборщиках остаётся много мусора, именно это является проблемой. Далее по порядку.

Подвисшие контейнеры (dangling containers)

Тут речь, конечно, идёт не о повисании ПО внутри контейнера, а о самих “ненужных” контейнерах. Например, для графических тестов поднимается целый стек: Postgres, Chrome, Selenium, само приложение, контейнер, из которого запускаются тесты, Redis и бог еще знает что. Если весь процесс (pipeline) или непосредственно задача (job) будут прерваны, то никто не погасит за нас эти контейнеры, и они продолжат висеть и потреблять ресурсы. Проблема!

Ненужные образы

В процессе сборки имя образа претерпевает примерно следующие изменения: image:$SHA -> image:stable -> image:release. Конечно, это примерно, шагов может больше или именования другие, но сути это не меняет. При последовательных комитах сратые старые образы остаются лежать мёртвым грузом.

Ситуация усугубляется тем, что один и тот же образ находится (с максимальной вероятностью) сразу на всех сборщиках, поскольку разные типы тестов запускаются параллельно и попадают на все сборщики и занимают x3 места. Проблема! Дважды проблема, поскольку с образами всё не так просто и очень интересно - об этом ниже.

Безымянные и кеширующие тома (unnamed and cache volumes)

Многие контейнеры при создании аллоцируют в докере временные анонимные тома/диски (мы же всегда про докер говорим, верно?) и оставляют их после себя. Также сам Gitlab, если вы не используете распределённые кеш (shared cache) на базе S3, всё равно создаёт кеш-тома, если ему явно не запретить это делать через disable_cache. Проблема!

Конечно, эти проблемы не простой “мусор” - старые образы могут ускорить последующую сборку, кеш-тома также теоретически могут ускорять сборку, так что они не совсем бесполезны. Однако, проблемы ускорения и кеширования мы решаем немного иначе - с помощью определённых схем именования образов, используя buildkit, который умеет подтягивать кешированные слои прямо из реестра образов (в нашем случае harbor) и пр.

Что же делать?

Проблемы появляются не сразу. Когда-то у нас был один сборщик, там вообще не было проблем с перетягиванием образов между этапами, а образы чистились через docker rmi на последнем шаге процесса. Когда сборщиков стало больше, и на них докинули ресурсы, пришлось немного усложнить схему - сначала были bash-скрипты, которые по расписанию удаляли образы по шаблону имени. Затем периодически стали использовать docker system prune. Но эти решения очень негибкие, плохо поддерживаются и масштабируются и обладают фундаментальной проблемой - частыми кеш-промахами (cache miss), что периодически сильно тормозило процессы (pipelines). И вот однажды терпеть это стало невозможно 😜 :)))

Нам нужно хорошее решение, желательно с баристой и массажисткой! Встречаем - gitlab-janitor!

Gitlab-janitor

Основными задачами были:

• консолидация всех чисток сборщика в одном месте;
• уменьшение кеш-промахов, насколько это возможно;
• простота работы.

Для чистки места на сборщиках уже есть проект gitlab-runner-docker-cleanup, он и явился идейным вдохновителем нашей утилиты, но, к сожалению, не выполнял всех необходимых нам функций.

Написав своё решение, мы решили опубликовать его в открытом виде - и зеркало на github, и образы на docker-hub, и даже документация с примерами. Ну и не мог я удержаться от разнообразных бейджиков :)

Проще всего запускать его в докере на каждом сборщике (для этого мы используем nomad 🥂 ):

docker run --rm \  -v /var/run/docker.sock:/var/run/docker.sock \  -v /persistent/janitor:/store \  -e REMOVE=true \  -e INCLUDE="*integr*, *units*" \  -e EXCLUDE="*gitlab*" \  -e CONTAINER_DEADLINE="1h10m" \  -e VOLUME_DEADLINE="4d" \  -e IMAGE_DEADLINE="4d" \  -e CACHE_SIZE="10G" \  -e IMAGE_STORE="/store/images.txt" \  rnds/gitlab-janitor:latest

Заметили IMAGE_STORE? С остальными параметрами всё просто - шаблоны для имён образов, томов, сроки хранения, а вот для образов всё гораздо интереснее!

Докер не сохраняет в своём локальном хранилище никакой информации о времени загрузки образа, а только обычную дату создания образа. В результате нет возможности определить, какой образ очень нужен и часто используется (хоть и создан давно), а какой свеженький, но больше никогда и никому не будет нужен.

Для решения этой проблемы в gitlab-janitor сделан простенький механизм - когда образ встречается первый раз, он сохраняется в файл с временной меткой - это считается датой появления. Когда подходит срок - образ удаляется. Однако, если gitlab-janitor увидит созданный контейнер из этого образа - то временная метка в этом файле сбрасывается. Именно для этого и используется параметр IMAGE_STORE. Данный файл можно монтировать с хост-машины, а можно и нет - в этом случае история образов будет теряться при пересоздании/обновлении контейнера-чистильщика:

selenium/standalone-chrome:latest sha256:c01aea5eb0bf279df5f745e3c277e30d7d9c81f15b9d1d4e829f1075c31ed5b1 1660205645postgres:10-alpine sha256:d7023df56cb7cbe961f0c402888f7170397c98c099fb76fbe16b5442a236ad51 1660205040redis:latest sha256:3edbb69f9a493835e66a0f0138bed01075d8f4c2697baedd29111d667e1992b4 1660205645

С остальными параметрами, документацией и примерами можно ознакомиться на гитхабе.

Результаты

Вот и подъехали результаты объективного контроля за работой gitlab-janitor на трех наших сборщиках:

Все чистки с помощью cron+bash, docker prune и пр. выключены. Параметры, оптимально подходящие под наши процессы, мы еще подбираем (и будем подбирать), но уже видно, что процесс вошел в стабильную фазу, и наш чистильщик выполняет свою работу!