EMD Blog

문서 상에는 GCS Backend가 Lock을 지원한다고 되어 있는데 AWS 처럼 별다른 설정 방법이 나와있지는 않음.몇가지 글을 확인해보니 같은 bucket내에 lock파일이 저장되는 방식인 듯 함. 테스트 해봐야겠음. lock을 걸어보니 state 파일과 같은 경로에 .tflock 파일이 생성되는 것을 확인 할 수 있었음.

tfe Provider는 Terraform Cloud를 생성하기 위한 코드이기 때문에 backend 관리에 보통 s3+DynamoDB를 활용한다. 하지만 단순하게 내용 공유 목적으로 코드를 공유 할 경우 state파일을 그냥 전달 하는 경우가 있는데 이 때 state 파일을 인식함에도 불구하고 모든 리소스를 새로 create 하려는 plan을 볼 수 있다. https://stackoverflow.com/questions/67204811/terraform-failed-to-install-provider-doesnt-match-checksums-from-dependency-l https://www.terraform.io/language/files/dependency-lock#dependency-lock-fi..

tfe_variable Resource를 사용해서 Terraform Workspace의 변수를 관리 할 수 있음. 하지만 이 variable Resource의 value로는 String만 지정이 가능함. 만약에 Map, List 등을 지정 할 경우 아래 에러가 발생 tfe_variable Inappropriate value for attribute "value": string required. 관련 이슈는 아래에서 확인 가능하며 해결방법도 나와있음.(jsonencode ) https://github.com/hashicorp/terraform-provider-tfe/issues/188 tfe_variable: list(string) not supported · Issue #188 · hashicorp/te..

Terraform Cloud는 조직 내에서 팀을 관리 할 수가 있는데 이 Team의 경우 유료 기능이기 때문에 무료 버전은 “owners” 팀 만을 관리 할 수 있다. 하지만 tfe_team Resource를 사용해서 owners 팀을 관리하려 하면 아래와 같은 에러가 발생한다. Error creating team owners for organization demo-vntg-organization: missing entitlements to create teams 생성 권한이 없다는 에러로 보이는데, 실제로 plan에 보면 team을 생성하긴 한다. 문제는 이 팀은 이미 존재하고 있는 상태지만 refresh로 state파일에 반영 할 수는 없기 때문에(Terraform으로 생성한 것이 아니므로) 무조건 ..

tfe provider를 사용해서 Organization을 구성 할 때 OAuth Client도 함께 구성 할 수 있다. 아래 Resource 참고 https://registry.terraform.io/providers/hashicorp/tfe/latest/docs/resources/oauth_client 위 리소스를 사용하면 이미 연결된 VCS Provider에 대해서 oauth_client_id 값을 받아 올 수 있다. 문제는 이 리소스의 경우 id를 받아오는 용도로 밖에 사용 할 수 없다는 것인데, 결국에는 Organization을 먼저 생성하고 수동으로 VCS 연결 후 다시 Terraform 코드를 Apply해줘야 한다. 이러면 굳이 저 리소스를 안쓰고 Client ID를 따로 관리하는 게 편해보..

SQL Server 사용시 Instance Type을 custom type으로 설정해야 한다. 아래 문서를 참고해서 custom type을 지정해주면 된다. https://cloud.google.com/sql/docs/mysql/instance-settings db-custom-- vCPU의 경우 1또는 2~96 사이의 짝수여야 한다. 메모리의 경우 256의 배수여야 하며 최소 3,840MB 이다. 만약에 vCPU가 1이고 메모리가 3,840MB라면 custom type은 db-custom-1-3840이 된다.

Terraform state에 관해서 꼭 알아야 할 부분들 정리해보았음. Terraform은 현재 구성에 대한 정보를 tfstate 파일에 저장한다. tfstate 파일에는 생성한 리소스와의 바인딩 정보가 저장되어 있기 때문에 인프라를 변경 할 경우 이 tfstate 파일을 참고해 리소스를 생성 할 지, 삭제 할지 등을 판단하게 된다. Terraform의 동작 방식은 아래와 같다. (apply 시) terraform refresh 후 계획 생성(plan) 계획에 맞게 리소스 생성 (apply) terraform refresh terraform refresh는 현재 tfstate의 바인딩 정보와 실제 생성된 리소스를 비교 후 tfstate 파일에 반영하는 작업이다. 중요한 것은 tfstate에 기록된 바인..

Terraform Workspace에 대한 내용 중 읽고 넘어가면 좋을 부분들 정리 Terraform을 로컬머신에서 실행할 경우 Terraform은 인프라 관련 구성들을 로컬에서 관리하게 된다. 하지만 Terraform Cloud를 사용하면 Workspace에서 모든 인프라 관련 구성들을 관리하게 된다. Terraform Cloud의 Workspace를 사용하느냐 Terraform 로컬 디렉토리를 사용하느냐에 따라서 데이터 관리 방식이 달라지는데 그 차이는 아래와 같다. 요소 Local Terraform Terraform Cloud 테라폼 구성 로컬 디스크 VCS 또는 API/CLi를 통해 주기적 업로드 변수 값 .tfvars 파일, CLI 인수, Shell 환경 Workspace > Variavles ..

개요 Terraform CLI를 사용해서 Terraform Cloud Workspace에 로컬 코드를 plan하거나 apply 할 수 있다. 이 방식은 Terraform CLI를 기존에 사용했다면 굉장히 쉽게 적용할 수 있는 workflow이며, 기존의 CI/CD 파이프라인이 존재하더라도 같이 사용할 수 있고 Sentinel 정책도 준수할 수 있다. 이 방식이 장점은 로컬의 있는 코드를 Terraform Cloud에서 실행할 수 있다는 점인데, Terraform Cloud의 환경(운영환경)을 그대로 사용해 테스트(plan만 사용) 할 수 있기 때문에 로컬 환경과 운영 환경 사이의 간극을 없애주는 역할을 하게 된다. 여기서 Terraform Cloud 직접 실행하는 명령어는 아래처럼 두 가지가 존재한다. ..

Terraform Cloud의 Workflow 3가지를 정리하려 한다. 이 내용들은 Terraform Cloud 문서화가 되어있긴 하지만 영어로 되어있기도 하고 번역이 매끄럽지가 않기 떄문에 이렇게 정리해두면 누군가에게는 도움이 될 수 있지 않을까 해서 정리해본다. UI/VCS-driven Runs UI/VCS-driven Runs Workflow는 Terraform Cloud를 사용할 경우 기본적으로 채택하게 되는 workflow이다. 이 workflow에서는 모든 workspace가 VCS(Github 같은)의 특정 분기와 연결된다. 작동 방식은 아래와 같다. Terraform에서 workspace를 생성할 때 VCS 선택한다. (Webhook) 해당 VCS에서 새 커밋에 대한 병합이 발생하면 Ter..