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 명령을 실행하면 2개의 EC2 서버가 생성됩니다. 하지만 현재 AWS 지역 내의 각 가용 영역(AZ)에 하나의 서버를 배포하려면 어떻게 해야 합니까? 코드가 aws_availability_zones 데이터 소스에서 영역 목록을 로드하도록 한 다음 각 영역을 반복하고 count 매개변수 및 배열 인덱스 액세스를 사용하여 여기에 ECXNUMX 서버를 생성할 수 있습니다.

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를 사용하여 웹 서버 클러스터 리소스의 복사본 0개를 생성하려고 시도합니다. 또는 count 매개변수를 XNUMX으로 설정하여 일부 부울 조건을 기반으로 모듈 연결을 선택적으로 만들 수도 있습니다. 이는 합리적인 코드처럼 보일 수 있지만 terraform 계획을 실행할 때 다음 오류가 발생합니다.

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대로 크게 점프하는 경우에도 사용자에게 문제가 발생할 수 있습니다.
• AWS API를 사용하여 ASG의 활성 서버 수를 결정하고, 외부 데이터 원본을 사용하여 이를 호출하고(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은 계획 명령을 실행할 때 해당 리소스를 고려하지 않습니다. 결과적으로 언뜻 보면 옳은 것처럼 보이는 계획은 성공하지 못할 수도 있습니다.

이것으로부터 배울 수 있는 두 가지 교훈이 있습니다.

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

  다음은 2장에서 IAM 사용자와 함께 Terraform 구성에 추가한 aws_iam_user 리소스를 동기화하는 가져오기 명령입니다(물론 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로 바꾸고 싶습니다. 이러한 변경은 사소해 보일 수 있지만 실제로는 서비스 중단을 초래할 수 있습니다.

  사실 webserver-cluster 모듈은 두 보안 그룹과 ALB의 name 매개변수를 포함하여 여러 리소스에서 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]
  }

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

  관심을 가질 수 있는 또 다른 유형의 리팩토링은 Terraform ID를 변경하는 것입니다. 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의 경우와 마찬가지로 인스턴스에서 Cluster_instance로) Terraform으로 이전 리소스를 삭제하고 새 리소스를 추가한 것처럼 나타납니다. 이러한 변경 사항을 적용하면 Terraform은 이전 보안 그룹을 삭제하고 새 보안 그룹을 생성하는 반면 서버는 모든 네트워크 트래픽을 거부하기 시작합니다.

  이 토론에서 알아야 할 네 가지 주요 교훈은 다음과 같습니다.

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

    terraform state mv <ORIGINAL_REFERENCE> <NEW_REFERENCE>

    ORIGINAL_REFERENCE는 현재 형식의 리소스를 참조하는 표현식이고 NEW_REFERENCE는 리소스를 이동하려는 위치입니다. 예를 들어, aws_security_group 그룹의 이름을 인스턴스에서 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를 다시 실행하면 모든 것이 제대로 작동할 것입니다. 이때쯤에는 정보가 이미 시스템 전체에 퍼져 있을 것이기 때문입니다.

  이 발췌문은 Evgeniy Brikman의 책에서 발췌되었습니다. "Terraform: 코드 수준의 인프라".

출처 : habr.com