EMD Blog

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..

가산 IDC와 GCP VPC를 인터커넥트로 연결했으나 대역폭 중첩의 문제로 IDC서버에서 GCP Cloud SQL Server 접속 시 프록시 서버를 거쳐가도록 설정함. 이 경우는 정상적으로 연결되는 것을 확인했으나 GCP에서 IDC에 운영중인 온프레미스 DB에 DB-link가 되는지 확인이 필요 === 시도했으나 아래 두 가지 문제 발생 Cloud SQL Server의 경우 sysadmin 권한 부여가 불가능 서버 링크 불가능 위 문제에 대해서는 문서와 GCP측에서도 확인해줌. 즉, 직접 VM에다가 SQL Server를 설치해 고가용성 설정을 하는 수밖에 없음.

기존에 gcloud compute ssh (IAP)를 사용해 위치에 상관없이 VM에 접속하고 있었으나 어느 순간부터 방화벽을 설정(22번 포트를 수동으로 허용)해야만 접속이 되는 문제 발생. IAP는 내부 IP만 있는 VM에 TCP 터널링을 통해 접속하는 방식이다. 하지만 외부 IP가 연결되어 있으면 TCP 터널링 대신 외부 IP를 사용하기 때문에 접속하고자 하는 IP에 대해 방화벽을 허용해줘야한다. 이 문제를 해결하기 위해 강제로 TCP 터널링을 사용하게하는 -tunnel-through-iap 플래그를 사용하면 외부 IP 존재여부에 상관없이 어디서든 IAP로 서버에 접속 가능해진다.

로드밸런서의 Public IP를 사용해 서버에 접근 시 서버 에러가 발생. 하지만 VM에 직접 연결된 공인 IP로 접근하면 정상적으로 200을 반환. https://cloud.google.com/load-balancing/docs/https/troubleshooting-ext-https-lbs 이 경우는 Health Check 이상으로 인한 문제로 잘못된 Health Check 경로를 수정해 해결.

IDC와 전용선 연결 시 GCP 특정 IP 대역과 겹치는 문제 발생 IDC에서는 172.17.0.0/16 대역을 사용중인데 GCP docker bridge가 172.17.0.0/16을 이미 사용하고 있어 Cloud SQL에 연결할 수가 없는 상황. 이런 상황에서 GCP의 Private Service Connect를 고려해볼 수는 있지만 Cloud SQL은 아직 지원을 안함(2023년부터 지원 예정) 대안으로 SNAT를 사용한 연결 진행중 Interconnect 후 Cloud SQL에 연결하고자 할 경우 아래 승인된 네트워크 설정에 대한 제한사항을 반드시 먼저 확인해함. 왜냐하면 이 문제는 IDC 쪽에서 대역폭만 바꿔주면 아주 쉽게 해결되기 때문. 제한사항은 아래 문서를 통해 확인 가능 https://cl..

로그만 보면 방화벽 문제라고 생각할 수도 있지만 인증 Proxy 연결 동작방식을 봤을때는 방화벽문제로 보기가 힘듬. 실제로 문서에도 방화벽 관련 내용은 없기도 하고 GCP Proxy 대역폭에 대한 방화벽은 이미 허용되어 있는 상태. (SQL 인증 Proxy 서버가 별도의 IP대역을 가지고 있는지는 확인 필요) 알고보니 동작방식에 대한 이해도 부족으로 인한 문제였음. 로컬 PC에서 SQL Server로 다이렉트로 연결하는 방식을 생각했으나 중간에 SQL Server와 같은 네트워크의 서버 하나를 거쳐야 하는 것이였음. 즉, 로컬 → SQL Proxy → SQL Server 가 아니라 로컬 → Proxy(IAP) → SQL Server와 같은 네트워크상의 서버 → SQL Proxy → SQL Server 방..

PDF Server로 사용할 Windows VM관리하기 위해 MIG를 생성했으나 계속 Unhealthy상태가 지속됨. VM은 정상이고 RDP로 접속해도 정상이지만 10분에 한번씩 종료되고 있음. Unhealthy여서 종료되는 것인지 종료돼서 Unhealthy인 것인지는 모르겠음. GCP 문서를 확인하고 리소스 구성과 방화벽을 확인했으나 구성자체에는 문제가 없었음. 이런 경우에는 health check를 위한 VM의 port상에 아무 서비스도 없어서 발생하는 경우임. 예를 들어 health check를 80포트로 하고 있다면 80포트의 WEB Server가 가동중이여야함.

GCP → IAM 및 관리자 → 서비스 계정으로 이동 서비스 계정 만들기 서비스 계정 이름 및 설명 입력 이 서비스 계정에 프로젝트에 대한 액세스 권한 부여에서 역할 선택 클릭 후 현재 사용 중 → 편집자 선택 완료를 클릭해 계정 설정 완료 서비스 계정 목록에서 방금 생성한 서비스 계정의 이메일 클릭 상단 탭에서 '키' 탭으로 이동 키 추가 → 새 키 만들기 → json 선택 키가 자동으로 다운로드 되며 terraform에서는 아래와 같이 사용하면 됨 main.tf terraform { required_providers { google = { source = "hashicorp/google" version = "3.5.0" } } } provider "google" { credentials = file(..

Shared VPC가 구성되어있는 프로젝트(host)의 compute.subnetworks.get 권한이 필요하다고 하면 Shared VPC를 사용하고자 하는 프로젝트(service)에서 사용중인 서비스 계정에 compute.subnetworks.get 권한을 부여한 후 host 프로젝트의 iam에 해당 서비스 계정을 추가해주면 됨. 또한 위와 같이 서비스 계정을 여러 프로젝트에 등록해두면 등록된 프로젝트들을 하나의 서비스 계정으로 인증/접근할 수 있어 편리함. 하지만 꼭 필요한 프로젝트에만 등록하고 최소 권한만 부여해서 사용할 것.

GCP CLI 설치와 설정이 끝난 후 gcloud를 실행시키면 아래와 같은 에러가 발생하는 상황이 생길 수 있음. Unable to connect to the server: error executing access token command "/usr/lib64/google-cloud-sdk/bin/gcloud config config-helper --format=json": err=exit status 1 output= stderr=Traceback (most recent call last): File "/usr/lib64/google-cloud-sdk/lib/gcloud.py", line 104, in main() File "/usr/lib64/google-cloud-sdk/lib/gcloud.py",..