고민의 흔적

GCP 클라우드 컴퓨팅 기본 속성

1. 컴퓨팅 리소스가 주문형 및 셀프서비스 방식으로 제공됩니다.
2. 클라우드 컴퓨팅 고객은 자동 인터페이스를 사용하므로 사람의 개입 없이 필요한 처리 능력, 스토리지 네트워크를 확보할 수 있습니다.
3. 어디서나 네트워크를 통해 리소스에 액세스 할 수 있습니다. 제공업체에서 대규모 풀의 리소스를 고객에게 할당하므로 고객은 규모의 경제가 주는 이점을 얻습니다.
4. 고객은 이러한 리소스의 정확한 물리적 위치를 파악하거나 신경 쓸 필요가 없습니다. 리소스는 탄력적으로 공급됩니다. 리소스가 추가로 필요하면 신속히 확보할 수 있고 적게 필요하면 축소할 수 있습니다.
5. 마지막으로 고객은 사용하거나 예약하는 만큼만 지불하면 됩니다 리소스 사용을 중단하면 지불도 중단됩니다.

GKE는 Google이 관리하는 클라우드 환경에서 컨테이너화 된 애플리케이션을 실행하며 사용자에게 관리 권한을 부여합니다.

컨테이너화는 이동성을 극대화하고 리소스를 효율적으로 사용할 수 있도록 코드를 패키지화하는 방식으로 Kubernetes는 컨테이너 내부에서 코드를 조정하는 방식으로 이해하면 됩니다.

GKE는 Compute Engine 기반 서비스이다.

Google Cloud Platform이 제공하는 서비스의 이면에는 다양한 리소스가 존재합니다.

1. 물리적 서버와 하드 드라이브 같은 물리적 애셋
2. 가상 머신이나 컨테이너 같은 가상 리소스

모두 Google의 글로벌 데이터 센터에서 관리됩니다.

Google Cloud는 멀티 리전, 리전, 영역을 통해 리소스를 제공합니다.

멀티 리전

1. 전 세계를 크게 세 지역으로 나눕니다. 아메리카, 유럽, 아시아 태평양

리전

1. 3개의 멀티 리전을 다시 나눈 것
2. 리전은 같은 대륙 내에서 독립된 지리적 위치입니다.
3. 리전 내에서는 네트워크 연결이 빠릅니다.
4. 일반적으로 95번째 백분위수에서 1밀리초 미만의 왕복 네트워크 지연 시간을 갖습니다.

영역

1. 리전은 최종적으로 영역으로 나뉩니다.
2. 영역이란 집중된 지리적 위치 내에 있는 GCP 리소스의 배포 위치를 뜻합니다.
3. 한 리전 내에 위치한 데이터 센터가 곧 영역이라고 볼 수 있습니다.
4. 하나의 영역이 반드시 하나의 데이터 센터인 것은 아닙니다.

Compute Engine 가상 머신 인스턴스는 특정 영역 내에 위치합니다. 

그 영역이 사용 불가 상태가 되면 가상 머신과 워크로드 또한 사용할 수 없게 됩니다.

GKE는 Compute Engine을 사용하므로 GKE 워크로드도 비슷한 영향을 받을 수 있습니다.

멀티 영역에 애플리케이션을 배포의 이점

1. 내결함성
2. 고가용성을 확보

세계 각지의 Google 데이터 센터는 Google 네트워크를 통해 연결됩니다.

Google 네트워크에 대한 설명

1. 사용자 앱을 포함한 모든 애플리케이션에 최대 처리량과 최소 지연 시간을 제공하도록 설계되었습니다.
2. Google 네트워크는 전 세계 90개 이상의 인터넷 교환 시설과 100개 이상의 접속 지점을 통해 공개 인터넷을 연결합니다.
3. 인터넷 사용자가 Google 리소스로 트래픽을 전송하면 Google은 지연 시간이 가장 낮은 에지 네트워크 위치에서 사용자의 요청에 응답합니다.
4. Google의 에지 캐싱 네트워크는 지연 시간을 최소화하도록 사용자 가까이에 콘텐츠를 배치합니다.
5. GKE를 비롯해 GCP에서 실행하는 애플리케이션도 이 에지 네트워크의 이점을 활용할 수 있습니다.

GCP와 리소스를 사용하면 리소스의 지리적 위치와 어느 수준에서 지정할지도 결정할 수 있습니다.

1. 영역 수준
   • 영역 리소스는 단일 영역 내에서 실행됩니다 따라서 해당 영역을 사용할 수 없게 되면 리소스 역시 사용할 수 없습니다. 간단한 예시로 Compute Engine 가상 머신 인스턴스와 영구 디스크를 들 수 있습니다. GKE의 구성요소의 하나인 '노드'도 영역 리소스에 해당합니다.
2. 리전 수준
   • 리전 리소스는 하나의 리전 내에 여러 영역에 걸쳐 실행됩니다. 리전 리소스를 사용하는 애플리케이션은 가용성을 높이기 위해 중복 배포될 수 있습니다. 이 전문 분야의 뒷부분에서 GKE를 사용하여 한 리전 내의 여러 영역에 리소스를 분산하는 방법을 알아보겠습니다. GCP 서비스인 Cloud Datastore도 이와 비슷하게 중복 방식을 통해 배포할 수 있습니다.
3. 멀티 리전 수준
   • 마지막으로 전역 리소스는 멀티 리전을 통해 관리할 수 있습니다. 전역 리소스는 애플리케이션의 가용성을 극대화합니다. 전역 리소스의 예시로는 HTTPS 부하 분산기와 virtual private cloud 즉 VPC 네트워크를 들 수 있으며 GKE 사용자도 이 리소스를 활용할 수 있습니다.

사용자가 사용하는 GCP 리소스는 위치와 상관없이 프로젝트에 속해야 합니다.

프로젝트란?

1. 항목을 구성하는 기본 수준으로 리소스 및 서비스를 생성, 사용할 때는 물론 결제, API, 권한 관리 시 기초가 됩니다.
2. 리전과 영역이 GCP 리소스를 물리적으로 구성한다면 프로젝트는 논리적으로 구성한다고 할 수 있습니다.
3. 프로젝트는 손쉽게 생성, 관리, 삭제가 가능하며 실수로 삭제할 경우 복구할 수도 있습니다.
4. 각 프로젝트는 고유한 프로젝트 ID와 프로젝트 번호로 식별됩니다.
5. 프로젝트 이름과 필터링을 위한 라벨을 정할 수 있습니다.
   • 라벨은 변경할 수 있지만 프로젝트 ID와 프로젝트 번호는 고정됩니다.
6. 프로젝트는 '폴더'라는 그룹으로 묶을 수 있습니다.
   1. 폴더를 사용하면 기업의 계층 구조를 반영하고 기업의 정책을 알맞은 수준에서 적용할 수 있습니다.
   2. 물론 폴더 내에 다른 폴더를 중첩할 수도 있습니다.
      1. 예를 들어 부서별 폴더를 만든 다음 각 부서의 폴더 내에 부서를 구성하는 팀별로 하위 폴더를 만들 수 있습니다.
      2. 각 팀의 프로젝트는 팀별 폴더에 속하게 됩니다. 모든 폴더는 하나의 조직에 포함됩니다.
      3. 조직은 GCP 리소스 계층 구조의 루트 노드입니다. 조직이 없더라도 GCP를 사용할 수는 있지만 조직은 무척 유용합니다.
      4. 조직을 이용해 기업 전반에 적용되는 정책을 설정할 수 있다. 또한 폴더를 사용하려면 조직이 필요합니다 GCP 고객이라면 이미 조직이 있을 것입니다. 그렇지 않다면 Google Cloud ID를 통해 무료로 만들 수 있습니다.
      5. 조직에는 고정 조직 ID와 변경할 수 있는 표시 이름이 있습니다. GCP 리소스 계층 구조는 조직 내 여러 부서와 팀의 리소스를 관리할 수 있도록 도와줍니다.
      6. 신뢰 경계와 리소스 격리를 구현하는 계층 구조를 정의할 수도 있습니다.
         1. 예를 들면 인사팀 직원에게 데이터베이스 서버 삭제 권한이 필요할까요? 엔지니어에게 직원 급여 데이터베이스를 삭제할 권한이 있어야 할까요? 둘 다 그렇지 않을 것입니다. Cloud IAM이라고도 하는 Cloud Identity and Access Management는 사용자가 사용하는 모든 GCP 리소스에 세부적인 액세스 제어를 가능케 합니다.
         2. IAM 정책을 정의하면 리소스의 사용자 액세스 제어가 가능합니다. 사용자가 선택한 수준에서 적용한 정책은 낮은 수준으로 상속됩니다. 예컨대 조직 수준에서 IAM 정책을 적용했다면 해당 조직 내의 폴더, 프로젝트 리소스까지 정책이 모두 적용됩니다.
         3. 계층 구조의 보다 낮은 수준에서 정책을 적용하면 추가 권한을 부여할 수 있습니다. 반면, 결제는 프로젝트 수준에서 누적됩니다. 대부분의 GCP 고객이 가진 리소스 계층 구조는 인사 조직도와 비슷하며 프로젝트 결제는 비용 센터 구조와 비슷합니다.
         4. 리소스 계층 구조가 중요한 이유는 GCP의 공유 보안 모델 때문입니다.
            1. 온프레미스 인프라에 애플리케이션을 구축할 경우 사용자가 스택 전체의 보안을 책임져야 합니다.
            2. 하드웨어와 하드웨어가 위치한 프레미스의 물리적 보안 디스크의 데이터 암호화 네트워크 무결성 애플리케이션에 저장된 콘텐츠 보호까지도 포함합니다.
            3. 하지만 애플리케이션을 GCP로 이전하면 Google에서 하위 레이어의 보안을 담당합니다. 하드웨어와 프레미스의 물리적 보안이나 디스크의 데이터 암호화 물리적 네트워크의 무결성 등이 포함되죠
            4. Google은 규모가 큰 만큼 대부분의 고객이 자체적으로 구현할 수 있는 것보다 안전하게 이러한 레이어를 보호할 수 있습니다. 데이터 보안을 비롯한 보안 스택의 상위 레이어는 여전히 사용자의 책임입니다.
            5. Google이 제공하는 도구는 사용자가 이러한 레이어에서 정의하는 정책을 구현하는 데 도움이 됩니다. 앞서 살펴본 리소스 계층 구조는 이러한 도구 중 하나이며 Cloud IAM 역시 마찬가지입니다.

GCP 결제

1. GCP 프로젝트 수준에서 설정합니다.
2. GCP 프로젝트를 정의할 때 결제 계정을 연결해야 합니다.
3. 결제 계정에서 사용자는 지불 옵션을 비롯한 모든 결제 정보를 설정합니다.
4. 결제 계정은 하나 이상의 프로젝트에 연결할 수 있습니다.
5. 결제 계정을 연결하지 않은 프로젝트는 무료 GCP 서비스만 사용 가능합니다.
6. 결제 계정은 매월 또는 기준액 도달 시 자동으로 청구 및 인보이스 되도록 설정할 수 있습니다.
7. 결제 하위 계정을 설정하면 프로젝트 결제를 분리할 수 있습니다.
8. GCP 서비스를 재판매하는 GCP 고객들은 재판매 고객별로 하위 계정을 사용하기도 합니다.

GCP 요금에 대한 걱정을 해결하는 세가지 유용한 도구

1. 예산 및 알림
   • 결제 계정 수준 또는 프로젝트 수준에서 예산을 정의할 수 있습니다.
   • 알림을 설정하면 비용이 예산 한도에 근접했을 때 알림을 받을 수 있습니다.
   • 예를 들면 예산 한도가 2만 달러이고 알림을 90%로 설정했다면 비용이 기준액이나 1만 8천 달러에 도달했을 때 알림을 받게 됩니다. 알림에 대한 응답으로 웹 훅이 호출되도록 설정할 수도 있으며 이 웹 훅을 사용하여 결제 알림을 기반으로 자동화를 제어할 수 있습니다. 예를 들어 결제 알림이 발생하면 리소스를 종료시키는 스크립트를 트리거하거나 웹 훅을 사용해 팀에 장애 신고를 제출할 수도 있습니다.
2. 결제 내보내기에서 보기
   • 외부 분석 검색이 손쉬운 곳에 결제 세부정보를 저장할 수 있습니다 BigQuery 데이터 세트나 Cloud Storage 버킷을 쓸 수 있다.
3. 보고서 보기
   • 보고서는 콘솔의 시각적 도구로 프로젝트 또는 서비스를 기준으로 지출을 모니터링할 수 있습니다.

GCP에 구현된 할당량은 예기치 못한 추가적인 결제 청구를 제한합니다.

할당량

1. 오류나 악성 공격으로 인해 리소스를 과소비하는 것을 방지하기 위해 설계되었다.
2. GCP 프로젝트 수준에서 적용됩니다.

할당량에는 두 가지 유형이 있다.

1. 비율 할당량
   • 특정 시점을 기준으로 재설정됩니다.
   • GKE 서비스는 기본적으로 GCP 프로젝트에서 API에 보내는 호출을 100초당 1천 건으로 제한하는 할당량을 구현하며 100초가 지나면 한도가 재설정됩니다.
   • 여기서 중요한 점은 GKE에서 실행되는 애플리케이션에서 받는 호출의 비율이 아닌 GKE 클러스터 자체에서 받는 호출을 제한하는 방식이라는 점입니다.
   • 일반적으로 그처럼 짧은 시간 안에 많은 호출을 보내는 일은 흔치 않으므로 할당량을 통해 오류성 행동을 차단하는 데 도움이 됩니다.
2. 배정 할당량
   1. 프로젝트 내에서 보유할 수 있는 리소스 수를 제어합니다.
   2. 배정 할당량은 시간이 지나도 재설정되지 않으므로 할당량이 넘지 않도록 리소스를 해제해야 합니다.
   3. 예를 들면 기본적으로 각 GCP 프로젝트는 VPC 네트워크 또는 virtual private cloud를 5개 이상 보유할 수 없도록 할당량이 적용됩니다.
   4. 할당량은 모든 프로젝트에 똑같이 적용되지 않습니다
      • 모든 프로젝트가 같은 할당량으로 시작되지만 Google Cloud 지원팀에 요청하면 일부 프로젝트의 할당량을 늘릴 수 있습니다.
      • 일부 할당량은 프로젝트 사용에 따라 자동으로 증가하기도 합니다.
      • GCP Console을 사용해 일부 프로젝트의 할당량을 줄일 수도 있습니다.
      • 모든 GCP 고객에게 고정되는 할당량도 일부 있습니다. 어떤 경우든 GCP 할당량은 고객에게 혜택을 주는 한편 예기치 않은 사용량 급증을 줄여 GCP 사용자 커뮤니티를 보호하는 역할을 합니다.

GCP와 상호작용하는 방법은 네 가지입니다

1. Google Cloud Platform Console
   • GCP Console은 웹 기반 그래픽 사용자 인터페이스로 GCP 리소스를 관리할 수 있습니다.
   • 간단한 마우스 클릭만으로 일반적인 작업을 수행할 수 있습니다.
   • 명령어를 외우거나 오타를 걱정할 필요가 없다.
   • GCP 프로젝트와 리소스를 가시적으로 파악하기도 용이합니다.
   • 웹브라우저로 console.cloud.google.com에 접속하여 GCP Console에 로그인하면 됩니다.
   • 왼쪽 상단의 탐색 메뉴 버튼을 통해 모든 GCP 서비스에 액세스 할 수 있습니다.
2. Cloud Shell
   • 사용 중인 머신에서 Cloud SDK 설치가 어려운 경우 사용한다.
   • Cloud Shell을 사용하면 브라우저에서 직접 명령줄을 통해 클라우드 리소스에 액세스 할 수 있습니다.
   • Cloud Shell을 사용하면 Cloud SDK 등의 도구를 로컬에 설치하지 않아도 손쉬운 프로젝트 및 리소스 관리가 가능합니다.
   • Cloud SDK, gcloud, kubectl 명령줄 도구와 그 외 유틸리티는 완전히 인증되어 있고 항상 최신 상태로 사용할 수 있습니다.
   • Cloud Shell은 어떻게 이것이 가능할까?
     • 비용이 없는 Compute Engine 가상 머신 인스턴스를 사용해 빌드되었기 때문입니다.
   • Cloud Shell 가상 머신은 단기적입니다. 사용자가 상호작용을 멈추면 작동을 중단하며 사용자가 Cloud Shell에 다시 진입하면 작동을 다시 시작합니다. 따라서 Cloud Shell에서 프로덕션 웹 서버를 실행하지 않는 것이 나을 수 있습니다.
   • 새 Cloud Shell 세션을 시작할 때마다 5GB의 영구 디스크 스토리지도 연결됩니다.
   • 또한 웹 미리보기 기능이 탑재되어 있으며 GKE 리소스를 비롯한 GCP Console 프로젝트 및 리소스에 대한 액세스 인증도 기본적으로 제공합니다.
   • Cloud Shell 코드 편집기는 웹브라우저에서 Cloud Shell 환경 내 파일을 실시간으로 편집하는 도구입니다.
   • Cloud Shell 명령 프롬프트에서 텍스트 편집기를 사용할 수도 있습니다.
   • 코드 우선 애플리케이션 또는 컨테이너 기반 워크로드를 작업할 때 무척 편리합니다. 변경사항을 다운로드, 업로드하지 않아도 간편하게 파일을 편집할 수 있기 때문이죠
3. Cloud SDK Cloud Console 모바일 앱
   • Google Cloud SDK를 다운로드하고 원하는 컴퓨터에 설치할 수도 있습니다.
   • Cloud SDK는 Google Cloud Platform용 명령줄 도구 집합을 포함하며 특히 이 과정에서 자주 사용할 gcloud 및 kubectl 명령어가 포함되어 있습니다.
   • gsutil 및 bq 유틸리티도 포함되어 있습니다.
   • 이러한 도구는 대화형으로나 자동화 스크립트에서 사용할 수도 있습니다.
   • Cloud SDK에는 다양한 프로그래밍 언어를 위한 클라이언트 라이브러리도 포함되어 있습니다
4. REST 기반 API
5. iOS와 Android에서 사용할 수 있는 Cloud Console 모바일 앱
   • 가상 머신 관리 가상 머신 로그 조회 프로젝트의 최신 결제 정보 확인 예산을 초과하는 프로젝트에 대해 결제 알림 받기
   • 커스텀 그래프를 설정하여 CPU 사용량과 네트워크 사용량 초당 요청 수, 서버 오류와 같은 주요 항목 표시 등이 있습니다

컴퓨팅 옵션

개요

Kubernetes 엔진에서 지속적 전달 파이프라인을 설정하는 방법

• Kubernetes Engine 클러스터에 Jenkins 애플리케이션 프로비저닝
• Helm 패키지 관리자를 사용하여 Jenkins 애플리케이션 설정
• Jenkins 애플리케이션의 기능 살펴보기
• Jenkins 파이프라인 생성 및 실행

젠킨스란?

Jenkins는 빌드, 테스트 및 배포 파이프라인을 유연하게 오케스트레이션 할 수 있는 오픈 소스 자동화 서버입니다. Jenkins를 사용하면 개발자가 지속적 배포에서 발생할 수 있는 오버헤드 문제에 대해 걱정하지 않고 프로젝트를 빠르게 배포할 수 있습니다.

1. Jenkins 프로비저닝

gcloud container clusters create jenkins-cd \
--num-nodes 2 \
--machine-type n1-standard-2 \
--scopes "https://www.googleapis.com/auth/source.read_write,cloud-platform"

Kubernetes 클러스터 만들기위한 명령어입니다.

gcloud container clusters list

클러스터가 실행 중인지 확인하는 명령어입니다.

gcloud container clusters get-credentials jenkins-cd

클러스터에 대한 자격 증명을 가져옵니다.

kubectl cluster-info

Kubernetes Engine은 이러한 자격 증명을 사용하여 새로 프로비저닝 된 클러스터에 액세스 합니다. 위의 명령어를 실행하여 클러스터에 연결할 수 있는지 확인합니다.

2. Setup Helm

Helm을 사용하여 Charts 리포지토리에서 Jenkins를 설치합니다. Helm은 Kubernetes 애플리케이션을 쉽게 구성하고 배포할 수 있게 해주는 패키지 관리자입니다. Jenkins가 설치되면 CI/CD 파이프라인을 설정할 수 있습니다.

helm repo add jenkins https://charts.jenkins.io
helm repo update

Helm의 차트 저장소 추가하는 명령어입니다.

3. Jenkins 구성 및 설치

Jenkins 설치 시 values파일을 템플릿으로 사용하여 설정에 필요한 값을 제공할 수 있습니다.

사용자 지정 values파일을 사용하여 Kubernetes 클라우드를 자동으로 구성하고 다음 필수 플러그인을 추가합니다.

• Kubernetes:1.29.4
• Workflow-multibranch:latest
• Git:4.7.1
• Configuration-as-code:1.51
• Google-oauth-plugin:latest
• Google-source-plugin:latest
• Google-storage-plugin:latest

이렇게 하면 Jenkins가 클러스터와 GCP 프로젝트에 연결할 수 있습니다.

gsutil cp gs://spls/gsp330/values.yaml jenkins/values.yaml
helm install cd jenkins/jenkins -f jenkins/values.yaml --wait

첫 번째 명령어는 values파일을 다운로드 하기 위한 명령어입니다.

두 번째 명령어는 Helm CLI를 사용하여 구성 설정으로 차트를 배포하는 명령어입니다.

kubectl get pods
kubectl create clusterrolebinding jenkins-deploy --clusterrole=cluster-admin --serviceaccount=default:cd-jenkins

클러스터에 배포할 수 있도록 Jenkins 서비스 계정을 구성합니다.

Jenkins 포드가 Running상태로 전환되고 컨테이너가 READY 상태인지 확인합니다.

export POD_NAME=$(kubectl get pods --namespace default -l "app.kubernetes.io/component=jenkins-master" -l "app.kubernetes.io/instance=cd" -o jsonpath="{.items[0].metadata.name}")
kubectl port-forward $POD_NAME 8080:8080 >> /dev/null &

위의 명령어를 실행하여 Cloud Shell에서 Jenkins UI로 포트 전달을 설정합니다.

kubectl get svc

Jenkins 서비스가 제대로 생성되었는지 확인합니다.

printf $(kubectl get secret cd-jenkins -o jsonpath="{.data.jenkins-admin-password}" | base64 --decode);echo

Jenkins 차트는 자동으로 관리자 암호를 생성합니다. 위의 명령어는 암호를 확인하기 위한 명령어입니다.

사용자 이름 admin과 자동 생성된 비밀번호로 로그인할 수 있습니다.

성공적으로 로그인이 된걸 확인할 수 있다.

6. 애플리케이션 배포

• 프로덕션 : 사용자가 액세스하는 라이브 사이트입니다.
• 카나리아 : 사용자 트래픽의 일정 비율만 수신하는 소규모 사이트입니다. 이 환경을 사용하여 모든 사용자에게 릴리스 되기 전에 라이브 트래픽으로 소프트웨어를 검증하십시오.

cd sample-app
kubectl create ns production
kubectl apply -f k8s/production -n production
kubectl apply -f k8s/canary -n production
kubectl apply -f k8s/services -n production

두 번째 명렁어로 배포를 논리적으로 격리하기 위해 Kubernetes 네임스페이스를 만듭니다.

kubectl apply 명령어를 사용하여 프로덕션 및 카나리아 배포와 서비스를 만듭니다.

기본적으로 프런트엔드의 복제본은 하나만 배포됩니다. 명령을 사용하여 kubectl scale항상 실행 중인 복제본이 4개 이상 있는지 확인합니다.

kubectl scale deployment gceme-frontend-production -n production --replicas 4
kubectl get pods -n production -l app=gceme -l role=frontend
kubectl get pods -n production -l app=gceme -l role=backend
kubectl get service gceme-frontend -n production

첫 번째 명령어를 실행하여 프로덕션 환경의 프런트엔드를 확장합니다.

이제 두 번째 명령어를 실행하여 프런트엔드용으로 5개의 포드, 프로덕션 트래픽용으로 4개, 카나리아 릴리스용으로 1개가 실행 중인지 확인합니다(카나리아 릴리스에 대한 변경 사항은 사용자 5명 중 1명(20%)에게만 영향을 미침).

세 번째 명령어를 실행하여 백엔드용 포드 2개(프로덕션용 1개, 카나리아용 1개)가 있는지 확인합니다.

네 번째 명령어는 프로덕션 서비스에 대한 외부 IP 검색하는 명령어입니다.

외부 IP 를 브라우저에 붙여 넣으면 카드에 표시된 정보 카드를 볼 수 있습니다.

export FRONTEND_SERVICE_IP=$(kubectl get -o jsonpath="{.status.loadBalancer.ingress[0].ip}" --namespace=production services gceme-frontend)
curl http://$FRONTEND_SERVICE_IP/version

첫 번째 명령어로 프런트엔드 서비스 로드 밸런서 IP를 나중에 사용할 수 있도록 환경 변수에 저장합니다.

브라우저에서 프런트엔드 외부 IP 주소를 열어 두 서비스가 모두 작동하는지 확인합니다.

curl 명령을 실행하여 서비스의 버전 출력을 확인합니다.

1.0.0 이 정상 출력되는 것을 확인하실 수 있습니다.

7. Jenkins 파이프라인 생성

git init
git config credential.helper gcloud.sh
git remote add origin https://source.developers.google.com/p/$DEVSHELL_PROJECT_ID/r/default
git config --global user.email "[EMAIL_ADDRESS]"
git config --global user.name "[USERNAME]"
git add .
git commit -m "Initial commit"
git push origin master

Multibranch Pipeline 옵션을 선택하고 확인을 클릭 합니다.

Branch Sources에서 소스 추가 를 클릭하고 git 을 선택합니다.

https://source.developers.google.com/p/[PROJECT_ID]/r/default

Project Repository에 위에 URL을 복사해 붙여 넣습니다. 

Credentials에서 이전 단계에서 서비스 계정을 추가할 때 생성한 자격 증명의 이름을 선택합니다.

Scan Multibranch Pipeline Triggers 섹션에서,  Periodically if not otherwise run을 선택하고 Interval 값을 1분으로 설정합니다. 이 단계를 완료하면 이라는 작업이 Branch indexing 실행됩니다.이 메타 작업은 저장소의 분기를 식별하고 기존 분기에서 변경 사항이 발생하지 않았는지 확인합니다. 왼쪽 상단의 sample-app을 클릭하면 master작업이 표시됩니다. Jenkins 파이프라인을 성공적으로 생성했습니다.

vi Jenkinsfile

REPLACE_WITH_YOUR_PROJECT_ID를 자기 자신의 PROJECT_ID값으로 바꾸고 저장을 해준다.

vi html.go

<div class="card blue">의 값을 <div class="card oragne"> 값으로 변경합니다.

vi main.go

const version string = "1.0.0"을 const version string = "2.0.0"의 값으로 변경합니다.

밑에 카나리아 릴리스 배포, 프로덕션에 배포는 생략하였습니다. 

마지막 과정까지 완료하여서 쿠버네티스 구글 클라우드 과정을 수료하였습니다! 이 후에 쿠버네티스 구글 클라우드 과정의 후기와 느낀 점의 글을 작성하겠습니다!

개요

지속적인 배포, 블루-그린 배포, 카나리아 배포 등과 같은 애플리케이션 배포 시나리오를 관리하기 위해 정기적으로 여러 배포를 사용합니다. 이 실습에서는 여러 이기종 배포가 사용되는 이러한 일반적인 시나리오를 수행할 수 있도록 컨테이너 확장 및 관리에 대한 실습을 제공합니다.

배포 소개

이기종 배포에는 일반적으로 특정 기술 또는 운영 요구 사항을 해결하기 위해 둘 이상의 별개의 인프라 환경 또는 지역을 연결하는 작업이 포함됩니다. 이기종 배포는 배포의 세부 사항에 따라 하이브리드, 멀티 클라우드 또는 퍼블릭-프라이빗이라고 합니다. 이 실습의 목적에 따라 이기종 배포에는 단일 클라우드 환경, 여러 퍼블릭 클라우드 환경(멀티 클라우드) 또는 온프레미스와 퍼블릭 클라우드 환경의 조합(하이브리드 또는 퍼블릭-프라이빗) 내의 지역에 걸친 배포가 포함됩니다.

단일 환경 또는 지역으로 제한된 배포에서는 다양한 비즈니스 및 기술 문제가 발생할 수 있습니다.

• 최대 리소스 : 모든 단일 환경, 특히 온프레미스 환경에서는 프로덕션 요구 사항을 충족하는 컴퓨팅, 네트워킹 및 스토리지 리소스가 없을 수 있습니다.
• 제한된 지리적 범위 : 단일 환경에 배포하려면 지리적으로 멀리 떨어져 있는 사람들이 하나의 배포에 액세스해야 합니다. 트래픽은 전 세계의 중앙 위치로 이동할 수 있습니다.
• 제한된 가용성 : 웹 규모의 트래픽 패턴은 애플리케이션이 내결함성과 탄력성을 유지하도록 요구합니다.
• 공급업체 종속 : 공급업체 수준 플랫폼 및 인프라 추상화로 인해 애플리케이션을 이식할 수 없습니다.
• 유연하지 않은 리소스 : 리소스가 특정 컴퓨팅, 스토리지 또는 네트워킹 오퍼링 세트로 제한될 수 있습니다.

이기종 배포는 이러한 문제를 해결하는 데 도움이 될 수 있지만 프로그래밍 방식의 결정론적 프로세스와 절차를 사용하여 설계해야 합니다. 일회성 또는 임시 배포 절차로 인해 배포 또는 프로세스가 취약해지고 장애를 견딜 수 없게 될 수 있습니다. 임시 프로세스는 데이터를 손실하거나 트래픽을 삭제할 수 있습니다. 좋은 배포 프로세스는 반복 가능해야 하며 프로비저닝, 구성 및 유지 관리를 위해 입증된 접근 방식을 사용해야 합니다. 이기종 배포에 대한 세 가지 일반적인 시나리오는 다중 클라우드 배포, 온프레미스 데이터 프론팅 및 CI/CD(지속적 통합/지속적 전달) 프로세스입니다.

1. 배포

gcloud container clusters create bootcamp --num-nodes 5 --scopes "https://www.googleapis.com/auth/projecthosting,storage-rw"

5개의 노드가 있는 클러스터를 만듭니다.

kubectl explain deployment

deployment에 대한 설명을 보여주는 명령어입니다.

kubectl explain deployment --recursive

--recursive 옵션을 사용하면 모든 필드에 대한 doployment 내용을 확인할 수 있습니다.

deployments/auth.yaml구성 파일을 업데이트합니다.

spec:
  container:
	image: "kelseyhightower/auth:1.0.0"

"kelseyhightower/auth:2.0.0"을 "kelseyhightower/auth:1.0.0"으로 업데이트를 해줍니다.

kubectl create -f deployments/auth.yaml

kubectl create 인증 배포를 생성하기 위해 명령을 실행하면 배포 매니페스트의 데이터를 준수하는 하나의 포드가 생성됩니다. 이는 replicas필드에 지정된 수를 변경하여 Pod 수를 확장할 수 있음을 의미합니다.

kubectl get deployments

배포를 생성한 후에는 생성되었는지 확인할 수 있습니다.

kubectl get replicasets

배포가 생성되면 Kubernetes는 배포용 ReplicaSet을 생성합니다. 배포를 위해 ReplicaSet이 생성되었는지 확인할 수 있습니다.

kubectl get pods

마지막으로 배포의 일부로 생성된 파드를 볼 수 있습니다. ReplicaSet이 생성될 때 Kubernetes에 의해 단일 Pod가 생성됩니다.

kubectl create -f services/auth.yaml

이제 인증 배포를 위한 서비스를 만들 차례입니다. 위의 명령어를 사용해서 인증 서비스를 만듭니다.

kubectl create -f deployments/hello.yaml
kubectl create -f services/hello.yaml

hello Deployment를 만들고 expose 합니다.

kubectl create secret generic tls-certs --from-file tls/
kubectl create configmap nginx-frontend-conf --from-file=nginx/frontend.conf
kubectl create -f deployments/frontend.yaml
kubectl create -f services/frontend.yaml

frontend 배포를 만들고 노출합니다.

kubectl get services frontend

curl -ks https://<EXTERNAL-IP>

외부 IP에 curl 명령을 치면 Hello라고 잘 나오는 것을 확인하실 수 있습니다.

2. 확장

이제 배포가 생성되었으므로 확장할 수 있습니다. 

kubectl scale deployment hello --replicas=5

kubectl scale의 replicas 필드는 위의 명령어를 사용하여 쉽게 업데이트할 수 있습니다.

kubectl get pods | grep hello- | wc -l
kubectl scale deployment hello --replicas=3
kubectl get pods | grep hello- | wc -l

deployment가 업데이트되면 Kubernetes는 연결된 ReplicaSet을 자동으로 업데이트하고 새 Pod를 시작하여 총 Pod 수가 5가 되도록 한다. 이제 5개의 helloPod가 실행 중인지 확인합니다. 확인하는 명령어는 kubectl get pods | grep hello- | wc -l입니다. kubectl scale deployment hello --replicas=3은 애플리케이션의 replicas를 3으로 축소하는 명령어입니다.

롤링 업데이트

배포는 롤링 업데이트 메커니즘을 통해 이미지를 새 버전으로 업데이트하는 것을 지원합니다. Deployment가 새 버전으로 업데이트되면 새 ReplicaSet을 생성하고 이전 ReplicaSet의 복제본이 감소함에 따라 새 ReplicaSet의 복제본 수를 천천히 늘립니다.

deployments/auth.yaml구성 파일을 업데이트합니다.

spec:
  container:
	image: "kelseyhightower/auth:2.0.0"

"kelseyhightower/auth:1.0.0"을 "kelseyhightower/auth:2.0.0"으로 업데이트를 해줍니다.

편집기에서 저장하면 업데이트된 배포가 클러스터에 저장되고 Kubernetes가 롤링 업데이트를 시작합니다.

kubectl get replicaset
kubectl rollout history deployment/hello

실행 중인 롤아웃에서 문제가 감지되면 일시 중지하여 업데이트를 중지합니다.

kubectl rollout pause deployment/hello
kubectl rollout status deployment/hello
kubectl get pods -o jsonpath --template='{range .items[*]}{.metadata.name}{"\t"}{"\t"}{.spec.containers[0].image}{"\n"}{end}'

1번째 명령어는 중지시키는 명령어입니다. 2번째 명령어는 deployment의 상태를 확인하는 명령어입니다.

3번째 명령어는 Pod에서 확인하기 위한 명령어입니다.

kubectl rollout resume deployment/hello
kubectl rollout status deployment/hello

롤아웃이 일시 중지되어 일부 포드는 새 버전이고 일부 포드는 이전 버전입니다. resume명령 을 사용하여 롤아웃을 계속할 수 있습니다.

status롤아웃이 완료되면 위의 status 명령어를 실행할 때 "hello" 성공적으로 롤아웃이 되었습니다라고 출력되어야 합니다.

kubectl rollout undo deployment/hello
kubectl rollout history deployment/hello
kubectl get pods -o jsonpath --template='{range .items[*]}{.metadata.name}{"\t"}{"\t"}{.spec.containers[0].image}{"\n"}{end}'

새 버전에서 버그가 감지되었다고 가정합니다. 새 버전에는 문제가 있는 것으로 추정되므로 새 Pod에 연결된 모든 사용자는 이러한 문제를 겪을 것입니다.

조사한 다음 제대로 수정된 버전을 릴리스할 수 있도록 이전 버전으로 롤백하고 싶을 것입니다.

다음 명령을 사용 rollout하여 이전 버전으로 롤백합니다.

카나리아 배포

사용자의 하위 집합을 사용하여 프로덕션에서 새 배포를 테스트하려는 경우 카나리아 배포를 사용합니다. Canary 배포를 사용하면 소규모 사용자 하위 집합에 대한 변경 사항을 릴리스하여 새 릴리스와 관련된 위험을 완화할 수 있습니다.

카나리아 배포는 새 버전이 포함된 별도의 배포와 정상적인 안정적인 배포와 카나리아 배포를 모두 대상으로 하는 서비스로 구성됩니다.

kubectl create -f deployments/hello-canary.yaml
kubectl get deployments

Canary 배포가 생성된 후에는 hello 하고 hello-canary의 두 개의 배포가 있어야 한다.

curl -ks https://`kubectl get svc frontend -o=jsonpath="{.status.loadBalancer.ingress[0].ip}"`/version

hello요청에 의해 제공되는 버전을 확인할 수 있습니다. 이것을 여러 번 실행하면 일부 요청이 hello 1.0.0에서 제공되고 작은 하위 집합(1/4 = 25%)이 2.0.0에서 제공되는 것을 볼 수 있습니다.

블루 - 그린 배포

롤링 업데이트는 오버헤드를 최소화하고 성능에 미치는 영향을 최소화하며 가동 중지 시간을 최소화하면서 애플리케이션을 천천히 배포할 수 있기 때문에 이상적입니다. 새 버전이 완전히 배포된 후에만 해당 새 버전을 가리키도록 로드 밸런서를 수정하는 것이 유리한 경우가 있습니다. 이 경우 블루-그린 배포가 올바른 방법입니다.

Kubernetes는 두 개의 개별 배포를 생성하여 이를 달성합니다. 하나는 이전 "파란색" 버전용이고 다른 하나는 새 "녹색" 버전용입니다. hello"파란색" 버전에 대해 기존 배포를 사용합니다. 배포는 라우터 역할을 하는 서비스를 통해 액세스 됩니다.새로운 "그린" 버전이 실행되고 나면 서비스를 업데이트하여 해당 버전을 사용하도록 전환합니다.

블루-그린 배포의 주요 단점은 애플리케이션을 호스팅 하는 데 필요한 클러스터에 최소 2배의 리소스가 필요하다는 것입니다. 한 번에 두 버전의 애플리케이션을 모두 배포하기 전에 클러스터에 충분한 리소스가 있는지 확인하십시오.

kubectl apply -f services/hello-blue.yaml

먼저 서비스를 업데이트합니다.

kubectl create -f deployments/hello-green.yaml
curl -ks https://`kubectl get svc frontend -o=jsonpath="{.status.loadBalancer.ingress[0].ip}"`/version
kubectl apply -f services/hello-green.yaml
curl -ks https://`kubectl get svc frontend -o=jsonpath="{.status.loadBalancer.ingress[0].ip}"`/version

녹색 배포가 있고 제대로 시작되면 현재 버전 1.0.0이 여전히 사용 중인지 확인합니다. 이제 새 버전을 가리키도록 서비스를 업데이트합니다. 서비스가 업데이트되면 "그린" 배포가 즉시 사용됩니다. 이제 새 버전이 항상 사용 중인지 확인할 수 있습니다.

kubectl apply -f services/hello-blue.yaml
curl -ks https://`kubectl get svc frontend -o=jsonpath="{.status.loadBalancer.ingress[0].ip}"`/version

필요한 경우 동일한 방식으로 이전 버전으로 롤백할 수 있습니다. "파란색" 배포가 계속 실행되는 동안 서비스를 이전 버전으로 다시 업데이트하기만 하면 됩니다. 서비스를 업데이트하면 롤백이 성공한 것입니다. 다시 한 번 올바른 버전이 사용 중인지 확인합니다.

개요

• Kubernetes Engine을 사용하여 완전한 Kubernetes 클러스터를 프로비저닝 합니다.
• 를 사용하여 Docker 컨테이너를 배포하고 관리 kubectl합니다.
• Kubernetes의 배포 및 서비스를 사용하여 애플리케이션을 마이크로 서비스로 나눕니다.

GitHub에서 샘플 코드를 가져와서 실습을 하셔야 됩니다.

1. Pods

kubectl create deployment nginx --image=nginx:1.10.0

Kubernetes는 deployment를 만들었습니다. deployment에 대한 자세한 내용은 나중에 설명한다고 합니다. 지금은 배포가 실행되는 노드에 오류가 발생하더라도 배포가 포드를 계속 실행 상태로 유지한다는 점만 알면 된다.

kubectl get pods

위의 명령어를 사용하여 현재 실행 중인 nginx 컨테이너를 볼 수 있다.

kubectl expose deployment nginx --port 80 --type LoadBalancer

Kubernetes는 공개 IP 주소가 연결된 외부 로드 밸런서를 생성했다. 해당 공용 IP 주소에 도달한 모든 클라이언트는 서비스 뒤의 포트로 라우팅 된다.

kubectl get services

Kubernetes의 현재 서비스 중인 목록을 볼 수 있다.

curl http://<External IP>:80

External IP를 이용하여 curl 명령어를 치면 Welcome to nginx 가 나오는 것을 확인하실 수 있습니다.

Kubernetes의 핵심은 Pod가 있다. Pod는 하나 이상의 컨테이너 컬렉션을 나타내고 보유한다. 일반적으로 서로에 대한 종속성이 강한 여러 컨테이너가 있는 경우 컨테이너를 단일 Pod 안에 패키징 한다. Pod에는 Volumes 도 있다.볼륨은 Pod가 살아있는 동안 지속되는 데이터 디스크이며 해당 포드의 컨테이너에서 사용할 수 있습니다. Pod는 콘텐츠에 대한 공유 네임스페이스를 제공합니다. 즉, 예제 Pod 내부의 두 컨테이너는 서로 통신할 수 있으며 연결된 볼륨도 공유할 수 있습니다. Pod는 또한 네트워크 네임스페이스를 공유한다. 이는 Pod 당 하나의 IP 주소가 있음을 의미합니다.

cat pods/monolith.yaml

위의 명령어는 모놀리스 포드 구성 파일을 확인하는 명령어이다.

• Pod는 하나의 컨테이너(모놀리스)로 구성됩니다.
• 컨테이너가 시작될 때 몇 가지 인수를 컨테이너에 전달합니다.

kubectl create -f pods/monolith.yaml

모놀리스 Pod를 만드는 명령어입니다.

모놀리스 컨테이너 이미지를 실행하려면 먼저 Docker Hub에서 가져와야 합니다.

kubectl describe pods monolith

kubectl describe 명령어를 사용하면 모노리스 Pod IP 주소 및 이벤트 로그를 포함하여 모놀리스 Pod에 대한 자세한 정보를 얻을 수 있다.

kubectl port-forward monolith 10080:80

기본적으로 Pod에는 사설 IP 주소가 할당되며 클러스터 외부에서 연결할 수 없습니다. kubectl port-forward 명령어를 사용하여 로컬 포트를 모놀리스 포드 내부의 포트에 매핑합니다.

curl http://127.0.0.1:10080

새로운 터미널을 열어서 curl 명령어를 치면 Hello라고 나오는 것을 확인하실 수 있습니다.

curl http://127.0.0.1:10080/secure

curl명령을 사용하여 보안 엔드포인트에 도달했을 때 인증 실패라고 나오는 것을 확인하실 수 있습니다.

curl -u user http://127.0.0.1:10080/login

로그인을 해서 JWT 토큰을 발급받습니다.

TOKEN=$(curl http://127.0.0.1:10080/login -u user|jq -r '.token')

Cloud Shell은 긴 문자열 복사를 잘 처리하지 못하므로 토큰에 대한 환경 변수를 만듭니다.

curl -H "Authorization: Bearer $TOKEN" http://127.0.0.1:10080/secure

다시 발급받은 토큰을 이용해서 접근을 하면 Hello 메시지가 정상 출력되는 것을 확인하실 수 있습니다.

kubectl logs monolith

위의 명령어는 log를 확인하는 명령어입니다.

kubectl logs -f monolith

-f는 실시간으로 발생하는 로그를 확인할 수 있는 명령어입니다.

kubectl exec monolith --stdin --tty -c monolith -- /bin/sh

위의 명령어는 Monolith Pod 내에서 대화형 셸을 실행합니다. 컨테이너 내에서 문제를 해결하려는 경우에 유용하게 사용할 수 있다.

ping -c 3 google.com

모놀리스 컨테이너에 셸이 있으면 ping명령을 사용하여 외부 연결을 테스트할 수 있습니다.

2. Services

포드는 영구적이지 않다. 여러 가지 이유로 중지되거나 다시 시작될 수 있으며 이로 인해 문제가 발생한다. Pod 집합과 다시 통신하려는 경우 다시 시작할 때 다른 IP 주소를 가질 수 있습니다. 이때 필요한 것이 서비스입니다. 서비스는 Pod에 안정적인 엔드포인트를 제공합니다.

서비스는 레이블을 사용하여 작동하는 Pod를 결정합니다. Pod에 올바른 레이블이 있으면 자동으로 선택되어 서비스에 노출된다.

서비스가 Pod에 제공하는 액세스 수준은 서비스 유형에 따라 다르다. 이에는 세 가지 유형이 있습니다.

• ClusterIP(내부) 기본 유형은 이 서비스가 클러스터 내부에서만 볼 수 있음을 의미합니다.
• NodePort클러스터의 각 노드에 외부에서 액세스 할 수 있는 IP를 제공하고
• LoadBalancer서비스에서 서비스 내의 노드로 트래픽을 전달하는 클라우드 공급자의 로드 밸런서를 추가합니다.

cat pods/secure-monolith.yaml

서비스를 생성하기 전에 먼저 https 트래픽을 처리할 수 있는 보안 포드를 생성한다.

kubectl create secret generic tls-certs --from-file tls/
kubectl create configmap nginx-proxy-conf --from-file nginx/proxy.conf
kubectl create -f pods/secure-monolith.yaml

보안 모노리스 Pod와 해당 구성 데이터를 작성하는 명령어입니다.

이제 보안 Pod가 생성되었으므로 보안 모놀리스 Pod를 외부에 노출해야 된다. 외부에 노출하려면 Kubernetes 서비스를 생성해야 된다.

• app: monolith 및 레이블이 있는 모든 포드를 자동으로 찾고 노출하는 데 사용되게  하는 secure: enabled이 있다.
• 이제 포트 31000번에서 nginx포트 443으로 외부 트래픽을 전달해야 되므로 노드 포트를 expose 해야 한다.

kubectl create -f services/monolith.yaml

모놀리식 서비스를 만드는 명령어이다.

gcloud compute firewall-rules create allow-monolith-nodeport --allow=tcp:31000

위의 명령어는 노출된 노드 포트에서 모놀리식 서비스에 대한 트래픽을 허용하는 명령어입니다.

gcloud compute instances list

리스트에 대한 정보를 볼 수 있는 명령어입니다. 노드 중 하나에 대한 외부 IP 주소를 가져옵니다.

curl -k https://<EXTERNAL_IP>:31000

curl 명령어를 치면 실패하는 것을 확인하실 수 있습니다.

현재 모놀리스 서비스에는 endpoint가 없습니다. 이와 같은 문제를 해결하는 한 가지 방법은 kubectl get pods레이블 쿼리와 함께 명령어를 사용하는 것입니다.

kubectl label pods secure-monolith 'secure=enabled'
kubectl get pods secure-monolith --show-labels

 Pod에 kubectl label에 누락된 레이블 secure=enabled 추가합니다.

kubectl describe services monolith | grep Endpoints

올바르게 레이블이 지정되었으므로 모놀리스 서비스에서 엔드포인트 목록을 확인하면 올바르게 나오는 것을 확인할 수 있다.

curl -k https://<EXTERNAL_IP>:31000

curl 명령어를 실행시키면 Hello라고 잘 나오는 것을 확인하실 수 있습니다.

3. Deployment

Deployment는 실행 중인 Pod 수가 사용자가 지정한 원하는 Pod 수와 동일하도록 만드는 방법입니다.

Deployment의 주요 이점은 Pod 관리의 낮은 수준 세부 정보를 추상화한다는 것입니다. Deployment는 복제본 세트를 사용하여 Pod 시작 및 중지를 관리합니다. Pod를 업데이트하거나 확장해야 하는 경우나 어떤 이유로 인해 중단된 경우, 다시 시작해야 하는 경우 Deployment에서 처리합니다.

Pod는 생성된 노드의 수명과 연결됩니다. 위의 예에서 Node3이 다운되었습니다(Pod와 함께 사용). 새 Pod를 수동으로 생성하고 이에 대한 노드를 찾는 대신 Deployment에서 새 Pod를 생성하고 Node 2에서 시작했습니다.

이제 Pod 및 서비스에 대해 배운 모든 것을 결합하여 Deployment를 사용하여 모놀리식 애플리케이션을 더 작은 서비스로 분할해봅시다.

모놀리스 앱을 세 개의 개별 조각으로 나눕니다.

• auth - 인증된 사용자에 대한 JWT 토큰을 생성합니다.
• hello - 인증된 사용자를 환영합니다.
• frontend - auth 및 hello 서비스로 트래픽을 라우팅 합니다.

각 서비스에 대해 하나씩 배포를 만들 준비가 되었습니다. 그런 다음 auth 및 hello 배포를 위한 내부 서비스와 frontend 배포를 위한 외부 서비스를 정의합니다. 완료되면 Monolith와 마찬가지로 마이크로 서비스와 상호 작용할 수 있습니다. 이제 각 부분을 독립적으로 확장하고 배포할 수 있습니다.

cat deployments/auth.yaml

Replicas 필드에 지정된 수를 변경하여 Pod 수를 확장할 수 있습니다.

kubectl create -f deployments/auth.yaml

deployments 개체를 만드는 명령어입니다.

kubectl create -f services/auth.yaml

인증 deployment를 위한 서비스를 만드는 명령어입니다.

kubectl create -f deployments/hello.yaml
kubectl create -f services/hello.yaml

hello deployment와 서비스를 만들고 expose 합니다.

kubectl create configmap nginx-frontend-conf --from-file=nginx/frontend.conf
kubectl create -f deployments/frontend.yaml
kubectl create -f services/frontend.yaml

frontend deployment를 만들고 expose 합니다.

kubectl get services frontend

위의 명령어를 이용해 외부 IP 주소를 확인합니다.

curl -k https://<EXTERNAL-IP>

curl 명령어로 EXTERNAL-IP로 요청을 보내면 Hello라는 메시지가 잘 나오는 것을 확인하실 수 있습니다.

쿠버네티스 입문반 Introduction to Docker

첫 수업으로 Introduction to Docker 강의를 들었습니다. 구글 클라우드 환경에서 터미널에 접속해 docker를 실행하고 실습하는 시간이 되었습니다. docker기본을 배우고 듣는 수업이라 어려운 수업은 아니였습니다. 강의가 영어로 되어있어 살짝 힘든 것 말고는 좋은 학습이 될 것 같습니다. 혹시 몰라 구글에서 사용하는 아이디는 모자이크 처리하였습니다.

구글 클라우드 쉘에 접속한 모습입니다. 여기서 쿠버네티스 실습을 진행합니다.

docker run hello-world

위의 사진을 잘 보시면 Unable to find image를 보실 수 있습니다. docker 데몬은 hello-world 이미지를 검색했지만 로컬에서 이미지를 찾지 못해서 Docker Hub라는 공개 레지스트리에서 이미지를 가져와서 해당 이미지에서 컨테이너를 생성하고 컨테이너를 실행했습니다.

docker images

docker images 명령어입니다. 이 스크린 샷은 못 찍었습니다. 이미지 목록을 확인하는 명령어입니다.

docker run hello-world

정상적으로 실행되었습니다. Hello from Docker !

docker ps

docker ps 명령어입니다. 실행 중인 컨테이너가 없습니다. 이전에 실행한 hello-world 컨테이너가 이미 종료되었습니다. 

docker ps -a

종료된 컨테이너를 포함하여 모든 컨테이너를 보려면 docker ps에서 - a 옵션만 추가시켜주면 됩니다.

mkdir test
cd test

test 디렉터리를 만들고 test 디렉터리에 들어갑니다. 

cat > Dockerfile <<EOF
# 공식 Node 런타임을 부모 이미지로 사용 
FROM node:lts
# 컨테이너의 작업 디렉터리를 /app으로 설정 
WORKDIR /app
# 현재 디렉터리 내용을 /app으로 설정
ADD . /app
# 컨테이너의 포트 80을 외부에서 사용할 수 있도록 설정.
EXPOSE 80
# 컨테이너가 실행될 때 node를 사용하여 app.js를 실행합니다. 
CMD ["node", "app.js"]
EOF

dockerfile을 만드는 방법에 대한 설명입니다. 간단하게 실습하는 것이라 명령어에 잘 모르실 경우 제 블로그 참고 바랍니다.

https://lusida-coding.tistory.com/35?category=1031465 

cat > app.js <<EOF
const http = require('http');
const hostname = '0.0.0.0';
const port = 80;
const server = http.createServer((req, res) => {
    res.statusCode = 200;
    res.setHeader('Content-Type', 'text/plain');
    res.end('Hello World\n');
});
server.listen(port, hostname, () => {
    console.log('Server running at http://%s:%s/', hostname, port);
});
process.on('SIGINT', function() {
    console.log('Caught interrupt signal and will exit');
    process.exit();
});
EOF

노드 애플리케이션 파일을 만듭니다. 포트 80에서 수신 대기하고 Hello World를 출력하는 간단한 HTTP 서버입니다.

docker build -t node-app:0.1 .

이미지를 빌드합니다. "."은 현재 디렉터리를 의미하므로 Dockerfile이 있는 디렉토리 내에서 이 명령어를 실행해야 합니다.

node은 기본 이미지이며 node-app빌드한 이미지입니다. node먼저 제거하지 않고는 node-app을 제거할 수 없습니다. 이미지의 크기는 VM에 비해 상대적으로 작습니다.

docker run -p 4000:80 --name my-app node-app:0.1

방금 빌드한 이미지를 기반으로 컨테이너를 실행합니다. 현재 터미널에서 실행되는 것을 확인하실 수 있습니다.

curl http://localhost:4000

--name은 원하는 경우 컨테이너의 이름을 지정할 수 있습니다.호스트 의 -p포트 4000을 컨테이너의 포트 80에 매핑하도록 명령어를 작성했다. 이제 http://localhost:4000. 포트 매핑이 없으면 localhost의 컨테이너에 연결할 수 없습니다. 다른 터미널을 열고 서버를 테스트합니다. Hello World가 정상적으로 출력되는 것을 확인하실 수 있습니다.

docker stop my-app && docker rm my-app

컨테이너를 중지하고 컨테이너를 지우는 명령어입니다.

docker run -p 4000:80 --name my-app -d node-app:0.1

컨테이너를 백그라운드에서 실행하려면(터미널 세션에 연결되지 않음) -d옵션을 지정해야 합니다.

docker logs my-app

컨테이너의 로그를 확인하는 명령어입니다.

docker logs -f [container_id]

 컨테이너가 실행될 때 로그의 출력을 실시간으로 확인하려면 -f옵션을 사용하면 됩니다.

docker build -t node-app:0.2 .

app.js파일에서 Hello World를 Hello Cloud로 수정 후 node-app:0.2로 빌드를 진행하였습니다.

2단계에서 기존 캐시 계층을 사용하고 있음을 알 수 있습니다. 3단계부터 에서 변경했기 때문에 레이어가 수정됩니다.

docker run -p 8080:80 --name my-app-2 -d node-app:0.2
curl http://localhost:8080
curl http://localhost:4000

새 이미지 버전으로 다른 컨테이너를 실행합니다. 호스트 포트 4000은 이미 사용 중이기 때문에 사용할 수 없습니다. 컨테이너를 실행 후 curl로 8080과 4000에 접속 테스트를 진행하였습니다. 8080에는 모자이크로 잘리긴 했으나 Hello to Cloud가 출력되었고 4000에는 수정하기 전인 Hello World가 출력되었습니다.

docker exec -it [container_id] bash

실행 중인 컨테이너 내에서 Bash 세션을 시작할 때는 명령어 마지막에 bash라고 지정해주면 됩니다. docker exec -it를 사용하면 pseudo-tty를 할당하고 표준 입력을 열린 상태로 유지하여 컨테이너와 상호 작용할 수 있습니다. bash는 Dockerfile에 WORKDIR지정된 디렉터리(/app)에서 실행되었습니다.

docker inspect [container_id]

Docker inspect를 사용하여 Docker에서 컨테이너의 메타데이터를 확인할 수 있습니다.

docker inspect --format='{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' [container_id]

docker tag node-app:0.2 gcr.io/[project-id]/node-app:0.2

도커를 푸시를 해주려면 컨테이너에 태그가 붙어있어야 합니다. 제 개인 도커 레파지토리에 푸시를 하려면 제 도커 레파지토리 이름 태그를  붙여줘야 합니다.

docker push gcr.io/[project-id]/node-app:0.2

도커를 gcr에 푸시하는 명령어입니다.