Terraform 함정

루프, if 문, 배포 기술과 관련된 함정을 비롯하여 Terraform 전체에 영향을 미치는 보다 일반적인 문제를 포함하여 몇 가지 함정을 강조해 보겠습니다.

• count 및 for_each 매개변수에는 제한이 있습니다.
• 다운타임 없는 배포 제한
• 좋은 계획이라도 실패할 수 있다.
• 리팩토링에는 함정이 있을 수 있습니다.
• 지연된 일관성은 지연과 일치합니다.

count 및 for_each 매개변수에는 제한이 있습니다.

이 장의 예제에서는 루프와 조건 논리에서 count 매개변수와 for_each 표현식을 광범위하게 사용합니다. 이러한 기술은 좋은 성과를 보이지만, 두 가지 중요한 한계가 있다는 점을 알아야 합니다.

• count나 for_each에서는 리소스 출력 변수를 참조할 수 없습니다.
• 모듈 구성에서는 count와 for_each를 사용할 수 없습니다.

count 또는 for_each에서는 리소스 출력 변수를 참조할 수 없습니다.

여러 대의 EC2 서버를 배포해야 하지만 어떤 이유에서인지 ASG를 사용하고 싶지 않은 경우를 가정해 보겠습니다. 귀하의 코드는 다음과 같을 수 있습니다.

resource "aws_instance" "example_1" {
   count             = 3
   ami                = "ami-0c55b159cbfafe1f0"
   instance_type = "t2.micro"
}

하나씩 살펴보겠습니다.

count 매개변수가 정적 값으로 설정되었으므로 이 코드는 아무 문제 없이 작동합니다. 즉, apply 명령을 실행하면 세 개의 EC2 서버가 생성됩니다. 하지만 현재 AWS 지역 내의 각 가용 영역(AZ)에 하나의 서버를 배포하려면 어떻게 해야 할까요? aws_availability_zones 데이터 소스에서 영역 목록을 로드한 다음 각 영역을 "루프"로 실행하고 count 매개변수를 사용하여 EC2 서버를 생성하고 인덱스로 배열에 액세스할 수 있습니다.

resource "aws_instance" "example_2" {
   count                   = length(data.aws_availability_zones.all.names)
   availability_zone   = data.aws_availability_zones.all.names[count.index]
   ami                     = "ami-0c55b159cbfafe1f0"
   instance_type       = "t2.micro"
}

data "aws_availability_zones" "all" {}

이 코드도 count 매개변수가 문제없이 데이터 소스를 참조할 수 있으므로 잘 작동합니다. 하지만 생성해야 하는 서버 수가 일부 리소스의 출력에 따라 달라진다면 어떻게 될까요? 이를 보여주는 가장 쉬운 방법은 random_integer 리소스를 사용하는 것입니다. 이름에서 짐작할 수 있듯이 이 리소스는 임의의 정수를 반환합니다.

resource "random_integer" "num_instances" {
  min = 1
  max = 3
}

이 코드는 1과 3 사이의 난수를 생성합니다. aws_instance 리소스의 count 매개변수에서 이 리소스의 결과 출력을 사용하려고 하면 어떤 일이 일어나는지 살펴보겠습니다.

resource "aws_instance" "example_3" {
   count             = random_integer.num_instances.result
   ami                = "ami-0c55b159cbfafe1f0"
   instance_type = "t2.micro"
}

이 코드에서 terraform plan을 실행하면 다음 오류가 발생합니다.

Error: Invalid count argument

   on main.tf line 30, in resource "aws_instance" "example_3":
   30: count = random_integer.num_instances.result

The "count" value depends on resource attributes that cannot be determined until apply, so Terraform cannot predict how many instances will be created. To work around this, use the -target argument to first apply only the resources that the count depends on.

Terraform에서는 리소스가 생성되거나 수정되기 전, 계획 시점에 count와 for_each를 평가해야 합니다. 즉, count와 for_each는 리터럴, 변수, 데이터 소스, 심지어 리소스 목록(길이를 스케줄링 시점에 결정할 수 있는 경우)을 참조할 수 있지만, 계산된 리소스 출력 변수는 참조할 수 없습니다.

모듈 구성에서는 count와 for_each를 사용할 수 없습니다.

어떤 시점에서는 모듈 구성에 count 매개변수를 추가하고 싶을 수도 있습니다.

module "count_example" {
     source = "../../../../modules/services/webserver-cluster"

     count = 3

     cluster_name = "terraform-up-and-running-example"
     server_port = 8080
     instance_type = "t2.micro"
}

이 코드는 모듈 내부에서 count를 사용하여 웹 서버 클러스터 리소스의 사본을 세 개 생성하려고 시도합니다. 또는 모듈의 count 매개변수를 0으로 설정하여 부울 조건에 따라 모듈을 선택 사항으로 만들 수 있습니다. 이 코드는 괜찮아 보이지만 terraform plan을 실행하면 다음 오류가 발생합니다.

Error: Reserved argument name in module block

   on main.tf line 13, in module "count_example":
   13: count = 3

The name "count" is reserved for use in a future version of Terraform.

안타깝게도 Terraform 0.12.6부터 모듈 리소스에서 count나 for_each를 사용하는 것이 지원되지 않습니다. Terraform 0.12 릴리스 노트(http://bit.ly/3257bv4)에 따르면, HashiCorp에서는 향후 이 기능을 추가할 계획이므로, 이 글을 읽는 시점에 따라 이미 사용 가능할 수도 있습니다. 확실히 알아보려면, 여기에서 Terraform 변경 로그를 읽어보세요.

제로 다운타임 배포의 한계

ASG와 함께 create_before_destroy 블록을 사용하면 다운타임 없는 배포를 위한 훌륭한 솔루션이 되지만, 한 가지 단점이 있습니다. 자동 확장 규칙이 지원되지 않습니다. 또는 더 정확히 말하면, 모든 배포에서 ASG 크기를 min_size로 재설정하는데, 이는 자동 크기 조정 규칙을 사용하여 실행 중인 서버 수를 늘리는 경우 문제가 될 수 있습니다.

예를 들어, webserver-cluster 모듈에는 오전 9시에 클러스터의 서버 수를 11개에서 9개로 늘리는 aws_autoscaling_schedule 리소스 쌍이 포함되어 있습니다. 예를 들어 오전 XNUMX시에 배포하면 새로운 ASG는 XNUMX개 대신 XNUMX개의 서버만으로 부팅되고 다음 날 오전 XNUMX시까지 그대로 유지됩니다.

이런 제한을 극복하는 방법은 여러 가지가 있습니다.

• aws_autoscaling_schedule의 반복 매개변수를 0 9 * * * ("오전 9시에 실행")에서 0-59 9-17 * * * ("오전 9시부터 오후 5시까지 XNUMX분마다 실행")과 같이 변경합니다. ASG에 이미 XNUMX개의 서버가 있는 경우 이 자동 확장 규칙을 다시 실행해도 아무것도 변경되지 않습니다. 바로 이것이 우리가 원하는 것입니다. 하지만 ASG가 새로 배포되면 이 규칙은 최대 XNUMX분 안에 해당 서버의 수가 XNUMX개에 도달하도록 보장합니다. 이는 그다지 우아한 접근 방식이 아니며, 서버 수를 XNUMX개에서 XNUMX개로 크게 늘리거나 줄이는 것도 사용자에게 문제를 일으킬 수 있습니다.
• ASG에 있는 활성 서버 수를 확인하기 위해 AWS API를 사용하는 사용자 지정 스크립트를 만들고, 외부 데이터 소스를 사용하여 이를 호출하고(249페이지의 외부 데이터 소스 참조), ASG의 desired_capacity 매개변수를 이 스크립트에서 반환된 값으로 설정합니다. 즉, 각각의 새로운 ASG 인스턴스는 항상 기존 Terraform 코드와 동일한 용량으로 시작하므로 유지 관리가 더 어려워집니다.

물론 이상적으로 Terraform에는 가동 중지 없는 배포에 대한 기본 제공 지원이 있었겠지만 2019년 XNUMX월 현재 HashiCorp 팀은 이 기능을 추가할 계획이 없었습니다.자세한 내용은 여기를 참조하세요).

올바른 계획이라도 제대로 실행되지 않을 수 있다

때로는 plan 명령을 실행하면 완벽하게 유효한 배포 계획이 생성되지만 apply 명령은 오류를 반환합니다. 예를 들어, 2장에서 만든 IAM 사용자에 사용한 것과 동일한 이름으로 aws_iam_user 리소스를 추가해보세요.

resource "aws_iam_user" "existing_user" {
   # Подставьте сюда имя уже существующего пользователя IAM,
   # чтобы попрактиковаться в использовании команды terraform import
   name = "yevgeniy.brikman"
}

이제 plan 명령을 실행하면 Terraform은 겉보기에 타당한 배포 계획을 출력합니다.

Terraform will perform the following actions:

   # aws_iam_user.existing_user will be created
   + resource "aws_iam_user" "existing_user" {
         + arn                  = (known after apply)
         + force_destroy   = false
         + id                    = (known after apply)
         + name               = "yevgeniy.brikman"
         + path                 = "/"
         + unique_id         = (known after apply)
      }

Plan: 1 to add, 0 to change, 0 to destroy.

apply 명령을 실행하면 다음 오류가 발생합니다.

Error: Error creating IAM User yevgeniy.brikman: EntityAlreadyExists:
User with name yevgeniy.brikman already exists.

   on main.tf line 10, in resource "aws_iam_user" "existing_user":
   10: resource "aws_iam_user" "existing_user" {

물론 문제는 해당 이름을 가진 IAM 사용자가 이미 존재한다는 것입니다. 이런 일은 IAM 사용자뿐만 아니라 거의 모든 리소스에 발생할 수 있습니다. 누군가가 이 리소스를 수동으로 또는 명령줄을 사용하여 만들었을 가능성이 있지만 어느 쪽이든 ID 중복으로 인해 충돌이 발생합니다. 이 오류에는 여러 가지 변형이 있어 Terraform 초보자들이 종종 당황하게 됩니다.

중요한 점은 terraform plan 명령은 Terraform 상태 파일에 지정된 리소스만 고려한다는 것입니다. 리소스가 다른 방식(예: AWS 콘솔에서 수동으로 클릭)으로 생성된 경우 해당 리소스는 상태 파일에 포함되지 않으므로 Terraform은 plan 명령을 실행할 때 해당 리소스를 고려하지 않습니다. 결과적으로, 첫눈에 옳은 것처럼 보이는 계획도 실패로 끝날 가능성이 큽니다.

여기에서 얻을 수 있는 교훈은 두 가지입니다.

• 이미 Terraform을 사용하기 시작했다면 다른 것은 사용하지 마세요. 인프라의 일부가 Terraform을 사용하여 관리되는 경우 더 이상 수동으로 변경할 수 없습니다. 그렇지 않으면 이상한 Terraform 오류가 발생할 위험이 있을 뿐만 아니라, 코드가 더 이상 인프라를 정확하게 표현하지 못하므로 IaC의 많은 이점을 얻을 수 없습니다.
• 이미 인프라가 있는 경우 import 명령을 사용하세요. 기존 인프라와 함께 Terraform을 사용하려면 terraform import 명령을 사용하여 상태 파일에 추가할 수 있습니다. 이렇게 하면 Terraform에서 어떤 인프라를 관리해야 할지 알 수 있습니다. import 명령은 두 개의 인수를 사용합니다. 첫 번째는 구성 파일의 리소스 주소입니다. 여기의 구문은 리소스 링크와 동일합니다: _. (aws_iam_user.existing_user와 같음). 두 번째 인수는 가져올 리소스 ID입니다. aws_iam_user 리소스 ID가 사용자 이름(예: yevgeniy.brikman)이고, aws_instance 리소스 ID가 EC2 서버 ID(예: i-190e22e5)라고 가정해 보겠습니다. 리소스를 가져오는 방법은 일반적으로 해당 페이지 하단의 설명서에 명시되어 있습니다.

  다음은 2장에서 Terraform 구성에 추가한 aws_iam_user 리소스와 IAM 사용자를 동기화하는 가져오기 명령입니다(물론 yevgeniy.brikman 대신 사용자 이름을 사용하세요).

  $ terraform import aws_iam_user.existing_user yevgeniy.brikman

  Terraform은 AWS API를 호출하여 IAM 사용자를 찾고 Terraform 구성의 aws_iam_user.existing_user 리소스와 해당 사용자 간에 상태 파일 연결을 생성합니다. 이제 plan 명령을 실행하면 Terraform은 IAM 사용자가 이미 존재한다는 것을 알고 다시 생성을 시도하지 않습니다.

  이미 Terraform으로 가져오고 싶은 리소스가 많은 경우, 코드를 직접 작성하고 각 리소스를 하나씩 가져오는 것은 번거로울 수 있다는 점에 유의하세요. 따라서 AWS 계정에서 코드와 상태를 자동으로 가져올 수 있는 Terraforming(http://terraforming.dtan4.net/)과 같은 도구를 주의를 기울이는 것이 좋습니다.

  리팩토링에는 함정이 있을 수 있습니다

  리팩토링 — 외부 동작은 그대로 두고 코드의 내부 구조만 바꾸는 프로그래밍의 일반적인 관행입니다. 이는 코드를 더 이해하기 쉽고, 깔끔하며, 유지 관리하기 쉽게 만드는 데 필요합니다. 리팩토링은 정기적으로 사용해야 하는 필수적인 기술입니다. 하지만 Terraform이나 다른 IaC 도구를 사용할 때는 코드의 "외부 동작"이 무엇을 의미하는지 매우 신중하게 고려해야 합니다. 그렇지 않으면 예상치 못한 문제가 발생할 수 있습니다.

  예를 들어, 일반적인 리팩토링 유형 중 하나는 변수나 함수 이름을 더 이해하기 쉬운 이름으로 바꾸는 것입니다. 많은 IDE에는 리팩토링 지원 기능이 내장되어 있어 프로젝트 전체에서 변수와 함수의 이름을 자동으로 바꿀 수 있습니다. 일반 프로그래밍 언어에서는 생각지도 못할 사소한 절차이지만 Terraform에서는 이 부분에 대해 매우 조심해야 하며, 그렇지 않으면 중단이 발생할 수 있습니다.

  예를 들어, webserver-cluster 모듈에는 cluster_name이라는 입력 변수가 있습니다.

  variable "cluster_name" {
     description = "The name to use for all the cluster resources"
     type          = string
  }

  foo라는 마이크로서비스를 배포하기 위해 이 모듈을 사용하기 시작했다고 상상해보세요. 나중에 서비스 이름을 bar로 바꾸고 싶어졌어요. 이런 변화는 사소한 것처럼 보일 수 있지만, 실제로는 서비스 중단을 초래할 수 있습니다.

  요점은 웹 서버-클러스터 모듈이 두 보안 그룹의 이름 매개변수와 ALB를 포함한 여러 리소스에서 cluster_name 변수를 사용한다는 것입니다.

  resource "aws_lb" "example" {
     name                    = var.cluster_name
     load_balancer_type = "application"
     subnets = data.aws_subnet_ids.default.ids
     security_groups      = [aws_security_group.alb.id]
  }

  리소스의 이름 매개변수를 변경하면 Terraform은 해당 리소스의 이전 버전을 삭제하고 그 자리에 새 버전을 만듭니다. 하지만 해당 리소스가 ALB인 경우, 해당 리소스가 제거된 시간과 새 버전이 로드된 시간 사이에는 웹 서버로 트래픽을 리디렉션할 메커니즘이 없습니다. 마찬가지로, 보안 그룹이 삭제되면 서버는 새 그룹이 생성될 때까지 모든 네트워크 트래픽을 거부하기 시작합니다.

  여러분이 관심을 가질 만한 또 다른 리팩토링은 Terraform 식별자를 변경하는 것입니다. 예를 들어 webserver-cluster 모듈의 aws_security_group 리소스를 살펴보겠습니다.

  resource "aws_security_group" "instance" {
    # (...)
  }

  이 리소스의 식별자는 인스턴스라고 합니다. 리팩토링 중에 더 이해하기 쉬운(귀하의 의견으로는) 이름인 cluster_instance로 변경하기로 결정했다고 상상해 보세요.

  resource "aws_security_group" "cluster_instance" {
     # (...)
  }

  결국 무슨 일이 일어날까? 정답: 업무 중단.

  Terraform은 각 리소스 ID를 클라우드 공급자 ID와 연결합니다. 예를 들어, iam_user는 AWS IAM 사용자 ID에 매핑되고, aws_instance는 AWS EC2 서버 ID에 매핑됩니다. 리소스 ID를 변경하는 경우(예: aws_security_group의 경우 instance에서 cluster_instance로 변경) Terraform에서는 기존 리소스를 삭제하고 새 리소스를 추가한 것으로 간주합니다. 이러한 변경 사항을 적용하면 Terraform은 기존 보안 그룹을 삭제하고 새 보안 그룹을 만들며, 그동안 서버는 모든 네트워크 트래픽을 거부하기 시작합니다.

  이 토론에서 얻을 수 있는 네 가지 주요 교훈은 다음과 같습니다.

  • 항상 plan 명령어를 사용하세요. 이는 모든 문제점을 드러낼 수 있습니다. 출력을 주의 깊게 검토하고 Terraform이 삭제해서는 안 될 리소스를 삭제할 계획인 상황을 파악하세요.
  • 삭제하기 전에 만드세요. 리소스를 교체하려면 원본을 삭제하기 전에 교체 리소스를 만들어야 하는지 신중하게 생각해보세요. 만약 대답이 '예'라면, create_before_destroy가 도움이 될 수 있습니다. 동일한 결과를 두 단계로 수동으로 얻을 수 있습니다. 먼저, 구성에 새 리소스를 추가하고 적용 명령을 실행한 다음, 구성에서 이전 리소스를 제거하고 적용 명령을 다시 실행합니다.
  • 식별자를 변경하려면 상태도 변경해야 합니다. 리소스를 삭제하고 새 버전을 만들지 않고 리소스와 연결된 식별자를 변경하려는 경우(예: aws_security_group의 이름을 instance에서 cluster_instance로 변경) Terraform 상태 파일을 그에 맞게 업데이트해야 합니다. 이 작업은 절대로 수동으로 하지 마세요. 대신 terraform state 명령을 사용하세요. 식별자의 이름을 바꿀 때는 다음 구문을 갖는 terraform state mv 명령을 실행해야 합니다.

    terraform state mv <ORIGINAL_REFERENCE> <NEW_REFERENCE>

    ORIGINAL_REFERENCE는 리소스를 현재 형태로 참조하는 표현식이고, NEW_REFERENCE는 리소스를 이동하려는 위치입니다. 예를 들어, aws_security_group의 이름을 instance에서 cluster_instance로 바꾸려면 다음 명령을 실행합니다.

    $ terraform state mv 
       aws_security_group.instance 
       aws_security_group.cluster_instance

    이는 이전에 aws_security_group.instance와 연관되었던 상태가 이제 aws_security_group.cluster_instance와 연관되어야 함을 Terraform에 알려줍니다. 이름을 바꾸고 이 명령을 실행한 후에도 terraform plan에 아무런 변경 사항이 표시되지 않으면 모든 작업을 올바르게 수행한 것입니다.

  • 일부 매개변수는 변경할 수 없습니다. 많은 리소스의 매개변수는 변경할 수 없습니다. 리소스를 변경하려고 하면 Terraform은 기존 리소스를 삭제하고 그 자리에 새 리소스를 만듭니다. 각 리소스 페이지에는 일반적으로 특정 매개변수를 변경할 때 어떤 일이 발생하는지 명시되어 있으므로 설명서를 확인하세요. 항상 plan 명령을 사용하고 create_before_destroy 전략을 사용하는 것을 고려하세요.

  지연된 일관성은 다음과 일치합니다. 지연

  AWS와 같은 일부 클라우드 공급업체의 API는 비동기식이며 일관성이 지연됩니다. 비동기성이란 인터페이스가 요청된 작업이 완료될 때까지 기다리지 않고 즉시 응답을 반환할 수 있음을 의미합니다. 지연된 일관성은 변경 사항이 시스템 전체에 전파되는 데 시간이 걸릴 수 있음을 의미합니다. 이러한 일이 발생하는 동안 응답이 일관되지 않을 수 있으며 API 호출에 응답하는 데이터 소스 복제본에 따라 달라질 수 있습니다.

  예를 들어 AWS에 EC2 서버를 생성해 달라고 요청하는 API 호출을 한다고 상상해보세요. API는 서버 자체가 생성될 때까지 기다리지 않고 거의 즉시 "성공" 응답(201 생성됨)을 반환합니다. 바로 연결을 시도하면 거의 확실히 실패할 것입니다. 그 시점에 AWS는 여전히 리소스를 초기화 중이거나, 혹은 서버가 아직 부팅되지 않았기 때문입니다. 게다가 이 서버에 대한 정보를 얻기 위해 다른 호출을 하면 오류(404 찾을 수 없음)가 발생할 수 있습니다. 문제는 해당 EC2 서버에 대한 정보가 여전히 AWS 전체에 전파되고 있을 수 있으므로 모든 곳에서 사용할 수 있게 되려면 몇 초가 걸릴 수 있다는 것입니다.

  지연 일관성을 갖춘 비동기 API를 사용할 때마다 작업이 완료되어 시스템 전체에 전파될 때까지 주기적으로 요청을 다시 시도해야 합니다. 안타깝게도 AWS SDK는 이에 대한 좋은 도구를 제공하지 않으며 Terraform 프로젝트는 이전에 6813(https://github.com/hashicorp/terraform/issues/6813)과 같은 많은 버그로 어려움을 겪었습니다.

  $ terraform apply
  aws_subnet.private-persistence.2: InvalidSubnetID.NotFound:
  The subnet ID 'subnet-xxxxxxx' does not exist

  즉, 리소스(서브넷 등)를 생성한 다음 해당 리소스에 대한 정보(예: 방금 생성한 서브넷의 ID)를 얻으려고 하면 Terraform에서 해당 정보를 찾을 수 없습니다. 이러한 버그(6813 포함)의 대부분은 수정되었지만, 특히 Terraform에서 새로운 리소스 유형에 대한 지원을 추가할 때 여전히 가끔씩 발생합니다. 귀찮긴 하지만 대부분의 경우 아무런 해를 끼치지 않습니다. 다시 terraform apply를 실행하면 모든 것이 제대로 작동할 것입니다. 이 시점에는 정보가 시스템 전체에 퍼졌을 것입니다.

  이 발췌문은 Evgeny Brickman의 책에서 발췌한 것입니다. "Terraform: 코드 레벨의 인프라".

출처 : habr.com