resource "aws_key_pair" "web_admin" {
key_name = "web_admin" # "" 내부의 값을 문자열로 반환
public_key = file("~/.ssh/web_admin.pub") # file() 내부의 "" 내부 값 또한 문자열로 받아서 해당 파일의 내용을 문자열로 반환
}
여기서 지정하는 이름은 AWS에서 사용하는 이름이 아니다. 테라폼 코드의 다른 부분이 이 리소스를 참조하기 위해 사용하는 이름이므로, AWS에서 정의되는 리소스의 이름과 혼동해서는 안 된다. AWS 리소스의 이름은 주로 속성값을 통해 지정한다.
계획(Plan) 확인
terraform plan 명령으로 web_infra.tf 파일을 통해 실제로 리소스 생성이 가능한지 확인한다.
테라폼은 tf 파일을 컴파일 후 사용자가 정의한대로 '이상적 상태'를 가정한 후 '현재 상태'와 비교하여 이상적 상태와 같이 인프라를 만드는 워크플로우를 가지고 이를 apply라고 한다.
Plan은 Apply 이전에 두 상태를 비교하여 작업할 일, 작업가능한지 등을 따진다.
resource "aws_key_pair" "web_admin" 앞의 + 는 리소스를 생성하겠다는 의미이다. + 를 통해 '이상적 상태'가 되기 위해 필요한 리소스를 추가할 것이라고 미리 보여주는 것이다.
{ } 내부의 + 정보들은 apply를 통해 추가될 '리소스 속성'이다. 단, (known after apply)라고 표시된 값은 실제로 리소스를 생성해야 부여되는 값이다. 즉, 아직 알 수 없다.
Plan: 1 to add, 0 to change, 0 to destroy. 1개의 리소스가 생성되고, 0개를 변경하고, 0개를 삭제한다는 의미다.
적용(Apply)
terraform apply 명령 입력 후 최종 확인 (yes 입력)을 거쳐 리소스가 생성된다. (기존 존재하던 keykey 키 이외에 web_admin 키가 추가됐다.)
적용 후 다시 terraform plan을 실행하면 AWS 계정 상태가 web_infra.tf 파일의 내용과 동일한 '이상적 상태'기 때문에 더이상 아까와 같이 add 되지 않는다.
즉 Terraform은 생성을 명령하는 것이 아닌 '이상적 상태'를 제공하는 것입니다. terraform apply명령을 통해 제공한 '이상적 상태'와 동일한 환경을 만들 뿐 terraform apply를 재실행한다고 추가 생성되거나, 중복되거나 하지 않는다.
terraform apply명령을 실행하면 terraform.tfstate 파일이 생성되며, 이 파일에 실제 상태를 임시로 저장하는 동시에 테라폼에서 관리되는 리소스 목록을 관리한다.
SSH 접속 허용을 위한 SG 정의
SG 리소스 정의
web_infra.tf 파일 맨 아래 다음 내용 추가
resource "aws_security_group" "ssh" {
name = "allow_ssh_from_all"
description = "Allow SSH port from all"
ingress {
from_port = 22
to_port = 22
protocol = "tcp"
cidr_blocks = ["0.0.0.0/0"]
}
}
계획(Plan) 확인 및 적용(Apply)
terraform plan
terraform apply
SG 생성 전 후
EC2 인스턴스 정의
AWS의 리소스 불러오기
web_infra.tf 파일 내부에 아래 내용 추가 (AWS에서 name=default 라는 SG를 default로 읽어온다.)
data "aws_security_group" "default" {
name = "default"
}
#이 코드를 통해 테라폼 내에서 default라는 기존에 존재하는 SG를 사용할 수 있다.
Public IP확인 → terraform console → aws_instance.web.public_ip = 13.209.14.27
ssh 접속 → ssh ec2-user@13.209.14.27 -i ~/.ssh/web_admin → sudo su - = root 로그인
mysql 설치 → yum -y install mysql
RDS에 접속
아래 명령으로 RDS 접속
mysql -h [RDS 엔드포인트] -u admin -p
= mysql -h terraform-20210201042317340700000001.cgmy7o7csrza.ap-northeast-2.rds.amazonaws.com -u admin -p
리소스 제거 및 복원
리소스 제거
web_infra.tf 파일을 다른 곳으로 이동 후 terraform plan 명령을 실행하거나 terraform plan -destroy 명령을 실행하면 아무 리소스도 없던 상태로 돌아간다. 왜냐면 정의된 리소스가 없는 백지상태이기 때문 (Terraform으로 생성된 리소스에 대해서만 적용되며, AWS에서 직접 생성한 리소스와는 상관없다.)
실제 적용을 위해서는 terraform destroy 명령 혹은 web_infra.tf 파일 없이 terraform apply 명령을 실행하면 모든 리소스가 지워진다.
terraform destroy 명령 실행 → Destory는 Apply의 역순으로 진행된다. (그래야 정상적으로 인프라를 구축했을 때 정상적으로 삭제되기 때문)
기존 keykey 키페어가 남아있는 것으로 terraform destroy는 테라폼에서 생성한 리소스만 제거하는 것을 확인했다.
다시 리소스 프로비저닝 해보기
그저 terraform apply만 해주면 지금까지 만들었던 [HCL 언어로 리소스 정의]의 모든 리소스를 한번에 다시 생성할 수 있습니다.
결론
테라폼 사용 이유 (44bits를 운영하는 Daegwon Nacyot Kim님의 요약을 그대로 인용)