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

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

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

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 계정 구성하기

Kubernetes 클러스터를 생성하고 GitLab 프로젝트에 연결하기 전에 Google Cloud Platform 계정이 필요합니다.

Gmail이나 Google Drive에 접근할 때 사용하는 기존 Google 계정으로 로그인하거나 새 계정을 생성하세요.

1. Kubernetes Engine 문서의 “시작하기 전에” 섹션에서 설명한 단계를 따라 필요한 API 및 관련 서비스를 활성화합니다.

2. Google Cloud Platform에서 청구 계정을 생성했는지 확인합니다.

Kubernetes 클러스터 생성하기

Google Kubernetes Engine(GKE)에서 새 클러스터를 만들려면 Create a Google GKE cluster 가이드의 단계를 따라 IaC(코드로서의 인프라) 접근 방식을 사용하세요.
이 가이드는 GKE 클러스터를 생성하고 Kubernetes용 GitLab 에이전트를 설치하기 위해 Terraform을 사용하는 새 프로젝트를 생성해야 합니다.
이 프로젝트가 GitLab 에이전트의 구성이 위치하는 곳입니다.

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

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

1. 왼쪽 사이드바 상단에서 Create new () 및 New project/repository를 선택합니다.
2. Create from template를 선택합니다.
3. Ruby on Rails 템플릿을 선택합니다.
4. 프로젝트 이름을 정하고 선택적으로 설명을 추가하며, GitLab Ultimate 플랜의 기능을 활용할 수 있도록 공개로 설정합니다.
5. Create project를 선택합니다.

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

에이전트 구성

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

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

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

인그레스 설치

클러스터가 실행 중일 때, 인터넷에서 애플리케이션으로 트래픽을 라우팅하기 위해 로드 밸런서인 NGINX Ingress Controller를 설치해야 합니다. GitLab 클러스터 관리 프로젝트 템플릿 또는 Google Cloud Shell을 사용하여 수동으로 NGINX Ingress Controller를 설치하세요:

1. 클러스터의 세부정보 페이지로 가서 고급 설정 탭을 선택합니다.
2. Google Cloud Console에서 클러스터를 방문할 수 있도록 Google Kubernetes Engine 링크를 선택합니다.
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'
   

   네임스페이스를 덮어쓴 경우 gitlab-managed-apps를 교체하세요.

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

2. 애플리케이션 프로젝트로 돌아갑니다.
3. 왼쪽 사이드바에서 설정 > CI/CD를 선택하고 변수를 확장합니다.
   • 값으로 애플리케이션 배포 도메인을 사용하는 KUBE_INGRESS_BASE_DOMAIN이라는 ключ를 추가합니다. 이 예제에서는 <IP address>.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
   

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

애플리케이션 배포

파이프라인이 실행될 때, 어떤 작업을 수행하고 있나요?

파이프라인의 작업을 보려면, 파이프라인의 상태 배지를 선택하세요.

아이콘은 파이프라인 작업이 실행 중일 때 표시되며, 페이지를 새로 고침하지 않고 작업이 완료되면 (성공) 또는 (실패)로 업데이트됩니다.

작업은 단계별로 나누어집니다:

• Build - 애플리케이션은 Docker 이미지를 빌드하고 이를 프로젝트의 Container Registry로 업로드합니다 (Auto Build).

• Test - GitLab은 애플리케이션에 대해 다양한 검사를 실행하지만, 테스트 단계에서 test 작업을 제외한 모든 작업은 실패할 수 있습니다:

  • test 작업은 언어와 프레임워크를 감지하여 단위 및 통합 테스트를 실행합니다 (Auto Test)

  • code_quality 작업은 코드 품질을 검사하고 실패할 수 있습니다 (Auto Code Quality)

  • container_scanning 작업은 Docker 컨테이너에 취약점이 있는지 확인하고 실패할 수 있습니다 (Auto Container Scanning)

  • dependency_scanning 작업은 애플리케이션이 취약점에 노출될 수 있는 의존성을 가지고 있는지 확인하고 실패할 수 있습니다 (Auto Dependency Scanning)

  • -sast로 끝나는 작업은 현재 코드에 대한 정적 분석을 실행하여 잠재적인 보안 문제를 확인하고 실패할 수 있습니다 (Auto SAST)

  • secret-detection 작업은 누출된 비밀을 검사하고 실패할 수 있습니다 (Auto Secret Detection)

• Review - 기본 브랜치의 파이프라인은 dast_environment_deploy 작업이 포함된 이 단계를 포함합니다. 더 많은 정보는 Dynamic Application Security Testing (DAST) 를 참조하세요.

• Production - 테스트와 검사가 완료되면, 애플리케이션이 Kubernetes에 배포됩니다 (Auto Deploy).

• Performance - 배포된 애플리케이션에 대한 성능 테스트가 실행됩니다 (Auto Browser Performance Testing).

• Cleanup - 기본 브랜치의 파이프라인은 stop_dast_environment 작업이 포함된 이 단계를 포함합니다.

파이프라인 실행 후, 배포된 웹사이트를 확인하고 모니터링하는 방법을 배우세요.

프로젝트 모니터링

애플리케이션을 성공적으로 배포한 후, 웹사이트를 보고 Environments 페이지에서 상태를 확인할 수 있습니다.

이 페이지는 배포된 애플리케이션에 대한 세부정보를 표시하며, 오른쪽 열에는 일반적인 환경 작업에 링크가 있는 아이콘이 표시됩니다:

• Open live environment () - 프로덕션에 배포된 애플리케이션의 URL을 엽니다.

• Monitoring () - Prometheus가 Kubernetes 클러스터 및 애플리케이션의 메모리 사용량, CPU 사용량 및 대기 시간에 대한 데이터를 수집하는 메트릭 페이지를 엽니다.

• Deploy to ( ) - 배포할 수 있는 환경 목록을 표시합니다.

• Terminal () - 애플리케이션이 실행 중인 컨테이너 내에서 웹 터미널 세션을 엽니다.

• Re-deploy to environment () - 더 많은 정보는 Retrying and rolling back에서 확인하세요.

• Stop environment () - 더 많은 정보는 Stopping an environment에서 확인하세요.

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

참고: 예제에서는 현재 애플리케이션을 호스팅하는 하나의 포드만 보여 주고 있지만, Settings > CI/CD > Variables에서 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. 파일을 스테이징합니다. 커밋 메시지를 추가한 후 Commit을 선택하여 새 브랜치와 병합 요청을 생성합니다.

   

병합 요청을 제출한 후, GitLab은 파이프라인과 그 안의 모든 작업을 실행합니다. 그리고 기본 브랜치가 아닌 브랜치에서 실행되는 몇 가지 작업도 추가로 실행됩니다.

몇 분 후, 테스트가 실패하며, 이는 당신의 변경으로 인해 테스트가 ‘깨졌음을’ 의미합니다. 실패한 test 작업을 선택하여 자세한 정보를 확인하세요:

Failure:
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를 선택한 다음, Open in Web IDE를 선택합니다.

3. 왼쪽 파일 디렉터리에서 test/controllers/welcome_controller_test.rb 파일을 찾아 열습니다.

4. 7번째 줄을 You're on Rails! Powered by GitLab Auto DevOps.로 변경합니다.

5. 왼쪽 사이드바에서 Source Control ()를 선택합니다.

6. 커밋 메시지를 작성하고 Commit을 선택합니다.

병합 요청의 개요 페이지로 돌아가면 테스트가 통과하는 것뿐만 아니라, 변경 내용이 배포된 검토 애플리케이션도 확인할 수 있습니다. View app 버튼을 선택하여 배포된 변경 사항을 확인하세요.

병합 요청을 병합한 후, GitLab은 기본 브랜치에서 파이프라인을 실행하고, 애플리케이션을 프로덕션에 배포합니다.

결론

이 프로젝트를 구현한 후, Auto DevOps의 기본 사항에 대한 확고한 이해를 가지게 되었을 것입니다. GitLab에서 빌드 및 테스트, 배포 및 모니터링하는 것으로 시작했습니다. 자동화된 특성과 더불어, Auto DevOps는 또한 당신의 워크플로우에 맞게 구성 및 사용자 정의할 수 있습니다. 추가적인 읽기를 위한 유용한 리소스는 다음과 같습니다:

1. Auto DevOps
2. 여러 Kubernetes 클러스터
3. 프로덕션에 대한 점진적인 롤아웃
4. 필요하지 않은 작업을 CI/CD 변수로 비활성화하기
5. 자신의 빌드팩을 사용하여 애플리케이션 빌드하기