테라폼 기본 문법 및 사용법

Terraform개요

• 테라폼은 프로그램 코드를 통해 인프라 서버를 구축/운영 할 수 있게 해주는 오픈 소스 소프트웨어 입니다.
• 코드형 인프라를 뜻하는 "IAC(Infra as a code) 도구(Tool)" 입니다.

코드형 인프라(Infrastructure as Code)란?

• 코드를 작성 및 실행하여 인프라를 생성, 배포, 수정, 정리하는 것을 말함
• 이는 서버를 물리적으로 설치하는 등의 하드웨어 측면을 포함하여 운영의 모든 측면을 소프트웨어적으로 생각할 수 있도록 도와줌
  → 데브옵스의 핵심은 서버, 데이터베이스, 네트워크, 로그 파일, 애플리케이션 구성, 문서, 자동화된 테스트, 배포 프로세스 등 거의 모든 것을 코드로 관리할 수 있다는 것이다

코드형 인프라 도구 종류

1. 애드혹 스크립트
   : 수행할 작업을 단계별로 나누고 bash, ruby, python 등 선호하는 언어를 사용하여 각 단계를 코드로 정의하고 작성된 스크립트를 서버에서 수동으로 실행하는 것을 말함. 소규모 일회성 작업에 적합함.

2. 구성 관리 도구
   :  셰프, 퍼핏, 앤서블, 솔트스택 등은 모두 구성 관리 도구로써 대상 서버에 소프트웨어를 설치하고 관리하도록 설계되어 있다.

 

애드혹 스크립트와 목적은 같지만 아래와 같은 장점이 있다.

 

• 코딩 규칙 일관되고 예측 가능한 코딩 규칙이 포함되어 있어 코드를 쉽게 탐색할 수 있다.

• 멱등성 실행 횟수에 관계없이 올바르게 동작하는 멱등성을 가진 코드로 작성할 수 있다.

• 분산형 구조에서의 배포 애드혹 스크립는 단일 로컬 머신에서만 실행되도록 설계되어 있는 반면 구성 관리 도구는 원격의 수많은 서버를 관리하기 위해 특별히 설계되어 있다.

 

3. 서버 템플릿 도구

    : 여러 서버를 시작하고 각각 동일한 코드를 실행하여 서버를 구성하는 기존 방식과 다르게, 서버 템플릿 도구는 운영체제, 소프트웨어, 파일 및 기타 필요한 모든 내용을 포함하고 있는 ‘스냅숏(snapshot)’으로 이미지를 생성한다.

 

앤서블과 같은 코드형 인프라 도구를 사용하여 모든 서버에 이미지를 설치할 수 있다.

 

4. 오케스트레이션 도구

   : 서버 템플릿 도구는 VM이나 컨테이너를 생성하기에 더없이 좋은 도구지만 아래와 같은 관리가 어렵다.

 

• VM과 컨테이너를 하드웨어에 효율적으로 배포하기

• 기존의 VM이나 컨테이너를 효율적으로 업데이트하거나 롤백하기

• VM과 컨테이너의 상태를 모니터링하고 비정상적인 부분을 자동으로 대체하기(자동복구)

• 발생하는 트래픽에 따라 VM과 컨테이너의 수를 늘리거나 줄이기(자동확장)

• VM과 컨테이너의 트래픽을 분산하기(부하분산)

• 서로 다른 네트워크에 있더라도 VM과 컨테이너가 서로 식별하고 통신할 수 있게 하기(서비스 검색)

 

이 작업들을 처리하기 위해 쿠버네티스, 마라톤/메소스, AWS ECS, 도커 스웜, 노마드같은 오케스트레이션 도구가 필요하다 .

 

5. 프로비젼 도구
   : 구성 관리, 서버 템플릿 및 오케스트레이션 도구가 각 서버에서 실행되는 코드를 정의한다면, 테라폼(terraform), 클라우드 포메이션(AWS Cloudformation), 오픈스택 히트(OpenStack Heat)와 같은 프로비전 도구는 서버 자체를 생성한다.

 

사실상 프로비전 도구를 사용하면 서버만 생성하는 것이 아니라 데이터베이스, 캐시, 로드밸런서, 큐, 모니터링, 서브넷 구성, 방화벽 설정, 라우팅 규칙 설정, SSL 인증서 등 인프라에 관한 거의 모든 부분을 프로비저닝할 수 있다. 

 

코드형 인프라의 장점

1. 자급식 배포(Self-service)
   : 코드를 수동으로 배포하는 대부분 팀에서는 배포를 수행하는데 필요한 ‘마법의 명령어’를 알고 있는 소수의 시스템 관리자만 프로덕션 환경에 접속하여 배포를 진행한다. 이것은 회사가 성장하는데 장애물이 된다. 인프라를 코드로 정의하면 전체 프로세스를 자동화할 수 있으며 개발자는 필요할 때마다 자체적으로 배포를 진행할 수 있다
2. 속도와 안정성(Speed and safety)
   : 배포 프로세스를 자동화하면 사람이 진행하는 것보다 훨씬 빠르게 컴퓨터가 배포를 진행할 수 있다. 자동화된 프로세스는 일관되고 반복 가능하며 수동으로 진행했을 때보다 오류가 적게 발생하기 때문에 안전하다
3. 문서화(Documentation)
   : 시스템 관리자 조직만 인프라에 관한 정보를 독점하는 것이 아니라 누구나 읽을 수 있는 소스 파일로 인프라 상태를 나타낼 수 있다. 즉, 코드형 인프라는 문서 역할을 하여 시스템 관리자가 휴가 중일 때도 조직의 모든 사람이 인프라 구조를 이해하고 업무를 처리할 수 있도록 해준다
4. 버전 관리(Version control)
   : 인프라의 변경 내용이 모두 기록된 코드형 인프라 소스 파일을 저장할 수 있으므로 버전을 쉽게 관리할 수 있다. 인프라 변경 내역이 남아 있기 때문에 시스템에 문제가 생겼을 때 문제가 발생한 지점을 찾기가 수월하다. 문제의 내용을 확인 다음 문제가 없던 이전 코드로 다시 되돌리면 문제가 해결된다
5. 유효성 검증(Validation)
   : 인프라 상태가 코드로 정의되어 있으면 코드가 변경될 때마다 검증을 수행하고 일련의 자동화된 테스트를 실행할 수 있으며, 정적 분석 프로그램에 코드를 전달하여 오류 발생 위험을 줄일 수 있다
6. 재사용(Reuse)
   : 인프라를 재사용 가능한 모듈로 패키징할 수 있으므로 모든 제품을 매번 처음부터 배포하는 대신 문서화되고 검증된 모듈로 일관되게 배포할 수 있다
7. 행복(Happiness)
   : 코드 배포나 수동적인 인프라 관리는 반복적이고 지루한 일이다. 이 작업들이 창의성을 불러일으키거나 도전 의식을 복돋우거나 성과를 인정받는 일이 아니기 때문에 기피 작업이다. 코드형 인프라는 이러한 반복적인 작업을 자동화할 수 있다

 

---

 

테라폼(Terraform)

 

1. 공급자(Provider) 및 리소스(Resource)

• AWS를 공급자로 사용하여 us-east-2 리전에 인프라를 배포한다는 것을 의미

 

각 유형의 공급자마다 서버, 데이터베이스 및 로드 밸런스와 같이 다양한 종류의 resource가 있으며 테라폼에서 리소스를 생성할 때는 다음과 같은 구문을 사용한다.

 

• PROVIDER: 공급자 이름 TYPE: instance같은 생성할 리소스 유형 NAME: 테라폼 코드에서 이 리소스를 참조할 식별자

ex)

 

• ami EC2 인스턴스를 생성하는 아마존 머신 이미지
• instance_type 실행할 EC2 인스턴스의 유형

2. 테라폼 기초 명령어

• terraform init 명령어
  : terraform에는 모든 공급자에 대한 코드가 포함되어 있지 않기 때문에 terraform init 명령어를 실행하여 테라폼에 코드를 스캔하도록 지시하고, 어느 공급자인지 확인하고, 필요한 코드(플러그인)을 다운로드 하도록 해야 함.
• terraform validate 명령어
  : 테라폼 템플릿 문법 검사
• terraform plan 명령어
  : 테라폼 빌드 검증 테스트로서 실제로 변경하기 전에 테라폼이 수행할 작업을 확인할 수 있음.
  + → 항목이 추가
  - → 항목이 제거
  ~ → 항목이 수정
• terraform apply [ --auto-approve ]
  : 테라폼 템플릿 적용
• terraform show
  : 테라폼에 의해 구성된 리소스에 대한 상태정보확인
• terraform destroy
  : 테라폼 상태정보파일을 참조하여 모든 리소스 제거

3-1. 테라폼 상태관리 개념 및 원리

• 앞서 테라폼으로 리소스를 생성하거나 업데이트할 때 terraform plan 또는 terraform apply 명령어를 실행하면 테라폼이 이전에 생성한 리소스를 찾아 적절히 업데이트할 수 있다
• 그런데 테라폼은 어떤 리소스를 관리해야 하는지 어떻게 알 수 있을까? AWS 계정에는 다양한 메커니즘을 통해 배포된 수많은 종류의 인프라가 있을 수 있는데 테라폼은 어떤 인프라가 관리 대상인지 어떻게 알 수 있을까?
• 테라폼이 인프라의 상태를 어떻게 탐지하는지, 그리고 테라폼 프로젝트의 파일 레이아웃, 격리, 잠금 등에 미치는 영향을 주는지 확인하는 것을 테라폼 상태관리라고 한다
• 원리
  : 테라폼을 실행할 때마다 테라폼은 생성한 인프라에 대한 정보를 테라폼 상태 파일에 기록한다. 기본적으로 /example 폴더에서 테라폼을 실행하면 테라폼은 /example/terraform.tfstate 파일을 생성한다. 이 파일에는 구성 파일(.tf)의 테라폼 리소스가 실제 리소스의 표현으로 매핑되는 내용을 기록하는 사용자 정의 JSON 형식이 포함되어 있다. 테라폼을 실행할 때마다 AWS에서 이 EC2 인스턴스의 최신 상태를 가져와서 테라폼의 구성과 비교하여 어느 변경 사항을 적용해야 하는지 결정한다.

3-2. 팀단위 테라폼 상태관리

• 개인 프로젝트에 테라폼을 사용하는 경우 로컬 컴퓨터의 단일 terraform.tfstate 파일에 상태를 저장하는 것이 좋다.
• 그러나 테라폼을 실제 운영 환경에서 팀 단위로 사용하고자 할 때는 다음과 같은 문제에 직면한다.
• 상태 파일을 저장하는 공유 스토리지
  : 테라폼을 사용하여 인프라를 업데이트하려면 각 팀원이 동일한 테라폼 상태 파일에 액세스해야 한다. 즉, 상태 파일을 공유 위치에 저장해야 한다.
• 상태 파일 잠금
  : 상태 데이터가 공유되자마자 ‘잠금(locking)’이라는 새로운 문제가 발생한다. 잠금 기능 없이 두 팀원이 동시에 테라폼을 실행하는 경우 여러 테라폼 프로세스가 상태 파일을 동시에 업데이트하여 충돌을 일으킬 수 있기때문이다. 

📢 해결 방안

• 여러 명의 팀원이 파일에 공통으로 액세스할 수 있게 하는 가장 일반적인 방법은 파일을 Git과 같은 버전 관리 시스템에 두는 것이다. 그러나 테라폼 상태 파일을 버전 관리 시스템에 저장하는 것은 다음과 같은 이유 때문에 부적절하다.
• 수동 오류
  : 테라폼을 실행하기 전에 최신 변경 사항을 가져오거나 실행하고 나서 푸시하는 것을 잊기 쉽다.
• 잠금
  : 대부분의 버전 관리 시스템은 여러 명의 팀 구성원이 동시에 하나의 상태 파일에 terraform apply 명령을 실행하지 못하게 하는 잠금 기능을 제공하지 않는다.
• 보안
  : 테라폼 상태 파일의 모든 데이터는 평문(plain text)으로 저장되는데 특정 테라폼 리소스에 중요한 데이터를 저장해야 할 때 문제가 발생한다.

▷▶ 때문에 상태 파일 공유 스토리지를 관리하는 가장 좋은 방법은 버전 관리 시스템을 사용하는 대신에 테라폼에 내장된 원격 백엔드 기능을 사용하는 것이다

3-3. Terraform 상태 파일 공유를 위한 원격 백엔드 구성

a.S3 서비스 : 수동오류, 보안 문제 해결

 

• bucket S3 버킷의 이름

• prevent_destroy prevent_destroy 를 true로 설정하면 terraform destroy 를 실행하는 것 같이 리소스를 삭제하려고 시도하는 경우 테라폼이 오류와 함께 종료된다. 정말로 삭제하려는 경우 주석 처리하면 된다.

• versioning S3 버킷에 버전 관리를 활성화하여 버킷의 파일이 업데이트될 때마다 새 버전을 만들도록 한다. 이를 통해 언제든지 이전 버전으로 되돌리 수 있다.

• server_side_encryption_configuration S3버킷에 기록된 모든 데이터에 서버 측 암호화를 설정한다.

 

 

b.Dynamodb : 잠금 문제 해결

• “잠금”에 사용할 DynamoDB 테이블을 생성한다.

• DynamoDB는 분산 잠금 시스템에 필요한 강력한 읽기 일관성 및 조건부 쓰기를 지원한다. 테라폼에서 DynamoDB를 잠금에 사용하려면 LockID라는 기본키가 있는 DynamoDB 테이블을 생성해야한다.

 

 

 

S3 버킷과 DynamoDB 테이블은 생성되지만 여전히 테라폼 상태는 로컬 디스크에 저장된다. 이를 해결하기 위해

 

c.원격 백엔드 구성

S3 버킷과 DynamoDB 테이블을 생성하고 테라폼 상태를 원격 백엔드에 구성하기 위해 terraform 블록을 구성한다.

 

• bucket 사용할 S3 버킷의 이름

• key 테라폼 상태 파일을 저장할 S3 버킷 내의 파일 경로 즉, terraform-up-and-running-state 버킷-global-s3- terrfrorm.tfstate 가 된다.

 

4. 테라폼 모듈

• 테라폼을 사용하면 코드를 테라폼 모듈에 넣고 전체 코드의 여러 위치에서 해당 모듈을 재사용할 수 있다.
• 이 부분은 매우 중요한 부분으로 모듈은 재사용할 수 있고 유지 관리할 수 있으며 테스트할 수 있는 테라폼 코드를 작성하는 데 있어 핵심 요소이다.

1. 일반 모듈

• terraform init, terraform apply 이런 것을 할 목적이 아니라 루트 모듈에 의해 참조가 되는 모듈
• 리소스가 정의되어 있음
• provider가 존재하지 않음, 있으면 오류난다

2. 루트 모듈

• resource 가 없고 모듈들을 불러와서 리소스 생성
• provider가 존재해야 한다
• modules 섹션과 provider 만 있고 보통 resource 섹션은 없음