История работ на Gitlab. Часть 2💬

Мы остановились на проблеме с SSH‑доступом. Часть пользователей неожиданно перестала подключаться по SSH:
• Ключи в UI GitLab были видны, как добавленные.
• При попытке клонирования или git fetch GitLab запрашивал пароль или возвращал ошибку «Permission denied (publickey)».

🔴В чем суть
• Когда Sidekiq был на том же сервере, он читал /var/opt/gitlab/.ssh/authorized_keys и было нормально.
• Когда мы вынесли его, он начал писать в свой /var/opt/gitlab/.ssh/authorized_keys на ноде сайдкика.
Произошла потеря мапинга ключа и прав пользователя, которая через БД. Помог ребилд этого файла из БД gitlab-rake gitlab:shell:setup. Но при добавлении или изменении ключа он писал новую инфу снова на ноду сайдкика. И так по кругу.

Решили проблему вот так.

А теперь финальное, сломалось покрытие кода. Просто перестал работать данный функционал.
Для code coverage Sidekiq парсит job.log в рилтайме, но процесс лога джобы такой, что он пумой кладётся на ФС гитлаба в одно место во время джобы (и тут он ещё не артефакт). А по завершению запаковывается уже в артефакт в другое место, по флоу в ссылке.

И раньше сайдкик нормально парсил этот job.log в директории, а после выноса он перестал видеть ФС на основной ноде и не парсил ничего, но при этом опять же все артефакты заданий в UI и S3 были.

⏩В итоге включили инкрементальное логирование. Теперь логи шлются в Redis, а не во временный файл на ФС. Redis виден Sidekiq и он может парсить логи для поиска и отображения процентов в интерфейсе. Из плюсов, логи теперь вобще не пишутся на ФС, а из минусов, эта схема не работает с кластерным Redis.

Какая мораль
Вынос Sidekiq на отдельный сервер – шаг вполне стандартный и рекомендованный для масштабирования GitLab. Документация хорошая, но иногда совсем не ясно где искать необходимое.
При этом, он обнажает любые неаккуратности в конфигурации и особенности архитектуры.