Модуль Terraform использует не тот provider: передаём alias явно
В корневой конфигурации добавили AWS provider с alias target, но модуль продолжает создавать ресурсы в прежнем окружении. Само объявление alias не меняет provider внутри всех дочерних модулей. Нужно явно связать имя, которое использует модуль, с конфигурацией, выбранной вызывающей стороной.
Здесь важно различать три понятия. Source определяет пакет provider. Локальное имя aws используется в коде. Конфигурация aws.target содержит конкретные настройки подключения. Одинаковый пакет может иметь несколько конфигураций для разных регионов или учётных записей.
Проверим выбор без создания ресурсов
Пример использует read-only data source aws_caller_identity. Подготовьте два AWS CLI profile training-source и training-target с доступом к соответствующим учебным аккаунтам. Профили и секреты хранятся вне HCL. Если оба профиля относятся к одному аккаунту, значение account_id не позволит различить их: используйте два действительно разных контекста или дополнительно проверьте caller ARN.
В корневом main.tf объявите две конфигурации и вызов модуля:
terraform {
required_providers {
aws = {
source = "hashicorp/aws"
}
}
}
provider "aws" {
region = "eu-central-1"
profile = "training-source"
}
provider "aws" {
alias = "target"
region = "eu-central-1"
profile = "training-target"
}
module "identity" {
source = "./modules/identity"
providers = {
aws.target = aws.target
}
}
output "selected_account" {
value = module.identity.account_id
}
В modules/identity/main.tf опишите, какое имя конфигурации ожидается внутри модуля:
terraform {
required_providers {
aws = {
source = "hashicorp/aws"
configuration_aliases = [aws.target]
}
}
}
data "aws_caller_identity" "current" {
provider = aws.target
}
output "account_id" {
value = data.aws_caller_identity.current.account_id
}
После init выполните plan своего инструмента. Selected_account должен соответствовать training-target. Data source читает идентичность подключения, а не создаёт облачный объект. Сверьте ожидаемый аккаунт с независимым известным значением, не ограничиваясь тем, что команда вернула любой номер.
Левая и правая стороны providers
В providers = { aws.target = aws.target } слева имя внутри дочернего модуля, справа конфигурация родителя. Они совпадают в примере для простоты, но могли называться aws.destination и aws.secondary. Configuration_aliases сообщает о допустимом имени в интерфейсе модуля; оно не создаёт credentials и не выбирает регион.
Если модулю нужна только одна конфигурация, можно оставить в нём обычный provider aws без alias и передать providers = { aws = aws.target }. Тогда configuration_aliases не требуется. Выберите один понятный интерфейс и согласуйте все ресурсы с ним.
Что наследуется автоматически
Конфигурации без alias могут наследоваться дочерними модулями по обычным правилам. Aliased configurations надо передавать явно. Если в корне объявлены только aliases, не рассчитывайте на заполненный default provider: неявная конфигурация без нужных параметров может привести к ошибке или к выбору окружения из внешних переменных.
Source requirements каждый модуль объявляет самостоятельно. Наличие required_providers в корне не является интерфейсом дочернего кода. Для Terraform и OpenTofu базовые правила передачи совпадают, но выбранные source registry и версии provider должны быть согласованы отдельно.
Изменение provider у существующего модуля
Для уже управляемых ресурсов смена конфигурации подключения требует более осторожного плана, чем этот read-only пример. Сначала установите, где физически находятся объекты из state. Если новый alias указывает на другой аккаунт или регион, чтение прежних ID может перестать находить ресурсы. Это не повод немедленно соглашаться на создание замен.
Проверьте terraform providers или tofu providers, конечные настройки профиля и план конкретных адресов. Завершённое исправление подтверждается ожидаемой identity и отсутствием неожиданных create/delete. Явная передача alias делает выбор видимым в вызове модуля, но правильность самого подключения всё равно нужно проверить фактом.
Ещё по теме
- CI считает terraform plan ошибкой при найденных изменениях: detailed-exitcode
- Lock-файл Terraform и OpenTofu: фиксируем версии и проверяем обновление провайдера
Продолжить изучение
Хотите управлять инфраструктурой через код и понимать последствия изменений? Plan, state, модули и работа с существующими ресурсами — темы программы «Terraform и OpenTofu: инфраструктура как код».
Продолжить на практике
- Terraform и OpenTofu: инфраструктура как код ↗
Описывайте инфраструктуру в коде, проверяйте изменения до применения и работайте со state без сюрпризов. HCL, модули, remote state, импорт, CI и различия Terraform/OpenTofu — на воспроизводимом учебном окружении.
