[terraform]테라폼 시작하기

일관(consistent)되고 예측가능한(predictable)환경을 달성하기 위해 소프트웨어를 통해 인프라를 프로비저닝 한다.

IaC의 이점은 무엇일까?

• Automated deployment
• Repeatable process
• Consistent environments
• Reusable components (DRY 원칙을 지킨다. Don’t Repeat Yourself)
• Documented architecture

코드로 인프라를 관리하니 제대로 작성한다면 동일한 인프라를 찍어낼 수 있을것이고, 코드를 통해 관리되니 git에 저장하여 배포를 자동화 한다거나 일관된 환경을 가질 수 있을 것이다. 그리고 개발자들에게 문서화란 어렵고도 중요한 일인데 이미 코드로 아키텍쳐가 구성이 되어있으니 어느정도 아키텍쳐의 문서도 작성된 셈이 된다.

테라폼의 특징은 어떤것들이 있을까?

테라폼의 핵심 구성요소는 다음과 같다.

• excutable : 하나의 단일 바이너리 파일로 모든 테라폼 기능을 수행할 수 있다.
• Configuration files : 배포할 구성요소들은 .tf 라는 확장자의 하나 이상의 terraform 파일에 포함된다.
• provider plugins : 서비스의 API와 통신하기 위해 terraform에서 호출하는 실행파일이다. 가장 기본적인 플러그인은 공개 테라폼 레지스트리인 registry.terraform.io에서 호스팅 된다.
• state data : 리소스들이 생성되면 진행상황을 추적하기 위해 배포에 대한 현재 정보가 포함된 상태 데이터를 유지 및 관리한다.

테라폼의 object Types

• Providers : 공급자(ex, aws, gcp …)
• Resources : 대상환경에서 만들고자 하는 것들. 작성하는 것의 대부분을 차지한다. 각 리소스는 providers와 연결되며 구성에 대해 몇가지 추가정보가 필요하다. (ex, vpc, subnet ... )
• Data sources : providers로 부터 정보를 쿼리하여 가져온다. 아무것도 생성하지 않고 구성에 사용할 정보를 요청하는 것 (ex, ec2를 생성할때 어딘가 ami의 정보를 넣어놓고 테라폼 수행시 가져와서 사용할 수 있도록 한다.)

테라폼의 workflow

• terraform init
  • 현재 작업 디렉토리 내에서 구성파일을 찾고 검사하여 provider 플러그인이 필요한지 확인한다.
  • 만약 그렇다면 대체위치(alternate location)을 설정하지 않는 이상 공용 테라폼 레지스트리(public terraform registry)에서 해당 플러그인을 다운받기 위해 시도한다. 
  • 현재의 상태를 상태파일에 저장하고 backend를 지정하지 않으면 현재 작업 디렉토리에 상태데이터 파일을 생성한다.
• terraform plan
  • 현재 상태와 상태파일을 비교하여 원하는 구성과 일치하도록 대상환경을 업데이트할 계획을 세운다.
  • 사용자가 확인할 수 있도록 변경사항을 print 해준다.
  • 변경사항을 파일에 저장하고 그 파일을 다음단계(apply)에 전달할 수 있다.

• terraform apply
  
  • 대상환경에 실제로 반영하는것
  • terraform plan을 통해 상태파일이 업데이트 되면 테라폼은 공급자 플러그인을 이용하여 이러한 변경사항을 실행한다.
  • 리소스가 변경 또는 생성된 후 상태데이터를 업데이트한다.
  • 만약 plan 파일을 인자로 전달하면 계획을 검토하였다고 가정하기때문에 변경사항을 확인하지 않는다.

• terraform destroy
  • 위험한 명령어
  • 상태 데이터에 있는 리소스들을 삭제한다.

 

# plan 후 결과값을 m3.tfplan 이름의 파일로 생성 
terraform plan -out "m3.tfplan"

# 위에서 plan 후 생성된 파일을 적용
terraform apply "m3.tfplan"