Ручное изменение облачного ресурса привело к неожиданному плану следующего развёртывания. Как инфраструктура как код обнаруживает расхождение между описанием и реально созданным ресурсом?
Инфраструктура как код обнаруживает расхождение через сравнение трёх состояний: желаемого состояния из конфигурации, сохранённого состояния инструмента и фактического состояния ресурса, полученного через API облачного провайдера. Если фактические параметры отличаются от желаемых, инструмент формирует план изменения, который обычно стремится вернуть ресурс к описанной конфигурации.
Декларативная инфраструктура появилась как способ сделать создание окружений воспроизводимым, проверяемым и управляемым через ревью. При ручных изменениях фактическая инфраструктура постепенно расходится с документацией и настройками, поэтому повторное развёртывание становится непредсказуемым.
Подход инфраструктуры как кода переносит описание ресурсов в версионируемые файлы. Инструмент не просто выполняет последовательность команд, а вычисляет переход от текущего состояния к желаемому.
Предположим, конфигурация описывает виртуальную машину определённого размера, но оператор изменил размер вручную через консоль. Если следующее развёртывание не обнаружит это изменение, окружение продолжит незаметно отклоняться от репозитория, а последующие операции могут дать разные результаты.
Ошибочное решение опасно в обе стороны: автоматическое возвращение параметра может вызвать простой или дополнительные расходы, а безусловное принятие ручного изменения разрушает единый источник управления и воспроизводимость.
Инструмент сначала читает конфигурацию и получает из облачного API актуальные параметры ресурса. Затем он сопоставляет ресурс с записью в файле состояния, которая связывает логический объект конфигурации с конкретным облачным объектом и хранит известные атрибуты.
После синхронизации получается план: создать отсутствующий ресурс, изменить отличающиеся параметры, заменить ресурс, если его нельзя обновить на месте, или удалить объект, которого больше нет в желаемом описании. Ручное изменение поэтому обычно приводит к плану возврата параметра к значению из конфигурации.
Файл состояния не является окончательной правдой о ресурсе: он служит картой и кэшем известных атрибутов. Фактические данные нужно периодически получать от провайдера, иначе изменения вне инструмента могут остаться незамеченными. Для чтения необходимы соответствующие права доступа, а задержки распространения изменений в облачном API способны временно показать устаревшее состояние.
Обнаруженное расхождение следует обработать осознанно. Если ручное изменение ошибочно, его возвращают автоматически после проверки плана. Если оно нужно, его переносят в конфигурацию и применяют через обычный процесс. Игнорирование отдельных атрибутов допустимо только намеренно: это снижает шум, но одновременно отключает контроль инструмента над этими параметрами.
План нужно проверять перед применением. Особенно опасны изменения, требующие пересоздания ресурса, затрагивающие сетевые зависимости, диски, базы данных или параметры безопасности. Для совместной работы также нужны блокировка состояния и контроль версий, но они защищают от одновременной записи состояния, а не от ручных изменений в облаке.
Команда вручную увеличила размер управляемой базы данных перед нагрузочным тестом, но не изменила конфигурацию инфраструктуры как кода. Следующий план показал возврат к меньшему размеру, что могло привести к нехватке производительности и повторному масштабированию во время теста.
Рассматривались три варианта. Оставить ручное изменение означало быстро решить задачу, но сохранить расхождение. Добавить исключение для параметра уменьшило бы количество предупреждений, однако инструмент перестал бы контролировать размер. Перенести изменение в конфигурацию требовало ревью и согласования расходов, зато сохраняло воспроизводимость.
Выбрали третий вариант: изменение внесли в репозиторий, проверили план и применили его в согласованное окно. В результате фактическое и желаемое состояния совпали, а последующие планы перестали предлагать обратное уменьшение ресурса.
Нет. Инструмент обнаружит изменение только если провайдер может прочитать соответствующий атрибут через API и возвращает его с достаточной точностью. Ограниченные права, неподдерживаемое поле, ошибка чтения или временно устаревший ответ могут привести к тому, что расхождение не будет видно.
Кроме того, некоторые значения вычисляются самим облаком или меняются автоматически. Если провайдер не позволяет корректно сопоставить их с конфигурацией, нужно проверить модель ресурса и правила игнорирования изменений, а не считать отсутствие изменения в плане доказательством отсутствия дрейфа.
Блокировка защищает состояние от одновременного изменения несколькими запусками инструмента. Она не запрещает оператору изменить ресурс через консоль, другой инструмент или прямой вызов API.
После внешнего изменения следующий запуск должен заново прочитать фактические параметры ресурса. Для предотвращения самого дрейфа нужны права доступа, ограничение ручных изменений, аудит, уведомления и процесс, требующий вносить инфраструктурные изменения через репозиторий.
Некоторые атрибуты нельзя изменить после создания ресурса из-за ограничений облачного API или модели провайдера. В таком случае изменение описывается как удаление старого объекта и создание нового, иногда с зависимыми ресурсами.
Пересоздание может привести к простою, потере локального состояния, смене адреса или необходимости миграции данных. Кандидат должен проверить, является ли параметр неизменяемым, какие зависимости будут затронуты и предусмотрены ли резервирование, перенос данных или отдельное окно обслуживания.