Друзья, всем привет! Сегодня расскажу одну историю из моей практики.
Однажды перед нами встала довольно понятная задача: в связи с ростом нагрузки и горизонтальным масшатбированием инстанса потребовалось вынести Sidekiq на отдельный хост.
🔴Схема была такой: делаем основной хост с API и всем тем, что осталось и новый отдельный хост под Sidekiq. Мы проверили, что у Sidekiq есть необходимый сетевой доступ, на основном GitLab‑узле Sidekiq отключили, а на новом сервере включили.
Итог: все основные тесты прошли успешно. Стандартные фоновые задачи работали нормально. Пайплайны запускались, джобы отрабатывали без явных ошибок. А вот с динамическими пайплайнами возникла проблема, они не могли найти артефакты.
⏩Как это выглядело
Джоба, которая должна была читать артефакты предыдущего стейджа, падала с ошибкой о том, что артефакты не найдены. Но при этом:
• В UI GitLab артефакт у предыдущей джобы был, его можно было скачать руками.
• Логи runner’а показывали стандартный запрос за артефактами, а затем падение на стороне GitLab.
Ошибка проявлялась именно в сценариях с динамической генерацией. Ну как ошибка...даже не ошибка
"exception.class": "Gitlab::Ci::Artifacts::DecompressedArtifactSizeValidator::FileDecompressionError",
"exception.message": "File decompression error",
Чем-то похожие проблемы нашлись тут и тут.
Если логически предположить, что теперь он ищет артефакты не там, значит выносим все артефакты, чтобы условия были единые. Для этого унесем их в S3, так как его можно использовать для хранения разных объектов. НО на тот момент артефакты всё ещё лежали на локальном диске. После вынесения Sidekiq эта схема стала особенно хрупкой.
🔴В итоге
• Унесли все CI‑артефакты в S3‑совместимое object storage
• Привели конфигурацию к единой схеме хранения, чтобы и web, и Sidekiq работали только через объектное хранилище.
• Динамические пайплайны перестали падать, GitLab стабильно находил объекты, а Sidekiq корректно обрабатывал джобы, завязанные на артефакты. Все, можно применять на проде?
Как бы не так. Новая проблема – сломавшиеся GitLab Pages ❌
Как только мы пофиксили одну проблему, вылезла следующая. Пользователи начали жаловаться, что GitLab Pages перестали открываться, часть проектов стала отдавать 404, а новые деплои страниц как будто вообще не происходили. То есть:
• В репозиториях джобы pages отрабатывали успешно.
• В файловой системе на стороне GitLab мы видели новые сборки в директории, которая служит storage для Pages
• При обращении к GitLab Pages через домен выдавался 404, пока не перезапускали gitlab-pages.
В нашем случае наложились сразу несколько факторов. И пути хранения перенастроенные (после ухода в object storage артефактов), и отдельный сервер Sidekiq, который обрабатывает джобы, отвечающие за публикацию Pages.
⏩В результате, gitlab-rails и Sidekiq думали, что Pages задеплоены на s3, складывали контент в нужное место, но сам Pages искал pages_deployments на файловой системе. Прям как тут.
Решение вроде бы простое:
gitlab_rails['object_store']['objects']['pages']['bucket'] = 'gitlab-pages'
• Проверяем, что все пути совпадают и перезапускаем сервис.
• Видим, что Pages вернулись к жизни и начали стабильно подхватывать новые деплои без ручных перезапусков.
🔴Но тестирование снова не проходит. Теперь у пользователей не находятся SSH ключи.
Это последний неприятный эффект, который мы получили «бонусом» после всех изменений. Но о нем в следующей части)