по-моему это не логично

ты пытался прочитать что вроде этого?
https://blog.gruntwork.io/why-we-use-terraform-and-not-chef-puppet-ansible-saltstack-or-cloudformation-7989dad2865c
Там есть пример, самые essentials как работает терраформ

представь, у тебя код который генерирует наполнение базы данных
сгенерированную базу данных ты тоже будешь хранить в гите?

очень хороший пример 🙂

Нет, но я буду хранить код, который всегда сможет воспроизвести все необходимые изменения в базе.

К слову я не собирался начинать холивар на тему терраформа, думаю хранение стейта терраформа о созданной инфре в S3 можно сравнить с хранением стейта куба в etcd.

Но даже если взять к примеру тот же куб, то имея деларативно описанный Deployment, тебе не приходится хранить все созданные им ReplicaSet и Pod в репозитории, ты хранишь только конкретный Deployment, исполнение которого всегда приведёт кластер к нужному состоянию.

просто у него немного другой подход этот подход мне нравится меньше, но с этим можно жить.

> думаю хранение стейта терраформа о созданной инфре в S3 можно сравнить с хранением стейта куба в etcd.

более того, терраформ тоже может хранить стейт в etcd

> то имея деларативно описанный Deployment, тебе не приходится хранить все созданные им ReplicaSet и Pod

верно, вот например я храню google_compute_instance_template, google_compute_region_instance_group_manager, но не сами инстансы

как по мне так подход 1-в-1

Но ты же можешь положить одинаковый Deployment в кубернетес, он не создаст новых подов, он просто обновит старый Deployment.

можешь, потому что в кубере неймспейс+имя = id ресурса

ок...а как же pv? 😊
если ты хочешь использовать уже существующий ebs volume например?

Ну ты не должен создавать PV вручную

Ты создаёшь PVC, если его не существует, то он создаётся, если существует, то ничего не меняется

PV - хорошая попытка, но нет)

ты наверное должен где-то там ручками указать id волюма

это не стандартный юзкейс, PV были сделаны для того чтобы менеджиться провижионером а не хьюманами, на то они и в Cluster Scope, а не Namespaced

@kvaps state полезен, когда:
* У тебя есть ресурсы, которыми ты не управляешь. Тогда ты можешь отличить "твой" ec2 от тех, которые трогать не надо. В случае ансибла тебе придётся городить искусственный "state" в виде меток, или запоминать id куда-нибудь. При этом код, который об этом заботится не несёт смысловой нагрузки, он описывает не желаемый результат, а как его отличить.
* есть сторонний проект, который зависит от результата. Стейт позволяет взять выхлоп твоего проекта и использовать его. Например, один стек у тебя разворачивает базу, а второй приложение,и второй стек может взять случайно сгенерированный пароль базы из стейта первого. В ансибле тебе для этого опять же придётся стейт эмулировать

В общем, ансиблу хорошо там, где он один и ему не с кем конфликтовать

А такие инструменты как cloud formation, terraform, которые хранят состояние, спокойно сосуществуют

И кстати, ансибл тоже генерит стейт, например, когда создаёт ресурс и далее в том же коде его передаёт другим ролям. Просто он его после выполнения плейбука отбрасывает

Стейт очень хорошо подходит для тех ресурсов, которые содержат случайные данные. Если инфраструктурный код создаёт ресурс со случайными данными, как без состояния понять, что ресурс не поменялся с момента последнего запуска? Никак.