DK
ну или применять террагрант, который сам умеет это все делать
Имхо риск не стоит свеч. Может я и не прав, но что случится если в terragrunt залезет баг и путь стейта сменится...
Size: a a a
2020 March 08
VT
Имхо риск не стоит свеч. Может я и не прав, но что случится если в terragrunt залезет баг и путь стейта сменится...
Риска нет.
Если кажется что есть - прошу объяснить подробно и в деталях пожалуйста.
Может я что то не понимаю. 😉
Если кажется что есть - прошу объяснить подробно и в деталях пожалуйста.
Может я что то не понимаю. 😉
i
Я выше описал почему terragrunt не збс
i
И не сможет в некоторых вещах в идеологии тф
i
что собственно и не надо
VT
что собственно и не надо
Можно более подробно и детально?
i
Можно более подробно и детально?
инструменту не нужно делать то, для чего он не сделан, что тут подробнее
i
s3 и dynamodb
i
юзеры
VT
юзеры
Ещё подробнее и в одно сообщение.
Спасибо.
Спасибо.
i
например создание пользователей с ролями для работы тф
VT
например создание пользователей с ролями для работы тф
Это делается первый раз при создании аккаунта. Разными средствами на любой вкус. В aws - при создании аккаунта например создавать роли, прописывать sso - можно используя cfn, можно ansible, boto3, API - что угодно.
И только потом уже мы запускаем терраформ/terragrunt в этом аккаунте, используя разрешенную роль.
Бакет и табличку для стейта можно конечно уже заранее создать и настроить как нужно - а можно и потом доверить это созданной роли.
Вот тут и удобна функциональность terragrunt, который может создать нам бакет. Это просто одна удобная, очень мелкая функциольность. Конечно можно использовать и что то другое.
Не забывайте про проблему курицы и яйца.
И только потом уже мы запускаем терраформ/terragrunt в этом аккаунте, используя разрешенную роль.
Бакет и табличку для стейта можно конечно уже заранее создать и настроить как нужно - а можно и потом доверить это созданной роли.
Вот тут и удобна функциональность terragrunt, который может создать нам бакет. Это просто одна удобная, очень мелкая функциольность. Конечно можно использовать и что то другое.
Не забывайте про проблему курицы и яйца.
i
Это делается первый раз при создании аккаунта. Разными средствами на любой вкус. В aws - при создании аккаунта например создавать роли, прописывать sso - можно используя cfn, можно ansible, boto3, API - что угодно.
И только потом уже мы запускаем терраформ/terragrunt в этом аккаунте, используя разрешенную роль.
Бакет и табличку для стейта можно конечно уже заранее создать и настроить как нужно - а можно и потом доверить это созданной роли.
Вот тут и удобна функциональность terragrunt, который может создать нам бакет. Это просто одна удобная, очень мелкая функциольность. Конечно можно использовать и что то другое.
Не забывайте про проблему курицы и яйца.
И только потом уже мы запускаем терраформ/terragrunt в этом аккаунте, используя разрешенную роль.
Бакет и табличку для стейта можно конечно уже заранее создать и настроить как нужно - а можно и потом доверить это созданной роли.
Вот тут и удобна функциональность terragrunt, который может создать нам бакет. Это просто одна удобная, очень мелкая функциольность. Конечно можно использовать и что то другое.
Не забывайте про проблему курицы и яйца.
один аккаунт 5 проектов на нем
i
root юзер вообще должен использоваться один раз - чтобы создать другого админ юзера
VT
root юзер вообще должен использоваться один раз - чтобы создать другого админ юзера
Это уже aws основы. Terraform здесь не при чем.
первое предупреждение.
первое предупреждение.
I
подскажите, а так можно делать?
resource "aws_instance" "${var.instance_name}"2020 March 09
N
нельзя так делать, даже терраформ на это ругается
I
да, уже проверил)
N
Ааа. У нас flavor удалять не принято
там не только про удаление, там написано "что любое изменение включая удаление flavor влечет ... проблемы"
НС
там не только про удаление, там написано "что любое изменение включая удаление flavor влечет ... проблемы"
Потому что все эти операции меняют uuid