1-2. terraform lifecycle

1. terraform Workflow

출처 - https://devops101-.hashnode.dev/introduction-to-terraform

 

Command	설명
terraform init	- Terraform 작업 디렉토리를 초기화 - 필요한 프로바이더 플러그인을 다운로드하고 백엔드 설정을 구성
terraform validate	- Terraform 구성 파일의 유효성을 검사하는 명령어 - 구성 파일, 구문 오류, 필요한 설정 포함 여부 확인
terraform plan	- 실행 계획을 생성 - 구성 파일에서 정의된 원하는 상태를 달성하기 위해 테라폼이 수행할 작업을 보여줌
terraform apply	- 구성의 원하는 상태에 도달하기 위해 필요한 변경 사항을 적용 - 리소스를 생성, 업데이트 또는 삭제
terraform destroy	- 구성에 정의된 모든 리소스를 삭제
terraform refresh	- 인프라의 실시간 상태로 상태 파일을 업데이트
terraform import	- 기존 인프라를 테라폼 관리 하에 가져오기 - 새로운 리소스를 생성하지 않고 가져옴

 

출처 : https://deview.kr/2021/sessions/519

 

2. terraform plan flow chart

출처 : terraform in action (https://livebook.manning.com/book/terraform-in-action/chapter-2/v-11/1)

 

3. 네이버 클라우드 플랫폼 Terraform Provider 개발기

출처 : https://deview.kr/2021/sessions/519

3-1. Terraform plan (최초 리소스 생성 시)

 

3-2. Terraform apply (최초 리소스 생성 시)

 

1. terraform apply 명령어 입력

2. Call Create API → VPC 생성

 

3. Call Create API → Subnet 생성

 

4. Call Create API → 서버 생성

5. Call Read API → terraform.tfstate 파일 업데이트

 

 

3-3. Terraform plan (tf 코드에서 리소스 삭제시)

1. tf 코드에서 server 블록 주석 처리

 

2. terraform plan 명령어 입력

 

3. provider에 프로비저닝된 리소스들의 상태를 Call Read API로 읽고, tfstate파일을 업데이트한다.

 

4. tf 코드와 state를 diff 비교를 통해 삭제 되는 것을 찾고, 이것을 콘솔로 알려준다.

 

 

3-4. Terraform apply (tf 코드에서 리소스 삭제시)

1. terraform apply 명령어 입력

 

2. Call delete API → 서버를 삭제 → tfstate파일 업데이트

 

3-5. Terraform plan (tf 코드에서 리소스 추가)

1. terraform plan → 삭제 했던 서버 다시 추가

 

2. Call Read API → tfstate 파일 업데이트

 

3. config와 tfstate간 diff를 통해 추가될 부분 체크 → 콘솔을 통해 추가됨을 알려준다.

 

3-6. Terraform apply (tf 코드에서 리소스 추가)

1. terraform apply → plan을 통해 추가될 부분 확인

2. call create API → 서버 생성

 

3. Call Read API → tfstate 값 갱신

 

 

 

4. lifecycle block

4-1. lifecycle 메타 인수

• 특정 리소스의 생성, 갱신, 삭제 동작을 제어하는 데 사용됨
• 리소스 블록 내에 포함됨
• 다양한 메타 인수(meta-arguments)를 통해 사용자 정의 가능
  • 각 인수는 Terraform의 기본 동작을 변경하여 리소스 관리에 유연성을 제공함

 

The lifecycle Meta-Argument - Configuration Language

 

인수	설명
create_before_destroy	- 새 리소스를 먼저 생성하고 기존 리소스를 나중에 삭제하여 다운타임을 최소화.
prevent_destroy	- 리소스를 삭제하려는 계획을 거부하여 중요한 리소스를 보호.
ignore_changes	- 지정된 리소스 속성에 대한 변경 사항을 무시
replace_triggered_by	- 특정 리소스나 속성의 변경에 의해 리소스를 교체

 

create_before_destroy
- 리소스 갱신 시 기존 리소스를 먼저 삭제하지 않고 새 리소스를 먼저 생성하도록 설정
- 리소스 갱신 시 다운타임을 최소화

resource "azurerm_resource_group" "example" {
  # ...

  lifecycle {
    create_before_destroy = true
  }
}

 

prevent_destroy
- S3 버킷이 실수로 삭제되지 않도록 보호

resource "aws_s3_bucket" "example" {
  bucket = "my-important-bucket"
  acl    = "private"

  lifecycle {
    prevent_destroy = true
  }
}

 

ignore_changes
- 해당 EC2의 tag 변경을 무시
- 외부 시스템에 의해 태그가 수정되더라도 Terraform 계획과 적용 시 이를 반영하지 않도록 함

resource "aws_instance" "example" {
  ami           = "ami-123456"
  instance_type = "t2.micro"

  lifecycle {
    ignore_changes = [
      # Ignore changes to tags, e.g. because a management agent
      # updates these based on some ruleset managed elsewhere.
      tags,
    ]
  }
}

 

replace_triggered_by
- aws_ecs_service.svc.id: aws_ecs_service 리소스의 id 속성 값이 변경될 때마다 aws_appautoscaling_target 리소스를 교체
- 리소스 간의 의존성을 명시적으로 관리
- 특정 리소스가 변경될 때 자동으로 다른 관련 리소스를 교체하여 일관된 상태를 유지할 수 있도록함

resource "aws_appautoscaling_target" "ecs_target" {
  # ...
  lifecycle {
    replace_triggered_by = [
      # Replace `aws_appautoscaling_target` each time this instance of
      # the `aws_ecs_service` is replaced.
      aws_ecs_service.svc.id
    ]
  }
}

 

4-2. Custom Condition Checks

인수	설명
precondition	- 리소스가 생성되기 전에 특정 조건을 검증
postcondition	- 리소스가 생성된 후에 특정 조건을 검증

 

 

precondition
-  리소스 생성전, AMI가 x86_64 아키텍처를 사용하는지 조건 검증
-  조건이 충족되지 않으면 error_message를 출력

 

resource "aws_instance" "example" {
  instance_type = "t2.micro"
  ami           = "ami-abc123"

  lifecycle {
    # The AMI ID must refer to an AMI that contains an operating system
    # for the `x86_64` architecture.
    precondition {
      condition     = data.aws_ami.example.architecture == "x86_64"
      error_message = "The selected AMI must be for the x86_64 architecture."
    }
  }
}

 

postcondition
- 인스턴스가 생성된 후, 공용 IP 주소가 있는지 조건 검증
-  조건이 충족되지 않으면 error_message를 출력

resource "aws_instance" "example" {
  instance_type = "t2.micro"
  ami           = "ami-abc123"

  lifecycle {
    postcondition {
      condition     = aws_instance.example.public_ip != null
      error_message = "The instance must have a public IP address."
    }
  }
}