Почему пайплайны в GitLab стали выполняться по часу и как мы это исправили

Уже полгода мы работаем над сервисом денежных переводов для нашего клиента.

В процессе работы мы столкнулась с критическим замедлением CI/CD-процессов при работе с GitLab-сервером: загрузка Docker-образов и артефактов в Docker Registry происходила со скоростью всего несколько килобайт в секунду. Это приводило к значительному увеличению времени выполнения пайплайнов и затягивало поставку обновлений на серверы.

При этом ресурсы VPS (процессор, память, сеть) не были перегружены. Причина явно была не в мощности инфраструктуры.

Быстрая и надежная сборка это основа современного CI/CD. Когда пайплайн "зависает" из-за сетевых ограничений, команда не может оперативно выпускать обновления, тестировать новые фичи и выкатывать фиксы. Для продукта с активным релизным циклом это превращается в серьезный тормоз..

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

Команда несколько раз шаг за шагом отслеживала цепочку CI/CD, пока не выявила "узкое место": передачу образов в GitLab Registry, расположенный в США. Доступ к ресурсам в США из России и наоборот ограничен в связи с действующими санкциями и контролем межгосударственного трафика.

Сами серверы (dev и staging) находятся в РФ и работают в офисной сети за NAT. Образы создаются локально и отправляются в GitLab Registry и именно на этом этапе процесс зависает из-за ограниченной пропускной способности канала.

1. Настройка VPN/WireGuard через Европу

— Попробовать направить трафик на GitLab через европейские узлы.

— Потенциально снимает ограничения, но требует дополнительной настройки маршрутов и проверки стабильности соединения.

2. Перенос staging-сервера в Европу

— Развернуть staging за пределами РФ, чтобы избежать блокировок при соединении с США.

— Рабочее решение, но требует 3–4 часа на настройку новых серверов и дополнительное время на развёртывание проектов.

— Важно, чтобы серверы не проходили через Cloudflare, иначе не получится корректно подключаться из CI/CD.

3. Отказ от записи образов в Registry

— Временно отключить шаг docker push в CI/CD.

— Перейти на сборку образов из исходного кода, как это было раньше.

— Добавить только запуск тестов для dev-среды.

— Позволяет продолжить работу без сетевых блокировок, но требует ручного контроля сборок.

Принятое решение

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

Чтобы не блокировать разработку, временно был выбран третий вариант: отключена загрузка образов в Docker Registry (docker push закомментирован в CI/CD).

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