일단 테라폼 도구에 대해 간단하게 역사에 대해 알아보자
테라폼(Terraform)은 하시코드(Hashicorp)에서 오픈소스로 개발중인 인프라스트럭처 관리 도구입니다.
서비스 실행에 필요한 환경을 구축하는 도구라는 점에서 셰프(Chef)나 앤서블(Ansible)같은 설정 관리 도구와 더불어 프로비저닝 도구로 분류됩니다.
테라폼은 도구로서의 인프라스트럭처(Infstructure as Code)를 지향하고 있는 도구로서,
GUI나 웹 콘솔을 사용해 서비스 실행에 필요한 리소스를 관리하는 대신 필요한 리소스들을 선언적인
코드로 작성해 자동으로 실행 계획을 생성하고, 리소스 간의 종속성을 식별하고, 구성 요소를 올바른 순서로 프로비저닝하여 관리할 수 있도록 해줍니다.
예를 들어, 가상 머신(VM)이 프라이빗 클라우드(VPC)에 종속된 경우 Terraform은 VM을 프로비저닝하기 전에 VPC가 생성되었는지 확인합니다.
VPC(Virtual Private Cloud)
퍼블릭 클라우드 환경 내에서 사용자가 직접 정의하고 제어할 수 있는 논리적으로 격리된 자신만의 프라이빗 가상 네트워크 공간 입니다.
테라폼의 기본 개념들
일단 테라폼을 자세하기 알아가기 전에 테라폼에 대한 기본 개념들 부터 간단하게 알아가보자
프로비저닝(Provisioning)
어떤 프로세스나 서비스를 실행하기 위한 준비 단계를 프로비저닝이라고 이야기 합니다.
프로비저닝에는 크게 네트워크나 컴퓨팅 자원을 준비하는 작업과
준비된 컴퓨팅 자원에 사이트 패키지나 애플리케이션 의존성을 준비하는 단계로 나뉘어 집니다.
명확한 경계는 불분명하지만 테라폼은 전자를 주로 다루는 도구 입니다.
프로바이터(Provider)
테라폼과 외부 서비스를 연결해주는 기능을 하는 모듈입니다.
예를 들어 테라폼으로 AWS 서비스의 컴퓨팅 자원을 생성하기 위해서는
aws 프로바이더를 먼저 셋업해야 합니다.
프로 바이더로는
- aws, Google Cloud Platform, Microsoft Azure와 같은 범용 클라우드 서비스를 비롯해
Github, Datadog, DNSimple과 같은 특정 기능을 제공하는 서비스
MySQL, RabbitMQ, Docker와 같은 로컬 서비스 등을 지원합니다.
전체 목록은 테라폼 프로바이더 에서 찾아볼수 있습니다.
리소스(자원)Resource
리소스란 특정 프로바이더가 제공해주는 조작 가능한 대상의 최소 단위입니다.
예를들어
AWS프로바이더는 aws_instance 리소스 타입을 제공하고,
이 리소스 타입을 사용해 Amazon EC2의 가상 머신 리소스를 선언하고 조작하는 것이 가능합니다.
EC2 인스턴스, 시큐리티 그룹, 키 페어 모두 aws프로바이더가 제공해주는 리소스 타입입니다.
HCL(Hashicorp Configuration Language)
HCL은 테라폼에서 사용하는 설정 언어 입니다.
테라폼에서 모든 설정과 리소스 선언은 HCL을 사용해 이루어집니다.
테라폼에서 HCL 파일의 확장자는 .tf를 사용합니다.
Terraform은 어떻게 작동할까?
Terraform은 애플리케이션 프로그래밍 인터페이스(API)를 통해 클라우드 플랫폼 및 기타 서비스 리소스를
생성하고 관리합니다.
Terraform은 Amazon Web Service(AWS), Microsoft Azura, Google Cloud, Github, IBM Cloud, Docker를 비롯한 액세스 가능 API를 통해 거의 모든 플랫폼 또는 서비스에서 작동합니다.
- 쓰기(Write)
- 계획(Plan)
- 적용(Apply)
1. 쓰기(write)
개발자는 사람이 읽을 수 있는 구성 파일을 작성하여 원하는 인프라에 대한 리소스 구성을 정의합니다.
간단하게 인프라에 대한 계획 문서(인프라 구성도)라고 생각하면 쉬울것 같습니다.
이 파일은 선억적 파일로, 개발자가 원하는 인프라에 대해 설명하지만 프로비저닝 방법은 설명하지 않습니다.
2. 계획(Plan)
테라폼 프로젝트 디렉터리 아래의 모든 .tf파일의 내용을 실제로 적용 가능한지 확인하는 작업을 계획 이라고 합니다.
테라폼은 이를 terraform plan 명령어로 제공하며,
이 명령어를 실행하면 어떤 리소스가 생성되고, 수정되고, 삭제될지 계획을 보여줍니다.
개발자가 가상 프라이빗 클라우드의 가상 머신에 애플리케이션을 배포하는 이전 예를 보면
- 앱을 호스팅할 새 가장 머신을 프로비저닝 합니다.
- 새 가상 시스템에 대한 트래픽을 분산하기 위해 로드 밸런서를 프로비저닝 합니다.
- 가상 머신 간에 트래픽을 분산하기 위해 로드 밸런서를 프로비저닝 합니다.
이 과정 전체를 계획 이라고 보면 됩니다.
3. 적용(Apply)
테라폼 프로젝트 디렉터리는 아래의 모든 .tf 파일의 내용대로 리소스 종속성을 고려하여 올바른 순서로 생성, 수정, 삭제하는 일을 적용합니다.
여기서 중요한 것은 리소스 A가 리소스 B에 의존하는 경우 Terraform은 리소스 B가 리소스 A보다 먼저 생성되록 합니다.
예를 들어, 개발자가 VPC의 속성을 업데이트하고 해당 VPC의 가상 머신 수를 변경하면
Terraform은 가상 머신을 확장하기 전에 업데이트된 속성으로 VPC를 다시 생성합니다.
이렇게 테라폼에서 생성, 수정, 삭제하는 이를 terraform apply 명령어로 제공합니다.
이 명령어를 실행하기 전에 변경 예정 사항은 plan 명령어를 사용해 확인할 수 있습니다.
적용하기 전에도 플랜의 결과를 보여줍니다.
이제 간단한 웹 애플리케이션을 아마존 웹 서비스에 배포하는 상황을 가정해 보겠습니다.
이 애플리케이션은 EC2 가상 머신에서 동작하며, RDS 데이터베이스에 데이터를 저장합니다.
- step: 먼저 아마존 웹 서비스 계정을 준비하고, API키를 설정합니다.
- step: 인프라스트럭처를 정의하는 HCL 언어로 필요한 리소스를 선언합니다.
- step: 선언된 리소스들이 생성가능한지 계획(Plan)을 확인합니다.
- step: 선언된 리소스들을 아마존 웹 서비스에 적용(Apply)합니다.
- step: 웹 애플리케이션을 배포합니다.
step1 아마존 웹 서비스 설정
테라폼은 인프라스트럭처 리소스를 선언할 수 있는 도구로서 다양한 서비스들을 지원합니다.
테라폼에서는 이를 프로바이더Providers라고 부릅니다.
테라폼은 다양한 프로바이더를 지원하지만, 이 중에서 가장 중요한 프로바이더는 단연 클라우드 서비스입니다.
대표적으로는 아마존 웹 서비스(Amazon Web Service), 마이크로소프트 애저(Microsoft Azure),
구글 클라우드 플랫폼(Google cloud Platform)이 있습니다.
여기서는 아마존 웹 서비스의 리소스를 테라폼으로 작성해나가겠습니다.
아마존 웹 서비스 프로바이더를 사용하기 위해서는 먼저 AWS 계정이 있어야 합니다.
이번 실습에서는 서울 리전을 사용하며, 계정 생성 시 함께 만들어지는 기본 VPC를 사용한다고 가정합니다.
아마존 루트 계정에 액세스 키를 발급하고 아래의 내용을 진행하는 것도 가능합니다.
하지만 루트 계정을 직접 사용하는 것은 권장하지 않습니다.
terraform 이라는 이름으로 IAM 사용자를 생성하고 관리자 권한을 부여해 진행 할 것을 추천합니다.
클라우드 서비스는 사용한 만큼 비용이 발생하므로 주의가 필요합니다.
자세한 내용은 각 서비스 요금 페이지를 참고해주세요
step2 HCL로 리소스 정의하고 AWS에 프로비저닝
- step1: 인프라스럭처를 정의하는 HCL 언어로 필요한 리소스를 선언합니다.
- step2: 선언된 리소스들이 생성가능한지 계획(Plan)을 확인합니다.
- step3: 선언된 리소스들을 아마존 웹 서비스에 적용(Apply)합니다
EC2와 RDS 리소스를 생성하기 위해 4개의 리소스
aws_key_pair, aws_security_group, aws_instance, aws_db_instance를 정의해 나갈 것입니다.
먼저 테라폼에 aws 프로바이더를 정의해야 합니다.
AWS 프로바이더 정의
먼저 프로젝트 디렉터리와 테라폼 파일 몇 개를 생성합니다.
$ mkdir web_infra
$ cd web_infra
$ touch provider.tf web_infra.tf디렉터리 이름과 파일 이름에 특별한 원칙은 없습니다.
테라폼은 기본적으로 특정 디렉터리에 있는 모든 .tf 확장자를 가진 파일을 전부 읽어들인후,
리소스 생성, 수정, 삭제 작업을 진행합니다.
파일은 상황에 따라 적절히 나눠줄 필요가 있지만,
여기서는 작성할 내용이 많지 않기 때문에 provider.tf와 web_infra.tf 두개로 나눠서 작성해 보겠습니다.
먼저 provider.tf 파일을 작성합니다.
.tf 확장자 파일은 HCL 언어로 작성됩니다.
HCL은 Hashicorp Configuration Language의 줄임말로 테라폼이나 다른
하시코프 애플리케이션에서 사용하기 위해 만들어진 설명 언어 입니다.
HCL로 다음과 같이 AWS 프로바이더를 정의합니다.
provider "aws" {
access_key = "<AWS_ACCESS_KEY>"
secret_key = "<AWS_SECRET_KEY>"
region = "ap-northeast-2"
}이 때 <AWS_ACCESS_KEY> 와 <AWS_SECRET_KEY> 는 앞서 생성한 terraform 사용자의
인증 정보로 대체해줍니다.
region은 리소스를 정의할 AWS 리전을 설명합니다.
여기서 사용한 ap-northest-2는 AWS의 서울리전을 의미합니다
provider "<PROVIDER_NAME>"위의 예제에는 aws 프로바이더를 사용하므로 <PROVIDER_NAME> 자리에 aws가 왔습니다.
프로바이더 선언 뒤로 중괄호 블록이 따라올 수 있습니다.
prover "<PROVIDER_NAME>" { }중괄호 사이에는 프로바이더에서 사용가능한 하나 이상의 속성(config)들을 지정할 수 있습니다.
provider "<PROVIDER_NAME>" {
<ATTR_NAME> = "<ATTR_VALUE>"
}위에서 정의한 내용을 다시 살펴보면 aws 프로바이더를 선언하고,
이 프로바이더에 access_key, secret_key, region 속성을 지정했다고 이해할 수 있습니다.
참고로 뒤에서 다루게 될 리소스 저으이도 프로바이더 정의와 크게 다르지 않습니다.
여기서는 3가지 속성만을 지정했지만,
aws 프로바이더는 더 다양한 속성들을 지원합니다.
aws 프로바이더 정의 블록에서 사용할 수 있는 모든 옵션은 테라폼 공식 문서 AWS 프로바이더의
인자 레퍼런스 Argument Reference 절에서 찾아볼 수 있습니다.
노트환경변수로 AWS 프로바이더 설정
AWS 프로바이더를 설정할 때 파일 안에 액세스 키를 기록했습니다.
테라폼은 코드로 작성되기 때문에 다른 프로그래밍 언어 소스 코드와 마찬가지로Git과 같은 버전 관리 도구에서 관리하는 게 일반적 입니다.
따라서 민감한 정보를 저장소에 기록해서는 안 됩니다.
이러한 문제를 피하기 위해 인증 정보를 프로바이더 속성값을 사용하지 않고
테라폼을 실행하는 환경에 직접 환경변수로 정의하는 방법을 사용할 수 있습니다.
이 때 사용하는 환경변수는 AWS 커맨드라인 인터페이스 AWSCLI에서 사용하는 환경 변수와 같습니다.
$ export AWS_ACCESS_KEY_ID="<AWS_ACCESS_KEY_ID>" # access_key $ export AWS_SECRET_ACCESS_KEY="<AWS_SECRET_ACCESS_KEY>" # secret_key $ export AWS_DEFAULT_REGION="ap-northeast-2" # region
이러한 환경변수를 정의하면 프로바이더에서 대응하는 옵션들을 생략할 수 있습니다. 자세한 내용은 AWS 커맨드라인 인터페이스(awscli)기초 환경변수 절을 참고해주세요
테라폼 프로젝트 초기화
현재 사용하는 버전이 0.10보다 낮다면 테라폼 프로젝트를 별도로 초기화하지 않아도 됩니다.
0.10이전에는 테라폼 본체에 프로바이더들이 포함되어 있었지만
0.10부터 프로바이더가 플러그인으로 분리되었고,
이에 따라서 태라폼 프로젝트를 별도로 초기화해야 합니다.
테라폼은 테라폼 프로젝트를 초기화할 때 프로바이더 설정을 보고 필요한 플러그인들을 설치합니다.
web_infra 디렉터리에서 terraform init 명령어를 실행합니다.
$ terraform init
Initializing the backend...
Initializing provider plugins...
- Checking for available provider plugins...
- Downloading plugin for provider "aws" (hashicorp/aws) 2.53.0...
...
Terraform has been successfully initialized!테라폼을 현재 디렉터리에 아래에 선언된 프로바이더 플러그인을 설치해줍니다.
이제 프로젝트 디렉터리에서 terraform version 명령어를 실행하면
테라폼 프로젝트에서 사용중인 프로바이더들의 버전도 함게 보여줍니다.
$ terraform version
Terraform v0.12.23
+ provider.aws v2.53.0
노트테라폼의 버전과 프로바이더의 버전
테라폼 버전에서 테라폼의 버전과 프로바이더 버전이 따로 출력된다는 의미는
두 버전이 따로 관리된다는 의미 입니다.
테라폼을 사용하다보면 테라폼의 버전과 프로바이더 버전에 따라서 미묘하게
실행 결과가 다른 경우가 상당히 많이 있습니다.따라서 가능하면 테라폼과 프로바이더의 버전을 프로젝트에 고정해서
사용하고 명시적으로 업데이트 하는 것을 권장합니다.예를 들어 다음 코드로 테라폼 버전을
0.12.23, aws프로바이더는2.53.0이상으로 고정할 수 있습니다.
이 내용은 프로바이더 정의 파일에 같이 작성해줍니다.terraform { required_version = "0.12.23" required_providers { aws = ">= 2.53.0" } }이제 이 코드는 테라폼
0.12.23에서만 동작합니다.
프로바이더가 설치되지 않은 상태에서 초기화할 경우 aws2.53.0이상 버전의 프로바이더를 설치해줍니다.
그 이하 버전이 설치되어있는 경우 동작하지 않으며 다시 초기화해서 프로바이더를 다시 설치해야합니다.
첫 번째 이터레이션: EC2 용 SSH키 페어 정의
프로바이더 셋업이 테라폼을 사용하기 위한 준비 작업이었다면 이제 AWS 리소스를 정의할 차례입니다.
첫 번째 리소스는 aws_key_pair 입니다.
이 리소스는 EC2 인스턴스를 생성하기 위해 필요합니다.
AWS에서 제공하는 가상 컴퓨팅 자원인 EC2 인스턴스를 생성하더라도 키 페어가 미리 정의되어 있지 않다면,
생성한 인스턴스에 접근할 수 없습니다.
따라서 인스턴스를 생성하기 전에 먼저 키 페어를 생성해야 합니다.
첫 번째 step: HCL 언어로 필요한 리소스를 정의
첫 번째 스템은 HCL로 리소스를 정의하는 일입니다.
리소스 정의 형식은 프로바이더와 비슷합니다.
web_infra.tf 파일에 다음 내용을 추가해 줍니다.
여기서 주목할 부분은 resource 키워드 다음에 "aws_key_pair" "web_admin"과 같이
두 개의 문자열이 온다는 점입니다.
첫 번째 문자열은 리소스 타입의 이름입니다.
따라서 이 자리에 올 수 있는 값들은 프로바이더에서 제공하는 리소스 타입의 이름들로 한정되어 있습니다.
리소스 이름에서 관습적으로 프로바이더 이름에 언더스코어 붙여 전치사(Prefix)로 사용합니다.
즉, 리소스 이름 aws_key_pair에서 aws 프로바이더가 제공하는 key_pair 리소스라는 것을 유추할 수 있습니다.
두 번째 문자열은 web_admin은 리소스에 임의로 붙이는 이름입니다.
이 이름은 테라폼 코드의 다른 곳에서 리소스를 참조하기 위해서 사용합니다.
참고문헌
