Terraform

cloud04/09.Terraform

Terraform

찬뭉 2023. 11. 15. 10:39

■ 데브옵스의 등장

■ 코드형 인프라란

■ 코드형 인프라 장점

■ 테라폼 작동 방식

■ 테라폼과 다른 코드형 인프라 도구 비교

제 01장 테라폼의 등장

1. 데브옵스(DevOps)의 등장

-----------------------------------------------------

(1) 클라우드의 등장과 IT 인프라의 변화

(2) 클라우드(Cloud)와 온프레미스

(3) 인프라를 코드로 관리

------------------------------------------------------

(1) 클라우드의 등장과 IT 인프라의 변화

클라우드의 등장으로 시스템 개발의 흐름이 크게 바뀌고 있다. 자신의 회사 데이터 센터나 기계실을 보유하여 온프로미스 환경에서 가동시키던 서버들을 클라우드 상의 가상 인스턴스로 옮기고 데이터베이스나 네트워크와 같은 클라우드 서비스를 이용함으로써 실행 환경의 구축 범위가 극도로 줄어들어 짧은 사이클로 릴리즈를 반복하는 스타일로 바뀌었다.

(2) 클라우드(Cloud)와 온프로미스

■ 클라우드 컴퓨팅 정의

클라우드 컴퓨팅은 컴퓨팅 리소스를 인터넷을 통해 서비스로 사용할 수 있는 주문형 서비스입니다. 기업에서 직접 리소스를 조달하거나 구성, 관리할 필요가 없으며 사용한 만큼만 비용을 지불하면 됩니다.

■ 클라우드 서비스 모델

IaaS(Intrastructure as a Service)

PaaS(Platform as a Service)

SaaS(Service as a Service)

FaaS(Function as a Service)

■ 클라우드 배포 유형

프라이빗 클라우드(Private Cloud)

퍼블릭 클라우드(Public Cloud)

하이브리드 클라우드(Hybrid Cloud)

멀티 클라우드(Multi Cloud)

■ 온프레미스(On-premisses)

자사에서 데이터 센터를 보유하고 시스템 구축부터 운용까지를 모두 수행하는 형태

■ 퍼블릭 클라우드(Public Cloud)

인터넷을 경유하여 불특정 다수에게 제공되는 클라우드 서비스

■ 프라이빗 클라우드(Private Cloud)

특정 기업 그룹에게만 제동되는 클라우드 서비스

[참고] 대표적인 클라우드 업체

대표적인 국외 클라우드 업체	대표적인 국내 클라우드 업체
- AWS(Amazon Web Service) - MS Azure - Google Cloud Platform(GCP)	- NCP(Naver Cloud Platform) - KT Cloud - NHN

(3) 인프라를 코드로 관리(Infrastructure as Code(IaC))

Developer + SysOps + DevOps + SecOps

데브옵스(DevOps)

데브옵스(DevOps)는 소프트웨어의 개발(Development)과 운영(Operations)의 합성어로서,
소프트웨어 개발자와 정보기술 전문가 간의 소통, 협업 및 통합을 강조하는 개발 환경이나 문화를 말한다. 데브옵스는 소프트웨어 개발조직과 운영조직간의 상호 의존적 대응이며 조직이 소프트웨어 제품과 서비스를 빠른 시간에 개발 및 배포하는 것을 목적으로 한다.

시삽(SysOps)

시삽(sysop)은 전자 게시판(BBS)이나 온라인 서비스 가상 공동체 등 다중 사용자 컴퓨터 시스템의 관리자이다. 기타 인터넷 기반 네트워크 서비스들의 관리자를 의미하기도 한다. 시스템 운영자(System Operator)의 줄임말이며, 시솝, 시샵 이라고도 한다. 사용자들과의 창구 역할을 맡고, 시스템 상의 문제를 고치거나 문제를 일으키는 사용자에게 제재를 가하는 등의 일을 한다.

2. 코드형 인프라(Infrastructure as Code)란?

코드형 인프라(Infrastructure as Code)란?

코드형 인프라란 코드를 작성 및 실행하여 인프라를 생성, 배포, 수정, 정리하는 것을 말한다.
-> 서버, 네트워크, 애플리케이션, 데이터베이스, 자동화된 테스트, 배포 프로세스 등

코드형 인프라(IaC)란? 코드가 곧 인프라이고, 인프라가 곧 코드이다.
-> Terraform

(1) 코드형 인프라 도구

코드형 인프라 도구에는 크게 5가지 범주가 있다.

애드혹 스크립트 (ex: 쉘스크립트)

구성 관리 도구 (ex: Ansible)

서버 템플릿 도구 (ex: Packer)

오케스트레이션 도구 (ex: Kubernetes)

프로비전 도구 (ex: Terraform)

1) 애드혹 스크립트(Ad-Hoc Script)

■ 애드혹 스크립트(Ad-Hoc Script)는 서버를 자동화 하는 가장 간단한 방법 중 하나이다.

-> 배쉬(bash), 루비(Ruby), 파이썬(Python) 등

■ 문제점

* 서버, 네트워크, 데이터베이스, 로드밸런서 구성등이 늘어나면 => ?

* 따라서, 애드혹 스크립트는 소규모 일회성 작업에 적합하다.

2) 구성 관리 도구(Configuration Tools)

■ 구성 관리 도구로 대상 서버에 소프트웨어를 설치하고 관리하도록 설계되어 있다.

-> 셰프, 퍼핏, 앤서블(Ansible), 솔트 스택(SaltStack)

■ 구성 관리 도구의 특징

* 코딩 규칙

* 멱등성

* 분산형 구조

3) 서버 템플릿 도구(Server Template Tools)

■ 서버 템플릿 도구

구성 관리 도구의 대안으로 최근에는 도커(Docker), 패커(Packer), 베이그런트(Vagrant)와 같은 서버 템플릿 도구의 사용이 높아지고 있는 추세이다.

서버 템플릿은 불변 인프라(Immutable Infrastructure)로 전환하는 핵심적인 구성 요소이다.

■ 서버 템플릿 도구 예제 - Packer + Ansible

패커 탬플릿 ——> 패커(Packer) ——> 서버 이미지 ——> 앤서블(Ansible)

서버 템플릿 도구인 패커를 사용하여 웹서버가 설치된 서버 이미지 생성 후

앤서블과 같은 배포 도구를 사용하여 모든 서버에 이미지를 설치한다.

이미지 작업을 위한 도구는 크게 2가지 범주로 나눈다.

가상 머신(Virtual Machine)
-> VMware, VirtualBox, Parallels 등
-> 가상머신은 하드웨어를 포함한 전체 컴퓨터 시스템을 에뮬레이트한다.

컨테이너(Container)
-> Docker, LXC, LXD, OpenVZ 등

패커 템플릿(web-server.json)

다음은 AWS에서 실행할 수 있는 VM 이미지인 아마존 머신 이미지(Amazon Machine
Image,AMI)를 생성하는 템플릿이다.

4) 오케스트레이션 도구(Orchestration Tools)

■ 다양한 오케스트레이션 도구들:

Kubernetes(!!!! Gold Standard !!!!)

* Amazon EKS(Elastic Kubernetes Service)

* Google GKE(Google Kubernetes Engine)

* MS AKS(Azure Kubernetes Service)

Apache Marathon(Mesos)

Docker Swarm

Hashicorp Nomad

Amazon ECS(Elastic Container Service)

MS ACS(Azure Container Service)

기타

5) 프로비전 도구(Provision Tools)

■ 프로비전 도구들:

HashiCorp Terraform

AWS Cloud Formation

OpenStack Heat

기타

프로비전 도구들 사용하여 서버, 데이터베이스, 캐시, 로드밸런서, 큐, 모니터링, 서브넷 구성, 방화벽 설정, 라우팅 규칙 설정, SSL 인증서 등 인프라에 관한 거의 모든 부분을 프로비저닝 할 수 있다.

■ 프로비전 도구 예제 - Terraform

테라폼 구성 ——> 테라폼 ——> 클라우드 공급자 ——> 클라우드 환경 구성

3. 코드형 인프라의 장점

1) 코드형 인프라 장점

자급식 배포(Self-service)
코드를 수동으로 배포하는 대부분 팀에서는 배포를 수행하는 데 필요한 '마법 명령어'를 알고 있는 소수의 시스템 관리자만 프로덕션 환경에 접속하여 배포를 진행할 수 있다. 이것은 회사가 성장하는 데 장애물이 된다. 인프라를 코드로 정의하면 전체 배포 프로세스를 자동화할 수 있으며 개발자는 필요할 때마다 자체적으로 배포를 진행할 수 있다.

속도와 안정성(Speed and safety)
배포 프로세스를 자동화하면 사람이 진행하는 것보다 더욱 빠르게 컴퓨터가 배포를 진행할 수 있다. 자동화된 프로세스는 일관되고 반복 가능하며, 수동으로 진행했을 때보다 오류가 적게 발생하기 때문에 더 안전하다.

문서화(Documentation)
시스템 관리자 조직만 인프라에 관한 정보를 독점하는 것이 아니라 누구나 읽을 수 있는 소스 파일로 인프라 상태를 나타낼 수 있다. 즉, 코드형 인프라는 문서 역할을 하여 시스템 관리자가 휴가 중일 때도 조직의 모든 사람이 인프라 구조를 이해하고 업무를 볼수 있도록 해준다.

버전 관리(Version control)
인프라의 변경 내용이 모두 기록된 코드형 인프라 소스 파일을 저장할 수 있으므로 버전을 쉽게 관리할 수 있다. 인프라 변경 내역이 남아 있기 때문에 시스템에 문제가 생겼을 때 문제가 발생한 지점을 찾기가 쉬워진다. 문제의 내용을 확인한 다음 문제가 없던 이전 코드로 다시 되돌리면 문제가 해결된다. 이는 디버깅을 돕는 강력한 도구이다.

유효성 검증(Validation)
인프라 상태가 코드로 정의되어 있으면 코드가 변경될 때마다 검증을 수행하고 일련의 자동화된 테스트를 실행할 수 있으며, 정적 분석(Static Analysis) 프로그램에 코드를 전달하여 오류 발생 위험을 줄일수 있다.

재사용성(Reuse)
인프라를 재사용 가능한 모듈로 패키징할 수 있으므로 모든 제품을 매번 처음부터 배포하는 대신 문서화되고 검증된 일관되게 배포할 수 있다.

행복(Hapiness)
코드형 인프라를 사용해야 하는 또 다른 중요한 이뉴는 바로 코드형 인프라를 사용했을 때 얻을 수 있는 행복이다. 코드 배포나 수동적인 인프라 관리는 반복적이고 지루한 일이다. 이 작업들이 창의성을 불러일으키거나 도전 의식을 북돋우거나 성과를 인정받는 일이 아니기 때문에 개발자와 시스템 관리자는 이러한 작업을 기피한다. 처음에는 문제를 알아차리지 못하고 배포가 잘 진행되는 것 같지만 한참이 지나 문제가 터지고 나서야 인지하게 될것이다. 이러한 환경은 스트레스를 유발한다. 코드형 인프라는 개발자가 코드 개발 작업에 더 집중할 수 있도록 대안을 제시한다.

4. 테라폼의 작동 방식

1) HashiCorp 회사 재품군

Infrastructure	Security	Networking	Applications
Terraform Packer	Vault	Consul	Nomad Vagrant

종 류	설 명
packer	https://www.packer.io/ Automate image builds with Packer. Create identical images for multiple platforms from a single source configuration.
terraform	https://www.terraform.io/ Automate infrastructure on any cloud with Terraform. Infrastructure automation to provision and manage resources in any cloud or data center.
Consul	https://www.consul.io/ Identity-based networking with Consul. Consul uses service identities and traditional networking practices to help organizations securely connect applications running in any environment.
Nomad	https://www.nomadproject.io/ Orchestration made easy. A simple and flexible scheduler and orchestrator to deploy and manage containers and non-containerized applications across on-premises and clouds at scale.
Vagrant	https://www.vagrantup.com/ Development environments simplified. Vagrant enables the creation and configuration of lightweight, reproducible, and portable development environments.

2) HashiCorp Terraform 동작원리

이 부분은 다음 장에서 자세하게 설명한다. 이 부분에서는 간략하게만 설명한다.

■ Provisioning(https://ko.wikipedia.org/wiki/프로비저닝)

프로비저닝(provisioning)은 사용자의 요구에 맞게 시스템 자원을 할당, 배치, 배포해 두었다가 필요시 시스템을 즉시 사용할 수 있는 상태로 미리 준비해 두는 것을 말한다. 서버 자원 프로비저닝, OS 프로비저닝, 소프트웨어 프로비저닝, 스토리지 프로비저닝, 계정 프로비저닝 등이 있다. 수동으로 처리하는 '수동 프로비저닝'과 자동화 툴을 이용해 처리하는 '자동 프로비저닝'이 있다.

테라폼의 동작

Refresh : view <——> Real ($ terraform apply)

Plan : Real ——> Desired ($ terraform plan)

Apply : Plan ——> Real ($ terraform apply)

Destroy ($ terraform destroy)

■ Providers(최소 +1000여개 providers 제공됨)

(IaaS) AWS, Azure, GCP, OpenStack, VMware, ...

(PaaS) k8s, Helm, Lamda, ...

(SaaS) Datadog, GitHub, ...

■ 워크플로(Workflow)(https://ko.wikipedia.org/wiki/워크플로)

워크플로(영어: workflow)는 작업 절차를 통한 정보 또는 업무의 이동을 의미하며, 작업 흐름이라고도 부른다. 더 자세히 말해, 워크플로는 작업 절차의 운영적 측면이다. 업무들이 어떻게 구성되고, 누가 수행하며, 순서가 어떻게 되며, 어떻게 동기화를 시킬지, 업무를 지원하기 위한 정보가 어떻게 흐르는지 그리고 업무가 어떻게 추적되는지이다.

다음과 같이 3가지의 키워드로 정의할 수 있다.
작업의 흐름도
작업 절차
업무의 이동성

5. 테라폼과 다른 코드형 인프라 도구 비교

(1) 테라폼과 다른 코드형 인프라 도구의 비교

■ 구성관리 vs 프로비저닝

구성 관리 도구들:

셰프(Chef, www.chef.io/chef)

퍼핏(Puppet, puppetlabs.com)

앤서블(Ansible, ansible.com)

솔트스택(Salt Stack, saltproject.io)

프로비전 도구들:

클라우드 포메이션(AWS Cloud Formation)

테라폼(Terraform)

오픈스택 히트(OpenStack Heat)

[비교] 반드시 읽어 주세요.**(!!!! 그림 위주로 봐 주세요. !!!!)

http://www.itdaily.kr/news/articleView.html?idxno=201814

[비교] **"구성관리 도구" vs "프로비전 도구"**

구성관리 도구와 프로지전 도구는 점점 구분이 애매해 지고 있다.(클라우드 업체들이 2가지 모두를 내장하기 시작했다.)

(예) 서버 템플릿 도구(패커, 도커)를 사용하는 경우라면, 테라폼을 사용하여 deploy 하고

(예) 서버 템플릿 도구를 사용하지 않는다면, 테라폼 사용하여 프로비저닝을 하고 셰프를 사용하여 각 서버를 구성한다.

■ 가변 인프라 vs 불변 인프라

가변 인프라 패러다임 : Chef, Puppet, Ansible, Saltstack

불변 인프라 패러다임 : Terraform, OpenStack Heat, AWS Cloud Formation

[비교] 가변 인프라 패러다임 vs 불변 인프라 패러다임

테라폼 같은 경우에는 대부분의 불변 이미지를 사용한다.(도커 이미지, 패커 이미지)

■ 절차적 언어 vs 선언적 언어

절차적 언어 스타일 코드: Chef, Ansible

선언적 언어 스타일 코드:
Terraform, AWS Cloud Formation, OpenStack Heat, Saltstack, Puppet

[비교] 절차적 언어 vs 선언적 언어

절차적 언어 방식과 선언적 언어 방식은 코드를 변경할 때 차이점이 발생한다.

(예) 15대의 서버를 사용하다가 25대의 서버로 증설해야 하는 경우

-> Ansible은 어떻게 동작 할까요?

-> Terraform은 어떻게 동작 할까요?

절차적 언어 방식을 사용하는 코드형 인프라 도구의 2가지 단점

절차적 코드는 인프라의 마지막 상태 정보를 기록하고 있지 않다.

절차적 코드는 재 사용 가능성을 제한한다.

선언적 언어는 최종상태가 동일해야한다

절차적 언어는

(2) 여러 도구를 함께 사용하는 경우의 예

아래 그림에서 사용되는 용어

* App : Application

* Server : Physical Server/Logical Server

* VM : Virtual Machine

* Infra : Infrastructure(Network, LB, DB, User, Authority, ..)

Terraform + Ansible	Terraform + Packer	Terraform + Packer + Docker
+--------+ \| App \| <----- Ansible +--------+ <----+ \| Server \| \| +--------+ +-- Terraform \| Infra \| \| +--------+ <----+	+--------+ \| VM \| <----- Packer/vagrant +--------+ <----+ \| Server \| \| +--------+ +-- Terraform \| Infra \| \| +--------+ <----+	+----------+ \| Container\| <----- Docker/kubernetes +----------+ \| VM \| <----- Packer/vagrant +----------+ <----+ \| Server \| \| +----------+ +-- Terraform \| Infra \| \| +----------+ <----+

제 02 장 테라폼 시작하기

___________________________

■ 테라폼 소개

■ 테라폼 설치

■ HCL(HashiCorp Configuration Language)

■ 변수(Variable)

■ 자동 스케일링 그룹

■ 로드 밸런서 배포

___________________________

1. 테라폼 소개

(1) 테라폼(Terraform)이란?

■ 테라폼이란? (https://developer.hashicorp.com/terraform/intro)

Terraform is an infrastructure as code tool that lets you build, change, and version cloud and on-prem resources safely and efficiently.
Terraform은 클라우드 및 온프레미스 리소스를 안전하고 효율적으로 빌드, 변경 및 버전화할 수 있는 코드형 인프라 도구입니다.

HashiCorp Terraform is an infrastructure as code tool that lets you define both cloud and on-prem resources in human-readable configuration files that you can version, reuse, and share. You can then use a consistent workflow to provision and manage all of your infrastructure throughout its lifecycle. Terraform can manage low-level components like compute, storage, and networking resources, as well as high-level components like DNS entries and SaaS features.
HashiCorp Terraform은 버전을 지정하고 재사용하고 공유할 수 있는 사람이 읽을 수 있는 구성 파일에서 클라우드 및 온프레미스 리소스를 모두 정의할 수 있는 코드형 인프라 도구입니다. 그런 다음 일관된 워크플로를 사용하여 수명 주기 동안 모든 인프라를 프로비저닝하고 관리할 수 있습니다. Terraform은 컴퓨팅, 스토리지 및 네트워킹 리소스와 같은 하위 수준 구성 요소와 DNS 항목 및 SaaS 기능과 같은 상위 수준 구성 요소를 관리할 수 있습니다.

(2) 테라폼의 동작원리

Terraform은 API(응용 프로그래밍 인터`페이스)를 통해 클라우드 플랫폼 및 기타 서비스에서 리소스를 생성하고 관리합니다. 제공업체를 통해 Terraform은 액세스 가능한 API를 통해 거의 모든 플랫폼 또는 서비스와 함께 작동할 수 있습니다.

HashiCorp와 Terraform 커뮤니티는 이미 다양한 유형의 리소스와 서비스를 관리하기 위해 수천 개의 공급자를 작성했습니다. Amazon Web Services(AWS), Azure, Google Cloud Platform(GCP), Kubernetes, Helm, GitHub, Splunk, DataDog 등을 포함 하여 Terraform Registry(https://registry.terraform.io/)에서 공개적으로 사용 가능한 모든 공급자를 찾을 수 있습니다.

■ Providers(최소 1000+ 개 providers 제공됨)

(IaaS) AWS, Azure, GCP, VMware, OpenStack, . ....

(PaaS) k8s, Helm, ...

(SaaS) Datadog, GitHub, ...

■ 테라폼(Terraform), 공급자(providers), 모듈(modules) 작동 방식

테라폼(Terraform)

Terraform은 물리적 시스템, VM, 네트워크 스위치, 컨테이너 등과 같은 인프라 리소스를 프로비저닝, 업데이트 및 파괴합니다.

구성(Configurations)

구성은 인프라 리소스의 원하는 상태를 설명하기 위해 사람이 읽을 수 있는 HCL(HashiCorp Configuration Language)을 사용하여 Terraform용으로 작성된 코드입니다.

공급자(Providers)

공급자는 Terraform이 해당 리소스를 관리하는 데 사용하는 플러그인입니다. 지원되는 모든 서비스 또는 인프라 플랫폼에는 사용 가능한 리소스를 정의하고 해당 리소스를 관리하기 위해 API 호출을 수행하는 공급자가 있습니다.

모듈(Modules)

모듈은 다른 구성에서 호출 및 구성할 수 있는 재사용 가능한 Terraform 구성입니다. 대부분의 모듈은 단일 공급자로부터 밀접하게 관련된 몇 가지 리소스를 관리합니다.

테라폼 레지스트리(Terraform Registry)

Terraform 레지스트리를 사용하면 모든 공급자 또는 모듈을 쉽게 사용할 수 있습니다. 이 레지스트리의 공급자 또는 모듈을 사용하려면 구성에 추가하기만 하면 됩니다. "terraform init" 명령을 실행하면 Terraform이 자동으로 필요한 모든 것을 다운로드합니다.

(3) 테라폼 워크플로(Workflow)

쓰기(Write): 여러 클라우드 공급자 및 서비스에 걸쳐 있을 수 있는 리소스를 정의합니다. 예를 들어 보안 그룹 및 로드 밸런서가 있는 Virtual Private Cloud(VPC) 네트워크의 가상 머신에 애플리케이션을 배포하기 위한 구성을 생성할 수 있습니다.
=> # vi example.tf

계획(Plan): Terraform은 기존 인프라 및 구성을 기반으로 생성, 업데이트 또는 파괴할 인프라를 설명하는 실행 계획을 생성합니다.
=> # terraform plan

적용(Apply): 승인 시 Terraform은 리소스 종속성을 고려하여 제안된 작업을 올바른 순서로 수행합니다. 예를 들어 VPC의 속성을 업데이트하고 해당 VPC의 가상 머신 수를 변경하면 Terraform은 가상 머신을 확장하기 전에 VPC를 다시 생성합니다.
=> # terraform apply

(4) 테라폼의 특징

모든 인프라 관리(Manage any infrastructure)
Terraform Registry 에서 이미 사용하고 있는 많은 플랫폼과 서비스에 대한 공급자를 찾아서 사용이 가능하며 또한, 직접 작성할 수도 있습니다. Terraform은 인프라에 대한 불변의 접근 방식을 취하여 서비스 및 인프라를 업그레이드하거나 수정하는 복잡성을 줄입니다.

인프라 추적(Track your infrastructure)
Terraform은 계획을 생성하고 인프라를 수정하기 전에 승인을 요청합니다. 또한 상태 파일 에서 실제 인프라를 추적합니다. 이 파일 은 환경에 대한 정보 소스 역할을 합니다. Terraform은 상태 파일을 사용하여 구성과 일치하도록 인프라에 대한 변경 사항을 결정합니다.

변경 자동화(Automate changes)
Terraform 구성 파일은 선언적이므로 인프라의 최종 상태를 설명합니다. Terraform이 기본 로직을 처리하기 때문에 리소스를 생성하기 위해 단계별 지침을 작성할 필요가 없습니다. Terraform은 리소스 종속성을 결정하기 위해 리소스 그래프를 빌드하고 병렬로 비의존 리소스를 생성하거나 수정합니다. 이를 통해 Terraform은 리소스를 효율적으로 프로비저닝할 수 있습니다.

구성 표준화(Standardize configurations)
Terraform은 구성 가능한 인프라 컬렉션을 정의하는 모듈 이라는 재사용 가능한 구성 구성 요소를 지원 하여 시간을 절약하고 모범 사례를 장려합니다. Terraform 레지스트리에서 공개적으로 사용 가능한 모듈을 사용하거나 직접 작성할 수 있습니다.

협력(Collaborate) -> Terraform Enterprise/Terraform Cloud 권장
구성이 파일에 작성되므로 VCS(버전 제어 시스템)에 커밋하고 Terraform Cloud를 사용하여 팀 전체에서 Terraform 워크플로를 효율적으로 관리할 수 있습니다. Terraform Cloud는 일관되고 안정적인 환경에서 Terraform을 실행하며 공유 상태 및 비밀 데이터에 대한 보안 액세스, 역할 기반 액세스 제어, 모듈과 공급자를 모두 공유하기 위한 비공개 레지스트리 등을 제공합니다.

(5) 테라폼 구성 요소

provider	테라폼으로 생성할 인프라의 종류를 의미한다.(ex: aws, google, ...)
resource	테라폼으로 실제로 생성할 인프라 자원을 의미한다.(ex: vpc, ec2, ...)
state	테라폼을 통해 생성한 자원의 상태를 의미한다.(ex: *.tfstate)
output	테라폼으로 만든 자원을 변수 형태로 state에 저장하는 것을 의미한다.
module	공통적으로 활용할 수 있는 코드를 문자 그대로 모듈 형태로 정의해는 것을 의미한다.
remote	다른 경로의 state를 참조하는 것을 말한다. output 변수를 불러올때 주로 사용한다.

■ provider

# 보통 provider.tf로 파일을 생성한다.
# ** AWS provider **
provider "aws" {
region = "ap-northeast-2"
}

■ resource

# main.tf, vpc.tf 등 원하는 형태로 파일이름을 사용한다.
# ** VPC 생성 **
resource "aws_vpc" "example" {
cidr_block = "10.0.0.0/16"
# cidr_block 외에도 많은 인자가 존재한다.
}

■ state

# terraform.tfstate 라는 파일명을 가진다.
{
"version": 4,
"terraform_version": "1.3.3",
"serial": 36,
"lineage": "9effb2cb-46c8-39f8-c3ab-16ed2a1afb93",
"outputs": {},
"resources": [],
"check_results": []
}

■ output

resource "aws_vpc" "example" {
cidr_block = "10.0.0.0/16"
# cidr_block 외에도 많은 인자가 존재한다.
}

output "vpc_id" {
value = aws_vpc.default.id
}
output "cidr_block" {
value = aws_vpc.default.cidr_block
}
output "public_ip" {
value = aws_instance.example.public_ip
}

■ module

module "vpc" {
source = "../_modules/vpc"
cidr_block = "10.0.0.0/16"
}

■ remote

# remote는 원격 참조 개념으로 이해하면 좋다.
data "terraform_remote_state" "vpc" {
backend = "remote"

config = {
bucket = "terraform-s3-bucket"
key = "terraform/vpc/terraform.tfstate"
region = "ap-northeast-2"
}
}

(6) 테라폼 기본 명령어

$ terraform CMD

init	테라폼 명령 사용을 위해 각종 설정을 진행한다.
plan	테라폼으로 작성한 코드가 실제로 어떻게 만들어질것인지 대한 예측 결과를 보여준다.
apply	테라폼 코드로 실제 인프라를 생성하는 명령이다.
import	이미 만들어진 자원을 테라폼 state 파일로 옮겨주는 명령이다.
state	테라폼 state를 다루는 명령이다. 하위 명령어로 mv, push와 같은 명령어가 있다.
destroy	생성된 자원들 state 파일 모두 삭제하는 명령이다.

* terraform show

* terraform fmt

* terraform state list

* terraform validate

(7) 명령 실행 단계(Command Process)

init	작성한 코드 폴더에서 init 명령을 입력하면, 테라폼의 다른 명령들을 위한 설정을 진행한다. 내부적으로는 provider와 state, module 설정 등이 있다. $ terraform init
plan	작성한 테라폼 코드가 어떻게 만들어질지에 대한 예측 결과를 보여주는 명령이다. 기본적으로 plan에 문제가 없어야 apply에 문제가 없을 확률이 높다. $ terraform plan
apply	실제로 작성한 코드로 인프라를 구성하는 명령이다. 인프라에 영향을 끼치는 명령이므로 주의 깊게 실행하여야 한다. $ terraform apply

2. 테라폼 아키텍처

(1) 테라폼 아키텍처 소개

Terraform은 Hashicorp에서 개발한 오픈 소스 도구로 클라우드 또는 온프레미스 환경에 관계없이 반복 가능한 코드를 통해 간단하고 효율적이며 선언적인 방식으로 인프라를 프로비저닝할 수 있다.

Terraform의 주요 기능 중 하나는 클라우드에 구애받지 않는 특성이다. 온프레미스 환경은 물론 Azure, AWS, GCP, VMware 등 모든 클라우드 환경에 인프라를 배포할 수 있다. 이 이점을 통해 클라우드 서비스 공급자마다 다른 도구를 배우거나 채택하지 않고도 클라우드 인프라를 자동화할 수 있다.

Terraform 아키텍처는 주로 다음 구성 요소로 구성된다.

테라폼 코어(Terraform Core)

공급자(Provider)

상태 파일(Terraform State)

(1) 테라폼 코어(Terraform Core)

Terraform의 핵심(Terraform CLI라고도 함)은 Go 프로그래밍 언어를 사용하여 개발된 정적으로 컴파일된 바이너리를 기반으로 한다.

이 바이너리는 Terraform 사용자를 위한 기본 인터페이스 역할을 하는 "terraform"이라는 명령줄 도구(CLI)를 생성한다. 오픈 소스이며 Terraform GitHub 리포지토리에서 액세스할 수 있다.

(2) 공급자(Providers)

Terraform 공급자는 Terraform이 클라우드 공급자, 데이터베이스 및 DNS 서비스를 포함하되 이에 국한되지 않는 다양한 범위의 서비스 및 리소스와 통신할 수 있도록 하는 모듈이다.

각 공급자는 Terraform이 특정 서비스 내에서 관리할 수 있는 리소스를 정의하고 Terraform 구성을 해당 서비스에 특정한 API 호출로 변환하는 일을 담당한다.

공급자는 AWS, Azure, Google Cloud와 같은 주요 클라우드 공급자가 개발한 것과 다양한 서비스에 대한 커뮤니티 지원 공급자를 포함하여 수많은 서비스 및 리소스에 사용할 수 있습니다. 공급자를 활용함으로써 Terraform 사용자는 기본 서비스 또는 공급자에 관계없이 일관되고 재현 가능한 방식으로 인프라를 유지할 수 있다.

(3) 상태 파일

Terraform 상태 파일은 Terraform 기능의 필수 요소입니다. Terraform이 관리하는 리소스와 현재 상태 및 종속성에 대한 정보를 저장하는 JSON 파일이다.

Terraform은 상태 파일을 활용하여 새 구성이 적용될 때 인프라에 적용해야 하는 변경 사항을 결정한다. 또한 여러 Terraform 실행에서 리소스가 불필요하게 다시 생성되지 않도록 한다.

상태 파일은 Terraform을 실행하는 머신에 로컬로 보관하거나 Azure Storage 계정, Amazon S3 또는 HashiCorp Consul과 같은 원격 백엔드를 사용하여 원격으로 보관할 수 있다 . 상태 파일에는 관리 중인 인프라에 대한 민감한 정보가 포함되어 있으므로 상태 파일을 보호하고 자주 백업을 유지하는 것이 중요하다.

2. 테라폼 설치

[참고] Install Terraform
https://developer.hashicorp.com/terraform/tutorials/aws-get-started/install-cli

(1) 여러가지 플랫폼에 테라폼 설치 방법

https://developer.hashicorp.com/terraform/tutorials/aws-get-started/install-cli#install-terraform

수동 설치(Manual Installation)
- Mac or Linux
- Windows

Mac OS X 설치(brew)

Windows 설치(choco)

Linux 설치(yum/dnf, apt-get/apt)
- Ubuntu/Debian, CentOS/RHEL, Fedora, Amazon Linux

(2) 윈도우 시스템에 테라폼 설치 예

[참고] Install Terraform

https://developer.hashicorp.com/terraform/downloads

다음은 Windows 테라폼을 설치하는 예이다.

윈도우에 바이너리 파일 설치
(ㄱ) choco 설치
(ㄴ) terraform 설치

윈도우에 바이너리 파일로 설치

(ㄱ) choco 설치(https://chocolatey.org/install)

관리자 권한으로 파워쉘(Power Shell)을 실행하고 다음과 같이 실행한다.

■ choco 설치

PS C:\Windows\system32> Set-ExecutionPolicy Bypass -Scope Process -Force; [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.ServicePointManager]::SecurityProtocol -bor 3072; iex ((New-Object System.Net.WebClient).DownloadString('https://community.chocolatey.org/install.ps1'))

■ choco 버전 확인

PS C:\Windows\system32> choco -v
1.2.0

(ㄴ) choco를 사용해서 terraform 설치

■ terraform 설치

PS C:\Windows\system32> choco install terraform
Chocolatey v1.2.0
Installing the following packages:
terraform
By installing, you accept licenses for the packages.
Progress: Downloading terraform 1.3.2... 100%

terraform v1.3.2 [Approved]
terraform package files install completed. Performing other installation steps.
The package terraform wants to run 'chocolateyInstall.ps1'.
Note: If you don't run this script, the installation will fail.
Note: To confirm automatically next time, use '-y' or consider:
choco feature enable -n allowGlobalConfirmation
Do you want to run the script?([Y]es/[A]ll - yes to all/[N]o/[P]rint): A

Removing old terraform plugins
Downloading terraform 64 bit
from 'https://releases.hashicorp.com/terraform/1.3.2/terraform_1.3.2_windows_amd64.zip'
Progress: 100% - Completed download of C:\Users\soldesk\AppData\Local\Temp\chocolatey\terraform\1.3.2\terraform_1.3.2_windows_amd64.zip (18.73 MB).
Download of terraform_1.3.2_windows_amd64.zip (18.73 MB) completed.
Hashes match.
Extracting C:\Users\soldesk\AppData\Local\Temp\chocolatey\terraform\1.3.2\terraform_1.3.2_windows_amd64.zip to C:\ProgramData\chocolatey\lib\terraform\tools.
..
C:\ProgramData\chocolatey\lib\terraform\tools
ShimGen has successfully created a shim for terraform.exe
The install of terraform was successful.
Software installed to 'C:\ProgramData\chocolatey\lib\terraform\tools'

Chocolatey installed 1/1 packages.
See the log for details (C:\ProgramData\chocolatey\logs\chocolatey.log).

■ terraform 설치 확인

PS C:\Windows\system32> terraform -help plan
Usage: terraform [global options] plan [options]

Generates a speculative execution plan, showing what actions Terraform
would take to apply the current configuration. This command will not
actually perform the planned actions.

You can optionally save the plan to a file, which you can then pass to
the "apply" command to perform exactly the actions described in the plan.

Plan Customization Options:
..... (중략) .....

(3) 리눅스(CentOS/RHEL)에서 테라폼 설치 예

[참고] Install Terraform

https://developer.hashicorp.com/terraform/downloads

(ㄱ) 패키지 다운로드(yum-utils)

(ㄴ) 저장소 등록

(ㄷ) 테라폼 설치

(ㄱ) 패키지 다운로드

$ sudo yum install -y yum-utils

yum-utils 패키지안에 yum-config-manager CMD 들어 있다.

CentOS 7 이하 vs CentOS 8 이상
(CentOS 7 이하) yum-config-manager CMD
(CentOS 8 이상) yum config-manger CMD

(ㄴ) YUM Repository 등록

$ sudo yum-config-manager \

--add-repo https://rpm.releases.hashicorp.com/RHEL/hashicorp.repo

/etc/yum.repos.d/hashicorp.repo

(ㄷ) 테라폼 설치

$ sudo yum -y install terraform

3. HCL(HashiCorp Configuration Language)

(1) HCL과 CDK

https://developer.hashicorp.com/terraform/language

https://developer.hashicorp.com/terraform/cdktf/concepts/hcl-interoperability

Terraform에는 HashiCorp 구성 언어(HCL) 또는 JSON 구문으로 작성된 인프라 구성 파일이 필요합니다. Terraform용 CDK(CDKTF)는 명령형 프로그래밍 언어에 정의된 구성을 Terraform용 JSON 구성 파일로 변환하여 작동합니다.

CDKTF는 조직 내의 모든 팀과 프로젝트에 적합한 선택이 아닐 수 있습니다. 예를 들어 일부 팀은 이미 Terraform에 매우 익숙하고 HCL 모듈, 공급자 등을 만들었습니다. 유연성을 제공하기 위해 CDKTF 애플리케이션은 HCL로 작성된 Terraform 프로젝트와 상호 운용 가능합니다.

구체적으로:

CDKTF 애플리케이션은 기존의 모든 Terraform 공급자 및 HCL 모듈을 사용할 수 있습니다.

CDKTF는 HCL Terraform 프로젝트가 구성에서 사용할 수 있는 모듈을 생성할 수 있습니다.

HCL(Terraform) 버전(2022년 10월28일 현재)

v1.3.x(최신)

v1.2.x

v1.1 및 이전

[비교] JSON vs HCL

https://docmoa.github.io/04-HashiCorp/03-Terraform/01-Information/02-hcl.html

JSON	HCL
{ "resource": { "aws_instance": { "example": { "instrance_type": "t2.micro", "ami": "ami-test123" } } } }	resource "aws_instance" "example" { instance_type = "t2.micro" ami = "ami-test123" }

[비교] Python vs HCL

Python	HCL
import aws import asyncplan aws(region="myregion", profile="default") my_asyncplan = asyncplan() aws_instance = aws.instance() aws_instance.instance_type = "t2.micro" aws_instance.ami = "ami-test123" my_asyncplan.add(aws_instance)	provider "aws" { region = var.region profile = var.profile } resource "aws_instance" "example" { instance_type = "t2.micro" ami = "ami-test123" }

(2) HCL 기본 문법

■ HCL 기본 문법(HCL Basic Syntax)

// 한줄 주석 방법1(C++ 주석)
# 한줄 주석 방법2(Linux/Unix 주석)

/*
여러줄(C 주석)
주석
라인
*/

locals {
key1 = "value1" // = 를 기준으로 키와 값이 구분됩니다.
key2 = "value2" // = 양쪽의 공백은 중요하지 않습니다.
myStr = "TF ♡ UTF-8" // UTF-8 문자를 지원합니다.(ex: ko_KR.UTF-8)
multiStr = <<FOO // <<EOF 같은 여러줄의 스트링을 지원합니다.
Multi
Line
String
with <<ANYTEXT
FOO // 앞(ex: FOO)과 끝 문자(ex: FOO)만 같으면 됩니다.

boolean1 = true // boolean true
boolean2 = false // boolean false를 지원합니다.

deciaml = 123 // 기본적으로 숫자는 10진수
octal = 0123 // 0으로 시작하는 숫자는 8진수
hexadecimal = "0xD5" // 0x 값을 포함하는 스트링은 16진수
scientific = 1e10 // 과학표기법도 지원합니다.

//funtion 들이 많이 준비되어있습니다.
myprojectname = format("%s is myproject name", var.project)
//인라인(inline) 조건문도 지원합니다.
credentials = var.credentials == "" ? file(var.credentials_file) : var.credentials
}

[참고] 함수(function)

https://developer.hashicorp.com/terraform/language/functions

[참고] 다양한 HCL 예제

https://github.com/hashicorp/hcl

[참고] HCL 기본 구문 사양

https://github.com/hashicorp/hcl/blob/main/hclsyntax/spec.md

[참고] 테라폼(Terrform) 기초 튜토리얼

https://www.44bits.io/ko/post/terraform_introduction_infrastrucute_as_code

[참고] 테라폼 스타일 가이드

https://github.com/jonbrouse/terraform-style-guide/blob/master/README.md#resource-naming

(3) 테라폼 파일 및 디렉토리

(3-1) 파일 확장자와 인코딩