Установка и настройка GitLab Server
Введение
Представьте: в вашей компании работают 10 разработчиков, код проекта конфиденциален — размещать его на внешних cloud-сервисах нельзя. Или вы работаете в банке — регулятор требует, чтобы код хранился на серверах внутри страны. Или самый простой случай — на GitHub/GitLab.com есть лимиты на бесплатные приватные репозитории, а на собственном сервере всё бесплатно и без ограничений.
GitLab (opens in a new tab) решает именно эти задачи. Это DevOps-платформа с открытым исходным кодом — управление исходным кодом, CI/CD, управление проектами — всё в одном месте. Самое главное — вы можете установить его на свой собственный сервер.
Примеры из реальной практики — когда нужен self-hosted GitLab:
- Финтех/Банки — требование регулятора: код и данные должны храниться внутри страны
- Государственные организации — секретные проекты, сети с ограниченным доступом в интернет
- Средние/крупные компании — 50+ разработчиков, GitHub Enterprise слишком дорог ($21/user/мес), GitLab self-hosted бесплатен
- Стартапы — бюджет ограничен, но нужен профессиональный DevOps-воркфлоу
- Аутсорсинговые компании — для каждого клиента необходима отдельная настройка групп и прав доступа
В этом руководстве мы установим GitLab-сервер с нуля, выполним настройку production-уровня, подключим Runner и запустим реальный CI/CD-пайплайн.
Как работает GitLab?
При установке GitLab на сервере запускается несколько сервисов, работающих совместно. Каждый из них выполняет свою задачу:
+-------------------------------------------------------------------+
| GITLAB SERVER |
| |
| +----------+ +-----------+ +------------+ +-----------+ |
| | | | | | | | | |
| | Nginx |--->| Workhorse |--->| Puma |--->| Sidekiq | |
| | (Proxy) | | (Fayllar) | | (Asosiy | | (Fon | |
| | | | | | ilova) | | ishlar) | |
| +----------+ +-----------+ +------+-----+ +-----------+ |
| | |
| +----------------------+----+ |
| | | | |
| +------+-----+ +----------+-+ +-------+------+ |
| | | | | | | |
| | PostgreSQL | | Redis | | Gitaly | |
| | (DB) | | (Cache) | | (Git repos) | |
| | | | | | | |
| +------------+ +------------+ +--------------+ |
| |
+-------------------------------------------------------------------+Кратко:
- Nginx — принимает запросы из браузера и перенаправляет их в нужное место
- Workhorse — обрабатывает большие файлы (upload/download), чтобы не нагружать Puma
- Puma — основное приложение GitLab. Веб-интерфейс, API, авторизация — всё здесь
- Sidekiq — выполняет фоновые задачи: отправка email, webhook'и, создание пайплайнов
- PostgreSQL — база данных, в которой хранятся все данные
- Redis — кеш и управление сессиями
- Gitaly — сервис для работы с Git-репозиториями
Все эти компоненты не нужно устанавливать отдельно — Omnibus-пакет GitLab автоматически устанавливает и настраивает всё. Поэтому отдельная установка Nginx, PostgreSQL или Redis не требуется.
GitLab CE или EE — какую версию выбрать?
GitLab выпускается в двух версиях. Различия следующие:
| GitLab CE (Community Edition) | GitLab EE (Enterprise Edition) | |
|---|---|---|
| Стоимость | Бесплатная, с открытым исходным кодом | Бесплатная (core) + платные планы |
| CI/CD | Полная поддержка | Дополнительно: merge trains, multi-project pipelines |
| Безопасность | Базовые функции | SAST, DAST, dependency scanning |
| Поддержка | Только сообщество | Официальная техническая поддержка |
| Подходит для | Небольших команд, личных проектов | Крупных организаций, корпоративных сред |
Какую версию устанавливать? Если вы думаете, что в будущем могут понадобиться платные функции — устанавливайте GitLab EE. На бесплатном плане он работает практически так же, как CE, но при необходимости можно активировать платные функции. В большинстве случаев рекомендуется EE.
Способы установки
GitLab можно установить несколькими способами:
| Способ | Описание | Когда использовать |
|---|---|---|
| Linux-пакет (Omnibus) | Установка напрямую на VM или bare-metal сервер | Самый распространённый, рекомендуется для production |
| Docker | Запуск внутри Docker-контейнера | Быстрое тестирование, небольшие команды |
| Kubernetes (Helm chart) | Деплой в K8s-кластер | Крупные организации, когда нужен auto-scaling |
| Из исходников | Самостоятельная сборка кода | Только для особых случаев, не рекомендуется |
В данном руководстве мы используем метод Linux-пакета (Omnibus) — устанавливаем на Ubuntu VM. Это самый распространённый и официально рекомендуемый GitLab способ. Все компоненты (Nginx, PostgreSQL, Redis и др.) поставляются в одном пакете.
Начало работы
Требования к серверу
Минимальные требования к серверу
| Хост | ОС | RAM | CPU | Диск | Статический IP |
|---|---|---|---|---|---|
| gitlab | Ubuntu 20.04+ | 8GB | 4 vCPU, 2 core | 80GB | Да, требуется |
8 ГБ RAM — этого достаточно для 500 пользователей. Если команда больше, рекомендуется 16 ГБ или более. Объём диска растёт в зависимости от количества репозиториев.
Настройка DNS
Для GitLab-сервера нужен домен — через него мы будем заходить в GitLab из браузера и выполнять Git-операции.
В DNS-хостинге необходимо указать IP-адрес GitLab-сервера для домена (или поддомена). Ниже приведён пример для ahost.uz (opens in a new tab).
Перейдите в настройки домена, в раздел DNS-хостинг:
У нас есть домен helm.uz (opens in a new tab). Добавим к нему поддомен gitlab:
- Name ->
gitlab(имя поддомена) - Type ->
A - TTL ->
14400 - RDATA -> статический IP-адрес GitLab-сервера
Установка GitLab
После настройки DNS приступаем к установке.
1-> Обновляем сервер и устанавливаем необходимые пакеты.
sudo apt update && sudo apt upgrade -y
sudo apt install -y curl openssh-server ca-certificates tzdata perl2-> Устанавливаем Postfix для email-уведомлений. GitLab использует почтовый сервер для отправки уведомлений пользователям.
sudo apt install -y postfixВо время установки появится окно конфигурации:
- В первом окне выберите "Internet Site"
- Во втором окне укажите домен вашего сервера (например,
gitlab.helm.uz)
3-> Устанавливаем GitLab. Выберите нужную вкладку — CE или EE:
- GitLab CE
- GitLab EE
Добавляем репозиторий GitLab CE и устанавливаем:
curl -s https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh | sudo bashВ EXTERNAL_URL укажите свой домен:
sudo EXTERNAL_URL="https://gitlab.helm.uz" apt install gitlab-ceПри успешной установке вы увидите следующий результат:
Установка может занять 5-10 минут. По завершении в консоли появится сообщение о пароле администратора — пароль пользователя root сохраняется в файле /etc/gitlab/initial_root_password. Этот файл автоматически удаляется через 24 часа, поэтому скопируйте пароль немедленно!
4-> Откройте в браузере ваш домен (в нашем случае gitlab.helm.uz). Должна открыться страница входа.
Войдите с именем пользователя root. Пароль получите с помощью следующей команды:
sudo cat /etc/gitlab/initial_root_passwordПосле входа откроется страница Welcome to GitLab:
Панель администратора: gitlab.helm.uz/admin — здесь можно посмотреть общую информацию о сервере.
Настройка GitLab Server
GitLab установлен, теперь перед использованием выполним несколько важных настроек.
1. Смена пароля администратора
Сейчас мы вошли с именем пользователя root и автоматически сгенерированным паролем. Давайте изменим их.
Перейдите в профиль -> Edit profile -> раздел Account:
Замените root на ваше имя пользователя и нажмите Update username:
Перейдите в раздел Password и установите новый пароль:
После сохранения вы будете перенаправлены на страницу входа — войдите с новыми учётными данными:
2. Отключение открытой регистрации
По умолчанию на странице входа GitLab есть кнопка Register now — это означает, что кто угодно может зарегистрироваться на вашем сервере. Это небезопасно, поскольку посторонние могут получить доступ.
Чтобы отключить эту функцию:
Перейдите в Admin Area:
Найдите раздел General -> Sign-up restrictions:
Снимите флажок Sign-up enabled и сохраните:
Теперь только администратор может создавать пользователей.
3. Автоматическое обновление SSL-сертификата
При установке GitLab SSL-сертификат автоматически получается через Let's Encrypt. Но сертификат нужно обновлять каждые 90 дней. Для автоматизации этого процесса:
sudo nano /etc/gitlab/gitlab.rbНайдите следующие строки и раскомментируйте (или добавьте):
# /etc/gitlab/gitlab.rb
letsencrypt['auto_renew'] = true
letsencrypt['auto_renew_hour'] = "12"
letsencrypt['auto_renew_minute'] = "30"
letsencrypt['auto_renew_day_of_month'] = "*/7"
letsencrypt['auto_renew_log_directory'] = '/var/log/gitlab/lets-encrypt'Эта настройка проверяет сертификат каждые 7 дней в 12:30 и при необходимости обновляет его.
Применяем изменения:
sudo gitlab-ctl reconfigure4. Настройка GitLab для production (тюнинг gitlab.rb)
Настройки по умолчанию достаточны для небольших команд, но при 20+ пользователях или когда нужно экономить ресурсы сервера, необходимо оптимизировать файл gitlab.rb.
sudo nano /etc/gitlab/gitlab.rb# /etc/gitlab/gitlab.rb — Production tuning
# Количество Puma worker'ов — каждый потребляет ~1 ГБ RAM
# Формула: количество ядер CPU + 1, но корректируйте с учётом RAM
# Для сервера с 8 ГБ RAM и 4 CPU:
puma['worker_processes'] = 4
# Sidekiq — worker для фоновых задач
# По умолчанию 1, при большом количестве пользователей увеличьте до 2-3
sidekiq['max_concurrency'] = 20
# PostgreSQL — shared_buffers рекомендуется устанавливать на 25% от RAM
# Для сервера с 8 ГБ:
postgresql['shared_buffers'] = "2048MB"
# Мониторинг — Prometheus и Grafana
# Состояние сервера можно отслеживать через gitlab.helm.uz/-/grafana
prometheus_monitoring['enable'] = true
grafana['enable'] = true
# Container Registry — для хранения Docker-образов
# Доступен через gitlab.helm.uz:5050
registry_external_url 'https://gitlab.helm.uz:5050'
# Настройки резервного копирования
gitlab_rails['backup_keep_time'] = 604800 # 7 дней (в секундах)Формула расчёта RAM: Сам GitLab потребляет ~4 ГБ RAM. Каждый Puma worker — ещё +700 МБ, каждый Sidekiq worker — +1 ГБ. На сервере с 8 ГБ RAM 4 Puma worker'а и 1 Sidekiq — это близко к пределу. Если на сервере работают и другие сервисы, уменьшите количество worker'ов.
Применяем изменения:
sudo gitlab-ctl reconfigure5. Создание группы и репозитория
В GitLab проекты можно объединять в группы. Например, удобно создать группу DevOps и размещать в ней все соответствующие репозитории:
Создаём новый репозиторий внутри группы:
Выполняем push проекта с локального компьютера:
Установка GitLab Runner
GitLab сам создаёт CI/CD-пайплайны, но для их выполнения нужен отдельный агент — GitLab Runner. Runner берёт каждый job из пайплайна и выполняет его: сборка кода, запуск тестов, деплой.
Типы Runner'ов
+------------------------------------------------------------------+
| GITLAB SERVER |
| |
| +-------------------+ +-------------------+ |
| | Project A | | Project B | |
| +--------+----------+ +--------+----------+ |
| | | |
+------------------------------------------------------------------+
| |
+--------v----------+ +---------v---------+
| Shared Runner | | Specific Runner |
| (Barcha loyihalar | | (Faqat bitta |
| uchun umumiy) | | loyiha uchun) |
+--------+----------+ +---------+---------+
| |
+--------v----------+ +---------v---------+
| Docker | | Shell |
| Executor | | Executor |
+-------------------+ +--------------------+- Shared Runner — обслуживает все проекты. Удобен для общих задач сборки и тестирования
- Specific Runner — привязан к одному проекту или группе. Используется, когда нужна специальная среда
Executor — определяет, где Runner выполняет job'ы:
- Docker executor — для каждого job'а создаётся новый Docker-контейнер (хорошая изоляция, рекомендуется)
- Shell executor — job'ы выполняются непосредственно на самом сервере (просто, но небезопасно)
Установка Runner
1-> Создаём Runner в Admin Area GitLab: Admin Area -> CI/CD -> Runners -> New instance runner
Укажите теги и настройки для Runner'а:
GitLab покажет токен и команду для регистрации:
2-> Теперь переходим на сервер и устанавливаем GitLab Runner:
# Скачиваем бинарный файл
sudo curl -L --output /usr/local/bin/gitlab-runner \
https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-amd64
# Даём права на выполнение
sudo chmod +x /usr/local/bin/gitlab-runner
# Создаём отдельного пользователя для GitLab Runner
sudo useradd --comment 'GitLab Runner' --create-home gitlab-runner --shell /bin/bash
# Устанавливаем и запускаем как сервис
sudo gitlab-runner install --user=gitlab-runner --working-directory=/home/gitlab-runner
sudo gitlab-runner start3-> Мы будем использовать Docker executor, поэтому на сервере должен быть установлен Docker. Воспользуйтесь руководством Установка Docker на Linux-серверы (opens in a new tab).
4-> Регистрируем Runner в GitLab. Используем токен, полученный от GitLab:
gitlab-runner register \
--url https://gitlab.helm.uz \
--token glrt-xxxxxxxxxxxxxxxxxxxxВ процессе регистрации будет задано несколько вопросов:
Runner name: runner1 — это только для идентификации, можно указать любое имя
Executor: docker — для выполнения job'ов внутри Docker-контейнера
Default Docker image: ubuntu:latest — используется, если в .gitlab-ci.yml образ не указан
5-> Запускаем Runner:
sudo gitlab-runner runНажмите View runner в GitLab для проверки — должен отображаться зелёный статус:
Конфигурация Runner
После регистрации Runner'а рассмотрим настройки в файле config.toml:
sudo nano /etc/gitlab-runner/config.toml# /etc/gitlab-runner/config.toml
concurrent = 4 # Сколько job'ов может выполняться одновременно
check_interval = 0 # Интервал опроса GitLab для получения новых job'ов (0 = по умолчанию 3 сек)
shutdown_timeout = 0 # Время ожидания перед завершением работы
[session_server]
session_timeout = 1800 # Таймаут для интерактивного веб-терминала (в секундах)
[[runners]]
name = "runner1"
url = "https://gitlab.helm.uz/"
token = "glrt-xxxxxxxxxxxxxxxxxxxx"
executor = "docker"
[runners.docker]
tls_verify = false
image = "ubuntu:latest" # Docker-образ по умолчанию
privileged = true # Необходимо для Docker-in-Docker
disable_entrypoint_overwrite = false
oom_kill_disable = false
disable_cache = false
volumes = ["/cache"] # Кеш между job'ами
shm_size = 0О параметре privileged = true: Он необходим для Docker-in-Docker (то есть для запуска Docker внутри Docker). Например, если в CI-пайплайне нужно собирать Docker-образы. Однако это небезопасно — контейнер получает полный доступ к хост-серверу. Если сборка Docker-образов не требуется, установите privileged = false.
Предоставляем GitLab Runner'у доступ к Docker:
sudo usermod -aG docker gitlab-runnerПерезапускаем Runner для применения изменений:
sudo gitlab-runner restartПервый CI/CD-пайплайн
Всё готово — GitLab установлен, настроен, Runner подключён. Теперь запустим первый пайплайн.
Как работает CI/CD?
+----------+ +-----------+ +------------+ +----------+
| | | | | | | |
| Dev |---->| GitLab |---->| GitLab |---->| Natija |
| (git push)| | (pipeline | | Runner | | (pass/ |
| | | yaratadi)| | (job bajara-| | fail) |
+----------+ +-----------+ | di) | +----------+
| +------------+
| |
| .gitlab-ci.yml |
+------------------+- Разработчик вносит изменения в код и выполняет git push
- GitLab находит в репозитории файл
.gitlab-ci.ymlи создаёт пайплайн - Runner получает job и выполняет его внутри Docker-контейнера
- Результат (успех или ошибка) отображается в интерфейсе GitLab
Написание пайплайна
Создаём файл .gitlab-ci.yml в корневой директории репозитория. Ниже два реальных примера — простой и production-уровня:
Простой пайплайн — только проверка сборки:
# .gitlab-ci.yml — простой вариант
stages:
- build
build:
stage: build
image: node:20
before_script:
- npm install -g pnpm
script:
- pnpm install
- pnpm next build
cache:
key: "$CI_COMMIT_REF_SLUG"
paths:
- node_modules/
rules:
- if: '$CI_COMMIT_BRANCH == "main"'
tags:
- sharedProduction-пайплайн — сборка, тестирование, создание Docker-образа и деплой:
В реальных проектах обычно несколько этапов. Например, для Node.js-проекта:
# .gitlab-ci.yml — production вариант
stages:
- install
- test
- build
- docker
- deploy
variables:
DOCKER_IMAGE: $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA
DOCKER_IMAGE_LATEST: $CI_REGISTRY_IMAGE:latest
# Установка зависимостей — кешируется для последующих этапов
install:
stage: install
image: node:20
script:
- npm install -g pnpm
- pnpm install --frozen-lockfile
cache:
key: "$CI_COMMIT_REF_SLUG"
paths:
- node_modules/
tags:
- shared
# Запуск тестов
test:
stage: test
image: node:20
script:
- npm install -g pnpm
- pnpm test
cache:
key: "$CI_COMMIT_REF_SLUG"
paths:
- node_modules/
policy: pull # Только чтение, без записи (быстрее)
tags:
- shared
# Сборка проекта
build:
stage: build
image: node:20
script:
- npm install -g pnpm
- pnpm build
artifacts:
paths:
- .next/ # Передача результата сборки на следующий этап
expire_in: 1 hour
cache:
key: "$CI_COMMIT_REF_SLUG"
paths:
- node_modules/
policy: pull
tags:
- shared
# Сборка Docker-образа и push в GitLab Container Registry
docker:
stage: docker
image: docker:24
services:
- docker:24-dind
before_script:
- docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
script:
- docker build -t $DOCKER_IMAGE -t $DOCKER_IMAGE_LATEST .
- docker push $DOCKER_IMAGE
- docker push $DOCKER_IMAGE_LATEST
rules:
- if: '$CI_COMMIT_BRANCH == "main"'
tags:
- shared
# Деплой на сервер (через SSH)
deploy:
stage: deploy
image: alpine:latest
before_script:
- apk add --no-cache openssh-client
- eval $(ssh-agent -s)
- echo "$SSH_PRIVATE_KEY" | ssh-add -
- mkdir -p ~/.ssh
- echo "$SSH_KNOWN_HOSTS" >> ~/.ssh/known_hosts
script:
- ssh $DEPLOY_USER@$DEPLOY_HOST "
docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY &&
docker pull $DOCKER_IMAGE_LATEST &&
docker compose -f /app/docker-compose.yml up -d
"
rules:
- if: '$CI_COMMIT_BRANCH == "main"'
when: manual # Деплой запускается только при ручном подтверждении
tags:
- sharedКлючевые понятия production-пайплайна:
artifacts— передаёт результат сборки на следующий этап (например, директорию.next/на этап docker)cache: policy: pull— на этапах test и build кеш только читается, что экономит время$CI_REGISTRY— встроенный Container Registry GitLab. Отдельный Docker Hub не нуженwhen: manual— этап deploy не запускается автоматически, администратор подтверждает его вручную в интерфейсе GitLab$SSH_PRIVATE_KEY,$DEPLOY_HOST— эти переменные хранятся в Settings -> CI/CD -> Variables (не в коде!)
Добавьте файл в репозиторий и выполните push в ветку main — пайплайн запустится автоматически.
Перейдите в раздел Pipelines:
Успешно выполненный пайплайн:
Для просмотра деталей нажмите на пайплайн:
Здесь мы написали простой пайплайн с одним этапом build. В GitLab CI можно настроить тестирование, деплой, multi-stage пайплайны и многое другое. Подробнее: CI/CD с GitLab CI (opens in a new tab)
Безопасность и резервное копирование
Установить GitLab-сервер недостаточно — необходимо обеспечить его защиту и предусмотреть меры по сохранению данных.
Настройка файрвола
На сервере откройте только необходимые порты, остальные закройте:
sudo ufw allow OpenSSH # SSH (порт 22) — для доступа к серверу через терминал
sudo ufw allow 80/tcp # HTTP — необходим для получения сертификата Let's Encrypt
sudo ufw allow 443/tcp # HTTPS — веб-интерфейс GitLab
sudo ufw enable
sudo ufw statusНастройка резервного копирования
В реальной жизни серверы выходят из строя, диски ломаются, сотрудники допускают ошибки. Без резервных копий все данные — код, issue, конфигурации CI/CD — будут потеряны. Поэтому резервное копирование — это не «настроим, когда понадобится», а то, что нужно настроить с первого дня.
Что сохраняет резервная копия:
- Все Git-репозитории
- Базу данных (пользователи, issue, merge request'ы, конфигурации CI/CD)
- LFS-объекты и загруженные файлы
Что НЕ сохраняет резервная копия (нужно делать отдельно):
/etc/gitlab/gitlab.rb— конфигурация сервера/etc/gitlab/gitlab-secrets.json— ключи шифрования (без них восстановление из резервной копии невозможно)
# Создание резервной копии вручную
sudo gitlab-backup create
# Файлы резервных копий хранятся здесь:
ls /var/opt/gitlab/backups/
# Результат: 1710100800_2024_03_11_16.9.1_gitlab_backup.tarАвтоматическое резервное копирование + бэкап конфигурационных файлов:
sudo crontab -e# Полное резервное копирование каждый день в 2:00
0 2 * * * /opt/gitlab/bin/gitlab-backup create CRON=1
# Отдельное резервное копирование конфигурационных файлов (каждый день в 2:30)
30 2 * * * cp /etc/gitlab/gitlab.rb /var/opt/gitlab/backups/gitlab.rb.$(date +\%F)
30 2 * * * cp /etc/gitlab/gitlab-secrets.json /var/opt/gitlab/backups/gitlab-secrets.json.$(date +\%F)Важно: Хранить резервные копии только на том же сервере недостаточно! Если диск выйдет из строя — резервная копия тоже будет потеряна. В production необходимо копировать бэкапы в другое место:
# Например, на другой сервер с помощью rsync
rsync -avz /var/opt/gitlab/backups/ backup-user@backup-server:/gitlab-backups/
# Или в S3-совместимое хранилище (MinIO, AWS S3)
# В gitlab.rb:
gitlab_rails['backup_upload_connection'] = {
'provider' => 'AWS',
'region' => 'us-east-1',
'aws_access_key_id' => 'ACCESS_KEY',
'aws_secret_access_key' => 'SECRET_KEY',
'endpoint' => 'https://s3.example.com'
}
gitlab_rails['backup_upload_remote_directory'] = 'gitlab-backups'Восстановление из резервной копии (restore):
# Останавливаем сервисы GitLab (база данных и кеш остаются работать)
sudo gitlab-ctl stop puma
sudo gitlab-ctl stop sidekiq
# Восстанавливаем из резервной копии (укажите timestamp из имени файла)
sudo gitlab-backup restore BACKUP=1710100800_2024_03_11_16.9.1
# Восстанавливаем конфигурационные файлы
sudo cp /backup/gitlab.rb /etc/gitlab/gitlab.rb
sudo cp /backup/gitlab-secrets.json /etc/gitlab/gitlab-secrets.json
# Reconfigure и restart
sudo gitlab-ctl reconfigure
sudo gitlab-ctl restartЧек-лист безопасности
На production-сервере обязательно выполните следующие меры:
1. SSH-ключи — отключите вход по паролю:
В файле gitlab.rb:
# Отключение git clone/push по паролю — только через SSH-ключ
gitlab_rails['gitlab_shell_ssh_port'] = 22Пользователи должны добавить свои SSH public key в разделе User Settings -> SSH Keys. После этого:
# Работа через SSH-ключ вместо пароля
git clone git@gitlab.helm.uz:devops/loyiha.git2. 2FA (двухфакторная аутентификация) — сделайте обязательной:
В Admin Area -> Settings -> General -> Sign-in restrictions:
- Включите Two-factor authentication
- Установите Grace period 3 дня — у пользователей будет 3 дня на настройку 2FA
3. Регулярное обновление:
Патчи безопасности GitLab выходят ежемесячно. Процедура обновления в production:
# Перед обновлением создайте резервную копию!
sudo gitlab-backup create
# Обновление
sudo apt update && sudo apt upgrade gitlab-ee -y
sudo gitlab-ctl reconfigure
# Проверка
sudo gitlab-ctl status
sudo gitlab-rake gitlab:check SANITIZE=true4. Мониторинг — отслеживание состояния сервера:
Выше мы включили Prometheus и Grafana в gitlab.rb. Теперь через gitlab.helm.uz/-/grafana можно отслеживать состояние сервера с помощью готовых дашбордов: CPU, RAM, диск, количество запросов, статистика пайплайнов.
5. Rate limiting — защита от brute-force:
# /etc/gitlab/gitlab.rb
# Не более 10 запросов в минуту на страницу входа
gitlab_rails['rate_limiting_response_text'] = 'Retry later'Просмотр логов GitLab
Когда что-то идёт не так, логи — ваш лучший помощник. Каждый компонент GitLab ведёт свой лог:
sudo gitlab-ctl tail # Все логи (в реальном времени)
sudo gitlab-ctl tail puma # Логи веб-приложения
sudo gitlab-ctl tail nginx # Логи прокси
sudo gitlab-ctl tail sidekiq # Логи фоновых задач
sudo gitlab-ctl tail gitaly # Логи Git-операций
sudo gitlab-ctl tail postgresql # Логи базы данныхЕсли проблема неочевидна, запустите общую диагностику:
sudo gitlab-rake gitlab:check SANITIZE=trueЭта команда проверит все компоненты GitLab и покажет обнаруженные проблемы.
Дополнительно
Дополнительные ресурсы
- GitLab CI | Релизы и интеграции (opens in a new tab)
- CI/CD с GitLab CI (opens in a new tab)
- GitHub Actions CI/CD (opens in a new tab)
- Установка Jenkins на Linux-серверы (opens in a new tab)
- От кода до сервера: CI/CD с Jenkins и Docker (opens in a new tab)
- Kubernetes CI/CD | GitHub Actions + Argo CD | GitOps (opens in a new tab)
Ресурсы, использованные при подготовке руководства
- How To Install and Configure GitLab on Ubuntu (opens in a new tab)
- Install self-managed GitLab (opens in a new tab)
- GitLab Administration Documentation (opens in a new tab)
Дата: 2024.06.13 (13 июня 2024 г.)
Последнее обновление: 2026.03.11 (11 марта 2026 г.)
Автор: Отабек Исмоилов
| Telegram (opens in a new tab) | GitHub (opens in a new tab) | LinkedIn (opens in a new tab) |
|---|