Terraform
Terraform은 개발환경을 Code로 관리(IAC - Infrastructure As Code)하게 도와주는 open-source 소프트웨어 도구이다. 여기서 개발환경 설정은 서버 인스턴스, 디비 인스턴스 뿐만 아니라 네트워크 구성, 로드벨런서, 권한 설정들을 모두 의미한다. 이런 코드화가 가능한 이유는 요즘의 개발 환경은 Cloud Computing Service(AWS, Google Cloud, Azure..)를 이용하기 때문이다.
테라폼 이외의 다른 IAC tool인 Chef, Puppet, Ansile, SaltStack, CloudFormation 이 있다. 그 중 왜 Terraform이 유행이 된걸까?? 솔직히 난 회사에서 쓰다 보니 다른 tool은 써보지 않아서 장단점을 파악 하지는 못 했으나 [이글에선]
- Provisioning 측면과 Configuration Management 측면의 차이 ( 장점이 맞나?? )
- Provisioning은 실제 서버 구성이고 Configuration Management는 기존 서버의 설정인데 Chef, Ansile, Puppet도 Provisioning을 지원한다고 하는데 딱히 이게 장점은 아닌거 같다
- Mutable Infrastructure vs Immutable Infrastructure ( 도커의 장점 아닌가?? )
- '수정 불가능한 인프라와 수정가능한 인프라' 의미를 해석했을때 수정 불가능한 인프라는 서버에 설치한 소프트웨어들 (openssl) 과 같은 히스토리를 고유하게 유지한다는 것이였다. 하지만 위 글에서 설명은 'terraform를 사용해 docker image를 통해 서버를 구성'한다면 이라고 말하고 있다 이건 도커의 장점이 아닌가 싶다.
- Procedural vs Declarative
- Chef 와 Ansible은 절차적으로 서버를 구성한다고 한다. 이게 어떤 방식인지는 사용해본적이 없어서 잘 모르겠다. 하지만 Terrform은 서버를 환경변수 설정하는 정의한다 서버를 몇대 어떤 os이미지로 어떤 사양으로 할지를 정의하면 끝이다. 이점은 장점이라고 볼 수 있을거 같다.
다른 차이점이 궁금하다면 위 링크를 읽어보기를 추천합니다.
Terraform - Provider, State
terraform을 처음 시작하면 terraform 명령어인 init, plan, apply가 먼저 눈에 들어온다. init은 현재 폴더를 terraform 명령어가 실행될 수 있는 환경으로 만들어준다. (npm init 과 비슷) 그 다음 .tf 파일에서 서버관련 설정을 하고 plan을 하면 현재 서버 정보와 비교해서 수정사항을 알려주고 apply를 하면 실제 서버에 반영됩니다.
하지만 여기서 궁금한 점은 1. 어떤 Cloud Service에 접근하고 2. 어떻게 기존 서버의 정보를 아는지 입니다.)
Provider
어떤 Cloud Service에 접근 할 것인지는 Provider통해 아래와 같이 정의 할 수 있습니다. Cloud Service에 따라 파리미터 변수가 달라질 수 는 있겠지만 중요한것은 Provider를 통해 Cloud Service에 대한 접근 설정을 할 수 있다는 것 입니다.
provider "cloud_service_name" {
region = "region_code"
profile = "profile_name"
}State
Provider을 통해 Cloud Service에 접근을 하였지만 기존의 Infra 정보는 어떻게 가저 오는 것일까?? 위에서 terraform은 명령어 plan과 apply가 있습니다. 이때 apply를 하면 init을 하면서 생성된 .terrform/terraform.tfstate 파일에 핸재 infra 구조 정보가 들어갑니다.
이 정보를 통해서 plan 명령어는 기존 infra구조와 변경된 infra 구조를 파악해서 추가, 삭제 사항을 알려준다.
State Management
Infra를 담당자가 한명이면 따로 State를 관리 할 필요가 없다 여기서 관리라는 것은 history를 의미한다. 하지만 여러명이서 관리를 한다면 주의 할 점이 생긴다.
- 최신화 - infra를 수정한다면 현재 state파일은 최신화된 상태여야 한다.
- Lock - infra를 수정하는 도중엔 다른 사람은 접근 할 수 없다.
- Isolating - infra는 Production, Staging 를 별도로 관리 되어야 한다.
이 3가지 점을 주의 해야 하기 때문에 state파일을 local 또는 git을 통해 관리하기엔 부족하다.
Local에서 관리하면 다른 사용자들과 state파일 공유가 힘들다.
Git을 사용할 경우 최신 버전을 Pull 하지 않으면 기존 버전으로 롤백 되어 버린다. 또한 보안상의 이슈도 있다.
테라폼은 이러한 이슈를 Cloud Service의 기능을 통해 해결 할 수 있는 기능을 제공한다.
backend를 아래와 같이 정의 함으로써 state파일을 S3(파일서버) 또는 Dynamodb(NoSQL)을 통해 관리 할 수 있게 해준다.
terraform {
backend "s3" {
# Replace this with your bucket name!
bucket = "terraform-up-and-running-state"
key = "global/s3/terraform.tfstate"
region = "us-east-2"
# Replace this with your DynamoDB table name!
dynamodb_table = "terraform-up-and-running-locks"
encrypt = true
}
}또 다른 과제 - 환경관리 그리고 모듈화
Terraform을 사용하다 보면 Resource와 Module 이란 개념을 사용해서 구조를 정의한다. 우선 구조정의 부터 쉽지 않을 뿐더러 이를 환경별로 분리하고 공통되는 resource를 모듈화 하여 재사용성을 높이려 하기는 또다른 문제이다.
나는 지금
- 기존 WebConsole로 구성된 infra를 코드화
- 환경별 인프라 구조 관리
- 모듈화 방식
에 대해 고민하고 있다.
모듈화를 하고 분리를 하면 할 수록 관리측면과 구조 변경(apply)에서 시간이 적게 소요되는 장점이 있지만 terraform 프로젝트에 가서 apply를 순서대로 실행해 줘야 한다는 불편함이 있다. 이를 편리하게 하고자 terragrunt라는 보조 툴이 있지만 아직 사용법을 잘 모르겠고 Terraform 조차 서툰 단계라 어느정도 정리가 되면 글을 적어보려 한다.
