☰

Развертывание на нескольких аккаунтах с помощью Terraform?

tag-icon • tag-icon amazon-web-services terraform
Развертывание на нескольких аккаунтах с помощью Terraform?

Я искал способ Terraform, чтобы иметь возможность развернуться на нескольких аккаунтах AWS одновременно в Terraform, и пока безуспешно. У AWS есть концепция сделать это с помощью Stacks, но я не уверен, есть ли способ сделать это в TF? Если да, то какие могут быть решения?

Подробнее о решении AWS можно прочитать здесь.https://aws.amazon.com/blogs/mt/supercharge-multi-account-management-with-aws-cloudformation/

решение1

Есть две проблемы, которые необходимо преодолеть, чтобы использовать одни и те же конфигурации terraform в нескольких аккаунтах AWS. Первая заключается в том, что вам нужно будет использовать разные файлы состояний для каждого аккаунта. Вторая заключается в том, что поставщик AWS будет использовать правильный профиль/учетные данные для нужного аккаунта.

Использование отдельного файла состояния для каждой учетной записи

На высоком уровне terraform работает просто, создавая график ресурсов зависимости из предоставленных файлов конфигурации terraform (*.tf); и сравнивает их с файлом состояния. Файл состояния может быть как локальным ( terraform.tfstate), так и удаленнымбэкэнд; общий удаленный бэкэнд AWS — этос3.

Даже если вы укажете поставщику AWS использовать отдельные аккаунты через переменные (подробнее об этом ниже), если оба аккаунта используют один и тот же бэкэнд, terraform будет постоянно падать. Это произойдет, потому что при переключении с одного аккаунта на другой идентификаторы AWS ресурсов не будут совпадать, и/или в файле состояния будут указаны ресурсы, которых нет в аккаунте, который в данный момент просматривает terraform.

Простой способ обойти это — использоватьрабочие пространства. Рабочие пространства позволяют использовать различные файлы состояний без указания различных внутренних ключей. Использование рабочих пространств очень просто. Если у вас есть простой блок terraform, такой как:

terraform {
    backend "s3" {
       bucket = "aws_bucket"
       key    = "terraform.tfstate"
       region = "us-east-1"
    }
}

Вы можете создавать новые рабочие пространства с помощью terraform workspace new <workspace-name>. Таким образом, вы можете создать рабочее пространство для обеих своих учетных записей, используя последовательность, например:

terraform workspace new account-1
terraform workspace new account-2

И вы можете переключить свое текущее рабочее пространство, используя terraform workspace select:

terraform workspace select account-1

Настройка поставщика AWS для поддержки рабочей области

Помимо использования отдельных файлов состояния. Вам также потребуется указать различные учетные данные AWS (т. е. ключи доступа) для каждой необходимой учетной записи. Учетные данные AWS указываются с помощьюпровайдеры. В этом случае мы, очевидно, используемПоставщик AWS.. По сути, вы хотите использоватьинтерполяцияв блоке ресурсов поставщика AWS, поэтому при переключении рабочих пространств terraform будет использовать правильные учетные данные. Предполагая, что у вас есть файл учетных данных aws, настроенный с отдельным профилем для каждой учетной записи:

[account-1]
aws_access_key_id=AKIAIOSFODNN7EXAMPLE
aws_secret_access_key=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

[account-2]
aws_access_key_id=AKIAI44QH8DHBEXAMPLE
aws_secret_access_key=je7MtGbClwBF/2Zp9Utk/h3yCo8nvbEXAMPLEKEY

Затем вы можете просто написать свой блок провайдера aws следующим образом:

provider "aws" {
    region  = "us-east-1"
    profile = "${terraform.workspace}"
}

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

Альтернативные методы

Это далеко не единственный способ достичь этого. Вы можете построитьмодули; и затем иметь разные каталоги, которые вызывают модуль с разными поставщиками AWS и указанными файлами состояния. У каждого метода есть свои плюсы и минусы.

Метод рабочего пространства — это то, как вы бы это сделали с одним каталогом, и вы бы использовали точно такие же файлы конфигурации Terraform, как написано.

Модули потребуют отдельных файлов конфигурации, которые, по крайней мере, вызывают модули и указывают поставщиков и бэкэнды. Модули будут иметь большой смысл, если вы собираетесь использовать несколько учетных записей, несколько регионов и несколько сред. Например, если вы собираетесь запускать в двух регионах для каждой учетной записи и двух разных средах (промежуточная и производственная). Модули имеют смысл здесь, потому что они обеспечивают гибкость с использованием аргументов, таких как количество (возможно, промежуточная запустит меньшее количество экземпляров и т. д.).

решение2

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

provider "aws" {
  version = "~> 2.18"
  profile = "second_account"
}

terraform {
  backend "s3" {
    encrypt = true
    bucket  = "shared_bucket"
    region  = "us-east-1"
    key     = "state"
    profile = "first_shared_account"
  }

  required_version = "~> 0.12.7"
}

Обратите внимание на разные профили, указанные как для конфигурации поставщика, так и для конфигурации бэкэнда. Вы можете иметь кучу разных профилей, пока каждый из них изолирован через собственное рабочее пространство

aws configure --profile third_account
terraform workspace new third_account
terraform workspace select third_account

Связанный контент