• Google 계정 구성
• Kubernetes 클러스터 생성
• 템플릿에서 새 프로젝트 만들기
• 에이전트 구성
• 인그레스 설치
• Auto DevOps 구성
• Auto DevOps 활성화 및 파이프라인 실행
• 애플리케이션 배포
  • 프로젝트 모니터링
  • 브랜치 사용
• 결론

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

이 튜토리얼에서는 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. 인그레스 설치
6. Auto DevOps 구성
7. Auto DevOps 활성화 및 파이프라인 실행
8. 애플리케이션 배포

Google 계정 구성

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

1. Kubernetes Engine 문서의 “시작하기 전 단계”에 설명된 단계를 따라 필요한 API 및 관련 서비스를 활성화하세요.
2. Google Cloud Platform에서 청구서 계정을 만들었는지 확인하세요.

참고: 새 Google Cloud Platform (GCP) 계정은 $300 크레딧을 받게 되며, Google과 협력하여 GitLab은 Google Kubernetes Engine과의 통합을 시작하기 위해 새로운 GCP 계정에 추가로 $200을 제공할 수 있습니다. 크레딧을 신청하려면 이 링크를 따르세요.

Kubernetes 클러스터 생성

Google Kubernetes Engine (GKE)에서 새 클러스터를 만들려면 구성 관리를 위한 프로젝트 생성 가이드의 단계를 따라 Infrastructure as Code (IaC) 방식을 사용하세요. 이 가이드에서는 Terraform를 사용하여 GKE 클러스터를 만들고 Kubernetes용 GitLab 에이전트를 설치해야 하는 새 프로젝트를 생성해야 합니다.

템플릿에서 새 프로젝트 만들기

GitLab 프로젝트 템플릿을 사용하여 시작하세요. 이름에서 알 수 있듯이, 이러한 프로젝트는 잘 알려진 프레임워크에서 개발된 최소 기능의 애플리케이션을 제공합니다.

경고: 애플리케이션 프로젝트는 클러스터 관리를 위한 프로젝트와 동일한 수준 또는 그 아래에 그룹 계층 구조에 만들어야 합니다. 그렇지 않으면 에이전트를 인가할 수 없습니다.

1. 좌측 사이드바의 상단에서 새로 만들기 () 및 새 프로젝트/저장소 만들기를 선택하세요.
2. 템플릿에서 만들기를 선택하세요.
3. Ruby on Rails 템플릿을 선택하세요.
4. 프로젝트에 이름을 지정하고, 선택적으로 설명을 추가하고, GitLab Ultimate plan에서 제공되는 기능을 활용할 수 있도록 공개로 설정하세요.
5. 프로젝트 만들기를 선택하세요.

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

에이전트 구성

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

1. 클러스터 관리를 위해 만든 프로젝트로 이동하세요.
2. 에이전트 구성 파일(.gitlab/agents/<agent-name>/config.yaml)로 이동하여 파일을 편집하세요.
3. ci_access:projects 속성을 구성하세요. 애플리케이션 프로젝트 경로를 id로 사용하세요.

ci_access:
  projects:
    - id: path/to/application-project

인그레스 설치

클러스터가 실행된 후, 인터넷에서 애플리케이션으로 트래픽을 라우팅하는 로드 밸런서로 NGINX Ingress Controller를 설치해야 합니다. NGINX Ingress Controller는 GitLab 클러스터 관리 프로젝트 템플릿을 통해 또는 Google Cloud Shell로 수동으로 설치할 수 있습니다.

1. 클러스터의 세부 정보 페이지로 이동하여 고급 설정 탭을 선택하세요.
2. Google Kubernetes Engine 링크를 선택하여 Google Cloud 콘솔에서 클러스터를 방문하세요.
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'
   

   namespace를 덮어썼다면 gitlab-managed-apps를 대체하세요.

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

2. 애플리케이션 프로젝트로 돌아갑니다.
3. 왼쪽 사이드바에서 Settings > CI/CD를 선택하고 Variables를 확장합니다.
   • KUBE_INGRESS_BASE_DOMAIN이라는 키를 추가하고, 애플리케이션 배포 도메인을 값으로 사용합니다. 이 예에서는 도메인을 <IP 주소>.nip.io로 사용합니다.
   • KUBE_NAMESPACE라는 키를 추가하고 배포 대상이 되는 Kubernetes 네임스페이스의 값을 입력하세요. 환경에 따라 다른 네임스페이스를 사용할 수 있습니다. 환경을 구성하려면 환경 범위를 사용합니다.
   • KUBE_CONTEXT라는 키를 추가하고 값으로 <path/to/agent/project>:<agent-name>를 입력하세요. 원하는 환경 범위를 선택하세요.
   • Save changes를 선택합니다.

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

Auto DevOps는 기본적으로 활성화되어 있지만, Auto DevOps를 비활성화할 수 있습니다. 기본적으로(자체 호스팅 인스턴스의 경우) 및 그룹 수준에서 Auto DevOps를 활성화하려면 다음 단계를 완료하세요:

1. 왼쪽 사이드바에서 검색 또는 이동을 선택하여 애플리케이션 프로젝트를 찾습니다.
2. Settings > CI/CD를 선택합니다.
3. Auto DevOps를 확장합니다.
4. Default to Auto DevOps pipeline를 선택하여 더 많은 옵션을 표시합니다.
5. 배포 전략에서 원하는 지속적인 배포 전략을 선택하여 기본 브랜치에서 파이프라인 실행이 성공한 후 애플리케이션을 프로덕션에 배포합니다.
6. Save changes를 선택합니다.

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 작업이 포함됩니다. 자세한 정보는 Dynamic Application Security Testing (DAST)를 참조하세요.

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

• 성능 - 배포된 애플리케이션에 대한 성능 테스트가 실행됩니다 (자동 브라우저 성능 테스트).

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

파이프라인을 실행한 후 배포된 웹사이트를 확인하고 모니터링 방법을 학습해야 합니다.

프로젝트 모니터링

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

• 라이브 환경 열기 () - 프로덕션에 배포된 응용 프로그램의 URL 열기
• 모니터링 () - 프로메테우스가 쿠버네티스 클러스터에 대한 데이터를 수집하고 응용 프로그램의 메모리 사용, CPU 사용 및 대기 시간에 미치는 영향을 보여주는 메트릭 페이지 열기
• 환경으로 배포 ( ) - 배포할 수 있는 환경 목록 표시
• 터미널 () - 응용 프로그램이 실행 중인 컨테이너 내에서 웹 터미널 세션 열기
• 환경 재배포 () - 자세한 내용은 다시 시도하거나 되감기를 참조하세요.
• 환경 중지 () - 자세한 내용은 환경 중지하기를 참조하세요.

GitLab은 환경 정보 아래에 배포 보드를 표시하며, 여기에는 쿠버네티스 클러스터의 파드를 나타내는 정사각형이 있고, 상태를 보여주기 위해 색으로 구분되어 있습니다. 배포 보드의 정사각형 위에 마우스를 올리면 배포 상태가 표시되고, 해당 정사각형을 선택하면 파드의 로그 페이지로 이동합니다.

참고: 예제에는 현재 한 가지 파드만 응용 프로그램을 호스팅하고 있는 것으로 표시되지만, 설정 > CI/CD > 변수(Settings > CI/CD > Variables)에서 REPLICAS CI/CD 변수를 정의하여 여러 개의 파드를 추가할 수 있습니다.

브랜치 사용

다음으로, 응용 프로그램에 콘텐츠를 추가하기 위해 피쳐 브랜치를 생성합니다:

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

3. 파일을 수정하여 다음 내용으로 변경하세요:

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

4. 파일을 스테이징합니다. 커밋 메시지를 추가한 다음 커밋(Commit)을 선택하여 새 브랜치와 병합 요청을 생성합니다.

   

병합 요청을 제출한 후, GitLab은 파이프라인과 해당 파이프라인의 모든 작업을 실행하며, 기본 브랜치 이외의 다른 브랜치에서만 실행되는 여러 작업도 실행됩니다.

몇 분 후, 테스트가 실패하여 변경으로 인해 테스트가 ‘망가졌음’을 의미합니다. 실패한 test 작업을 선택하여 관련 정보를 확인할 수 있습니다:

실패:
WelcomeControllerTest#test_should_get_index [/app/test/controllers/welcome_controller_test.rb:7]:
<You're on Rails!> expected but was
<You're on Rails! Powered by GitLab Auto DevOps.>..
Expected 0 to be >= 1.

bin/rails test test/controllers/welcome_controller_test.rb:4

테스트를 수정하려면:

1. 병합 요청으로 돌아갑니다.
2. 오른쪽 상단에서 코드(Code)를 선택한 다음 Gitpod에서 열기(Open in Gitpod)를 선택합니다.
3. 파일 디렉토리에서 test/controllers/welcome_controller_test.rb 파일을 찾아서 선택하여 엽니다.
4. 7번 라인을 You're on Rails! Powered by GitLab Auto DevOps.로 변경합니다.
5. 커밋(Commit)을 선택합니다.
6. 좌측 열에서 스테이징되지 않은 변경 사항(Unstaged changes) 아래에서 확인 표시 아이콘 ()을 선택하여 변경 사항을 스테이징합니다.
7. 커밋 메시지를 작성하고 커밋(Commit)을 선택합니다.

병합 요청의 개요(Overview) 페이지로 돌아가면 테스트가 통과되었을 뿐만 아니라 자동 리뷰 응용 프로그램으로 배포된 응용 프로그램도 볼 수 있어야 합니다. 변경 사항이 반영된 응용 프로그램을 확인하려면 응용 프로그램 보기(View app) 버튼을 선택합니다.

병합 요청을 병합한 후, GitLab은 기본 브랜치에서 파이프라인을 실행하고 응용 프로그램을 프로덕션 환경에 배포합니다.

결론

이 프로젝트를 구현한 후, 당신은 Auto DevOps의 기본을 습득했을 것입니다. GitLab에서 응용 프로그램을 빌드, 테스트, 배포 및 모니터링하는 방법에 대해 이해하게 되었습니다. 자동적인 성격에도 불구하고, Auto DevOps는 워크플로우에 맞게 구성하고 사용자 정의할 수 있습니다. 더 많은 정보를 찾으려면 다음의 유용한 자료가 도움이 될 것입니다:

1. Auto DevOps
2. 다중 쿠버네티스 클러스터
3. 생산 환경으로 점진적 롤아웃
4. CI/CD 변수를 사용하여 필요없는 작업 비활성화
5. 사용자 정의 빌드팩을 사용하여 응용 프로그램 빌드