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

Question

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

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

Теперь, с другой стороны, принятый и одобренный ответ на Лучшие практики при использовании Terraform гласит:

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

(Акцент сделан автором, а не мной)

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

Answer 1

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

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

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

Answer 2

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

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

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

Answer 3

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

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

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

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

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

Answer 4

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

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

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

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

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