DevOps в HashiCorp Terraиз серии

Примечание: полная ментальная карта доступна по адресу: DevOps in Terraform MindMap.

Серверная часть Terraform

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

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

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

Локальные серверные части

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

Локальный сервер хранит состояние в локальной файловой системе, блокирует это состояние с помощью системных API и выполняет операции локально.

terraform {
  backend "local" {
    path = "relative/path/to/terraform.tfstate"
  }
}

В этом примере аргумент path сообщает Terraform, где хранить файл состояния. Путь указан относительно корневого каталога модуля. Если путь не указан, Terraform будет использовать расположение по умолчанию, то есть terraform.tfstate в корневом каталоге модуля.

Удаленные серверные части

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

Например:

terraform {
  backend "s3" {
    bucket = "mybucket"
    key    = "path/to/my/key"
    region = "us-east-1"
  }
}

Ключевые моменты использования бэкендов

Есть несколько ключевых моментов, которые следует помнить при работе с серверными конфигурациями:

  1. При изменении конфигурации серверной части очень важно запустить terraform init. Это гарантирует, что Terraform получит необходимую конфигурацию для нового бэкенда. Невыполнение terraform init может привести к использованию предыдущей конфигурации серверной части.
  2. Terraform предоставляет возможность перенести ваше состояние при изменении серверной части. Несмотря на удобство, всегда рекомендуется вручную создавать резервные копии вашего состояния для обеспечения безопасности данных. Сделайте копию файла terraform.tfstate и сохраните ее в отдельном месте, пока миграция не будет завершена.

Примеры серверных частей

Удаленные серверные части, такие как AWS S3 и хранилище BLOB-объектов Azure, являются популярным выбором, поскольку они позволяют блокировать состояние и хорошо работают в командных средах. Ниже приведены примеры того, как настроить оба.

АВС S3

terraform {
  backend "s3" {
    bucket = "mybucket"
    key    = "path/to/my/key"
    region = "us-west-2"
    # Optional, allows state locking & consistency checking
    dynamodb_table = "mytable"
  }
}

В этом примере Terraform использует корзину S3 в регионе us-west-2 для хранения файла состояния. Значения mybucket и path/to/my/key следует заменить вашим фактическим именем корзины и ключом. Параметр dynamodb_table используется для блокировки состояния и проверки согласованности, что предотвращает одновременный запуск Terraform другими пользователями.

Лазурный

terraform {
  backend "azurerm" {
    resource_group_name  = "StorageAccount-ResourceGroup"
    storage_account_name = "abcd1234"
    container_name       = "tfstate"
    key                  = "prod.terraform.tfstate"
  }
}

В этом примере Terraform использует контейнер больших двоичных объектов учетной записи хранения Azure для хранения файла состояния. Замените "StorageAccount-ResourceGroup", "abcd1234", "tfstate" и "prod.terraform.tfstate" фактическим именем группы ресурсов, именем учетной записи хранения, именем контейнера хранилища и ключом соответственно.

Лучшие практики

  • Использовать удаленное состояние. Удаленное состояние позволяет обмениваться состоянием вашей инфраструктуры между всеми членами вашей команды. Это необходимо для совместной работы и более безопасно, потому что извлекаются и отправляются только изменения, а это означает, что конфиденциальные части вашего состояния никогда не должны быть на диске.
  • Включить блокировку состояния. Блокировка состояния помогает предотвратить любые одновременные запуски Terraform, которые могут привести к повреждению файла состояния или конфликтам в изменениях инфраструктуры. Многие удаленные серверные части, такие как AWS S3 (при использовании с DynamoDB), Azure Blob Storage, Google Cloud Storage и т. д., поддерживают блокировку состояния.
  • Защитите серверную часть. Файл состояния может содержать конфиденциальную информацию, поэтому очень важно обеспечить ее безопасность. Используйте шифрование в состоянии покоя, если оно поддерживается серверной частью. Кроме того, контролируйте доступ к серверной части с помощью соответствующих ролей и политик IAM.
  • Разделение разных сред. У вас должны быть разные файлы состояния для разных сред, таких как производственная, промежуточная, разработка и т. д. Этого можно добиться с помощью рабочих областей или отдельных конфигураций серверной части.
  • Использовать управление версиями. Если ваш сервер поддерживает управление версиями (например, AWS S3), включите его. Это позволяет вам вернуться к предыдущей версии файла состояния, если что-то пойдет не так.
  • Создайте резервную копию файла состояния. Несмотря на то, что ваше состояние хранится удаленно и, возможно, имеет версию, все же рекомендуется время от времени делать резервную копию файла состояния, особенно перед внесением значительных изменений.
  • Ограничение доступа. Файл состояния может содержать конфиденциальные данные в зависимости от вашей инфраструктуры. Вы должны ограничить доступ к файлу состояния только тем, кому он абсолютно необходим.

Заключение