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

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

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

Рабочие пространства могут быть полезны в определённых сценариях использования, но для работы с интерфейсом командной строки 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 (рекомендуется) и удалённый бэкенд и в документации.