EMD Blog

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를 따로 관리하는 게 편해보..

현재 상황은 아래와 같음. ============================================================ - 현재 구축되어 있는 GCP의 네트워크(shared VPC 사용 중)와 IDC 센터는 인터커넥트로 연결되어 있음. - GCP 내에는 Cloud SQL이 비공개 IP로 구성되어 있으며, IDC에서 이 Cloud SQL로 접근해야하는 상황. - 하지만 IDC의 IP 대역은 172.17.0.0/16이기 때문에 GCP 비공개 서비스에 직접적으로 접근 불가.(GCP의 172.17.0.0/16 대역은 Docker 브리지로 예약) - 때문에 Proxy VM을 구축해서 IDC -> Proxy VM -> Cloud SQL 형태를 만드려고 함. - 여기서 Proxy VM은 MIG+자동복..

gcloud compute instance-groups managed rolling-action stop-proactive-update study-managed-instance-group \\ --zone=asia-northeast3-a gcloud compute instance-groups managed rolling-action stop-proactive-update 명령어가 MIG내 최대 인수턴스 개수에 어떤 영향을 미치는 지 궁금함. 그래서 GCP 케이스에 아래와 같은 내용으로 등록하였음. ==============[케이스 질문]================ 스테이트풀 구성 중 궁금한 점이 있어 문의드립니다. 처음에 아래와 같이 스테이트리스 인스턴스 그룹과 오토스케일링을 설정했습니다. ======..

Cloud 모니터링의 알림 채널을 Pub/Sub으로 설정해 알림 메세지를 게시하면 Cloud Functions에서 메세지 내용 확인 시 데이터가 암호화되어 있는 것을 볼 수 있다. 모니터링 알림 스키마 구조 https://cloud.google.com/monitoring/support/notification-options#pubsub 위 문서에서 중간쯤 보면 스키마 구조와 설명이 적혀있다. 하지만 메세지를 출력해보면 아래와 같이 나온다. (검은색으로 칠해진 부분은 base64 데이터이다.) 즉, 아래구조로 출력된다. ( Message ID와 Publish Time은 Pub/Sub에서 생성) { data : string, messageId: string, message_id : string, publish..

Cloud Function을 HTTP 트리거로 생성함. 구독의 서비스 계정에는 해당 함수에 대한 호출자 역할을 부여하였으며 인증을 위해 서비스 계정 토큰 생성자 역할을 부여하였음. Cloud Function은 외부 호출을 허용 해놓은 상태. Publish하면 구독이 메세지를 받아오긴 하나 Push가 되지 않음. Cloud Logging으로 쿼리해보았지만 나오는 로그도 없음. 일단 문서 추가로 확인해보고 케이스에 등록할 예정. 도저히 모르겠음. 해당 내용 케이스로 등록함. ================== 케이스 등록 내용 ================= Cloud Function을 HTTP 트리거로 배포해 Pub/Sub으로 호출하려 합니다. 현재 아래처럼 구성하였습니다. Cloud Function - H..

GCP Cloud Function을 Pub/Sub 트리거를 통해 구성할 시 자동으로 구독이 생성되고 gcf-{cloud function name}-{region}-{topic} ID를 갖게 됨. 이는 기존 조직의 네이밍 룰을 따르고 있지 않아 관리가 불편해짐. Pub/Sub 트리거 구성 시 구독 ID를 직접 지정할 수 있는지 확인해 보았으나 관련 문서를 찾지 못했음. 그래서 GCP에 케이스를 남겨 아래와 같은 답변을 받음, ========================= 해당 이슈에 대하여 재현 해본결과 subscription 은 cloud functions 에 의해 자동으로 생성되며 안타깝게도 이 구독은 Cloud Functions에서 관리하므로 변경이 불가한것으로 확인 되었습니다. 말씀 하신대로 구독 ..

GCP에서 Cloud Monitoring의 Uptime Check를 설정할 때 방화벽에서 Uptime Check IP를 허용해주어야 한다. 하지만 문서상에서 이 Uptime Check가 분기마다 변경될 수도 있다라는 식의 설명이 작성되어 있는 것을 볼 수 있는데, 아래 처럼 적혀있다. =========== 문제의 문서 https://cloud.google.com/monitoring/uptime-checks/using-uptime-checks#get-ips 위 문서를 보면 “업타임 체크에 사용되는 IP 주소는 변경될 수 있지만, 일반적으로 분기별로 두 번 이상 변경할 수 없으며, 별도의 공지가 있어야 합니다.” 라는 문구가 있다. =========== 말이 애매모호 하지만 일단은 Uptime Check I..