Мои файлы состояния хранятся вместе с файлами терраформ. (Я знаю, что это не идеально, но сейчас это то, что есть на моем рабочем месте. Есть планы отказаться от этой модели управления состоянием)
Цель моей ветки - создать новый экземпляр ec2 (названный adhoc-ec2) с различными вложениями политики. Изменение протестировано, поэтому экземпляр ec2 существует в среде разработки.
В конце, моя ветка и связанный с ней PR прошли процесс проверки PR, файл состояния уже обновлен в другой ветке и объединен с master филиал.
Разница между двумя версиями файлов настолько велика, что невозможно сопоставить вручную.
Основная причина, конечно, в том, что файл terraform содержит слишком много ресурсов, но сейчас уже слишком поздно отменить это.
Теперь мне нужно разрешить все конфликты, прежде чем я смогу объединить свою ветку в master.
Я пытался разрешить конфликт следующим образом:
Переустановите мою ветку на master (чтобы мой файл terraform содержал все последние изменения)
Замените устаревший файл состояния в ветке последней версией в master
бегать terraform refresh в попытке синхронизировать файл состояния и фактические ресурсы среды AWS.
Однако, видимо, этот план не работает. Потому что когда я бегу terraform plan сразу после этого, планы показывают, что terrafrom все еще хочет создать экземпляр ec2 adhoc-ec2 (который уже создан, как я уже говорил ранее в этом вопросе)
В качестве альтернативы я могу уничтожить экземпляры ec2 со всеми зависимыми ролями и политиками, но это займет много времени.
Есть ли более простой способ разрешить такой конфликт файлов состояний? Зачем refresh не сработало в первую очередь?
Рабочий процесс Terraform не поддерживает совместное использование изменений состояния через пул-реквест, если только вы не можете гарантировать, что одновременно будет только один пул-реквест. Terraform ожидает, что после обновления файла состояния новый файл будет немедленно доступен для всех последующих запусков Terraform.
Чтобы лучше приблизиться к стандартному рабочему процессу Terraform (с удаленным состоянием), я бы предложил изменить ваш подход следующим образом:
terraform plan чтобы увидеть, каков будет его эффект, но не применить еще.master ветка временно заморожена, пока вы применяете изменения. (Это ручная версия блокировки, которую Terraform обычно обрабатывает автоматически с помощью удаленного сервера.)terraform apply против основной ветки с внесенными в нее изменениями и создайте новую фиксацию, содержащую terraform.tfstate Обновить. Вставьте это прямо в master ветвь, минуя запросы на вытягивание, потому что это просто результат вашего изменения, которое уже было рассмотрено. (Вы должны переместить новое состояние в master ветвь, даже если terraform apply не удалось, потому что вам нужно будет открыть новый PR, чтобы реагировать на любые ошибки, но вы должны убедиться, что все, кто запускает Terraform, тем временем увидят частично обновленное состояние.)terraform.tfstate в основную ветвь, сообщите своим коллегам, что основная ветвь снова разморожена и что теперь они должны перенастроить все ожидающие ветки на основную ветку, чтобы гарантировать, что они проводят тестирование на соответствие последнему состоянию. (Это ручной эквивалент разблокировки состояния.)Как вы знаете, сохранять состояние Terraform в системе контроля версий не рекомендуется, поскольку это предотвращает автоматическую блокировку и создает некоторую неопределенность в отношении того, работают ли разработчики с самым последним снимком состояния. Но если вы будете осторожны, чтобы сохранить все предположения, которые делает Terraform, как я описал выше, тогда вы сможете относительно безопасно использовать Terraform на данный момент, пока не сможете перейти к стандартному подходу с использованием удаленного состояния.
Бег terraform refresh будет обновлять только ресурсы, уже находящиеся в файле состояния, поэтому, если ваш экземпляр еще не существует в файле состояния, Terraform все равно хочет его создать.
Вместо этого вам следует использовать terraform import чтобы добавить ресурсы в файл состояния на основе того, что возвращает API AWS, который затем должен соответствовать тому, что находится в ваших манифестах.