Как лучше всего использовать созданные ресурсы в Terraform?

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

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

resource "aws_vpc" "example" {
  # fill in here all the same settings that the existing object already has

  cidr_block = "10.0.0.0/16"
}

# Can then use that vpc's id in other resources using:
#    aws_vpc.example.id

Но вместо того, чтобы запускать terraform apply немедленно, вы можете сначала запустить terraform import, чтобы указать Terraform связать этот ресурсный блок с существующим VPC, используя его идентификатор, назначенный AWS:

terraform import aws_vpc.example vpc-abcd1234

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

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

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

В этом случае вы можете использовать aws_vpc источник данных, который может искать VPC по различным атрибутам. Обычный выбор - искать VPC по его тегам, если в вашей среде есть предсказуемая схема тегов, которая позволяет описать единственный VPC, который вы ищете:

data "aws_vpc" "example" {
  tags = {
    Name = "example-VPC-name"
  }
}

# Can then use that vpc's id in other resources using:
#    data.aws_vpc.example.id

В некоторых случаях пользователи вводят дополнительное косвенное обращение, чтобы найти VPC каким-либо другим способом, кроме прямого запроса API-интерфейсов AWS VPC. Это более сложная конфигурация, и варианты здесь довольно широки, но, например, если вы используете хранилище параметров SSM, вы можете поместить VPC в параметр хранилища параметров и получить его с помощью aws_ssm_parameter источник данных.

Если существующей системой управления VPC является CloudFormation, вы также можете использовать aws_cloudformation_export < / a> или aws_cloudformation_stack, чтобы получить информацию из CloudFormation. API.

Если вы счастливы управлять им с помощью терраформ, продвигаясь вперед, вы можете импортировать существующие ресурсы в свое состояние терраформирования. Вот страница использования для него https://www.terraform.io/docs/import/usage.html

Сначала вам нужно будет определить блок ресурсов внутри вашей конфигурации для vpc. Вы можете сделать что-то вроде:

resource "aws_vpc" "existing" {
  cidr_block       = "172.16.0.0/16"

  tags = {
    Name = "prod"
  }
}

а затем на cli запустите команду

terraform import aws_vpc.existing <vpc-id>

Убедитесь, что вы запустите план терраформирования после этого, потому что терраформ может попытаться внести в него изменения. Вам как бы придется немного перепроектировать его, добавив всю необходимую конфигурацию в ресурс aws_vpc. Как только он будет выровнен, terraform не будет пытаться его изменить. Затем вы можете повторно использовать это для развертывания в других учетных записях и регионах.

Как вы предложили, вы можете использовать источник данных для vpc. Это может быть полезно, если вы хотите управлять им за пределами terraform, вместо того, чтобы иметь возможность уничтожить vpc, если он запускается неопытным пользователем.

Некоторые клиенты, с которыми я работал, предпочитают управлять ресурсами, такими как виртуальные ПК / подсети (и другая основная инфраструктура), в отдельных сценариях terraform, к которым имеют доступ только старшие инженеры. Это позволяет избежать сценариев бедствий, когда люди случайно разрушают базовую инфраструктуру.

Лично я предпочитаю управлять всем своим кодом terraform в репозитории git, который затем развертывается с помощью инструмента CI / CD, даже если над ним работаю только я. Некоторые люди могут не видеть смысла тратить время на создание конвейера и могут продолжать запускать его локально.

В этом посте есть несколько отличных рекомендаций по запуску terraform в автоматизированной среде https://learn.hashicorp.com/terraform/development/running-terraform-in-automation