programmer.cwchoiit

테라폼에서 Provisioner가 어떤것이고 EC2 Userdata는 무엇이며 둘 간의 차이는 무엇인지 알아보자. Provisioner 테라폼에서 공식적으로 지원하는 문법이다. 세 가지 종류가 있는데 다음과 같다. file: 로컬 -> 리모트 파일복사 local-exec: 로컬PC에서 명령어 수행 remote-exec: 리모트 머신에서 명령어 수행 (SSH, WinRM 과 같은 프로토콜을 지원) 그래서 위 세가지 경우를 처리하기 위해 테라폼에서 provisioner라는 녀석을 제공해준다고 생각하면 된다. 이 녀석은 기본적으로는 첫 리소스 생성 시점에 수행되지만 여러 옵션들을 통해 삭제 시점이라던가 매번 수행할 수 있도록 커스터마이징 할 수도 있다. EC2 Userdata 우선 Userdata는 무엇이냐?..

terraform_remote_state는 어떤것이고 어떻게 활용하는지 알아보자. terraform_remote_state 이 terraform_remote_state는 Data Source로써 사용이 가능하다. hasicorp에서 공식적으로 지원하는 Terraform 이라는 Provider를 사용하면 이를 구현할 수 있다. The terraform_remote_state Data Source | Terraform | HashiCorp Developer Retrieves the root module output values from a Terraform state snapshot stored in a remote backend. developer.hashicorp.com 예전에는 Terraform Reg..

저번 시간에는 Terraform Registry에 있는 모듈을 가져다가 사용하는 것 까지는 해봤다. 이번에는 내가 스스로 모듈을 만들어서 그 모듈을 사용해보자. Directory path 우선, 나의 모듈을 가지고 사용하는 테라폼 소스 코드의 구조는 다음과 같다. account 라는 폴더가 하나의 모듈로서 기능을 할 것이고 그 모듈을 루트 디렉토리에 있는 main.tf 에서 사용할 것이다. 그럼 account 디렉토리에 각각의 파일을 하나씩 알아보자. 참고로 파일명은 정해져 있는게 아니라 관습적으로 사용되는 명칭이다. 그니까 꼭 저것을 따르지 않아도 되지만 관습이니 안 따라야할 이유도 없다. versions.tf 이 파일은 테라폼과 프로바이더의 버전을 명시한 파일이다. 소스 코드는 다음과 같다. terr..

저번 포스팅에서 잠시 다루어보았던 Terraform Cloud를 좀 더 이해해보는 포스팅이다. 우선 기존에 만들었던 Organizations의 Workspace로 가보자. Workspace > Settings > General에 가보면 다음과 같은 설정 부분이 있다. 저번엔 이 부분을 우선 Local로 하고 추후에 더 자세히 알아보기로 했었는데 이 부분에 대해 얘기할 시간이다. Execution Mode: Local Terraform 명령 수행을 Local에서 실행하겠다는 의미이다. 즉, 작업자 PC에서 실행하겠다는 의미가 된다. Terraform Cloud는 State 저장 역할만 수행하게 된다. Execution Mode: Remote Remote로 설정하게 되면 Terraform Cloud 인프라에..

Workspace 테라폼에서 Workspace는 프로젝트 단위라고도 생각할 수 있고 상태 관리의 단위라고도 생각할 수 있다. 예를 들어 환경이 세 가지인(Dev, Staging, Prod) 경우 비슷한 환경에서 살짝 살짝 달라질텐데 이 코드를 복붙해서 세 개의 프로젝트 단위로 관리하기는 비효율적이며 공간 낭비이다. 이럴 때 워크스페이스가 유용하게 사용될 수 있다. 이게 가능한 이유는 하나의 테라폼 프로젝트에 여러 Workspace가 만들어질 수 있기 때문이다. 현재 프로젝트 트리는 다음과 같다. 아직 Init 조차 하지 않은 상태이다. 다음 main.tf 파일을 보자. provider "aws" { region = "ap-northeast-2" } variable "vpc_name" { descripti..

Terraform 에서는 taint와 untaint라는 명령어가 있다. 이 명령어가 무엇인지 알아보고 어떻게 사용하는지 알아보자. taint taint는 Terraform에서 리소스를 관리하는 중 특정 리소스에 문제가 생겼을 때 해당 리소스에 문제가 생겼다는 것을 Terraform에게 알리는 명령어이다. 그럼 Terraform은 이 리소스에 문제가 생겼다는것을 알고 교체하려한다. 현재 나의 Workspace에서 관리하는 State는 다음과 같다. 이 중에서 Internet Gateway에 어떤 문제가 발생했다고 가정해보자. 그래서 해당 리소스에 taint를 하려고 한다. tf taint "module.vpc.aws_internet_gateway.this[0]" 이렇게 한 후 Apply를 해보면 taint..

State 이번엔 상태 관리에 대한 내용이다. Terraform을 이용해서 어떤 작업을 하면 현재 작업한 상태에 대한 파일이 기록되는 것을 terraform.state 파일을 통해 알았다. 이 파일을 보면 지금 이 Terraform이 관리하고 있는 상태를 보여준다. 굉장히 중요한 파일이다. 이 파일을 기점으로 Apply를 했을 때 변경점을 캐치하거나, 관리하고 있는 리소스를 파악하거나 할 수 있고 Destroy 명령어를 했을 때 무엇을 삭제할지 파악할 수 있기 때문이다. terraform.state { "version": 4, "terraform_version": "1.7.4", "serial": 3, "lineage": "6c566e9f-a596-337a-6760-5e67c5348e36", "outpu..

이번엔 루프를 이용해보자. 다음 main.tf 파일을 보자. provider "aws" { region = "ap-northeast-2" } resource "aws_iam_group" "developer" { name = "developer" } resource "aws_iam_group" "employee" { name = "employee" } output "groups" { value = [ aws_iam_group.developer, aws_iam_group.employee ] } variable "users" { type = list(any) } resource "aws_iam_user" "this" { for_each = { for user in var.users : user.name => ..

HCL은 조건문도 사용할 수 있다. Variables와 Condition을 조합해서 한번 조건문을 다뤄보자. Basic 다음 main.tf 코드를 보자. provider "aws" { region = "ap-northeast-2" } variable "is_john" { type = bool default = true } locals { message = var.is_john ? "Hello John" : "Oh, Your are not John." } output "message" { value = local.message } 변수로 is_john이라는 녀석을 선언한다. 이 녀석은 boolean 타입의 변수고 기본값이 true이다. 이 때 로컬 변수 message는 is_john의 값에 따라 값이 달라..

이번에는 HCL의 for-each문을 활용해서 여러개의 리소스를 만들어보자. count 우선, for-each를 사용하기 전 count를 먼저 사용해보자. 이 count는 HCL에서 예전부터 있던 기능인데 이 기능에 대한 문제점을 보완하고자 for-each가 나왔다고 생각하면 된다. 우선 코드를 바로 보자. # --------- # count provider "aws" { region = "ap-northeast-2" } resource "aws_iam_user" "count" { count = 5 name = "count-user-${count.index}" } output "count_user_arns" { value = aws_iam_user.count.*.arn } 이 코드에서 "count = 5..