Переезд из живого облака: разведка только на чтение
Сначала читаем существующую инфраструктуру, строим карту зависимостей и печатаем проект Terraform. Применяете его вы, а не мы.
Переезд между облаками обычно продают как услугу с кнопкой. Нажали — поехали. Проблема в том, что кнопка предполагает, что кто-то уже понял вашу инфраструктуру, и этот кто-то — не вы.
Мы делим переезд на три шага, и первые два не меняют ничего.
Шаг первый: разведка только на чтение
Инструмент подключается к живому облаку и читает, что там есть. Без записи. Без создания служебных ресурсов. Без изменения тегов.
Это ограничение техническое, а не декларативное: у режима разведки нет операций записи. Ключ доступа для разведки может быть выдан с правами только на чтение, и он будет работать.
Причина в том, что разведка выполняется на работающей системе. Момент, когда инструмент впервые смотрит на вашу инфраструктуру, — худший из возможных момент для того, чтобы он что-нибудь в ней поправил.
Шаг второй: карта зависимостей
Результат разведки — не список ресурсов, а граф. Что от чего зависит, что с чем связано сетью, что чьё состояние.
Список ресурсов бесполезен для переезда. Он не отвечает на единственный важный вопрос: в каком порядке переносить, чтобы на каждом шаге получалась работающая система, а не набор частей.
Карта зависимостей отвечает. Она же показывает то, что обычно и является причиной провала переезда: связи, о которых никто не помнил.
Шаг третий: проект Terraform, который применяете вы
На выходе — обычный проект Terraform. Вы его читаете, правите, применяете. Или не применяете.
Это ключевое различие с кнопкой. Мы не выполняем перенос — мы печатаем описание целевого состояния, которое можно ревьюить как код.
Разница проявляется в момент, когда что-то идёт не так. Если переезд выполнял чёрный ящик, разбираться приходится с чёрным ящиком. Если переезд — это ваш план Terraform, разбираться приходится с планом, который вы читали.
Почему не «полностью автоматически»
Потому что автоматический переезд требует решений, которые мы не имеем права принимать за вас.
Какие ресурсы вообще переносить, а какие оставить. Что заменить управляемым сервисом целевого облака, а что перенести как есть. Где допустим простой, а где нет. Что делать с данными, которые в старом облаке лежат в проприетарном хранилище.
Инструмент, который принимает эти решения сам, принимает их по умолчанию. Значения по умолчанию для переезда инфраструктуры — плохая идея.
Что при этом действительно автоматизируется
Скучная и объёмная часть: инвентаризация, восстановление связей, генерация описания, проверка полноты. Это работа, которая руками занимает недели и делается с ошибками именно из-за объёма.
То есть мы автоматизируем то, что человек делает плохо, и оставляем человеку то, что он делает хорошо. Обратное распределение встречается чаще и работает хуже.
Требование git и здесь
Сгенерированный проект попадает в репозиторий, и дальше на него действуют общие правила: применение внутри git, чистое дерево, файл состояния Terraform в индекс не попадает.
Переезд в результате становится не событием, а серией коммитов. Через год на вопрос «почему эта машина такого размера» будет ответ.