Skip to content

Gitlab

Jump to bottom
andyceo edited this page Apr 28, 2016 · 20 revisions

На этой странице рассказывается, как поднять Gitlab и настроить внутри него Continuous Integration, используя докер-контейнеры.

На этой странице будет использоваться версия 8.6.4-ce.0, если вам нужна другая, поменяйте везде в тексте на нужную.

При работе с Docker hub, всегда рекомендуется использовать конкретные версии (а не latest или вообще без указания версий), для более эффективного использования кеша файловой системы.

Для обеспечения непересекающегося проброса портов из контейнера на хост-систему, будет использован префикс портов 2501. Это значит, например, что порт 80 в контейнере будет проброшен на 2581 на хост-системе.

Установка Gitlab из докер-образа

Ссылка на официальную инструкцию Gitlab на английском языке: GitLab Docker images

Ссылка на официальный Docker-образ Gitlab CE (Community Edition): gitlab/gitlab-ce

  1. Установка:

     sudo docker run -d -h gitlab.example.com --name gitlab --restart always \
   -p 2944:443 -p 2581:80 -p 2523:22 \
   -v /data/gitlab/config:/etc/gitlab \
   -v /data/gitlab/logs:/var/log/gitlab \
   -v /data/gitlab/data:/var/opt/gitlab \
   -e "GITLAB_SHELL_SSH_PORT=2523" \
   gitlab/gitlab-ce:8.6.4-ce.0

    В данном примере, мы пробрасываем стандартные порты в контейнере на некие нестандартные на хост-системе. Если запросы на порты 80 и 443 можно перенаправить с хоста в контейнер через проксирование в nginx на хосте (тем более, что на хосте могут работать и другие контейнеры, в которые надо пробрасывать HTTP-запросы с определенных доменов или поддоменов), то порт 22 нужно пробросить как есть, а SSH на хосте настроить на использование другого порта:

      sudo docker run -d -h gitlab.example.com --name gitlab --restart always \
    -p 2944:443 -p 2581:80 -p 22:22 \
    -v /data/gitlab/config:/etc/gitlab \
    -v /data/gitlab/logs:/var/log/gitlab \
    -v /data/gitlab/data:/var/opt/gitlab \
    gitlab/gitlab-ce:8.6.4-ce.0

    Более подробно читайте на GitLab Docker images.

  2. Подключаемся к docker-образу, если нам надо сделать там какие-то настройки:

         sudo docker exec -it gitlab bash
    
Например, если ваш докер-контейнер гитлаба пробросил свой `22` порт (SSH) на какой-то отличный от `22` порт на хостовой системе (в нашем примере это порт `2523`, нужно указать это в настройках (файл `/etc/gitlab/gitlab.rb` внутри контейнера):

     sudo docker exec -it gitlab bash
     nano /etc/gitlab/gitlab.rb
     gitlab_rails['gitlab_shell_ssh_port'] = 2523

  3. Заходим на Gitlab из браузера:

     URL: gitlab.example.com:2581
 Login: root
 Password: 5iveL!fe

    По умолчанию, по HTTPS Gitlab не настроен работать.

  4. Чтобы отсылка почты из Gitlab работала корректно, нужно настроить пересылку писем по SMTP. Подробнее см. Docker - Проксирование почты из контейнера на хост-систему. Смотрите этот таск, для приблизительных настроек почты, в т.ч. Gitlab CI: gitlab-ci not sending email on build failure.

Ссылки:

Также, можно установить с помощью Ansible-роли andyceo.docker: Ansible Docker config.

Обновление Gitlab через Docker

Выпуск новой версии, устранение косяков в Dockerfile, который собирает Gitlab - возможные причниы обновиться.

  1. Остановить работающий контейнер:

     sudo docker stop gitlab

  2. Удалим старый контейнер:

     sudo docker rm gitlab

    Или последние два пункта можно сделать одной командой:

     sudo docker rm -f gitlab

  3. Скачаем docker-образ с новым контейнером:

     sudo docker pull gitlab/gitlab-ce:8.6.4-ce.0

  4. Создадим и запустим контейнер с теми же опциями, с которыми мы запускали старый контейнер (см. команду sudo docker run в пункте Установка Gitlab из докер-образа.

  5. Т.к. id пользователей Linux между разными версиями контейнеров могут не сохраниться, то нужно выполнить следующие команды для восстановления прав и пользователей на файлы:

     sudo docker exec gitlab update-permissions
 sudo docker restart gitlab

  6. Могут понадобиться следующие команды (но не всегда, было при переезде с 8.4.x на 8.6.x):

     sudo gitlab-rake db:migrate RAILS_ENV=production --trace
 sudo gitlab-ctl reconfigure
 sudo gitlab-ctl restart

    См. Getting 500 error after upgrading from 8.5

  7. Также, может понадобиться перестартовать раннеры на тех хостах, где они выполняются:

     sudo docker restart gitlab-runner-01
 sudo docker restart gitlab-runner-02
 ...
 sudo docker restart gitlab-runner-0n

Добавление уже существующих репозиториев в Gitlab

Добавим в свежеустановленный Gitlab уже существующий репозиторий, и настроим репозиторий на одновременное использование нескольких удаленных репозиториев (одни из которых будет направлен в Gitlab).

Также, мы начнем эксперименты с CI.

  1. Создадим проект (репозиторий) в админке Gitlab.

  2. Добавляем дополнительный удаленный репозиторий:

     git remote add gitlab ssh://git@gitlab.example.com:2523/root/example.com.git

  3. Заливаем локальную master-ветку в новый удаленный репозиторий:

     git push gitlab master

  4. Создаем новую ветку на основе удаленного master в новом репозитории:

     git checkout -b gitlab-master gitlab/master

  5. Положим специальный файл для Gitlab CI с описанием сборки и тестов .gitlab-ci.yml, следующего содержания:

     before_script:
   - uname -a
 
 job1:
   script:
     - php -v
 
 job2:
   script:
     - php -v

  6. Коммит, пуш (находимся на ветке gitlab-master):

     git add .
 git commit -am "Added .gitlab-ci.yml file"
 git push gitlab HEAD:master

Ссылки:

Создание, запуск, настройка (подключение к Gitlab) и обновление пускателей (раннеров, Runners) для CI

  1. Запустим контейнер с раннером внутри для Gitlab CI (докер-раннер, см. Run gitlab-runner in a container). Для того, чтобы этот раннер мог использовать докер-образы, упомянутые в .gitlab-ci.yml и нужные для сборки проекта, необходимо пробросить ему сокет докера на хост-системе (опция -v /var/run/docker.sock:/var/run/docker.sock):

     sudo docker run -d --name gitlab-runner --restart always \
   -v /var/run/docker.sock:/var/run/docker.sock \
   -v /data/gitlab-runner/config:/etc/gitlab-runner \
   gitlab/gitlab-runner:ubuntu-v1.1.3

    Еше можно установить раннер с помощью Ansible-роли andyceo.docker: Ansible Docker config.

  2. Обновление раннера можно сделать так: сначала удалим его образ целиком (но оставим подключенные папки данных, volumes):

     sudo docker rm -f gitlab-runner

    затем запустим контейнер заново, с теми же опциями (см. sudo docker run в этом разделе). Т.к. при запуске контейнера мы не указывали конкретную версию раннера, будет скачана последняя (latest). Не забывайте пробрасывать папки данных (volumes), чтобы не настраивать раннер повторно (не проходить повторно регистрацию в Gitlab, и т.п.)

  3. Регистрируем раннер в Gitlab:

     sudo docker exec -it gitlab-runner gitlab-runner register

    Когда указываете URL гитлаба к которому будет прикреплен раннер, будьте внимательны! Возможно, потребуется указать IP хост-сервера и хост-порт, на который проброшен гитхаб:

     http://192.168.2.3:2581/ci

    Также, если в ваших файлах .gitlab-ci.yml используется какой-либо docker-образ для сборки, то надо указать executor'ом docker.

    Также, когда указываете образ по умолчанию, указывайте его вместе с тегом (версией), особенно если это ваш вручную собранный образ и у вас нет репозитория образов. Если не указать тег (версию), то executor будет пытаться найти latest, не найдет, пойдет на официальный Docker Hub, не найдет и там - и завершится с ошибкой.

    Еще момент. Ранее, при регистрации, в секции конфига раннера, относящейся к докеру, было прописано priveleged = true. Для раннера версии ubuntu-v1.1.3, после регистрации там оказывалось priveleged = false. Нужно руками поправить на ``priveleged = trueи рестартануть контейнер раннера:sudo docker restart gitlab-runner`. Можно составить команду для регистрации раннера, в которой можно будет указать этот параметр.

После этого, раннер сможет подхватывать задания и выполнять их. Вы должны увидеть статусы сборок в разделе Builds репозитория. Сборки происходят на каждый коммит. Тажке можно видеть текущие раннеры в админке, в соответствующем разделе админки Runners.

Также, нужно включить билды для данного проекта (http://gitlab.example.com/your_name/your_project/edit), вкладка Features, чекбокс Builds.

Если вы хотите строить докер-образы из раннера, см. раздел Упаковываем тестируемое приложение в Docker-контейнер с помощью Gitlab CI.

Ссылки:

Gitlab - перенос данных с omnibus-установки в docker-установку и обновление до последней версии

  • Старая версия, omnibus-установка: 8.2.2 (соответствующий тег докер-образа - 8.2.2-ce.0)

  • Новая версия, docker-установка: 8.4.3 (соответствующий тег докер-образа - 8.6.7-ce.0)

  1. Делаем бекап omnibus-установки:

     sudo gitlab-rake gitlab:backup:create

    Он будет лежать там, где указано в настройке backup_path (файл config/application.yml). По умолчанию это /var/opt/gitlab/backups.

  2. Устанавливаем gitlab из докера:

     sudo docker run -d -h gitlab.example.com --name gitlab --restart always \
   -p 2944:443 -p 2581:80 -p 2523:22 \
   -v /data/gitlab/config:/etc/gitlab \
   -v /data/gitlab/logs:/var/log/gitlab \
   -v /data/gitlab/data:/var/opt/gitlab \
   -e "GITLAB_SHELL_SSH_PORT=2523" \
   gitlab/gitlab-ce:8.2.2-ce.0

  3. В вышеприведенной команде, на хост-системе будет автоматически создана папка /data/gitlab/data. Внутри будет подпапка backups. Скопируем туда свежесделанный бекап:

     sudo cp /var/opt/gitlab/backups/1454922293_gitlab_backup.tar /data/gitlab/data/backups

  4. Внутри контейнера gitlab, исправим пользователя и права на файл с бэкапом, они могли скопироваться неправильно:

     sudo docker exec -it gitlab bash
 
 chmod 600 /var/opt/gitlab/backups/1454922293_gitlab_backup.tar
 chown git:git /var/opt/gitlab/backups/1454922293_gitlab_backup.tar

  5. Восстановим бэкап:

     sudo docker exec -it gitlab bash
 
 # Stop processes that are connected to the database
 gitlab-ctl stop unicorn
 gitlab-ctl stop sidekiq
 
 # This command will overwrite the contents of your GitLab database!
 sudo gitlab-rake gitlab:backup:restore BACKUP=1454922293
 
 # Start GitLab
 gitlab-ctl start
 
 # Check GitLab
 gitlab-rake gitlab:check SANITIZE=true

  6. Проверим, что можем залогиниться в браузере:

     URL: gitlab.example.com:2583
 Login: root
 Password (default): 5iveL!fe

  7. Обновим Gitlab:

     sudo docker rm -f gitlab
 
 sudo docker run -d -h gitlab.example.com --name gitlab --restart always \
   -p 2944:443 -p 2581:80 -p 2523:22 \
   -v /data/gitlab/config:/etc/gitlab \
   -v /data/gitlab/logs:/var/log/gitlab \
   -v /data/gitlab/data:/var/opt/gitlab \
   -e "GITLAB_SHELL_SSH_PORT=2523" \
   gitlab/gitlab-ce:8.6.7-ce.0

    При первом запуске, Gitlab сам запустит все необходимые процедуры обновления.

  8. Поправим права и пользователей файлов:

     sudo docker exec gitlab update-permissions
 sudo docker restart gitlab

  9. Удалим старую Omnibus-установку (необязательно):

     # Stop gitlab and remove its supervision process
 sudo gitlab-ctl uninstall
 
 # Debian/Ubuntu
 sudo dpkg -r gitlab
 
 # Redhat/Centos
 sudo rpm -e gitlab

Также, можно попробовать другой способ: если Gitlab был установлен через deb-пакет (см. Install a GitLab CE Omnibus package on), то можно просто удалить этот пакет:

sudo aptitude purge gitlab-ce

И не забыть потом удалить данные из рабочих папок Gitlab:

sudo rm -rf /var/opt/gitlab/
sudo rm -rf /opt/gitlab

Ссылки:

Настраиваем WebHooks

Отладка webhooks:

  1. Откроем на сервере, на котором планируется обрабатывать веб-хуки Gitlab (пусть у него будет адрес example.com), эхо-сервер nc:

     nc -l 1234

  2. В Gitlab, зарегистрируем новый хук.

  3. Нажмите кнопку Test у вебхука. В консоли сервера отобразится посланный хук.

Ссылки:

Упаковываем тестируемое приложение в Docker-контейнер с помощью Gitlab CI

Основная страница официальной документации про это: Using Docker Build

Два основных пути:

  1. Запускать Runner на машине с докером, c executor=shell, прописывать пользователя раннера в группу docker (что даст ему полные права root).
  2. Использовать executor=docker, но когда в контейнере присутствует демон докера (docker-in-docker, dind), связанный с хост-машиной.

Мы будем рассматривать второй путь. Здесь нам понадобиться минимум два раннера (т.к. мы будем использовать два разных сервера): первый, который будет собирать приложение в контейнер и пушить его в приватный репозиторий, (а перед этим, если нужно, запустит тесты и сборку), а второй - будет запускать собранный контейнер (docker run). При этом, эти раннеры могут быть разнесены на разные сервера (первый - в котором запушен раннер-сборщик - мощный, а второй - в котором запушен раннер-пускатель контейнеров - менее мощный, т.к. он исполняет просто продакшен-контейнер). В случае, если вы используете один сервер для всего, можно обойтись одним раннером.

  1. Запустим первый Runner (для сборки проекта) в docker-контейнере:

     sudo docker run -d --name gitlab-runner \
 	--restart always \
 	-v /var/run/docker.sock:/var/run/docker.sock \
 	-v /data/gitlab-runner/config:/etc/gitlab-runner \
 	gitlab/gitlab-runner:ubuntu-v1.1.3

    Обратите внимание, что контейнер, в котором исполняется раннер, запущен в непривилегированном режиме, без флага --privileged. Это не нужно, т.к. в этот контейнер напрямую пробрасывается сокет из хост-системы.

  2. Затем, нужно зарегистрировать (или перерегистрировать) раннер в вашей копии Gitlab:

     sudo docker exec -it gitlab-runner bash
 gitlab-runner register --docker-image "gitlab/dind:latest" --docker-privileged

    Здесь при регистрации раннера указано, что он будет запускать образы докера в привилегированном режиме (опция --docker-privileged). Этот раннер теперь может использовать docker для сборки образов, для их пуша в приватный репозиторий. Если не будет установлена опция --docker-privileged, то вы получите следующее сообщение, когда раннер доберется до первой команды docker: Cannot connect to the Docker daemon. Is the docker daemon running on this host. В качестве образа, используемого по умолчанию (--docker-image "gitlab/dind:latest").

  3. Настраиваем второй раннер, не в контейнере. Docker на этой машине уже должен быть установлен:

     # Add Gitlab runner Debian/Ubuntu repository:
 curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-ci-multi-runner/script.deb.sh | sudo bash
 
 # Install Gitlab runner:
 sudo apt-get install gitlab-ci-multi-runner
 
 # Add gitlab-runner user to docker group:
 sudo usermod -aG docker gitlab-runner
 
 # Verify that gitlab-runner has access to Docker:
 sudo -u gitlab-runner -H docker info
 
 # Register the runner:
 sudo gitlab-ci-multi-runner register

    Ссылки: Install using official GitLab repositories, Use shell executor

  4. Зарегистрируем раннер:

     sudo docker exec -it gitlab-runner bash
 gitlab-runner register --docker-privileged

    Не забудьте указать тег, чтобы отфильтровать запуск этого раннера.

  5. Настроим соответствующим образом файл .gitlab-ci.yml

@TODO: дописать инструкцию.

Краткая мысль: мы создаем образ-билдер (builder), чтобы этот образ собирал проект и упаковывал его в docker-контейнер. Можно отнаследоваться от образа gitlab/dind, который в свою очередь наследуется от jpetazzo/dind, для того, чтобы иметь возможность создавать образы и пушить их в репозиторий (в том числе, в свой приватный репозиторий). Подробности в п.2 данного раздела.

@TODO: дописать инструкцию с использованием скрипта разворачивания контейнера с докер-приложением.

Интересные ссылки

Footer is under construction

Sidebar is under construction

Clone this wiki locally