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

Рабочие пространства в 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 (рекомендуется)» и «Удаленный бэкенд».