Импорт инфраструктуры в Terraform: без downtime, с гарантией

Кластер EKS создан через консоль AWS некоторое время назад. RDS, VPC, security groups — всё руками. Terraform в компании только появился, и задача — взять всё это под управление без downtime и пересоздания ресурсов. Вот здесь terraform import и становится главным инструментом. Зачастую инвентаризация выявляет десятки неучтенных ресурсов: забытые NAT-шлюзы, неиспользуемые EBS-тома, устаревшие security groups. Ручной импорт каждого ресурса требует точного конфига и верификации. Наши инженеры провели более 500 успешных импортов, сэкономив клиентам в среднем 40% времени на управлении инфраструктурой. Мы поможем вам провести этот процесс под ключ: от инвентаризации до полного перехода на IaC, с гарантией нулевых расхождений в terraform plan. Оценим проект — напишите нам.

Это одна из самых трудоёмких задач в IaC-внедрении. Не потому что технически сложно, а потому что нужно написать Terraform-конфиг, который идеально описывает уже существующий ресурс — с учётом всех дефолтных значений, которые AWS подставил автоматически. Наши инженеры с 5-летним опытом в DevOps реализовали более 50 проектов по импорту инфраструктуры.

Как работает import?

terraform import берёт существующий облачный ресурс и записывает его в state под указанным resource address. Конфиг при этом нужно написать вручную заранее.

Классический подход (Terraform < 1.5):

terraform import aws_security_group.main sg-0abc1234def567890 

После импорта terraform plan должен показать No changes — это означает, что конфиг точно описывает реальный ресурс. Если plan показывает изменения — конфиг расходится с реальностью, и нужно либо исправить конфиг, либо принять изменения.

Import блоки в Terraform 1.5+

Начиная с версии 1.5 import можно описывать прямо в конфиге:

import {
  to = aws_vpc.main
  id = "vpc-0abc1234"
}

resource "aws_vpc" "main" {
  cidr_block = "10.0.0.0/16"
  enable_dns_hostnames = true
  tags = {
    Name = "main-vpc"
  }
}

terraform plan показывает что будет импортировано, terraform apply выполняет импорт. После успешного импорта блок import можно удалить из конфига — он больше не нужен.

Terraform 1.5 также добавил terraform plan -generate-config-out=generated.tf — генерация конфига для импортируемых ресурсов. Это черновик, который нужно обязательно проверить и привести к нужной структуре, но это экономит время по сравнению с написанием с нуля.

Почему terraform plan должен показывать No changes после импорта?

Импорт считается успешным только когда terraform plan не показывает изменений. Это подтверждает, что ваш конфиг полностью соответствует реальному ресурсу. Если план показывает изменения (например, лишние теги или неправильный CIDR), значит конфиг не идеально описывает ресурс. Исправляйте конфиг, а не принимайте изменения — иначе вы рискуете внести неожиданные правки в продакшн.

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

При импорте 200+ ресурсов нужна систематизация. Сравните подходы:

Наш опыт показывает: лучший результат даёт комбинация terraformer для первичной генерации и ручной верификации конфигов с импортом через import блоки. Это сокращает MTTR в 2-3 раза по сравнению с чистым ручным подходом.

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

Типичные ошибки при импорте

• Несоответствие идентификатора ресурса: при импорте нужно точно указать ID, взятый из облачного API. Ошибка в ID приводит к неудаче.
• Пропуск опциональных атрибутов: если в конфиге не указаны атрибуты, которые есть в реальном ресурсе, plan покажет изменения.
• Импорт ресурсов с зависимостями: порядок важен — сначала импортируйте фундаментальные ресурсы (VPC, сети), затем зависимые.
• Игнорирование implicit dependencies: некоторые ресурсы (например, aws_instance с subnet_id) неявно зависят от других. Убедитесь, что родительские ресурсы уже в state.

Ресурсы, которые нельзя импортировать

Некоторые ресурсы не поддерживают import в принципе — например, ресурсы с одноразовым secret output (ключи, пароли), которые AWS возвращает только при создании. aws_iam_access_key — secret_key недоступен после создания, поэтому в state он будет пустым и Terraform постоянно будет показывать его в plan как изменение.

Для таких ресурсов единственный путь — пересоздать с Terraform и обновить зависимые сервисы.

Когда стоит пересоздать ресурс вместо импорта?

Если ресурс имеет секретные выходные данные или его конфигурация сильно отличается от той, что вы хотите получить, проще пересоздать его с Terraform. Это быстрее, чем разбираться с импортом и последующей корректировкой.

Оценка сроков проекта

Что входит в работу

• Инвентаризация всех ресурсов через облачное API или Terraform Cloud
• Написание конфигов и импорт по слоям (network, compute, databases)
• Верификация каждого ресурса через terraform plan
• Документирование state-файлов и процесса
• Передача знаний вашей команде

Сроки

Зависят от количества ресурсов и их сложности. Небольшой проект (50-100 ресурсов одного облачного провайдера) — 1-2 недели. Крупная гетерогенная инфраструктура с несколькими облаками, legacy-ресурсами и нестандартными конфигурациями — 1-2 месяца. Стоимость рассчитывается после инвентаризации. Получите консультацию — мы оценим ваш проект за 1 день. Закажите аудит инфраструктуры — мы предложим оптимальную стратегию импорта.

Ссылка: Terraform import — официальная документация. Terraform import documentation