Все статьи
simple-container infrastructure platform-engineering 4 мин чтения

Драйвер облака не должен компилироваться внутрь инструмента деплоя

Облачные драйверы Simple Container теперь живут в собственных репозиториях, выходят по собственному расписанию и разрешаются в момент деплоя, а не компилируются при сборке. Рассказываем, что даёт эта граница — и почему понадобился 920-мегабайтный бинарник, чтобы этот аргумент стал убедительным.

автор Vitaly Nikitin

Есть класс инструментов, которые набирают вес пропорционально числу поддерживаемых облаков. Каждый новый провайдер — новые зависимости, новые версии SDK, новые единицы компиляции. Бинарник растёт. Шаг линковки разбухает. Скорость выхода релизов всего инструмента оказывается в заложниках у скорости выхода каждого из облачных SDK внутри него.

Simple Container прошёл через эту точку. Монолитная сборка весила 920 МБ, а Go-линковщик в пике потреблял 12,9 ГБ памяти. Это не сноска — это аргумент в пользу другой архитектуры.

Эта архитектура вышла на прошлой неделе.

Граница, которая делает плагины возможными

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

Механика: когда sc нужен облачный драйвер, он находит нужный релиз на GitHub, проверяет контрольную сумму sha256 и запускает бинарник. Драйвер открывает шину gRPC через локальный сокет; sc обращается к нему так же, как обращался бы к встроенному драйверу. Файл состояния, движок Pulumi, граф ресурсов — всё это по-прежнему общее, через тот же интерфейс. С точки зрения вашего стека — ничего не изменилось.

С точки зрения самого драйвера — изменилось почти всё. Теперь у облачного драйвера есть собственный репозиторий, собственные зависимости, собственный тег релиза, собственные контрибьюторы. Добавление поддержки Cloud.ru или обновление Yandex Cloud SDK больше не требует релиза sc. Драйвер выходит, когда готов; sc фиксирует версию, которой доверяет.

Сегодня по этой модели опубликованы три драйвера: sc-plugin-cloudflare , sc-plugin-yandex и sc-plugin-cloudru . Каждый поставляется с бинарниками для нескольких платформ — linux-amd64, linux-arm64, darwin-arm64 — и файлом sha256sums.

Требование обратной совместимости, которое определило дизайн

Разбить инструмент — несложно. Разбить правильно — вот где настоящая работа.

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

Механизм, который это обеспечивает — стабильность URN. Pulumi идентифицирует каждый управляемый ресурс по URN, который строится из типа ресурса, провайдера и логического пути в стеке. Изменение способа загрузки драйвера не должно менять формат URN, который он регистрирует, — иначе diff увидит ресурс до плагина и ресурс после как разные объекты.

Команда подтвердила побайтовую идентичность URN через границу раздела до того, как написала саму шину. Интеграционный тест для каждого драйвера прогоняет существующий стек целиком и утверждает отсутствие неожиданных изменений в плане. Этот тест является условием выпуска.

Что даёт граница расширения на практике

Этот аргумент применим шире, чем только к Simple Container.

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

Граница плагина инвертирует большинство из этого. Драйвер выходит тогда, когда его мейнтейнеры готовы. Обновление безопасности в Yandex Cloud SDK не требует релиза sc — репозиторий sc-plugin-yandex делает собственный релиз. Пользователь, работающий только с Cloudflare, не тянет драйвер Cloud.ru в свой процесс. Граница доверия явная: sc проверяет бинарник драйвера перед запуском, а не доверяет тому, что было скомпилировано при сборке.

Индустрия в целом движется в ту же сторону. Запуск Respan на Hacker News на прошлой неделе — AI-шлюз, целиком построенный вокруг плагинной модели, — собрал в комментариях обсуждение ровно того же вопроса: что должно быть в ядре, а что — расширением. Одна из формулировок там была особенно точной: «Обычно, когда в индустрии говорят „плагин“, имеется в виду, что запускать компилятор не нужно». Именно это ожидание плагинная модель sc теперь и выполняет.

Текущее состояние

Шина плагинов есть в выпущенном бинарнике sc — релиз v2026.10.30 поставляется с cosign-бандлом, SLSA in-toto аттестацией и CycloneDX SBOM. Три драйвера опубликованы. Тест на совместимость проходит.

Что ещё не выпущено: уменьшение размера бинарника. После того как встроенные копии Cloudflare и Yandex будут удалены из ядра, размер sc ощутимо сократится. Эта работа ведётся на открытой ветке, не смёрджена. Этот пост — о границе раздела, не о цифре. Цифра придёт, когда придёт.

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

Он выполняется.


Публичный релиз Simple Container размещён в репозитории api . Если вы запускаете sc на существующем стеке и хотите понять, как выглядит обновление до плагинной версии, напишите нам .