Чем плох docker-machine?
И снова здравствуйте! В этой статье я хочу продолжить вопрос динамических gitlab-раннеров, которые запускаются в Yandex Cloud. В прошлой статье мы рассмотрели старый подход, основанный на docker-machine.
Естественным будет вопрос: «Чем плох docker-machine?» И тут такой же простой ответ: «Ничем, он хорош». Но хорош он ровно до момента его промышленного использования.
И тут появляется масса неприятных и неочевидных проблем:
- Повисшие/не созданные виртуальные машины. Это, пожалуй, главная беда. При создании autoscale-раннеров через docker-machine может случится так, что ВМ не будет создана, а вот запись о ней — будет. А, поскольку, мы можем создавать их десятками, легко получиться ситуация, когда менеджмент-машина просто подвисает из-за огромного количества умерших раннеров. Лечится такое ручной чисткой, которая влечет за собой простой и гнев разработчиков. 
- Нет полноценного управления состоянием. После перезагрузки менеджмент-машины может потерять свой стейт, значит, все созданные до этого ВМ останутся неучтенными и будут выедать бюджет, пока вы руками не удалите их. 
- Мы можем работать только в докере, что в некоторых случаях неудобно. 
- Доступны только linux-раннеры. 
Проблемы не такие страшные. Ну, подумаешь, пару раз в неделю зайти, почистить мертвые раннеры или удалить уже неактуальные. Однако, это очень сильно влияет на непрерывность процессов и может целиком остановить CI. А это уже большая проблема.
Что за fleet plugin?
В 2022 году Gitlab опубликовал blueprints, в котором расписал те же проблемы динамических раннеров на docker-machine и объявил о начале работы над новым поколением autoscale-раннеров. И вот совсем недавно появилась экспериментальная возможность начать их использовать.
Для начала давайте поймем, в чем же отличия.
Во-первых, новый подход реализован через плагины, то есть можно самостоятельно написать плагин, который позволит использовать ресурсы в любом облаке.
Во-вторых, плагины предоставляют абстракцию. Gitlab просто передает команду увеличить/уменьшить количество раннеров, а как это будет реализовано уже зависит от разработчика плагина. Вместе с тем, новый taskmanager имеет актуальные данные о доступных раннерах, что исключает ошибки которые встречаются в docker-machine.
Если резюмировать, то fleet plugin — это абстракция для реализации, создания, подключения и/или удаления ВМ в любом провайдере. При этом всегда используются instance group, что позволяет полностью отдать заботу о создании и жизненном цикле ВМ на откуп облачному провайдеру.
Как пользоваться новыми autoscale-runners?
Мы подошли к самому интересному: к использованию плагина на практике.
Плагин для Yandex Cloud опубликован в публичном репозитории. Сейчас он имеет минимальный, но достаточный функционал.
Переходим к настройке.
- 
Нужно клонировать репозиторий к себе и собрать бинарный файл командой env GOOS=linux GOARCH=amd64 go build -o fleeting-plugin-yc ./cmd/fleeting-plugin-yc
- Создаем сервисный аккаунт с правами admin 
- Поднимаем в ЯО виртуальную машину для управлениями динамическими раннерами. Ресурсов ей много не нужно, можно обойтись 2 vCPU и 4 RAM. И не забываем навесить на эту машину сервисный аккаунт, который мы создали выше. 
- Подготавливаем базовый образ. В нем должны быть установлены git, gitlab-runner, docker, а также все утилиты необходимые во время CI/CD 
- Копируем бинарный файл по пути - /usr/local/bin/fleeting-plugin-yc
- Устанавливаем и регистрируем gitlab-runner 
- Обновляем конфигурационный файл 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"- Настраиваем темплейт (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- При необходимости добавляем закрытый ssh-ключ, чтобы была возможность ходить на динамически созданные виртуальные машины. Если не указывать, ключи будут генерироваться автоматически. 
- Перезапускаем gitlab-runner и наблюдаем за созданием новых ВМ в Yandex Cloud 
И все?
Да. После 10 шагов вы получаете рабочую систему autoscale-раннеров, которая будет автоматически создавать и удалять ВМ в зависимости от потребности.
В конце хочется еще раз отметить, что на данный момент fleeting plugin находится на этапе эксперимента, и Gitlab не рекомендует использовать этот подход в продакшене. Со своей стороны тоже хотел бы предостеречь от использования этого подхода в проде, поскольку написанный плагин еще не прошел нормальную обкатку и может содержать ошибки. В sports.ru мы только начинаем путь по переходу на новые раннеры и по возможности будем делиться своим опытом.
С удовольствием выслушаю критику и советы. И, конечно, жду, что кто-то присоединится к разработке плагина.
 
          