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

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

이 튜토리얼에서는 Auto DevOps를 사용하여 Google Kubernetes Engine (GKE)에 애플리케이션을 배포하는 예제를 통해 시작하는 데 도움을 드립니다.

당신은 GitLab 내장 Kubernetes 통합을 사용하고 있으므로 Google Cloud Platform 콘솔을 사용하여 수동으로 Kubernetes 클러스터를 생성할 필요가 없습니다. GitLab 템플릿에서 생성한 애플리케이션을 만들고 배포하고있습니다.

이 지침은 자체 관리 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 계정이 필요합니다. 기존의 Google 계정(예: Gmail 또는 Google 드라이브에 사용하는 계정)으로 로그인하거나 새 계정을 만들어야합니다.

1. Kubernetes Engine 설명서의 “시작하기 전 단계” 섹션에 설명된 단계를 따라 필요한 API 및 관련 서비스를 활성화합니다.
2. Google Cloud Platform에서 청구 계정을 생성했는지 확인합니다.

참고: 새 Google Cloud Platform(GCP) 계정마다 $300의 크레딧을 받을 수 있으며, Google과의 협력을 통해 GitLab은 Google Kubernetes Engine과의 통합을 시작하는 데 추가 $200를 제공할 수 있습니다. 이 링크를 따라가 신용을 신청하세요.

Kubernetes 클러스터 생성

Google Kubernetes Engine (GKE)에서 새 클러스터를 만들려면 Infrastructure as Code (IaC) 접근 방식을 사용하여 Terraform을 사용하여 GKE 클러스터를 만들고 Kubernetes를 위한 GitLab 에이전트를 설치하는 새 프로젝트를 만드는 단계를 Google GKE 클러스터 생성 가이드에서 따릅니다. 이 프로젝트는 GitLab 에이전트의 구성이 있는 곳입니다.

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

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

경고: 애플리케이션 프로젝트는 Terraform이 사용되어 GKE 클러스터를 만들고 GitLab 에이전트를 설치하는 프로젝트와 동일한 수준이거나 아래에있는 그룹 계층에서 생성하십시오. 그렇지 않으면 에이전트를 승인하는 데 실패합니다.

1. 왼쪽 사이드바의 맨 위에서 새로 만들기()와 새 프로젝트/저장소 만들기를 선택합니다.
2. 템플릿에서 만들기를 선택합니다.
3. Ruby on Rails 템플릿을 선택합니다.
4. 프로젝트에 이름을 지정하고 선택적으로 설명을 추가 한 다음, 특징을 활용하기 위해 공개 설정을 선택합니다GitLab Ultimate plan에서 제공되는 기능 이용하기 위해 공개 설정을 선택합니다.
5. 프로젝트 만들기를 선택합니다.

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

에이전트 구성

이제 애플리케이션 프로젝트를 배포하기 위해 Kubernetes용 GitLab 에이전트를 구성해야합니다.

1. 클러스터를 관리하려고 만든 프로젝트로 이동합니다.
2. [에이전트 구성 파일]((../../../user/clusters/agent/install/index.md#create-an-agent-configuration-file) (.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 Cluster management project template를 사용하거나 Google Cloud Shell에서 수동으로 실행하십시오:

1. 클러스터 세부 정보 페이지로 이동하여 고급 설정 탭을 선택합니다.
2. Google Kubernetes Engine 링크를 선택하여 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'
   

   namespace를 덮어쓴 경우 gitlab-managed-apps를 대체하십시오.

   다음 단계에서 이 IP 주소가 필요합니다.

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

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

기본적으로 Auto DevOps가 활성화되어 있지만, 자체 관리 인스턴스의 경우 Auto DevOps를 비활성화할 수 있습니다. 그렇다면 Auto DevOps를 비활성화했다면 다음 단계를 완료하여 활성화하세요:

1. 왼쪽 사이드바에서 검색 또는 이동을 선택하고 응용 프로그램 프로젝트를 찾습니다.
2. 설정 > CI/CD를 선택합니다.
3. Auto DevOps를 확장합니다.
4. 기본값으로 Auto 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 작업을 포함합니다. 자세한 내용은 Dynamic Application Security Testing (DAST)를 참조하십시오.

• 프로덕션 - 테스트와 확인이 완료된 후 응용 프로그램은 Kubernetes에 배포됩니다 (자동 배포).

• 성능 - 배포된 응용 프로그램에 대해 성능 테스트를 실행합니다 (자동 브라우저 성능 테스트).

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

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

프로젝트 모니터링

응용 프로그램을 성공적으로 배포한 후 운영 > 환경으로 이동하여 웹사이트를 확인하고 건강 상태를 확인할 수 있습니다. 이 페이지에서는 배포된 응용 프로그램에 대한 세부 정보를 표시하며, 오른쪽 열은 일반적인 환경 작업으로 연결되는 아이콘을 표시합니다:

• 실시간 환경 열기 () - 프로덕션에 배포된 응용 프로그램의 URL을 엽니다.
• 모니터링 () - Prometheus가 클러스터 및 해당 응용 프로그램의 메모리 사용, CPU 사용 및 대기시간에 영향을 미치는 데이터를 수집하는 지표 페이지를 엽니다.
• 배포 대상 ( ) - 배포할 수 있는 환경 목록을 표시합니다.
• 터미널 () - 응용 프로그램이 실행 중인 컨테이너 내에서 웹 터미널 세션이 열립니다.
• 환경에 재배포 () - 자세한 내용은 다시 시도하고 롤백하기를 참조하십시오.
• 환경 중지 () - 자세한 내용은 환경 중지를 참조하십시오.

GitLab은 환경 정보 아래에 배포 보드를 표시합니다. 이 보드는 쿠버네티스 클러스터의 팟을 나타내는 정사각형을 나타내며 상태를 나타내도록 색상이 부여됩니다. 배포 보드의 정사각형 위로 마우스를 올리면 배포 상태가 표시되며, 정사각형을 선택하면 팟 로그 페이지로 이동합니다.

참고: 예시에서 현재 한 개의 팟이 응용 프로그램을 호스트하고 있지만, 설정 > 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. 파일을 스테이징합니다. 커밋 메시지를 추가하고, 커밋을 선택하여 새 브랜치를 생성하고 머지 요청을 생성합니다.

   

머지 요청을 제출하면 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.>..
1 이상이어야 함을 예상했습니다.

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

오류를 수정하려면:

1. 머지 요청으로 돌아갑니다.
2. 오른쪽 상단에서 코드를 선택하고 웹 IDE에서 열기를 선택합니다.
3. 파일 디렉토리에서 test/controllers/welcome_controller_test.rb 파일을 찾아 선택하여 엽니다.
4. 7행을 You're on Rails! Powered by GitLab Auto DevOps.로 변경합니다.
5. 왼쪽 사이드바에서 소스 제어 ()를 선택합니다.
6. 커밋 메시지를 작성하고, 커밋을 선택합니다.

머지 요청의 개요 페이지로 돌아가면 테스트가 통과되었고 변경 내용이 리뷰 응용 프로그램으로 배포되었음을 볼 수 있습니다. 변경 사항이 배포된 것을 보려면 응용 프로그램 보기 버튼을 선택하여 방문할 수 있습니다.

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

결론

이 프로젝트를 구현한 후에는 Auto DevOps의 기본에 대해 solide한 이해를 가져야 합니다.
빌드하고 테스트한 다음 응용 프로그램을 배포하고 모니터링하는 등의 모든 것을 GitLab에서 수행했습니다.
자동화된 특성에도 불구하고, Auto DevOps를 워크플로에 맞게 구성하고 사용자화할 수도 있습니다.
더 읽을 거리에 대한 유용한 자료들은 다음과 같습니다:

1. Auto DevOps
2. 다중 Kubernetes 클러스터
3. 생산 증분 배포
4. 필요하지 않은 작업 비활성화하기 - CI/CD 변수 사용
5. 자체 빌드팩 사용하여 응용 프로그램 빌드하기