Должен ли я передавать файлы .tfstate на Git?

Я немного озадачен вопросом о том, следует ли передавать файлы .tfstate на Git или нет. Документация Terraform гласит:

Terraform также поместил некоторое состояние в файл terraform.tfstate по умолчанию. Этот файл состояния чрезвычайно важен; он сопоставляет различные метаданные ресурсов с фактическими идентификаторами ресурсов, чтобы Terraform знал, что он управляет. Этот файл должен быть сохранен и распространен среди всех, кто может использовать Terraform. Мы рекомендуем просто ввести его в управление версиями, поскольку он обычно не слишком большой.

Теперь, с другой стороны, принятый и поддержанный ответ на Рекомендации по использованию Terraform гласит:

Конфигурация Terraform может использоваться для обеспечения множества ящиков в разных инфраструктурах, каждая из которых может иметь другое состояние. Поскольку это может также запускаться несколькими людьми, это состояние должно находиться в централизованном месте (например, S3), но не git.

(Подчеркивание оригинальным автором, а не мной)

Кто прав, и если да, то почему?

Ответ 1

TL; DR:

Важный! Хранение в системе контроля версий может привести к появлению потенциально конфиденциальных данных и рисков, при которых Terraform будет работать со старой версией состояния. Не делай этого.

Terraform больше не рекомендует сохранять состояние в системе контроля версий. Ваши "хорошие" варианты являются удаленными или локальными.

Удаленное состояние дает значительные преимущества по сравнению с локальным и хранением в системе контроля версий. Подробная информация о них ниже.

Оригинальный ответ:

Евгений, ответ хороший. Эта проблема теперь несколько менее противоречива, так как Terraform обновил свои документы, заявив:

Terraform также помещает некоторое состояние в файл terraform.tfstate по умолчанию. Этот файл состояния чрезвычайно важен; он сопоставляет различные метаданные ресурса с фактическими идентификаторами ресурса, чтобы Terraform знал, чем он управляет. Этот файл должен быть сохранен и разослан всем, кто может запустить Terraform. Обычно рекомендуется настроить удаленное состояние при работе с Terraform. Это будет означать, что любые потенциальные секреты, хранящиеся в файле состояния, не будут проверяться в системе контроля версий.

Таким образом, больше нет разногласий между установленной передовой практикой и официальными рекомендациями.

Обновление 2019-05-17

В самой последней версии документов это было изменено, чтобы сказать:

... Это состояние хранится по умолчанию в локальном файле с именем "terraform.tfstate", но оно также может храниться удаленно, что лучше работает в командной среде....

Я не ожидаю, что совет когда-либо вернется к исходному контролю, являющемуся предпочтительным методом хранения состояния.

Несмотря на приведенную выше цитату из документации, удаленное состояние по-прежнему выгодно как сольный разработчик

Удаленное состояние позволяет индивидуальному разработчику:

Работайте/запускайте код Terraform с нескольких устройств
Простое резервное копирование и защита от потери файла состояния, в зависимости от выбранного бэкэнда
Разделить разделы их архитектуры через выходы
Автоматически шифровать файл состояния в состоянии покоя, в зависимости от выбранного бэкэнда

Ответ 2

Есть несколько причин не хранить ваши файлы .tfstate в Git:

Скорее всего, вы забудете зафиксировать и отправить изменения после запуска terraform apply, так что у ваших товарищей по команде будут .tfstate файлы .tfstate. Кроме того, без какой-либо блокировки этих файлов состояния, если два члена команды одновременно запускают Terraform для одних и тех же файлов .tfstate, вы можете перезаписать изменения друг друга. Вы можете решить обе проблемы: а) хранить файлы .tfstate в .tfstate S3 с помощью удаленного состояния Terraform, которое будет автоматически выдвигать/извлекать файлы .tfstate каждый раз, когда вы запускаете terraform apply и б) использовать такой инструмент, как terragrunt, чтобы обеспечить блокировку для ваши файлы .tfstate.
Файлы .tfstate могут содержать секреты. Например, если вы используете ресурс aws_db_instance, вам необходимо указать пароль базы данных, и Terraform сохранит его в виде открытого текста в файле .tfstate. Это плохая практика от имени Terraform, и хранение незашифрованных секретов в системе контроля версий только усугубляет ситуацию. По крайней мере, если вы храните файлы .tfstate на S3, вы можете включить шифрование в состоянии покоя (SSL обеспечивает шифрование во время движения) и настроить политики IAM для ограничения доступа к ним. Это очень далеко от идеала, и мы должны увидеть, будет ли когда-нибудь исправлена открытая тема, обсуждающая эту проблему.

Для получения дополнительной информации, проверьте Как управлять состоянием Terraform и Terraform: Up & Running.

Ответ 3

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

Кроме того, в файлах состояний вещи могут быстро изменяться как результат для выполняемых вещей, а не на самом деле в коде, что делает все это довольно неудобным.

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

Я бы сказал, что S3 - это, вероятно, лучшее место, где вы можете сейчас их поместить. Это в значительной степени бесплатное, долговечность отличная, так же как и доступность, там очень хорошая поддержка для него в Terraform, используя ресурс remote state. И, вероятно, самое главное, вам нужно создать ведро S3 для начала работы. Необходимо создать кластер Consul или etcd сначала без Terraform (в противном случае у вас есть проблема с цыпленком и яйцом, где вы храните состояние для их создания?) - это немного боль, даже если вы намерены использовать любой из этих продуктов.

Очевидно, что если вы используете OpenStack, то Swift должен сделать хорошую альтернативу (хотя я ее не использовал). Я также не использовал Hashicorp Atlas, но если вы с удовольствием заплатите за эту услугу, это также будет полезно.

Ответ 4

Я вижу преимущество в том, чтобы делиться terraform.tfstate другими способами, а не Git.

Например: S3, Dropbox и т.д. (С включенным контролем версий)

Тогда можно будет вернуться к предыдущему состоянию инфраструктуры.

Например, вы откатываете репозиторий из коммита B, обратно в коммит A. Если terraform.tfstate не изменился - terraform подумает, как откатить все, что вы добавили во время коммита B. И откат будет легким.

В случае, если terraform.tfstate также откатился до фиксации A, то terraform будет думать, что terraform.tfstate синхронизирован с требуемой конфигурацией, и не будет применять откат к вашей инфраструктуре.