일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |
- devops
- gcp
- Java
- cloud
- terraform
- vm
- github
- snat
- IAM
- Terraform Cloud
- AWS
- k8s
- ECR
- pro
- IAP
- VAGRANT
- cloud function
- pub/sub
- 우테캠
- CentOS
- kubernetes
- Clean Code
- direnv
- Uptime Check
- docker
- vpc peering
- Python
- cicd
- MIG
- interconnect
- Today
- Total
목록Public Cloud/GCP (35)
EMD Blog
로드밸런서의 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",..
GCP Interconnect 부분에서 개선이 필요해 내용 정리해봄. 개요 온프레미스 네트워크와 VPC 네트워크 간 물리적인 연결(중간에 Partner사를 낄 수도 있다). 내부 IP로 온프레미스와 GCP 네트워크 간 통신이 가능해짐. 일반적인 GCP 리소스 뿐만 아니라 외부 IP가 없는 비공개 GCP 리소스(예를 들어 Cloud SQL)에도 접근이 가능하다. 두 네트워크 간 통신이 필요하다면 VPN을 생각 할 수 있지만 대규모 트래픽을 고려하고 있다면 Interconnect를 선택하는 것이 좋다. VPN은 암호화 후 공개 인터넷을 거쳐 트래픽이 전달되기 때문에 아무래도 느릴 수 밖에 없다. Interconnect 연결 GCP Interconnect 연결 방식은 두 가지가 존재한다. Dedicated I..
내용 정리 할 것까지는 아닌거 같아서 링크만 남겨둠 GCP 감사로그 데이터 액세스 감사로그 구성 감사구성 리소스 Terraform GCP 감사로그 모듈
GCP의 KMS 사용 시 알아두면 좋을 내용들 정리 해보았음. 계층 구조 먼저 KMS 사용전 GCP KMS 리소스의 계층 구조에 대해 알고 있어야 함. GCP KMS의 계층 구조는 organization > folder > project> keyring > key로 구성 되어 있으며, 어느 수준에서 역할을 부여하느냐에 따라 사용 가능한 key 범위가 달라진다. 예를 들면 organization 계층에서 역할을 부여하면 organization내의 모든 key를 사용 할 수 있는 것이고 keyring 계층에서 역할을 부여하면 keyring 내 key만을 사용 할 수 있는 것이다. Key Key는 대칭 암호화, 비대칭 서명, 비대칭 암호화, MAC 서명 용도로 사용 되며 리소스 계층 구조에 따라 하나의 키 링..