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

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

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

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

Управление рабочими пространствами интерфейса командной строки​

Каждый инициализированный рабочий каталог начинается с одного рабочего пространства с именем default.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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