Автоматическое масштабирование непрерывного развертывания GitLab с помощью GitLab Runner

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

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

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

Цели

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

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

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

Для создания этого проекта мы будем использовать три отдельных сервера. Сначала ознакомьтесь с терминами:

  • GitLab – ваш экземпляр GitLab, где хранятся репозитории кода.
  • GitLab Bastion – ядро этой инфраструктуры. Этот экземпляр позволяет взаимодействовать с API вашего хостинг-провайдера для создания необходимых серверов. Он не должен обрабатывать другие задачи.
  • GitLab Runners – это временные серверы, которые создаются bastion-сервером для обработки задач CI/CD вашей очереди сборки. Эти серверы являются одноразовыми, на них выполняется или тестируется код до сборки.

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

Требования

Все задачи мануала можно выполнить с помощью не-root пользователя с привилегиями администратора.

1: Импортирование проекта JavaScript

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

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

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

Вставьте указанный ниже URL-адрес в Git repository URL:

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

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

Теперь у вас есть новый проект GitLab, и можно приступить к настройке CI-конвейера.

2: Настройка инфраструктуры

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

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

Для начала создайте bastion-сервер. Создайте новый сервер Ubuntu 16.04 наименьшего размера (bastion-сервер не будет выполнять задачи тестирования, а только создавать новые серверы).

Рекомендуем вам использовать хранилища объектов для кэширования данных.

Включите на новом сервере частную сеть и мониторинг.

После этого вам нужно настроить хранилище объектов для кэширования. Запишите его API Key, он понадобится позже.

3: Настройка GitLab Runner

Теперь можно настроить GitLab Runner. усатновите скрипты из репозиториев GitLab и GitHub.

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

Подключитесь к серверу по SSH, перейдите в каталог /tmp, затем добавьте официальный репозиторий 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

Также вам нужно установить 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 Runner с существующей установкой GitLab, нужно подключить два экземпляра, получив токен, который авторизует GitLab Runner в репозиториях кода.

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

Слева выберите Overview и Runners.

На странице Runners в разделе How to setup a shared Runner for a new project скопируйте токен и запишите его вместе с общедоступным URL вашего экземпляра GitLab (раздел 2). Если вы используете HTTPS, убедитесь, что сертификат не является самоподписанным, иначе GitLab Runner не запустится.

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

[yourhostname] runner-bastion

Если это необходимо, вы можете ввести теги кода, который вы будете собирать с помощью 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.

6: Настройка кэширования и Docker Machine

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

Для этого обновите 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

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

7: Добавление учетных данных

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

Откройте панель управления хостингом и выберите настройки API. Здесь вы должны сгенерировать новый токен.

Выберите описательное имя для нового токена, например, GitLab Runner Access. Убедитесь, что права на чтение и запись включены.

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

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

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

На bastion-сервере откройте конфигурационный файл GitLab Runner:

nano /etc/gitlab-runner/config.toml

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

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

[[runners]]

url = «https://example.com»

token = «existinggitlabtoken»             # 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 = «your-driver»

MachineOptions = [

«image=coreos-stable», # The system image to use by default

«ssh-user=core», # The default SSH user

«access-token=ACCESS_TOKEN», # Access token from Step 7

«region=nyc3», # The data center to spawn runners in

«size=1gb», # The size (and price category) of your spawned runners

«private-networking» # Enable private networking on runners

]

[runners.cache]

Type = «s3»   # The Runner is using a distributed cache with the S3-compatible service

ServerAddress = «nyc3.your-object-storage.com»

AccessKey = «YOUR_STORAGE_KEY»

SecretKey = «YOUR_ STORAGE_SECRET»

BucketName = «your_bucket_name»

Insecure = true # We do not have a SSL certificate, as we are only running locally

После того, как вы добавите новые строки, укажите свои данные: токен доступа, регион и размер серверов и т.д.

Вам также необходимо настроить кэш и ввести адрес сервера хранилища объектов, access key, secret key и имя вашего хранилища.

Перезапустите GitLab Runner:

gitlab-runner restart

Узнать больше о доступных опциях можно в документации GitLab.

9: Тестирование GitLab Runner

Теперь bastion-сервер настроен и может создавать серверы по мере необходимости. Давайте протестируем его работу.

Чтобы запустить сборку, отредактируйте файл readme.md. Добавьте в файл какой-нибудь текст, затем нажмите Commit changes.

Теперь сборка будет инициирована автоматически.

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

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

Устранение неполадок

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

gitlab-runner stop

gitlab-runner —debug start

Результат должен выдать ошибку, которая поможет определить причину проблемы.

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

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

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

Заключение

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

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

Tags: , , , , ,