[Terraform] 테라폼 동작원리 ( + Ansible )

 

 

Terraform이 강력한 이유는 tfstate 파일로 인프라를 리소스 단위로 상태 관리를 하기 때문이다.

 

 

AWS, AZURE 같은 Public Cloud 환경은 여러 리소스 ( VPC, EC2 등 )이 서로 유기적으로 연동되어 있는데, 이를 '코드'로 구현하고 구현된 '상태'를 비교하여 어떤 인프라 요소가 생성, 변경, 삭제 되는지를 예측할 수 있다. 반면 대표적인 또 다른 배포도구인 Ansible은 상태를 관리하지 않는다.

 

상태를 관리하는 Terraform, 상태를 관리하지 않는 Ansible.

 

두 도구의 철학은 다르다. 

 

Terraform은 비교로 인프라를 관리하고

Ansible은 명령으로 인프라를 관리한다. 

 

Terraform은

내가 원하는 상태는 'EC2가 t3.small이야' 라고 말하면 

테라폼은 실제 환경과 API로 통신하여 '실제 환경은 EC2가 t3.large네'라고 상태를 비교하여 변경,생성,삭제 지점을 파악한다. 

 

Ansible은

'EC2를 t3.small로 변경해!' 라고 그냥 명령을 내리는 것이다. 

Ansible은 직접 ssh로 접속해서 생성,변경,삭제 명령을 수행한다. 

 

그러므로

Code를 절차적으로 실행해서 인프라 환경을 구성하는 작업은 Ansible이 유리하고 ( OS 설정 같은 내부작업 ) 

AWS, Azure 인프라 환경 같이 여러 리소스가 유기적으로 연결되어 있는 인프라의 생성 및 관리는 테라폼이 유리하다. 

 

 

한마디로 정리하면,   테라폼은 '과거'를 기억한다.

 

 

테라폼 동작 원리

 

테라폼은 과거를 '장부'에 기록하는데, 그것이 tfstate 파일이다. 

 

왜 장부(tfstate)가 필요할까?

 

 

 

 

 

어떤 Engineer가 good_ec2라는 이름을 가진 EC2 서버의 설정을 변경하는 코드를 작성했다 가정하자. 그러나 실제환경인 AWS는 good_ec2가 뭔지 모른다. good_ec2는 사람이 이해할 수 있는 이름이므로 EC2를 특정지을 수 없다. 또 다른 누군가가 특정 EC2를 good_ec2로 네이밍할 수도 있는것이다. 특정 지을수 없다면 추적되지 못하므로 지속적 관리가 불가능해진다. ( Ansible처럼 일회성으로 생성, 변경, 삭제가 목적이라면 모를까... )

 

 

 

 

미래와 현재 사이에 과거를 기억하는 tfstate를 두어보자. 

 

Engineer가 good_ec2를 최초 생성할때 tfstate에는 good_ec2가 어떤 EC2인지 특정지을 수 있는 ID와 매핑되어 기록된다. Engineer가 good_ec2를 변경하려한다면 테라폼은  tfstate를 읽어 해당 EC2의 상태를 API로 호출하여 비교한다. 

 

여기서 tfstate의 기록을 현재(실제환경)에서 API로 호출하여 최신화하는 작업을 refresh 라고한다. 

 

'terraform plan'을 실행하면 미래 와 현재를 비교한다. tfstate에 기록된 대상들을 임시로 refresh하여 현재상태로 만들고 수정된 코드와 비교한다 . ( apply가 아닌 plan이므로 실제 tfstate가 최신화되는 것은 아님, 임시로... )  

 

현재에는 없는데 미래에 있으면 생성(Create)

현재에도 있고 미래에도 있으면 변경(Update)

현재에는 있는데 미래에 없으면 삭제(Delete)

 

모든 것은 상태가 기록된 tfstate를 기준으로 동작하므로, tfstate는 정말 중요하다. 

 

실제 환경에 인프라가 구성되어 있는데, tfstate를 지워버리면 어떻게 될까?

 

테라폼은 tfstate를 기준으로 refresh하여 현재 코드와 실제환경을 비교하므로, tfstate가 없다면 코드로 작성된 모든 리소스는 신규 생성 대상이 된다. 이미 인프라가 모두 구성되어 있는데, 동일한 인프라가 중복되어 또 다시 생성되는 것이다. 이렇듯 tfstate는 항상 최신상태를 유지하도록 관리되어야 하므로, 여러 사람이 동시에 테라폼코드를 수정하는 상황을 잘 제어해야 한다. 

 

 

테라폼 배포과정 

 

코드 작성(tf파일 생성) > init > validate > plan > apply 

 

 

terraform init

 

init은 테라폼 초기환경을 구성한다. 

 

코드에 작성한 API를 호출하는 프로바이더에 대한 정보가 명시된 .terraform.lock.hcl 파일을 생성하고 프로바이더 바이너리 파일을 설치한다.  .terraform.lock.hcl 파일은 설치한 프로바이더에 대한 정보가 명시되어 있다. .terraform.lock.hcl 파일을 git으로 공유하면 다른 팀원이 init 시, .terraform.lock.hcl 파일에 명시된 프로바이더를 설치한다. 

 

이외에도 선언한 모듈들의 소스를 로컬로 가져오거나 tfstate를 어디에 저장할 것인가에 대한 여러 설정을 초기화 한다. 

 

terraform validate

 

작성된 소스들의 테라폼 문법을 검사하는 과정이다. 

 

 

terraform plan

 

tfstate 파일을 임시로 refresh하여 테라폼 코드와 상태를 비교하는 과정이다. 

 

 

terraform apply

 

실제 환경으로 배포가 되는 과정이다. 배포가 완료되면 tfstate 파일은 refresh되어 현재 상태가 기록된다.