GCP는 자원이 User 기반이 아니라 프로젝트 기반이며 조직(Organiztion) 이라는 구성을 가지고 있습니다.
리소스 계층 구조 정의
Google Cloud 리소스는 계층적으로 구성됩니다. 이러한 계층 구조를 통해 기업의 오퍼레이션 구조를 Google Cloud에 매핑하고 관련 리소스 그룹에 대한 액세스 제어 및 권한을 관리할 수 있습니다. 다음 다이어그램은 계층 구조의 예시를 보여줍니다.
조직은 계층 구조의 최상위 요소이며 상위 요소가 없습니다.
계층 구조의 최상위 노드는 조직(예: 회사)을 나타내는 조직 리소스입니다. 조직 리소스는 계층 구조 하위에 있는 모든 리소스를 중앙에서 제어할 수 있게 해줍니다.
다음 계층 구조에는 폴더가 있습니다. 폴더를 사용하면 상위 조직의 여러 부서 및 팀에 대한 요구사항을 격리할 수 있습니다. 마찬가지로 폴더를 사용하여 프로덕션 리소스를 개발 리소스로부터 분리할 수 있습니다.
계층 구조 맨 아래에는 프로젝트가 있습니다. 프로젝트에는 앱을 구성하는 컴퓨팅, 스토리지, 네트워킹 리소스가 포함됩니다.
아래 다이어그램은 완벽한 형태의 Google Cloud 리소스 계층 구조의 대표적인 예시입니다.
조직 노드 만들기
Google Cloud에서 지원되는 기능의 상당수에는 조직 노드가 필요합니다. Cloud ID를 이용하면 example.com 같은 기업 인터넷 도메인에 매핑되는 조직 노드를 만들 수 있습니다. 기존 Google Cloud 프로젝트와 결제 계정을 조직 노드로 마이그레이션할 수 있습니다.
프로젝트 구조 지정
Google Cloud를 사용하려면 프로젝트가 필요합니다. Compute Engine 가상 머신 및 Cloud Storage 버킷과 같은 모든 Google Cloud 리소스는 단일 프로젝트에 속합니다.
일반적으로 환경마다 애플리케이션당 하나의 프로젝트가 있는 것이 좋습니다.
Google ID 관리
Google Cloud는 인증 및 액세스 관리에 Google 계정을 사용합니다. 개발자 및 기타 기술 담당자는 Google 계정이 있어야 Google Cloud에 액세스할 수 있습니다. Cloud ID를 통해 회사 도메인 이름에 연결된 완전 관리형 Google 계정을 사용하는 방법을 권장합니다. 이렇게 하면 개발자는 회사 이메일 ID를 사용하여 Google Cloud에 액세스할 수 있으며 관리자는 관리 콘솔을 통해 계정을 보고 제어할 수 있습니다. 이 문서의 이어지는 섹션에서는 기존 ID 플랫폼을 Cloud ID와 통합하는 방법을 설명합니다.
Cloud ID는 독립형 서비스로서의 ID(IDaaS) 솔루션입니다. 이 솔루션을 통해 Cloud Platform 고객은 Google Cloud의 다양한 직장 생산성 앱 모음인 Google Workspace가 제공하는 다양한 ID 관리 기능에 액세스할 수 있습니다 Cloud ID에는 Google Workspace 라이선스가 필요 없습니다. Cloud ID에 가입하면 회사 도메인 이름과 연결된 Google 계정을 통해 관리 계층이 제공됩니다. 이 관리 계층을 통해 Google Cloud를 포함한 Google 서비스에 대한 액세스를 사용 설정하거나 사용 중지할 수 있습니다. 또한 Cloud ID에 가입하면 도메인에 대한 조직 노드가 생성되며, 이는 회사 구조와 통제를 리소스 계층 구조를 통해 Google Cloud 리소스에 매핑하는 데 도움이 됩니다.
GCP 리소스는 단순하게 프로젝트 단독으로도 사용 가능하지만 기업환경에 적합하게 설계되어 필요한 경우 기업의 조직구조와 동일하게 계층적으로 구성하는 것이 가능합니다. 이러한 계층 구조를 통해 기업의 운영 구조를 GCP에 매핑 가능하며 관련 리소스 그룹에 대한 액세스 제어 및 권한을 체계적으로 관리할 수 있습니다. 필요한 경우 기업의 조직구조와 동일하게 계층적으로 구성하는 것이 가능합니다.
✔ Cloud Identity 를 활용해서 조직 구성
IAM 및 관리자 -> ID 및 조직을 클릭한 후 아래 화면이 나타나면 "체크리스트로 이동"을 클릭합니다.
[설정 시작하기] 버튼을 클릭합니다.
Google Cloud를 사용하려면 Google ID 서비스(Cloud ID 또는 Workspace )를 사용하여 Google Cloud 리소스의 사용자에 대한 사용자 인증 정보를 관리해야 합니다. Cloud ID 및 Workspace 모두 사용자 인증 정보를 제공하여 다른 사용자가 내 클라우드 리소스에 액세스할 수 있습니다. Workspace는 Gmail, Google Drive, 기타 서비스와 같은 추가 소비자 서비스를 제공합니다.
이미 Google 외의 ID 공급업체를 사용하고 있더라도 Cloud ID 또는 Workspace를 사용하는 Google ID 계정이 필요합니다. 현재 ID 공급업체를 Google ID 계정과 연계하면 직원들이 기존 사용자 인증 정보로 Google Cloud에 액세스할 수 있습니다.
Workspace는 Cloud ID보다 많은 기능을 제공하기 때문에 라이선스당 비용도 더 높습니다. 이러한 이유로 비용이 더 많이 드는 Workspace 기능에 액세스할 필요가 없는 사용자에 한해 Cloud ID를 선별적으로 사용할 수도 있습니다.
Google ID 서비스를 설정한 후 이를 사용해 도메인을 확인합니다. 도메인을 확인하면 Google Cloud 리소스 계층 구조의 루트 노드가 될 조직 리소스가 자동으로 생성됩니다.
이 태스크를 수행할 수 있는 사용자
ID 관리자는 조직 내 개인 또는 그룹에게 역할 기반 액세스를 할당합니다. 개인은 Cloud ID 또는 Workspace의 최고 관리자여야 합니다.
도메인 관리자: DNS 구성과 같은 도메인 설정을 보고 수정할 수 있는 회사의 도메인 호스트에 대한 액세스 권한을 보유합니다.
이 태스크에서 수행하는 작업
도메인과 연결된 Google ID 서비스가 있어야 Google Cloud 조직의 인증을 관리할 수 있습니다.
Google ID 서비스와 도메인을 연결합니다. 그러면 Google Cloud 리소스 계층 구조의 루트 노드가 될 조직 리소스가 생성됩니다.
조직 리소스가 정상적으로 생성되었는지 확인합니다.
이 태스크가 권장되는 이유
Google Cloud 설정 체크리스트를 사용하려면 도메인에 연결된 Google ID 서비스 및 프로젝트를 저장할 조직 리소스가 있어야 합니다. 리소스 계층 구조를 구성하고 팀의 계정 ID와 액세스 제어를 중앙에서 관리하려면 기본적으로 필요한 사항입니다.
[CLOUD ID 가입] 버튼을 클릭합니다.
Google ID 관리
Google Cloud는 인증 및 액세스 관리에 Google 계정을 사용합니다. 개발자 및 기타 기술 담당자는 Google 계정이 있어야 Google Cloud에 액세스할 수 있습니다.
Google ID는 사용자 라이프사이클 관리, 디렉터리 서비스, 계정 보안, 싱글 사인온(SSO), 기기 관리 등을 하나의 간편한 통합 솔루션으로 제공합니다
아래 내용은 도메인을 발급한 사이트에서 수행해야 합니다. 본 문서에서는 https://내도메인.한국/ 사이트에서 정보를 수정했습니다.
도메인이 정상적으로 확인되면 아래와 같은 화면이 출력됩니다.
GCP 콘솔에서 "리소스 관리" 메뉴를 클릭하면 아래와 같이 최상위 조직이 생성된 것을 확인할 수 있습니다.
#4) 폴더 구조 추가하기
좀 더 효율적인 조직 관리를 위해서는 폴더를 만들어서 관리할 수 있으며 보다 다양하고 유연한 접근 제어 기능을 활용할 수 있습니다. 폴더 자원은 프로젝트 간의 추가 그룹화 메커니즘 및 격리 경계를 제공하며 조직 내 하위 조직으로 볼 수 있습니다. 폴더를 사용하여 회사 내의 여러 법인, 부서 및 팀을 모델링 할 수 있습니다.
“폴더 만들기” 를 클릭하면 하단과 같이 조직 밑으로 폴더를 만들 수 있습니다. 내역을 입력 또는 선택한 후 [만들기] 버튼을 클릭합니다.
Google Cloud ID 및 액세스 관리 – IAM을 통해 관리자는 누가 어떤 리소스에 대해 어떤 조치를 취할 수 있는지 승인할 수 있습니다. IAM은 규정 준수 프로세스를 용이하게 하는 기본 제공 감사를 통해 전체 조직의 보안 정책에 대한 통합 보기를 제공합니다.
IAM Components
IAM manages access control by defining who (identity) has what access (role) for which resource
Member
구성원은 Google 계정(최종 사용자용), 서비스 계정(앱 및 가상 머신용), Google 그룹 또는 리소스에 액세스할 수 있는 Google Workspace 또는 Cloud ID 도메인일 수 있습니다. 회원의 ID는 사용자, 서비스 계정 또는 Google 그룹과 연결된 이메일 주소입니다. 또는 Google Workspace 또는 Cloud ID 도메인과 연결된 도메인 이름입니다.
Role
리소스에 대한 액세스 권한이 최종 사용자에게 직접 부여되지 않습니다. 역할은 권한 모음이며 인증된 구성원에게 부여됩니다. 권한은 예를 들어 service.resource.verb 형식으로 표시됩니다. compute.instances.list 권한은 리소스에 허용되는 작업을 결정합니다. 구성원에게 부여된 역할은 역할에 포함된 모든 권한을 부여합니다. GCP는 다양한 역할 유형을 지원합니다.
Basic or Primitive roles
Roles historically available in the Google Cloud Console. Also, referred to as primitive roles
Roles are Owner, Editor, and Viewer.
Provide board level of permissions and not recommended
Predefined roles
Roles that give fine-grained granular access control
Roles are created and maintained by Google and automatically updated as necessary, such as when Google Cloud adds new features or services.
Custom roles
Roles created to tailor permissions to the needs of the organization, when predefined roles don’t meet the needs.
Custom roles are not maintained by Google; when new permissions, features, or services are added to Google Cloud, the custom roles will not be updated automatically.
IAM Policy
IAM 정책은 하나 이상의 구성원을 역할에 바인딩합니다. IAM 정책은 어떤 역할이 어떤 구성원에게 부여되는지 정의하고 적용하며 이 정책은 리소스에 연결됩니다. 리소스에 연결된 IAM 정책은 리소스에 대한 액세스 유형(역할)이 있는 사람(구성원)을 정의합니다. IAM 정책은 리소스 계층 구조의 모든 수준(조직 수준, 폴더 수준, 프로젝트 수준 또는 리소스 수준)에서 설정할 수 있습니다. IAM 정책 상속은 전이적이며 리소스는 모든 상위 리소스의 정책을 상속합니다. 리소스에 대한 효과적인 정책은 해당 리소스에 설정된 정책과 계층의 상위에서 상속된 정책의 통합입니다. 기본적으로 권한 -> 역할 -> (IAM 정책) -> 구성원 인증된 구성원이 리소스에 액세스를 시도하면 IAM은 리소스의 정책을 확인하여 작업이 허용되는지 여부를 결정합니다.
Service Accounts
A service account is a special kind of account used by an application or a virtual machine (VM) instance, not a person.
Applications use service accounts to make authorized API calls, authorized as either the service account itself, or as Google Workspace or Cloud Identity users through domain-wide delegation.
is identified by its email address, which is unique to the account.
does not have passwords, and cannot log in via browsers or cookies.
are associated with private/public RSA key-pairs that are used for authentication to Google.
Other users or service accounts cannot impersonate a service account.
are not members of the Google Workspace domain, unlike user accounts.
Cloud NAT 서비스를 사용하면 외부 IP 주소가 포함되지 않은 Google Cloud VM 인스턴스를 인터넷에 연결할 수 있습니다.
Cloud NAT를 사용하면 Compute Engine 인스턴스 및 Kubernetes Engine 컨테이너 pod가 공유 공개 IP 주소를 사용하여 인터넷과 통신할 수 있습니다. Cloud NAT는 인터넷에 연결하는 가상 라우터인 Cloud Router에 NAT 게이트웨이를 사용하여 서브넷을 연결합니다.
아키텍처
Cloud NAT는 소프트웨어로 정의되는 분산형 및 관리형 서비스입니다. 프록시 VM 또는 어플라이언스를 기반으로 하지 않습니다. Cloud NAT는 Virtual Private Cloud(VPC) 네트워크를 지원하는 Andromeda 소프트웨어를 구성하여 외부 IP 주소가 없는 VM에 소스 네트워크 주소 변환(소스 NAT 또는SNAT)이 제공되도록 합니다. Cloud NAT는 또한 설정된 인바운드 응답 패킷에만 대상 네트워크 주소 변환(대상 NAT 또는 DNAT)을 제공합니다.
각 Cloud NAT 게이트웨이는 단일 VPC 네트워크, 리전, Cloud Router와 연결됩니다. Cloud NAT 게이트웨이 및 Cloud Router는 제어 영역을 제공합니다. 이는 데이터 영역에 포함되지 않으므로 패킷이 Cloud NAT 게이트웨이 또는 Cloud Router를 통과하지 않습니다.
2. Cloud SDK에는 Python이 필요합니다. 지원되는 버전은 Python 3(권장, 3.5~3.8) 및 Python 2(2.7.9 이상)입니다. 기본적으로 Windows 버전의 Cloud SDK는 Python 3 및 Python 2와 함께 제공됩니다. Cloud SDK를 사용하려면 운영체제에서 지원되는 Python 버전을 실행할 수 있어야 합니다.
3. 설치가 완료되면 설치 프로그램에서 시작 메뉴 및 바탕화면 바로가기를 만들고, Google Cloud CLI 쉘을 시작하고, gcloud CLI를 구성할 수 있는 옵션이 제공됩니다.
[Finish] 버튼을 클릭하면 터미널 창을 시작하고 gcloud init 명령어를 실행합니다.
위의 화면에서 "Y" 를 입력하면 gcloud CLI로 인증 화면이 나타나고 GCP 계정으로 login 하면 "gcloud CLI로 인증되었습니다" 라는 메시지가 브라우저에 출력됩니다. 명령창에는 GCP 로그인 정보가 출력되고 project를 선택하라는 메시지가 나타납니다. 자신의 프로젝트를 선택합니다.
이어서 default Region과 Zone을 선택합니다.
설치가 완료되면 아래 gcloud --version 명령어로 명령어가 잘 수행되는지 확인합니다.
이 튜토리얼에서는 웹 애플리케이션을 Docker 컨테이너 이미지에 패키징하고 Google Kubernetes Engine(GKE) 클러스터에서 이 컨테이너 이미지를 실행하는 방법을 설명합니다. 그러면 사용자는 사용자 니즈에 따라 확장 가능한 부하 분산된 복제본 세트로서 웹 애플리케이션을 배포하게 됩니다.
목표
샘플 웹 애플리케이션을 Docker 이미지로 패키징합니다.
Artifact Registry에 Docker 이미지 업로드
GKE 클러스터 만들기
샘플 앱을 클러스터에 배포
배포의 자동 확장 관리
샘플 앱을 인터넷에 노출
샘플 앱의 새 버전을 배포합니다.
시작하기 전에
다음 단계에 따라 Kubernetes Engine API를 사용을 설정합니다.
좌측 메뉴의 "API 및 서비스" - "사용 설정된 API 및 서비스" 메뉴를 클릭합니다.
우측에 화면이 나타나면 "API 서비스 사용 설정"을 클릭합니다.
검색창에 "Artifact Registry" 입력합니다. 검색 결과인 Artifact Registry API를 클릭한 후 "사용"을 클릭합니다.
검색창에 "Kubernetes Engine API"를 입력합니다. 검색 결과인 Kubernetes Engine API를 클릭한 후 "사용"을 클릭합니다.
Google Cloud Console의 프로젝트 선택기 페이지에서 Google Cloud 프로젝트를 선택하거나 만듭니다.
Artifact Registry and Google Kubernetes Engine API를 사용 설정합니다.
이 명령어는 현재 디렉터리에서 Dockerfile을 사용하여 이미지를 빌드하고, 로컬 환경에 저장하고, asia-northeast3-docker.pkg.dev/my-project/hello-repo/hello-app:v1과 같은 이름으로 태그를 지정하도록 Docker에 지시합니다. 다음 섹션에서 이미지가 Artifact Registry로 푸시됩니다.
PROJECT_ID 변수는 컨테이너 이미지를 Google Cloud 프로젝트의 hello-repo 저장소와 연결합니다.
asia-northeast3-docker.pkg.dev 프리픽스는 저장소의 리전 호스트인 Artifact Registry 를 나타냅니다.
docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
asia-northeast3-docker.pkg.dev/pjt-aicallbot-prd/hello-repo/hello-app v1 8b9a9caee254 24 minutes ago 11.5MB
<none> <none> a66d4b996c65 24 minutes ago 263MB
alpine latest e9adb5357e84 6 days ago 5.57MB
golang 1.8-alpine 4cb86d3661bf 4 years ago 257MB
로컬에서 컨테이너 실행
로컬 PC Docker 엔진을 사용하여 컨테이너 이미지를 테스트합니다. REGION은 각자가 생성하고자 하는 REGION을 지정합니다. 본 문서에서는 asia-northeast3 로 지정했습니다.
docker run --rm -p 8080:8080 REGION-docker.pkg.dev/${PROJECT_ID}/hello-repo/hello-app:v1
브라우저에 http://localhost:8080 을 입력하면 아래와 같은 화면이 나타납니다.
[참고사항]
아래와 같이 오류가 발생하면
C:\Program Files (x86)\Google\Cloud SDK\git_dir\hello-app>docker run --rm -p 8080:8080 asia-northeast3-docker.pkg.dev/pjt-aicallbot-prd/hello-repo/hello-app:v1
Unable to find image 'asia-northeast3-docker.pkg.dev/pjt-aicallbot-prd/hello-repo/hello-app:v1' locally
docker: Error response from daemon: Head "https://asia-northeast3-docker.pkg.dev/v2/pjt-aicallbot-prd/hello-repo/hello-app/manifests/v1":
denied: Permission "artifactregistry.repositories.downloadArtifacts" denied on resource "projects/pjt-aicallbot-prd/locations/asia-northeast3/repositories/hello-repo" (or it may not exist).
See 'docker run --help'.
gcloud auth configure-docker REGION-docker.pkg.dev 를 수행합니다. REGION은 각자의 REGION 정보에 맞도록 변경합니다. 본 문서에서는 asia-northeast3 를 지정합니다.
hello-app> gcloud auth configure-docker asia-northeast3-docker.pkg.dev
Adding credentials for: asia-northeast3-docker.pkg.dev
After update, the following will be written to your Docker config file located at [C:\Users\LGCNS\.docker\config.json]:
{
"credHelpers": {
"asia-northeast3-docker.pkg.dev": "gcloud"
}
}
Do you want to continue (Y/n)? Y
Docker configuration file updated.
Cloud Shell을 사용할 경우 웹 미리보기 버튼
을 클릭한 후 "8080 포트에서 미리보기" 메뉴를 선택합니다.
브라우저 창이 열리고 아래와 같은 내용이 브라우저에 표시됩니다.
또는 새로운 터미널 창(Cloud Shell 탭)을 열고 다음 명령어를 실행하여 'Hello, World!'로 요청에 응답하는지 확인합니다.
curl http://localhost:8080
성공적인 응답을 확인하면 docker run 명령어가 실행 중인 탭에서 Ctrl+C 키를 눌러 컨테이너를 종료합니다.
Artifact Registry에 Docker 이미지 푸시
GKE 클러스터에서 컨테이너 이미지를 다운로드하고 실행할 수 있도록 컨테이너 이미지를 레지스트리에 업로드해야 합니다. 이 튜토리얼에서는 Artifact Registry에 컨테이너를 저장합니다.
Artifact Registry에 인증하도록 Docker 명령줄 도구를 구성합니다. REGION은 각자의 리전으로 변경합니다.
Cloud Console에서 Google Kubernetes Engine 페이지로 이동합니다
만들기를 클릭합니다.
표준이나 Autopilot 모드를 선택하고 구성을 클릭합니다.
이름 필드에 hello-cluster 이름을 입력합니다.
영역 또는 리전을 선택합니다. 표준 클러스터: 위치 유형에서 영역을 선택한 후 영역 드롭다운 목록에서 Compute Engine 영역(예: us-west1-a)을 선택합니다. Autopilot 클러스터: 리전 드롭다운 목록에서 Compute Engine 리전(예: us-west1)을 선택합니다.
만들기를 클릭합니다. 그러면 GKE 클러스터가 생성됩니다.
클러스터가 생성될 때까지 기다립니다. 클러스터가 준비되면 클러스터 이름 옆에 녹색 체크표시가 나타납니다.
GKE에 샘플 앱 배포
이제 Docker 이미지를 GKE 클러스터에 배포할 준비가 되었습니다.
Kubernetes는 하나 이상의 컨테이너를 포함하는 확장 가능한 단위인 포드로 나타냅니다. Pod는 Kubernetes에서 배포 가능한 최소 단위입니다. 일반적으로 Pod를 클러스터 전체에 걸쳐 함께 확장하고 배포할 수 있는 복제본 집합으로 배포합니다. 복제본 세트를 배포하는 한 가지 방법은 Kubernetes 배포를 사용하는 것입니다.
이 섹션에서는 클러스터에서 hello-app이 실행되도록 Kubernetes 배포를 만듭니다. 이 배포에는 복제본(포드)이 있습니다. 배포 포드 하나에는 컨테이너 하나(hello-app Docker 이미지)만 포함됩니다. 또한 CPU 부하를 기준으로 포드 수를 3개부터 1~5개까지 확장하는 HorizontalPodAutoscaler 리소스를 만듭니다.
1. GKE 클러스터에 연결되어 있는지 확인합니다. COMPTE_ZONE 은 클러스터가 생성된 ZONE을 입력합니다.
gcloud container clusters get-credentials hello-cluster --zone COMPUTE_ZONE
## 아래 메시지가 출력됩니다.
Fetching cluster endpoint and auth data.
kubeconfig entry generated for hello-cluster.
2. hello-app Docker 이미지의 Kubernetes 배포를 만듭니다. REGION과 PROJECT_ID는 각자의 환경에 맞게 수정합니다.
포드에는 개별적으로 할당된 IP 주소가 있지만 클러스터 내에서만 이 IP에 연결할 수 있습니다. 또한 GKE 포드는 확장 요구에 따라 시작 또는 중지할 수 있도록 설계되었습니다. 또한 오류로 인해 포드가 다운되면 GKE는 해당 포드를 자동으로 다시 배포하여 매번 새 포드 IP 주소를 할당합니다.
즉, 모든 배포에서 활성 포드 집합에 해당하는 IP 주소 집합은 동적입니다.
1) 포드를 하나의 정적 호스트 이름으로 그룹화하고
2) 클러스터 포드 그룹을 클러스터 외부 인터넷에 노출하는 방법이 필요합니다.
Kubernetes 서비스는 이 두 가지 문제를 해결합니다. 서비스 그룹 포드는 클러스터 내의 모든 포드에서 연결할 수 있는 하나의 고정 IP 주소로 그룹화됩니다. 또한 GKE는 고정 IP에 DNS 호스트 이름을 할당합니다. 예를 들면 hello-app.default.svc.cluster.local 입니다.
GKE의 기본 서비스 유형을 ClusterIP라고 하며, 여기서 서비스는 클러스터 내부에서만 연결할 수 있는 IP 주소를 가져옵니다. 클러스터 외부에서 Kubernetes 서비스를 노출하려면 LoadBalancer 유형의 서비스를 만듭니다. 이 유형의 서비스는 인터넷을 통해 연결할 수 있는 포드 모음에 외부 부하 분산기 IP를 생성합니다.
이 섹션에서는 LoadBalancer 유형의 서비스를 사용하여 hello-app 배포를 인터넷에 노출합니다.
1. kubectl expose 명령어를 사용하여 hello-app 배포를 위한 Kubernetes 서비스를 생성합니다.
여기에서 --port 플래그는 부하 분산기에 구성된 포트 번호를 지정하고 --target-port 플래그는 hello-app 컨테이너가 리슨하는 포트 번호를 지정합니다.
hello-app pod가 Kubernetes 서비스를 통해 인터넷에 노출됩니다.
2. 다음 명령어를 실행하여 hello-app-service의 서비스 세부정보를 가져옵니다.
kubectl get service
## 출력
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
hello-app-service LoadBalancer 10.100.1.94 34.64.112.20 80:31390/TCP 4h22m
kubernetes ClusterIP 10.100.0.1 <none> 443/TCP 8h
hello-app-service의 EXTERNAL_IP 주소를 클립보드에 복사합니다(예: 203.0.113.0).
새 브라우저를 열고 클립보드에 복사한 서비스 IP 주소를 붙여 넣습니다. Hello, World! 메시지가 Hostname 필드와 함께 표시됩니다. Hostname은 브라우저에 HTTP 요청을 제공하는 hello-app 포드 세 개 중 하나입니다.
샘플 앱의 새 버전 배포
이 섹션에서는 새 Docker 이미지를 빌드하고 GKE 클러스터에 배포하여 hello-app을 새 버전으로 업그레이드합니다.
GKE의 순차적 업데이트 기능을 사용하면 다운타임 없이 업데이트를 할 수 있습니다. 순차적 업데이트 중에 GKE 클러스터는 기존 hello-app 포드를 새 버전의 Docker 이미지가 포함된 포드로 점진적으로 대체합니다. 업데이트하는 동안 부하 분산기 서비스가 트래픽을 이용 가능한 포드로만 라우팅합니다.
1. hello 앱 소스 코드와 Dockerfile을 클론한 Cloud Shell로 돌아갑니다. main.go 파일의 hello() 함수를 업데이트하여 새 버전 2.0.0을 보고하세요.
새 hello-app Docker 이미지를 빌드하고 태그를 지정합니다. REGION과 PROJECT_ID는 각자의 환경에 맞게 수정합니다.
denied: Permission "artifactregistry.repositories.downloadArtifacts" denied on resource "projects/pjt-aicallbot-prd/locations/asia-northeast3/repositories/hello-repo" (or it may not exist)
브라우저에 표시되는 구글 로그인 계정을 선택한 후 화면에 표시되는 코드를 복사하여 아래 화면의 verificatioin code 에 붙여넣습니다.
gcloud init
gcloud init
Welcome! This command will take you through the configuration of gcloud.
Your current configuration has been set to: [default]
You can skip diagnostics next time by using the following flag:
gcloud init --skip-diagnostics
Network diagnostic detects and fixes local network connection issues.
Checking network connection...done.
Reachability Check passed.
Network diagnostic passed (1/1 checks passed).
You must log in to continue. Would you like to log in (Y/n)? Y
Go to the following link in your browser:
https://accounts.google.com/o/oauth2/auth?response_type=code&client_id=32555940559.apps.googleusercontent.com&redirect_uri=urn%3Aietf%3Awg%3Aoauth%3A2.0%3Aoob&scope=openid+https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fuserinfo.email+https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fcloud-platform+https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fappengine.admin+https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fcompute+https%3A%2F%2Fwww.googleapis.com%2Fauth%2Faccounts.reauth&state=uwzdA5YrAHOZN7QJWAOqdRo43Cs9V6&prompt=consent&access_type=offline&code_challenge=o2gsdC9wfhzUZXZ4tJy_tg8iMEk7r11gtd_ZPycsI2U&code_challenge_method=S256
Enter verification code:
사용할 프로젝트를 선택하고, default zone 선택합니다.
본 문서에서는 my-default-project 프로젝트와 [50] asia-northeast3-a zone을 선택했습니다.
gcloud 명령어로 GCP 프로젝트를 조회해 봅니다.
$ gcloud config list project
[core]
project = my-default-project
