CloudNet@ 팀의 가시다님께서 Leading 하시는 Terraform T101 Study 내용 요약
해당 Terraform Study 는 Terraform Up and Running 책을 기반으로 진행 중입니다.
이번 게시글은 책에 나와있는 DevOps, IaC 에 관한 이론적 내용이며, Terraform 실습은 다음 게시글부터 진행하겠습니다.
1. Cloud Service의 등장
하드웨어 인프라를 사용한만큼 비용을 지불하는 서비스
기존의 조직들이 소프트웨어를 서비스하기 위해서는 수많은 하드웨어를 먼저 설치하는 작업을 선행하고,
그 위에 소프트웨어를 개발하여 실행하여야 했습니다.
때문에 얼마 전까지만 해도 하드웨어를 관리하는 운영팀(Ops), 소프트웨어를 개발하는 개발팀(Dev)는 철저하게 분리되어 있었습니다.
하지만 오늘 날에는 중대한 변화가 일어나고 있는데, 이유는 바로 클라우드(Cloud) 서비스의 등장 때문입니다.
클라우드를 사용함으로써 조직들이 가지고 있던 하드웨어적 부담을 덜게 되면서, 소프트웨어적 역량에 집중하기 시작했습니다.
현재 흐름은 데이터 센터 -> 클라우드 서비스 (AWS, Azure, GCP 등) 로의 이동
그러면서 운영팀(Ops)들 또한 셰프(Chef), 퍼핏(Puppet), 테라폼(Terraform), 도커(Docker) 같은 도구를 사용하여 소프트웨어 작업에 많은 시간을 투자하고 있습니다.
2. DevOps의 등장
데브옵스는 소프트웨어를 효율적으로 전달하는 프로세스
결과적으로 현재는 운영팀과 개발팀이 모두 소프트웨어 작업에 많은 시간을 투자하게 되면서 두 팀 간의 경계가 모호해지고 있습니다.
지금도 여전히 두 팀을 따로 두는 곳이 굉장히 많지만, 예전에 비해 두 팀 간의 협력이 굉장히 많이 요구되고 있는 추세입니다.
때문에, 두 팀간의 교두보 역할을 할 수 있는 DevOps라는 포지션이 등장하기 시작했습니다.
DevOps의 4가지 핵심 가치 (CAMS)
- 문화(Culture)
- 자동화(Automation)
- 측정(Measurement)
- 공유(Sharing)
3. 코드형 인프라(IaC) 란??
코드를 작성 및 실행하여 인프라를 생성, 배포, 수정, 정리하는 것
클라우드 서비스가 본격적으로 사용되면서 서버, 네트워크 등의 물리적 하드웨어 인프라를 소프트웨어 측면에서 활용할 수 있게 되었습니다.
데브옵스의 핵심은 서버, 데이터베이스, 네트워크, 로그 파일 등의 거의 모든 것을 코드로 관리할 수 있는 것입니다.
코드형 인프라(IaC, Infrastructure as Code)는 그 중 하나의 문화이자 기술이며,
코드형 인프라에는 5가지 범주가 있습니다.
3.1. 애드혹 스크립트 (ad hoc script)
수행할 각 단계를 코드로 정의하고 작성된 스크립트를 서버에서 수동으로 실행
# setup-webserver.sh 내용
sudo apt-get update
sudo apt-get install -y php apache2
sudo service apache2 start
3.2. 구성 관리 도구
Chef, Puppet, Ansible 등의 소프트웨어를 설치하고 관리하도록 설계된 도구
애드혹 스크립트와 비교하여 아래와 같은 장점 보유
- 코딩 규칙 (Coding Convention)
코드 일관화, 예측가능하고 쉬운 탐색 가능
- 멱등성 (Idmpotence)
여러 번 반복해서 실행하더라도 항상 동일하게 작동하는 것
- 분산형 구조 (Distribution)
다수의 원격 서버 관리 용이
3.3. 서버 템플릿 도구
Docker, Packer, Vagrant 등 동일한 코드로 서버 배포 및 설정 가능
이미지 작업을 위해 가상머신 혹은 컨테이너 등이 필요
한 번 만들어진 이미지는 불변(Immutable)함으로 변경이 필요하다면 새로 이미지를 생성하여야 합니다.
3.4. 오케스트레이션 도구
서버 템플릿 도구 관리를 위한 도구
3.5. 프로비전 도구
인프라 자체를 생성하는 도구
- Terraform, CloudFormation 등
4. Terraform 이란??
Terraform 은 HashiCorp 에서 Go언어로 개발된 오픈 소스 프로비전 도구
- Terraform 바이너리가 AWS / Azure / GCP 등의 공급자를 대신해 API 를 호출하여 리소스 생성
- Terraform은 생성하고자 하는 인프라 정보가 담긴 테라폼 구성 파일을 생성하여 API 호출
4.1. 선언적 언어 (Declarative) 사용
원하는 최종 상태를 지정하는 방식
4.2. 기본 개념
1. resource
실제로 생성할 인프라 자원을 의미
EC2, ELB, VPC 등
// Example
resource "aws_instance" "ubuntu" {
ami = "ami-0e9bfdb247cc8de84"
}
2. provider
Terraform 으로 정의할 Infrastructure Provider를 의미
AWS, Azure, GCP 등
// Example
provider "aws" {
region = "ap-northeast-2"
}
3. output
Terraform 출력 변수
인프라 배포 후 생성된 자원을 Output으로 선언하여, 이후 remote state에 사용 가능
// Example
output "s3_bucket_arn" {
description = "S3 Bucket arn"
value = aws_s3_bucket.backend.arn
}
4. backend
Terraform 상태를 저장할 공간을 지정하는 부분
외부에 저장하여 다른 사람과 협업 가능
// Example
terraform {
backend "s3" {
bucket = "s3-terraform-example"
key = "example/terraform.tfstate"
region = "ap-northeast-2"
dynamodb_table = "state-lock-example"
}
}
5. module
공통적으로 활용할 수 있는 인프라 코드를 한 곳으로 모아서 정의
모듈을 사용하면 변수만 변경하여 동일한 리소스 배포가 가능
/// Example module "vpc"
{ source = "../example/01.vpc"
// 아래와 같이 변수만 변경하여 사용 가능
vpc_cidr = 10.0.0.0/16
}
6. remote state
VPC, IAM 등과 같이 공통 리소스 사용 가능
terraform.tfstate 파일이 저장된 backend 위치를 명시하여 output 정보를 가져온다.
/// Example, example/terraform.tfstate 파일에 위치한 vpc 정보를 가져옴
data "terraform_remote_state" "vpc" {
backend = "s3"
config = {
bucket = "s3-terraform-example"
key = "example/terraform.tfstate"
region = "ap-northeast-2"
}
}
이번 게시글에서는 Terraform 에 대한 기초적인 이론을 학습했습니다.
다음 게시글에서는 실제 로컬에서 Terraform 을 실행하기 위한 환경을 구성해보겠습니다.