Автоматическое масштабирование непрерывного развертывания GitLab с помощью GitLab Runner
Cloud Server | Комментировать запись
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.
Требования
- Настроенный GitLab на вашем сервере.
- Сервер Ubuntu 16.04 (читайте Установка и настройка GitLab в Ubuntu 16.04).
- Включенная частная сеть (читайте мануал Как включить частную сеть на рабочем сервере?).
Все задачи мануала можно выполнить с помощью не-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: CI/CD, Docker, Docker Machine, GitLab, GitLab CI, GitLab Runner