Евгений

Vitaly Karasik

Евгений, я хочу это сделать Terraform

Terraform - инструмент для провижининга инфраструктуры. tf управляет ресурсами инфраструктуры и хранит их состояние в стейте для того чтобы просчитывать изменения при изменении параметров или кода
Пользователи на ваших серверах - это уже не инфраструктура, они никак не фигурируют (и не могут без костылей) в стейте tf, а значит именно управлять ими tf не будет.
Вы, конечно, можете использовать костыль в виде null resource запускающего просто sh\posh\cmd скрипт, который откуда то возьмет данные для подключения к вашим серверам, данные о пользователях которых надо создать
Терраформ этим ресурсом по сути не управляет, он только выполнит\перевыполнит(по триггерам на состояние других ресурсов в tf) ваш скрипт. О небезопасности хранения учетных данных таким образом думаю не стоит напоминать.
Аналогично вместо скрипта может быть ансибл\шеф (возможно через провайдер) или что-то другое так же запускаемое терраформом (но стейт созданных "ресурсов"=пользователей хранить будет опять же не терраформ, а значит об управлении речь не идет)
Не надо плоскогубцами забивать гвозди. Да, в некоторых случаях это возможно сделать, но это создает больше проблем чем решает
Кстати, намек как плоскогубцами забить гвоздь содержится в описании null_resource - ссылка выше.

ключ - это имя объекта в s3 бакете, контент которого соответствует файлу terraform.tfstate лежащему сейчас локально.
Если у вас простой код (как на скриншоте) - можете спокойно называть ключ "terraform.tfstate"
Если вы в одном бакете храните ключи разных частей одной инфраструктуры - сделайте логическое разделение "ec2/terraform.tfstate", "vpc/terraform.tfstate"
вообще можете назвать хоть "123" - это просто название ключа, где терраформ будет искать стейт в будущем. Единственное ограничение - имя ключа должно соответствовать правилам именования объектов в S3

Потерять можно все при любом действии и любым продуктом.
Терраформ просто позволяет сделать это .. красиво и очень удобно, если вы хреново его спланировали.
Правило 1: используйте автоприменение только в тех местах где не жалко или где вы железобетонно уверены(и берете риски на себя)
Правило 2: валидируйте план. Хотя бы глазами
Вообще, есть у некоторых людей практика делать план в файл, валидировать его какой то внешней логикой, и при успешной валидации применять план из файла, не просчитывая его заново (он делается при каждом апплае) с автоподтверждением. Мне не нравится, да и терраформ честно предупреждает что на момент реального применения ситуация может отличаться и менять придется совсем другие элементы.
Правило 3: разноси элементы по логическим слоям, чтобы уменьшить зону поражения при гибельном апплае. Например настройки сети а одной папке со своим стейтом, запуск приложения - в другой. И связывайте через ремоут стейт. Главное соблюдать меру, чтобы каждую, скажем , security group в aws не создавать в отдельных слоях.
Правило 4: используйте модули, если применение логической группы ресурсов используется более одного раза. Тут тоже не стоит плодить модули на каждый ресурс и подходить разумно.
Правило 5: тестируйте изменения! (Используя одни и те же модули для стейжа и прода). Логично предположить что если вы снесли стейж то и прод снесется.
Правило 6: используйте vcs для работы с кодом терраформ (для того чтобы откатывать код для восстановления убитого стейжа например)
Правило 7: используйте lifecycle политики Prevent destroy на ресурсах, чтобы запрещать из убиение
Помидор 7.1: используйте ignore changes там где это нужно
Правило 8: используйте правильный инструмент для того что вы хотите сделать. Терраформ умеет много чего, но конфигурейшн менеджер он не заменит, хотя по функциям они чуть да пересекаются.

В принципе, если продолжать я могу до штук 20 дойти полезных советов, но на 90% мои правила, по сути - используйте для работы с кодом терраформ те же правила что и для работы с любым другим кодом - снимете 70% проблем. Остальные будут связаны с особенностью работы терраформ и радиусом кривизны рук автора терраформ кода.

P.S. пишу на ходу в метро, орфографию и пунктуацию правит т9. Спрашивайте, вдруг заметите какой нибудь термин, который я писать не собирался :D

https://docs.aws.amazon.com/en_us/cli/latest/userg...
Вы получаете креды.
Вам нужно положить их в соответствующие переменные окружения.
Далее следующая команда AWS CLI будет использовать их.

Saboteur неплохо ответил(что не отменяет того что все остальные ответившие тоже правы)
Девопс - это практики. Это не набор инструментов( инструменты используются на определенных этапах, реализация которых необходима для приближения к идеалу), однако определенные необходимые инструменты опять же есть.
Про девопс можно прочитать очень много информации, но я, как админ (win-админ :D) вижу ситуацию для вас, как и любого, с опсовой основой, примерно так:

1. Жирным вы выделили вопросы который для вас вот конкретно сейчас не играют ни малейшей роли. Дмитрий Шицков и Saboteur написали почему: зависит от проекта.
   
2. Завет любого ops-а: автоматизируй всё что можно
   Если выбор между configuration management (chef, ansible, puppet и тд) и скриптами - то лучше первое. Хотя и тут можно поспорить, у меня в проекте chef-ом автоматизированное не очень-то используется на последнем этапе доставки в прод, поскольку мы все равно запечатываем машину и запускаем в AWS с asg без пост-конфигурации. Тут можно до посинения спорить хорошо это или нет, но скрипты в идеальном мире проигрывают DSL
   
3. Вы пишете код для автоматизации
   Вам понадобится git (который тянет за собой git-хостинг: bitbucket, github, gitlab и тп.) и навыки правильной работы с гитом. Для отслеживания и планирования изменений - понадобится какой-нибудь таск трекер (jira, таск трекер встроенный в gitlab, что-то другое).
   
4. Инфраструктура как код
   Автоматизируй всё означает автоматизацию развертывания инфраструктуры
   Здесь уже вступают в силу особенности вашего окружения - в облаках вы скорее всего захочете использовать terraform или, например, CloudFormation в AWS - встроенное средство оркестрации, или же будете сразу все запускать в контейнерах - docker , kubernetes используя соответствующие инструменты.
   
5. Мониторинг
   Без правильного и подходящего вашему продукту мониторинга(+логирования) жить нельзя. И это было еще до DevOps тренда - это классика администрирования. Здесь ничего не посоветую, с Zabbix-ом сам не ужился, переехал на influx и прилегающие (TICK stack). Для логирования - graylog, ELK. В некоторых частях используется prometheus который в том числе и для кубера удобен. В общем - с чем подружитесь.
   

Это только то, что вы уже должны знать и вам легче будет к ним приступить.
Будете хорошо ориентироваться (не только знать, но и выбрать правильные инструменты, уметь построить правильный пайплайн) - вас с руками оторвут, несмотря на то что вы можете быть слабы в других областях (тестирование, билд и проч.)

Для примерного осознания всего цикла можно посмотреть на (картинка относительно рандомная,таких много, два года назад я ориентировался по другой, с более подходящим мне списком инструментов, но найти не могу =( )


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

1. AMI
Все плюсы и минусы вам расписали.
2. S3 bucket
Поддерживает шифрование, в том числе и клиентским(вашим) ключом - вы можете свободно положить в приватный бакет всю необходимую секретную информацию и простым aws s3 cp в юзердате всё получить.
Обновление сертификатов и конфигов, соответственно, просто перезаливкой в бакет и пересозданием инстансов ASG
Это вместо некоего веб хранилища.
3. SSM parameters
Можно перед развертыванием ASG инициализировать параметры вашего окружения, вплоть до сертификатов в зашифрованных ключах SSM и при развертывании забирать значения из SSM
Более сложно чем бакет, поскольку предназначается для кросс-датацентрового обмена секретами.

В вашем случае наилучшим решением будет s3 бакет, а самым простым и быстрым в реализации - AMI
Для того чтоюы не передавать access key и secret key для работы с амазоном в юзердате - используйте aws instance profile с нужными инстансу политиками.