Можно ли связать рабочую область terraform с учетной записью aws

Если у вас есть две учетные записи AWS, одна для разработки и одна для работы (например), я знаю, что можно использовать рабочие области terraform для управления состоянием каждой среды.

Однако, если я переключу рабочее пространство с «dev» на «live», есть ли способ указать terraform, что теперь он должен применять состояние к реальной учетной записи, а не к тестовой?

Один из способов, о котором я думал, который подвержен ошибкам, - это менять мой файл secret.auto.tfvars каждый раз, когда я переключаю рабочее пространство, поскольку я предполагаю, что при работе с другим ключом доступа (тем, который принадлежит «живой» учетной записи) поставщик AWS затем будет применять на этот счет. Однако было бы очень легко поменять местами рабочую область и иметь неправильные учетные данные, что приведет к запуску изменений в неправильной среде.

Я ищу способ почти связать рабочее пространство с идентификатором учетной записи в AWS.

Я нашел этот https://github.com/hashicorp/terraform/issues/13700, но он относится к устаревшей команде env, этот комментарий выглядел несколько многообещающим, в частности

Обновлять

Я нашел некоторую информацию на GitHub, где я оставил этот комментарий в качестве ответа на предыдущий комментарий, который рекомендовал рассматривать модули вместо рабочих пространств и фактически указывает на то, что рабочие пространства не очень подходят для этой задачи. Если кто-нибудь может предоставить информацию о том, как модули могут быть использованы для решения этой проблемы одновременного обслуживания нескольких версий «одной и той же» инфраструктуры, я бы хотел увидеть, как это улучшит концепцию рабочего пространства.

6
0
1 937
2
Перейти к ответу Данный вопрос помечен как решенный

Ответы 2

Рабочие области Terraform содержат информацию о состоянии. Они подключаются к учетным записям пользователей в зависимости от способа использования AWS_ACCESS_KEY_ID и AWS_SECRET_ACCESS_KEY в среде. Чтобы ссылка на сайт любой заданной рабочей области в учетной записи AWS, они должны были бы хранить учетные данные пользователя каким-то образом, чего они по понятным причинам не делают. Поэтому я не ожидал, что рабочие области когда-либо будут напрямую поддерживать это.

Но чтобы почти связать рабочее пространство с учетной записью, вам просто нужно автоматически переключать AWS_ACCESS_KEY_ID и AWS_SECRET_ACCESS_KEY каждый раз, когда переключается рабочее пространство. Вы можете сделать это, написав оболочку для terraform, которая:

  1. Передает все команды на настоящий terraform, если не находит workspace select в командной строке.

  2. Обнаружив workspace select в командной строке, он разбирает имя рабочего пространства.

  3. Экспортируйте AWS_ACCESS_KEY_ID и AWS_SECRET_ACCESS_KEY для Аккаунт AWS, который вы хотите ссылка на сайт в рабочую область

  4. Закончите, передав команду рабочей области на настоящий terraform.

Это будет загружать правильные учетные данные каждый раз

terraform workspace select <WORKSPACE>

было использовано

Ответ принят как подходящий

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

Это один (из многих) способов структурировать каталоги; вы даже можете поместить модули в их собственное репозиторий Git, но я постараюсь не слишком путать вещи. В этом примере у вас есть простое приложение с 1 экземпляром EC2 и 1 базой данных RDS. Вы пишете любой код Terraform, который вам нужен, в подкаталогах modules/*/, не забывая параметризовать все атрибуты, которые различаются в разных средах.

Тогда в ваших каталогах dev/ и live/main.tf должен быть одинаковым, в то время как provider.tf и terraform.tfvars отражают информацию, специфичную для среды. main.tf будет вызывать модули и передавать параметры, специфичные для env.

modules/
|-- ec2_instance/
|-- rds_db/
dev/
|-- main.tf             # --> uses the 2 modules
|-- provider.tf         # --> has info about dev AWS account
|-- terraform.tfvars    # --> has dev-specific values
live/
|-- main.tf             # --> uses the 2 modules
|-- provider.tf         # --> has info about live/prod AWS account
|-- terraform.tfvars    # --> has prod-specific values

Когда вам нужно спланировать / применить любой env, вы переходите в соответствующий каталог и запускаете там свои команды TF.


Что касается того, почему это предпочтительнее использования Terraform Workspaces, Документы TF хорошо объясняет это:

In particular, organizations commonly want to create a strong separation between multiple deployments of the same infrastructure serving different development stages (e.g. staging vs. production) or different internal teams. In this case, the backend used for each deployment often belongs to that deployment, with different credentials and access controls. Named workspaces are not a suitable isolation mechanism for this scenario.

Instead, use one or more re-usable modules to represent the common elements, and then represent each instance as a separate configuration that instantiates those common elements in the context of a different backend. In that case, the root module of each configuration will consist only of a backend configuration and a small number of module blocks whose arguments describe any small differences between the deployments.

BTW> Terraform просто изменил подкоманду env на workspace, когда решили, что «env» слишком запутывает.

Надеюсь это поможет!

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

ydaetskcoR 15.08.2018 08:48

Спасибо @ydaetskcoR. Добавил раздел.

KJH 15.08.2018 14:50

@kjh В этой модели terraform init выполняется в каждом подкаталоге отдельно (например, dev/ и live/), поскольку я предполагаю, что состояние серверной части необходимо синхронизировать для каждого каталога (что относится к другому бэкэнду, например, уникальному ведру s3 в каждой учетной записи)

David 20.08.2018 15:27

@DavidGoate - ага! Кстати, не обязательно должно быть уникальное ведро S3; может быть просто ключом различия («папкой») в том же ведре.

KJH 20.08.2018 15:39

Другие вопросы по теме