Terraform dynamic blocks Terraform 을 이용해서 resource 들을 생성하다보면 종종 사용하게 되는게 resource 내부의 configuration block 이다. 이런 block 들은 한개만 사용될 수도 있지만 경우에 따라서는 여러개를 설정해서 사용하는 경우도 있을 것이고, 한개도 필요 없는 경우도 있을 것이다. 이런 다양한 경우를 좀 더 유연하게 컨트롤 할 수 있게 해주기 위해 dynamic block 이 사용된다. (0.12 버전부터 지원) 예제와 함께 사용법에 대해 알아보자. 사용법 예제 코드를 살펴보며 사용법에 대해 익혀보자. main.tf terraform.tfvars variables.tf terraform.tfvars 파일에서 `ingre

Terraform cloud Terraform cloud란 이름 그대로 Terraform 의 운영환경을 cloud 를 통해 관리할 수 있도록 해주는 서비스다. 예를 들어 Server 를 cloud 환경에서 운영할 수 있도록 해주는 AWS, GCP 같은 서비스라고 생각하면 된다. Terraform cloud 는 Terraform 의 실행환경과 state 를 관리해주기 때문에, 따로 Terraform 을 위한 instance 를 운영하거나 state 관리를 위해 remote 저장소를 사용하는 일은 하지 않도록 도와준다. 즉 Terraform 사용자는 Terraform 운영은 모두 Terraform cloud에 맡기고, Terraform code 를 통해 infrastructure 를 구축하는 일에 집중할 수 있게된다. 그렇다면 어떻게 Terraform cloud 를 사용하면 되는지 살펴보자.

Workspace 일반적으로 서버 개발자들은 목적에 따라 여러개의 환경을 구성하여 서버를 구축한다. (일반적인 예가 dev, staing, production 으로 서버를 각각 구축하여 운영하는 것이다.) 따라서 Terraform 으로 서버 환경을 구축하기 위해서는 이 부분에 대한 고려가 필요한데, 다양한 방법이 있지만 그 중 하나가 Terraform CLI 에서 제공하는 workspace다. workspace란 단어 그대로 구축하고자 하는 서버 환경에 따라 workspace 를 나누어서 각 서버의 상태를 관리하겠다는 뜻이다. 즉 3개의 서버 환경이 구성되어 있고 3개의 workspace 를 만들어서 각각 infrastructure 를 구성하였다면, 총 3개의 상태파일(.tfstate)이 각각 생성되어 관리가 될 것이다. 예제와 함께 사용법에 대해 더 쉽게 알아보자. 예제 코드 먼저 workspace 테스트를 위해 사용할 코드

Module publishing 내가 만든 module 을 혼자 사용하는 것도 좋지만 전세계 사람들과 함께 공유하여 사용한다면 어떨까? 잘 만든 module 을 통해 다른 Terraform 개발자들이 Infrastructure 를 구성하도록 도와줄 수 있다면 아주 멋진 일이 될 것이다. 그렇다면 어떻게 다른 개발자들에게 공유할 수 있을까? Terraform 에서는 Terraform registry 에 누구나 쉽게 자신이 만든 module 을 publish 할 수 있게 해준다. Publish 된 module 은 전세계 개발자들이 누구나 쉽게 검색하여 사용이 가능하다. Module publish 요구사항 Module 을 publish 하기 위해서는 몇가지 따라야 할 요구사항이 필요하다. GitHub - 개발한 module 을 public Terraform registry 에 배포

Module 만들기 이전 포스트 에서 module 을 사용하는 방법에 대해 알아보았으니, 이번에는 module 을 직접 만들어 보겠다. 아래 그림처럼 AWS 의 public, private subnet 을 가지는 VPC 를 구성하는 module 을 만들어보자. AWS vpc example 출처는 이고, web server 나 database server 의 구축은 생략하고 VPC 만 mod

Modules Module 이란? Module 은 한개 또는 여러개의 .tf 또는 .tf.json 파일들로 구성되어 있으며, module 에 따라 한개 또는 여러개의 resource 들을 포함한다. module 내의 파일들은 한개의 directory 에 모두 위치한다. module 은 쉽게 생각하면 일종의 library 라고 할 수 있을 것 같다. 여러 기능들을 포함하고 있는 library 를 만들어서 사용하는 곳에서 원하는 기능들을 사용하듯이, 여러 resource 들을 포함하고 있는 module 을 만들어서 원하는 곳에서 원하는 resource 들을 생성하거나, 필요한 정보를 가져올 수도 있다. module 은 크게 두가지로 나눌 수 있다. Root module - Terraform command 를 수행하는 directory 에 있는 파일들로 구성된 module 을 Root module 이라고 한다. **C

Local values Local values 란 모듈내에서 사용할 수 있는 값이다. 간단하므로 예제와 함께 살펴보자. 선언 방법 locals block 을 통해 선언할 수 있으며, block 안에 다양한 type 의 variables 를 선언할 수 있다. 예제에서는 date, common_tags 두개를 선언하였고 각각 string, object type 으로 선언해주었다. 선언 시 다른 local values, resource attributes, varialbes 를 사용하여 선언하는 것도 가능하다. 사용 방법 선언 방법처럼 사용 방법도 굉장히 간단하다. local. 으로 선언한 local value 를 사용할 수 있다. 위의 예제를 살펴보면 awsiamuser.example1, awsiamuser.example2 의 resource 에서 동일한 tag 값을 가지기 위해

Output values Output values 란 모듈에서 제공하는 값이며, 다른 모듈에서 그 값을 다양하게 사용하여 Infrastructure 구성에 도움을 준다. 모듈의 return value 라고 생각하면 쉬울 것 같다. 선언 방법 예제와 함께 선언 방법에 대해 알아보자. Output values 는 보통 outputs.tf 파일을 생성하여 선언하며 (물론 파일 이름은 개발자 자유이다) output block 을 통해 생성할 수 있다. output 의 이름은 다른 것들과 마찬가지로 다른 output 의 이름과 중복 되어서는 안된다. 사용할 수 있는 Arguments 에 대해서 살펴보자. value를 제외한 모든 Arguments 는 optional 이므로 사용하지 않아도 문제는 없다. value - output 으로 사용할 값을 명시해준다. string, number, list 등등 다양한 type

Input variables Input variables 란 모듈에 제공되는 변수이며, 모듈의 source code 의 변경 없이 모듈을 customize 할 수 있도록 해준다. 쉽게 생각해서 일반적인 프로그래밍을 생각한다면 함수에 전달되는 전달 인자라고 보면 될 것 같다. 선언 방법 예제와 함께 선언 방법에 대해 알아보자. 위의 예제처럼 variable block 을 통해 Input variables 를 선언할 수 있고, "iamusername" 처럼 variable 의 이름을 지정 해 줄 수 있다. variables 의 이름은 value 를 할당하거나 다른곳에서 참조를 할때 사용이 되며, 다른 variable 의 이름과 중복이 되어서는 안된다. 각각의 Arguments 에 대해서 알아보자. 모든 Arguments 는 optional 이므로 사용하지 않아도 문제는 없다. default - variable 의

Data sources Data source 는 Terraform 을 사용하지 않고 만든 infrastructure resource 또는 다른 곳에서 사용중인 Terraform code 를 통해 만들어진 resource 의 Data 를 가져오는데 사용된다. 각각의 provider 들은 resource 와 함께 data source 도 제공하고 있다. Data source 문법 예제를 통해 어떻게 사용하는지 알아보자. 코드의 첫번째 라인처럼 data block 을 통해 원하는 type 의 data 를 가져올 수 있다. 예제 코드에서는 username 이 fooname 인 awsiamuser 의 data 를 가져오도록 하였고 foo 라는 이름을 붙혀줬다. 이처럼 data 를 가져오기 위해서는 data block 안에 정보들(Arguments)을 명시해줘야 하는데, 이 Arguments 에 대한 내용은 각각의 Pr

Resource Meta-Arguments 이전 포스트 에서 resource block 안에서 사용할 수 있는 Arguments 란 무엇인지 알아 보았다. 각각의 resource 들은 해당 resource 를 생성하기 위해 각기 다른 Arguments 를 선언할 수 있다. 하지만 이렇게 각기 다른 Arguments 외에 모든 resource 가 공통적으로 사용 할 수 있는 Arguments 가 있는데, 이걸 Meta-Arguments 라고 부른다. 이번 포스트에서는 이 Meta-Arguments 의 종류와 사용법에 대해서 알아보겠다. 1. depends_on depends_on 이란 이름 그대로 특정 resource 에 dependency 를 설정해 줄때 사

Resource Resource 는 Terraform 의 가장 중요한 구성요소 중 하나이다. Resource 를 선언함으로써 virtual networks, compute instance 등 다양한 infrastructure 를 생성할 수 있다. 바로 실습을 하며 어떻게 사용하는지 알아보자! 쉽게 배울 수 있다. Resource 문법 간단한 예제를 통해 resource 문법에 대해 알아보자. 위의 간단한 예제에서 보이듯이 resource 라는 block 을 만들어서 원하는 resource 를 생성할 수 있다. Type, Name "awsiamuser" 라고 선언된 부분은 resource type 에 해당되는 부분으로 예제에서는 AWS 의 IAM User 를 생성하겠다는 뜻이다. 이 resource type 은 어떤 provider 를 사용하냐에 따라 사용할 수 있는 type 들이 달라진다. (각 provider 의

Provider Provider 란 infrastructure 의 type 이라고 생각하면 될 것 같다. 쉬운 예로 AWS, GCP, Azure 가 각각 provider 라고 생각하면 된다. 물론 다른 provider 들도 굉장히 많다. 여기에서 다양한 provider 들을 확인해 볼 수 있다. 이런 provider 들에 대해 더 자세히 알아보고 싶다면, 여기에서 확인할 수 있다. 이 Site는 Terraform registry 라는 곳인데, 여기에 다양한 Provider 와 Module (Library 라고 생각하면 된다. 추후 해당 내용에 대해 포스팅 하겠다.) 이 등록되어 있고, 해당 내용에 대해 확인할 수 있다. 자! 그럼 이제 드디어! Provider 를 사용하는

IaC IaC 란 Infrastructure as Code 를 뜻하는 용어이다. 쉽게 예를 들자면, 우리가 만든 Application 을 돌리기 위한 infrastructure 를 code 를 통해 구축한다라고 생각하면 좋을 것 같다. 더 구체적인 예를 들어 보겠다. 만약 Spring boot app 을 만들었고, 이 app을 AWS의 EC2에서 실행시키기 위해 AWS infrastructure 를 구축해야 한다고 하자. IaC 방식을 사용하지 않는다면, AWS console 에 접속해서 EC2 서비스를 선택하고 Next, Next 를 눌러가며 EC2 인스턴스를 만들고 app 을 실행시켜야 한다. (물론 AWS CLI 를 활용하는 방법도 있다.) 하지만 이 모든 절차를 code 로 구현해 구축하는 것이 바로 IaC 이다. Terraform 자 그럼 이제 Terraform에 대해 알아보자. Terraform 이란 code 를 통해 infrastruc