Terraform: как перенести состояние между проектами? - PullRequest
0 голосов
/ 17 мая 2018

Каков наименее болезненный способ переноса состояния ресурсов из одного проекта (т. Е. Перемещения вызова модуля) в другой, особенно при использовании удаленного хранилища состояний?Хотя рефакторинг относительно прост в одном и том же файле состояний (т. Е. Взять этот ресурс и переместить его в субмодуль или наоборот), я не вижу альтернативы операции JSON для рефакторинга в разные файлы состояний, особенно если мы используем удаленный(S3) состояние (т. Е. Взять этот подмодуль и переместить его в другой проект).

Ответы [ 3 ]

0 голосов
/ 24 июля 2018

Наименее болезненный способ, который я нашел, - вытащить оба удаленных состояния локально, переместить модули / ресурсы между ними, а затем подтолкнуть вверх.Также помните, что если вы перемещаете модуль, не перемещайте отдельные ресурсы;переместить весь модуль.

Например:

cd dirA
terraform state pull > ../dirA.tfstate

cd ../dirB
terraform state pull > ../dirB.tfstate

terraform state mv -state=../dirA.tfstate -state-out=../dirB.tfstate module.foo module.foo

terraform state push ../dirB.tfstate

# verify state was moved
terraform state list | grep foo

cd ../dirA
terraform state push ../dirA.state

К сожалению, terraform state mv command не поддерживает указание двух удаленных бэкэндов , так что это самый простой способ, который я нашелпереместить состояние между несколькими пультами.

0 голосов
/ 29 июня 2019

Как упомянуто в соответствующем Terraform Q -> Рекомендации по использованию Terraform

  1. Работать с меньшим количеством ресурсов проще и быстрее:
    • Cmds terraform plan и terraform применяют оба вызова API для облачных вычислений для проверки состояния ресурсов.
    • Если вся ваша инфраструктура объединена в одну композицию, это может занять много минут (даже если выиметь несколько файлов в одной папке).

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


Возможные процедуры переноса состояний Terrform между проектами / службами:

Пример сценария:

Предположим, у нас есть папка с именемcommon со всеми нашими .tf файлами для определенного проекта, и мы решили разделить (переместить) наши .tf Terraform ресурсы в новую папку проекта с именем security.поэтому теперь нам нужно переместить некоторые ресурсы из common папки проекта в security.

Случай 1:

Если папка security по-прежнему не существует (что является лучшим сценарием).

  1. Резервное копирование содержимого внутреннего состояния Terraform, хранящегося всоответствующее AWS S3 Bucket (так как оно версионно, мы должны быть еще безопаснее).
  2. С вашей консолью, помещенной в исходную папку, для нашего случая common выполните make init, чтобы убедиться, что ваша .terraform локальная папкаон синхронизируется с вашим удаленным состоянием.
  3. Если папка security все еще не существует (что должно быть истиной), клонируйте (скопируйте) папку common с именем назначения security и обновите config.tf файл внутри этой новой клонированной папки, указывающий на новый внутренний путь S3 (рассмотрите возможность обновления 1 учетной записи за раз, начиная с менее критической, и оцените результаты с помощью terraform state list).

Например:

# Backend Config (partial)
terraform {
  required_version = ">= 0.11.14"

  backend "s3" {
    key = "account-name/security/terraform.tfstate"
  }
}
Внутри нашей только что созданной папки security запустите terraform-init (без удаления скопированной локальной папки .terraform, которая уже была сгенерирована и синхронизирована на шаге 2), в результате чего будет сгенерирована новая копиясостояние ресурсов (в интерактивном режиме) в новом пути S3.Это безопасная операция, поскольку мы еще не удалили ресурсы из старого файла пути .tfstate.
$ make init
terraform init -backend-config=../config/backend.config
Initializing modules...
- module.cloudtrail
- module.cloudtrail.cloudtrail_label

Initializing the backend...
Backend configuration changed!

Terraform has detected that the configuration specified for the backend
has changed. Terraform will now check for existing state in the backends.

Acquiring state lock. This may take a few moments...
Acquiring state lock. This may take a few moments...
Do you want to copy existing state to the new backend?
  Pre-existing state was found while migrating the previous "s3" backend to the
  newly configured "s3" backend. No existing state was found in the newly
  configured "s3" backend. Do you want to copy this state to the new "s3"
  backend? Enter "yes" to copy and "no" to start with an empty state.

  Enter a value: yes
...                                                             

Successfully configured the backend "s3"! Terraform will automatically                                                                        
use this backend unless the backend configuration changes.                                                                                    

Initializing provider plugins...                                                                                                              
...                                                                                                                                                                                                                                                                                                                                                                                                                                                                                             
Terraform has been successfully initialized!                                                                                                                                                                                                                                             
...                                                                                                                                                                                                                                                            

enter image description here

Выборочно удаляйте нужные ресурсы из каждого состояния (terraform state rm module.foo), чтобы сохранить нужные пути в путях /common и /security.Более того, необходимо параллельно выполнять необходимые обновления (добавлять / удалять) модулей / ресурсов из ваших файлов .tf в каждой папке, чтобы синхронизировать как локальное объявление кодовой базы, так и удаленный .tfstate.Это разумная операция, пожалуйста, начните с тестирования процедуры на менее критичном единственном ресурсе.

В качестве справочного материала мы можем рассмотреть следующие документы и инструменты:

Случай 2:

Если папка security уже существует и с ней связан удаленный.В пути AWS S3 вам нужно использовать другую последовательность шагов и команд, возможно, те, на которые ссылаются ссылки ниже: 1. https://www.terraform.io/docs/commands/state/list.html 2. https://www.terraform.io/docs/commands/state/pull.html 3. https://www.terraform.io/docs/commands/state/mv.html 4. https://www.terraform.io/docs/commands/state/push.html

Ссылки ссылки:

0 голосов
/ 18 мая 2018

Вероятно, самый простой вариант - использовать terraform import на ресурсе в новом месте файла состояния, а затем terraform state rm в старом месте.

Terraform обрабатывает некоторую автоматическую миграцию состояний при копировании / перемещенииПапка .terraform есть, но я использовал ее только для смещения всего файла состояния, а не его части.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...