인프라 규모가 작으면 개별로 직접 설정하거나, 부팅 이미지 또는 부팅 명령어 실행을 할 수 있다. 그러나 수백 대 그 이상의 규모에는 기존의 방법으로는 관리가 어렵다. 그래서 ANSIBLE, TERRAFORM 과 같은 IaC (코드형 인프라)로 편리하게, 효율적으로 운영해야 한다.
1. IaC (Infrastructure as Code)
IaC 는 Infrastructure as Code 단어 그대로 인프라를 코드로 관리하는 방식이다. 코드로 다수의 인프라 자원을 통제, 운영함으로서 가용성과 안정성을 높일 수 있고, 문서화 및 버전관리 등의 추가 이점을 누릴 수 있다.
IaC 의 장점으로는
- 배포 프로세스 자동화
- 배포 속도 향상 및 안정성 (에러 발생 감소)
- 코드 파일로 문서화 가능
- 버전 관리
- 유효성 검증
- 재사용성
이 있다.
IaC 을 구현하는 툴은 여러가지가 있으며, CHEF, PUPPET, ANSIBLE, TERRAFORM 을 예로 들 수 있다. 클라우드에서 많이 사용하는 툴은 ANSIBLE, TERRAFORM 이므로, 이 두 가지를 공부할 것이다.
2. TERRAFORM
인프라 구축, 운영을 코드(code)로 자동화하는 툴이다. terraform 을 인프라에 적용하는 과정은 WRITE > PLAN > APPLY 이다.
1) 실행 과정
- WRITE : 설정파일(코드)를 통해 인프라 구성을 정의
- PLAN : 구성될 인프라 구성 검토 (어떻게 인프라가 구성될지 사전에 확인)
- APPLY : 작성한 코드 (설정)파일을 인프라에 적용하고, STATE 파일을 갱신함
2) 기본 용어 및 구성
- Provider : 테라폼으로 생성할 클라우드의 종류 (ex : AWS, AZURE, GCP 등), provider.tf 파일에 정의한다.
- Resource : 생성, 수정할 클라우드 서비스를 의미한다. (ec2, vpc, s3 등), main.tf 파일에 정의한다.
- Variables : 클라우드 인프라에 사용될 변수이다. variables.tf 파일의 정의한다.
- Locals : 값을 저장하는데 사용하는 변수이다. Variables 와 비슷한 역할이지만, 차이가 있다.
Variables, Local 차이점
- variables : 전역변수의 기능과 비슷하다. terraform 내부 어디에서나 참조 가능, 테라폼 구성 실행 중에 값을 변경할 수 있다.
- Locals : 지역변수와 비슷하며 해당 모듈 내에서만 참조 가능, 테라폼 구성 실행 중에 값 변경 할 수 없다.
- State : 인프라의 현재 상태를 나타내는 파일이다. json 형식으로 작성되며 리소스 이름,
리소스 유형, 리소스 속성, 리소스 상태의 정보를 포함한다.
- Output : 테라폼 코드 실행 결과를 확인할 때 사용한다. 즉 코드로 생성한 인프라의 설정 또는 값들을 담고 있다.
- Provisioner : 리소스에 필요한 설정 또는 SW 를 정의하고, 자동화(자동 실행)하는 기능이다.
- Module : 테라폼 파일을 그룹으로 나눈 것이다. 서비스 또는 작업(프로젝트)를 기준으로 그룹을 나눌 수 있다. 생성된 모듈을 호출할 수 있으므로 재사용성, 가독성을 높인다.
- Data : 기존에 생성된 인프라의 정보를 활용할 때 사용한다. (기존에 생성되었다는 것은 테라폼 코드가 실행되는 시점에 존재하고 있는 인프라의 정보를 의미한다.)
3) 코드 파일 구조
- 기본 구조
Terraform_folder/ (최소 형태)
|-- README.md
|-- main.tf
|-- variables.tf
|-- outputs.tfTerraform_folder/ (최대 형태)
|-- README.md
|-- main.tf
|-- variables.tf
|-- outputs.tf
|-- modules/
| |-- module_name1
| |-- main.tf
| |-- variables.tf
| |-- outputs.tf
| |-- module_name2
| |-- main.tf
| |-- variables.tf
| |-- outputs.tf
3. ANSIBLE
코드(code)를 통해 인프라의 세부 설정, 실행 환경 등을 원격으로 관리하는 툴이다.
(CM, Configuration Management 의 기능을 갖고 있다.) 테라폼이 인프라 구축, 구성 자동화에 초점이 맞춰져 있다면, 엔서블은 인프라 시스템 각각의 설정을 포함한 운영환경 자동화에 초점이 맞춰져 있다.
1) 실행 과정
- 플레이북(playbook)과 호스트 목록을 읽어들임
- SSH를 사용하여 관리 대상 시스템에 접속
- 플레이북에 정의된 각 작업(task)을 순서대로 실행하며, 필요하다면 해당 서버의 상태를 변경함. 각 작업은 특정 모듈을 사용하여 수행된다.
- Ansible은 대상 서버의 상태를 모니터링하여 플레이북의 정의와 일치하도록 조정한다.
2) 기본 용어 및 구성
- Modules : 원격 호스트에서 작업을 수행하는 프로그램(코드)이다. 사실상 명령어 처럼 사용하므로, 작업을 위한 명령어로 생각하면 된다.
- Module utilities : 앤서블 모듈 생성 시 활용할 수 있는 파이썬 코드(파일)이다. 기존에 생성된 모듈이 아닌 사용자 정의로 모듈을 만들 때 코드의 간결함과 중복 방지를 위해 사용한다.
- Plugins : 모듈은 원격 호스트를 관리하기 위해 사용하지만, 플러그인은 앤서블 자체의 추가기능을 사용하는게 목적이다. 젠킨스 플러그인을 예시로 들 수 있다.
- Inventory : 원격으로 관리할 시스템 목록을 작성한 파일이다.
- Playbook : 인벤토리에 정의한 시스템 대상으로 어떤 작업을 수행할 것인지 명세한 것이다. 여러 작업을 자동화 할 수 있다. 플레이북 내부에는 1개 이상의 play 가 있고, play 안에는 1개 이상의 task 가 있다.
- Ansible search path : 말 그대로 탐색 경로이다. 같은 이름의 리소스 (플레이북, 모듈, 플러그인 등) 각각 다른 경로에 저장 가능하며, 이때 같은 이름의 리소스를 참조할 때 탐색 경로(search path)로 구분한다.
** ad-hoc : 작업을 CLI 에서 명령어로 수행하는 방법이다. 플레이북이 코드로 명시한 작업을 수행한다면, ad-hoc 은 CLI 에서 명령어를 실행해서 작업을 수행한다.
4. 차이점
테라폼과 앤서블은 인프라 구성 및 운영을 자동화하는 툴이다. 그러나 역할과 기능은 다르며,
테라폼이 인프라 아키텍처 구축 및 운영을 자동화 한다면, 앤서블은 시스템 별 설정 및 운영환경을 자동화 한다. 시스템 개별이 아닌 여러 시스템으로 이루어진 인프라 아키텍처 구축, 운영 자동화는 테라폼을, 시스템 개별의 설정 및 프로그램 실행 환경 자동화에는 앤서블을 사용한다.
