Как использовать рабочие области Terraform для управления несколькими состояниями
Terraform произвел революцию в нашем взгляде на инфраструктуру, и с Cloud это ступенька к всему как коду. Это качественный скачок в истории вычислений, где все, включая оборудование и операционные системы, виртуализировано и может быть определено как код.
Terraform упростил жизнь архитекторам инфраструктуры, администраторам и организациям и помогает в создании постоянно меняющейся, а также более масштабируемой и эластичной вычислительной инфраструктуры, чем когда-либо прежде.
Terraform использует декларативный, высокоуровневый и идемпотентный набор кода для определения инфраструктуры. Администраторы инфраструктуры обычно просто заявляют, какую инфраструктуру они хотели бы иметь, не беспокоясь о внутренних вызовах API.
Terraform не зависит от облака и может помочь вам управлять несколькими облачными конфигурациями с помощью одной настройки. Вы также можете объявить зависимости между компонентами, распределенными по облаку.
Одна из проблем IaC - возможность повторного использования. Terraform рекомендует сохранять код СУХИМ (не повторяйтесь). Это особенно верно, если вы управляете несколькими средами.
Управление несколькими средами
Возьмем типичный сценарий, с которым большинство из нас сталкивается в своей работе. Организации обычно имеют несколько сред для запуска своего программного обеспечения. Существует среда разработки, в которой разработчики работают над разработкой нового программного обеспечения, среда тестирования, в которой тестировщики тестируют разработанный код, и производственная среда (или рабочая среда), в которой конечные клиенты взаимодействуют с программным обеспечением.
Как правило, код и конфигурация, применяемые к среде разработки, после тестирования переходят в режим тестирования и, наконец, в продукт. Следовательно, то же самое следует сказать и об инфраструктуре.
Давайте посмотрим на способы управления инфраструктурой в нескольких средах с помощью Terraform.
Стратегия 1. Создайте отдельные каталоги для каждой среды.
Это элементарно. Просто создайте отдельные папки для каждой среды и повторите настройку для dev, test и prod. Типичное дерево выглядит так:
Что ж, для начала это может показаться разумным подходом, но есть несколько проблем:
- Теперь нам нужно поддерживать три копии одной и той же конфигурации.
- Конфигурация несовместима с CI / CD, поскольку требуется вмешательство человека для продвижения кода в более высокие среды.
Стратегия 2. Использование рабочих пространств
Как вы, возможно, уже выяснили, единственное различие между этими средами будет заключаться в значениях переменных и файле состояния.
У нас есть два требования:
- Должен быть способ динамического определения отдельных переменных для каждой среды.
- Должен быть способ управлять отдельными состояниями для каждой среды.
Terraform позволяет добиться именно этого с помощью рабочих пространств.
Представляем рабочие области
Рабочие области в Terraform - это просто независимо управляемые файлы состояний.
Если мы используем локальный сервер для хранения состояния Terraform, Terraform создает файл с именем terraform.tfstate для хранения состояния примененной конфигурации. Однако в сценариях, где вы можете использовать одну и ту же конфигурацию для разных контекстов (например, в разных средах), отдельные состояния могут быть необходимы, но могут использовать одну и ту же конфигурацию.
Terraform использует рабочие области по умолчанию, и если вы не объявляете рабочее пространство, вы все равно работаете с рабочим пространством по умолчанию. Когда вы создаете рабочее пространство и применяете там свою конфигурацию Terraform, Terraform создает каталог с именем terraform.tfstate.d. Внутри него он создает подкаталог для каждой рабочей области. Подкаталоги содержат отдельные файлы состояний для конкретной рабочей области, как показано в примере ниже:
Давайте посмотрим на практическое упражнение, чтобы понять, как оно работает в реальной жизни.
Предпосылки
- Аккаунт AWS. В этом упражнении используется корзина S3, которая является бесплатной службой.
- Terraform 0.12 CLI установлен в вашей системе.
Создание файлов Terraform
Давайте клонируем этот репозиторий GitHub для этого упражнения:
$ git clone https://github.com/bharatmicrosystems/terraform-workspaces.git
Измените каталог на клонированный репозиторий и давайте посмотрим на отдельные файлы:
Переменная project_name - это карта, которая по умолчанию равна ga-terraform-dev для ключа dev и ga-terraform-prod для ключа prod. Файл variables.tf также определяет две строковые переменные, называемые env и aws_region.
Файл main.tf объявляет aws_s3_bucket и имеет неявную зависимость от ресурса random_id. Мы используем ресурс random_id для генерации случайного числа, чтобы сделать корзину S3 глобально уникальной. В ресурсе aws_s3_bucket мы используем поиск на карте var.project_name для ключа var.env.
Файл outputs.tf определяет имя сегмента в качестве вывода.
Развертывание в среде разработки
Начнем с нашего первого развертывания в среде разработки.
Создайте новое рабочее пространство под названием dev:
$ terraform workspace new dev Created and switched to workspace "dev"! You're now on a new, empty workspace. Workspaces isolate their state, so if you run "terraform plan," Terraform will not see any existing state for this configuration.
Планируйте развертывание Terraform с env=dev:
Примените план:
Как видите, Terraform создал корзину с именем ga-terraform-dev-14913.
Развертывание в среде Prod
Теперь повторим то же самое для среды prod.
Создайте новое рабочее пространство под названием prod:
$ terraform workspace new prod Created and switched to workspace "prod"! You're now on a new, empty workspace. Workspaces isolate their state, so if you run "terraform plan," Terraform will not see any existing state for this configuration.
Выполните план Terraform с env=prod:
Примените план:
Terraform создает новую корзину с именем ga-terraform-prod-7436.
Осмотрите ковши в консоли
Перейдите в консоль AWS - ›S3, и вы увидите, что Terraform создал два отдельных сегмента для каждой среды:
Посмотреть состояние Terraform
Перечислите дерево корневого модуля:
И мы видим, что есть каталог terraform.tfstate.d, в котором у нас есть подкаталоги для каждой рабочей области, и каждая папка имеет свой файл состояния.
Уничтожение ведер
А теперь давайте уничтожим то, что мы создали. Давайте сначала начнем со среды разработки, а затем перейдем к продукту.
Перейдите в рабочее пространство dev:
$ terraform workspace select dev Switched to workspace "dev".
Выполните terraform destroy и введите yes, когда будет предложено подтвердить:
Давайте проверим консоль AWS и обновим:
Как видите, Terraform уничтожил ведро dev, но ведро prod не затронуто.
Давайте сейчас уничтожим ведро prod.
Перейдите в рабочее пространство prod:
$ terraform workspace select prod Switched to workspace "prod".
Выполните terraform destroy и введите yes для подтверждения:
Давайте посмотрим на консоль AWS и обновимся. Вы обнаружите, что Terraform удалил корзину prod S3.
Это показывает, что обе среды работают независимо друг от друга и имеют свои файлы состояния.
Заключение
Terraform Enterprise и Cloud выводят рабочие пространства на новый уровень, связывая их с репозиторием VCS, где вы можете интуитивно планировать и применять свои развертывания. Вы также можете сотрудничать со своей командой, поскольку сборки запускаются в централизованном месте, чтобы каждый мог просматривать и управлять ими.
Спасибо за прочтение! Надеюсь, вам понравилась статья. Увидимся в следующем.
