베하 ~~~~~
수 지 타 산 입니다 !
다들 잘 지내셨나요?
날씨가 따뜻해지는 만큼 겉옷도 얇아지고 있네요!
곧 벚꽃이 필 생각을 하니 행복해요
오늘도 함께 시작해보아요.
1. 테라폼이란
테라폼 (Terraform) 은 하시코프에서 제공하는 클라우드 인프라 환경 배포 툴이다.
Ansible이나 Chef와 비슷하다고 생각할 수 있으나, 테라폼은 '특정 클라우드 환경' 을 배포하는 것에 좀 더 초점이 맞춰져 있다는 것이 다르다. Ansible은 일반 서버,가상 머신, 심지어 라즈베리파이에서도 SSH를 통해 동일한 환경을 배포할 수 있는 반면, 테라폼은 AWS, GCP 등의 클라우드 플랫폼 위에서 환경을 배포할 때 주로 사용한다. 그러나 코드로서 인프라를 정의한다는 개념 자체는 Ansible과 같은 환경 배포 툴과 동일하며, 일반 베어메탈 서버가 아닌 특정 클라우드 플랫폼의 특징에 맞는 환경을 코드로서 배포한다는 점이 다르다.
코드로서 인프라를 정의하기 & 재현 가능한 인프라
테라폼의 웹페이지에서 강조하는 것이
Infrastructure as a Code (코드로서 인프라를 정의하기), Reproducible Infrastructure (재현 가능한 인프라) 이다.
AWS든, GCP든, Azure든 클라우드 인프라 환경을 코드로서 정의해 사용함으로써 동일한 인프라를 재현할 수 있다는 뜻이다.
클라우드 인프라를 코드로 명시적으로 정의하니 여러번 실행해도 동일한 환경이 생성될것이다.
간단한 예시로서 테라폼을 사용하지 않았을 때, 사용할 때의 차이점을 생각해보자.
테라폼 도입 전
- 나는 10.0.0.0/16의 VPC, 10.0.1.0/24의 Subnet, 이를 연결해주는 Gateway, 내부 전용 NAT, Ubuntu 18.04 인스턴스를 생성하려고 한다. 그러나 이러한 일련의 작업을 AWS 관리 콘솔 사이트에서 직접 수행하는 것은 매우 귀찮은 일이며, 이러한 설정이 더욱 세밀해지고 복잡해질수록 사람이 직접 관리하기 어려워진다.
그런데 동일한 클라우드 설정 환경을 10개의 부서에 동일하게 제공해야한다고 생각해보자. 당신은 Ansible, Chef 등의 클라우드 인프라 자동 배포 툴과 aws CLI의 사용 방법을 알고 있지만, 이러한 툴들은 10개 부서에 동일한 클라우드 설정 환경을 배포해야하는 요구사항에는 부합하지 않는 것 같다. 이를 자동화할 방법이 있다면 클라우드 환경의 배포는 더욱 쉬워질것이다.
테라폼 도입 후
- 미리 준비한 테라폼 템플릿들을 사용하면 원하는 환경을 클라우드에 배포할 수 있다. 예를 들어 VPC는 vpc.tf라는 파일에, EC2 인스턴스는 instance.tf에, Subnet은 subnet.tf 파일에 저장한 뒤 테라폼을 실행시키기만 하면 동일한 환경을 클라우드에서 완벽하게 재현할 수 있다. 이러한 클라우드 설정 환경은 직접 사람이 일일이 작업하는 것이 아니라, HCL (Hashicorp Configuration Language) 라고 하는 언어로 작성된 코드를 테라폼에 입력함으로서 구성된다.
모든 클라우드 설정은 코드에 의해 명시적으로 작성되기 때문에 클라우드 인프라를 동일하게 배포하는 것이 가능해진다. 다양한 요구사항에 맞도록 여러 버전의 코드를 작성해 클라우드 인프라의 리비전을 관리할수도 있다. 미리 준비해둔 테라폼 설정 파일을 테라폼에서 사용하기만 하면 복잡한 AWS 클라우드 환경을 한꺼번에 생성하고 한꺼번에 삭제할수도 있다.
2. 테라폼 사용하기 - Quickstart
테라폼을 이용해 아래의 과정을 진행함으로써 사용법을 학습한다.
(1) SSH 키 가져오기 -> (2) 네트워크 관련 오브젝트 생성하기 -> (3) 보안 그룹 및 Rule 생성하기 -> (4) EC2 인스턴스 생성하기
테라폼 설치
리눅스를 기준으로, 아래의 명령어로 간단하게 테라폼 실행 바이너리 파일을 내려받을 수 있다.
2019년 3월 15일 기준으로, 사용할 수 있는 테라폼 최신 버전은 0.11.13이다.
[root@keystone terraform-example] wget https://releases.hashicorp.com/terraform/0.11.13/terraform_0.11.13_linux_amd64.zip
[root@keystone terraform-example] unzip terraform_0.11.13_linux_amd64.zip
[root@keystone terraform-example] rm terraform_0.11.13_linux_amd64.zip
[root@keystone terraform-example] mv terraform /usr/bin && sudo chmod +x
테라폼의 버전을 확인한다.
[root@keystone terraform-example]# terraform -v
Terraform v0.11.13
테라폼 사용 준비
나는 terraform-example이라고 하는 빈 디렉터리를 새롭게 만든 뒤, 해당 디렉터리 안에서 모든 작업을 수행하였다.
[root@keystone terraform-example]# pwd
/root/terraform-example
가장 먼저 특정 클라우드 프로바이더를 정한 뒤, 해당 프로바이더를 사용하기 위한 설정을 저장해야한다. 프로바이더는 위에서 언급했던대로 AWS, GCP 등 여러가지를 사용할 수 있지만 여기서는 AWS를 기준으로 한다.아래의 내용으로 aws-provider.tf 파일을 저장한다.
[root@keystone terraform-example] cat aws-provider.tf
provider "aws" {
access_key = "<ACCESS_KEY>"
secret_key = "<SECRET_KEY>"
region = "ap-northeast-2"
}
access_key와 secret_key는 AWS 관리 콘솔의 IAM에서 적절히 얻어와 입력한다. region은 서울 리전을 사용하였다.
위와 같은 .tf 파일은 HCL (Hashicorp Configuration Language) 라고 하는 별도의 언어로 작성한다.
테라폼을 사용하기 위해서는 테라폼 초기화 작업이 필요하다. terraform init 명령어를 사용해 테라폼 디렉터리를 초기화한다.
[root@keystone terraform-example] terraform init
Initializing provider plugins...
- Checking for available provider plugins on https://releases.hashicorp.com...
- Downloading plugin for provider "aws" (2.2.0)...
...
If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.
AWS를 위한 플러그인 등을 내려받아 현재 테라폼 디렉터리를 초기화하는 것을 확인할 수 있다. 디렉터리 구조를 확인해보면 aws에 관련된 파일들이 .terraform 디렉터리에 위치하고 있다. 만약 인프라의 리비전 관리를 위해 테라폼 파일들을 github에서 관리한다면, .gitignore에 추가해주는 것이 좋을 듯 하다.
[root@keystone terraform-example] tree -a
.
├── aws-provider.tf
└── .terraform
└── plugins
└── linux_amd64
├── lock.json
└── terraform-provider-aws_v2.2.0_x4
3 directories, 3 files
이로서 테라폼에서 AWS를 사용하기 위한 설정은 완료되었다.
여기까지 테라폼의 개념과
테라폼을 사용하기 위한 기초 순서를 알아보았어요.
고생하셨습니다!
다음에는 테라폼을 이용한 작업을 진행해 볼까해요
다음시간에도 함께해요
제에에에에에발 ~~~
'CSP (Cloud Service Provider) > AWS' 카테고리의 다른 글
[AWS] AppSync (0) | 2023.03.24 |
---|---|
[AWS] 테라폼 실습 (0) | 2023.03.12 |
[AWS] ECS 실습 (0) | 2023.02.27 |
[AWS] EKS 실습 (0) | 2023.02.20 |
[AWS] ECS (0) | 2023.02.12 |
댓글