Rivalry2

HTML Diff

0 added 0 removed

Original 2026-01-01

Modified 2026-02-26

1 Terraform хранит текущее состояние инфраструктуры в файле с расширением .tfstate. При выполнении операций Terraform идет в файл состояния и проверяет, какая инфраструктура уже развернута. На основе того, что есть в состоянии и что описано в проекте, Terraform понимает, что нужно сделать - создать инфраструктуру или изменить.

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

3 Например, два разработчика могут одновременно запустить изменение инфраструктуры. Или в разных ветках проекта могут храниться разные состояния инфраструктуры.

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

5 <h2>Зачем нужно удаленное хранилище состояния</h2>

6 Когда мы управляем своей инфраструктурой на одной машине, схема работы с Terraform выглядит просто. Мы обновляем инфраструктуру, ее состояние изменяется.

7 У нас локально всегда хранится актуальный файл с состоянием:

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

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

10 Если организовать этот процесс через git-репозиторий, нужно сначала обновить инфраструктуру, затем добавить коммит с новым tfstate и отправить его в удаленный репозиторий. Коллега должен получить из репозитория актуальный tfstate, внести свои изменения, и в свою очередь отправить изменения в коде Terraform и новый файл состояния в Git:

11 Такой подход требует концентрации внимания и может привести к проблемам:

12 <ul><li>Человеческий фактор. Один из разработчиков может забыть обновить state из репозитория и применит неправильные изменения на инфраструктуру</li>

13 <li>Неконсистентность состояний. В git могут храниться разные версии состояния, и кто-нибудь применит неактуальные изменения на инфраструктуру</li>

14 <li>Конфликт применения изменений. Terraform будет работать у обоих с локальным файлом состояния и не будет знать о том, что кто-то уже обновляет ту же инфраструктуру</li>

15 </ul>Чтобы избавиться от этих проблем, Terraform предлагает собственный механизм удаленного хранения состояния. В нем большую часть операций контроля и синхронизации Terraform выполняет автоматически.

16 Концепция Terraform, описывающая удаленное хранение состояния, называется remote backend.

17 <h2>Что такое Terraform remote backends</h2>

18 В терминологии Terraform<a>backend</a>- это решение, которое отвечает за хранение состояния. Если состояние хранится удаленно - этоremote backend.

19 При использовании remote backend Terraform сохраняет состояние в удаленное хранилище, а локально в tfstate хранит только информацию об этом удаленном хранилище.

20 В качестве хранилища может выступать любое<a>облачное объектное хранилище</a>по типу Amazon S3: Google Cloud Storage, Azure Storage, Yandex Cloud Storage и другие подобные решения. Также Terraform может использовать для удаленного хранения состояния HTTP-сервер, базу данных PostgreSQL или облачную платформу Terraform Cloud.

21 В схеме с remote backend при выполнении любых операций над инфраструктурой Terraform будет обращаться к удаленному файлу состояния, блокировать его на время выполнения изменений, затем перезаписывать этот файл с учетом внесенных изменений:

22 C remote backend Terraform самостоятельно будет решать ту проблему синхронизации состояний, которая возникала при командной работе с Git. Любой участник процесса при работе с инфраструктурой будет получать единственный актуальный файл состояния - у него не будет возможности получить некорректный.

23 Еще Terraform remote backend нативно поддерживает механизмы блокировки состояния. Если начать изменять какую-либо инфраструктуру, ее состояние не будет доступно никому другому, пока все изменения не будут применены. Это позволит исключить любые конфликты с параллельным применением изменений на одной и той же инфраструктуре.

24 Перейдем к практике и попробуем организовать хранение состояния удаленно. В качестве remote backend используем хранилище типа S3.

25 <h2>Как настроить хранение состояния в S3</h2>

26 Настроим хранение состояния в облаке YandexCloud. Будем использовать консольную утилиту облака<a>YandexCLI</a>. Она позволит создавать объекты в облаке через терминал.

27 Для достижения цели нам понадобятся:

28 <ul><li>Хранилище файлов типа S3, в которое Terraform будет сохранять состояние инфраструктуры</li>

29 <li>Бессерверная БД типа DynamoDB, в которой Terraform будет фиксировать блокировки</li>

30 <li>Сервисный аккаунт облака, через который Terraform сможет управлять содержимым S3 и DynamoDB</li>

31 </ul>Эти объекты в облаке нам предстоит создать. Технически мы можем использовать Terraform и для управления этими объектами тоже. Но к моменту выполнения terraform init в проекте они уже должны существовать. То есть объекты для хранения remote backend должны быть созданы в другом проекте Terraform с локальным состоянием.

32 Для упрощения процесса создадим нужные для remote backend объекты вручную. Они в дальнейшем почти никогда не меняются.

33 <h3>Подготавливаем облако для хранения состояния</h3>

34 Создадим в облаке S3-хранилище yc-hexlet-state объемом 10МБ. Этого хватит для хранения состояния надолго:

35 Дальше нам нужно сделать табличку в облачной базе данных, где Terraform будет фиксировать блокировки состояния:

36 Сохраним document_api_endpoint, он нам понадобится при конфигурации Terraform.

37 Таблицы в YDB YandexCli создавать не умеет, поэтому таблицу добавим в веб-интерфейсе облака. Найдем нашу базу в разделе "Managed Service for YDB":

38 Нам нужен раздел "Навигация". Там найдем опцию "Создать таблицу" и создадим документную таблицу lock с колонкой LockID типа String, которая будет являться ключом партиционирования:

39 Далее через YandexCLI создадим сервисный аккаунт hexlet-remote, который будет сохранять состояние Terraform в облачное хранилище:

40 В ответе получим id нового сервисного аккаунта. Он понадобится, чтобы разрешить сервисному аккаунту взаимодействовать с хранилищем.

41 Проверим имя каталога YandexCloud, в котором работаем:

42 В примере выше используется каталог default.

43 Выдадим роли storage.editor и ydb.editor нашему сервисному аккаунту в этом каталоге:

44 В --subject указываем id сервисного аккаунта, который создали ранее.

45 Мы разрешили сервисному аккаунту hexlet-remote просматривать и изменять S3-хранилище в нашем каталоге, а также работать с базой в Managed YDB. Теперь настроим Terraform так, чтобы он подключался к хранилищу S3 и клал туда состояние.

46 Создадим у сервисного аккаунта ключи доступа к S3 хранилищу:

47 Сохраним значения key_id и secret. Они понадобятся для подключения Terraform к удаленному хранилищу.

48 Мы создали в облаке всё необходимое для удаленного хранения состояния. Теперь настроим Terraform так, чтобы он отправлял состояние в удаленное хранилище.

49 <h3>Описываем remote backend в проекте Terraform</h3>

50 Создадим в проекте файл backend.tf и вставим туда блок backend, описывающий хранение состояния:

51 У каждого типа backend в Terraform свой набор параметров. Мы используем backend "s3" и указываем для него:

52 <ul><li>endpoints- список эндпоинтов. Здесь мы указываем сетевой адрес хранилища S3. В случае YandexCloud - это всегда storage.yandexcloud.net. У других облачных провайдеров будет другой. А так же указываем document_api_endpoint созданной нами Managed YDB</li>

53 <li>region- свойство, характерное для S3 конкретного облачного провайдера. У YandexCloud это всегда ru-central1</li>

54 <li>bucket- имя хранилища, которое мы создали</li>

55 <li>key- директория в хранилище, куда Terraform будет класть файл состояния</li>

56 <li>access_keyиsecret_key- соответственно, key_id и secret созданного нами ключа доступа</li>

57 <li>dynamodb_table- имя таблицы, которую мы создали в Managed YDB через интерфейс облака</li>

58 <li>Параметрыskipслужат для упрощения подключения к S3, в учебных целях</li>

59 </ul>Инициируем инфраструктуру, выполнив terraform init.

60 Если изменить настройки backend в существующем проекте, необходимо будет вызвать модифицированную команду: terraform init -migrate-state. В этом случае Terraform постарается перенести локальный файл с состоянием в удаленное хранилище.

61 В итоге мы должны увидеть, что Terraform смог настроить работу с бэкендом s3:

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

63 Теперь проверим, как работает наша блокировка. Откроем две вкладки терминала на проекте с Terraform. Выполним в первой вкладке terraform apply:

64 Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols: + create Terraform will perform the following actions: # yandex_vpc_network.net will be created + resource "yandex_vpc_network" "net" { ... } Plan: 1 to add, 0 to change, 0 to destroy. Do you want to perform these actions? Terraform will perform the actions described above. Only 'yes' will be accepted to approve. Enter a value:

65 Видим стандартный вывод Terraform, информирующий о готовности изменить инфраструктуру.

66 Теперь зайдем во вторую вкладку и попробуем выполнить terraform apply в этом же проекте:

67 Acquiring state lock. This may take a few moments... ╷ │ Error: Error acquiring the state lock │ │ Error message: ConditionalCheckFailedException: Condition not satisfied │ Lock Info: │ ID: ac5bf646-b858-c819-c847-95f260d3c613 │ Path: yc-hexlet-state/hexlet-remote-state │ Operation: OperationTypeApply │ Who: hexlet@user │ Version: 1.3.7 │ Created: 2023-07-06 11:38:14.794552864 +0000 UTC │ Info: │

68 Здесь мы видим блокировку. В тот момент, когда мы выполнили terraform apply в первый раз, Terraform создал запись о блокировке. Пока первая сессия работы с Terraform не завершится, остальные попытки менять инфраструктуру будут блокироваться.

69 Так мы с помощью удаленного хранения состояния в S3-хранилище и блокировки состояния в YDB добились того, что:

70 <ul><li>Состояние инфраструктуры всегда будет одинаковым и актуальным у всей команды. Локально в .tfstate проекта будет храниться только адрес удаленного бэкенда</li>

71 <li>Не возникнут конфликты одновременного обновления инфраструктуры двумя или более членами команды</li>

72 </ul>Мы настроили удаленное хранение состояния. Осталось позаботиться о безопасности и о том, чтобы ключи для нашего хранилища не утекли в сеть.

73 <h2>Как работать с секретами backend</h2>

74 В работе с секретами backend стоит придерживаться тех же правил, что при работе с другими секретами Terraform. В примере выше мы прописали все настройки backend прямым текстом. Это может сделать наши облачные S3 и Managed YDB уязвимыми.

75 Доработаем хранение секретов backend, чтобы обезопасить нашу инфраструктуру.

76 В разделе backend мы не можем обращаться к обычным переменным Terraform. Переменные как сущность относятся к самому tfstate. А на момент обработки состояния Terraform еще не знает о переменных, которые существуют в инфраструктуре. Так секретами backend понадобится управлять отдельно.

77 Terraform позволяет подключать секреты состояния при выполнении terraform init по одному, либо в файле с помощью параметра -backend-config.

78 Вернемся к нашему backend.tf и уберем из него данные, которые можно считать чувствительными:

79 Мы убрали значения bucket, access_key, secret_key и параметры dynamodb_* для подключения к базе. Без них в открытом виде нашим данным об инфраструктуре ничего не угрожает.

80 Создадим отдельный файл secret.backend.tfvars и вставим в него то, что вынесли из backend.tf:

81 Имя secret.backend.tfvars будет соответствовать маске secret.* в .gitignore нашего проекта Terraform, и файл с этими секретами не попадет в сеть.

82 Подключим файл с секретами backend при инициации инфраструктуры:

83 terraform init -backend-config=secret.backend.tfvars

84 Инициация должна пройти успешно. С точки зрения Terraform ничего не изменилось. Он подгружает все параметры, описанные в -backend-config, внутрь блока backend.

85 Для передачи файла с секретами коллегам можно применять облачные менеджеры ключей, такие как AWS Secret Manager или Yandex Lockbox.

86 <h2>Выводы</h2>

87 Удаленное хранение состояния предполагает, что Terraform сохраняет файл с состоянием инфраструктуры terraform.tfstate в некоторое удаленное хранилище. Локально он хранит только адрес удаленного хранилища и параметры подключения к нему.

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