Terraform 소개

2000년 초반까지만 하더라도 많은 소프트웨어 개발 회사들은 많은 비용과 시간을 서버 등등의 하드웨어를 빌드 하는데 사용했다. 시스템 엔지니어 혹은 ops 팀이라고 하는 서버 관리 팀이 따로 있는게 대부분 이었다. 개발자들이 빌드한 애플리케이션을 ops팀에게 넘기면 ops팀이 서버에 디플로이하는 과정을 담당했었다. 그리고 이러한 과정은 많은 부분이 수동 작업이었다. 당연히 비용과 시간이 많이 걸렸으며 문제도 많이 생겼었다. 개발자가 자기 dev box에서는 다 작동하는걸 확인하고 ops 팀에 넘겼는데 실제 프로덕션 서버에서는 문제가 발생했던 적은 예전에는 흔치 않게 겪었던 일이다. 하지만 AWS를 필두로한 클라우드 서비스가 널리 퍼지면서 회사들은 점차 서버를 직접 관리하지 않게되었고 그러면서 개발팀 과 ops팀의 구분이 모호해지기 시작했다. 개발자가 코딩 부터 서버 실행 및 디플로이 까지 전부 다 충분히 할 수 있는 환경이 주어진것이다. 그러면서 DevOps 운동이 일어나기 시작했다. 많은 devops 들이 생겨나고 devops 분야가 발전하면서 IAC (Infrastructure As Code) 도 같이 많은 주목을 받기 시작했다. IAC는 단어 그대로 서버 등등의 인프라스트럭쳐를 코드로 표현 한다는 의미로, AWS UI를 통해 수동으로 서버를 운영하는게 아니라 코드로 서버 생성, 운영 및 관리 하는 것이다. 애플리케이션과 마찬가지로 인프라도 코드로 정의하고 출시, 운영, 관리 심지어 테스트 까지 하는게 IAC 이다.

IAC Tools

현재 이미 많은 IAC tool들이 있는데, 아래 리스트가 아마 가장 유명한 것들일 것이다.

• Chef
• Puppet
• Ansible
• SaltStack
• Docker
• Packer
• Varrant
• CloudFormation
• Terraform
• OpenStack

그 외에도 다수가 있지만 주로 위의 tool들이 널리 사용된다. 그 중 terraform에 대해서 소개 하고자 한다. terraform은 위에 나열된 tool 들 중에 가장 최근 개발된 것들중 하나이다. Chef나 Puppet 등은 configuration management tool이라고 하여 이미 생성된 서버의 셋팅을 관리해주는 tool인데 반면에 terraform은 server provisioning tool 이라고 하는데 서버를 생성하는 기능을 제공하는 tool이다. 물론 Chef 나 Puppet을 통하여서도 어느정도 server provisioning이 가능하지만 (마찬가지로 terraform을 통하여서도 어느정도의 configuration management가 가능하다) terraform은 server provisioning이 주 기능인 tool이기 때문에 Chef 나 Puppet등을 사용해서 server provisioning을 하는것보다 훨씬 더 자연스럽고 효울적으로 server provisioning을 할 수 있다.

Terraform & AWS

Terraform을 사용하여 서버 생성 뿐만이 아니라 데이터베이스, load balancers, 모니티링, firewall setting, routing rules, dns settings, network 설계 등등 인프라 전체 설계를 정의 및 관리 할수 있다. 예를 들어, terraform 코드를 사용해서 AWS상에서 ec2 instance들을 생성하고 security groups를 설정하고 elb나 alb를 설정을 할수 있는것이다. 예를 들어, 아래 코드를 사용해서 AWS에서 coreos 기반의 ec2 2개를 서울 리전에 생성할수 있다.

provider "aws" {
  region  = "ap-northeast-2"
}

data "aws_ami" "coreos" {
  most_recent = true

  filter {
    name   = "name"
    values = ["*CoreOS*"]
  }

  filter {
    name   = "virtualization-type"
    values = ["hvm"]
  }
}

resource "aws_instance" "coreos" {
    count = 2
    ami = "${data.aws_ami.coreos.id}"
    instance_type = "t2.micro"
    vpc_security_group_ids = ["${aws_security_group.ec2_front_end.id}"]
  
    tags { 
  	  Name = "example" 
    }
}

위에 코드를 실행시키면 terraform이 AWS의 API를 통하여 AWS의 서울 리전에 cores 기반의 ec2 인스턴스를 t2.micro로 2개를 생성시킨다. Terraform 코드는 declartive 문법을 기반으로 이루어지고 있는데, 위의 예제 코드에서 볼수 있듯이 생성하고자 하는 인프라의 정의만 정해주는 식으로 되어 있다. 이러한 declartive 문법으로 되어 있기 때문에 코드만 봐도 인프라의 전체적인 그림을 이해 하기가 쉽다.

Terraform 장점

자동화

• 수동으로 서버를 생성하는게 아니라 코드로 생성 하기 때문에 서버 운영및 관리가 모두 자동화 될 수 있다. 예를 들어, AWS에서 새로운 서버를 생성 하기 위해서 AWS 콘솔에 로그인 할 필요도 없이 terraform 코드를 실행시키기만 하면 된다.

속도 와 안전

• 코드로 실행 되기 때문에 사람이 수동으로 작업하는것 보다 훨씬 빠르며 또한 사람이 직접 할 때 생길수 있는 실수 들을 방지할수 있다.

문서화

• 모든 인프라가 코드로 기록 및 관리 되기 때문에 자동으로 문서화가 된다. 가장 큰 장점중에 하나인데, 많은 회사에서 인프라를 직접 구현하고 관리한 담당자를 제외하고는 전체 서버를 전부 파악하고 있는 사람이 없는 경우가 많다. 하지만 terraform의 경우에는 새로 들어온 개발자 라도 terraform code를 보면 전체적인 구성을 이해할수 있다.

형상관리

• 여느 코드와 마찬가지로 terraform 코드도 git 등등을 이용해 형상관리를 할수 있다. 이 뜻은, 인프라의 변경 기록을 쉽게 볼수 있다는 뜻이다.

리뷰 및 테스트

• 역시 여느 코드와 마찬가지로 terraform 코드도 리뷰 및 테스트가 가능하다. 이 점 또한 큰 장점 중에 하나인데, 수동으로 서버 작업을 할때는, 실제로 실행하기 전에 리뷰 하는것이 굉장히 힘들수 밖에 없었다. 그래서 문제가 발견 됬을때는 이미 프로덕션 애플리케이션에 영향을 주고 난 후인 경우가 많았는데, terraform의 경우 코드 리뷰와 테스트를 통해 문제가 실제로 발생되는 것을 어느정도 예방할수 있다.

Reuse

• 역시 여느 코드와 마찬가지로 reuse가 가능하다. 한번 terraform 코드를 사용해서 인프라를 구축해놓으면 그 후 새로 추가하는 인프라들을 구성하기가 쉬워진다.

Terraform을 사용해서 인프라를 구축하면 처음에는 수동으로 구축하는것 보다 시간이 더 걸리는것은 사실이다. 그냥 AWS 콘솔에서 하면 너무 간단한것이 terraform으로 할려니깐 복잡하고 시간이 걸려서 짜증이 날때도 있다. 하지만 terraform을 사용해서 코드화가 되고나면 앞으로의 보수유지 및 관리가 훨씬 쉬어진다. 앞으로 terraform 사용법에 관한 여러 tip들을 계속해서 공유 하고자 한다. So stay tuned!