일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |
- Terraform Cloud
- CentOS
- cloud
- terraform
- ECR
- pro
- k8s
- snat
- MIG
- vm
- github
- Python
- AWS
- Clean Code
- devops
- IAP
- direnv
- interconnect
- cicd
- docker
- Java
- kubernetes
- gcp
- Uptime Check
- 우테캠
- pub/sub
- VAGRANT
- IAM
- vpc peering
- cloud function
- Today
- Total
목록전체 글 (87)
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 방..
/etc/fstab 내 재부팅 시 자동으로 마운트 되도록 설정했으나 정상작동하지 않으며 해당 위치에 똑같이 마운트 시도해도 마운트가 되지 않는 문제가 발생함 GCP의 Ubuntu20.04 환경이며 보조 디스크를 마운트하는 상황 확인해보니 mount option 중 nobootwait이 deprecated 돼서 문제가 발생한 것이였음 UUID= /mnt/disks/sdb ext4 discard,defaults,nobootwait 0 2 에서 UUID= /mnt/disks/sdb ext4 discard,defaults,nofail 0 2 로 변경
PDF Server로 사용할 Windows VM관리하기 위해 MIG를 생성했으나 계속 Unhealthy상태가 지속됨. VM은 정상이고 RDP로 접속해도 정상이지만 10분에 한번씩 종료되고 있음. Unhealthy여서 종료되는 것인지 종료돼서 Unhealthy인 것인지는 모르겠음. GCP 문서를 확인하고 리소스 구성과 방화벽을 확인했으나 구성자체에는 문제가 없었음. 이런 경우에는 health check를 위한 VM의 port상에 아무 서비스도 없어서 발생하는 경우임. 예를 들어 health check를 80포트로 하고 있다면 80포트의 WEB Server가 가동중이여야함.
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이 된다.
MacOS 환경에서 VirtualBox 설치 후 VM 실행 시 kernel driver not installed error가 발생할 수 있음 이 이슈는 MacOS에서 Oracle 앱을 차단해서 발생한 이슈로 시스템 환경설정 → 보안 및 개인 정보 보호로 가서 Oracle App을 허용해주면 됨. 간단한 이슈지만 OS버전이 업데이트 되면서 App허용 표시가 다르게 약간 다르게 표시되어 헷갈릴 수 있으니 주의