들어가며
감사히도 이번에 테라폼 기초 입문 스터디 3기에 참여하게 되었다.
테라폼 스터디는 작년부터 10월부터 이어져온 스터디다.
작년 10월 1기 처음 모집 시작했을 때, 너무 참여하고 싶었는데 그때 해외출장 때문에 도저히 완수를 못할 것 같아서(자기객관화) 포기하고 있었는데, 감사히ㅠㅠ기회를ㅠㅠ주셔서ㅠㅠ 이번 스터디에 참여하게 되었다.
이번 테라폼 기초 입문 스터디 3기(이하 t1013)는 책 <테라폼으로 시작하는 IaC>을 기반으로 유형욱, 윤서율님이 맡아서 진행해주신다.
* 본 포스팅은 책 <테라폼으로 시작하는 IaC>을 기반으로 작성되었음을 밝힙니다.
1장: IaC와 테라폼
IaC?
<한줄 요약>
컴퓨터가 읽고 실행할 수 있는 정의 파일을 이용해 인프라나 서비스를 관리하고 프로비저닝하는 프로세스
<세줄 요약>
- 코드로서 표현되는 인프라(Infrastructure as Code)
- 사용자가 인프라 관리를 UI(User Interface)나, 명령어를 이용해 수동 조작하는게 아니라 코드로 자동화할 수 있게 해준다.
- 인프라를 코드 형태로 관리하기 때문에, 변경사항 추적과 버전 관리가 용이하다.
<Why? 존재 의의>
IaC를 왜 쓸까?
인프라 운영은 그동안 수동 방식으로 진행해왔다.
- 1단계: 매뉴얼(엑셀)
- 2단계: 스크립트
- 3단계: 가상머신(VM) → 스냅샷으로 재사용 가능. 관리 툴이 다르면 일관된 관리가 불가능.
- 4단계: 클라우드 인프라 → API를 활용하여 민첩성과 확장성 증가. CSP마다 멀티 클라우드 자동화를 위해서는 별도 작업 필요.
- 5단계: 컨테이너 → VM보다 더 가벼워서 민첩성, 확장성이 높다. 제어시스템과 모니터링을 별도로 신경 써야 하며(자동화의 역설), 최신 기술이라 전문 인력이 이전 기술에 비해 부족하다.
인프라, 특히 가변적이고 추상화된 리소스를 다룰 때는 기존 자동화를 재적용하는 것이 어렵다.
특히 클라우드 처럼 동적이면서도 서로 다른 플랫폼의 기술을 융합하려면 프로세스 적인 접근이 필요하다. MSA처럼 작은 규모로 독립성을 유지하면서, 장애 극복 능력을 갖고 있어야하며, 반복적인 작업을 효율적으로 하기 위해 코드적 표현 방식에 기반한 자동화가 필요하다.
<특징>
위와 같은 요구사항에서 IaC는 다음과 같은 장점을 제시하는 방법론이다.
1. 버전 관리
- 무언가 잘못되었을 때 복구할 수 있다.
- 프로젝트 진행 중 과거의 어떤 시점으로 돌아갈 수 있다.
- 소스 코드의 변경 사항(+누가 수정했는지)을 추적할 수 있다.
- 인프라를 코드로 관리하기 때문에 버전 관리 시스템(Version control system)과 연계할 수 있다.
- https://ko.wikipedia.org/wiki/%EB%B2%84%EC%A0%84_%EA%B4%80%EB%A6%AC
2. 협업
- 파일 형태로 되어있기 때문에 공유가 쉽다.
- 버전 관리 시스템(Version control system)과 연계하면 공동 작업도 할 수 있다.
- Branch로 프로젝트에 영향을 최소화 하면서 새로운 부분을 개발할 수 있다.
3. 재사용성
자주 반복되거나 표준화된 구성을 매번 새로 작성하지 않고, 기존 모듈을 재활용할 수 있다.
4. 기술의 자산화
각 조직 별로 관리 노하우와 작업 방식이 코드에 포함되어 있어서 기술 부채를 줄인다.
한편으론 IaC의 단점도 있다.
1. 코드 문법 학습
테라폼과 같은 새로운 IaC 도구를 위해 별도 학습이 필요하다.
2. 대상 인프라에 대한 이해 필요
IaC지식과 더불어, IaC로 관리하려는 인프라의 지식이 필요하다.
Terraform?
<한줄 요약>
HashiCorp에서 공개한 IaC 도구
<세줄 요약>
- 하시코프의 철학 중에서, 테라폼은 워크플로에 집중(Workflows, not technologies), IaC(Versioning through Codification, Automation through Codification), 실용주의(Pragmatism) 라는 세가지 철학을 갖고있다.
- 테라폼 자체만으론 다양한 인프라와 서비스를 프로비저닝할 수 없기 때문에 대상 인프라의 프로바이더와 API명세를 테라폼 코드로 호출하여 동작한다.
- On-Premise, Hosted SaaS, Private Install 세가지 형태로 제공한다.
<Why? 존재 의의>
사실 IaC 도구는 테라폼 말고도 다양하게 존재한다.
아래는 테라폼과 구성 관리 도구로 유명한 Ansible과 어떤 유명한 스터디에서 애용하는 AWS의 Cloud Formation과 Azure의 ARM Template를 비교한 표이다.
아래 표의 출처는 책 <테라폼으로 시작하는 IaC>이고, 색깔은 내가 입혔다.
(*색깔은 저자와 출판사의 의도가 아님을 밝힙니다.)
Terraform | Ansible | Cloud Formation | ARM Template | |
유형 | 프로비저닝 | 구성 관리 | 프로비저닝 | 프로비저닝 |
구성 방식 | 이뮤터블 | 뮤터블 | 이뮤터블 | 이뮤터블 |
오픈소스 여부 | 공개 | 공개 | 비공개 | 비공개 |
적용 대상 클라우드 | 멀티 | 멀티 | AWS 전용 | Azure 전용 |
정책 설정 | 가능 | 불가능 | 부분적 | 부분적 |
라이프사이클 관리 | 가능 | 불가능 | 부분적 | 부분적 |
온프레미스 지원 | 부분적 | 부분적 | 불가능 | 불가능 |
위 표에서 볼 수 있듯이, 테라폼은 특정 클라우드나 인프라에 종속적이지 않고 동일한 워크로드를 설계할 수 있다는 것이 장점이다.
2장: 실행 환경 구성
테라폼은 IaC 도구이기 때문에, 코드를 구성하고 테스트하고 실행하는 작업자 환경에서 실행하도록 설계되었다.
Terraform Cloud, Terraform Enterprise에서는 원격 실행 환경을 지원한다.
책에서는 개인이 로컬 작업 환경을 구성하는 방법을 안내한다.
본 포스팅에선 생략하며, 각자 사용 환경에 맞게 테라폼 실행 환경을 구성하는 자세한 방법은 Docs에서 볼 수 있다.
https://developer.hashicorp.com/terraform/downloads
아래는 책과 t1013 스터디에서 사용하는 IDE인 VScode에서 소개하고 권장하는 Extension과 설정이다.
- HashiCorp HCL : syntax highlighting for HCL files - 링크
- HashiCorp Terraform : Highlighting syntax from Terraform 등 - 링크
- 설정 ⇒ Files: Auto Save 값을 afterDelay 로 선택
3장: 기본 사용법
테라폼은 필요에 의해 특정 인프라를 구성하기 위한 목적으로 처음 접하는 경우가 많다.
원하는 특정 인프라를 구성하기 이전에, 테라폼이 IaC 도구로서 갖고있는 기본 사용법을 익혀보자.
3.1 주요 커맨드
3.1.1 커맨드 사용법과 'help' 옵션
terraform 커맨드 종류는 'terraform'만 입력하면 바로 확인할 수 있다.
> terraform
Usage: terraform [global options] <subcommand> [args]
The available commands for execution are listed below.
The primary workflow commands are given first, followed by
less common or more advanced commands.
Main commands:
init Prepare your working directory for other commands
validate Check whether the configuration is valid
plan Show changes required by the current configuration
apply Create or update infrastructure
destroy Destroy previously-created infrastructure
All other commands:
console Try Terraform expressions at an interactive command prompt
fmt Reformat your configuration in the standard style
…
더 자세한 인수와 서브커멘드는 명령어 뒤에 -help를 붙여서 확인할 수 있다.
terraform console -help
terraform init -help
terraform apply -help
3.1.2 terraform init
<한줄 요약>
- 테라폼을 시작하는데 사용되는 첫번째 명령어다.
<세줄 요약>
- 테라폼 구성 파일이 있는 작업 디렉터리를 초기화하는데 사용하는 명령어다.
- terraform init 명령를 통해서 테라폼에서 사용되는 프로바이더, 모듈 등의 지정된 버전에 맞춰서 루트 모듈을 구성한다.
- 작업 디렉터리를 초기화하지 않고(=terraform init 명령어를 실행하지 않고) teraform plan 혹은 terraform apply를 실행하면 프로바이더 등 구성에 대한 초기화 작업이 실행되지 않았다고 에러가 난다.
<Why? 존재 의의>
terraform init, 즉 초기화가 필요한 이유는 무엇일까?
맨 위 테라폼 세줄 요약에서 썼듯이, 테라폼 자체만으론 다양한 인프라와 서비스를 프로비저닝할 수 없다. 대상 인프라의 프로바이더와 API명세를 테라폼 코드로 호출해야 하기 때문이다.
따라서 초기화하면서 프로바이더(Local, cloud, backend 등) 플러그인을 찾고 설치해야 한다.
이는 프로바이더, 모듈, 백엔드 등 구성을 설정하거나 변경할 때도 초기화가 필요하다.
terraform init을 하지 않고 바로 plan 등 명령어를 실행하면 아래와 같은 에러가 나타난다.
3.1.3 validate
작성한 테라폼 구성 파일에 문법적으로 오류가 없는지 찾아주는 역할을 한다. 맞춤법 검사기
3.1.4 plan & apply
terraform plan은 테라폼으로 적용할 인프라의 변경 사항에 관한 실행 계획을 생성한다.
terraform validate가 단순히 문법을 검사하는 용도였다면, terraform plan은 사용자가 출력되는 결과를 확인하여 어떤 변경이 적용될 지 검토하는데에 도움을 준다.(문법은 맞는데 엉뚱한 걸 적용하면 안 되니까)
terraform plan 명령은 변경사항을 실제로 적용하지는 않는다. 한마디로 '변경점 미리보기'로 이해할 수 있다.
terraform apply는 plan에서 적용된 내용을 토대로 작업을 실행한다.
terraform apply만 실행하면 정말 변경을 적용할 것인지 묻는 입력 모드가 실행된다.
이 때, 적용을 진행하려면 yes를 입력한다. yes가 아닌 모든 문자는 적용을 취소로 간주한다.
Do you want to perform these actions?
Terraform will perform the actions described above.
Only 'yes' will be accepted to approve.
Enter a value: yes
3.1.5 destroy
terraform destroy는 테라폼 구성에서 관리하는 모든 개체를 제거한다.
apply와 마찬가지로, 정말 모든 관리 개체들을 삭제할 것인지 묻는 입력 모드가 실행되고, yes라고 입력해야만 삭제를 실행한다.
Do you really want to destroy all resources?
Terraform will destroy all your managed infrastructure, as shown above.
There is no undo. Only 'yes' will be accepted to confirm.
Enter a value: yes
실습
기본 명령어 연습
지금까지 배운 명령어를 실습하여 이미지로 나열해보면 다음과 같다.
init으로 작업 디렉토리를 초기화 한다.
ls
cat main.tf
terraform init
유효성 검사와 plan을 진행한다.
terraform validate
terraform plan
apply로 변경을 적용한다.
새 파일이 생성된 것을 확인한다.
terraform apply
ls
destroy로 개체를 삭제한다.
파일이 삭제된 것을 확인할 수 있다.
terraform destroy
ls
테라폼으로 EC2 1대 배포하기
스터디 1주차에서 배운 테라폼으로 ec2를 생성하고 삭제하는 실습을 영상으로 만들어보았다.
https://www.youtube.com/watch?v=9lZkiLXeCR8