Terraform - всегда ли уникальный идентификатор в файле .tfstate использовался раньше? - PullRequest
Новая
       35

Terraform - всегда ли уникальный идентификатор в файле .tfstate использовался раньше?

1 голос
/ 01 июня 2019

В файле состояния Terraform ниже приведен раздел файла .tfstate для OpenStack (который использует API-интерфейсы AWS и, следовательно, AWS является поставщиком): 

"aws_instance.7.3" 
  "primary": {
    "attributes": { 
      "id": "6b646e50-..."

Скажем, я удаляю экземпляр / ресурс вручную вконсоль.Моя Конфигурация Terraform может быть изменена таким образом, что План Terraform может запускать ai) пересоздание (+/-) или ii) уничтожение (-) и создание / добавление (+).

Вопрос : в любом случае, существует ли вероятность, что новый созданный узел будет иметь такой же атрибут "id", как и раньше в файле состояния?

Другими словами,будет ли атрибут "id" ("instance_id" в случае GCP) всегда уникальным в течение жизненного цикла инфраструктуры?(чтобы я знал, что новый узел создается / воссоздается наверняка при сравнении старого файла tfstate с новым файлом tfstate с атрибутом "id" или "instance_id" и убедитесь, что .tfstate отражает то, что, как было сказано, произошло в плане.)

Причина, по которой я проверяю, отражает ли .tfstate план (точное число созданий / воссозданий / уничтожений), хотя «применить» происходит в соответствии с «планом», иногда .tfstate ДЕЛАЕТНЕ отражает это.

Причина этого в том, что после «применения» terraform, похоже, выполняет GET-вызов провайдеру для обновления файла .tfstate, и этот GET-вызов иногда возвращает несовместимое состояниеInfrastucture (то есть он может не возвращать детали узла, даже если он создан и является частью инфраструктуры!).

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

...