Google Kubernetes Engine에 애플리케이션을 배포하는 Auto DevOps 사용하기

Tier: Free, Premium, Ultimate Offering: GitLab.com, Self-managed, GitLab Dedicated

이 튜토리얼에서는 Google Kubernetes Engine (GKE)에 애플리케이션을 배포하는 방법을 예를 통해 Auto DevOps로 시작하는 데 도움을 드리겠습니다.

GitLab의 기본 Kubernetes 통합을 사용하므로 Google Cloud Platform 콘솔을 사용하여 매뉴얼으로 Kubernetes 클러스터를 만들 필요가 없습니다. GitLab 템플릿에서 생성한 애플리케이션을 만들고 배포합니다.

이 지침은 Self-managed GitLab 인스턴스에도 적용됩니다. 셀프-관리 러너가 구성되어 있고 Google OAuth가 활성화되어 있는지 확인하십시오.

Google Kubernetes Engine에 프로젝트를 배포하려면 다음 단계를 따르십시오.

  1. Google 계정 구성
  2. Kubernetes 클러스터 만들고 에이전트 배포
  3. 템플릿에서 애플리케이션 프로젝트 생성
  4. 에이전트 구성
  5. Ingress 설치
  6. Auto DevOps 구성
  7. Auto DevOps 활성화 및 파이프라인 실행
  8. 애플리케이션 배포

Google 계정 구성

GitLab 프로젝트와 Kubernetes 클러스터를 만들고 연결하기 전에 Google Cloud Platform 계정이 필요합니다. Gmail이나 Google 드라이브에 액세스하는 데 사용하는 기존 Google 계정으로 로그인하거나 새로 만드십시오.

  1. Kubernetes Engine 문서의 “시작하기 전에” 섹션에 설명된 단계를 따라 필요한 API 및 관련 서비스를 활성화하십시오.
  2. Google Cloud Platform과 요금 청구 계정을 만들었는지 확인하십시오.
note
새로운 Google Cloud Platform (GCP) 계정은 $300 크레딧을 받게 되며, Google과의 파트너십을 통해 GitLab은 Google Kubernetes Engine과의 통합을 시작할 수 있는 새로운 GCP 계정에 추가로 $200을 제공할 수 있습니다. 이 링크를 따라 크레딧을 신청하십시오.

Kubernetes 클러스터 생성

Google Kubernetes Engine (GKE)에 새 클러스터를 만들려면 Infrastructure as Code (IaC) 접근 방식을 사용하여 Google GKE 클러스터 만들기 가이드의 단계를 따르십시오. 이 가이드를 통해 Terraform을 사용하여 GKE 클러스터를 만들고 Kubernetes용 GitLab 에이전트를 설치하는 새 프로젝트를 만들어야 합니다. 이 프로젝트에는 GitLab 에이전트의 구성이 들어 있습니다.

템플릿에서 애플리케이션 프로젝트 생성

GitLab 프로젝트 템플릿을 사용하여 시작하십시오. 이름에서 알 수 있듯이, 해당 프로젝트는 일부 잘 알려진 프레임워크를 사용하여 구축된 베어본 애플리케이션을 제공합니다.

caution
애플리케이션 프로젝트를 클러스터 관리를 위한 프로젝트와 동일한 수준 또는 그 아래 그룹 계층에 만들어야 합니다. 그렇지 않으면 에이전트를 승인할 수 없습니다.
  1. 왼쪽 사이드바에서 맨 위의 Create new ()를 선택하고 New project/repository를 선택하십시오.
  2. 템플릿에서 만들기를 선택하십시오.
  3. Ruby on Rails 템플릿을 선택하십시오.
  4. 프로젝트에 이름을 지정하고, 선택적으로 설명을 추가하고, GitLab Ultimate plan에서 제공되는 기능을 활용할 수 있도록 공개로 만듭니다.
  5. 프로젝트 만들기를 선택하십시오.

이제 GKE 클러스터에 배포할 애플리케이션 프로젝트가 준비되었습니다.

에이전트 구성

이제 GitLab Kubernetes를 사용하여 애플리케이션 프로젝트를 배포할 수 있도록 GitLab Kubernetes 에이전트를 구성해야 합니다.

  1. 클러스터를 관리하는 프로젝트를 방문하십시오.
  2. 에이전트 구성 파일 (.gitlab/agents/<agent-name>/config.yaml)에 이동하여 편집하십시오.
  3. ci_access:projects 속성을 구성합니다. 애플리케이션의 프로젝트 경로를 id로 사용하십시오: 
ci_access:
  projects:
    - id: path/to/application-project

Ingress 설치

클러스터가 실행된 후에는 인터넷에서 애플리케이션으로 트래픽을 라우팅하기 위해 로드 밸런서인 NGINX Ingress Controller를 설치해야 합니다. NGINX Ingress Controller를 다음과 같이 GitLab 클러스터 관리 프로젝트 템플릿을 통해 또는 Google Cloud Shell을 통해 매뉴얼으로 설치하십시오.

  1. 클러스터의 세부 정보 페이지로 이동한 다음 고급 설정 탭을 선택하십시오.
  2. Google Cloud Console에서 클러스터를 방문하기 위한 링크를 선택하십시오.
  3. GKE 클러스터 페이지에서 연결을 선택한 다음 Cloud Shell에서 실행을 선택하십시오.

  4. Cloud Shell이 시작되면 다음 명령을 실행하여 NGINX Ingress Controller를 설치하십시오: 

    helm upgrade --install ingress-nginx ingress-nginx \
--repo https://kubernetes.github.io/ingress-nginx \
--namespace gitlab-managed-apps --create-namespace
   
# 인그레스 컨트롤러가 성공적으로 설치되었는지 확인하십시오
kubectl get service ingress-nginx-controller -n gitlab-managed-apps

Auto DevOps 구성

Auto DevOps에 필요한 기본 도메인 및 설정을 구성하려면 다음 단계를 따르십시오.

  1. NGINX를 설치한 후 몇 분 후에 로드 밸런서가 IP 주소를 획들하고 다음 명령으로 외부 IP 주소를 확인할 수 있습니다: 

    kubectl get service ingress-nginx-controller -n gitlab-managed-apps -ojson | jq -r '.status.loadBalancer.ingress[].ip'

    네임스페이스를 덮어썼다면 해당 네임스페이스로 변경하십시오.

    이 IP 주소를 복사하여 다음 단계에서 사용합니다.

  2. 애플리케이션 프로젝트로 돌아가십시오.
  3. 왼쪽 사이드바에서 설정 > CI/CD를 선택하고 Variables를 확장하십시오.
    • KUBE_INGRESS_BASE_DOMAIN이라는 이름의 키를 추가하고 애플리케이션 배포 도메인을 값으로 설정하십시오. 이 예제에서는 도메인을 <IP 주소>.nip.io로 사용하십시오.
    • KUBE_NAMESPACE라는 이름의 키를 추가하고 배포 대상인 Kubernetes 네임스페이스의 값을 설정하십시오. 환경 별로 다른 네임스페이스를 사용할 수 있습니다. 환경을 구성하고 환경 범위를 사용하십시오.
    • KUBE_CONTEXT라는 이름의 키를 추가하고 <path/to/agent/project>:<agent-name>의 값을 설정하십시오. 선택한 환경 범위를 선택하십시오.
    • 변경 사항 저장을 선택하십시오.

Auto DevOps 활성화 및 파이프라인 실행

자동 DevOps는 기본적으로 활성화되지만, 자동 DevOps를 비활성화할 수도 있습니다. 자동 DevOps를 활성화하려면 다음 단계를 완료하세요.

  1. 왼쪽 사이드바에서 검색 또는 이동을 선택하고 애플리케이션 프로젝트를 찾습니다.
  2. 설정 > CI/CD를 선택합니다.
  3. 자동 DevOps를 확장합니다.
  4. 기본 자동 DevOps 파이프라인으로 전환을 선택하여 더 많은 옵션을 표시합니다.
  5. 배포 전략에서 원하는 지속적 배포 전략을 선택하여 기본 브랜치에서 파이프라인이 성공적으로 실행된 후 애플리케이션을 프로덕션 환경에 배포합니다.
  6. 변경사항 저장을 선택합니다.

  7. .gitlab-ci.yml 파일을 편집하여 Auto DevOps 템플릿을 포함하고 변경 사항을 master 브랜치에 커밋합니다: 

    include:
- template: Auto-DevOps.gitlab-ci.yml

    해당 커밋은 파이프라인을 트리거해야 합니다. 다음 섹션에서 파이프라인의 각 작업이 수행하는 작업에 대해 설명합니다.

애플리케이션 배포

파이프라인이 실행되면, 무엇을 수행하고 있나요?

파이프라인의 작업을 보려면 파이프라인 상태 배지를 선택합니다. 아이콘은 파이프라인 작업이 실행 중일 때 표시되며, 페이지 새로고침 없이 작업이 완료되면 성공() 또는 실패()로 업데이트됩니다.

작업은 다음과 같은 단계로 구분됩니다:

파이프라인 단계

  • 빌드 - 애플리케이션은 Docker 이미지를 빌드하고 해당 이미지를 프로젝트의 컨테이너 레지스트리에 업로드합니다 (자동 빌드).

  • 테스트 - GitLab은 애플리케이션에 여러 가지 확인을 수행하지만, test를 제외한 모든 작업은 테스트 단계에서 실패할 수 있습니다:

    • test 작업은 언어와 프레임워크를 감지하여 단위 및 통합 테스트를 수행합니다 (자동 테스트)
    • code_quality 작업은 코드 품질을 확인하고 실패해도 괜찮습니다 (자동 코드 품질)
    • container_scanning 작업은 Docker 컨테이너에 취약점이 있는지 확인하고 실패해도 괜찮습니다 (자동 컨테이너 스캐닝)
    • dependency_scanning 작업은 취약점이 있는 의존성이 있는지 확인하고 실패해도 괜찮습니다 (자동 의존성 스캐닝)
    • -sast로 끝나는 작업은 현재 코드에 대해 정적 분석을 수행하여 보안 문제를 확인하고 실패해도 괜찮습니다 (자동 SAST)
    • secret-detection 작업은 누출된 비밀을 확인하고 실패해도 괜찮습니다 (자동 비밀 검색)

  • 리뷰 - 기본 브랜치의 파이프라인에는 dast_environment_deploy 작업이 포함됩니다. 자세한 정보는 동적 애플리케이션 보안 테스트(DAST)를 참조하세요.

  • 프로덕션 - 테스트와 확인이 완료되면, 애플리케이션은 Kubernetes에 배포됩니다 (자동 배포).

  • 성능 - 배포된 애플리케이션에 대해 성능 테스트를 수행합니다 (자동 브라우저 성능 테스트).

  • 정리 - 기본 브랜치의 파이프라인에는 stop_dast_environment 작업이 포함됩니다.

파이프라인을 실행한 후에는 배포된 웹사이트를 확인하고 모니터링하는 방법을 배웁니다.

프로젝트 모니터링

애플리케이션을 성공적으로 배포한 후, 운영 > 환경으로 이동하여 환경 페이지에서 애플리케이션의 웹사이트를 확인하고 건강 상태를 확인할 수 있습니다. 이 페이지에는 배포된 애플리케이션에 대한 세부 정보가 표시되며, 우측 열에는 일반적인 환경 작업으로 연결되는 아이콘이 표시됩니다:

환경

  • 실시간 환경 열기 () - 프로덕션 환경에 배포된 애플리케이션의 URL 열기
  • 모니터링 () - Prometheus가 수집한 Kubernetes 클러스터에 대한 데이터가 포함된 메트릭 페이지 열기. 해당 데이터는 애플리케이션의 메모리 사용, CPU 사용 및 지연 시간에 어떤 영향을 미치고 있는지 보여줍니다
  • 배포 대상 선택 ( ) - 배포할 수 있는 환경 디렉터리 표시
  • 터미널 () - 애플리케이션이 실행 중인 컨테이너 내에서 웹 터미널 세션 열기
  • 환경 다시 배포 () - 자세한 정보는 다시 시도 및 롤백을 참조하세요
  • 환경 중지 () - 자세한 정보는 환경 중지을 참조하세요

GitLab은 환경 정보 아래에 배포 보드를 표시합니다. 해당 보드에는 Kubernetes 클러스터의 포드를 나타내는 사각형이 표시되며, 해당 상태를 나타내기 위해 색으로 구분됩니다. 배포 보드의 사각형 위에 마우스를 가져가면 배포 상태가 표시되며, 해당 사각형을 선택하면 포드 로그 페이지로 이동합니다.

note
예시에서는 현재 애플리케이션을 호스팅하는 포드가 하나만 표시되지만, 설정 > CI/CD > 변수에서 REPLICAS CI/CD 변수를 정의하여 포드를 더 추가할 수 있습니다.

브랜치로 작업하기

다음으로, 애플리케이션에 내용을 추가하기 위해 기능 브랜치를 생성합니다:

  1. 프로젝트 리포지터리에서 다음 파일로 이동합니다: app/views/welcome/index.html.erb. 이 파일은 <p>You're on Rails!</p> 단락만 포함해야 합니다.
  2. 변경 사항을 적용하려면 GitLab Web IDE를 엽니다.

  3. 파일을 편집하여 다음 내용을 포함시킵니다: 

    <p>You're on Rails! Powered by GitLab Auto DevOps.</p>

  4. 파일을 stage에 올리고 커밋 메시지를 추가한 후 커밋을 선택하여 새 브랜치와 Merge Request을 생성합니다.

    Web IDE commit

Merge Request을 제출하면, GitLab은 파이프라인 및 해당 파이프라인에 포함된 모든 작업을 실행합니다. 이는 앞서 설명한 대로 기본 브랜치 이외에도 실행하는 몇 가지 추가 작업을 포함합니다.

몇 분 후에 테스트가 실패한다는 것을 확인하면, 이는 변경 사항으로 테스트가 ‘손상’되었음을 의미합니다. 자세한 정보를 확인하려면 실패한 test 작업을 선택하십시오. 

실패:
WelcomeControllerTest#test_should_get_index [/app/test/controllers/welcome_controller_test.rb:7]:
<You're on Rails!> 기대되는데
<You're on Rails! Powered by GitLab Auto DevOps.>..
예상값 0이 1 이상이어야 합니다.
bin/rails test test/controllers/welcome_controller_test.rb:4

손상된 테스트를 수정하려면:

  1. Merge Request으로 돌아갑니다.
  2. 우측 상단에서 코드를 선택한 후 Gitpod에서 열기를 선택합니다.
  3. 파일 디렉터리에서 test/controllers/welcome_controller_test.rb 파일을 찾아 엽니다.
  4. 7번째 줄을 You're on Rails! Powered by GitLab Auto DevOps.로 변경합니다.
  5. 커밋을 선택합니다.
  6. Unstaged changes 아래에서 변경 사항을 stage에 올리기 위해 체크 아이콘()를 선택합니다.
  7. 커밋 메시지를 작성하고 커밋을 선택합니다.

Merge Request의 개요 페이지로 돌아가면 테스트가 통과하고, 리뷰 애플리케이션이 배포된 것을 확인할 수 있습니다. 변경된 내용이 배포된 것을 확인하려면 View app 버튼을 선택하여 리뷰 애플리케이션을 방문할 수 있습니다.

Merge Request을 Merge한 후, GitLab은 기본 브랜치에 대해 파이프라인을 실행한 후 애플리케이션을 프로덕션 환경에 배포합니다.

결론

이 프로젝트를 구현한 후에는 Auto DevOps의 기본을 확실하게 이해해야 합니다. 애플리케이션을 빌드하고 테스트하여 배포하고 모니터링하는 등 모든 작업을 GitLab에서 수행했습니다. 자동화된 성격에도 불구하고, Auto DevOps는 워크플로에 맞게 구성하고 사용자 정의할 수도 있습니다. 아래는 더 읽을 거리를 위한 도움이 되는 자원들입니다:

  1. Auto DevOps
  2. 다중 Kubernetes 클러스터
  3. 프로덕션 환경으로의 점진적 롤아웃
  4. CI/CD 변수를 사용하여 필요없는 작업 비활성화하기
  5. 사용자 정의 빌드팩을 사용하여 애플리케이션 빌드하기