синтаксисы это понятно, но как мог мой терраформ, стейт который только локально на моем пк изменить существующий S3?

в общем случае зависит от API используемого терраформ-провайдером, а не от самого терраформа
если API может принять несколько запросов на создание ресурса и не вернуть ошибку, то терраформ может по-простому этими ресурсами начать управлять

а как это реализовано в твоём конкретном случае лучше спросить в документации амазона

Кажется вот:
https://github.com/terraform-providers/terraform-provider-aws/issues/9223

Да, спасибо

добрый вечер. Подскажите, а в planfile какие-то секреты хранятся? Безопасно ли хранить его как артефакт в пайплайне gitlab? Или лучше через cache?

сходу я не нагрепал вроде ничего криминального, но кто его знает :)

От кого защищаешься?

А есть у кого посмотреть стиль деплоя ECS тасков? организация, итд

допустим, если task definition в тераформе, как деплоить новый тег? передавать его через vars?

...или засунуть их это в json файл... но тогда как управлять тегом... хз

у нас через jsonencode функцию
https://gist.github.com/dizer/835d2d6b129e30feb20b32023a34b150

Неплохо, да

А локально какие-то есть контейнеры?

Где локально?

На десктопах разработчиков, в смысле

А что вы хотите делать терраформом на десктопах разрабов? Не очень понял вопрос.

Не. Терраформ тут частично при чем. Смотрите. Есть набор сервисов/тасков ECS, скажем 10-20 штук. По одной из парадигм, необходимо делать локальнее тестирование и разработку. Как это делается в вашем случае?

Зачем разрабатывать в контейнерах? Это контрпродуктивно. Проблемы с дебагерами, памятью и дисковой на ровном месте.
А для тестов у нас так: собирается два образа из одной ревизии кода (через базовые образы). Один продовый, второй на основе первого с тестами. И вот второй тестируется в CI. Если все хорошо, то первый можно попытаться задеплоить.
Тут можно возразить, что деплоится и тестируется не одно и то же, но тащить в прод образ с тестами не хочется.

Разрабатывать в IDE, понятно. Но остальное окружение в контейнерах