일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |
- kubernetes
- CentOS
- Uptime Check
- github
- ECR
- pub/sub
- direnv
- cloud
- snat
- IAM
- Python
- pro
- vm
- MIG
- devops
- AWS
- interconnect
- IAP
- k8s
- terraform
- vpc peering
- gcp
- VAGRANT
- Java
- cloud function
- 우테캠
- cicd
- docker
- Clean Code
- Terraform Cloud
- Today
- Total
목록MIG (7)
EMD Blog
현재 상황은 아래와 같음. ============================================================ - 현재 구축되어 있는 GCP의 네트워크(shared VPC 사용 중)와 IDC 센터는 인터커넥트로 연결되어 있음. - GCP 내에는 Cloud SQL이 비공개 IP로 구성되어 있으며, IDC에서 이 Cloud SQL로 접근해야하는 상황. - 하지만 IDC의 IP 대역은 172.17.0.0/16이기 때문에 GCP 비공개 서비스에 직접적으로 접근 불가.(GCP의 172.17.0.0/16 대역은 Docker 브리지로 예약) - 때문에 Proxy VM을 구축해서 IDC -> Proxy VM -> Cloud SQL 형태를 만드려고 함. - 여기서 Proxy VM은 MIG+자동복..
gcloud compute instance-groups managed rolling-action stop-proactive-update study-managed-instance-group \\ --zone=asia-northeast3-a gcloud compute instance-groups managed rolling-action stop-proactive-update 명령어가 MIG내 최대 인수턴스 개수에 어떤 영향을 미치는 지 궁금함. 그래서 GCP 케이스에 아래와 같은 내용으로 등록하였음. ==============[케이스 질문]================ 스테이트풀 구성 중 궁금한 점이 있어 문의드립니다. 처음에 아래와 같이 스테이트리스 인스턴스 그룹과 오토스케일링을 설정했습니다. ======..
PDF Server로 사용할 Windows VM관리하기 위해 MIG를 생성했으나 계속 Unhealthy상태가 지속됨. VM은 정상이고 RDP로 접속해도 정상이지만 10분에 한번씩 종료되고 있음. Unhealthy여서 종료되는 것인지 종료돼서 Unhealthy인 것인지는 모르겠음. GCP 문서를 확인하고 리소스 구성과 방화벽을 확인했으나 구성자체에는 문제가 없었음. 이런 경우에는 health check를 위한 VM의 port상에 아무 서비스도 없어서 발생하는 경우임. 예를 들어 health check를 80포트로 하고 있다면 80포트의 WEB Server가 가동중이여야함.
이번 포스팅에서는 스테이트풀 구성 중 메타데이터와 IP에 대한 부분을 진행해보자. 구성은 이전 포스팅 내용에 해당하는 리소스가 존재한다고 가정하고 진행하겠다. 메타데이터 메타데이터(Metadata)에 제대로 설명한 적은 없는 것 같다. 인터넷에 메타데이터로 검색하면 데이터에 대한 데이터라고 설명이 나온다. 메타데이터에 익숙하지 않은 사람이라면 저 말이 잘 와닿지 않을 수도 있는데, 휴대폰 사진을 생각하면 쉽게 이해할 수 있다. 스마트폰 일반 카메라로 아무사진이나 찍고 사진첩에 들어가서 보자. 안드로이드는 어떻게 나올지 모르겠는데 아이폰이라면 사진 상단에 언제 어디서 찍었는지 표시가 될 것이다. 이런 정보들이 메타데이터이다. 예시라서 그냥 간단하게 사진에 대한 위치, 시간 정도로만 예시를 들었는데 메타데이..
이전 포스팅에서는 스테이트풀 구성 중 디스크를 스테이트풀로 구성하는 방법에 대해 알아 보았다. 하지만 이전 글에서 윈도우로 새 스테이트풀 MIG를 구성한다는 것을 기존 스테이트리스 MIG(Linux)를 수정하는 방식으로 진행하는 바람에 리눅스로 진행해버리고 말았고, 원래 진행 하고 싶었던 것은 스테이트리스 MIG(Linux) + 스테이트풀 MIG(Windows) 구성이였기 때문에 이참에 IaC의 장점도 짚고 갈겸 리소스들을 정리하고 가보도록 하자. 잠깐 다른 얘기를 하면, 나 같은 경우 글 작성이 굉장히 느린 편이기 때문에 글을 작성하면서 생성해 놓은 리소스들로 인해 과금이 될 우려가 있다. 그래서 매일 글을 작성하고 나서는 리소스를 전부 지워버리고 글을 이어서 작성할 때 포스팅에 적어둔 CLI를 그대로..
이전 게시글에서 스테이트리스를 구성했으니 이제 스테이트풀 구성을 해보도록 하자. 실수로 윈도우 인스턴스로 구성한다는 것을 리눅스 인스턴스로 구성해버리는 바람에 다음 포스팅에서 리소스를 다시 정리했습니다. 2022.02.16 잘못 된 내용 확인 후 수정 하였습니다. 스테이트풀 MIG 스테이트풀은 간단하게 말하면 인스턴스가 재생성되더라도 상태가 유지되도록 하는 MIG 구성이다. 상태가 유지되는 대신 오토스케일링을 지원하지 않기 때문에 일괄 작업이나 데이터 베이스, 모놀리식 어플리케이션 등에 주로 사용된다. 참고로 MIG라면 재생성이나 자동 복구 시 이름은 유지되니 이름을 고정하고 싶은 경우라면 스테이트풀로 구성할 필요가 없으며, IP를 고정하고 싶은 경우에도 고정 IP를 따로 설정할 수 있기 때문에 스테이트..
이전 포스팅에서 인스턴스를 만들어 봤으니 이제 MIG를 구성해보자. 관리형 인스턴스 그룹(Manged Instance Group) 제목에 있는 MIG는 Managed Instance Group의 약자로 관리형 인스턴스 그룹을 말한다. GCP에서 인스턴스 그룹은 비관리형 인스턴스 그룹과 관리형 인스턴스 그룹으로 나뉘는데, 비관리형 인스턴스 그룹은 인스턴스를 묶은 것이다. 딱히 무슨 기능이 제공되는 것은 아니고 그냥 논리적으로 묶은 것 뿐이다. 이렇게 묶은 인스턴스 그룹은 로드밸런서를 연결할 수 있게 된다. 그럼 관리형 인스턴스 그룹은 뭐가 다를까? 관리형 인스턴스 그룹은 오토스케일링을 제공해주고 장애 복구 기능을 지원한다. 이 외에도 다양한 zone에 VM을 생성해 가용성을 높히거나 다양한 배포 옵션을 제..