티스토리 뷰

Terraform VS Google Deployment Manager

Terraform은 인프라를 코드로 관리하게 해주는 도구이다. (Infra as Code)

사실 GCP에는 Deployment Manager 라는 훌륭한 Infra as Code 서비스가 있는데

굳이 Terraform을 쓸 필요가 있나 싶기도 하다.

하지만 둘다 장단점이 있다.

Terraform 같은 경우 지원하는 리소스만 사용가능하기에 GCP의 alpha, beta version의 리소스들을 사용할 수 없다.

(수정: Google 과 Hashicorp 의 협업을 통해 1.19.0 버전부터는 beta 버전의 리소스도 사용이 가능하다. 자세한 버전 정보는 Google Provider Versions 링크를 참고) 

또 Deployment Manager에 비해 state 파일들을 관리해야하는 불편함도 있다.

그래도 여전히 Terraform은 Deploy Manager 못지않게 사용하기 간편하고

GCP뿐 아니라 AWS, Azure 등의 타 벤더사 리소스도 관리 할 수 있기 때문에

개인적으로 엔지니어 입장에서 기술 스택 하나 늘린다는 생각하면 Terraform이 더 끌린다.

 

사전준비

1. Terraform 설치

Cloud Shell에는 이미 terraform이 설치 되어 있다.

하지만 타벤더 클라우드의 리소스까지 GCP Cloud Shell에 들어가서 관리 할 수는 없지 않은가.

로컬 환경에 Terraform을 설치한다.

mac 이라면 간단히 brew 명령어로 설치 가능하다.

brew install terraform

 

설치가 되면 terraform이 정상적으로 설치되었는지 확인한다.

terraform

Terraform 설치 확인

 

2. Google Cloud Platform 신규 계정

Google Cloud Platform 신규 계정을 생성하면 300불 크래딧을 준다.

Terraform 실습을 하다보면 이런저런 리소스를 생성하는데 이때 발생하는 비용은 저 무료 크래딧으로 충분하다.

 

Project 생성

다음과 같이 프로젝트를 새로 생성한다.

default는 한 계정에 프로젝트 25개 밖에 못만드나보네

 

Enable API

필요한 API를 활성화 시킨다. 

이 포스팅에서는 Compute Engine instance를 생성/삭제 할 것이므로 

Compute Engine API를 enable 한다.

Enabling 기다리는거 상당히 오래걸림. 거의 5분 걸림. GCP 장애인줄.

 

Project 폴더 생성

로컬 머신에 terraform 관련 파일들이 저장될 폴더를 생성한다.

mkdir infra-as-code
cd infra-as-code

 

 

Project credentials

Terraform이 내 GCP프로젝트의 리소스들을 관리하려면 service account key가 필요하다.

다음과 같이 service account를 생성한다.

만들어둔게 있으면 그거쓰면 됨. 없으면 새로 생성

 

VM instance 하나만 만들어볼꺼니까 Role은 Compute Admin을 선택한다. (Least privilege)

Role은 언제나 최소 권한으로

 

+ CREATE KEY 버튼을 눌러서 키를 생성한다. (JSON으로 생성했다.)

사실 Cloud shell로 terraform 돌릴꺼면 key 필요없음. 담부턴 귀찮으니까 Cloud shell 에서 실습한걸로 작성해야지.

 

key를 생성하면 내 로컬 머신에 다운로드 된다.

다운로드 된 key의 이름을 credentials.json 으로 바꾸고 위에서 생성했던 project 폴더에 옮겨둔다.

key 이름 안바꿔도 상관없지만 너무 길어서 그냥 바꿈

 

Terraform 사용

로컬 터미널에서 project 폴더 위치로 이동 후 terraform 설정을 위한 tf 파일을 생성한다.

vi instance.tf

 

다음의 내용을 작성한다.

// Configure the Google Cloud provider
provider "google" {
 credentials = "${file("credentials.json")}"
 project     = "terraform-reo"
 region      = "us-central1"
}

// Create a GCE instance
resource "google_compute_instance" "default" {
  name         = "terraform"
  machine_type = "f1-micro"
  zone         = "us-central1-a"

  boot_disk {
    initialize_params {
      image = "debian-cloud/debian-9"
    }
  }

  network_interface {
    network = "default"
    access_config {
    }
  }
}

 

간단한 실습이 목적이므로 가장 저렴한 f1-micro 타입의 인스턴스를 생성하기로 한다.

region과 zone을 굳이 us-central1 으로 설정한 이유는 us-east4를 제외한 US region의 f1-micro 인스턴스는 Always Free Tier 라서 크래딧과 무관하게 공짜로 사용 가능하다.

 

tf 파일을 작성했다면 init 명령어로 terraform을 initialize 시킨다.

terraform init

드디어 init

 

plan 명령어로 현재 tf 설정 적용시 infra가 어떻게 변경되는지 체크한다.

terraform plan

리소스 많아지면 plan 보는것도 일이 겠네

 

apply 명령어로 tf에 정의한 설정들을 실행한다.

terraform apply

위 명령어를 실행하면 plan을 보여주고 이대로 진행할것인지 한번더 확인을 한다. 

둘중에 하나만 골라. yes or yes 

 

yes를 타이핑 하고 엔터를 누른다.

23초! 리소스 많아지면 엄청 걸리겠네 이거

 

위와 같이 작업 완료 메세지가 출력 되었다면

GCP 콘솔에서 Compute Engine > VM instances 메뉴로 이동하여 instance가 정상적으로 생성되었는지 확인한다.

음. 잘 생성되었군

 

다시 프로젝트 폴더에 돌아오면 terraform.tfstate 라는 파일이 생성된 것을 확인 할 수 있다.

뭐여. 갑자기 언제 생긴거여

 

이름 그대로 terraform의 state 정보를 담고 있는 파일이다.

tf 파일의 설정과 실제 리소스간의 mapping을 위한 정보와 metadata 가 담겨 있고 거대 인프라 프로비져닝시 성능향상의 효과도 있다.

default로 로컬환경에 terraform.tfstate 파일이 생성되지만 remote storage에 저장할 수도 있다.

보통 팀환경에서 로컬 state 파일을 사용할 경우 모든 팀원들이 항상 terraform 사용전에 내 파일이 가장 최종 버전의 terraform.tfstate인지 확인해야하기 때문에 remote storage를 사용하는 것이 편하다.

 

show 명령어를 사용하여 현재 state 정보를 볼 수 있다.

terraform show

끝! 자 이제 만든거 다시 지우자.

 

Destroy

Infra as Code로 인프라를 관리하면 편한것 중 하나가 생성만큼 삭제도 쉽다.

언제 GCP콘솔에서 하나하나 찾아서 delete 버튼을 누를것인가.

토이프로젝트 할때마다 그것이 귀찮아서 아예 프로젝트를 통째로 삭제하곤 했는데

매번 프로젝트 삭제하고 다시 생성하고 api들 enable하고 service account 만들고 그런짓을 할 필요가 없다.

destroy 명령어로 tf에 설정된 리소스들을 간단히 제거 할 수 있다.

plan 명령어에 destroy  옵션으로 어떤 리소스들이 제거될지 확인할 수 있다.

terraform plan -destroy

Terraform 으로 흥한 리소스 Terraform으로 망하리라

 

destroy 명령어를 실행하면 apply 명령어 처럼 plan을 보여주고 이대로 진행할것인지 의사를 묻는다.

하나만 선택해 어서 yes or yes

 

yes를 타이핑하고 엔터.

만들때는 23초였는데 제거할때는 2분 13초네

 

위와 같이 destroy 성공 메세지가 출력되면 GCP콘솔의 Compute Engine > VM instnaces 메뉴로 이동하여 instance가 정상적으로 제거되었는지 확인한다.

감쪽같이 사라짐

 

 

끝으로 (Why Infra as Code?)

간단하게 Terraform으로 GCP instance를 생성/제거 해보았다.

GCP 콘솔로도 간단하게 할 수 있는 작업이지만,

프로젝트 규모가 커지고 관리하는 인프라 리소스가 많아지면 어느순간 콘솔로 관리할 수 없는 시점이 오기 마련이다.

어느 리소스가 언제 변경 되었는지 어떻게 기억 할 것인가.

Terraform, ansible이나 GCP의 Deployment manager 같은 Infrastructure as Code 도구를 사용하면 많은 이점이 있다.

일단 말 그대로 인프라가 코드로 관리된다.

이게 스크립트 하나만 구동하면 전체 아키텍쳐 인프라 구성요소들이 뿅뿅 간단하고 빠르게 생성되게 해준다.

항상 설정이 일정하기 때문에 같은 환경으로 새로운 인프라를 뚝딱 만들어낼 수도 있어 개발, 테스트 효율이 높아진다.

또 코드이기 때문에 깃헙같은 소스 repository에서 코드 변경 히스토리 및 버전 관리를 할 수 있고

누가 언제 어떻게 인프라를 변경했는지가 투명하게 공개되며

코드 내용을 검색도 할 수 있고

인프라 변경에 대한 코드 리뷰도 가능하다.

이러한 장점들로 인해 인프라 운영 risk가 최소화되고 직접 수동으로 해야하는 작업들이 줄어들어 좀 더 효율적으로 인프라를 운영할 수 있게 해준다.

 

그러니까 Infra as Code 쓰자. 두번 쓰자.

 

끗.

 

Reference

Terraform을 이용한 Infrastructure as Code 실전 구성하기 :: 변정훈::AWS Summit Seoul 2018

Qwiklabs: Terraform Fundamentals

Getting Started with Terraform on Google Cloud Platform

Terraform Documentation

'DevOps > Terraform' 카테고리의 다른 글

Terraform GCP resource dependencies  (0) 2019.09.04
Terraform GCP Credentials  (0) 2019.09.04
댓글