Привіт, Terraform Data. Бувай, Null Resource

💡 Усі статті, обговорення, новини про DevOps — в одному місці. Приєднуйтесь до DevOps спільноти!

Це переклад статті з мого технічного блогу

Новий Terraform 1.4 вийшов зовсім нещодавно та приніс низку нових функцій, включаючи покращений run output у Terraform Cloud, можливість використовувати результати політики OPA в CLI та вбудовану альтернативу null_resource — terraform_data.

У цій публікації я хочу показати та розказати про ресурс terraform_data, який має два призначення:

по-перше, дозволяє зберігати довільні значення та використовувати їх пізніше для реалізації тригерів життєвого циклу (lifecycle) інших ресурсів
по-друге, його можна використовувати для запуску provisioners, у разі відсутності ресурсу, який би виконав потрібне

Для тих із вас, хто знайомий із null provider, ресурс terraform_data може виглядати дуже схожим. І ви маєте рацію!

Замість того, щоб бути окремим провайдером, ресурс terraform_data тепер пропонує ті самі можливості у вигляді інтегрованого функціоналу. І це круто!

Хоча null provider усе ще доступний і наразі немає заяв про зупинку його підтримки (станом на квітень 2023 року, версія 3.2.1), terraform_data є нативною заміною null_resource, і останній незабаром може бути визнаний застарілим та його підтримка може припинитися.

Ресурс terraform_data має два опціональні аргументи, input та triggers_replace, і його конфігурація виглядає наступним чином:

input (опціональний параметр) зберігає значення, яке передається до ресурсу.
triggers_replace (опціональний параметр) — це значення, яке запускає перестворення ресурсу, якщо саме змінюється

Є два атрибути, крім аргументів, які зберігаються у terraform state — id та output — після створення ресурсу. Подивімося на це детальніше.

output атрибут вираховується та зберігається на основі значення input
id — це унікальний ідентифікатор екземпляру ресурсу в terraform state (як і для будь-якого іншого ресурсу).

Приклад використання terraform_data разом з replace_triggered_by

Розгляньмо перший варіант використання ресурсу terraform_data — це можливість ініціювати заміну іншого ресурсу на основі значення input-аргументу.

Тут трохи контексту: аргумент replace_triggered_by мета-аргументу lifecycle дозволяє ініціювати заміну ресурсу на основі іншого ресурсу або атрибуту іншого ресурсу.

Якщо ви ще не знайомі із replace_triggered_by, ви можете переглянути іншу публікацію на моєму блозі, де я це розглядаю.

replace_triggered_by є потужним функціоналом, але ось у чому його особливість: необхідно передавати ресурс або атрибут ресурсу, і ви не можете передати змінну (variable) або локальне значення (local) для replace_triggered_by.

Проте за допомогою terraform_data ви можете опосередковано ініціювати перестворення іншого ресурсу, використовуючи змінну (variable) або вираз у локальному значенні (local) для input аргументу.

Наступний код ілюструє це:

Якщо модифікувати значення змінної revision, то наступний запуск Terraform plan запропонує замінити й aws_instance.webserver:

Приклад використання terraform_data разом з provisioner

Перш ніж почати: HashiCorp радить (і я також це підтримую) уникати використання provisioner, якщо тільки у вас немає інших варіантів. Одна з причин — додаткова, неявна та неочевидна залежність, яка з’являється в кодовій базі: бінарний файл, який викликається всередині блоку provisioner, має бути на машині.

Але давайте будемо реалістами: provisioner все ще широго використовується, і завжди є той самий унікальний проєкт, якому ця штука потрібна.

Ось фрагмент коду, який демонструє використання provisioner у ресурсі terraform_data:

У цьому прикладі відбувається наступне:

Коли ресурси створюються вперше, запускається provisioner всередині terraform_data.
Наступний виклик plan/apply ініціює новий запуск provisioner лише тоді, коли приватна IP-адреса інстансу (aws_instance.webserver.private_ip) змінюється, оскільки це буде тригером для повторного створення terraform_data. Водночас відсутність змін внутрішнього IP-адреси означає відсутність виконання provisioner.

_____

Зі своєю здатністю зберігати та використовувати значення для тригерів життєвого циклу (lifecycle) та provisioner, terraform_data є потужним інструментом, який може покращити ваш Terraform код.

Незважаючи на те, що null provider усе ще займає своє місце в екосистемі Terraform, terraform_data є його еволюцією, і його інтеграція як вбудований функціонал, безсумнівно, є дуже гарною новиною.

Чому б не спробувати це у своєму наступному проєкті та подивитися, як це може спростити ваш код? 🙌