Разработка кастомного Terraform Provider для внутренних сервисов

Разработка terraform provider: где рвётся автоматизация

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

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

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

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

Что даёт единый слой управления внутренними сервисами

Свой провайдер превращает внутренние сервисы в такой же декларативный ресурс, как облачные: единый слой управления, где описание сервиса живёт в репозитории, применяется через Terraform и проходит проверку кода. Дальше — измеримые следствия, которые видно на первой же неделе работы.

Единое описание вместо ручных правок

Источник правды один: окружения сервиса, права, секреты и точки мониторинга описаны в одном файле. Любое изменение проходит план применения, и расхождение между описанием и реальным состоянием видно до выката, а не после сбоя. Новый сервис выводится по шаблону: подготовка окружения занимает одно применение вместо дней ручных операций, а целый класс отказов — «поправили руками и забыли зафиксировать» — исчезает.

Разграничение прав и сред по умолчанию

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

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

Сравнение подходов: скрипты, шаблоны, обёртка или свой слой

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

Когда хватает шаблонов и скриптов

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

Когда без своего слоя не обойтись

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

Этапы работы: от аудита инфраструктуры до передачи кода

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

Что фиксируем на входе

Разбираем перечень сервисов, окружений и ролей доступа: что создаётся руками, что уже автоматизировано, где описания расходятся с фактическим состоянием. Отдельно собираем ограничения — правила безопасности, порядок согласования изменений, требования к аудиту. На выходе получаем карту ресурсов и список пробелов в доступах, а не общее описание «как всё устроено».

1. Аудит инфраструктуры и доступов: инвентаризация сервисов и прав, сверка реального состояния с описаниями.
2. Схема целевого описания: какие сущности становятся ресурсами и источниками данных, как связаны между собой.
3. Разработка и настройка провайдера: реализация ресурсов, импорт существующих объектов, корректная обработка изменений и удаления.
4. Проверка на тестовом контуре: создание, изменение и откат на копии окружения, сверка плана с ожидаемым результатом.
5. Опытная эксплуатация: команда работает через новый инструмент на ограниченном участке, мы сопровождаем и правим по замечаниям.
6. Передача и обучение команды: разбор кода, порядок развёртывания и обновления, регламент разбора сбоев.

Как проверяем результат перед сдачей

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

Артефакты в репозитории: код, схемы, регламенты, доступы

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

Код и описание инфраструктуры

• Исходники Terraform-провайдера с описанием каждого ресурса и источника данных: какие параметры обязательны, какие вычисляются, как обрабатываются конфликты при изменении.
• Конфигурации окружений — раздельные наборы параметров и изолированные состояния, чтобы проверка не могла задеть промышленный контур.
• Готовые модули для типовых сервисов: подключение нового сервиса сводится к нескольким строкам вместо копирования чужого файла целиком.
• Набор проверок и примеры использования — песочница, где видно, как ресурс ведёт себя при создании, изменении и удалении.

Схемы и регламенты для команды

• Схемы связей между сервисами, окружениями и внешними системами: на одной странице видно, что от чего зависит и что затронет изменение.
• Политики доступа и роли — кто читает состояние, кто меняет, кто применяет изменения в промышленном контуре; разграничение зашито в код и проверяется автоматически.
• Регламент изменений: порядок выпуска новой версии, правила обратной совместимости и процедура отката.
• Инструкции для дежурной смены: типовые отказы, как отличить их от сбоя инфраструктуры и что делать по шагам.

Кейс: 40 сервисов под управлением Terraform вместо ручных правок

К нам пришла команда, у которой 40 внутренних сервисов жили в нескольких окружениях, и каждое окружение собиралось руками. Мы перевели всё на единое описание инфраструктуры на Terraform и разработали провайдер под внутренние сервисы — для тех сущностей, под которые готовых ресурсов не было.

Что было до

Вывод нового сервиса занимал два-три дня: инженер заводил сеть, балансировщик, базы, очереди и права по инструкции на 30 шагов. На релиз приходилось 15-20 ручных правок, и часть из них расходилась с тем, что уже работало в проде — окружения постепенно разъезжались.

Восстановление после сбоя упиралось в то, что актуальную конфигурацию никто точно не знал: её собирали по логам и опросам сервисов. Около половины инцидентов приходилось не на ошибку в коде, а на расхождение настроек.

Что стало после

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

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

Что делать, если инфраструктура уже описана вручную?

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

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

Порядок перевода подчинён радиусу поражения. Первыми идут сервисы без состояния и внешнего трафика — очереди, кеши, стенды: ошибка там стоит перезапуска, а не простоя. Затем сети, балансировка и права доступа, потом хранилища с данными. То, что держит трафик, переводится последним и по одному — тогда откат ограничен одним компонентом.

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

Технические сомнения: состояние, права, откат, поддержка

Сомнения, которые возникают перед разработкой Terraform-провайдера, обычно одни и те же: где живёт состояние, кто вправе применять изменения, как откатиться и что будет после передачи кода. Ниже — краткие ответы, детали разбираем на созвоне по вашей задаче.

Кто вправе менять инфраструктуру?

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

Как устроен откат изменения окружения?

Перед применением план показывает все изменения, включая удаление ресурсов. Откат опирается на зафиксированную версию провайдера и снимок состояния; ресурсы с данными при этом не пересоздаются.

Что будет при изменении интерфейсов сервисов?

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

Кто поддерживает код после передачи?

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

Обсудим задачу: разберём инфраструктуру и вернёмся с планом

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

Что помогает нам собрать корректную оценку:

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

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

Готовы начать с короткого разговора по делу: опишите задачу автоматизации — вернёмся с оценкой и планом.

• Начинают с полного охвата: пытаются описать кодом сразу все внутренние сервисы, вместо одного ограниченного контура. Объём работ растёт быстрее, чем польза, и первый результат теряется в согласованиях.
• Ведут ручные правки параллельно с описанием в коде. Через месяц никто не знает, где актуальная версия, и любое очередное применение изменений затирает чужую работу.
• Не разграничивают права: один общий доступ на всех, изменения уходят в рабочий контур без проверки. Ошибка одного участника останавливает работу всей команды.
• Не договариваются о правилах именования и структуре описаний заранее. Каждый пишет по-своему, и вместо единого слоя управления получается набор несвязанных файлов, которые никто, кроме автора, не читает.
• Переносят всё разом, без параллельного периода, и отключают ручные способы в тот же день. При первом же сбое вернуться к прежнему порядку уже нечем.
• Оставляют поддержку «на потом»: в репозитории нет ответственного, не описаны порядок изменений и порядок отката. Через несколько месяцев слой управления перестаёт обновляться и расходится с реальной инфраструктурой.
• Хранят чувствительные данные прямо в описаниях инфраструктуры. Секреты попадают в историю изменений и остаются там навсегда, доступные каждому, кто откроет репозиторий.
• Считают, что после запуска работа заканчивается: не закладывают время на обучение команды и сопровождение, а затем удивляются, что инструментом пользуются два человека из десяти.