В этой серии статей мы рассмотрим процесс размещения инфраструктуры для разработки в облаке InfoboxCloud. Для удобного развертывания стека приложений будем использовать Docker.

В первой статье развернем Gitlab, включающий в себя:

  • веб-интерфейс для системы управления исходными текстами git, максимально похожий на GitHub
  • удобный просмотр активностей пользователей
  • браузер файлов
  • Wiki
  • возможности проведения Code Review
  • баг-трекер
  • возможность создания сниппетов кода
  • возможность вставки web hooks
  • билд-сервер

и многое другое.



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

Подготовка окружения


1. Создайте сервер с CentOS 7 для установки Docker в InfoboxCloud. Для работы Docker сейчас необходима именно виртуальная машина, поэтому при создании сервера обязательно установите галочку «Разрешить управление ядром ОС».

Как правильно создать сервер в InfoboxCloud для Docker
Если у вас еще нет доступа в InfoboxCloud – закажите его.

После регистрации вы получите данные для доступа к панели управления на email. Войдите в панель управления по адресу: https://panel.infobox.ru

В разделе «Облачная инфраструктура» вашей подписки нажмите «Новый сервер» (при необходимости подписка меняется в правом верхнем углу в выпадающем меню).



Задайте необходимые параметры сервера. Обязательно выделите серверу 1 публичный IP–адрес и установите галочку «Разрешить управление ядром ОС», как показано на скриншоте ниже.



В списке доступных операционных систем выберите CentOS 7 и завершите создание сервера.



После этого данные для доступа к серверу придут к вам на электронную почту.

После создания сервера с CentOS 7 подключитесь к нему по SSH.

Мы подготовили скрипт, который позволит вам установить Docker и полезные утилиты для работы с Docker на такой сервер. Необходимые настройки будут выполнены автоматически.

Выполните команду для установки Docker и Compose:

bash <(curl -s http://repository.sandbox.infoboxcloud.ru/scripts/docker/centos7/install.sh)

Docker и compose будут установлены.

Можно создать образ с установленным docker в панели управления, нажав на сервер и далее «Создать образ». После этого из образа с Docker можно будет создавать новые сервера и не выполнять этот шаг повторно.

Системные требования к облачному серверу


Для комфортной работы Gitlab рекомендуется 2 ядра CPU и 2Gb Ram от 100 до 500 пользователей.
Если нужно максимально сэкономить при тестировании — можно серверу с Gitlab выдать 1 ядро CPU 1 ггц, но памяти должно быть не менее 2 гб.

Если нужно работать с большим количеством пользователей:

CPU
  • 4 ядра CPU – до 2,000 пользователей
  • 8 ядер CPU – до 5,000 пользователей
  • 16 ядер CPU – до 10,000 пользователей
  • 24 ядра CPU – до 15,000 пользователей

RAM
  • 4GB RAM – до 1,000 пользователей
  • 8GB RAM — до 2,000 пользователей
  • 16GB RAM — до 4,000 пользователей
  • 32GB RAM — до 8,000 пользователей
  • 64GB RAM — 16,000 пользователей

Если нужно большее количество пользователей — можно запустить Gitlab на нескольких серверах.

Устанавливаем Gitlab


Мы уже подготовили файлы для быстрого развертывания Gitlab последней версии. Gitlab будет развернут в Docker-контейнер. Перед этим мы обновим официальный образ с Gitlab: получим все обновления на ОС включая последнюю версию Gitlab (официальный образ обновляется с задержкой, у нас последняя стабильная версия будет раньше).

Установите git командой:

yum install -y git

Перейдите в директорию пользователя.

cd ~

Скачайте необходимые файлы для развертывания gitlab.

git clone https://github.com/trukhinyuri/gitlab-docker.git

Теперь перейдите в директорию с файлами для развертывания.

cd ~/gitlab-docker

В директории присутствуют следующие файлы и директории:

  • Dockerfile: описывает действия, которые будут произведены над официальным образом gitlab;
  • docker-compose.yml описывает как нужно развертывать полученный образ, какие порты пробрасывать, какие папки контейнера монтировать куда на хост;
  • папка config: в этой папке gitlab будет хранить конфигурационные файлы
  • папка data: в этой папке gitlab будет хранить файлы данных
  • папка logs: в этой папке gitlab будет хранить логи логи

В Dockerfile содержится:
FROM gitlab/gitlab-ce:latest
MAINTAINER Yuri Trukhin <yuri@trukhin.com>
ENV REFRESHED_AT 2015.09.27.004
ENV GITLAB_SHELL_SSH_PORT 8005
RUN apt-get update
RUN apt-get -y upgrade
EXPOSE 80
EXPOSE 443
EXPOSE 22

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

  • FROM указывает из какого образа какой версии будем строить контейнер. В данном случае используем официальный образ Gitlab Community Edition последней версии.
  • ENV устанавливает переменные окружения. ENV REFRESHED_AT 2015.09.27.004 — дата сборки образа. Если необходимо обновить контейнер — меняем дату, перестраиваем образ (как это делать ниже) и разворачиваем его. ENV GITLAB_SHELL_SSH_PORT 8005 указывает Gitlab, что на хосте SSH будет располагаться на порту 8005 и нужно работать с этим портом (и учитывать это в веб-интерфейсе).
  • RUN запускает команды внутри контейнера. Обновляем ОС.
  • EXPOSE показывает какие порты нужно сделать доступными для проброса на хост.

В docker-compose.yml содержится:

gitlab:
  build: .
  ports:
  - "8004:443"
  - "8003:80"
  - "8005:22"
  volumes:
  - ./config:/etc/gitlab
  - ./logs:/var/log/gitlab
  - ./data:/var/opt/gitlab
  restart: always

Первой строкой указываем название контейнера, который получится в результате. build указывает путь где располагается Dockerfile для сборки образа. В секции ports указываем какие порты хоста пробросить на какие порты контейнера. В секции volumes указываем какие папки хоста пробросить в контейнер в соответствующие папки. Политика restart: always означает, что контейнер будет запускаться автоматически и при загрузке системы и при падении процессов в нем.

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

docker-compose build

Затем развернуть контейнер командой:

docker-compose up -d

Если перед Gitlab вам необходимо поставить балансировщик — пример создания связанных контейнеров с балансировщиком можно увидеть в этой статье. Рекомендуется включить шифрование трафика на стороне балансировщика NGINX для безопасного входа в Gitlab.

Если вы не знаете, как отредактировать файл — подробности в этой статье в разделе «Как отредактировать текстовый файл». Если вам интересно разобраться с Docker Compose – подробности тут.

Теперь вы можете войти в gitlab по адресу:

http://ip–адрес вашего сервера

Gitlab был успешно установлен.



Данные для входа по-умолчанию:

  • логин: root
  • пароль: 5iveL!fe

При первом входе будет предложено установить новый пароль для входа.

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



Первоначальная настройка


Направьте A–запись домена, с которым будет использоваться gitlab, на выделенный ip–адрес хоста в облаке. Выделенный адрес можно посмотреть в панели управления в разделе «Облачная инфраструктура».



Основные параметры gitlab следует указать на хосте в файле ~/gitlab/config/gitlab.rb.

Если строчки с параметрами, которые мы будем указывать, закомментированы (перед параметром установлена #) — # следует убрать. Это нужно сделать только для тех параметров, которые устанавливаем.

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

cp gitlab.rb gitlab.rb.old


Конфигурация параметров в gitlab.rb

external_url

В параметре укажите домен, направленный на сервер, по которому будет доступен Gitlab.



time_zone

В этом параметре указывается часовой пояс.

gitlab_rails['time_zone'] = 'Europe/Moscow'

Настройки почты в gitlab.rb

В данном разделе указаны работающие параметры в gitlab.rb для домена, привязанного к Яндекс Почте. Настройки для Gmail и Mailgun указаны тут.

Вставьте эти параметры в файл gitlab.rb, заменив git.alm@plugndo.com на адрес вашей яндекс для домена. Замените здесь ваш пароль от почты на ваш пароль от почты. Вместо plugndo.com вставьте имя вашего почтового домена. Остальные настройки оставьте неизменными.

gitlab_rails['smtp_enable'] = true
gitlab_rails['smtp_address'] = "smtp.yandex.ru"
gitlab_rails['smtp_port'] = 587
gitlab_rails['smtp_user_name'] = "git.alm@plugndo.com"
gitlab_rails['smtp_password'] = "здесь ваш пароль от почты"
gitlab_rails['smtp_domain'] = "plugndo.com"
gitlab_rails['smtp_authentication'] = "login"
gitlab_rails['smtp_enable_starttls_auto'] = true
#gitlab_rails['smtp_openssl_verify_mode'] = 'peer'

gitlab_rails['gitlab_email_from'] = 'git.alm@plugndo.com'
gitlab_rails['gitlab_email_reply_to'] = 'git.alm@plugndo.com'

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

docker restart CONTAINER_ID

, где вместо CONTAINER_ID укажите уникальный номер вашего контейнера с gitlab. Его можно посмотреть с помощью команды:

docker ps

Для проверки корректности настройки почты создайте пользователя в Gitlab, если все сделано правильно — пользователь получит на email ссылку для установки пароля.



Заключение


После применения инструкций статьи вы получили актуальную версию Gitlab на собственном облачном сервере. Можно приступать к настройке системы для ваших проектов. Благодаря тройной репликации в распределенной отказоустойчивой системе хранения данных в InfoboxCloud вы можете не беспокоиться за сохранность ваших данных.

Как получить пробную версию InfoboxCloud бесплатно?

Пришлите нам ваш адрес электронной почты и ФИО на trukhinyuri@infoboxcloud.com, в ответ получите данные для доступа к панели управления. Вы можете тестировать новый регион облака в течение 14 дней, далее можно перейти на полную версию облака.

Если вы нашли ошибку в статье или у вас есть вопросы/замечания, напишите нам в ЛС или на почту. Если вы не можете оставлять комментарии на Хабре, напишите в Сообществе InfoboxCloud.

Продуктивной разработки!

Комментарии (9)


  1. Scratch
    28.09.2015 13:22

    У комьюнити gitlab нет хуков, поэтому он малоюзабельный


    1. nmike
      30.09.2015 00:17

      как нет хуков? а кто мешает в самом репозитарии их поднять? гитлаб использует (на сколько я знаю) только update хук, как минимум pre-recieve не трогает. В конце концов под ним обычный git бежит.


      1. Scratch
        30.09.2015 06:51

        каждый раз в конфиги лазить когда нужно хук настроить? Спасибо, я и без гитлаба справлюсь


        1. outcoldman
          30.09.2015 07:18

          А на что именно хук нужен?
          Есть веб хуки.


          1. Scratch
            30.09.2015 09:36

            Нужно, чтобы после коммита в мастер, например, запускался билд в дженкинсе, т.е отправлялся обычный http get запрос на нужный урл.
            В codebasehq это делается одним кликом


            1. outcoldman
              30.09.2015 15:44

              В GitLab Community Edition есть WebHooks. Вот этот плагин нужно поставить в Jenkins
              github.com/elvanja/jenkins-gitlab-hook-plugin


              1. Scratch
                30.09.2015 22:18

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


                1. outcoldman
                  30.09.2015 23:05

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


  1. outcoldman
    28.09.2015 18:25

    Я бы рекомендовал бы использовать неофициальный gitlab docker image hub.docker.com/r/sameersbn/gitlab
    Он просто великолепен. Не понимаю, почему gitlab не попросили sameersbn просто отдать им этот image.