Непрерывная интеграция/внедрение приложения symfony с помощью docker-compose и gitlab ci

Install the Docker image and start the container

Before you begin, ensure Docker is installed.

To run inside a Docker container, you need to make sure that the configuration is not lost when the container is restarted. To do this, there are two options, which are described below.

Make sure that you read the FAQ section which describes some of the most common problems with GitLab Runner.

• If you are using a , you also
  need to expose port by adding to your command.

• If you want to use the Docker Machine executor for autoscaling feature, you also need to mount Docker Machine
  storage path: :

  • by adding for system volume mounts
  • by adding for Docker named volumes

Option 1: Use local system volume mounts to start the Runner container

This example uses the local system for the configuration volume that is mounted into the container. This volume is used for configs and other resources.

note On macOS, use instead of .

Option 2: Use Docker volumes to start the Runner container

In this example, you can use a configuration container to mount your custom data volume.

1. Create the Docker volume:

2. Start the GitLab Runner container using the volume we just created:

noteTo set the container’s timezone, in the command, use the flag . View a list of available time zones.

¶ Как создавать репозиторий?

Шаг 1. Зайдите в свой аккаунт на GitLab и нажмите на иконку «Groups» в верхней панели.

Шаг 2. Затем перейдите во вкладку «Your group».

Шаг 3. Выберите команду с названием вашего учебного проекта.

Шаг 4. Вы перешли на страницу своей команды. Теперь нужно создать репозиторий. Для этого нажмите на кнопку «New project».

Если у вас уже есть нужный вам репозиторий, то перейдите к шагу 6.

Шаг 5. Напишите название вашего репозитория и добавьте нужные данные. Готово!

Шаг 6.

Перенос существующего репозитория
Если у вас уже есть репозиторий на MIEM GitLab, то его легко можно перенести:

1. Для этого зайдите на страницу нужного вам проекта. Далее перейдите в настройки.

1. Опуститесь до раздела «Advanced» и разверните его с помощью кнопки «Expand».

1. Найдите внутри блок «Transfer project» и с помощью селектора выберите новое расположение.

Перенос существующего репозитория с другой платформы

Если проект был создан на другой платформе (Github, Bitbucket и т.д.), то при создании нового репозитория откройте вверху вкладку «Import project» вместо «Blank project», а затем выберите » Repo by URL».

Подробнее о миграции проектов.

При этом вся информация по коммитам будет перенесена. Однако, чтобы она корректно отображалась и учитывалась в статистике, необходимо, чтобы коммиты были сделаны с почты @miem.hse.ru. Если коммиты были сделаны с другой почты, то необходимо добавить ее адрес в личном кабинете в Git.miem.hse.ru (подробнее в блоке «Коммит»)

Взгляд под другим углом

• создаётся проект common-ci-config, в котором хранится общий и другие файлы, необходимые для сборки;
• создаётся пользователь gitlab-ci-distributor, которому даются права на push (Master) в нужные проекты.

common-ci-configgitlab-ci-distributorcommon-ci-config

• В каждом проекте становится видно, когда изменился и кто его изменил. Пропадает проблема хранения эффективного , т.к. в каждом проекте всегда видно полную версию без include.
• В проектах, где не нужна последняя версия сборочных файлов на момент сборки, сборочные файлы добавляются коммитом.
• В проектах, где на момент сборки всегда нужна последняя версия, сборочные файлы клонируются.
• Можно часть файлов добавлять в коммит, а часть — использовать из клонированной копии.
• Можно реализовать концепцию include для с помощью вызова скрипта. То есть, если нужно, чтобы при сборке всегда использовал последнюю версию конфигурации тестирования, то тестирование выносится в скрипт в проекте common-ci-config.

Шесть, возникшие проблемы

1. ошибка установки gitlab

выполненныйОшибка времени:

Текстовая информация выглядит следующим образом:

Все было красным, и я испугался.

Перейдите на форум GitLab, чтобы найти решение:

2. Старт 502

Я взял. Это было хорошо, но вдруг по необъяснимым причинам получилось 502. Думаю, проблема в тайм-ауте. Его надо выставить в файле конфигурации на более длительное время:

1. Откройте файл:

2. Время модификации

Найдите эти два места:

3. Обновите файл конфигурации.

Тогда я только что закончил изменять указанные выше файлы, если вы все еще не можете?

Попробуйте изменить порт:

Если вы по-прежнему не можете, вернитесь и выполните шаг 5 — удаление-переустановка.

5: Настройка GitLab Bastion

Вернитесь в свое SSH-соединение с bastion-сервером и выполните следующую команду:

sudo gitlab-runner register

Это инициирует процесс связки, и вам будет задан ряд вопросов.

На следующем этапе введите URL-адрес экземпляра GitLab из предыдущего раздела:

Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com)

https://example.com

Затем введите токен экземпляра GitLab:

Please enter the gitlab-ci token for this runner

sample-gitlab-ci-token

Введите описание, которое поможет вам распознать его в веб-интерфейсе GitLab. Мы рекомендуем выбрать уникальное описательное имя, например:

Please enter the gitlab-ci description for this runner

Если это необходимо, вы можете ввести теги кода, который вы будете собирать с помощью runner-сервера. Однако мы рекомендуем на этом этапе оставить это поле пустым. Это можно легко изменить в интерфейсе GitLab.

Please enter the gitlab-ci tags for this runner (comma separated):

code-tag

Следующий параметр позволяет вам выбрать, должен ли ваш runner-сервер создавать репозитории без каких-либо тегов или же требовать определенных тегов. В этом случае выберите значение true, чтобы runner-сервер мог обрабатывать все репозитории.

Whether to run untagged jobs [true/false]: true

Следующее поле позволяет вам распределить runner-сервер между всеми проектами либо зарезервировать его для одного конкретного проекта.

Whether to lock Runner to current project [true/false]: false

Выберите исполнитель, который будет собирать ваши машины. Поскольку GitLab будет создавать новые серверы с помощью Docker, выберите docker+machine (узнать больше о преимуществах каждого подхода можно в этой ):

Please enter the executor: ssh, docker+machine, docker-ssh+machine, kubernetes, docker, parallels, virtualbox, docker-ssh, shell:

docker+machine

Затем нужно выбрать образ по умолчанию (для  проектов, где образ не указан явно). Выберите базовый вариант:

Please enter the Docker image (e.g. ruby:2.1):

alpine:latest

Теперь вы закончили настройку основного runner-сервера! На этом этапе он должен появиться на странице GitLab Runner администратора GitLab, к которой вы обращались, чтобы получить токен.

Если вы столкнулись с какими-либо проблемами, обратитесь к документации GitLab Runner.

Последовательное выполнение задач

Задача ‘package’ должна выполняться только при успешном прохождении тестов. Определим порядок выполнения задач путем введения стадий ():

Должно сработать.

Также не стоит забывать о том, что компиляция (которой в нашем случае является конкатенация файлов) занимает время, поэтому не стоит проводить ее дважды. Введем отдельную стадию для компиляции:

Посмотрим на получившиеся артефакты:

Скачивание файла “compile” нам ни к чему, поэтому ограничим длительность жизни временных артефактов 20 минутами:

Итоговая функциональность конфига впечатляет:

• Есть три последовательных стадии: компиляция, тестирование и архивация приложения.
• Результат стадии компиляции передается на последующие стадии, то есть приложение компилируется только однажды (что ускоряет рабочий процесс).
• Архивированная версия приложения хранится в артефактах сборки для дальнейшего использования.

zypper

Create a file named that contains the repository configuration below.

Make sure to replace el and 6 in the config below with your :

name=runner_gitlab-ci-multi-runner
baseurl=https://packages.gitlab.com/runner/gitlab-ci-multi-runner/opensuse/13.2/$basearch
enabled=1
repo_gpgcheck=1
pkg_gpgcheck=0
gpgkey=https://packages.gitlab.com/runner/gitlab-ci-multi-runner/gpgkey
autorefresh=1
type=rpm-md


name=runner_gitlab-ci-multi-runner-source
baseurl=https://packages.gitlab.com/runner/gitlab-ci-multi-runner/opensuse/13.2/SRPMS
enabled=1
repo_gpgcheck=1
pkg_gpgcheck=0
gpgkey=https://packages.gitlab.com/runner/gitlab-ci-multi-runner/gpgkey
autorefresh=1
type=rpm-md

Valid options for os and dist parameters can be found .

Update your local zypper cache by running

zypper --gpg-auto-import-keys refresh runner_gitlab-ci-multi-runner
zypper --gpg-auto-import-keys refresh runner_gitlab-ci-multi-runner-source

Анатомия репозитория

Репозиторий GitHub состоит из папок, содержащих файлы, такие как важнейшие файлы исходного кода. Обычно в репозитории есть много других типов файлов. Это могут быть файлы документации, страницы руководства, файлы лицензий на программное обеспечение, инструкции по сборке и файлы сценариев оболочки. Нет никаких правил относительно того, что репозиторий должен или должен содержать, но есть соглашения.

Если вы разбираетесь в одной кухне, вы можете ориентироваться на любой кухне. То же самое и с репозиториями. Как только вы поймете условные обозначения, вы поймете, где найти то, что вам нужно.

Итак, как получить копию репозитория на свой компьютер и как встроить программу в двоичный исполняемый файл?

В-четвертых, настройте GitLab

1. ВведитеОткройте файл и поместитеИзмените его на свой собственный IP или HostName, например:

2. Настроить постфикс

Чтобы настроить исходящий почтовый ящик GitLab, мы можем использовать следующую команду для проверки публикации и отправки электронных писем:

Выполните следующую команду, чтобы проверить отправку почты:

Получение письма займет много времени. Рекомендуется сначала заняться другими делами.

Потом через некоторое время у него необъяснимым образом появится подсказка:

Тогда мне было страшно, но мне было очень любопытно, поэтому я вошел и посмотрел:

После открытия: Запишите системный адрес электронной почты отправителя: Я такой:

После завершения вышеуказанной конфигурации вы можете запустить GitLab:

3. Настройте службу SMTP.

Если вы думаете, что это слишком громоздко, вам не нужно настраивать его, это не повлияет на вашу работу, но вы не можете получать сообщения электронной почты, вы также можете использовать систему электронной почты Tencent:

Сделайте конфигурацию эффективной:

Прикрепите общие команды:

Installation

cautionWith GitLab Runner 10, the executable was renamed to . If you
want to install a version prior to GitLab Runner 10, visit the old docs.

1. Create a folder somewhere in your system, ex.: .
2. Download the binary for 64-bit or 32-bit and put it into the folder you
   created. The following assumes you have renamed the binary to (optional).
   You can download a binary for every available version as described in
   .
3. Make sure to restrict the permissions on the GitLab Runner directory and executable.
   If you do not set these permissions, regular users can replace the executable with their own and run arbitrary code with elevated privileges.
4. Run an :
5. Register a runner.

6. Install GitLab Runner as a service and start it. You can either run the service
   using the Built-in System Account (recommended) or using a user account.

   Run service using Built-in System Account (under directory created in step 1. from above, ex.: )

   Run service using user account (under directory created in step 1. from above, ex.: )

   You have to enter a valid password for the current user account, because
   it’s required to start the service by Windows:

   See the if you encounter any
   errors during the GitLab Runner installation.

7. (Optional) Update the runner’s value in
   to allow multiple concurrent jobs as detailed in advanced configuration details.
   Additionally, you can use the advanced configuration details to update your
   shell executor to use Bash or PowerShell rather than Batch.

Voila! Runner is installed, running, and will start again after each system reboot.
Logs are stored in Windows Event Log.

Настройка Nginx

Откройте ваш конфигурационный файл

CentOSnano /etc/nginx/conf.d/${WEBSITE_NAME}.conf

Debian/Ubuntunano /etc/nginx/sites-available/$WEBSITE_NAME

Код вашего файла должен соответствовать следующему:

# переадресация с HTTP на HTTPS
#
server {
    if ($host = website.com) {
        return 301 https://$host$request_uri;
    }
    
    listen 80;
    listen :80;
    server_name website.com;
}
# upstream-серверы для балансировки
#
upstream dirlist {
        ip_hash; # липкая балансировка по IP-клиента
        server 127.0.0.1:8081;
        server 127.0.0.1:8082;
}
# обработка SSL и соединение с upstream-серверами
#
server {
  listen 443 ssl;
  listen :443 ssl;
  server_name website.com;
  ssl_certificate /etc/letsencrypt/live/website.com/fullchain.pem;
  ssl_certificate_key /etc/letsencrypt/live/website.com/privkey.pem;
  access_log /var/log/nginx/website_access.log;
  error_log /var/log/nginx/website_error.log;
 
  # все запросы отправляем на upstream
  location / {
    proxy_pass http://dirlist/;
  }
}

Добавьте в конфигурационный файл следующие строки:

upstream gitlab-workhorse {
   server unix:/var/opt/gitlab/gitlab-workhorse/socket fail_timeout=0;
}

вместо

upstream dirlist {
        ip_hash; # липкая балансировка по IP-клиента
        server 127.0.0.1:8081;
        server 127.0.0.1:8082;
}

Измените блок , чтобы он выглядел как указано ниже:

location / {
     client_max_body_size 0;
     gzip off;

     proxy_read_timeout      300;
     proxy_connect_timeout   300;
     proxy_redirect          off;

     proxy_http_version 1.1;

     proxy_set_header    Host                $http_host;
     proxy_set_header    X-Real-IP           $remote_addr;
     proxy_set_header    X-Forwarded-Ssl     on;
     proxy_set_header    X-Forwarded-For     $proxy_add_x_forwarded_for;
     proxy_set_header    X-Forwarded-Proto   $scheme;
     proxy_pass http://gitlab-workhorse;
}

Добавьте строку в двух блоках (с 80-ым портом и с 443-им)

server_tokens off;

После

server_name website.com;

Замените строку

root /var/www/website.com;

На следующую

root /opt/gitlab/embedded/service/gitlab-rails/public;

Добавьте следующие строки:

ssl on;
ssl_ciphers "ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4";
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 5m;

Перед строками

ssl_certificate /etc/letsencrypt/live/website.com/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/website.com/privkey.pem; # managed by Certbot

В итоге код в конфигурационном файле должен быть таким:

server {
    if ($host = website.com) {
        return 301 https://$host$request_uri;
    } # managed by Certbot
    listen 80;
    listen :80;
    server_name website.com;
    server_tokens off;
}

upstream gitlab-workhorse {
    server unix:/var/opt/gitlab/gitlab-workhorse/socket fail_timeout=0;
}

server {
    listen 443 ssl;
    listen :443 ssl;
    server_name website.com;
    server_tokens off;
    root /opt/gitlab/embedded/service/gitlab-rails/public;

    ssl on;
    ssl_ciphers "ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4";
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_prefer_server_ciphers on;
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 5m;

    ssl_certificate /etc/letsencrypt/live/website.com/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/website.com/privkey.pem; # managed by Certbot


    location / {
       client_max_body_size 0;
       gzip off;

       proxy_read_timeout      300;
       proxy_connect_timeout   300;
       proxy_redirect          off;

       proxy_http_version 1.1;

       proxy_set_header    Host                $http_host;
       proxy_set_header    X-Real-IP           $remote_addr;
       proxy_set_header    X-Forwarded-Ssl     on;
       proxy_set_header    X-Forwarded-For     $proxy_add_x_forwarded_for;
       proxy_set_header    X-Forwarded-Proto   $scheme;
       proxy_pass http://gitlab-workhorse;
  }

}

Сохраните файл и перезагрузите nginx командой или .

Репозиторий коробок

Наша миссия — клонировать репозиторий ящиков, а затем создайте приложение ящиков.

Репозиторий имеет ту же структуру, что и Atom. Там список папок и файлов, а ниже — содержимое файла readme. Он следует стандартной схеме репозитория, но это меньший по размеру проект, поэтому в нем меньше папок и файлов.

Файл readme тоже короче. В нем есть раздел под названием «Разработка». В этом разделе есть ссылка под названием «Построение из исходного кода». Если мы перейдем по этой ссылке, мы должны найти информацию нам нужно.

Обычно для навигации по репозиторию и поиска нужной информации требуется легкое отслеживание, но это не сложно. Внимательно прочтите все на странице репозитория. Иногда информация присутствует, но может не отображаться на видном месте.

GitLab Runner

Также, вместе с GitLab 8.13 был выпущен GitLab Runner 1.7. Список самых интересных изменений:

• Добавлено использование Go 1.7 — добавляет поддержку Runner на Mac OS X Sierra !323
• Добавлена GIT_STRATEGY=none !332
• Добавлена поддержка OffPeak для автоскейлинга !345
• Введена переменная для включения режима трассировки shell в bash, cmd.exe и powershell.exe !339
• В первую очередь загружается конфиг InCluster, если загрузка неудачна — конфиг kubectl !327
• Godep: github.com/Sirupsen/logrus обновлен до версии 0.10.0 !344
• Добавлено использование и !341
• Значение поля runner теперь переводится в нижний регистр для совместимости с ограничениями GCE !297
• Добавлена обработка before_script при выполнении команды exec !355
• Сборки больше не помечаются как неудавшиеся из-за ошибки кеширования !359
• Внесены улучшения в процедуру регистрации !356

Полный список изменений можно посмотреть в чейнджлоге Runner’а.

Создание репозитория и подключение к нему

Попробуем создать проект и подключиться к нему из Linux. Также для теста мы создадим файл и закинем его в наш репозиторий.

В веб-интерфейсе GitLab создаем новый проект:

Задаем имя проекта, оставляем или редактируем URL, выбираем уровень доступа. После кликаем по кнопке Создать проект:

* в данном примере мы создаем проект с названием Test, url до него будет http://gitlab.dmosk.ru/root/test. Уровень доступа мы задаем «Приватный» — доступ к репозиторию будет только у авторизованного пользователя.

Для примера попробуем подключиться с компьютера Linux к нашему репозиторию и закинуть на него тестовый файл.

Для начала установим git на компьютер с Linux:

а) Если используем CentOS / Red Hat:

yum install git-core

б) Если используем Ubuntu / Debian:

apt-get install git

Создаем папку для тестового проекта:

mkdir -p /projects/test

Переходим в нее:

cd /projects/test

Создаем репозиторий:

git init

Создаем файл:

vi testfile.txt

Добавляем в него все файлы (то есть, наш единственный файл):

git add .

Делаем коммит:

git commit -m «Очередное изменение проекта» -a

Подключаемся к созданному репозиторию:

git remote add origin http://gitlab.dmosk.ru/root/test.git

Заливаем в него закоммиченный файл:

git push origin master

Переходим на веб-страницу нашего проекта — мы должны увидеть наш файл:

Настройка SSL

В данном примере мы сконфигурируем наш сервер для возможности работы по https и получения сертификата от Let’s Encrypt. Все настройки выполняются в конфигурационном файле:

vi /etc/gitlab/gitlab.rb

Меняем настройку:

external_url ‘http://gitlab.dmosk.ru’

* где gitlab.dmosk.ru — url для нашего портала, который мы задали при первом конфигурировании.

на:

external_url ‘https://gitlab.dmosk.ru’

* мы просто добавили s к http.

Также настраиваем получение сертификата от Let’s Encrypt:

letsencrypt = true

И задаем опции для автоматического обновления сертификата:

letsencrypt = true
letsencrypt = «22»
letsencrypt = «50»
letsencrypt = «*/7»

* где:

• auto_renew — разрешает автоматическое обновление.
• auto_renew_hour — время в часах, когда нужно запускать задание на обновление сертификата.
• auto_renew_minute — время в минутах, когда нужно запускать задание на обновление сертификата.
• auto_renew_day_of_month — день месяца. В данном примере, раз в 7 дней.

Применяем новую конфигурацию:

gitlab-ctl reconfigure

В процессе переконфигурирования мы можем получить ошибку получения сертификата. Пробуем запустить команду:

gitlab-ctl renew-le-certs

Register the Runner

Get the information needed to register the runner.

• Log into https://gitlab.com/ and go to the repository.
• Navigate to «Settings > CI/CD».
• Click the «Expand» button next to the «Runners» section.
• Scroll down the page and check the «Set up a specific Runner manually» section. It provides the following information.
  • URL: https://gitlab.com/
  • Registration Token: {YourToken}
• Make a note of these values. You’ll need them later.

Register the runner. The URL and token are those displayed above. The description is just text. I’ve given it the machine name.

gitlab-runner register -n \
  --url https://gitlab.com/ \
  --registration-token {YourToken} \
  --executor shell \
  --description "obvm1"

Check the runner is active.

service gitlab-runner status

Using binary file

It is possible to download and install via binary file, if necessary.

Install

WARNING:
With GitLab Runner 10, the executable was renamed to . If you
want to install a version prior to GitLab Runner 10, visit the old docs.

1. Simply download one of the binaries for your system:

   # Linux x86-64
   sudo curl -L --output /usr/local/bin/gitlab-runner "https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-amd64"
   
   # Linux x86
   sudo curl -L --output /usr/local/bin/gitlab-runner "https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-386"
   
   # Linux arm
   sudo curl -L --output /usr/local/bin/gitlab-runner "https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-arm"
   
   # Linux arm64
   sudo curl -L --output /usr/local/bin/gitlab-runner "https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-arm64"
   
   # Linux s390x
   sudo curl -L --output /usr/local/bin/gitlab-runner "https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-s390x"

   You can download a binary for every available version as described in
   .

2. Give it permissions to execute:

   sudo chmod +x /usr/local/bin/gitlab-runner

3. Create a GitLab CI user:

   sudo useradd --comment 'GitLab Runner' --create-home gitlab-runner --shell /bin/bash

4. Install and run as service:

   sudo gitlab-runner install --user=gitlab-runner --working-directory=/home/gitlab-runner
   sudo gitlab-runner start

NOTE:
If is installed and run as service (what is described
in this page), it will run as root, but will execute jobs as user specified by
the command. This means that some of the job functions like cache and
artifacts will need to execute command,
therefore the user under which jobs are run, needs to have access to the executable.

Update

1. Stop the service (you need elevated command prompt as before):

   sudo gitlab-runner stop

2. Download the binary to replace the GitLab Runner executable. For example:

   sudo curl -L --output /usr/local/bin/gitlab-runner "https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-amd64"

   You can download a binary for every available version as described in
   .

3. Give it permissions to execute:

   sudo chmod +x /usr/local/bin/gitlab-runner

4. Start the service:

   sudo gitlab-runner start

Установка GitLab в Ubuntu 18.04

У GitLab есть несколько версий. Кроме онлайн версии, в которую вы можете выгружать свои проекты, доступной на веб-сайте GitLab.com, есть версия Community Edition и платная версия Enterprice Edition, которые можно установить на свой компьютер и создать собственный Git-сервер. В этой инструкции мы рассмотрим, как установить GitLab Ubuntu 18.04 версии Community Edition. Для этого будем использовать официальный репозиторий.

Сначала обновите репозитории до самой последний версии:

1. Установка репозитория

Затем нужно загрузить установщик репозитори из официального сайта. Этот скрипт загрузит и установит все ключи и инструменты необходимые, чтобы подключить репозиторий Gitlab в систему. Для его загрузки и запуска выполните команду:

2. Установка пакета программы

После завершения вы можете установить gitlab-ce командой:

Когда установка GitLab Ubuntu 18.04 будет завершена, вы увидите такое сообщение:

3. Развёртывание GitLab

Теперь нам необходимо подготовить программу к работе. Сначала нужно настроить URL, по которой будет открываться интерфейс GitLab. Для этого откройте файл /etc/gitlab/gitlab.rb и найдите там строчку external_url. Здесь нужно указать ваш домен. На своём локальном компьютере я буду использовать домен gitlab.local:

Сохраните и закройте файл. После этого надо пересобрать программу, учитывая изменённую конфигурацию:

Если на вашем сервере включён брандмауэр, необходимо добавить в исключения порты для протоколов http и ssh:

Чтобы наш локальный домен работал, необходимо добавить запись о нём в файл /etc/hosts:

4. Развёртывание программы с установленным Apache

Если на вашем компьютере уже установлен веб-сервер Apache, вы можете настроить программу таким образом, чтобы она работала через существующий веб-сервер. Для этого измените такие строки в /etc/gitlab/gitlab.rb:

Затем пересоберите программу:

В Apache надо добавить новый виртуальный хост с такой конфигурацией:

<VirtualHost *:80>
ServerName gitlab.local
ServerSignature Off
ProxyPreserveHost On
AllowEncodedSlashes NoDecode
<Location />
  Require all granted
  ProxyPassReverse http://127.0.0.1:8080
  ProxyPassReverse http://gitlab.local
</Location>
RewriteEngine on
RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f
RewriteRule .* http://127.0.0.1:8080%{REQUEST_URI} 
DocumentRoot /opt/gitlab/embedded/service/gitlab-rails/public
ErrorDocument 404 /404.html
ErrorDocument 422 /422.html
ErrorDocument 500 /500.html
ErrorDocument 503 /deploy.html
LogFormat "%{X-Forwarded-For}i %l %u %t \"%r\" %>s %b" common_forwarded
ErrorLog /var/log/apache2/gitlab_error.log
CustomLog /var/log/apache2/gitlab_forwarded.log common_forwarded
CustomLog /var/log/apache2/gitlab_access.log combined env=!dontlog
CustomLog /var/log/apache2/gitlab.log combined
</VirtualHost>

Здесь gitlab.local — это домен, который будет использоваться для доступа к gitlab, а порт 8080 — тот порт, на котором сервис gitlab ожидает соединений. Его можно посмотреть командой:

После этого активируйте модули Apache — rewrite, proxy и proxy_http:

А потом активируйте наш виртуальный хост и перезапустите Apache:

Шаг 5 — Начальная настройка конфигурации через веб-интерфейс

Когда GitLab работает, и доступ разрешен, мы можем выполнить начальную настройку конфигурации приложения через веб-интерфейс.

Первый вход в систему

Откройте доменное имя вашего сервера GitLab в вашем браузере:

При первом входе откроется диалоговое окно установки пароля для учетной записи администратора:

В начальном диалоговом окне ввода пароля укажите и подтвердите защищенный пароль для административной учетной записи. Нажмите кнопку Change your password (Изменить пароль), когда будете готовы.

После этого вы перейдете на стандартную страницу входа в систему GitLab:

Здесь вы можете войти в систему с помощью только что заданного пароля. Учетные данные:

• Имя пользователя: root
• Пароль:

Введите эти значения в поля для существующих пользователей и нажмите кнопку Sign in (Вход). После входа в приложение откроется начальная страница, куда вы сможете добавлять проекты:

Теперь вы можете внести простые изменения и настроить GitLab желаемым образом.

Изменение настроек профиля

Одной из первых задач после установки должна стать настройка профиля. GitLab использует разумные значения по умолчанию, но обычно после начала использования программного обеспечения их требуется изменить.

Чтобы внести необходимые изменения, нажмите значок пользователя в правом верхнем углу интерфейса. Выберите пункт Settings (Настройки) в выпадающем меню:

Откроется раздел настроек Profile (Профиль):

Измените имя и адрес электронной почты с Administrator и admin@example.com на более подходящие значения. Введенное имя будет отображаться другим пользователям, а адрес электронной почты будет использоваться для определения аватара по умолчанию, отправки уведомлений, в действиях Git через интерфейс и т. д.

После завершения настройки нажмите кнопку Update Profile settings (Обновить настройки профиля):

На указанный адрес электронной почты будет отправлено письмо с подтверждением. Следуйте указаниям в письме, чтобы подтвердить учетную запись и начать ее использовать с GitLab.

Изменение имени учетной записи

Нажмите Account (Учетная запись) в левой панели меню:

Здесь вы можете найти свой частный токен API или настроить двухфакторную аутентификацию. Однако пока что нас интересует раздел Change username (Изменить имя пользователя).

По умолчанию первой административной учетной записи присваивается имя root. Поскольку это имя широко известно, безопаснее заменить его другим именем. Изменится только имя учетной записи, права администратора у вас сохранятся. Замените root предпочитаемым именем пользователя:

Нажмите кнопку Update username (Обновить имя пользователя), чтобы внести изменения:

При следующем входе в GitLab обязательно используйте новое имя пользователя.

Добавление ключа SSH для своей учетной записи

В большинстве случаев вы захотите использовать с Git ключи SSH для взаимодействия с проектами GitLab. Для этого вам нужно добавить свой открытый ключ SSH в учетную запись GitLab.

Если вы уже создали на локальном компьютере пару ключей SSH, вы можете просмотреть открытый ключ с помощью следующей команды:

Вы увидите большой блок текста, выглядящий примерно так:

Скопируйте этот текст и вернитесь на страницу настройки профиля в веб-интерфейсе GitLab.

Если вместо этого вы получите сообщение, выглядящее следующим образом, это будет означать, что на вашем компьютере не настроена пара ключей SSH:

В этом случае вы можете создать пару ключей SSH, для чего нужно ввести следующую команду:

Примите параметры по умолчанию, а при желании укажите пароль для локальной защиты ключа:

После этого вы сможете просматривать свой открытый ключ с помощью следующей команды:

Скопируйте отображаемый блок текста и вернитесь в настройки профиля в веб-интерфейсе GitLab.

Нажмите пункт SSH Keys (Ключи SSH) в левом меню:

Вставьте в указанное место открытый ключ, скопированный с локального компьютера. Присвойте ему описательное название и нажмите кнопку Add key (Добавить ключ):

Теперь вы должны иметь возможность управлять проектами и хранилищами GitLab с локального компьютера без ввода учетных данных GitLab.