Terraform
HashiCorp사의 Terraform은 버전화, 재사용 및 공유할 수 있는 사람이 읽을 수 있는 구성 파일에서 클라우드 및 온프레미스 리소스를 모두 정의할 수 있는 코드형 인프라(IaC) 도구로 Amazon Web Services(AWS), Azure, Google Cloud Platform(GCP), Kubernetes, Helm, GitHub, Splunk, DataDog 등 수천여개의 다양한 Provider를 제공한다.
Provider
테라폼을 적용할 대상으로 한번에 하나의 프로비저닝만 가능하며 terraform init을 통해 설치된다. (aws 구성을 azure로 변경하는 등의 작업은 불가함, 프로바이더에 대한 자세한 정보는 아래 링크 참조)
https://registry.terraform.io/browse/providers
원하는 프로바이터를 선택하고 오른쪽 상단의 USE PROVIDER 버튼을 누르면 간단한 사용방법이 나온다.
Workflow and Terminology used in Terraform
테라폼은 크게 write -> plan -> apply의 과정을 거쳐 인프라를 프로비저닝한다.
- write : 여러 클라우드 공급자 및 서비스에 걸쳐 있을 수 있는 리소스를 정의한다.
- plan : 기존 인프라 및 구성(tfstate)을 기반으로 생성, 업데이트 또는 파괴할 인프라를 설명하는 실행 계획을 생성한다.
- apply : 승인 시 Terraform은 모든 리소스 종속성을 고려하여 올바른 순서로 제안된 작업을 수행한다.
아래는 테라폼에서 사용하는 용어들이다.
- resourece : 실제로 생성할 인프라 자원을 의미
- output : 인프라를 프로비저닝 한 후에 생성된 자원을 output 부분으로 출력할 수 있음
- backend : terraform의 상태를 저장할 공간 지정 (내부 / 외부 모두 가능 , 이 기능으로 다른사람들과 협업 가능)
- module : 공통적으로 활용할 수 있는 인프라 코드를 한곳으로 모아 정의하는 부분 (변수만 바꿔서 동일한 리소스를 쉽게 생성 가능)
- remote state : VPC , IAM 등과 같이 여러 서비스가 공통으로 사용하는 것이 가능 ( ftstate 파일이 저장돼 있는 backend 정보를 명시하면, trerraform이 backend에서 output 정보들을 가져옴 )
- .tfstate 파일 : 테라폼이 인프라스트럭처의 상태를 추적하고 관리하는 핵심 도구로 아래와 같은 역할을 수행한다.
- 인프라스트럭처 상태 추적: 파일을 통해 프로비저닝된 리소스의 상태를 기록하고, 변경 사항을 추적하며, 이전 상태와의 차이를 분석하여 필요한 변경을 식별합니다. (plan 시 달라지는 부분을 확인할 수 있음)
- 변경 관리: 변경 사항을 .tfstate 파일에 반영하고 apply 시 이 파일을 사용하여 변경 사항을 적용한다. 이런 방식으로 인프라스트럭처를 안전하게 변경하고 일관성 있게 유지할 수 있다.
- 협업 및 공유: .tfstate 파일은 팀 간 협업과 공유를 지원한다. 팀원들은 동일한 .tfstate 파일(백엔드 등)에 액세스하여 상태를 공유하고, 변경 사항을 추적하고 충돌을 방지할 수 있다.
- 롤백 및 복구: .tfstate 파일은 변경 사항을 롤백하고 이전 상태로 복구하는 데 사용될 수 있다.
환경 구축
테라폼 설치하기
테라폼은 여러 운영체제에서 사용할 수 있지만, Mac을 사용하기 때문에 brew와 tfenv를 사용해서 설치해보려고 한다.
ftenv를 사용하면 테라폼의 버전을 쉽게 관리할 수 있다.
# tfenv 설치
brew install tfenv
# 테라폼 설치
tfenv list-remote # 설치 가능 버전 확인
tfenv install 1.5.1
tfenv use 1.5.1
tfenv list # tfenv로 설치한 버전 확인
# 테라폼 버전 정보 확인
terraform version
visual studio code 설치하기
코드를 수정하기 위한 에디터로 vs code를 사용했다. 설치는 아래처럼 brew를 활용해도 좋지만 웹(https://code.visualstudio.com)에서 다운로드 받아 설치할 수도 있다.
vscode를 설치한 후엔 code 명령어를 사용할 수 있도록 Path에 추가해주면 좋다.(https://velog.io/@mingkyme/VSCode-Command-line-%EC%84%A4%EC%B9%98-code-%EB%AA%85%EB%A0%B9%EC%96%B4)
brew install visual-studio-code
awscli 설치하기
aws를 cli(command line interface)로 다루기 위한 툴로 brew를 사용해서 설치할 수 있다.
brew install awscli
유용한 도구 설치
아래 툴들을 추가로 설치하면 작업할 때 좀 더 유용하다.
brew install tree, jq, watch
graphviz (dot) 플러그인 설치하기
vscode의 마켓플레이스에서 해당 플러그인을 추가로 설치해주면, 오른쪽처럼 .dot파일을 그래프로 볼 수 있다.
.dot 파일은 terraform graph 명령을 사용해 생성할 수 있기 때문에 위 플러그인을 사용하면 테라폼 코드의 구조를 그래프로 확인할 수 있다.
테라폼 사용
ec2 웹서버 배포하기
테라폼을 사용해서 ec2에 아파치 웹 서비스를 배포해보자.
provider "aws" {
region = "ap-northeast-2"
}
resource "aws_instance" "example" {
ami = "ami-0c9c942bd7bf113a2"
instance_type = "t2.micro"
vpc_security_group_ids = [aws_security_group.instance.id]
user_data = <<-EOF
#!/bin/bash
echo "Hello, T1012 Study 8080" > index.html
nohup busybox httpd -f -p 8080 &
EOF
user_data_replace_on_change = true # true일 경우 인스턴스를 재생성한다.
tags = {
Name = "Single-WebSrv"
}
}
resource "aws_security_group" "instance" {
name = var.security_group_name
ingress {
from_port = 8080
to_port = 8080
protocol = "tcp"
cidr_blocks = ["0.0.0.0/0"]
}
}
variable "security_group_name" {
description = "The name of the security group"
type = string
default = "terraform-example-instance"
}
output "public_ip" {
value = aws_instance.example.public_ip
description = "The public IP of the Instance"
}
위 코드를 apply하면, aws 서울 리전(ap-northeast-2)에 우분투(ami-0c9c942bd7bf113a2) 이미지를 사용한 t2.micro 유형의 ec2 인스턴스를 Single-WebSrv라는 이름으로 보안 그룹을 적용해서 생성한다.
user_data에 아래 코드를 넣어 줬기 때문에 인스턴스가 실행되면서 아파치 웹 서버(8080번 포트)로 index.html을 띄운다.
#!/bin/bash
echo "Hello, T1012 Study 8080" > index.html
nohup busybox httpd -f -p 8080 &
vpc와 subnet은 default를 사용하므로, 해당 리소스가 클라우드 계정 내에 없다면 생성이 실패할 수 도 있다.
이럴 경우 아래 명령을 실행해주자.
# default VPC를 생성
aws ec2 create-default-vpc
# default Subnet 생성
aws ec2 create-default-subnet --availability-zone ap-northeast-2a
aws ec2 create-default-subnet --availability-zone ap-northeast-2b
aws ec2 create-default-subnet --availability-zone ap-northeast-2c
aws ec2 create-default-subnet --availability-zone ap-northeast-2d
위의 모든 과정은 ~/.aws/credential에 크레덴셜 정보가 있어야 가능하다.
만약 없다면 aws configre 명령어로 설정해주면 된다.
lifecycle
테라폼은 기본적으로 immutable한 인프라스트럭쳐 관리를 지향하기 때문에 기본 수명주기는 삭제 후 생성이지만, 작업 시 리소스를 제거하면 안되는 경우가 종종 있다.
lifecyle은 이런 경우에 리소스의 기본 수명주기를 작업자가 의도적으로 변경할 수 있도록하는 메타인수다.
메타인수를 사용하면 아래 기능들이 가능하다.
- create_before_destroy (bool): 리소스 수정 시 신규 리소스를 우선 생성하고 기존 리소스를 삭제
- prevent_destroy (bool): 해당 리소스를 삭제 Destroy 하려 할 때 명시적으로 거부
- ignore_changes (list): 리소스 요소에 선언된 인수의 변경 사항을 테라폼 실행 시 무시
- precondition: 리소스 요소에 선언해 인수의 조건을 검증
- postcondition: Plan과 Apply 이후의 결과를 속성 값으로 검증
하지만 위의 메타인수들을 잘못 사용하면 적용은 잘 되지만 실제로는 리소스가 사라지는 경우가 있다.
ex) 동일한 리소스를 수정할 때 create_before_destroy 옵션을 키고 적용하면 생성 후 삭제하게 되는데, 이 때 기존 리소스가 삭제됨
제대로 이해하고 사용하면 유용하지만, 잘못 사용할 경우 리스크가 있는 기능인 것 같다.
'DevOps > IaC (Infrastructure as Code)' 카테고리의 다른 글
Terraform Backend 생성하기 (S3 버킷) (0) | 2023.10.22 |
---|---|
[T1012] Week 6. 테라폼으로 협업하기 (0) | 2023.08.13 |
[T1012] Week 4. State & module (0) | 2023.07.29 |
[T1012] Week 3. 테라폼 기본 사용법 정리 (3/3) (0) | 2023.07.22 |
[T1012] Week 2. 테라폼 기본 사용법 정리 (2/3) (0) | 2023.07.15 |
Infrastructure as Code : 코드를 통한 인프라 구축 (0) | 2022.12.30 |
댓글