Terraform применяется после того, как импорт Terraform хочет принудительно использовать новый ресурс для кэша шлюза хранилища. - PullRequest
Новая
       26

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

0 голосов
/ 09 октября 2018

Прежде чем Terraform поддерживал Storage Gateway в AWS, я создал три файловых шлюза другими способами.По сути, я использовал Terraform для запуска поддерживаемых битов (политика iam, сегмент s3, экземпляр ec2, объем кэша) и использовал сценарий bash, выполняющий вызовы cli, чтобы собрать все вместе.Это прекрасно работает.

Теперь, когда Terraform поддерживает создание / активацию файлового шлюза (включая предоставление тома кеша), я реорганизовал свой Terraform для исключения сценариев bash.

Экземпляр шлюза и том кеша были созданы с использованием следующей Terraform: 

resource "aws_instance" "gateway" {
  ami           = "${var.instance_ami}"
  instance_type = "${var.instance_type}"

  # Refer to AWS File Gateway documentation for minimum system requirements.
  ebs_optimized = true
  subnet_id     = "${element(data.aws_subnet_ids.subnets.ids, random_integer.priority.result)}"

  ebs_block_device {
    device_name           = "/dev/xvdf"
    volume_size           = "${var.ebs_cache_volume_size}"
    volume_type           = "gp2"
    delete_on_termination = true
  }

  key_name = "${var.key_name}"

  vpc_security_group_ids = [
    "${aws_security_group.storage_gateway.id}",
  ]
}

Когда экземпляр запущен и работает, следующий фрагмент скрипта bash ищет идентификатор тома и настраивает том в качестве кеша шлюза:

# gets the gateway_arn and uses that to lookup the volume ID
gateway_arn=$(aws storagegateway list-gateways --query "Gateways[*].{arn:GatewayARN,name:GatewayName}" --output text | grep ${gateway_name} | awk '{print $1}')
volume_id=$(aws storagegateway list-local-disks --gateway-arn ${gateway_arn} --query "Disks[*].{id:DiskId}" --output text)
echo "the volume ID is $volume_id"

# add the gateway cache
echo "adding cache to the gateway"
aws storagegateway add-cache --gateway-arn ${gateway_arn} --disk-id ${volume_id}

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

resource "aws_storagegateway_gateway" "nfs_file_gateway" {
  gateway_ip_address = "${aws_instance.gateway.private_ip}"
  gateway_name       = "${var.gateway_name}"
  gateway_timezone   = "${var.gateway_time_zone}"
  gateway_type       = "FILE_S3"
}

resource "aws_storagegateway_cache" "nfs_cache_volume" {
  disk_id     = "${aws_instance.gateway.ebs_block_device.volume_id}"
  gateway_arn = "${aws_storagegateway_gateway.nfs_file_gateway.id}"
}

Оттуда я запустил следующее, чтобы получить disk_id тома кеша (обратите внимание, что я отредактировал идентификатор учетной записи и идентификатор шлюза: 

aws storagegateway list-local-disks --gateway-arn arn:aws:storagegateway:us-east-1:[account_id]:gateway/[gateway_id] --region us-east-1

Возвращает: 

{
    "GatewayARN": "arn:aws:storagegateway:us-east-1:[account_id]:gateway/[gateway_id]",
    "Disks": [
        {
            "DiskId": "xen-vbd-51792",
            "DiskPath": "/dev/xvdf",
            "DiskNode": "/dev/sdf",
            "DiskStatus": "present",
            "DiskSizeInBytes": 161061273600,
            "DiskAllocationType": "CACHE STORAGE"
        }
    ]
}

Затем я запустил команду импорта Terraform на ресурсе aws_storagegateway_cache, чтобы перетащить существующий ресурс в файл состояния.

Команда Irun: 

terraform_11.5 import module.sql_backup_file_gateway.module.storage_gateway.aws_storagegateway_cache.nfs_cache_volume arn:aws:storagegateway:us-east-1:[account_id]:gateway/[gateway_id]:xen-vbd-51792

Импорт успешно завершен. Затем я запускаю процесс инициализации Terraform и план Terraform, который показывает, что если бы я запустил приложение, том кэша был бы воссоздан.

Вывод из плана: 

-/+ module.sql_backup_file_gateway.module.storage_gateway.aws_storagegateway_cache.nfs_cache_volume (new resource required)
      id:                     "arn:aws:storagegateway:us-east-1:[account_id]:gateway/[gateway_id]:xen-vbd-51792" => <computed> (forces new resource)
      disk_id:                "xen-vbd-51792" => "1" (forces new resource)
      gateway_arn:            "arn:aws:storagegateway:us-east-1:[account_id]:gateway/[gateway_id]" => "arn:aws:storagegateway:us-east-1:[account_id]:gateway/[gateway_id]"

Нет других значений для disk_id, которые я могу предоставить в операторе импорта, которые позволяют завершить импорт. Я не уверен, что я могу изменить наИзбегайте воссоздания тома кеша, если запускается последующий terraform apply.

1 Ответ

0 голосов
/ 11 октября 2018

Я действительно нашел решение.@ydaetskcoR - ваш комментарий относительно отображения volume_id в disk_id привел меня к поиску Terraform, который мне был нужен для преодоления разрыва между объявлением экземпляра и объявлением кэша.

Этот блок Terraform позволяет мне искать ebs_block_device таким образом, чтобы можно было вывести правильные disk_id позже в Terraform: 

data "aws_storagegateway_local_disk" "cache" {
  disk_path   = "/dev/xvdf"
  gateway_arn = "${aws_storagegateway_gateway.nfs_file_gateway.arn}"
}

После того, как я добавил этот блок, язатем реорганизовал Terraform, который настраивает кэш для следующего: 

resource "aws_storagegateway_cache" "nfs_cache_volume" {
  disk_id     = "${data.aws_storagegateway_local_disk.cache.id}"
  gateway_arn = "${aws_storagegateway_gateway.nfs_file_gateway.id}"
}

Теперь, когда я запускаю terraform init и terraform plan, том шлюза не отображается как нуждающийся в каких-либо изменениях или заменах.

Спасибо, что помогли мне отследить это.

-Dave

...