Devops Day 48 (5.12) Infrastructure as Code_Terraform

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

 

절차형 Iac의 종류 :
AWS CDK
Pulumi

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

 

선언형 IaC 종류 :
CloudFormation (AWS에서만 사용가능)

Azure Blueprint (Azure에서만 사용가능)

Cloud Deployment Manager (GCP에서만 사용가능)

Terraform: 어떤 클라우드 서비스에도 적용되는 범용 IaC 도구입니다.

 

Terraform 기초 Hands on
테라폼은 HashiCorp의 인프라스트럭처 코드 도구입니다.

테라폼을 사용하는 것은 인프라스트럭처를 수동으로 관리하는 것보다 여러 가지 이점이 있습니다:

- 테라폼은 여러 클라우드 플랫폼에서 인프라스트럭처를 관리할 수 있습니다.

- 사람이 읽을 수 있는 구성 언어를 통해 빠르게 인프라스트럭처 코드를 작성할 수 있습니다.

- 테라폼의 상태는 배포 과정에서 리소스 변경 사항을 추적할 수 있게 해줍니다.

- 인프라스트럭처에 대한 구성을 버전 관리에 커밋하여 안전하게 협업할 수 있습니다.
관리 : 테라폼의 프로바이더라고 불리는 플러그인을 통해 테라폼은 클라우드 플랫폼과 다른 서비스와 그들의 API를 통해 상호작용할 수 있습니다.

 

배포 Workflow :
테라폼을 사용하여 인프라스트럭처를 배포하기 위한 단계는 다음과 같습니다:

 

Scope (범위): 프로젝트의 인프라스트럭처를 식별합니다.

Author (작성): 인프라스트럭처의 구성을 작성합니다.

Initialize (초기화): 인프라스트럭처를 관리하기 위해 테라폼이 필요로 하는 플러그인을 설치합니다.

Plan (계획): 테라폼이 구성과 일치하도록 할 변경 사항을 미리 보여줍니다.

Apply (적용): 계획된 변경 사항을 실행합니다.

 

협력 : 테라폼은 원격 상태 백엔드를 통해 인프라스트럭처 협업을 가능하게 합니다. 또한 테라폼 클라우드를 버전 관리 시스템(GitHub, GitLab 등)에 연결하여 구성 변경을 커밋할 때 자동으로 인프라스트럭처 변경을 제안할 수 있습니다.

 

Terraform 설치 :

1. Hashicorp GPG 내용 확인 위한 프로그램 설치
sudo apt-get update && sudo apt-get install -y gnupg software-properties-common

 

2. Hashicorp GPG 키 설치
wget -O- https://apt.releases.hashicorp.com/gpg | \

gpg --dearmor | \

sudo tee /usr/share/keyrings/hashicorp-archive-keyring.헿

 

3. 키 내용 확인
gpg --no-default-keyring \

--keyring /usr/share/keyrings/hashicorp-archive-keyring.gpg \

--fingerprint

 

4. Hashicorp 정식 레포지토리 로컬 시스템에 설치
echo "deb [signed-by=/usr/share/keyrings/hashicorp-archive-keyring.gpg] \

https://apt.releases.hashicorp.com $(lsb_release -cs) main" | \

sudo tee /etc/apt/sources.list.d/hashicorp.list

 

5. Hashicorp 정보 다운
sudo apt update

6. 로컬 시스템에 새로운 레포지토리에 Terraform 설치
sudo apt-get install terraform

 

7. 설치 완료 댔는지 확인 방법
terraform -help

 

Terraform Build Infrastructure
1. 로컬에 디렉토리 Terraform 작업할 폴더를 생성 합니다
mkdir으로 디렉토리 생성 합니다.

 

2. 생성한 폴더 / 디렉토리로 들어가 touch main.tf 으로 terraform 파일 생성합니다.

코드에 리전, AMI, 인스턴스 타입 그리고 인스턴스 명 설정하고 저장합니다.

 

3. 이 디렉토리 실행 및 dependencies 설치 하기 위해 “terraform init” cmd 실행합니다.

 

4. Terraform Validate 으로 코드에 이상이 없는지 확인할 수 있습니다. 다음 Terraform apply 으로 인프라 생성 할 수 있습니다. 이상 없이 완료 되면 하단 사진처럼 보입니다.

5. Terraform show 명령으로 AWS EC2 정보들을 확인 할 수 있습니다.

 

6. Terraform state list 으로 관리 할 수 있는 명령어가 있습니다.

 

인프라 변경
1. Terraform 코드 / 내용에 변경 내용이 있을 경우 하단 사진처럼 표시 됩니다.

2. 변경한 내용으로 다시 terraform apply 하면 변경된 내용으로 새로운 인프라 생성합니다.

변경 내용 진행 할 경우 그전에 생성한 인프라 삭제하고 새로운 인프라 생성합니다.

 

인프라 삭제
1. 생성한 인프라 삭제 하고 싶으면 terraform destroy 명령으로 진행하면 됩니다.

 

2. 삭제하기 위해서 yes 기입 하면 하단 사진처럼 진행 됩니다.

 

변수 기입
1. 추가 변수 / 정보들을 기입할 수 있습니다.

하단 예시 확인

1.1 인스턴스 파일 하나 생성

1.2 변수 코드 기입. 변수 값을 기입하지 않을 경우 default 값으로 생성

1.3 변수에 값을 기입하면 내용이 변경 (EC2 명 변경)

 

쿼리 데이터_Output
1. Terraform apply로 변수 있는 EC2 생성 후 폴더 및 디렉토리에 outputs.tf 파일 생성

 - 외 정보 기입 후 EC2에 적용 가능합니다.

1.1 인스턴스 id + IP 값 할당 후 다시 terraform apply 하면 적용

Store Remote State

제작 환경에서는 상태(state)를 안전하고 암호화된 상태로 유지하고, 팀원들이 인프라에 대해 협업할 수 있는 환경에서 Terraform을 실행하는 것이 가장 좋습니다.

 

Terraform Cloud를 사용하면 팀이 인프라 변경 사항을 쉽게 버전 관리하고 감사할 수 있습니다. 또한 API 토큰 및 액세스 키를 포함한 변수를 안전하게 저장하며, 오랜 시간 동안 실행되는 Terraform 프로세스에 안전하고 안정적인 환경을 제공합니다.

 

1. Terraform Cloud Set up
main.tf / 인스턴스 만든 파일에 하단 코드 추가 합니다.

1.2 Terraform login 으로 terraform cloud에 로그인 합니다.

 

1.3 Terraform init 으로 state file을 Terraform Cloud으로 이동합니다. 로컬에 있는 state file 삭제 하기 위해  rm terraform.tfstate 사용합니다.

 

1.4 Terraform Cloud에서 변수 (Acceskey, token등 설정 할 수 있습니다) 설정 완료 후 Terraform apply 하면 내용들이 적용됩니다.

 

1.5 Terraform destroy 로 삭제가 가능합니다.

 

참조 : https://learn.hashicorp.com/collections/terraform/aws-get-started

AWS | Terraform | HashiCorp Developer

발표 :
[C911] 가변적(mutable) 인프라와 불변적(immutable) 인프라의 차이는 무엇인가요?

가변적 인프라는 웹 서버를 만들고 기존의 변경 가능한 인프라에 배포했을 경우, 문제 발생시 서버를 쉽게 변경할 수 있습니다. 패치를 적용하거나 업그레이드 또는 다운그레이드를 수행하며 스케일을 확장하거나 축소할 수 있습니다.

 

가변적(mutable) 인프라의 장점:

- 변경이 필요할 때마다 IT 팀이 서버를 처음부터 구축할 필요가 없습니다.

- 개별 서버에 대해 업데이트를 롤아웃할 수 있어 업데이트 과정이 빨라집니다.

- 각 사용자의 특정 요구 사항에 맞는 인프라를 사용할 수 있습니다.

- 각 서버를 개별적으로 이해하므로 문제 진단이 더 쉬워집니다.

 

가변적 인프라의 단점:

- 각 서버의 구성이 고유하기 때문에 각 서버의 문제 진단과 관리가 어려워집니다. 이를 구성 드리프트(configuration drift)라고 합니다.

- 구성 변경 사항이 문서화되지 않아 추적이 어렵고, 진단이 거의 불가능해집니다.

- DNS 오류나 네트워크 연결성의 저하와 같은 여러 이유로 업데이트가 실패할 수 있으며, 이러한 문제를 인식하고 수정하는 데 시간이 소요됩니다.

- 업데이트 추적 문제로 디버깅에 시간이 많이 소요될 수 있습니다. 문제에 대한 통찰력이 전혀 없는 여러 버전의 업데이트를 얻게 될 수도 있습니다.

 

불변적 인프라는 사버가 설치된 이후 절대 변경되지 않는 형태의 인프라입니다. 변경이 필요한 경우, 새로운 배포를 하고 인프라를 추가하며 이전 인프라를 폐기해야 합니다.

 

불변적(immutable) 인프라의 장점:

- 분리된 버전 관리: 각 서버 버전은 서로 독립적입니다. 동시에 두 개의 버전이 실행되지 않습니다.

- 추적이 쉬움: 변경이 필요할 때마다 새로운 서버 버전을 생성하기 때문에 각 버전의 오류를 추적할 수 있습니다. 중간 구간이 없습니다.

- 각 서버의 구성이 일관되므로 다른 서버를 테스트하고 업데이트를 롤아웃하는 것이 쉽습니다.

- 서버가 동일하게 유지되므로 예측 가능성이 있습니다.

- 클라우드 기술과 같은 상호 의존적인 환경에 적합합니다.

- 이전 버전이 영향을 받지 않기 때문에 배포를 롤백할 수 있습니다.

 

불변적 인프라의 단점:

- 기존 서버를 수정할 수 없습니다. 문제가 발생한 경우, 동일한 구성을 가진 서버는 완전히 재구축해야 합니다.

- 데이터 저장을 로컬 디스크에 복사하는 대신 외부 데이터 저장소를 사용해야 합니다.

 

[C912] Terraform의 선언적 방식으로 작성된 코드는 항상 인프라의 최신 상태를 의미합니다. Terraform은 어떤 방식으로 인프라를 최신 상태로 유지할 수 있는 걸까요?

 

Terraform은 선언적인 방식으로 작성된 코드를 사용하여 인프라의 최신 상태를 유지할 수 있습니다. 다음과 같은 방식으로 인프라를 최신 상태로 유지합니다:

 

Terraform State: Terraform은 상태 파일(state file)을 사용하여 관리 중인 인프라의 현재 상태를 추적합니다. 이 상태 파일은 Terraform이 생성한 리소스의 상태와 구성 정보를 저장합니다. 각 Terraform 명령 실행 시, Terraform은 상태 파일을 업데이트하여 인프라 상태의 변화를 기록합니다.

 

Plan and Apply: Terraform은 terraform plan 명령을 통해 코드 변경 사항을 분석하고, 어떻게 인프라가 업데이트될 것인지 미리 확인할 수 있습니다. 이후 terraform apply 명령을 사용하여 변경 사항을 실제로 적용합니다. 이 과정에서 Terraform은 현재 상태와 원하는 상태를 비교하여 필요한 리소스를 생성, 수정, 삭제합니다.

 

Infrastructure as Code: Terraform의 코드는 인프라 구성을 기술하고, 원하는 상태를 명시합니다. 코드는 버전 관리 시스템에 저장되어 변경 사항을 추적하고 협업을 지원합니다. 코드를 변경하면 Terraform은 변경 사항을 인식하고 적용하여 인프라를 최신 상태로 업데이트합니다.

 

이러한 방식으로 Terraform은 선언적인 코드를 사용하여 인프라를 원하는 상태로 유지하며, 변경 사항을 추적하고 업데이트하는 기능을 제공합니다.