Практически все современные системы управления инфраструктурой опираются на один и тот же фундаментальный механизм — сохранённое состояние (persistent state).
Terraform хранит состояние в .tfstate, Crossplane использует Kubernetes API как систему записи, GitOps-решения строят дополнительные слои поверх Kubernetes. Архитектурные различия между этими инструментами огромны, но их объединяет одна идея: между конфигурацией и реальной инфраструктурой существует некоторое долговременное представление мира, которое считается авторитетным.
Исторически это было вполне разумно. Когда Terraform появился, облачные API были значительно медленнее, инфраструктура хуже наблюдалась, а полный обход ресурсов занимал ощутимое время. Поддерживать локальный снимок состояния было выгоднее, чем каждый раз заново опрашивать провайдера.
Проблема в том, что со временем этот снимок превратился из оптимизации в архитектурный фундамент. Вокруг него со временем выросла целая экосистема: удалённые хранилища состояния, механизмы блокировки, импорт ресурсов, синхронизация состояния с инфраструктурой, обнаружение дрейфа конфигурации, миграции состояния и другие инструменты, необходимые для поддержания согласованности между сохранённым представлением системы и её фактическим состоянием.
В какой-то момент возникает вопрос: а обязательно ли вообще ориентироваться на сохранённое состояние как на краеугольный камень архитектуры? Можно ли построить систему, которая будет работать напрямую с реальной инфраструктурой, не поддерживая отдельный долговременный слой состояния?
Эта гипотеза и стала отправной точкой для проекта Wye — системы, которую я начал собирать как эксперимент, чтобы проверить, можно ли полностью отказаться от сохранённого состояния в IaC.
Другая модель
В основе Wye лежит достаточно простая идея. Вместо модели Git → Состояние → Инфраструктура используется модель Git → Инфраструктура где:
Git содержит желаемое состояние;
реальная инфраструктура является источником истины;
состояние существует только как временное представление, которое можно получить заново в любой момент.
Это не означает отсутствие состояния вообще. Системы управления инфраструктурой, не использующей никакого состояния вообще, не существует — чтобы принять решение, системе всё равно необходимо знать, что находится у провайдера прямо сейчас. Разница заключается в другом: наблюдаемое состояние не является авторитетным и не живёт дольше, чем необходимо для работы системы.
В Wye введено строгое разделение на два типа состояния, выраженных в файлах:
Конфигурация (
.cfg.ncl) — описание целевого состояния, хранимое в Git и являющееся единственным источником намерения системы (intent).Наблюдаемое состояние (
.obs.json) — данные, получаемые от провайдера через внешний API. В них фиксируются значения, которые нельзя задать заранее в конфигурации (например, динамически назначенные IP-адреса или сгенерированные ID), но которые необходимы для связывания ресурсов. В отличие от.tfstate, эти файлы не являются источником истины: они игнорируются Git, могут быть удалены в любой момент и полностью восстанавливаются повторным сканированием инфраструктуры. По сути, это локальный кеш.
Вместо привычной модели Terraform plan → apply Wye использует другую модель исполнения, в которой нет отдельного планирования как промежуточного этапа между анализом и применением изменений.
Почему отсутствие сохранённого состояния не ломает зависимости
Первый вопрос, который обычно возникает после описания такой модели, звучит так: если нет глобального файла состояния, то как система связывает ресурсы между собой?
В Terraform эту задачу решает именно .tfstate. Он хранит соответствие между логическим ресурсом из конфигурации и объектом, существующим у провайдера.
В Wye используется другой подход. Конфигурация пишется на языке Nickel — функциональном языке конфигурации с контрактами и детерминированной моделью вычислений. Зависимости между ресурсами выражаются через обычные импорты файлов наблюдаемого состояния.
Например, после создания сетевого интерфейса его наблюдаемые атрибуты оказывается в файле network.ec2-eni.obs.json. Nickel-конфигурация может импортировать этот файл и использовать значение его ENI ID для создания виртуальной машины AWS EC2.
Таким образом граф зависимостей строится не вокруг глобального файла состояния, а вокруг явных импортов между ресурсами. Граф импортов автоматически определяет порядок применения изменений.
Это позволяет использовать одну и ту же модель как для вычисления конфигурации, так и для построения графа зависимостей.
Почему Nickel
Для конфигурации Wye используется Nickel. Выбор языка здесь продиктован не синтаксисом и не эстетикой, а набором практических свойств, которые критичны для данного подхода.
Первое — поддержка импортов как базового примитива языка (важна возможность импорта как файлов целевого языка, так и .json). В Wye зависимости между ресурсами выражаются напрямую через импорт файлов. Импорты в Nickel становятся не просто механизмом композиции, а основой для построения графа зависимостей всей инфраструктуры.
Второе — предсказуемость и зрелость языка. Конфигурация инфраструктуры должна быть детерминированной и воспроизводимой. Nickel предоставляет функциональную модель вычислений без побочных эффектов, где одинаковые входные данные всегда приводят к одинаковому результату. Это важно для того, чтобы процесс вычисления конфигурации можно было безопасно запускать многократно в разных контекстах.
Третье — система контрактов. В Wye каждый провайдер описывает схему допустимой конфигурации, и Nickel позволяет проверять эти контракты на этапе вычисления конфигурации, до любых обращений к внешним API. Это означает, что значительная часть ошибок отлавливается ещё на уровне модели данных, а не во время применения изменений к инфраструктуре.
Дрейф как артефакт файловой системы
В большинстве IaC-систем дрейф существует как временный результат выполнения команды. Он появляется в момент планирования и исчезает сразу после принятия решения — либо применяется, либо игнорируется. Это делает его по сути побочным результатом выполнения CLI-команды, а не частью модели системы.
В Wye этот подход изменён. Результат сравнения между желаемым и реальным состоянием не остаётся внутри процесса выполнения команды, а материализуется в виде отдельного .cfgdiff.json файла.
Таким образом дрейф перестаёт быть транзитивными данными планировщика и становится наблюдаемым артефактом файловой системы. Его можно анализировать независимо от CLI, использовать в CI, хранить в репозитории или передавать внешним системам наблюдения.
Например, если контейнер db.dkr-ctr был остановлен вручную, после wye scan-sync -d рядом появится db.dkr-ctr.cfgdiff.json:
{
"stopped": true
}Этот файл является не побочным эффектом команды, а частью модели наблюдения инфраструктуры.
Неучтённые ресурсы
Отдельной проблемой являются ресурсы, которые существуют в инфраструктуре, но отсутствуют в конфигурации Git.
Во время полного сканирования Wye способен обнаруживать такие объекты и помещать информацию о них в директорию untracked.
Для каждого найденного ресурса создаются два файла:
наблюдаемое состояние в виде
.obs.jsonфайла;полная конфигурация в виде
.cfgdiff.jsonфайла (каноническое представление объекта как разница относительно пустого желательного состояния);
Таким образом, неучтённый ресурс становится явной сущностью системы, а не скрытым состоянием вне контроля IaC-инструмента. Это позволяет обнаруживать "внешне созданную" инфраструктуру, анализировать её структуру и принимать решение — импортировать ли её в конфигурацию или удалить.
Базовые команды
Команда stage
Единственная команда, отвечающая за приведение инфраструктуры к желаемому состоянию — stage.
Название выбрано не случайно и отсылает к Git-терминологии. В Wye Git index используется не как промежуточная область для будущего коммита, а как отражение текущего состояния реально применённой инфраструктуры. Иными словами, индекс в любой момент времени соответствует тому, что уже развернуто в системе.
Поэтому "stage" означает не "подготовить изменения к коммиту", как в классическом Git, а "согласовать желаемое состояние с реальной инфраструктурой и зафиксировать результат в индексе".
Для каждого изменения .cfg.ncl-файла относительно индекса команда stage применяет правило:
добавлен → ресурс создаётся;
изменён → ресурс модифицируется;
удалён → ресурс удаляется;
перезаписан → ресурс переименовывается (и, возможно, модифицируется);
Во время выполнения stage система обращается к API провайдеров и получает текущее состояние ресурсов, затем вычисляет разницу между новой желаемой конфигурацией и реальной инфраструктурой. На основе этой разницы выполняются только те операции, которые необходимы для приведения системы к целевому состоянию.
При этом важно, что сравнение всегда выполняется относительно живой инфраструктуры, а не относительно сохранённого снимка состояния, как в классических системах, основанных на сохранённом состоянии.
Команда scan-sync
Отдельно существует операция сканирования инфраструктуры (scan-sync), однако она не участвует в процессе приведения системы к желаемому состоянию и используется исключительно для наблюдения и диагностики.
Во время сканирования Wye обращается к API провайдеров и получает текущее состояние ресурсов, после чего сравнивает его с конфигурацией в Git. При обнаружении расхождений система фиксирует их в виде файлового артефакта — .cfgdiff.json, содержащего детализированное описание отличий между реальной инфраструктурой и желаемой конфигурацией.
Если в инфраструктуре присутствуют ресурсы, отсутствующие в рабочей директории Git, соответствующие им .cfgdiff.json и .obs.json файлы помещаются в директорию untracked/.
Команда sync
Помимо полного сканирования существует более точечная операция — sync. В отличие от scan-sync, которая работает на уровне указанного набора провайдеров или всей инфраструктуры в целом, sync применяется к конкретному ресурсу (файлу конфигурации). В этом случае Wye обновляет соответствующий .obs.json и при необходимости создаст .cfgdiff.json, если обнаружены расхождения. Это делает sync более лёгким и локализованным инструментом для работы с отдельными ресурсами, не требующим полного обхода всей системы и всех провайдеров.
Откат на Git ревизию
Поскольку желаемое состояние полностью хранится в Git, откат к любой предыдущей версии становится естественным следствием модели: достаточно переключить репозиторий на нужную ревизию и применить изменения.
Механика отката:
переводим HEAD на нужную ревизию:
git reset --soft <commit>;переводим рабочую директорию на нужную ревизию:
git restore --worktree --source=<commit> :/;применяем изменения рабочей директории к индексу:
wye stage $(git diff --name-only)
Таким образом откат в Wye — это не отдельная операция уровня инфраструктуры, а обычное применение изменений, где целевым состоянием становится выбранная ревизия Git.
Сравнение с Terraform и Crossplane
Важно понимать, что Wye не является "Terraform без .tfstate".
Terraform использует модель снимка инфраструктуры. Она даёт глобально согласованное представление состояния системы и позволяет эффективно вычислять изменения. Взамен появляется необходимость поддерживать согласованность между этим снимком и реальностью.
Crossplane решает задачу иначе: он переносит управление инфраструктурой внутрь Kubernetes и использует Kubernetes API как плоскость управления (control plane). Такая модель обеспечивает непрерывное согласование, но требует существования самого Kubernetes-кластера и всей связанной с ним инфраструктуры.
Wye делает другой выбор. Он не использует ни файл состояния, ни Kubernetes API. Вместо этого система поддерживает реактивное наблюдение реальной инфраструктуры и явное применение изменений.
Это не делает модель автоматически лучше. Это просто другой набор компромиссов.
Компромиссы
Отказ от файла состояния не избавляет от сложности полностью — он переносит её в другие места.
Во-первых, система теряет глобальный консистентный снимок всей инфраструктуры. Наблюдаемое состояние может устаревать между сканированиями.
Во-вторых, появляется концепция выборочная актуализация данных. Во время применения изменений обновляются только те ресурсы, которые участвуют в текущем графе изменений. Для получения полного актуального представления требуется отдельное сканирование.
В-третьих, наблюдение становится явной операцией. Вместо неявного обновления состояния внутри планировщика пользователь самостоятельно контролирует момент получения информации о реальной системе.
С другой стороны, исчезает целый класс проблем, связанных с поддержанием согласованности глобального файла состояния.
Текущее состояние проекта
Сейчас Wye находится на стадии рабочего прототипа. Реализованы провайдеры для AWS EC2 и Docker.
Архитектурно система не привязана ни к облакам, ни к контейнерам. Любая внешняя система с наблюдаемым и управляемым состоянием может быть подключена через слой провайдера — будь то сетевое оборудование, облачные сервисы или внутренние платформенные API.
Основная цель проекта сейчас — проверить саму гипотезу о том, что управление инфраструктурой возможно без сохранённого состояния как фундаментального архитектурного элемента.
Пока рано делать окончательные выводы. Но уже сейчас становится понятно, что многие механизмы, которые сегодня считаются неотъемлемой частью IaC, на самом деле являются следствием выбранной модели состояния, а не обязательным свойством систем управления инфраструктурой.