서브 도메인을 등록하기 위해서 CNAME과 A 레코드 같은 정보를 DNS 서비스에 등록해야한다.
DNS
인터넷을 구성하고 있는 IP 주소는 IPv4의 경우 192.168.0.1 같이 숫자로 구성된다. 이런 숫자는 아무런 의미도 없기 때문에 외우기 힘들다는 단점이 있다. 따라서 naver.com 같은 문자열로 서버 주소를 표현하게 되었다. 다만 실제 컴퓨터 통신에서는 naver.com이라는 문자열 주소를 192.168.0.1 같은 IPv4 주소로 변환해주는 서비스가 필요하다. 이런 서비스를 DNS 서비스라고 한다.
DNS는 Domain Name System의 약자로 naver.com 같은 문자열 주소를 IP 주소로 해석해주는 네트워크 서비스를 말한다. DNS 서버에는 도메인 주소와 IP 주소의 쌍(Pair)이 저장된다. 예를 들어,
naver.com
192.168.0.1
google.com
172,17.0.1
plusblog.co.kr
10.234.34.12
이런 정보가 DNS 서버에 저장되고 사용자가 웹 브라우저나 프로그램에서 naver.com을 요청하면 이 테이블에서 naver.com을 찾아 192.168.0.1 을 응답해준다. 사용자의 웹 브라우저나 프로그램은 이 IP 주소를 이용해서 통신하게 된다.
결국 위 테이블에서 하나의 행(Row)를 '레코드(Record)'라고 하며, 저장되는 타입에 따라 A Record와 CNAME으로 구분할 수 있다.
A 레코드 (A Record)
A 레코드(A Record)는 DNS에 저장되는 정보의 타입으로 도메인 주소와 서버의 IP 주소가 직접 매핑시키는 방법이다. 위 테이블에 적혀있는 것처럼 첫 번째 컬럼값이 naver.com 같은 도메인 주소고, 두 번째 컬럼 값이 192.168.0.1 같은 IP 주소인 형태를 말한다.
위에서 말했던 것처럼 사용자가 A 레코드에 해당하는 도메인 주소에 대한 해석을 요청하면 DNS 서버는 IP 주소를 리턴해준다.
CNAME
CNAME은 Canonical Name의 약자로 도메인 주소를 또 다른 도메인 주소로 매핑 시키는 형태의 DNS 레코드 타입이다.
naver.com
192.168.0.1
dev.plusblog.co.kr
172.17.0.1
develop.plusblog.co.kr
dev.plusblog.co.kr.
위와 같은 정보가 DNS 서버에 저장되어 있다고하자. 사용자가 dev.plusblog.co.kr 주소를 요청하면 서버는 172.17.0.1 를 응답한다. A 레코드 정보의 해석이다.
만약 develop.plusblog.co.kr을 요청하면 DNS 서버는 dev.plusblog.co.kr을 리턴하고, 사용자는 다시 dev.plusblog.co.kr 정보를 DNS 서버에 요청한다. DNS 서버는 이제 172.17.0.1 을 리턴하고 사용자는 IP 주소를 사용하게 된다.
develop.plusblog.co.kr과 dev.plusblog.co.kr 정보가 매핑되어 있는 행(Row)을 CNAME 타입이라고 한다. 즉, 도메인 주소에 대한 별명(?)을 붙여주는 정보라고 할 수 있다.
A 레코드 vs. CNAME
A 레코드 타입과 CNAME 타입의 장단점은 명확하다.
A 레코드의 장점은 한번의 요청으로 찾아갈 서버의 IP 주소를 한번에 알 수 있다는 점이다. 반면 단점은 IP 주소가 자주 바뀌는 환경에서는 조금 번거로울 수 있다는 점이다. 예를 들어, 172.17.0.2 서버에서 plusblog.co.kr, dev.plusblog.co.kr, travel.plusblog.co.kr 등 여러개의 서브 도메인들을 처리하고 있다고하자. 각 서브 도메인들을 A 레코드로만 매핑시켰다면, 172.17.0.2라는 IP 주소가 172.17.0.3이라는 주소로 변경되었다면 모든 A 레코드를 찾아서 변경해야 한다.
CNAME 레코드의 장점은 IP 주소가 자주 변경되는 환경에서 유연하게 대응할 수 있다는 점이다. 예를 들어, dev.plusblog.co.kr, travel.plusblog.co.kr 도메인 정보를 plusblog.co.kr이라는 주소로 매핑시키는 CNAME 레코드로 저장하고, plusblog.co.kr이라는 주소를 172.17.0.2 라는 IP 주소로 매핑시키는 A 레코드로 저장해 놨다면, 서버의 IP 주소가 바뀌었을 때 plusblog.co.kr의 A 레코드 정보만 변경시키면 된다.
CNAME 레코드의 단점은 실제 IP 주소를 얻을 때까지 여러번 DNS 정보를 요청해야 한다는 점이다. DNS 정보를 해석하는데 여러번 요청이 필요하다는 점은 경우에 따라서 성능저하를 유발할 수 있다.
* 참고 : 레코드 타임
A record : Address Record
CNAME : Canonical Name Record. 도메인 및 서브도메인만 지원. 하위주소(example.com/sub)는 지원하지 않음
NS : Name Server Record
TXT : 도메인 정보를 확인할 때 상요하는 레코드
SRV : 서비스 종류 및 포트를 지정하여 서비스의 위치를 저장하는 레코드
1. A 레코드 도메인 주소를 IP(*IPv4) 주소로 매핑한다. 위에서 우리가 살펴봤던 과정은 youtube.com의 A 레코드를 찾는 과정과 같다. 도메인 주소와 IP 주소가 바로 매핑되기 때문에 비교적 빠르게 IP 주소를 받을 수 있다. 단, IP 주소가 바뀌면 A 레코드에 변경 사항을 적용해줘야 한다.
2. CNAME 레코드 CNAME에서 는 canonical의 약자이다. canonical 자체는 '정식의'라는 의미이다.
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.
Google Cloud Platform 계정이 있어야 합니다. Terraform 0.15.3 이상이 로컬에 설치되어야 합니다.
Google Cloud Shell
이 문서는 Google Cloud Shell 내에서 수행하는 형태로 설명합니다.
✔ Set up GCP
GCP 콘솔에 로그인한 후 다음 리소스를 생성합니다.
1. Project 생성 : 프로젝트를 생성합니다. "리소스 관리"에서 프로젝트를 생성할 수 있습니다.(예시, 프로젝트명 pjt-terraform)
2. Compute Engine API : 프로젝트를 선택하고 Compute Engine의 "VM 인스턴스"메뉴를 클릭합니다. 오른쪽 화면에 Google Compute Engine API "사용" 버튼을 클릭합니다.
3. service account key: Terraform이 GCP 계정에 액세스할 수 있도록 서비스계정과 서비스 계정 키를 만듭니다. 키를 생성할 때 다음 설정을 사용합니다.
생성한 프로젝트를 선택
"IAM 및 관리자" 의 하위 메뉴인 "서비스 계정"을 클릭
서비스 계정 만들기를 클릭
원하는 이름을 지정하고 [만들고 계속하기]를 클릭(예시, terraform-account)
역할선택에서 "편집자" 선택하고 [계속] 버튼 클릭
"서비스 계정 관리자 역할" 텍스트 박스에 GCP 계정 입력(예시, ypjeong@gmail.com)
[완료] 버튼 클릭
서비스 계정을 만든 후 서비스 계정키를 다운로드합니다.
서비스 계정을 클릭(예시, terraform-account@pjt-terraform.iam.gserviceaccount.com)
상단의 "키" tab 선택.
"키 추가" drop-down 메뉴에서 "새 키 만들기" 선택
"키 유형"을 JSON 으로 지정
[만들기]를 클릭하고 키 파일을 저장(예시, pjt-terraform.json)
Warning: 서비스 계정 키 파일은 GCP 프로젝트에 대한 액세스를 제공합니다. 다른 비밀 자격 증명처럼 취급해야 합니다. 특히 소스 제어에 체크인해서는 안 됩니다.
Enable the Google Cloud APIs
Google Cloud 콘솔에서 Terraform용 API를 활성화해야 합니다.
Cloud Resource Manager API
Compute Engine API
Cloud Storage API
다른 조직에서 작업하는 경우 다음 2가지 API도 활성화해야 합니다.
Identity and Access Management (IAM) API
Cloud Billing API
이제 API를 활성화하려면 GCP 서비스에서 '사용 설정된 API 및 서비스'를 클릭합니다.
Write configuration
Terraform에서 인프라스트럭처를 설명하는 데 사용되는 파일셋을 Terraform 구성(Terraform configuration)이라고 합니다. 네트워크를 만들기 위한 첫 번째 구성을 작성합니다.
Terraform 구성을 위한 디렉터리를 만듭니다.
$ mkdir learn-terraform-gcp
디렉토리로 이동합니다.
$ cd learn-terraform-gcp
Terraform은 작업 디렉토리에서 .tf 또는 .tf.json으로 끝나는 모든 파일을 로드합니다.
아래는 terraform 구성에 대한 main.tf 파일을 만듭니다.
$ touch main.tf
텍스트 편집기(vi, vim, nano 등)로 main.tf를 열고 아래 내용을 붙여넣습니다. <NAME>을 다운로드한 서비스 계정 키 파일의 경로로, <PROJECT_ID>를 프로젝트 ID로 교체하고 파일을 저장해야 합니다. region과 zone 내용도 자신의 환경에 맞도록 변경해 줍니다.
Terraform {} 블록에는 Terraform이 인프라를 프로비저닝하는 데 사용할 필수 공급자와 Terraform 설정이 포함되어 있습니다. 각 공급자에 대해 source 속성은 호스트 이름, 네임스페이스 및 공급자 유형을 정의합니다. Terraform은 기본적으로 Terraform 레지스트리에서 공급자를 설치합니다. 이 예제 구성에서 Google 공급자 소스는 Registry.terraform.io/hashicorp/google의 약어인 hashcorp/google로 정의됩니다.
또한 required_providers 블록에서 각 공급자에 대한 버전 제약 조건을 정의할 수 있습니다. 버전 속성은 선택 사항이지만 공급자 버전을 적용하는 데 사용하는 것이 좋습니다. 이것이 없으면 Terraform은 항상 최신 버전의 공급자를 사용하므로 주요 변경 사항이 발생할 수 있습니다.
Providers
provider 블록은 지정된 제공자를 구성합니다(본 문서에서는 google). 공급자는 Terraform이 리소스를 생성하고 관리하는 데 사용하는 플러그인입니다. Terraform 구성에서 여러 공급자 블록을 정의하여 다른 공급자의 리소스를 관리할 수 있습니다.
리소스 블록을 사용하여 인프라의 구성 요소를 정의합니다. 리소스는 서버와 같은 물리적 구성 요소일 수도 있고 Heroku 애플리케이션과 같은 논리적 리소스일 수도 있습니다.
리소스 블록에는 블록 앞에 리소스 유형과 리소스 이름이라는 두 개의 문자열이 있습니다. 이 예에서 리소스 유형은 google_compute_network이고 이름은 vpc_network입니다. 유형의 접두사는 공급자 이름에 매핑됩니다. 예제 구성에서 Terraform은 google 공급자를 통해 google_compute_network 리소스를 관리합니다. 리소스 유형과 리소스 이름은 함께 리소스의 고유 ID를 형성합니다. 예를 들어 네트워크의 ID는 google_compute_network.vpc_network입니다.
리소스 블록에는 리소스를 구성하는 데 사용하는 인수가 포함되어 있습니다. 인수에는 머신 크기, 디스크 이미지 이름 또는 VPC ID와 같은 항목이 포함될 수 있습니다.
Initialize the directory
새 구성을 생성하거나 버전 제어에서 기존 구성을 체크아웃할 때 terraform init를 사용하여 디렉토리를 초기화해야 합니다. 이 단계에서는 구성에 정의된 공급자를 다운로드합니다.
디렉토리를 초기화합니다.
$ terraform init
Terraform은 google 공급자를 다운로드하여 현재 작업 디렉토리의 숨겨진 하위 디렉토리인 .terraform에 설치합니다. Terraform init 명령은 설치된 제공자 버전 Terraform을 출력합니다. 또한 Terraform은 .terraform.lock.hcl이라는 잠금 파일을 생성합니다. 이 파일은 모든 Terraform 실행의 일관성을 보장하는 데 사용되는 정확한 공급자 버전을 지정합니다. 이를 통해 구성에 사용된 공급자를 업그레이드하려는 시기를 제어할 수도 있습니다.
Format and validate the configuration
모든 구성 파일에서 일관된 형식을 사용하는 것이 좋습니다. terraform fmt 명령은 가독성과 일관성을 위해 현재 디렉토리의 구성을 자동으로 업데이트합니다. 구성을 포맷합니다. 수정 사항이 있는 경우 Terraform은 수정한 파일의 이름을 인쇄합니다.
terraform fmt
terraform validate 명령을 사용하여 구성이 구문적으로 유효하고 내부적으로 일관성이 있는지 확인할 수 있습니다. 구성을 확인합니다. 위에 제공된 예시 구성은 유효하므로 Terraform은 성공 메시지를 반환합니다.
terraform validate
Success! The configuration is valid.
IAM 에서 주구성원에 서비스 계정을 추가한다. 또는 서비스계정의 주구성원에 GCP 계정을 추가한다.
terraform apply 명령어를 다시 수행하니 성공적으로 수행됐다.
google_compute_network.vpc_network: Creating...
google_compute_network.vpc_network: Still creating... [10s elapsed]
google_compute_network.vpc_network: Still creating... [20s elapsed]
google_compute_network.vpc_network: Still creating... [30s elapsed]
google_compute_network.vpc_network: Creation complete after 39s [id=projects/pjt-terraform/global/networks/terraform-network]
Terraform은 어떤 인프라 변경을 계획하고 있는지 표시하고 변경하기 전에 승인을 요청합니다.
이 출력은 구성과 일치하는 인프라를 생성하기 위해 Terraform이 수행할 작업을 설명하는 실행 계획을 보여줍니다. 출력 형식은 Git과 같은 도구에서 생성된 diff 형식과 유사합니다. 출력에는 "google_compute_network" "vpc_network" 리소스 옆에 +가 표시됩니다. 이는 Terraform이 이 리소스를 생성함을 의미합니다. 그 아래에는 설정할 속성이 표시됩니다. 표시된 값이 "적용 후 알려짐"인 경우 리소스가 생성될 때까지 값을 알 수 없음을 의미합니다.
이제 Terraform이 일시 중지되고 계속 진행하기 전에 승인을 기다립니다. 계획의 내용이 올바르지 않거나 위험해 보이는 경우 인프라를 변경하지 않고 여기에서 중단하는 것이 안전합니다. 이 경우 계획이 허용 가능한 것 같으므로 확인 프롬프트에서 yes를 입력하여 계속 진행합니다. Terraform이 네트워크를 프로비저닝합니다.
이제 Terraform을 사용하여 인프라를 만들었습니다. GCP 콘솔에 접속하여 프로비저닝한 VPC 네트워크를 확인합니다.
main.tf에 region과 zone을 지정했는데 모든 region에 subnet이 생성되었다. 이게 맞는건지 아닌지 확인 필요. 이렇게 생성되는 게맞음. 그럼 하나의 리전에만 생성하려면? vpc resource 영역에 auto_create_subnetworks = false 옵션 추가
Inspect state
구성을 적용할 때 Terraform은 terraform.tfstate라는 파일에 데이터를 기록했습니다. Terraform은 관리하는 리소스의 ID와 속성을 이 파일에 저장하므로 앞으로 해당 리소스를 업데이트하거나 삭제할 수 있습니다.
Terraform 상태 파일은 Terraform이 관리하는 리소스를 추적할 수 있는 유일한 방법이며 종종 민감한 정보를 포함하므로 상태 파일을 안전하게 저장하고 인프라를 관리해야 하는 신뢰할 수 있는 팀원에게만 배포해야 합니다. 프로덕션 환경에서는 Terraform Cloud 또는 Terraform Enterprise를 사용하여 원격으로 상태를 저장하는 것이 좋습니다. Terraform은 상태를 저장하고 관리하는 데 사용할 수 있는 다른 여러 원격 백엔드도 지원합니다.
Terraform이 이 네트워크를 만들 때 Google 공급자로부터 메타데이터도 수집하여 상태 파일에 기록합니다. 이 컬렉션의 뒷부분에서 이러한 값을 참조하여 다른 리소스 또는 출력을 구성하도록 구성을 수정합니다.
Change Infrastructure
위에서 Terraform을 사용하여 VPC 네트워크 인프라를 생성했습니다. 여기서는 terraform 구성을 수정하고 Terraform 프로젝트에 변경 사항을 적용하는 법을 설명합니다. Terraform 구성을 업데이트하면 Terraform은 원하는 상태에 도달하는 데 필요한 항목만 수정하는 실행 계획을 빌드합니다. 프로덕션에서 Terraform을 사용할 때 버전 제어 시스템을 사용하여 구성 파일을 관리하고 Terraform Cloud 또는 Terraform Enterprise와 같은 원격 백엔드에 상태를 저장하는 것이 좋습니다.
Create a new resource
terraform apply를 실행하여 새 리소스를 생성할 수 있습니다. Google 컴퓨팅 인스턴스 리소스에 대한 구성을 main.tf에 추가합니다.
이름과 머신 유형은 단순한 문자열이지만 boot_disk 및 network_interface는 복잡한 블록입니다. 리소스에 대해 지원되는 모든 인수는 GCP 문서에서 확인할 수 있습니다.
컴퓨팅 인스턴스는 Debian 운영 체제를 사용하며 이전에 생성한 VPC 네트워크에 연결됩니다. 이 구성이 google_compute_network.vpc_network.name을 사용하여 네트워크의 이름 속성을 참조하는 방법에 주목하세요. 이렇게 하면 두 리소스 간의 종속성이 설정됩니다. Terraform은 적절한 순서로 생성되도록 관리하는 리소스의 종속성 그래프를 작성합니다.
인수가 없어도 access_config 블록이 있으면 VM에 외부 IP 주소가 제공되어 인터넷을 통해 액세스할 수 있습니다.
팁: 다른 인스턴스에서 오는 경우를 포함하여 인스턴스에 대한 모든 트래픽은 허용하도록 방화벽 규칙이 생성되지 않는 한 방화벽에 의해 차단됩니다. 트래픽이 인스턴스에 액세스할 수 있도록 google_compute_firewall 리소스를 추가합니다.
이제 Terraform apply를 실행하여 컴퓨팅 인스턴스를 생성합니다. Terraform은 작업을 확인하라는 메시지를 표시합니다.
terraform apply 다시 실행합니다. Google Cloud Platform은 실행 중인 인스턴스에서 부팅 디스크 이미지 교체를 지원하지 않기 때문에 Terraform은 인스턴스를 교체합니다.
$ terraform apply
Terraform은 먼저 기존 인스턴스를 파괴한 다음 새 인스턴스를 생성합니다. terraform show를 사용하여 이 인스턴스와 연결된 새 값을 확인할 수 있습니다.
Destroy Infrastructure
Terraform을 사용하여 인프라를 만들고 수정했습니다. 이제 Terraform 관리 인프라를 파괴하는 방법을 알아봅니다.
인프라가 더 이상 필요하지 않으면 보안 노출과 비용을 줄이기 위해 이를 파괴할 수 있습니다. 예를 들어 서비스에서 프로덕션 환경을 제거하거나 빌드 또는 테스트 시스템과 같은 단기 환경을 관리할 수 있습니다. 인프라를 구축하고 수정하는 것 외에도 Terraform은 관리하는 리소스를 파괴하거나 재생성할 수 있습니다.
Destroy
Terraform destroy 명령은 Terraform 프로젝트에서 관리하는 리소스를 종료합니다. 이 명령은 Terraform 상태에 지정된 모든 리소스를 종료한다는 점에서 terraform apply의 반대입니다. 현재 Terraform 프로젝트에서 관리하지 않는 다른 곳에서 실행 중인 리소스는 파괴하지 않습니다.
$ terraform destroy
Terraform apply와 마찬가지로 Terraform은 리소스를 파괴해야 하는 순서를 결정합니다. GCP는 VPC 네트워크에 다른 리소스가 아직 남아 있는 경우 VPC 네트워크를 제거하지 않으므로 Terraform은 인스턴스가 먼저 제거될 때까지 기다립니다. 작업을 수행할 때 Terraform은 올바른 작업 순서를 결정하기 위해 종속성 그래프를 생성합니다. 여러 리소스가 있는 더 복잡한 경우 Terraform은 안전한 경우 병렬로 작업을 수행합니다.
Define Input Variables
지금까지의 예제에서는 하드 코딩된 값을 사용했습니다. Terraform 구성에는 구성을 보다 동적이고 유연하게 만드는 변수를 사용할 수 있습니다.
Define input variables
Learn-terraform-gcp 디렉토리에서 다음 변수 정의를 사용하여 variables.tf라는 새 파일을 만듭니다.
팁: Terraform은 작업 디렉토리에서 .tf로 끝나는 모든 파일을 로드하므로 원하는 대로 구성 파일의 이름을 지정할 수 있습니다. 구성을 보다 쉽게 구성하고 이해할 수 있도록 자체 파일에 변수를 정의하는 것이 좋습니다.
이 파일은 Terraform 구성 내에서 4개의 변수를 정의합니다. 프로젝트 및 credentials_file 변수에 빈 블록({ })이 있습니다. 지역 및 영역 변수는 기본값을 설정합니다. 기본값이 설정되어 있으면 변수는 선택 사항입니다. 그렇지 않으면 변수가 필요합니다. 지금 terraform 계획을 실행하면 Terraform은 project 및 credentials_file에 대한 값을 묻는 메시지를 표시합니다.
Use variables in configuration
새 변수를 사용하도록 main.tf에서 GCP 제공자 구성을 업데이트합니다.
terraform {
required_providers {
google = {
source = "hashicorp/google"
}
}
}
provider "google" {
version = "3.5.0"
// credentials = file("<NAME>.json")
credentials = file(var.credentials_file)
// project = "<PROJECT_ID>"
// region = "asia-northeast3"
// zone = "asia-northeast3-a"
project = var.project
region = var.region
zone = var.zone
}
변수는 var. 접두사로 참조됩니다.
Assign values to your variables.
파일의 값을 사용하여 변수를 설정할 수 있습니다. Terraform은 작업을 실행할 때 작업 디렉토리에서 terraform.tfvars 또는 *.auto.tfvars 라는 파일을 자동으로 로드합니다.
terraform.tfvars라는 파일을 만들고 아래 값을 복사하여 붙여넣습니다. <PROJECT_ID> 및 <FILE>을 GCP 프로젝트 ID와 키 파일 경로로 바꿔야 합니다.
지역 및 구역 입력 변수는 기본값으로 설정되어 있으므로 설정할 필요가 없습니다. 변수 파일에 설정한 값은 원래 구성과 일치하므로 Terraform은 인프라를 변경할 필요가 없습니다.
Query Data with Output Variables
위에서는 입력 변수를 사용하여 Terraform 구성을 매개변수화했습니다. 여기에서는 출력 값을 사용하여 Terraform 사용자에게 쉽게 쿼리하고 표시할 데이터를 구성합니다.
복잡한 인프라를 구축할 때 Terraform은 모든 리소스에 대해 수백 또는 수천 개의 속성 값을 저장합니다. Terraform 사용자는 몇 가지 중요한 가치에만 관심이 있을 수 있습니다. 출력은 표시할 데이터를 지정합니다. 이 데이터는 apply가 호출될 때 출력되며, terraform output 명령어를 사용하여 조회할 수 있습니다.
Define outputs
Terraform이 프로비저닝하는 인스턴스의 IP 주소에 대한 출력을 정의합니다. 다음 내용으로 output.tf라는 파일을 만듭니다.
output "ip" {
value = google_compute_instance.vm_instance.network_interface.0.network_ip
}
"ip"라는 이름의 출력 변수를 정의합니다. 변수 이름은 다른 모듈에 대한 입력으로 사용되는 경우 Terraform 변수 명명 규칙을 따라야 합니다. 값 필드는 컴퓨팅 인스턴스의 첫 번째 네트워크 인터페이스 속성의 network_ip 값을 지정합니다.
다중 출력 블록을 정의하여 다중 출력 변수를 지정할 수 있습니다.
Inspect outputs
이러한 출력 값을 사용하려면 먼저 이 구성을 적용해야 합니다.
$ terraform apply
Terraform output 명령으로 출력을 쿼리합니다.
$ terraform output
Terraform 출력을 사용하여 Terraform 프로젝트를 인프라의 다른 부분 또는 다른 Terraform 프로젝트와 연결할 수 있습니다.
Destroy your infrastructure
$ terraform destroy
Next steps
Terraform 구성 언어에 대한 더 많은 실습 경험을 원하거나 Terraform의 빌딩 블록에 대해 자세히 알아보려면 아래 문서를 참조합니다.
Configuration Language - 보다 정교한 Terraform 구성을 작성하기 위해 변수, 출력, 종속성, 메타 인수 및 기타 언어 기능에 더 익숙해집니다.
테라폼Terraform은 하시코프Hashicorp에서 오픈소스로 개발중인 인프라스트럭처 관리 도구입니다. 서비스 실행에 필요한 환경을 구축하는 도구라는 점에서 셰프Chef나 앤서블Ansible 같은 설정 관리 도구와 더불어 프로비저닝 도구로 분류됩니다. 테라폼은 코드로서의 인프라스트럭처Infrstructure as Code를 지향하고 있는 도구로서, GUI나 웹 콘솔을 사용해 서비스 실행에 필요한 리소스를 관리하는 대신 필요한 리소스들을 선언적인 코드로 작성해 관리할 수 있도록 해줍니다.
이 글에서는 테라폼의 기본적인 개념들을 소개하고, 테라폼으로 아마존 웹 서비스Amazon Web Serivce(이하 AWS)에서 간단한 웹 애플리케이션을 배포하기 위한 인프라스트럭처를 프로비저닝해보겠습니다.
테라폼 설치
테라폼을 사용하려면 먼저 설치를 해야 합니다.
Linux 는 OS에 따라 패키지를 설치해서 사용할 수 있습니다. 본 문서에서는 Debina/Ubuntu 기준으로 설명합니다.
시스템이 최신 상태이고 gnupg, software-properties-common 및 curl 패키지가 설치되어 있어야 합니다. 이 패키지를 사용하여 HashiCorp의 GPG 서명을 확인하고 HashiCorp의 Debian 패키지 저장소를 설치합니다.
$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS
NAMES
3771450c61e3 f2f70adc5d89 "/docker-entrypoint.…" 6 minutes ago Up 6 minutes 0.0.0.0:8000->80/tcp tutorial
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)
