서버 관리를 위해 어드민 권한으로 서버에 접속하는 루트를 구축할 것이다.
SSH 방식으로만 접근이 가능하며, private한 (사내)네트워크 하에 구축되는 ec2 인스턴스다.
아래 사진에서 표시했듯이
AMI는 Amazon Linux 2 AMI
를 사용할 것이다.
빨간색 음영처리된 부분을 복사한다.
아래 그림과 같이 화살표 방향이 가리키는 곳에 붙여넣기를 한다.
해당 부분이 values
에 들어갈 내용이다.
data "aws_ami" "amazon_linux" {
most_recent = true
filter {
name = "name"
values = ["amzn2-ami-hvm-2.0.*-x86_64-gp2"]
}
owners = ["amazon"]
}
resource "aws_instance" "bastion" {
ami = data.aws_ami.amazon_linux.id
instance_type = "t2.micro"
}
터미널에 다음의 명령어를 입력하자.
flake8 혹은 black 을 사용해본 적이 있으면 쉽게 이해할 수 있는
자동 포맷팅 기능이다.(pretify)
docker-compose -f deploy/docker-compose.yml run --rm terraform fmt
그리고 bastion.tf 파일이 유효하게 작성됐는지 확인하기 위해서 다음을 입력하자.
docker-compose -f deploy/docker-compose.yml run --rm terraform validate
실제 state를 적용하는 것은 아니다.
마치 makemigrations
를 하는 것과 같다.
변경 사항을 기록하는 단계다.
적용하지는 않았다는 의미다.
docker-compose -f deploy/docker-compose.yml run --rm terraform plan
위 명령어를 입력하고 바로 에러 메시지가 출력됐다.
AWS 다이나모 테이블 이름과 main.tf
에 입력한 그것이 달라서 발생한 에러다.
migrate
과 유사하다.
변경사항을 적용하는 것이다.
따라서, 협업을 할 때 terraform apply 명령어를 사용하는 것에 주의를 기울여야 한다.
docker-compose -f deploy/docker-compose.yml run --rm terraform apply
AWS 다이나모DB 테이블의 항목을 삭제해주니, 다시 init 명령어가 실행됐다.
미친 구글링으로 해결할 수 있었다.
기본 VPC
를 생성해주었고,
다시 terraform init 및 apply를 진행했다.
드디어 해결ㅜㅜ
3시간 정도 삽질한 것 같다. 해결되어 행복하다.
Desired state이 이미 반영됐기에 AWS에 적용된 리소스에 변화가 없다.
즉, terraform을 통해 정의내린 AWS (provider)의 상태가 이미 반영됐다면
여러번 apply를 해도 번복되거나 이중 적용되지 않는다. terraform의 장점이며, 관리가 쉬워진다.
"내 동료가 반영했으니, 내가 다시 명령어를 입력해서 추가 반영되는 일이 발생해서는 안되겠지?" 와 같은 고민/걱정을 할 필요가 없는 것이다.
terraform을 접하며 가장 마음에 드는 명령어다.
아무리 인스턴스 유형이 micro이고, 개인 실습 프로젝트라지만
인스턴스를 생성한 것 자체가 과금 발생의 원인을 제공하는 셈이다.
코드로써 인프라를 관리하는 것의 장점은 쉽고 빠르게 인프라 구축 및 삭제가 아닌가 싶다.
destroy
해보자.
docker-compose -f deploy/docker-compose.yml run --rm terraform destroy