개요로드 밸런서는 운영관리 입장에서 상당히 많은 편의성을 제공한다.그래서 그런지 규모가 작은 프로젝트 즉, "부하 분산"이 필요없는 프로젝트임에도 불구하고 정말 많은 사람들이 로드 밸런서를 활용한다. 그런데 나의 경우, 작은 프로젝트에 LB를 쓰는게 그 기술의 취지에 맞지 않고, 그렇기에 많은 자원이 낭비가 된다는 생각에 쓰기가 싫었다. (뭔가 괜히 패배하는 기분이랄까..?) 여기서부터 지옥 시작이었다.  포트로 분리된 서버에 LB 없이 하나의 서버로 각각의 포트에 SSL을 적용하는 테스크를 진행 (이 가설엔 논점이 굉장히 많은데, 다른 포스팅에서 다뤄보겠다.)했는데, 사실 이건 로드 밸런서로 뚝딱뚝딱 1-2시간이면 할 수 있는 업무다. [사건의 발단🥹] 그런데 위와 같은 이유로 로드밸런서를 사용하기 ..

개요예기치 못한 에러 때문에 개발자가 모르는 사이 서비스가 갑자기 다운될 수도 있다. 이러한 이슈를 방지하기 위해 로그를 모니터링하는 것은 매우 중요한 일이며,  메일, slack, chat 등으로 실시간 알림을 통해 로그를 모니터링할 수 있다.  Cloud Logging  Cloud Logging을 보면 정말 많은 로그들이 실시간으로 쌓이고 있다. 이번 포스팅에서는 Error 관련 로그가 발생했을 때 회사의 DEV 계정으로 메일 알림을 전송하는 것을 세팅해보도록 한다.  Cloud Logging의 가장 우측에 알림 만들기라는 버튼을 클릭하자.원래 이 서비스는 없었고 StackDriver라는 서비스로 지원됐었는데, 새로 생겼다고 한다. 그래서 Cloud Logging 관련 리서치를 하면 여전히 Stack..

개요회사 서버 개편 작업을 위해서 다음과 같은 작업을 수행하였다.Instance Template, Instance Group 생성 (https://cobinding.tistory.com/229)Cloud NAT Gateway 구축 (https://cobinding.tistory.com/244)  [GCP] Cloud Nat Gateway 구축 과정 및 작동 방식요구사항 서버 상황 현재 VM 인스턴스의 외부 ip는 임시 ip로 되어있다. 배포는 수동으로 “인스턴스 바꾸기”를 통해서 새로운 인스턴스 이름과 ip를 부여받는 방식으로 운영하고 있다. 인스턴스cobinding.tistory.com [GCP] Instance Template과 Instance Group을 통한 VM 서버 생성과 블루-그린 배포개요 ..

개요서버 상황배포는 “인스턴스 바꾸기”를 통해서 새로운 인스턴스 이름과 ip를 부여받는 방식으로 운영하고 있다.인스턴스 바꾸기를 통해 인스턴스를 삭제하고 교체하면, 인스턴스의 외부 ip도 인스턴스가 교체될 때마다 달라진다. 문제 상황NICE API 요청을 위해 ip 주소가 바뀔 때마다 화이트리스트에 등록을 해야함VM인스턴스에서 도는 웹사이트는 WebClient를 통해서 NICE 서버와 http 통신을 한다. 이때, VM 인스턴스의 외부 ip가 HTTP 통신 요청 헤더의 host 필드값으로 들어가게 된다. NICE 측에서는 이 요청값을 통해, 화이트리스트에 등록된 IP인지 아닌지 확인을 한다. ➡️ 따라서 IP를 번거롭게 매번 등록해야 한다. 위험성도 높다.인스턴스 바꾸기를 통해 배포가 될 때마다 외부 i..

개요웹사이트 개편 작업 이후 도입된 외부 API는 요청 헤더값에 우리 웹사이트의 vm 인스턴스 정보가 담긴다. 이러한 VM 인스턴스 IP 주소는 유동 IP로 설정되어있어서, IP가 변경될 때마다(배포할 때마다 - 블루∙그린배포) 매번 VM 인스턴스의 IP를 화이트리스트에 업로드해야 한다. 이러한 수동 업데이트 방식은 문제의 소지가 다분하다.  이 문제를 해결하기 위한 개편작업을 담당하였다. 그 과정을 시리즈로 블로그에 정리해보려 한다. 이 포스팅은 그 시작점인 Instance Template의 설정과 MIG이다.  Instance Template Instance Template은 MIG를 통해 서버를 운영하기 위해서 가상머신 생성을 위한 일종의 규칙 사항들을 정리해 놓은 것이다.GCP의 Instance ..

개요Cloud Build 작업을 하면서 트리거 테스트를 위해 계속 커밋을 남겼었다.그런데 공용 Repository에 커밋 및 푸시를 남기지 않고 트리거를 실행하고, 로그를 볼 수 있는 방법을 찾아서 공유한다.GCP는 상대적으로 자료가 많이 없어서 작업이 꽤 힘들다..🥹 GCP를 사용하는 동안 꾸준히 기록해보자!!  Cloud Build 트리거 실행 Cloud Build > 트리거 경로로 들어가서 빌드 테스트를 실행하고 싶은 트리거의 실행 버튼을 누른다.  그럼 위와 같이 트리거를 실행할 트리거 이름과 저장소, 브랜치 입력창이 나온다. 여기서 Cloud Build에 트리거 대상으로 설정해준 브랜치를 입력하고 트리거 실행을 하면된다. 그럼 바로 빌드가 되고 원격 저장소에 commit이 남지 않는다...! ..

개요보통 서버에 SSH 접속 버튼을 눌러 접속하는데chmod 명령어로 ssh 키 관련 작업을 하고 서버에서 나간 이후....계속 아래와 같은 SSH 인증 관련 에러가 발생했다.    로그를 살펴보니까, Invalid ssh key entry 이런 오류가 발생했다.새로 키를 발급 받고 메타데이터에 추가하는 등 발버둥을 쳤지만 해결이 안돼서 다음과 같은 방법을 진행했다.  직렬 콘솔VM 인스턴스에서 직렬 콘솔에 연결을 설정하면 부팅 및 네트워킹 문제를 디버그하고 고장 난 인스턴스의 문제를 해결하는 등 여러 VM 인스턴스 관련 기타 문제 해결 작업을 수행할 수 있다. 실제로 포트를 연결하고 콘솔에 들어가보면 서버 상태와 관련한 로그들이 출력되므로, 문제 해결에 좋은 도구가 될 것같다.   직렬 콘솔을 사용한 ..

개요CI/CD 구축의 핵심 과정인 Google Cloud Build와 Cloud Run을 세팅하는 과정에 대해 알아보자.  1. Google Cloud Build 설정하기Google Cloud Build란?Google Cloud Build는 Google Cloud 인프라에서 빌드를 실행하는, 말 그대로 빌드 서비스다. 사용자가 세팅한 Trigger가 발생하면 Github, Cloud Storage 등등에서 소스 코드를 가져오고, 사양에 맞게 빌드를 실행한다. Docker Container나 Java Archive와 같은 도구를 통해 Artifact(빌드 결과물)를 빌드하도록 설정할 수 있다.  Cloud Build 동작 과정 1. Cloud Build의 빌드 트리거에 사용자가 설정한 코드 변경이 감지된다..

개요Google Artifact Registry 구축기에 Google Cloud SDK 설치 및 세팅 관련 과정을 첨부해서 글을 작성했었는데 이를 따로 빼는 게 맞다고 판단하였다. GAR에만 쓰는 게 아니고 또 GAR 관련 포스팅 해야할 내용이 추가되었기 때문에.. 😆  1. Google Cloud SDK란?쉽게 말해서 Google Cloud 관련 툴을 다루기 위한 명령툴이다. 주의할 점필자는 서버 상에서 AR(Artifact Registry)에 접속해야 하므로 VM 인스턴스 서버에 설치를 했다.필요 하에 서버 자체에 설치를 할 수도 있지만 일반적인 경우라면 로컬에 설치하고, 편리하게 로컬 환경에서 접속할 수 있는 도구다.   2-1. Google Cloud SDK 패키지 경로 추가VM 인스턴스에 Go..

개요GCP 환경에서 CI/CD를 구축하기 위해 도커 컨테이너 이미지가 저장될 저장소가 필요하다.처음에는 Docker Hub를 통해 이 저장소를 구축할 생각이었으나, private/public 저장 공간을 생각 못 했다.Docker Hub의 private version을 이용하려면 요금을 지불..해야한다..! 그런데 어차피 유료라면 Google의 Artifact Registry라는 저장소를 사용하는 게 낫다고 판단했다.Google Cloud에 종속성이 높지만, 보안적인 측면에서 더 강한 장점이 있는 Google Artifact Registry를 사용하기 위해 해당 문서를 작성한다. Artifact RegistryArtifact Registry란?컨테이너 이미지(docker)나 언어 패키지(Maven, np..