Создание data source
Тема дорожной карты · Terraform
Источники данных Terraform позволяют конфигурации запрашивать существующую инфраструктуру или внешние системы и использовать результаты как входные данные для определений ресурсов, не управляя жизненным циклом запрашиваемого объекта. Блок data в HCL определяет провайдер, тип ресурса и критерии фильтрации — например, получение последнего ID Amazon Linux AMI из AWS или чтение существующей группы ресурсов Azure по имени — так что terraform plan всегда разрешает актуальные значения, а не жёстко прописанные строки. Источники данных Terraform незаменимы для интеграции независимо управляемой инфраструктуры: одна команда владеет общим VPC, созданным в отдельном state-файле, а команда-потребитель читает ID подсетей через data "terraform_remote_state" или блок data "aws_vpc", не дублируя и не хардкодя значения. На GCP, Kubernetes и других провайдерах источники данных предоставляют метаданные проектов, конечные точки кластеров и версии секретов из Vault или AWS Secrets Manager, обеспечивая безопасную и динамическую конфигурацию без хранения чувствительных значений в tfvars-файлах. Правильное использование источников данных делает конфигурации Terraform DRY, снижает связность между state-файлами и гарантирует, что terraform apply всегда создаёт ресурсы против актуального авторитетного состояния облачного окружения.
Как это работает
Создание data source — написание своего Terraform-провайдера на Go через Terraform Plugin Framework (современный, с 2022) или старый SDK v2. Провайдер реализует Schema, Configure, CRUD-методы (Create, Read, Update, Delete) на каждый ресурс. Публикуется в Terraform Registry (публично) или хостится приватно. Тестируется acceptance-тестами против реального или mock-API.
Когда применять
Свой провайдер — только когда (а) у целевой системы нет существующего Terraform-провайдера, (б) поддержка инфры через Terraform реально лучше другого инструмента (Helm chart, кастомный CLI, Pulumi). Для внутренних микросервисов часто проще конфигурация через Helm/Kustomize, чем провайдер. Кастомный провайдер — реальный софт с реальной стоимостью поддержки.
Типичные ошибки
Ловушки Создание data source: пишут провайдер, когда хватило бы Kubernetes-оператора или простого CLI; не обрабатывают Read корректно (drift-detection ломается); нет версионирования (каждый релиз — пересборка latest); пропуск acceptance-тестов (тонкие баги едут к юзерам провайдера).