IaC 코드형 인프라

1. Infrastructure as Code (IaC)의 의미와 필요성

 1-1. IaC란?

• 설정을 코드로 작성하여 클라우드 인프라스트럭처의 생성/수정/삭제를 자동화하는 방법
• 수동 프로세스가 아닌 코드를 통해 인프라를 관리하고 프로비저닝 하는 것

 1-2. IaC의 장점

• 서버, 데이터베이스, 네트워크, 배포 프로세스, 테스트 등 거의 모든 것을 코드로 관리할 수 있다
• 현재와 같은 클라우드 네이티브 환경에서, 운영적인 측면이 모두 코드로 대체될 수 있다
• 인프라를 모듈식 구성 요소로 분할하고 자동화를 통해 다양한 방식으로 결합할 수 있다
• 인프라 구성의 생성/수정/삭제를 자동화 할 수 있다
• 인프라 구성에 대한 내용이 텍스트파일의 형태로 작성되있어서
  • 쉽게 공유가능
  • 버전관리 가능
  • 시스템 관리자 뿐만아니라 개발자도 인프라를 다룰 수 있다

 1-3. 그냥 수동으로 설정하면 안돼?

• 인프라 엔지니어가 AWS의 Management Console을 사용해서 인프라를 구성할 수 있다
  • 즉, 수동설정할 수 있다
• 수동설정의 장점
  • GUI를 통해 쉽고 빠르게 설정 가능
• 수동설정의 단점
  • 휴먼에러 발생 가능
  • 기대하는 인프라 구성을 만들었는지 확인하기 어려움 (But IaC를 활용하면 한눈에 파악 가능)
  • 인프라 구성을 다른 리전에 적용하기 힘듬
  • 인프라 구성의 세부 사항을 팀 구성원에게 전달하기 힘듬

2. IaC의 종류

 2-1. 선언형 IaC와 절차형 IaC의 차이

• 선언형 IaC
  • 필요한 리소스와 리소스의 속성 등 바람직한 시스템 상태를 정의하면 IaC 툴이 바람직한 상태로 구성해 준다
  • 선언적 접근 방식에는 시스템 오브젝트의 현재 상태 목록을 유지하며, 이를 통해 인프라를 더 쉽게 관리할 수 있다
  • 원하는 인프라를 자동으로 프로비저닝하며 변경이 있을 때 마다 선언적 IaC 툴이 이를 자동으로 적용한다
  • 사람이 직접 하지 않아도 동일한 결과로 여러 번 실행될 수 있다
  • JSON, YAML 등을 사용
  • 실제 인프라가 적용된 결과(기대하는 상태)와 적용할 내용이 직관적으로 매핑됨
  • 길을 찾아갈때, ~역에서 2번출구로 내려서 홈플러스 방향으로 800m이동후 가나건물 2층

 

• 절차형 (or 명령형) IaC
  • 바람직한 구성을 얻기 위한 특정 명령을 정의하며, 정의된 명령을 올바른 순서로 실행해야 한다
  • 업데이트를 허용하지 않고 명시적인 방향을 사용하는 불안정한 접근 방식이다
  • 변경이 필요한 경우, 명령적 IaC툴은 운영자가 변경 사항이 어떻게 적용되어야 하는지를 해독해야 한다
  • 실제 적용된 결과를 가늠하기 어렵고, 코드를 읽기에 직관적이지 않음
  • 길을 찾아갈때, 센텀로 19 가나건물 2층

 

3. IaC 종류

 3-1. 절차형 IaC의 종류

• AWS CDK
• Pulumi

 3-2. 선언형 IaC의 종류

• CloudFormation (AWS에서만 사용가능)
• Azure Blueprint (Azure에서만 사용가능)
• Cloud Deployment Manager (GCP에서만 사용가능)
• Terraform: 어떤 클라우드 서비스에도 적용되는 범용 IaC 도구

 3-3. 테라폼을 사용하는 이유

• 테라폼이 사용하는 언어는 HCL 이다
  • 선언적이지만, 논리적인 기능을 제공한다
    • YAML에서는 지원하지 않는 반복문, 지역 변수 등을 지원한다
• 다양한 클라우드 사업자를 지원한다
• 불변(Immutable)하다
• 예측 가능하다
• 여러 번 반복 적용하더라도, 기대한 바 그대로 인프라를 만들어 준다

 3-4. 테라폼 주소

https://www.terraform.io/

Terraform by HashiCorp

 

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

 

 4-1. 예시

 

우리는 Windows 나 Apple MacOS 를  사용하면서 보안, 안정성 그리고 성능 등의 이유로 OS(운영체제)를 자주 업데이트 합니다.

 

OS는 시간이 지남에 따라 내용이나 설정이 수시로 변화가 발생하며, 새로운 애플리케이션를 설치할 때는 레지스트리도 변경합니다.

 

소프트웨어가 업데이트나 설정 변경 등을 반복하면서 최신 상태로 유지하는 것처럼 서버용 소프트웨어도 유사한 방법으로 관리하였습니다.

 

이렇게 서버가 시간 지남에 따라 상태가 변해가고 이로 인해 문제가 발생하는 것을 컨피규레이션 디리프트 ( Configuration Drift ) 라고 합니다.

https://www.openmaru.io/%eb%b6%88%eb%b3%80%ec%9d%98-%ec%9d%b8%ed%94%84%eb%9d%bc%ec%8a%a4%ed%8a%b8%eb%9f%ad%ec%b2%98/

불변의 인프라스트럭처(immutable infrastructure) - OPENMARU APM

 

 

 4-2. AWS를 기준으로 접근 방법과, 도구 알아보기

• 잘못 설정된것을 찾기 위한 도구: AWS Config
  • 바른 설정을 지정해놓고, 찾고 고칠 수 있게 만들어준다
• 사고 감지 도구: AWS CloudFormation Drift Detection

이러한 관리형 서비스 외에 보다 개발 방법에 가까운 솔루션

• 정상 작동 상태를 파일로 저장: Terraform state files

Terraform의 상태 정의 파일은 인프라의 실제 상태와의 비교 대상으로서 현재 상황을 진단/점검할 수 있다

 

불변한(Immutable) 인프라스트럭처는 인프라 변경을 원천적으로 막을 수 있는 방법론

 

1. 한번 생성했으면 수정하지 않는다.
   • 프로비저닝 및 배포했으면, 콘솔에 접속해서 수동으로 설정하지 않습니다
   • 변경이 필요한 경우 새 배포
   • 새 인프라 추가 후 기존 인프라 폐기
2. 인스턴스 내부 구성(사용자 스크립트 등)이 필요할 경우 AMI로 만들어 놓는다
   • Develop → Deploy → Configure ( X )
   • Develop → Configure → Deploy ( O )
3. 코드형 인프라(IaC)를 사용한다

---

가변적(mutable) 인프라와 불변적(immutable) 인프라의 차이는 무엇일까?

• 가변적 인프라
  • 시스템을 변경하면서 운영하는 방법
  • 시스템 변경 작업이 있을 때마다 서버에 상태 변화, 여러대의 서버일시 각각의 서버마다 상태 다름
    • 시스템 변경 작업에는 배포 업그레이드 보안 취약점 조치 및 장애에 대한 대응이 있음
    • 업그레이드 과정 : 서버접속, 어플리케이션 정지, 업데이터, 리부팅, 테스트를 위한 다운타임 필요
• 불변적 인프라
  • 배포 업그레이드 보안 취약점 조치 등의 서버 상태의 변경이 필요할 경우 이미지를 만들어 배포
  • 업그레이드시, 기존 운영 환경은 버리고 새로운 상태의 서버 환경을 만듬
  • 서버를 변경 불가능한(Immutable) 것으로 취급

 

• 찻잔과 종이컵의 비유
  • 가변적 = 도자기 = 지속적 patch 관리가 필요한 Legacy Infra
    • 변경 가능한 인프라는 항상 운영가능한 상태
    • 대체 불가능한 유일한 시스템으로 다루는 개념
  • 불변적 = 일회용 종이컵 = 한번쓰고 버리는 Cloud Infra
    • 변경 불가능한 인프라는 서버를 일회용으로 취급하는 개념
• 변경이 필요하다면? 
  • 가변적 인프라는 시스템을 변경하지만, 불변적 인프라는 새로운 서버를 구축한다
• 불변적 인프라의 장점
  • 서버를 항상 깨끗(clean)한 상태로 유지한다
    • 예시) DVD로 소프트웨어를 배포할 때 소프트웨어의 변경이 생기면 새로운 이미지로 DVD를 제작
    • 즉, 서비스 운영환경을 호스트OS와 분리후 이미지로 생성하여 서버에 배포하여 실행함

https://www.openmaru.io/%eb%b6%88%eb%b3%80%ec%9d%98-%ec%9d%b8%ed%94%84%eb%9d%bc%ec%8a%a4%ed%8a%b8%eb%9f%ad%ec%b2%98-aci/

불변의 인프라스트럭처 - 머신 중심에서 애플리케이션 중심으로 변화

 

https://www.openmaru.io/%eb%b6%88%eb%b3%80%ec%9d%98-%ec%9d%b8%ed%94%84%eb%9d%bc%ec%8a%a4%ed%8a%b8%eb%9f%ad%ec%b2%98/

불변의 인프라스트럭처(immutable infrastructure) - OPENMARU APM

 

Terraform의 선언적 방식으로 작성된 코드는 항상 인프라의 최신 상태를 의미한다.

Terraform은 어떤 방식으로 인프라를 최신 상태로 유지할 수 있는 걸까?

 

상태

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

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

- 테라폼은 tfstate(상태파일)에 상태가 저장된다

예를 들어ec2를 3대 만들면 상태파일이 저장된다. ec2를 2대 더 만들고자 하면 5라고 입력한다. 그러면 2대가 지워지고 5대가 생기게 된다. 만약 상태파일을 지우고 ec2한대를 만든다면? 한대가 더 생성되어 총 6대가 된다. 왜냐하면 선언적으로 한대 만들어 줘 라고 선언했지만 상태파일이 없기 때문에 이전상태를 모르게 된다. 이상태에서 destroy를 하게 된다면? 아까 만든 ec2한대가 사라지고 총 5대가 된다.

 

 

 

https://learn.hashicorp.com/tutorials/terraform/refresh

Use Refresh-Only Mode to Sync Terraform State | Terraform - HashiCorp Learn

 

---

Terraform 다운로드

https://www.terraform.io/downloads

 

Terraform

가장 많이 쓰이는 IaC 도구로, 표준으로 보아도 무방하다.

Terraform 구성 요소

provider - 테라폼으로 생성할 인프라의 종류를 의미

resource - 테라폼으로 실제로 생성할 인프라의 자원을 의미

state - 테라폼을 통해 생성한 자원을 상태를 의미

output - 테라폼으로 만든 자원을 변수 형태로 state에 저장하는 것을 의미

module - 공통적으로 활용할 수 있는 코드를 문자 그대로 모듈 형태로 정의하는 것을 의미

remote - 다른 경로의 state를 참조하는 것을 의미, Output 변수를 불러올 때 주로 사용

 

Terraform 명령어

init - 테라폼 명령어 사용을 위해 각종 설정을 진행

plan - 테라폼으로 작성한 코드가 실제로 어떻게 만들어질지에 대한 예측 실행

apply - 테라폼 코드로 실제 인프라를 생성

import - 이미 만들어진 자원을 테라폼 state 파일로 옮겨주는 명령어

state - 테라폼 state를 다루는 명령어\, 하위 명령어로 mv\, push와 같은 명령어가 있다.

destroy - 생성된 자원\, state 파일 기준으로 모두 삭제하는 명령어

Terraform 기본 개념

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

provider : Terraform으로 정의할 Infrastructure Provider를 의미합니다. https://www.terraform.io/docs/providers/index.html

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

backend : terraform의 상태를 저장할 공간을 지정하는 부분입니다. backend를 사용하면 현재 배포된 최신 상태를 외부에 저장하기 때문에 다른 사람과의 협업이 가능합니다. 가장 대표적으로는 AWS S3가 있습니다.

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

remote state : remote state를 사용하면 VPC, IAM 등과 같은 공용 서비스를 다른 서비스에서 참조할 수 있습니다. tfstate파일(최신 테라폼 상태정보)이 저장되어 있는 backend 정보를 명시하면, terraform이 해당 backend에서 output 정보들을 가져옵니다.

 

Terrafrom 작동 원리

Local 코드 : 현재 개발자가 작성/수정하고 있는 코드 AWS 인프라 : 실제로 AWS에 배포되어 있는 인프라 Backend에 저장된 상태 : 가장 최근에 배포한 테라폼 코드 형상

위와 같이 Local에서 작성한 테라폼 코드로 인프라를 정의하고, 해당 코드를 실제 AWS 인프라로 프로비저닝하며, backend를 구성하여 최신 코드를 저장합니다.

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을 하면 로컬에 해당 코드가 없기 때문에 리소스가 삭제 또는 변경된다는 결과를 보여준다.

만약 기존에 인프라를 AWS에 배포한 상태에서 테라폼을 적용하고 싶으면 모든 리소스를 terraform import로 옮겨야 합니다.

출처 : https://young-dev.com/aws/aws-terraform-01/#aws-configure

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

https://www.redhat.com/ko/topics/automation/what-is-infrastructure-as-code-iac

코드형 인프라(IaC)란?