Сколько ресурсов нужно VPS для разработчика и CI/CD

MAATRIX

Слабый сервер под CI/CD растягивает сборки и выстраивает задачи в очередь, а избыточный — это деньги на ветер. Правильная конфигурация VPS для разработчика и CI/CD зависит от тяжести сборок, числа параллельных пайплайнов и того, живёт ли рядом стейджинг. Разберём по полочкам, сколько нужно ядер, памяти и диска, почему для сборок критичен быстрый накопитель и где граница между «хватает» и «пора добавить».

От чего пляшет расчёт

В отличие от многих задач, сервер под разработку нагружается неравномерно и по нескольким осям сразу. Сборки упираются в процессор и диск, тесты — в процессор и память, стейджинг-приложение держит память постоянно, а установка зависимостей интенсивно молотит диск и сеть. Поэтому единой цифры «сколько нужно» не существует — конфигурацию считают под конкретный профиль нагрузки.

Три главных фактора определяют требования. Первый — тяжесть самой сборки: линтинг маленького сервиса и компиляция крупного фронтенда отличаются в разы. Второй — параллелизм: сколько пайплайнов идёт одновременно, ведь каждый забирает ресурсы. Третий — соседи по серверу: если рядом стейджинг и база тестов, им тоже нужна своя доля. Разложив свою работу по этим трём осям, вы точно поймёте, что и в каком объёме заказывать.

Стоит сразу отбросить и обратную крайность — соблазн взять минимальный тариф ради экономии. Сервер, на котором сборки постоянно упираются в потолок, обходится дороже мнимой экономии: разработчики ждут результата, очередь пайплайнов растёт, а падающие по памяти сборки приходится перезапускать. Ресурсы под CI/CD — это вложение во время команды, и оно окупается быстрее, чем кажется. Поэтому расчёт ведут не от «как подешевле», а от реального профиля нагрузки, о котором и пойдёт речь ниже по каждому ресурсу отдельно.

Процессор: ядра под сборки и тесты

Сборка и тесты — процессороёмкие операции, и здесь ядра работают. Для линтинга и тестов небольшого бэкенда достаточно 2 ядер. Компиляция, сборка фронтенда с бандлингом, прогон большого набора тестов выигрывают от 4 ядер и более, потому что многие сборочные инструменты распараллеливают работу и реально используют несколько ядер.

Ключевой множитель — параллелизм пайплайнов. Если раннер настроен выполнять несколько сборок одновременно или у вас команда, пушащая часто, задачи конкурируют за процессор. Ориентир: закладывайте ядро на каждую параллельную сборку, которую хотите держать без деградации. Признак нехватки процессора очевиден — сборки идут долго, а при одновременных пушах выстраиваются в очередь и ждут. Если это происходит регулярно, добавление ядер напрямую ускоряет конвейер и разгружает очередь.

Память: тесты, стейджинг и компиляция

Память на сервере разработки расходуется сразу на несколько нужд. Сам процесс сборки и особенно компиляция крупных проектов способны потреблять заметный объём, и нехватка памяти приводит к падению сборки с ошибкой нехватки ресурсов — обиднее всего, когда это случается в середине долгого прогона. Тесты, поднимающие приложение и базу, тоже требуют своей доли.

Отдельная статья — стейджинг. Если на том же сервере крутится работающая копия приложения, она держит память постоянно, независимо от сборок. Прибавьте базу данных для тестов — и минимального тарифа перестаёт хватать. Практический ориентир: 4 ГБ достаточно для лёгкого проекта с тестами, но под сборку фронтенда, компиляцию или соседство со стейджингом закладывайте 8 ГБ и выше. Память — тот ресурс, на котором экономия оборачивается падающими сборками, поэтому её берут с запасом.

Диск: скорость решает

Для CI/CD диск часто оказывается недооценённым узким местом. Установка зависимостей создаёт тысячи мелких файлов, сборка пишет и перезаписывает артефакты, Docker разворачивает слои образов — всё это интенсивная работа с диском. На медленном HDD даже мощный процессор простаивает в ожидании операций чтения и записи, и сборка тянется. Поэтому под разработку берут обязательно SSD.

По объёму закладывайте больше, чем кажется на первый взгляд. Сборки оставляют временные файлы, Docker копит образы и слои, кеш зависимостей растёт. Без регулярной очистки диск забивается, и пайплайны встают из-за нехватки места — типичная авария активного раннера. Разумно держать запас по объёму и настроить периодическую очистку неиспользуемых образов. Быстрый и достаточный по объёму диск снимает добрую половину проблем со скоростью и стабильностью конвейера.

Один сервер или несколько

Отдельный вопрос конфигурации — держать все роли на одном VPS или разнести. Для небольшого проекта раннер, стейджинг и база тестов уживаются вместе, и это экономно. Но у совмещения есть цена: тяжёлая сборка забирает ресурсы, и в этот момент стейджинг может тормозить или падать — неприятно, если именно тогда его смотрит заказчик.

Когда сборки становятся частыми и тяжёлыми, роли разносят: отдельный сервер под раннер, отдельный под стейджинг. Так нагрузка изолируется, и сборка не влияет на демонстрационное окружение. Это же повышает надёжность — падение одной роли не тянет за собой остальные. Разносить сразу не обязательно: начните с одного сервера и добавьте второй, когда почувствуете взаимные помехи. У MAATRIX добавить ещё один VPS или нарастить текущий можно в любой момент, оплатив из России удобным способом.

Как выбрать тариф и не переплатить

Сведём в практическую логику. Лёгкий проект с тестами и небольшим стейджингом — 2 ядра, 4 ГБ, SSD. Активная разработка с тяжёлыми сборками, фронтендом и Docker — 4 ядра, 8 ГБ, быстрый и просторный SSD. Много параллельных пайплайнов или команда — добавляйте ядра под параллелизм и память под соседей по серверу. Стейджинг для российской аудитории держите в RU, раннер, тянущий зарубежные пакеты, — ближе к реестрам.

Разумная стратегия — стартовать под текущую нагрузку и расширяться по реальным сигналам: сборки встали в очередь — добавьте ядра; компиляция падает по памяти — добавьте RAM; диск забился — расширьте его и настройте очистку. У MAATRIX конфигурацию меняют без переезда, а оплата идёт картой РФ, по СБП, криптой или токеном MAAT. Так вы платите за используемые ресурсы и наращиваете их тогда, когда конвейер действительно этого требует, а не покупаете мощность впрок.

Частые вопросы