Управление рабочими областями

Рабочие области в CLI OpenTofu — это отдельные экземпляры данных состояния в одном и том же рабочем каталоге OpenTofu. Они существенно отличаются от рабочих областей в облачном бэкенде: для каждой из них предусмотрена собственная конфигурация OpenTofu, и каждая работает как отдельный рабочий каталог.

OpenTofu использует состояние для сопоставления ресурсов с объектами реального мира. Если запустить одну и ту же конфигурацию несколько раз с отдельными данными состояния, OpenTofu сможет управлять несколькими наборами непересекающихся ресурсов.

Рабочие области могут быть полезны в определённых сценариях, но для использования CLI OpenTofu они не обязательны. Для сложных развертываний, требующих отдельных учётных данных и средств управления доступом, мы рекомендуем использовать альтернативные подходы.

Управление рабочими областями CLI​

В каждом инициализированном рабочем каталоге изначально есть одна рабочая область с именем default.

Используйте команды tofu workspace list, tofu workspace new и tofu workspace delete, чтобы управлять доступными рабочими областями в текущем рабочем каталоге.

Используйте команду tofu workspace select, чтобы изменить выбранную рабочую область. Для заданного рабочего каталога можно одновременно выбрать только одну рабочую область. Большинство команд OpenTofu взаимодействуют только с выбранной рабочей областью. Это относится к развертыванию и изменению состояния.

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

Сценарии использования​

Чтобы поддерживать несколько экземпляров конфигурации с полностью отдельными данными состояния, можно создать несколько рабочих каталогов. Однако OpenTofu устанавливает отдельный кэш плагинов и модулей для каждого рабочего каталога, поэтому поддержка нескольких каталогов может привести к лишнему расходу трафика и дискового пространства. Кроме того, такой подход требует дополнительных действий: например, нужно отдельно обновлять конфигурацию из системы контроля версий для каждого каталога и повторно инициализировать каждый каталог при изменении конфигурации. Рабочие области удобны тем, что позволяют создавать разные наборы инфраструктуры, используя одну рабочую копию конфигурации и те же кэши плагинов и модулей.

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

Рабочие области, отличные от области по умолчанию, часто связаны с ветками функций в системе контроля версий. Рабочая область по умолчанию может соответствовать ветке main или trunk, описывающей предполагаемое состояние рабочей инфраструктуры. Создав ветку функции для внесения изменений, разработчик может также создать соответствующую рабочую область и развернуть в ней временную копию основной инфраструктуры. Затем он сможет протестировать изменения на этой копии, не затрагивая рабочую инфраструктуру. После слияния изменений и их развертывания в рабочей области по умолчанию тестовую инфраструктуру удаляют, а временную рабочую область — удаляют.

Когда не следует использовать несколько рабочих областей​

Рабочие области позволяют быстро переключаться между несколькими экземплярами одной конфигурации в рамках одного бэкенда. Они не предназначены для решения всех задач.

При использовании OpenTofu для управления крупными системами следует создавать отдельные конфигурации OpenTofu, соответствующие архитектурным границам системы. Это позволяет командам управлять разными компонентами независимо друг от друга. Одних рабочих областей недостаточно для декомпозиции системы: у каждой подсистемы должны быть собственные конфигурация и бэкенд.

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

Альтернативы рабочим областям​

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

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

• Если во всех конфигурациях доступна система управления конфигурацией, одна из них может использовать resource для экспорта переменных, а другая — datasource для их импорта.

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

• Для адресов серверов используйте специфичный для поставщика ресурс, чтобы создать DNS-запись с предсказуемым именем. Затем это имя можно использовать напрямую или воспользоваться поставщиком dns, чтобы получать опубликованные адреса в других конфигурациях.

• Если состояние одной конфигурации OpenTofu хранится в удалённом бэкенде, доступном другим конфигурациям, то эти конфигурации могут напрямую использовать terraform_remote_state для получения выходных данных корневого модуля. Такая схема усиливает связанность конфигураций, но корневой конфигурации не требуется публиковать результаты в отдельной системе.

Внутреннее устройство рабочих областей​

С технической точки зрения рабочие области эквивалентны переименованию файла состояния. При этом OpenTofu обеспечивает дополнительную защиту и поддержку удалённого состояния.

Рабочие области также предназначены для совместного использования. Они не являются приватными, если только вы не используете исключительно локальное состояние и не добавляете его в систему контроля версий.

Для локального состояния OpenTofu хранит состояния рабочих областей в каталоге с именем terraform.tfstate.d. С этим каталогом следует обращаться так же, как с локальными файлами terraform.tfstate. Некоторые команды добавляют эти файлы в систему контроля версий, но при наличии нескольких участников мы рекомендуем вместо этого использовать удалённый бэкенд.

При использовании удалённого состояния рабочие области хранятся непосредственно в настроенном бэкенде. Например, если вы используете Consul, рабочие области хранятся путём добавления имени рабочей области к пути состояния. Чтобы имена рабочих областей корректно и безопасно сохранялись во всех бэкендах, они должны быть допустимы в качестве сегмента URL-пути без экранирования.

OpenTofu хранит имя текущей рабочей области локально в игнорируемом каталоге .terraform. Это позволяет нескольким участникам команды одновременно работать в разных рабочих областях. Имена рабочих областей также связываются с соответствующими удалёнными рабочими областями в облачном бэкенде. Подробнее об именах рабочих областей в облачных бэкендах см. в разделах «Интеграция с CLI (рекомендуется)» и «Удалённый бэкенд».