Об опыте перехода с on-premises на облачные Gitlab runners

*Все технические решения описаны в обезличенном виде и адаптированы под публичное изложение. Проект находится под НДА, поэтому часть информации и детали реализации были изменены или обобщены.

Изначальный расчет был на то, что данное решение позволит существенно сократить обслуживание «железной» инфраструктуры. А вместе с ним 一 и расходы на IT-отдел в принципе. Дополнительно планировались привести в порядок текущий парк, который в тот момент насчитывал большое количество неуправляемых раннеров. Часть из них была просто забыта и заброшена, другая часть 一 в один прекрасный момент зависла и так и не пришла в себя. И, разумеется, никому не хотелось с этим разбираться, ведь гораздо проще было просто создать новый раннер. 

Все это выливалось в то, что длительность сборок проектов составляла по несколько часов 一 долго, нудно, тяжело и нерационально. 

Итого, наша мотивация для перехода в облако включала в себя:

• Масштабирование в зависимости от нагрузки;

• Значительное сокращение времени сборки;

• Возможность оперативной адаптации под новый проект или задачу. 

Сравним текущее решение on-premises с облаком

On-premises не увеличивает ресурсы по щелчку пальцев: приходится поднимать виртуалочку, ставить туда раннер и регистрировать его в Gitlab. И только после этого танца с бубнами им можно наконец-то пользоваться. Другое дело облако, в котором все происходит автоматически, по запросу от Gitlab-менеджера.

Наш выбор и ход действий

В итоге пал на одного из крупных российских облачных провайдеров с его autoscale-группами. Немного поговорим и об его инфраструктуре и подготовке. 

Нами была создана сегментированная сеть с ограничением исходящего трафика, чтобы у раннеров не было прямого доступа в Сеть. Также был подготовлен образ Gitlab-менеджера(по совместительству и linux раннера) с заранее установленным плагином для беспроблемной интеграции с Облаком, а также образ Windows-раннера, настроенный средствами автоматизации конфигурации.

И вот у нас на руках, казалось бы, готовое решение. Но нет. Все оказалось не так просто.

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

Анализ этой ситуации показал, что так происходит из-за того, что в конфигурации Gitlab-runner было описано сразу 2 группы раннеров: Windows и Linux. По какой-то причине автоскеллер сначала инициировал масштабирование Linux-виртуальных машин, после чего пытался их удалить, но терялся и начинал всю эту бессмысленную процедуру по новой. Итог был один: постоянная попытка заскейлиться в ту или иную сторону без какой-либо практической пользы. 

Мы решили это разделением 2-х групп раннеров используя 2 сервиса: отдельно зарегистрировали сервис для Windows и сервис для Linux.

concurrent = 10 check_interval = 0 connection_max_age = "15m0s" shutdown_timeout = 0   ######### # Linux runner group ######### [[runners]]   name = "gitlab-runner-linux-autoscaler"   url = "${url}"   id = ${id_linux}   token = "${token_linux}"   executor = "docker-autoscaler"   output_limit = 20480 # 20MB     [runners.feature_flags]     FF_USE_FLEETING_ACQUIRE_HEARTBEATS = true     [runners.cache]     Type = "s3"     Path = "/"     Shared = true     [runners.cache.s3]       ServerAddress = "storage.yandexcloud.net"       AccessKey = "${s3_bucket_ak}"       SecretKey = "${s3_bucket_sk}"       BucketName = "${s3_bucket_runner_cache}"       BucketLocation = "ru-central1"       Insecure = false     [runners.docker]     pull_policy = "if-not-present"     tls_verify = false     image = "alpine:latest"     privileged = true     disable_entrypoint_overwrite = false     oom_kill_disable = false     disable_cache = true # use s3 cache for runners     volumes = ["/cache","/var/run/docker.sock:/var/run/docker.sock"]     shm_size = 0     network_mtu = 0   # https://docs.gitlab.com/runner/configuration/advanced-configuration.html#the-runnersautoscaler-section   [runners.autoscaler]     plugin = "fleeting-plugin-yc"     capacity_per_instance = 2     max_use_count = 100     max_instances = 5     instance_ready_command = "sudo cloud-init status --wait"     [runners.autoscaler.state_storage]     enabled = true     [runners.autoscaler.plugin_config]     name        = "gitlab-linux-runners"     folder_id   = "${folder_id}"     config_file = "/etc/gitlab-runner/template_linux.yml"     [runners.autoscaler.connector_config]     username = "ubuntu"   # https://docs.gitlab.com/runner/configuration/advanced-configuration.html#the-runnersautoscalerpolicy-sections   [[runners.autoscaler.policy]]     idle_count = 1     idle_time  = "15m0s"     # periods    = ["* * * * sat-sun"]    concurrent = 10 check_interval = 0 connection_max_age = "15m0s" shutdown_timeout = 0   ######### # Windows runner group ######### [[runners]]   name = "gitlab-runner-windows-autoscaler"   url = "${url}"   id = ${id_windows}   token = "${token_windows}"   executor = "docker-autoscaler"   output_limit = 20480 # 20MB   builds_dir = "C:/builds"     [runners.feature_flags]     FF_USE_FLEETING_ACQUIRE_HEARTBEATS = true     FF_USE_POWERSHELL_PATH_RESOLVER = true     [runners.cache]     Type = "s3"     Path = "/"     Shared = true     [runners.cache.s3]       ServerAddress = "storage.yandexcloud.net"       AccessKey = "${s3_bucket_ak}"       SecretKey = "${s3_bucket_sk}"       BucketName = "${s3_bucket_runner_cache}"       BucketLocation = "ru-central1"       Insecure = false     [runners.docker]     pull_policy = "if-not-present"     tls_verify = false     image = "windows/servercore:ltsc2019"     # privileged = true     disable_entrypoint_overwrite = false     oom_kill_disable = false     disable_cache = false     volumes = ["//./pipe/docker_engine://./pipe/docker_engine"]     shm_size = 0     network_mtu = 0   # https://docs.gitlab.com/runner/configuration/advanced-configuration.html#the-runnersautoscaler-section   [runners.autoscaler]     plugin = "fleeting-plugin-yc"     capacity_per_instance = 2     max_use_count = 100     max_instances = 5     [runners.autoscaler.state_storage]     enabled = true     [runners.autoscaler.plugin_config]     name        = "gitlab-windows-runners"     folder_id   = "${folder_id}"     config_file = "/etc/gitlab-runner/template_windows.yml"     [runners.autoscaler.connector_config]     os          = "windows"     protocol    = "ssh"     username    = "Administrator"   # https://docs.gitlab.com/runner/configuration/advanced-configuration.html#the-runnersautoscalerpolicy-sections   [[runners.autoscaler.policy]]     idle_count = 1     idle_time  = "15m0s"     # periods    = ["* * * * sat-sun"]

И это сработало! Бонусом это внесло удобство и для администрирования: стало возможно спокойно зайти, перезагрузить нужную группу раннеров, не трогая вторую. 

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

Решено было переносить артефакты в объектное хранилище совместимое с S3 API, чтобы сократить скорость скачивания и скорость загрузки. В совокупности бы это позволило прокачать скорость сборки.

gitlab_rails['object_store']['enabled'] = true gitlab_rails['object_store']['proxy_download'] = false gitlab_rails['object_store']['connection'] = {   'provider' => 'AWS',   'endpoint' => '{{ gitlab_s3_endpoint }}',   'path_style' => true,   'region' => '{{ gitlab_s3_region }}',   'aws_access_key_id' => '{{ gitlab_s3_access_key }}',   'aws_secret_access_key' => '{{ gitlab_s3_secret_key }}' } gitlab_rails['object_store']['objects']['lfs']['enabled'] = false gitlab_rails['object_store']['objects']['artifacts']['bucket'] = '{{ gitlab_artifacts_s3_bucket }}' gitlab_rails['object_store']['objects']['packages']['bucket'] = '{{ gitlab_packages_s3_bucket }}'

Но и на этом не все. При сборке на Windows-раннерах были специфические окружения, например, тот же SDK. Все это приходилось пересобирать на Docker-контейнерах. 

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

Про интеграцию в пайплайны

Новые проекты собирались в Docker, поэтому было удобно и не запарно просто поменять тэг раннера и на этом успокоиться. Но были и специфические проекты 一 пусть и устаревшие, но из той категории, которые могут в любой момент пересобраться.

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

Промежуточные результаты

Чем мы можем похвастаться на данный момент?

• Часть команд перешла на использование облаков и отзываются о наших раннерах более, чем положительно: удобно, понятно и просто.

• Часть же команды пока пребывает на старых раннерах. Тут все завязано на специфике проектов. За один подход это не решишь.

• Нет полной картинки и возможности ее получить из-за регулярных изменений конфигурации автоскеллера, которые то увеличивают, то уменьшают инстанс — мы еще в поисках оптимальных значений для себя

Но уже сейчас можно сказать, что и нагрузка на IT-отдел, и затраты на обслуживание «железа» поползли вниз, что не могло не понравится руководству компании.