Gitlab - andyceo/documentation GitHub Wiki

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

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

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

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

Ссылка на официальную инструкцию 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.

Ссылки:

• GitLab Docker images
• gitlab/gitlab-ce

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

Выпуск новой версии, устранение косяков в 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).

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

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

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

    git remote add gitlab ssh://[email protected]: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
   

Ссылки:

• Configuration of your builds with .gitlab-ci.yml
• Переменные, доступные раннеру в .gitlab-ci.yml

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.

Ссылки:

• Quick Start (Gitlab CI)
• Runners
• Configuration of your builds with .gitlab-ci.yml
• Run gitlab-runner in a container
• GitLab Runner at Docker Hub
• Docker integration
• Using Docker Images

• Старая версия, 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

Ссылки:

• Backup restore
• Uninstalling omnibus-gitlab

Отладка webhooks:

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

    nc -l 1234
   

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

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

Ссылки:

• http://muff.kiev.ua/content/nc-realizatsiya-podklyuchenii-i-ozhidanii-vkhodyashchikh-soedinenii-cherez-tcp-i-udp
• http://webhamster.ru/mytetrashare/index/mtb0/1407475810qv5t4pvyrf

Основная страница официальной документации про это: 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: дописать инструкцию с использованием скрипта разворачивания контейнера с докер-приложением.

• GitLab Architecture Overview
• Gogs - Go Git Service - конкурент Gitlab
• Official Docker Gogs image