Запускаем новые GitLab Auto-scaling раннеры в Yandex Cloud

Чем плох docker-machine?

И снова здравствуйте! В этой статье я хочу продолжить вопрос динамических gitlab-раннеров, которые запускаются в Яндекс Облаке. В прошлой статье мы рассмотрели старый подход, основанный на docker-machine. 

Естественным будет вопрос: «Чем плох docker-machine?» И тут такой же простой ответ: «Ничем, он хорош». Но  хорош он ровно до момента его промышленного использования.

И тут появляется масса неприятных и неочевидных проблем:

1. Повисшие/не созданные виртуальные машины. Это, пожалуй, главная беда. При создании autoscale-раннеров через docker-machine может случится так, что ВМ не будет создана, а вот запись о ней — будет. А, поскольку, мы можем создавать их десятками, легко получиться ситуация, когда менеджмент-машина просто подвисает из-за огромного количества умерших раннеров. Лечится такое ручной чисткой, которая влечет за собой простой и гнев разработчиков. 

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

3. Мы можем работать только в докере, что в некоторых случаях неудобно.

4. Доступны только linux-раннеры. 

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

Что за fleet plugin?

В 2022 году Gitlab опубликовал blueprints, в котором расписал те же проблемы динамических раннеров на docker-machine и объявил о начале работы над новым поколением autoscale-раннеров. И вот совсем недавно появилась экспериментальная возможность начать их использовать. 

Для начала давайте поймем, в чем же отличия. 

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

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

Если резюмировать, то fleet plugin — это абстракция для реализации, создания, подключения и/или удаления ВМ в любом провайдере. При этом всегда используются instance group, что позволяет полностью отдать заботу о создании и жизненном цикле ВМ на откуп облачному провайдеру. 

Как пользоваться новыми autoscale-runners?

Мы подошли к самому интересному: к использованию плагина на практике. 

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

Переходим к настройке.

1. Нужно клонировать репозиторий к себе и собрать бинарный файл командой

   env GOOS=linux GOARCH=amd64 go build -o fleeting-plugin-yc ./cmd/fleeting-plugin-yc  

2. Создаем сервисный аккаунт с правами admin 

3. Поднимаем в ЯО виртуальную машину для управлениями динамическими раннерами. Ресурсов ей много не нужно, можно обойтись 2 vCPU и 4 RAM. И не забываем навесить на эту машину сервисный аккаунт, который мы создали выше.

4. Подготавливаем базовый образ. В нем должны быть установлены git, gitlab-runner, docker, а также все утилиты необходимые во время CI/CD

5. Копируем бинарный файл по пути /usr/local/bin/fleeting-plugin-yc

6. Устанавливаем и регистрируем gitlab-runner

7. Обновляем конфигурационный файл gitlab-runner, добавляя нужные поля. В конце должно получится следующее:

[runners.autoscaler] 
plugin = "fleeting-plugin-yc"
capacity_per_instance = 1
max_use_count = 1
max_instances = 10

[runners.autoscaler.plugin_config]
  name             = "gitlab-autoscale-runners" 
  folder_id        = ""
  config_file      = "/etc/gitlab-runner/template.yml"
  ssh_file         = "/etc/gitlab-runner/id_rsa"

[runners.autoscaler.connector_config]
  username          = "ubuntu"

[[runners.autoscaler.policy]]
  idle_count = 5
  idle_time = "20m0s"

8. Настраиваем темплейт (template.yml) для динамических раннеров и помещаем его по ранее указанному пути

platform: "standard-v3" 
zone: "ru-central1-a" 
preemptible: true 
serviceAccount: ""

resources: 
  cpu: 2 
  memory: 2147483648 
  fraction: 100

disk: 
  type: "network-ssd" 
  size: 17179869184 
  image: ""

network: 
  network: "" 
  subnet: "" 
  nat: false

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

10. Перезапускаем gitlab-runner и наблюдаем за созданием новых ВМ в Яндекс Облаке

И все?

Да. После 10 шагов вы получаете рабочую систему autoscale-раннеров, которая будет автоматически создавать и удалять ВМ в зависимости от потребности. 

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

С удовольствием выслушаю критику и советы. И, конечно, жду, что кто-то присоединится к разработке плагина.