IaC 개요

# IaC ( Infrastructure as Code ) 란?

 

코드형 인프라

docker - docker compose

kubernetes - manifest file (ex. yaml 파일)

AWS - CloudFormation

 

기존의 인프라는 물리적인 형태를 제외하면 명령어, 쉘스크립트 등으로 구성, 관리, 운영 해왔다.

가상화로 컨테이너화 된 인프라들은 코드 형태로 인프라를 선언하고, 코드를 적용시켜 해당되는 인프라를 배포한다.

인프라를 코드로 표현하고 실행해서 시스템을 구성하고 관리, 운영 해왔다 (ex. 쉘스크립트)

자동화된 도구들이 많이 나왔고, 이런 가상환경들이 제공됨에 따라 iac 도구들이 탄생

 

 

 

# IaC 장점

 

1) 비용 절감

 사람의 노력적인 측면에 인프라 관리를 수동적으로 하지 않아 다른 생산적인 작업에 집중 할 수 있다.

 

2) 빠른 속도

인프라 구성 및 관리, 배포를 자동화하여 신속하게 실행 시킨다, 효율적이다.

-

3) 안정성

수동으로 구성할 때 사람의 실수에 관련된 위험을 제거할수있다.

 

4) 코드화 및 버전 관리

표준화된 포맷과 규칙으로 작성된 코드 문서를 통해 누구나 읽을 수 있고 확인 할 수 있다. 코드는 변경 사항 이력을 남길수있어서 문제 발생시 어떤 부분해서 문제가 발생했는지 확인하기 쉽다.

 

5) 재사용성

인프라를 코드화 하고 관련 리소스를 그룹 및 모듈화 해서 필요시 필요한 부분을 재사용 할 수 있다.

 

 

# IaC 도구 및 구성관리

 

1) 구성 관리 / 배포

요즘엔 구성 관리와 배포 도구의 경계가 모호해졌다

 

구성 관리(Configuration Management)도구

- 베어메탈 시스템, 가상 컴퓨터 및 클라우드 인스턴스 내에서 패키지 설치, 애플리케이션 구성, 운영체제 관련 구성하는 도구를 CM(Configuration Management) tool 이라고 한다.

- Ansible, Chef, Puppet, SaltStack

 

배포(Provisioning) 도구

-새로운 인프라 리소스를 배포하고 이미 배포된 인프라 리소스의 생명주기 관리하는 도구이다.

- AWS CloudFormation, OpenStack Heat, Terraform

 

 

 

2) 가변 인프라 / 불변 인프라

 

가변 인프라

- 구성 관리 도구는 가변 인프라에 초점을 맞추고 있다.

- VM,운영테제와 같이 시간에 따라 계속해서 변화되는 형태의 인프라, 패치를 해주어야 한다

- 인프라의 형태가 바뀐다

- 시간에 따른 고유한 상태 있어서 교체하기 쉽지 않다.

 

불편 인프라

- 컨테이너와 같은 형태 , 어플리케이션을 업데이트 하려면 이미지를 교체 해야한다 ( 이미지 자체는 바뀌지 않음)

- 얼마든지 교체가 가능하다

 

 

 

3) 절차적 / 선언적 언어

 

절차적 언어

- 작업을 할 때 순서가 있다

- Ansible , Chef

 

선언적 언어

- 특별한 순서가 없다

- AWS CloudFormation, OpenStack Heat, Puppet, SlatStack, Terraform

 

 

 

4) 마스터 및 에이전트 유무

 

마스터의 유무

- 쿠버네티스의 control-plane

- 마스터가 죽으면 아무것도 제어가 되지 않는다. 중앙 집중화된 개념이다.

- Chef, Puppet, SaltStack 도구는 마스터 서버가 있어야 한다.

- 다른 도구들은 분산 아키텍처를 가지고 있어서 무조건 서버란 개념이 필요하지 않음

 

에이전트 유무

- 원격에 있는 시스템을 관리하기위해 별도의 프로그램이 필요한가

- 앤서블과 테라폼은 마스터와 에이전트를 사용하지 않는다