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

Auto DevOps를 사용하여 애플리케이션을 Amazon Elastic Kubernetes Service (EKS)에 배포하기

이 튜토리얼에서는 Auto DevOps를 통해 Amazon Elastic Kubernetes Service (EKS)에 애플리케이션을 배포하는 방법을 예제로 소개합니다.

이 튜토리얼은 GitLab의 네이티브 Kubernetes 통합을 사용하므로 AWS 콘솔을 사용하여 Kubernetes 클러스터를 수동으로 생성할 필요가 없습니다.

자신의 관리되는 인스턴스에서도 이 튜토리얼을 따를 수 있습니다.

자신의 러너를 구성하세요.

EKS에 프로젝트를 배포하려면:

Amazon 계정을 구성하세요
Kubernetes 클러스터를 생성하고 에이전트를 배포하세요
템플릿에서 새 프로젝트를 생성하세요
에이전트를 구성하세요
Ingress 설치하기
Auto DevOps 구성하기
Auto DevOps 활성화 및 파이프라인 실행하기
애플리케이션 배포하기

Amazon 계정 구성하기

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

기존 Amazon 계정으로 로그인하거나 새 계정을 생성하세요.

Kubernetes 클러스터 생성하기

Amazon EKS에서 새 클러스터를 생성하려면:

Amazon EKS 클러스터 생성하는 단계를 따르세요.

원하는 경우 eksctl을 사용하여 클러스터를 수동으로 생성할 수도 있습니다.

템플릿에서 애플리케이션 프로젝트 만들기

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

경고:
애플리케이션 프로젝트를 클러스터 관리 프로젝트와 동일한 수준 또는 그 이하의 그룹 계층에 생성하세요. 그렇지 않으면 에이전트를 승인하는 데 실패합니다.

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

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

에이전트 구성하기

다음으로, 애플리케이션 프로젝트를 배포하기 위해 Kubernetes에 대한 GitLab 에이전트를 구성하겠습니다.

클러스터 관리 프로젝트를 위해 생성한 프로젝트로 이동합니다.
에이전트 구성 파일(.gitlab/agents/eks-agent/config.yaml)로 이동하여 편집합니다.
ci_access:projects 속성을 구성합니다. 애플리케이션 프로젝트 경로를 id로 사용하세요:
```
ci_access:
  projects:
    - id: path/to/application-project
```

Ingress 설치하기

클러스터가 실행된 후, 애플리케이션으로 인터넷에서의 트래픽을 라우팅하기 위해 로드 밸런서로 NGINX Ingress Controller를 설치해야 합니다.

NGINX Ingress Controller를 GitLab 클러스터 관리 프로젝트 템플릿을 통해 설치하거나, 명령줄을 통해 수동으로 설치할 수 있습니다:

자신의 머신에 kubectl과 Helm이 설치되어 있는지 확인하세요.
클러스터에 접근하기 위한 IAM 역할을 생성합니다.
클러스터에 접근하기 위한 액세스 토큰을 생성합니다.

kubectl을 사용하여 클러스터에 연결합니다:

helm upgrade --install ingress-nginx ingress-nginx \
--repo https://kubernetes.github.io/ingress-nginx \
--namespace gitlab-managed-apps --create-namespace

# Ingress 컨트롤러가 성공적으로 설치되었는지 확인합니다
kubectl get service ingress-nginx-controller -n gitlab-managed-apps

자동 DevOps 구성

자동 DevOps에 필요한 기본 도메인 및 기타 설정을 구성하려면 다음 단계를 따르세요.

NGINX를 설치한 몇 분 후, 로드 밸런서가 IP 주소를 얻으며, 다음 명령어로 외부 IP 주소를 확인할 수 있습니다:
```
kubectl get all -n gitlab-managed-apps --selector app.kubernetes.io/instance=ingress-nginx
```
네임스페이스를 덮어쓴 경우 gitlab-managed-apps를 교체하세요.

다음으로, 다음 명령어를 사용하여 클러스터의 실제 외부 IP 주소를 찾습니다:
```
nslookup [External IP]
```
여기서 [External IP]는 이전 명령어로 찾은 호스트 이름입니다.

IP 주소는 응답의 비권위적 응답: 섹션에 나열될 수 있습니다.

다음 단계에서 필요하므로 이 IP 주소를 복사하세요.
애플리케이션 프로젝트로 돌아갑니다.
왼쪽 사이드바에서 Settings > CI/CD를 선택하고 Variables를 확장합니다.
- 애플리케이션 배포 도메인을 값으로 가지는 KUBE_INGRESS_BASE_DOMAIN이라는 키를 추가합니다. 이 예제에서는 도메인 <IP address>.nip.io를 사용하세요.
- 배포를 목표로 하는 쿠버네티스 네임스페이스의 값을 가지는 KUBE_NAMESPACE라는 키를 추가합니다. 각 환경에 대해 다른 네임스페이스를 사용할 수 있습니다. 환경을 구성하고 환경 범위를 사용하세요.
- path/to/agent/project:eks-agent와 같은 값을 가지는 KUBE_CONTEXT라는 키를 추가합니다. 원하시는 환경 범위를 선택하세요.
- 변경 사항 저장을 선택합니다.

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

자동 DevOps는 기본적으로 활성화되어 있지만, 전체 인스턴스(자체 관리 인스턴스의 경우) 및 개별 그룹에 대해 비활성화할 수 있습니다. 비활성화된 경우 자동 DevOps를 활성화하려면 다음 단계를 완료하세요:

왼쪽 사이드바에서 Search or go to를 선택하고 애플리케이션 프로젝트를 찾습니다.
Settings > CI/CD를 선택합니다.
Auto DevOps를 확장합니다.
Default to Auto DevOps pipeline을 선택하여 추가 옵션을 표시합니다.
배포 전략에서 원하는 지속적인 배포 전략을 선택하여 파이프라인이 기본 브랜치에서 성공적으로 실행된 후 애플리케이션을 프로덕션에 배포합니다.
변경 사항 저장을 선택합니다.
.gitlab-ci.yml 파일을 편집하여 Auto DevOps 템플릿을 포함하고 기본 브랜치에 변경 사항을 커밋합니다:
```
include:
- template: Auto-DevOps.gitlab-ci.yml
```

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

애플리케이션 배포

파이프라인이 실행될 때, 무엇을 하고 있나요?

파이프라인의 작업을 보려면 파이프라인 상태 배지를 선택합니다.

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

작업은 다음 단계로 나뉘어집니다:

Build - 애플리케이션이 Docker 이미지를 빌드하고 이를 프로젝트의 컨테이너 레지스트리로 업로드합니다 (자동 빌드).
Test - GitLab이 애플리케이션에 대해 다양한 검사를 수행하지만, test를 제외한 모든 작업은 테스트 단계에서 실패할 수 있습니다:
- test 작업은 언어와 프레임워크를 감지하여 단위 및 통합 테스트를 실행합니다 (자동 테스트).
- code_quality 작업은 코드 품질을 검사하며 실패할 수 있습니다 (자동 코드 품질).
- container_scanning 작업은 Docker 컨테이너에 취약점이 있는지 검사하며 실패할 수 있습니다 (자동 컨테이너 스캐닝).
- dependency_scanning 작업은 애플리케이션에 취약할 수 있는 의존성이 있는지 검사하며 실패할 수 있습니다 (자동 의존성 스캐닝).
- -sast로 끝나는 작업은 현재 코드에 대해 잠재적인 보안 문제를 확인하기 위해 정적 분석을 실행하며 실패할 수 있습니다 (자동 SAST).
- secret-detection 작업은 유출된 비밀을 검사하며 실패할 수 있습니다 (자동 비밀 탐지).
Review - 기본 브랜치의 파이프라인에는 dast_environment_deploy 작업이 포함된 이 단계가 포함됩니다. 보다 자세한 내용은 동적 애플리케이션 보안 테스트(DAST)를 참조하세요.
Production - 테스트와 검사가 완료된 후, 애플리케이션이 Kubernetes에 배포됩니다 (자동 배포).
Performance - 배포된 애플리케이션에 대해 성능 테스트가 실행됩니다 (자동 브라우저 성능 테스트).
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 변수를 정의하여 더 많은 파드를 추가할 수 있습니다.

브랜치 작업하기

다음으로, 응용 프로그램에 내용을 추가하기 위해 기능 브랜치를 만듭니다:

프로젝트의 리포지토리에서 다음 파일로 이동합니다: app/views/welcome/index.html.erb.
이 파일은 단지 하나의 단락만 포함해야 합니다: <p>You're on Rails!</p>.
변경을 하기 위해 GitLab Web IDE를 엽니다.

파일을 다음과 같이 수정합니다:

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

파일을 스테이징합니다. 커밋 메시지를 추가한 후, 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

깨진 테스트를 수정하려면:

병합 요청으로 돌아갑니다.
오른쪽 상단에서 Code를 선택한 후, Open in Web IDE를 선택합니다.
왼쪽 파일 디렉토리에서 test/controllers/welcome_controller_test.rb 파일을 찾아 선택하여 엽니다.
7번째 줄을 You're on Rails! Powered by GitLab Auto DevOps.로 변경합니다.
왼쪽 사이드바에서 Source Control ()을 선택합니다.
커밋 메시지를 작성하고 Commit을 선택합니다.

병합 요청의 Overview 페이지로 돌아가면 테스트가 통과할 뿐만 아니라 응용 프로그램이 리뷰 응용 프로그램으로 배포된 것을 확인할 수 있습니다. View app 버튼을 선택하여 배포된 변경 사항을 볼 수 있습니다.

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

결론

이 프로젝트를 구현한 후, Auto DevOps의 기본 개념을 확실히 이해하게 될 것입니다.

어플리케이션을 구축하고 테스트하는 것에서부터 배포 및 모니터링까지 모든 과정이 GitLab 내에서 이루어집니다.

자동화의 특성에도 불구하고, Auto DevOps는 당신의 작업 흐름에 맞게 구성하고 사용자 정의할 수 있습니다.

다음은 추가 학습을 위한 유용한 자료입니다: