GitLab Self-Hosted: встановлення, адміністрування та оновлення під ключ

GitLab Self-Hosted: встановлення, адміністрування та оновлення під ключ

Зберігати код на GitLab.com зручно рівно до моменту, коли юридичний або compliance-відділ вимагає розмістити репозиторії всередині периметра. Або коли рахунок за 500 користувачів перевищує бюджет. Self-hosted GitLab дає повний контроль, але навантажує команду операційною відповідальністю: продуктивність, безпека, апгрейди. І якщо апгрейд провалиться — сервіс зупиниться на години. Ми вирішуємо це завдання під ключ: від вибору схеми розгортання до регулярних оновлень без даунтайму.

За час нашої роботи ми розгорнули GitLab більш ніж для 50 проєктів — від стартапів з 10 розробниками до enterprise з тисячами користувачів. Кожен випадок вимагав індивідуального підходу до інфраструктури, бекапів та процесу оновлень. Нижче — конкретні схеми, конфіги та підводні камені, з якими ми стикалися.

Як вибрати спосіб встановлення?

Три офіційні способи розгорнути GitLab — Omnibus, Helm chart і Docker Compose — і кожен підходить під своє навантаження.

Omnibus (gitlab-ee deb/rpm) — найпростіший варіант для одного сервера. Все в одному: Nginx, PostgreSQL, Redis, Sidekiq, Workhorse, Gitaly. Конфігурація в /etc/gitlab/gitlab.rb. Ідеальний для команд до 500 осіб на одному потужному хості. Ми рекомендуємо Omnibus для 90% клієнтів: він у 10 разів простіший в адмініструванні, ніж Helm.

Helm chart (gitlab/gitlab) — для Kubernetes. Кожен компонент розгортається як окремий Deployment: webservice, sidekiq, gitaly, kas, registry. Горизонтальне масштабування досягається за рахунок складності: мінімальні ресурси для production — 16 CPU / 32 ГБ RAM тільки під GitLab. Вибирайте Helm, якщо ваш стандарт — Kubernetes, і ви готові інвестувати в його адміністрування.

Docker Compose — тільки для dev-середовищ та тестів. У production не використовуємо. Приклад тюнінгу gitlab.rb під high load:

# Продуктивність Puma
puma['worker_processes'] = 4
puma['min_threads'] = 1
puma['max_threads'] = 4
# PostgreSQL
postgresql['shared_buffers'] = "2048MB"
postgresql['work_mem'] = "32MB"
postgresql['max_connections'] = 200
# Gitaly
gitaly['configuration'] = {
  concurrency: [
    { rpc: "/gitaly.SmartHTTPService/PostUploadPack", max_per_repo: 20 },
  ]
}

Hardening: як захистити інстанс від атак?

Після встановлення GitLab відкритий для інтернету ширше, ніж потрібно. Мінімальні кроки забезпечення безпеки:

• Вимкнути публічну реєстрацію (gitlab_rails['gitlab_signup_enabled'] = false) — інакше інстанс стає здобиччю спам-ботів за кілька годин.
• Налаштувати SMTP для нотифікацій — без цього 2FA по email не запрацює.
• Увімкнути HTTPS: в gitlab.rb letsencrypt['enable'] = true, external_url 'https://git.company.com'.
• Обмежити rate limit: gitlab_rails['rate_limit_requests_per_period'].
• Налаштувати LDAP/SAML для інтеграції з корпоративним IdP.

Окремо — винесення Gitaly на окремий сервер з швидкими NVMe. Це знижує затримки при клонуванні та push на 30% і зменшує навантаження на основний сервер.

Чому апгрейди ламаються (і як цього уникнути)

GitLab вимагає послідовного оновлення через проміжні версії. Стрибок з 15.x на 17.x напряму неможливий. Кожне мажорне оновлення містить breaking changes. Характерний випадок: апгрейд з 16.x на 17.0 ламав інсталяції з кастомними налаштуваннями PostgreSQL через незавершені фонові міграції. Помилка: PG::UndefinedTable: ERROR: relation "ci_runners" does not exist. Рішення — перед апгрейдом дочекатися завершення всіх міграцій командою gitlab-rake gitlab:background_migrations:finalize.

Наш процес апгрейду (ми робимо його замовникам раз на квартал):

1. Перевірити незавершені фонові міграції.
2. Зробити повний бекап: gitlab-backup create SKIP=artifacts (артефакти окремо в object storage).
3. Послідовно оновлювати за матрицею сумісності GitLab.
4. Після кожного кроку запускати gitlab-ctl status та gitlab-rake gitlab:check.

Ми гарантуємо відсутність даунтайму: всі операції проводяться в rolling-режимі або з мінімальним вікном обслуговування.

Резервне копіювання та відновлення

За замовчуванням gitlab-backup кладе архів локально — на той самий диск, що й дані. Це не бекап, а ілюзія. Налаштовуємо Object Storage:

gitlab_rails['backup_upload_connection'] = { 'provider' => 'AWS', 'region' => 'eu-central-1', 'aws_access_key_id' => ENV['AWS_ACCESS_KEY_ID'], 'aws_secret_access_key' => ENV['AWS_SECRET_ACCESS_KEY'] }
gitlab_rails['backup_upload_remote_directory'] = 'my-gitlab-backups'
gitlab_rails['backup_keep_time'] = 604800 # 7 днів

Cron: 0 2 * * * /opt/gitlab/bin/gitlab-backup create CRON=1. Відновлення тестуємо щокварталу — це обов'язкова процедура.

Терміни та процес роботи

Повний цикл «з нуля до production» займає 3-5 днів. Вартість розраховується індивідуально після аудиту ваших вимог.

Що входить в роботу

Ми працюємо з GitLab постійно: досвід 50+ проєктів. Оцінимо ваш проєкт за 1 день. Напишіть нам для консультації — розберемо вашу ситуацію та запропонуємо рішення.