EMD Blog

Terraform Cloud에서 VCS 연결 시 팀별 액세스 권한 설정이 안되는 이슈가 있음. 테스트 내용은 아래와 같음. team 내 member 역할이 부여된 상태로 Terraform Cloud와 VCS 연동 → 내 repository만 액세스 가능 team 내 maintainer 역할이 부여된 상태로 Terraform Cloud와 VCS 연동 → 내 repository만 액세스 가능 organizations 내 소유자 원한이 부여된 상태로 Terraform Cloud와 VCS 연동 → 내 repository만 액세스 가능 알고 보니 OAuth 연동 시 조직 repository 액세스 권한을 체크 해줘야했음. 만약 조직의 소유자라면 그냥 체크만 하고 넘어가면 되지만 조직 member라면 소유자에게 액..

Github Actions에서 Terraform output 출력 시 이상한 값이 출력됨. output 값이 출력되는 것이 아니라 run에 해당되는 프로세스가 출력됨. [예상한 값] 192.168.1.129 [실제 출력 값] /home/runner/work/_temp/067af7a4-257b-4fd1-87b4-26517e149c8d/terraform-bin -chdir=infra output -raw database_ip 192.168.1.129::debug::Terraform exited with code 0. ::debug::stdout: 192.168.1.129 ::debug::stderr: ::debug::exitcode: 0 ::set-output name=stdout::192.168.1.129..

문서 상에는 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 ..