✔️ 암시적 의존성
Terraform 코드를 이용해 EIP와 S3 버킷을 생성해보자
# Elastic IP resource
resource "aws_eip" "app_server_eip" {
instance = aws_instance.app_server.id # app_server 인스턴스를 만들고 그 인스턴스의 id 값을
vpc = true # 참조하라는 의미이다.
}
# S3 Bucket
resource "aws_s3_bucket" "app_bucket" {
bucket = "ssh-20220421"
}
만들어지지도 않은 instance의 ID를 어떻게 알까 ?
Argument reference - 리소스 블록을 선언할 때 사용하는 parameter
Attribute reference - 리소스가 만들어지고 난 이후에 terraform.tfstate 파일에서 볼 수 있는 항목들
aws_instance.app_server.Attribute reference 로 사용하면 그 값을 참조할 수 있다.
app_server의 ID 값을 참조해서 EIP에 인스턴스를 할당한다.
이런 것을 암시적 의존성이라고 한다.
인스턴스와 EIP의 관계에서 EIP가 암시적으로 인스턴스를 의존하고 있다는 것이다.
인스턴스가 먼저 만들어지고 EIP가 나중에 만들어져서 연결이 된다.
테라폼이 절차적인 언어는 아니지만 리소스들의 관계를 테라폼이 분석해서 순서를 결정하게 된다.
작성한 코드를 실행해보자
기본적으로 생성하려는 리소스 간에 연관 관계가 없다면 리소스를 병렬로 만든다.
aws_instance와 aws_s3_bucket 중 뭐가 더 먼저 만들어지는가는 랜덤한 것이다.
Plan: 3 to add, 0 to change, 0 to destroy.
aws_instance.app_server: Creating... # 인스턴스와 s3_bucket은 병렬적으로 만들어진다.
aws_s3_bucket.app_bucket: Creating...
aws_s3_bucket.app_bucket: Creation complete after 2s [id=ssh-20220421]
aws_instance.app_server: Still creating... [10s elapsed]
aws_instance.app_server: Still creating... [20s elapsed]
aws_instance.app_server: Still creating... [30s elapsed]
aws_instance.app_server: Still creating... [40s elapsed]
aws_instance.app_server: Still creating... [50s elapsed]
aws_instance.app_server: Still creating... [1m0s elapsed]
aws_instance.app_server: Creation complete after 1m3s [id=i-093e82473330efdbf]
aws_eip.app_server_eip: Creating... # 인스턴스의 생성이 완료되어야 eip를 만들고
aws_eip.app_server_eip: Creation complete after 2s [id=eipalloc-0a2aef6a02ca546d5] # 인스턴스와 eip를 연결시킨다.
Apply complete! Resources: 3 added, 0 changed, 0 destroyed.
삭제 시에는 eip를 먼저 삭제한다.
인스턴스에 eip가 붙어있기 때문에 먼저 삭제할 수 없으며 eip를 먼저 삭제하고 인스턴스를 삭제해야 된다.
인스턴스와 s3_bucket은 연관 관계가 없기 때문에 동시에 지워지는 것을 알 수 있다.
aws_s3_bucket.app_bucket: Destroying... [id=ssh-20220421]
aws_eip.app_server_eip: Destroying... [id=eipalloc-0a2aef6a02ca546d5]
aws_s3_bucket.app_bucket: Destruction complete after 1s
aws_eip.app_server_eip: Destruction complete after 2s
aws_instance.app_server: Destroying... [id=i-093e82473330efdbf]
aws_instance.app_server: Still destroying... [id=i-093e82473330efdbf, 10s elapsed]
aws_instance.app_server: Still destroying... [id=i-093e82473330efdbf, 20s elapsed]
aws_instance.app_server: Still destroying... [id=i-093e82473330efdbf, 30s elapsed]
aws_instance.app_server: Still destroying... [id=i-093e82473330efdbf, 40s elapsed]
aws_instance.app_server: Still destroying... [id=i-093e82473330efdbf, 50s elapsed]
aws_instance.app_server: Still destroying... [id=i-093e82473330efdbf, 1m0s elapsed]
aws_instance.app_server: Still destroying... [id=i-093e82473330efdbf, 1m10s elapsed]
aws_instance.app_server: Still destroying... [id=i-093e82473330efdbf, 1m20s elapsed]
aws_instance.app_server: Still destroying... [id=i-093e82473330efdbf, 1m30s elapsed]
aws_instance.app_server: Still destroying... [id=i-093e82473330efdbf, 1m40s elapsed]
aws_instance.app_server: Still destroying... [id=i-093e82473330efdbf, 1m50s elapsed]
aws_instance.app_server: Still destroying... [id=i-093e82473330efdbf, 2m0s elapsed]
aws_instance.app_server: Still destroying... [id=i-093e82473330efdbf, 2m10s elapsed]
aws_instance.app_server: Still destroying... [id=i-093e82473330efdbf, 2m20s elapsed]
aws_instance.app_server: Destruction complete after 2m21s
✔️ 리소스 생성 순서
- 의존 관계가 없는 리소스는 병렬로 실행
- 의존 관계가 있는 경우 의존 관계에 따라 순서가 정해진다.
✔️ 명시적 의존성
인스턴스의 시작과 동시에 인스턴스에서 실행 중인 app이 s3의 특정 object에 접근해야 한다고 가정해보자
이때는 s3가 먼저 만들어져 있어야 접근할 수 있다.
만약 s3가 조금 나중에 만들어지면 app에서 object를 참조할 수 없으며 app이 정상적으로 작동할 수 없게된다.
이럴 때 사용하는 것이 명시적 의존성이다.
의존 관계를 우리가 직접 정할 수 있다.
resource "aws_instance" "app_server" {
depends_on = [
aws_s3_bucket.app_bucket
]
}
명시적 의존성을 정의할 때는 meta agrument 라는 것을 사용하는데
meta argument란 모든 소스에 공통적으로 적용할 수 있는 argument이다.
meta argument의 하나인 depends_on 을 사용하며 depends_on은 기본적으로 list를 받는다.
list는 [ ]를 사용한다.
s3 버킷이 만들어진 뒤 인스턴스를 만들며 인스턴스를 다 만들고 eip를 만든다.
aws_s3_bucket.app_bucket: Creating...
aws_s3_bucket.app_bucket: Creation complete after 2s [id=ssh-20220421]
aws_instance.app_server: Creating...
aws_instance.app_server: Still creating... [10s elapsed]
aws_instance.app_server: Still creating... [20s elapsed]
aws_instance.app_server: Still creating... [30s elapsed]
aws_instance.app_server: Creation complete after 33s [id=i-04c4755f363c3a891]
aws_eip.app_server_eip: Creating...
aws_eip.app_server_eip: Creation complete after 1s [id=eipalloc-014cbac07051c1829]
Apply complete! Resources: 3 added, 0 changed, 0 destroyed.
삭제 시
aws_eip.app_server_eip: Destroying... [id=eipalloc-014cbac07051c1829]
aws_eip.app_server_eip: Destruction complete after 2s
aws_instance.app_server: Destroying... [id=i-04c4755f363c3a891]
aws_instance.app_server: Still destroying... [id=i-04c4755f363c3a891, 10s elapsed]
aws_instance.app_server: Still destroying... [id=i-04c4755f363c3a891, 20s elapsed]
aws_instance.app_server: Still destroying... [id=i-04c4755f363c3a891, 30s elapsed]
aws_instance.app_server: Still destroying... [id=i-04c4755f363c3a891, 40s elapsed]
aws_instance.app_server: Destruction complete after 40s
aws_s3_bucket.app_bucket: Destroying... [id=ssh-20220421]
aws_s3_bucket.app_bucket: Destruction complete after 1s
Destroy complete! Resources: 3 destroyed.
'DevOps > Terraform' 카테고리의 다른 글
[Terraform] 연관된 변수들을 연쇄적으로 참조하기 (0) | 2022.04.22 |
---|---|
[Terraform] 입력 변수 (Input Variable) (0) | 2022.04.21 |
[Terraform] Terraform 상태 확인 (0) | 2022.04.21 |
[Terraform] Terraform Workflow (실행 순서) (0) | 2022.04.21 |
[Terraform] Terraform 구성 파일 (0) | 2022.04.21 |
영차영차 성장 블로그
포스팅이 좋았다면 "좋아요❤️" 또는 "구독👍🏻" 해주세요!