Polpid's Pensieve

VPC network

기본적으로 독립적인 private network 이다.

서로 다른 network 간에 internal IP 로 통신을 하기 위해서는 VPC peering 또는 VPN 설정이 필요하다.

Instance 간 External IP 를 통한 연결

다른 VPC  network, 다른 region, 다른 zone 일 경우에도 External IP 를 통한 연결은 가능하다. 

Instance 에 대한 access는 오직 ICMP firewall rule 에 의해서 컨트롤 되기 때문이다. (0.0.0.0/0)

Instance 간 Internal IP 를 통한 연결

기본적으로 동일한 VPC Network상에 존재하지 않으면 불가능 하다.

단, 동일한 VPC Network 에 속한 instance 들은 zone, region다르더라도 internal IP 을 통한 연결이 가능하다.

위 그림을 보자.

Internal IP 접속 여부

위 표를 보면 동일 VPC  Network 가 아닌 instance 는 Internal IP 로 ping 이나가질 않는다. 

그래서 위 구성에서는 vm-appliance라는 instance 를 하나 더 만들었다. 이 instance 를 생성할때에 network interface 에 mynetwork, managementnet, privatent을 등록해주면 vm-appliance 에서 서로 다른 Network  에 있는 Instance  와 통신이 가능하게 된다. 

참고자료

https://google.qwiklabs.com/focuses/1230?parent=catalog

Network Load Balancer 는 같은 region의 vm 들의 트래픽을 분배해준다.

다시 말해 동일한 Network Load Balancer 를 사용하는 vm 들은 동일한 region에 존재한다.

다음과 같은 방법으로 Network Load Balancer 를 생성할 수 있다.

1. target pool 생성

target pool 은 forwarding rule 에 정의된 traffic을 받을수 있는 instance group 이다.

gcloud compute target-pools create nginx-pool

2. instance group 생성

gcloud compute instance-groups managed create nginx-group \
         --base-instance-name nginx \
         --size 2 \
         --template nginx-template \
         --target-pool nginx-pool

template 에 정의된 nginx-template 은 미리 만들어야 한다. 

3. forwarding rule  생성

gcloud compute forwarding-rules create nginx-lb \
         --region us-central1 \
         --ports=80 \
         --target-pool nginx-pool

다른글

2019/07/31 - [Development/GoogleCloud] - [GCP]Http Load Balancer

참고자료

https://google.qwiklabs.com/focuses/558?parent=catalog&qlcampaign=1c-ccace-12

https://cloud.google.com/load-balancing/docs/network/

 먼저 Dockerfile 이 있다고 가정한다. 

내가 만든 이미지는 spring boot 어플리케이션이다.

Dockerfile

이제 이 Dockerfile 을 빌드를 한다.

sudo docker build -t asia.gcr.io/[GOOGLE_PROJECT_ID]/mail-service:v1 .

docker build : 컨테이너를 만드는 명령어

-t : 이미지에 태그 정하는 옵션

asia.gcr.io/[GOOGLE_PROJECT_ID]/mail-service:v1 : 후에 구글 컨테이너 레지스트리에 올리기 위한 이름 규칙이다.

[HOST_NAME]/[GOOGE_PROJECT_ID]/[IMAGE_NAME]

# 참고 (출처 : https://cloud.google.com/container-registry/docs/pushing-and-pulling)

• gcr.io hosts the images in the United States, but the location may change in the future
• us.gcr.io hosts the image in the United States, in a separate storage bucket from images hosted by gcr.io
• eu.gcr.io hosts the images in the European Union
• asia.gcr.io hosts the images in Asia

이미지가 생성되면 위와 같이 볼수 있다. PROJECT_ID 는 일부러 [GOOGLE_PROJECT_ID] 라고 변경했다.

이제 이미지를 PUSH 해보자

안된다...

뭔가 인증작업이 필요하다.

저기 표시된 url  로 일단 들어가보자. https://cloud.google.com/container-registry/docs/advanced-authentication

거기 가이드 대로 따라해보면 다음과 같은 과정을 거치게 된다.

그런데 위에 내용이 뭔가 좀 이상하다. 

config 파일에 내용이 들어가긴 했는데 다음과 같은 문구가 눈에 거슬린다.

'docker-credential-gcloud' 가 PATH에 없어서 Docker credential helper 를 설정했지만 정상적으로 동작 안할꺼다.. 라는 내용이다. 뭐지???

이렇게 했더니 다시 에러가 난다. 이번에는 Cloud SDK 가 뭔가 없다고 한다. 

그래서 아래 URL 로 이동해서 Cloud SDK 를 설치했다.

https://cloud.google.com/sdk/docs/downloads-apt-get

거기에 있는 명령어들을 쭉 실행 한다음 마지막에 gcloud init 까지 한다.

gcloud components install docker-credential-gcr

이제서야 Error 없이 뭔가 OK 라고 나온다.

이제 다시 이미지는 컨테이너 레지스트리에 push를 해보자.

이렇게 내 계정의 Container Registry 를 확인해보면 정상적으로 업로드가 됐다.

올해 초부터 시작했던 Google Cloud Study 가 어느덧 3번째 과정이 끝났다. 

2018/05/15 - [Development/Tech&Seminar] - Google Cloud Study Jams 후기

맨 처음에는 Qwiklabs 을 통해서 공부를 했었다. 그리고 두번 째 Advanced 과정에서는 Coursera 에 있는 GCP 과정을 수강을 했다. 

Qwiklabs 이나 Coursera 과정에 분명 실습 과정이 있긴 했지만 실습이 끝난 후에는 기억이 나지 않았다. ^^;;; 그래서 아쉬움이 많이 남긴 했었는데 이번에는 정말 사용해야 할 만한 이유가 생겼다.

바로 3번째 과정이 Cloud Hackathon 이라는 이름으로 프로그램을 직접  GCP 에 올려서 진행을 해야 했기 때문이다. 

우선 처음에 한숨이 나왔다.. 주제는 Bigdata 와 Kubernetes를 이용한 Microservice 구현 이었다. 먼저 선택은 Kubernetes를 이용한 Microservice 를 구현하는것으로 정했지만.. 뭐부터 해야할지 막막했다. 

기간은 총 6주. 충분한 시간이긴 했지만 정말.. 아무것도 할 수가 없었다. 갑자기 회사일은 바뻐지고. 덕분에 체력은 바닥나고. 명절에는 당연히 못하고.

그래도 결론적으로 거의 극적으로 구현까지는 했다. 그래서 지난 10월 6일 모든 팀들이 모여서 만든것을 소개하는 시간이 있었다. 

우리 팀에서 제출 한 것은 간단한 회원 가입을 Microservice 로 나누어서 GCP 의  Kubernetes에 올려서 동작을 확인해보는 것이었다. 만들긴 했지만 완성도가 많이 떨어졌다. 중간중간 exception처리나 message queue도 넣으려고 했는데 못 넣었다. 언제나 그렇지만 시간이 좀더 있었다면이라는 생각을 많이 했다. (그런데.. 시간이 많이 있었으면 좀더 나았을까 라는 질문도 던져봤다. -_-;;;)

다른 팀들 발표도 계속 진행이 되었고 독특한 아이디어로 구현한 모습들이 많았다. 약간 부끄러웠다. ㅠㅠ

기념품으로 후드 짚업과 여행용 짐정리 가방(?) 을 받았다. 

그리고 이런 인증서도 받았다. 좀더 잘 할 걸 이라는 후회가 되었지만 아무튼 좀 뿌듯했다.

그리고 이번 3차 과정 수료로 또 하나 모은 배지. 드디어 3개를 모았다. 

총 4개를 모으면 하나의 모양을 만들어내는 배지이다. 이제 마지막 1개가 남았다. 

그리고 공개된 마지막 4단계 최종 과정. 5번째는 개인별로 직접 지원(?) 이기 때문에 일단 4단계에서 최종 마무리가 된다. 그리고 주어진 미션은 이번달 10월 25일에 열리는 Google Summit 에서 개발자 라운지(?) 라는 곳에서 이번에 발표한 내용을 그곳에서 발표하는 것이다. ㅡ,,ㅡ;;;;; 망했다..

25일에 열리는 Google Summit 은 참석을 하려고 신청은 미리 하긴 했었는데 이런 형태로 참석을 해야 될줄은 몰랐다. 앞으로 남은 기간은 2 주 정도. 지금 만들어놓은 것을 어떻게 해서든지 다듬어야 하는데 과연 그게 가능할 지 모르겠다. 지금껏 했는데 마지막 하나를 포기하자니 정말 아쉽고, 발표를 하자니 눈앞이 깜깜하다. 

이번 Hackathon 과정이 끝나면 뭐가 기다릴지 굉장히 궁금했는데 이런게 있을 줄이야. 한숨 돌릴 수 있을 줄 알았는데 더 바쁘게 생겼다. ㅠㅠ