Terraform: инфраструктура на уровне кода

Switched to workspace "example1".

Чтобы понять, как это работает внутри, еще раз загляните в свой бакет. Вы должны увидеть новую папку под названием env:, как показано на рис. 3.5.

Рис. 3.5. Бакет S3 после того, как вы начали использовать собственные рабочие области

Внутри env: вы найдете по одной папке для каждой из ваших рабочих областей (рис. 3.6).

Внутри каждой из этих рабочих областей Terraform использует значение key, которое вы указали в конфигурации хранилища, поэтому вы должны найти файлы example1/workspaces-example/terraform.tfstate и example2/workspaces-example/terraform.tfstate. Иными словами, переключение на другую рабочую область равнозначно изменению пути хранения вашего файла состояния.

Рис. 3.6. Terraform создает по одной папке для каждой рабочей области

Это удобно, когда вы уже развернули модуль Terraform и хотите с ним поэкспериментировать (например, попробовать изменить структуру кода), но так, чтобы ваши эксперименты не отразились на состоянии уже развернутой инфраструктуры. Вы можете выполнить команду terraformworkspacenew и развернуть новую копию той же инфраструктуры, но с отдельным файлом состояния.

Вы можете даже сделать так, чтобы этот модуль менял свое поведение в зависимости от того, в какой рабочей области вы находитесь. Для этого он может считывать имя рабочей области с помощью выражения terraform.workspace. Например, в рабочей области по умолчанию можно указать тип сервера EC2 t2.medium, а во всех остальных областях — t2.micro (чтобы, скажем, сделать свои эксперименты более экономными):

resource "aws_instance" "example" {

  ami           = "ami-0c55b159cbfafe1f0"

  instance_type = terraform.workspace == "default" ? "t2.medium" : "t2.micro"

}

Этот код использует тернарный синтаксис, чтобы присвоить параметру instance_type значение t2.medium либо t2.micro в зависимости от значения terraform.workspace. Все подробности о тернарном синтаксисе и условной логике в Terraform изложены в главе 5.

Рабочие области Terraform отлично подходят для быстрого развертывания и удаления разных версий вашего кода, но у них есть несколько недостатков.

• Файлы состояния всех ваших рабочих областей находятся в одном и том же хранилище (например, в одном бакете S3). Это означает, что все они используют аналогичные механизмы аутентификации и управления доступом, что является одной из основных причин, почему они не подходят для изоляции разных окружений, таких как среды для финального тестирования и промышленного применения.

• Рабочие области не видны в коде или терминале без использования команд terraformworkspace. При чтении кода невозможно сказать, в скольких рабочих областях развернут модуль: в одной или десяти, так как выглядят они идентично. Это усложняет обслуживание, поскольку у вас нет полноценного представления о вашей инфраструктуре.

• Из двух предыдущих пунктов вытекает тот факт, что рабочие области могут быть довольно сильно предрасположены к ошибкам. Из-за нехватки прозрачности можно легко забыть, в какой рабочей области вы находитесь, и внести изменения не в том месте (например, случайно выполнить команду terraformdestroy в рабочей области production вместо staging). Поскольку вам приходится использовать один и тот же механизм аутентификации для всех рабочих областей, у вас нет другого уровня защиты от подобных ошибок.

Чтобы как следует изолировать разные окружения, вместо рабочих областей лучше использовать структуру файлов и каталогов, о которой пойдет речь в следующем подразделе. Но прежде, чем двигаться дальше, не забудьте удалить три сервера EC2, которые вы только что развернули. Для этого выполните terraformworkspaceselect<имя> и terraformdestroy в каждой из трех рабочих областей.

Изоляция с помощью описания структуры файлов

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

• Поместить конфигурационные файлы Terraform для каждой среды в отдельную папку. Например, вся конфигурация для среды финального тестирования может находиться в папке stage, а в папке prod может храниться конфигурация промышленной среды.

• Предусмотреть для каждой среды разные хранилища с разными механизмами аутентификации и управления доступом (предположим, у каждого окружения может быть отдельная учетная запись AWS со своим бакетом S3 в качестве хранилища).

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