[50일차] Terraform

 

IaC의 의미와 필요성

DevOps의 주요 가치 중 하나는 바로 자동화로, 코드형 인프라(Infrastructure as Code), 즉 IaC는 설정을 코드로 작성하여 클라우드 인프라스트럭처의 생성/수정/삭제를 자동화하는 방법이다.

 

• IaC의 장점

인프라를 만드는 과정이 자동화되므로, 오류가 훨씬 덜 발생하고 안전하다.

IaC는 쉽게 공유할 수 있고, 버전 관리에 용이하다.

코드와 현재 상태를 비교하여, 추후 인프라 상태의 변경에 따르는 위험을 분석하고 검증할 수 있다.

배포 과정을 소수의 시스템 관리자만 진행하는 것이 아닌, 개발자 스스로가 배포하고 인프라를 통제할 수 있는 환경으로 만들 수 있다.

 

예상치 못한 인프라 변경에 따른 사고 (Configuration Drift)

어떻게 알아내고, 어떻게 고칠까?

 

• AWS Config

잘못 설정된 것을 찾기 위한 도구로서, 바른 설정을 지정해놓고 찾아서 고칠 수 있게 만들어준다.

 

• AWS CloudFormation Drift Detection

사고 감지를 위한 도구로서, 스택에서 드리프트 감지 작업을 수행하면 스택이 예정 템플릿 구성에서 드리프트되었는지 확인하고, 드리프트 감지를 지원하는 스택의 각 리소스에 대한 드리프트 상태 관련 세부 정보를 반환한다.

 

• Terraform state files

위와 같은 관리형 서비스 보다 개발 방법에 가까운 솔루션이다.

정상 작동 상태를 파일로 저장하고, 상태 정의된 파일은 인프라의 실제 상태와의 비교 대상으로서 현재 상황을 진단/점검할 수 있다.

 

• terraform plan Command

terraform plan 명령은 실행 계획을 생성하여 Terraform이 인프라에 적용할 변경 사항을 미리 볼 수 있도록 합니다. 기본적으로 Terraform은 계획을 생성할 때 다음을 수행한다.

 

이미 존재하는 원격 개체의 현재 상태를 읽어 Terraform 상태가 최신 상태인지 확인합니다.

현재 구성을 이전 상태와 비교하고 차이점을 확인한다.

적용되는 경우 원격 개체가 구성과 일치하도록 하는 일련의 변경 작업을 제안한다.

 

IaC 종류

• 절차형 IaC

프로그래밍 언어를 이용해서 직접 순차적으로 인프라를 생성하도록 코드를 작성하는 방법이다.

선언형에 비해 더 강력한 일들을 할 수 있으나, 실제 적용된 결과를 가늠하기 어렵고, 코드를 읽기에 직관적이지 않다.

 

• EC2를 추가로 생성할 갯수를 입력한다.

절차형 프로그래밍

imperative programming === How to

원하는 결과를 절차를 통하여 얻는다.

 

절차형 프로그래밍 언어에서는 비선언적인 형태를 라이브러리나 프레임워크 등으로 캡슐화하여 선언형 프로그래밍을 흉내낸다.

 

절차형 IaC의 종류

Cloud Development Kit(CDK), Pulumi, Red Hat, Ansible

 

• 선언형 IaC

선언형 언어 JSON, YAML 등을 사용며, 실제 인프라가 적용된 결과(기대하는 상태)와 적용할 내용(YAML 등)이 직관적으로 매핑된다.

 

• 최종적으로 원하는 EC2 갯수를 입력한다.

선언형 프로그래밍

declarative programming === What is

원하는 결과를 선언한다.

 

 

선언형 IaC의 종류

CloudFormation, Blueprint, Cloud Deployment Manager, Terraform

 

 

Terraform

출처: https://developer.hashicorp.com/terraform/tutorials/aws-get-started/infrastructure-as-code

 

테라폼은 애플리케이션 프로그래밍 인터페이스(API)를 통해 클라우드 플랫폼 및 기타 서비스에 리소스를 생성하고 관리한다. Provider들은 테라폼이 접근 가능한 API를 가진 사실상 모든 플랫폼이나 서비스와 함께 작동할 수 있도록 한다.

 

테라폼 기본 개념

• resource

실제로 생성할 인프라 자원을 의미한다. ex) aws_security_group, aws_lb, aws_instance

• provider

Terraform으로 정의할 Infrastructure Provider를 의미한다.

• output

인프라를 프로비저닝 한 후에 생성된 자원을 output 부분으로 뽑을 수 있다. Output으로 추출한 부분은 이후에 remote state에서 활용할 수 있다.

• backend

terraform의 상태를 저장할 공간을 지정하는 부분입니다. beNX에서는 기본적으로 s3를 사용하고 있다.

• module

공통적으로 활용할 수 있는 인프라 코드를 한 곳으로 모아서 정의하는 부분이다. Module을 사용하면 변수만 바꿔서 동일한 리소스를 손쉽게 생성할 수 있다는 장점이 있다.

• remote state

remote state를 사용하면 VPC, IAM 등과 같이 여러 서비스가 공통으로 사용하는 것을 사용할 수 있다. tfstate파일이 저장되어 있는 backend 정보를 명시하면, terraform이 해당 backend에서 output 정보들을 가져온다.

 

State

Terraform은 관리중인 인프라 및 구성에 대한 상태를 저장한다.

Terraform에서 실제 리소스를 구성에 매핑하고 메타데이터를 추적하며 대규모 인프라의 성능을 향상시키는 데 사용된다.

기본적으로 terraform.tfstate라는 이름의 로컬 파일에 저장되지만 원격으로 저장할 수도 있어 팀 환경에서 더 잘 작동한다.

Terraform 상태의 주요 목적은 원격 시스템의 개체와 구성에 선언된 리소스 인스턴스 간의 바인딩을 저장하는 것이다.

Terraform은 구성 변경에 대한 응답으로 원격 개체를 만들 때 특정 리소스 인스턴스에 대해 해당 원격 개체의 ID를 기록한 다음 향후 구성 변경에 따라 해당 개체를 업데이트하거나 삭제할 수 있다.

 

• Remote State

Remote State는 루트 모듈에서 구성할 수 있는 백엔드 또는 Terraform Cloud에 의해 구현된다.

 

• Delegation and Teamwork

output values를 다른 config와 공유할 수 있다. 이것으로 인해 인프라를 더욱 작은 구성요소로 관리할 수 있다.

AWS의 보다 구체적인 예로서, remote state를 통해 VPC ID, 서브넷, NAT 인스턴스 ID 등을 공유하여 다른 Terraform state가 이를 사용하도록 할 수 있습니다.

 

• Locking and Teamwork

테라폼은 state locking을 사용하여 동일한 상태에 대해 테라폼의 동시 실행을 방지할 수 있다.

 

이 세 가지 형상의 흐름을 이해하면 각 테라폼 명령이 어떤 작업을 위한 일인지 쉽게 파악하실 수 있다. 여기서 가장 중요한 것은 AWS 실제 인프라와 Backend에 저장된 상태가 100% 일치하도록 만드는 것이다. 테라폼을 운영하면서 최대한 이 두가지가 100% 동일하도록 유지하는 것이 중요한데, 테라폼에서는 이를 위해 import, state 등 여러 명령어를 제공한다.

먼저, 인프라 정의는 Local 코드에서 시작한다. 개발자는 로컬에서 테라폼 코드를 정의한 후에 해당 코드를 실제 인프라로 프로비전한다. 이 때 backend를 구성하여 최신 코드를 저장하는데, 흐름은 아래와 같습니다.

 

Terraform 명령어

• Terraform init

지정한 backend에 상태 저장을 위한 .tfstate 파일을 생성하며, 여기에는 가장 마지막에 적용한 테라폼 내역이 저장된다.

init 작업을 완료하면, local에는 .tfstate에 정의된 내용을 담은 .terraform 파일이 생성된다.

기존에 다른 개발자가 이미 .tfstate에 인프라를 정의해 놓은 것이 있다면, 다른 개발자는 init작업을 통해서 local에 sync를 맞출 수 있다.

 

• Terraform plan

정의한 코드가 어떤 인프라를 만들게 되는지 미리 예측 결과를 보여준다. plan을 한 내용에 에러가 없다고 하더라도, 실제 적용되었을 때는 에러가 발생할 수 있다.

Plan 명령어는 어떠한 형상에도 변화를 주지 않는다.

 

• Terraform apply

실제로 인프라를 배포하기 위한 명령어이다. apply를 완료하면, AWS 상에 실제로 해당 인프라가 생성되고 작업 결과가 backend의 .tfstate 파일에 저장된다.

해당 결과는 local의 .terraform 파일에도 저장된다.

 

• Terraform import

AWS 인프라에 배포된 리소스를 terraform state로 옮겨주는 작업이다.

이는 local의 .terraform에 해당 리소스의 상태 정보를 저장해주는 역할을 한다. (코드를 생성해주지 않는다.)

Apply 전까지는 backend에 저장되지 않는다.

Import 이후에 plan을 하면 로컬에 해당 코드가 없기 때문에 리소스가 삭제 또는 변경된다는 결과를 보여줍니다. 이 결과를 바탕으로 코드를 작성하실 수 있다.

 

 

 

==================================================================

참고 자료

 

https://devops-art-factory.gitbook.io/devops-workshop/terraform/terraform/terraform-1

Terraform 원리 - DevOps Workshop

https://developer.hashicorp.com/terraform/tutorials/aws-get-started/infrastructure-as-code

What is Infrastructure as Code with Terraform? | Terraform | HashiCorp Developer