Как автоматически масштабировать непрерывное развертывание GitLab с GitLab Runner в DigitalOcean

Вступление

GitLab - это инструмент с открытым исходным кодом, используемый командами разработчиков программного обеспечения для управления полным жизненным циклом разработки и доставки. GitLab предоставляет широкий набор функций: отслеживание проблем, git-репозитории, непрерывная интеграция, реестр контейнеров, развертывание и мониторинг. Все эти функции созданы с нуля как единое приложение. Вы можете разместить GitLab на своих собственных серверах или использовать https://gitlab.com [GitLab.com], облачный сервис, где проекты с открытым исходным кодом получают все функции высшего уровня бесплатно.

Функции непрерывной интеграции / непрерывной доставки (CI / CD) GitLab - это эффективный способ выстроить привычку тестировать весь код перед его развертыванием. GitLab CI / CD также отлично масштабируется благодаря дополнительному инструменту GitLab Runner, который автоматизирует масштабирование вашей очереди сборки, чтобы избежать длительного ожидания команд разработчиков, пытающихся выпустить код.

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

цели

Мы собираемся построить в DigitalOcean масштабируемый процесс CI / CD, который автоматически реагирует на запросы путем создания новых серверов на платформе и уничтожает их, когда очередь пуста.

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

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

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

* GitLab *: Ваш размещенный экземпляр GitLab или собственный экземпляр, где хранятся ваши репозитории кода.
* GitLab Bastion *: сервер bastion или Droplet - это ядро того, что мы будем настраивать. Это управляющий экземпляр, который используется для взаимодействия с API DigitalOcean для создания капель и их уничтожения при необходимости. На этом сервере не выполняются задания.
* GitLab Runners *: ваши runners - это временные серверы или дроплеты, которые создаются на лету сервером bastion, когда это необходимо для выполнения задания CI / CD в вашей очереди сборки. Эти серверы являются одноразовыми и находятся там, где ваш код выполняется или тестируется до того, как ваша сборка будет помечена как проходящая или неудачная.

изображение: https: //assets.digitalocean.com/articles/gitlab-runner/Autoscaling-GitLab-Runners.png [Диаграмма бегунов GitLab]

Используя каждый из компонентов GitLab, процесс CI / CD позволит вам быстро масштабироваться в зависимости от потребностей. Помня об этих целях, мы готовы начать настройку нашего непрерывного развертывания с GitLab и DigitalOcean.

Предпосылки

В этом руководстве предполагается, что вы уже настроили GitLab на своем собственном сервере или через размещенный сервис и что у вас уже есть учетная запись DigitalOcean.

Чтобы настроить это на Ubuntu 16.04 Droplet, вы можете использовать изображение DigitalOcean одним щелчком мыши или следовать нашему руководству: «https://www.digitalocean.com/community/tutorials/how-to-install-and-configure- gitlab-on-ubuntu-16-04 [Как установить и настроить GitLab в Ubuntu 16.04]. »

Для целей данного учебного пособия мы предполагаем, что у вас есть доступ к частным сетям для этой капли, чего вы можете достичь, следуя нашему руководству на «https://www.digitalocean.com/community/tutorials/how-to-enable-digitalocean-». частные сети на существующих каплях [Как включить частную сеть DigitalOcean на существующих каплях] », но это не обязательно.

В этом руководстве мы будем использовать не-root пользователей с правами администратора в наших каплях.

Шаг 1 - Импортировать проект JavaScript

Для начала мы создадим новый пример проекта в существующем экземпляре GitLab, содержащий образец приложения Node.js.

изображение: https: //assets.digitalocean.com/articles/gitlab-runner/gitlab.jpg [Интерфейс GitLab]

Войдите в свой экземпляр GitLab и щелкните значок * plus *, затем выберите * New project * в раскрывающемся меню.

На экране нового проекта выберите тег * Import project *, затем нажмите * Repo by URL *, чтобы импортировать наш пример проекта непосредственно из GitHub.

Вставьте следующий URL-адрес клона в URL-адрес хранилища Git:

https://github.com/do-community/hello_hapi.git

Этот репозиторий является базовым приложением JavaScript для демонстрации, которое мы не будем запускать в производство. Чтобы завершить импорт, нажмите кнопку * Новый проект *.

Ваш новый проект теперь будет в GitLab, и мы можем приступить к настройке нашего конвейера CI.

Шаг 2 - Настройка инфраструктуры

Наш GitLab Code Runner требует специальной конфигурации, так как мы планируем программно создавать дроплеты для обработки нагрузки CI по мере ее роста и уменьшения.

В этом учебном пособии мы создадим два типа машин: экземпляр * bastion *, который контролирует и порождает новые машины, и наши экземпляры * runner *, которые являются временными серверами, порождаемыми бастионным Droplet для создания кода при необходимости. Экземпляр бастиона использует Docker для создания ваших бегунов.

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

* Гибкие капли * - Мы создадим оптимизированные для памяти капли для наших бегунов GitLab, поскольку это процесс с интенсивным использованием памяти, который будет выполняться с использованием Docker для контейнеризации. Вы можете уменьшить или увеличить эту каплю в будущем по мере необходимости, однако мы рекомендуем использовать гибкую опцию капли в качестве отправной точки, чтобы понять, как ваш конвейер будет работать под нагрузкой.
* DigitalOcean Spaces (Хранение объектов) * - Мы будем использовать DigitalOcean Spaces для сохранения кэшированных компонентов сборки во всех ваших бегунах по мере их создания и уничтожения. Это сокращает время, необходимое для настройки нового участника, когда конвейер CI занят, и позволяет новым участникам выбирать, где другие немедленно остановились.
* Частная сеть * - мы создадим частную сеть для ваших бегунов Droplet и GitLab, чтобы обеспечить безопасную компиляцию кода и сократить требуемую конфигурацию брандмауэра.

Для начала создадим бастионную каплю. Создайте new Droplet, затем в разделе * выберите изображение * перейдите на вкладку * Приложения одним щелчком *. Оттуда выберите * Docker 16.04 * (обратите внимание, что эта версия актуальна на момент написания), затем выберите наименьший доступный размер капли, поскольку наша бастионная капля будет управлять созданием других капель, а не фактически выполнять тесты.

Рекомендуется создать свой сервер в центре обработки данных, который включает в себя DigitalOcean Spaces, чтобы использовать функции кэширования хранилища объектов. упомянутый ранее.

Выберите параметры * Частная сеть * и * Мониторинг *, затем нажмите * Создать каплю *.

Нам также необходимо настроить пространство для хранения, которое будет использоваться для кэширования. Выполните шаги, описанные в «https://www.digitalocean.com/community/tutorials/how-to-create-a-digitalocean-space-and-api-key[How To Создать пространство DigitalOcean и ключ API]», чтобы создать новое пространство в том же или ближайшем центре обработки данных, что и размещенный вами экземпляр GitLab, вместе с ключом API.

Запишите этот ключ, так как он понадобится нам позже в руководстве.

Теперь пришло время начать наш CI!

Шаг 3 - Сконфигурируйте бастионный сервер GitLab Runner

Теперь, когда готов новый Droplet, мы можем настроить GitLab Runner. Мы будем устанавливать скрипты из репозиториев GitLab и GitHub.

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

Подключитесь к Droplet с помощью SSH, перейдите в каталог + / tmp +, затем добавьте official[itficial GitLab Runner репозиторий в менеджер пакетов Ubuntu:

cd /tmp
curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh | sudo bash

После добавления установите приложение GitLab Runner:

sudo apt-get install gitlab-runner

Нам также нужно установить * https: //docs.docker.com/machine/install-machine/#install-machine-directly [Docker Machine] *, который является дополнительным инструментом Docker, который помогает автоматизировать развертывание контейнеров в облаке провайдеры:

curl -L https://github.com/docker/machine/releases/download/v0.14.0/docker-machine-`uname -s`-`uname -m` >/tmp/docker-machine && \
sudo install /tmp/docker-machine /usr/local/bin/docker-machine

После завершения этих установок мы можем перейти к подключению нашего GitLab Runner к нашей установке GitLab.

Шаг 4 - Получить токен регистрации бегуна

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

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

В левой части экрана наведите курсор мыши на * Overview * и выберите в списке появившихся * Runners *.

На странице «Runners» в разделе «* Как настроить совместно используемого Runner для нового проекта» * скопируйте токен, показанный на шаге 3, и запишите его вместе с общедоступным URL-адресом вашего экземпляра GitLab из шага 2. Если вы используете HTTPS для Gitlab, убедитесь, что это не самозаверяющий сертификат, иначе GitLab Runner не запустится.

Шаг 5 - Сконфигурируйте GitLab на капле бастиона

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

sudo gitlab-runner register

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

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

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

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

Please enter the gitlab-ci token for this runner

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

Please enter the gitlab-ci description for this runner

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

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

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

Whether to run untagged jobs [true/false]:

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

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

Выберите исполнителя, который будет строить ваши машины. Поскольку мы будем создавать новые капли с помощью Docker, мы выберем + docker + machine + здесь, но вы можете узнать больше о преимуществах каждого подхода в этом https://docs.gitlab.com/runner/executors/ README.html # compatibility-chart [совместимость диаграммы]:

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

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

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

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

Если у вас возникнут какие-либо проблемы с этими шагами, GitLab Runner документация содержит варианты для устранения неполадок.

Шаг 6. Настройте Docker Caching и Docker Machine

Чтобы ускорить создание Droplet, когда очередь сборки занята, мы будем использовать инструменты кэширования Docker на Bastion Droplet, чтобы хранить изображения для ваших обычно используемых контейнеров в DigitalOcean Spaces.

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

curl -L https://github.com/docker/machine/releases/download/v0.14.0/docker-machine-`uname -s`-`uname -m` >/tmp/docker-machine && sudo install /tmp/docker-machine /usr/local/bin/docker-machine

Обновив Docker Machine, мы можем перейти к настройке наших токенов доступа для использования GitLab Runner.

Шаг 7 - Сбор учетных данных DigitalOcean

Теперь нам нужно создать учетные данные, которые GitLab Runner будет использовать для создания новых капель с использованием вашей учетной записи DigitalOcean.

Посетите ваш DigitalOcean https://cloud.digitalocean.com [панель инструментов] и нажмите * API *. На следующем экране найдите * Персональные токены * и нажмите * Создать новый токен *.

Дайте новому токену имя, которое вы узнаете, например + GitLab Runner Access +, и убедитесь, что включены области чтения и записи, так как нам нужен Droplet для создания новых машин без участия человека.

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

Шаг 8 - Редактирование файлов конфигурации GitLab Runner

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

При подключении SSH к бастионному Droplet используйте ваш любимый текстовый редактор, например, nano, чтобы открыть файл конфигурации GitLab Runner для редактирования:

nano /etc/gitlab-runner/config.toml

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

/etc/gitlab-runner/config.toml

concurrent = 50   # All registered Runners can run up to 50 concurrent builds

[[runners]]
 url = ""
 token = ""             # Note this is different from the registration token used by `gitlab-runner register`
 name = "example-runner"
 executor = "docker+machine"        # This Runner is using the 'docker+machine' executor
 limit = 10                         # This Runner can execute up to 10 builds (created machines)
 [runners.docker]
   image = "alpine:latest"               # Our secure image
 [runners.machine]
   IdleCount = 1                    # The amount of idle machines we require for CI if build queue is empty
   IdleTime = 600                   # Each machine can be idle for up to 600 seconds, then destroyed
   MachineName = "gitlab-runner-autoscale-%s"    # Each machine will have a unique name ('%s' is required and generates a random number)
   MachineDriver = "digitalocean"   # Docker Machine is using the 'digitalocean' driver
   MachineOptions = [
       "digitalocean-image=coreos-stable", # The DigitalOcean system image to use by default
       "digitalocean-ssh-user=core", # The default SSH user
       "digitalocean-access-token=", # Access token from Step 7
       "digitalocean-region=", # The data center to spawn runners in
       "digitalocean-size=", # The size (and price category) of your spawned runners
       "digitalocean-private-networking" # Enable private networking on runners
   ]
 [runners.cache]
   Type = "s3"   # The Runner is using a distributed cache with the S3-compatible Spaces service
   ServerAddress = ".spaces.digitaloceanspaces.com"
   AccessKey = ""
   SecretKey = ""
   BucketName = ""
   Insecure = true # We do not have a SSL certificate, as we are only running locally

После добавления новых линий настройте токен доступа, регион и размер капли в соответствии с вашими настройками. Для целей данного руководства мы использовали наименьший размер капли в 1 ГБ и создали наши капли в NYC3. Обязательно используйте информацию, которая имеет отношение к вашему делу.

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

После завершения перезапустите GitLab Runner, чтобы убедиться, что конфигурация используется:

gitlab-runner restart

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

Шаг 9 - Проверьте свой GitLab Runner

На этом этапе наша бастионная капля GitLab Runner сконфигурирована и может создавать капли DigitalOcean по требованию, так как очередь CI заполняется. Нам нужно протестировать его, чтобы убедиться, что он работает, перейдя к вашему экземпляру GitLab и проекту, который мы импортировали на шаге 1.

Чтобы запустить сборку, отредактируйте файл + readme.md, щелкнув по нему, затем щелкнув * edit *, и добавьте в него любой соответствующий текст тестирования, затем нажмите * Commit Changes *.

Теперь автоматически запускается сборка, которую можно найти в опции проекта * CI / CD * на левой панели навигации.

На этой странице вы должны увидеть запись конвейера со статусом * running *. В вашей учетной записи DigitalOcean вы увидите несколько капель, автоматически созданных GitLab Runner для создания этого изменения.

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

Поиск проблемы

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

gitlab-runner stop
gitlab-runner --debug start

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

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

docker-machine rm $(docker-machine ls -q)

Дополнительные шаги по устранению неполадок и дополнительные параметры конфигурации вы можете найти в документации GitLab.

Заключение

Вы успешно настроили автоматический конвейер CI / CD с помощью GitLab Runner и Docker. Отсюда вы можете настроить более высокие уровни кэширования с помощью Docker Registry, чтобы оптимизировать производительность или изучить использование тегов сборок кода для конкретных исполнителей кода GitLab.

Чтобы узнать больше о GitLab Runner, see подробную документацию или узнать больше, вы можете прочитать GitLab’s series из постов в блоге о том, как максимально использовать ваш непрерывный интеграционный конвейер.

Этот пост также появляется в GitLab Blog .

TOC