Кластер EKS створено через консоль AWS деякий час тому. RDS, VPC, security groups — все вручну. Terraform у компанії тільки з'явився, і завдання — взяти все це під управління без даунтайму та перестворення ресурсів. Ось тут 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+ ресурсів потрібна систематизація. Порівняйте підходи:
| Інструмент | Час на 200 ресурсів | Контроль якості | Ручне доопрацювання |
|---|---|---|---|
Ручний terraform import |
2-4 тижні | Повний | Тільки написання конфігів |
Import блоки + -generate-config-out |
1-2 тижні | Високий | Перевірка згенерованого коду |
| Terraformer | 3-5 днів | Низький | Значна правка (50-70%) |
Наш досвід показує: найкращий результат дає комбінація 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. Це швидше, ніж розбиратися з імпортом та подальшим коригуванням.
Оцінка термінів проекту
| Розмір інфраструктури | Кількість ресурсів | Орієнтовний термін | Складність |
|---|---|---|---|
| Мала | до 50 | 1 тиждень | Низька |
| Середня | 50 – 200 | 2 – 4 тижні | Середня |
| Велика | 200 – 500 | 1 – 2 місяці | Висока |
| Enterprise | 500+ | від 2 місяців | Дуже висока |
Що входить в роботу
- Інвентаризація всіх ресурсів через хмарне API або Terraform Cloud
- Написання конфігів та імпорт по шарах (network, compute, databases)
- Верифікація кожного ресурсу через
terraform plan - Документування state-файлів та процесу
- Передача знань вашій команді
Терміни
Залежать від кількості ресурсів та їх складності. Невеликий проект (50-100 ресурсів одного хмарного провайдера) — 1-2 тижні. Велика гетерогенна інфраструктура з кількома хмарами, legacy-ресурсами та нестандартними конфігураціями — 1-2 місяці. Вартість розраховується після інвентаризації. Отримайте консультацію — ми оцінимо ваш проект за 1 день. Замовте аудит інфраструктури — ми запропонуємо оптимальну стратегію імпорту.
Посилання: Terraform import — офіційна документація.
