GitLab – это инструмент для создания и управления Git репозиториями. Настройка непрерывной интеграции (Continuous Integration — CI) описана в статье GitLab CI/CD. После установки сервиса Gitlab мы получим бесплатный приватный GIT репозиторий и бесплатный CI/CD.
Старайтесь придерживаться концепции 1 VPS - 1 роль (сервис), не нужно загромождать разными службами (задачами) один и тот же сервер.
Минимальные это значит, что вы GitLab запустите, но вот будет ли он работать? Итак: 2 ядра и 4 ОЗУ. GitLab рекомендуется устанавливать на выделенный VPS c 4 ядрами и 8 ГБ оперативной памяти и быстрые диски (много операций ввода-вывода на диск). Разработчики настоятельно рекомендуют перед установкой настроить SWAP на 50% доступной памяти, мотивируя тем что и без свапа будет работать, но может упасть!!! :( Достаточно ли хороша производительность вашей системы для запуска GitLab в ограниченной среде можно проверить при помощи утилит в разделе Как измерить производительность VPS (bench).
PostgreSQL — единственная поддерживаемая база данных, которая входит в пакет Omnibus GitLab. Вы также можете использовать внешнюю базу данных PostgreSQL (поддержка MySQL была удалена в GitLab 12.1).
GitLab предлагает две разные версии: Community Edition (CE) и Enterprise Edition (EE). Разница gitlab-ee заключается в поддержке, которую вы получаете от GitLab B.V. и если в будущем вы захотите перейти на платный уровень, то вам не придется переустанавливать GitLab.
Существует 2 версии
Как я писал выше, если вы используйте практику 1 сервер - 1 задача, то проблем с установкой GitLab. GitLab при установке подтягивает все нужные зависимости, например Nginx, PostgreSQL. Приведу пример для установки gitlab-ce то есть версии Community Edition.
Предварительно нужно только настроить домен, указывающий на ваш сервер (то есть прописать А запись в DNS). Это важно, потому что сервис GitLab будет самостоятельно пытаться получить SSL сертификат Let’s Encrypt в процессе установки. В этой статье как пример используется домен your_domain, не забудьте заменить его на ваше доменное имя.
apt update apt install ca-certificates curl openssh-server postfix tzdata perl
curl -s https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh | sudo bash apt install gitlab-ce
external_url 'https://your_domain' letsencrypt['contact_emails'] = ['8host@example.com']
После внесения изменений сохраните и закройте файл.
gitlab-ctl reconfigure
Команда инициализирует GitLab, используя информацию о вашем сервере. Это полностью автоматизированный процесс, поэтому вам не придется предпринимать какие-либо действия. Также будет настроен SSL сертификат Let’s Encrypt для указанного вами домена.
https://your_domain
Всё! Измените пароль и имя пользователя так как по умолчанию учетной записи администратора GitLab присваивается имя root (Users Settings → Account).
Этот вариант, когда у вас на сервере уже что-то установлено, но вы вынуждены установить еще и GitLab (чтобы окончательно убить ваш сервер ). И так, у нас уже установлен Nginx, как-то он настроен и нам нужно за ним установить GitLab. Мы будем использовать установку GitLab EE (gitlab-ee), которая работает за сервером Nginx, который будет выполнять обратное проксирование и осуществлять обработку SSL-трафика.
curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-ee/script.deb.sh | sudo bash apt install gitlab-ee
# Укажите своё доменное имя и протокол: external_url 'example.domain' -> external_url 'http://gitlab.<ваш_домен>' # выключаем встроенный nginx nginx['enable'] = true -> nginx['enable'] = false # пользователь, от имени которого работает веб-сервер web_server['external_users'] = [] -> web_server['external_users'] = ['www-data'] # параметр для определения IP адресов проксируемого сервера gitlab_rails['trusted_proxies'] = [ '127.0.0.1', '<внешний IP адрес сервера>' ] # протокол для работы с веб-сервером gitlab_workhorse['listen_network'] = "unix" # интерфейс и порт для прослушивания gitlab_workhorse['listen_addr'] = "/var/opt/gitlab/gitlab-workhorse/socket"
gitlab-ctl reconfigure
Ознакомитесь с официальная документация по настройке производительности GitLab Running GitLab in a memory-constrained environment. Я же пробегусь кратко. Если не сказано обратного, тюнинг делаем в файле /etc/gitlab/gitlab.rb изменяя указанные ниже параметры.
puma['worker_processes'] = 0
Это должно освободить 100-400 МБ памяти.
sidekiq['max_concurrency'] = 5
prometheus_monitoring['enable'] = false
gitlab_rails['env'] = { 'MALLOC_CONF' => 'dirty_decay_ms:1000,muzzy_decay_ms:1000' } gitaly['env'] = { 'MALLOC_CONF' => 'dirty_decay_ms:1000,muzzy_decay_ms:1000' }
После внесения всех этих изменений перенастройте GitLab, чтобы использовать новые настройки:
gitlab-ctl reconfigure
Cразу после установки сервисов Gitlab
# free -h total used free shared buff/cache available Mem: 5.8Gi 4.9Gi 194Mi 128Mi 765Mi 568Mi Swap: 2.0Gi 2.0Mi 2.0Gi
И после примененных вышеприведённых настроек оптимизации, как видим они впечатляют:
total used free shared buff/cache available Mem: 5.8Gi 2.7Gi 2.1Gi 116Mi 1.1Gi 2.8Gi Swap: 2.0Gi 6.0Mi 2.0Gi
Для сбрасывания пароля от пользователя root в GitLab, используем консоль Rails, запускаем её:
gitlab-rails console
На следующем этапе нам нужно узнать настоящий логин пользователя root (ведь вы его могли переименовать). Пользователья с правами root всегда будет первым. И в итоге получается так:
irb(main):007:0> user = User.find(1) => #<User id:1 @root> irb(main):014:0> user.password = 'New_Password' => "New_Password" irb(main):015:0> user.password_confirmation = 'New_Password' => "New_Password" irb(main):016:0> user.save! => true
Если все хорошо, консоль выведет true, после этого можете логинеться как обычно через веб-интерфейс GitLab.
На этом этапе у нас есть рабочий экземпляр GitLab, который размещен на сервере. Вы можете начать импортировать или создавать новые проекты, настраивать соответствующий уровень доступа, конфигурировать GitLab Runner CI/CD.