- Self-compiled installation
- Consider the Linux package installation
- Select a version to install
- Software requirements
- GitLab directory structure
- Overview
- 1. Packages and dependencies
- sudo
- Git
- Mail server
- ExifTool
- 2. Ruby
- 3. RubyGems
- 5. Node
- 6. System users
- 7. Database
- Supervise Redis with systemd
- Leave Redis unsupervised
- 9. GitLab
- Clone the Source
- Установка веб-инструмента GitLab на Linux Ubuntu Server
- Подготовка сервера
- 1. Обновление списков пакетов
- 2. Время
- 3. Настройка брандмауэра
- Установка GitLab
- 1. Необходимые компоненты
- 2. Установка GitLab
- 3. Конфигурируем веб-адрес
- Вход в веб-интерфейс
- Настройка GitLab
- Русский интерфейс
- Создание репозитория и подключение к нему
Self-compiled installation
This is the official installation guide to set up a production GitLab server using the source files. It was created for and tested on Debian/Ubuntu operating systems. Read requirements.md for hardware and operating system requirements. If you want to install on RHEL/CentOS, you should use the Linux packages. For many other installation options, see the main installation page.
This guide is long because it covers many cases and includes all commands you need, this is one of the few installation scripts that actually work out of the box. The following steps have been known to work. Use caution when you deviate from this guide. Make sure you don’t violate any assumptions GitLab makes about its environment. For example, many people run into permission problems because they changed the location of directories or run services as the wrong user.
If you find a bug/error in this guide, submit a merge request following the contributing guide.
Consider the Linux package installation
Because a self-compiled installation is a lot of work and error prone, we strongly recommend the fast and reliable Linux package installation (deb/rpm).
One reason the Linux package is more reliable is its use of runit to restart any of the GitLab processes in case one crashes. On heavily used GitLab instances the memory usage of the Sidekiq background worker grows over time. The Linux packages solve this by letting the Sidekiq terminate gracefully if it uses too much memory. After this termination runit detects Sidekiq is not running and starts it. Because self-compiled installations don’t use runit for process supervision, Sidekiq can’t be terminated and its memory usage grows over time.
Select a version to install
Make sure you view this installation guide from the branch (version) of GitLab you would like to install (for example, 16-0-stable ). You can select the branch in the version dropdown list in the upper-left corner of GitLab (below the menu bar).
If the highest number stable branch is unclear, check the GitLab blog for installation guide links by version.
Software requirements
GitLab directory structure
When following the instructions on this page, you create this directory structure:
|-- home | |-- git | |-- .ssh | |-- gitlab | |-- gitlab-shell | |-- repositories
- /home/git/.ssh — Contains OpenSSH settings. Specifically, the authorized_keys file managed by GitLab Shell.
- /home/git/gitlab — GitLab core software.
- /home/git/gitlab-shell — Core add-on component of GitLab. Maintains SSH cloning and other functionality.
- /home/git/repositories — Bare repositories for all projects organized by namespace. This is where the Git repositories which are pushed/pulled are maintained for all projects. This area contains critical data for projects. Keep a backup.
The default locations for repositories can be configured in config/gitlab.yml of GitLab and config.yml of GitLab Shell.
For a more in-depth overview, see the GitLab architecture doc.
Overview
1. Packages and dependencies
sudo
sudo is not installed on Debian by default. Make sure your system is up-to-date and install it.
Install the required packages (needed to compile Ruby and native extensions to Ruby gems):
GitLab requires OpenSSL version 1.1. If your Linux distribution includes a different version of OpenSSL, you might have to install 1.1 manually.
Git
- Is always at the version required by GitLab.
- May contain custom patches required for proper operation.
Install the needed dependencies:
Clone the Gitaly repository and compile Git. Replace with the stable branch that matches the GitLab version you want to install. For example, if you want to install GitLab 13.6, use the branch name 13-6-stable :
git clone https://gitlab.com/gitlab-org/gitaly.git /tmp/gitaly make git Optionally, you can remove the system Git and its dependencies:
apt remove
For the Custom Favicon to work, GraphicsMagick must be installed.
Mail server
To receive mail notifications, make sure to install a mail server. By default, Debian is shipped with exim4 but this has problems while Ubuntu does not ship with one. The recommended mail server is postfix and you can install it with:
Then select ‘Internet Site’ and press Enter to confirm the hostname.
ExifTool
GitLab Workhorse requires exiftool to remove EXIF data from uploaded images.
2. Ruby
The Ruby interpreter is required to run GitLab. See the requirements section for the minimum Ruby requirements.
The use of Ruby version managers such as RVM , rbenv or chruby with GitLab in production, frequently leads to hard to diagnose problems. Version managers are not supported and we strongly advise everyone to follow the instructions below to use a system Ruby.
Linux distributions generally have older versions of Ruby available, so these instructions are designed to install Ruby from the official source code.
3. RubyGems
Sometimes, a newer version of RubyGems is required than the one bundled with Ruby.
To update to a specific version:
GitLab has several daemons written in Go. To install GitLab we need a Go compiler. The instructions below assume you use 64-bit Linux. You can find downloads for other platforms at the Go download page.
| shasum go1.19.10.linux-amd64.tar.gz
5. Node
- node 18.x releases (v18.16.1 or later). Other LTS versions of Node.js might be able to build assets, but we only guarantee Node.js 18.x.
- yarn = v1.22.x (Yarn 2 is not supported yet)
In many distributions, the versions provided by the official package repositories are out of date, so we must install through the following commands:
Visit the official websites for node and yarn if you have any trouble with these steps.
6. System users
Create a git user for GitLab:
7. Database
In GitLab 12.1 and later, only PostgreSQL is supported. In GitLab 16.0 and later, we require PostgreSQL 13+.
Install the database packages.
For Ubuntu 20.04 and later:
For Ubuntu 18.04 and earlier, the available PostgreSQL doesn’t meet the minimum version requirement. You must add PostgreSQL’s repository:
wget /etc/apt/sources.list.d/pgdg.list' apt update apt
Verify the PostgreSQL version you have is supported by the version of GitLab you’re installing:
psql Start the PostgreSQL service and confirm that the service is running:
service postgresql start service postgresql status
Create a database user for GitLab:
Create the pg_trgm extension:
Create the btree_gist extension (required for GitLab 13.1+):
Create the plpgsql extension:
Create the GitLab production database and grant all privileges on the database:
Try connecting to the new database with the new user:
Check if the pg_trgm extension is enabled:
If the extension is enabled this produces the following output:
Check if the btree_gist extension is enabled:
If the extension is enabled this produces the following output:
Check if the plpgsql extension is enabled:
If the extension is enabled this produces the following output:
Quit the database session:
See the requirements page for the minimum Redis requirements.
Once done, you can configure Redis:
/etc/redis/redis.conf /etc/redis/redis.conf.orig /etc/redis/redis.conf.orig | /etc/redis/redis.conf | | usermod
Supervise Redis with systemd
If your distribution uses systemd init and the output of the following command is notify , you must not make any changes:
If the output is not notify , run:
/etc/redis/redis.conf redis:redis /etc/redis/redis.conf /etc/systemd/system/redis-server.service.d/10fix_type.conf systemctl daemon-reload systemctl restart redis-server.service
Leave Redis unsupervised
If your system uses SysV init, run these commands:
redis:redis /var/run/redis 755 /var/run/redis | service redis-server restart
9. GitLab
Clone the Source
Установка веб-инструмента GitLab на Linux Ubuntu Server
Обновлено: 09.01.2023 Опубликовано: 14.05.2020
Используемые термины: GitLab, Ubuntu. Рассмотрим процесс установки и настройки веб-инструмента жизненного цикла DevOps на Linux Ubuntu Server на примере версий 18.04 и 20.04. За основу взята официальная инструкция с сайта GitLab. В нашей инструкции приведен пример установки как платной. так и бесплатной версий программы.
Подготовка сервера
В качестве предварительный настроек, мы обновим список пакетов в репозиториях, настроим правильное время и откроем порты в брандмауэре.
1. Обновление списков пакетов
2. Время
* данная команда задаст настройки для московского времени. Все файлы с временными зонами находятся в каталоге /usr/share/zoneinfo. Для автоматической синхронизации времени ставим пакет:
3. Настройка брандмауэра
По умолчанию, в Ubuntu брандмауэр настроен на то, чтобы принимать любые пакеты. Но если у нас он настроен на блокировку, нужно добавить порты 80 и 443.
Установка GitLab
1. Необходимые компоненты
При запросе типа конфигурации, выбираем Internet Site (если уведомления должны отправляться наружу) или Local only (уведомления в пределах сервера): * при получении других запросов во время установки postfix можно ответить по умолчанию, нажимая Enter.
2. Установка GitLab
Если установка выполняется на неподдерживаемую скриптом систему, например, Ubuntu новой версии (на момент обновления инструкции 22) или Astra Linux, мы увидим сообщение об ошибке:
Unfortunately, your operating system distribution and version are not supported by this script.
You can override the OS detection by setting os= and dist= prior to running this script.
You can find a list of supported OSes and distributions on our website: https://packages.gitlab.com/docs#os_distro_version
For example, to force Ubuntu Trusty: os=ubuntu dist=trusty ./script.sh
Please email support@packagecloud.io and let us know if you run into any issues.
* в нашем примере предполагается, что наша система подобна системе Ubuntu 20.04 (Focal Fossa). Запускаем скрипт:
_______ __ __ __
/ ____(_) /_/ / ____ _/ /_
/ / __/ / __/ / / __ `/ __ \
/ /_/ / / /_/ /___/ /_/ / /_/ /
\____/_/\__/_____/\__,_/_.___/
Thank you for installing GitLab!
3. Конфигурируем веб-адрес
* данная настройка говорит, что наш веб-инструмент будет отвечать на запросы, которые пришли на узел gitlab.dmosk.ru — это значит, что данное имя должно быть зарегистрирована в DNS или прописано в локальный файл hosts. Выполняем конфигурирование:
Вход в веб-интерфейс
Открываем браузер и вводим наш адрес, который мы указали в настройках в опции external_url — в данном примере, http://gitlab.dmosk.ru. Мы должны увидеть страницу авторизации, на которой нас запросят пароль для администратора. Посмотреть пароль, который был назначен пользователю после установки можно в файле /etc/gitlab/initial_root_password:
Вводим в качестве пользователя root и пароль, который посмотрели в файле: Мы должны войти в систему.
Настройка GitLab
Русский интерфейс
По умолчанию, портал устанавливается с интерфейсом на английском. Для смены языка, кликаем по иконке в правом верхнем углу и выбираем Settings: В меню слева нажимаем по Preferences: В подразделе Localization выбираем нужный нам язык и первый день недели: Сохранияем настройки и перезапускаем страницу для применения нового языка.
Создание репозитория и подключение к нему
Попробуем создать проект и подключиться к нему из Linux. Также для теста мы создадим файл и закинем его в наш репозиторий. В веб-интерфейсе GitLab создаем новый проект: Задаем имя проекта, оставляем или редактируем URL, выбираем уровень доступа. После кликаем по кнопке Создать проект: * в данном примере мы создаем проект с названием Test, url до него будет http://gitlab.dmosk.ru/root/test. Уровень доступа мы задаем «Приватный» — доступ к репозиторию будет только у авторизованного пользователя. Для примера попробуем подключиться с компьютера Linux к нашему репозиторию и закинуть на него тестовый файл. Для начала установим git на компьютер с Linux: а) Если используем CentOS / Red Hat: