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

Amazon Elastic Kubernetes Service (EKS)에 애플리케이션을 배포하려면 Auto DevOps를 사용하세요

이 튜토리얼에서는 Auto DevOps를 시작하는 데 도움을 드리겠습니다. Amazon Elastic Kubernetes Service (EKS)에 애플리케이션을 배포하는 방법을 예를 통해 설명합니다.

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

자체 관리 인스턴스에서도 이 튜토리얼을 따를 수 있습니다. 런너가 구성되어 있는지 확인하세요.

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

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

Amazon 계정을 구성합니다

GitLab 프로젝트에 Kubernetes 클러스터를 생성하고 연결하기 전에 Amazon Web Services 계정이 필요합니다. 기존의 Amazon 계정으로 로그인하거나 새 계정을 생성하세요.

Kubernetes 클러스터를 생성하고 배포하세요

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

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

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

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

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

경고: 애플리케이션 프로젝트를 클러스터 관리 프로젝트와 동일 또는 그 이하의 그룹 계층에 만들어야 합니다. 그렇지 않으면 에이전트를 인증하지 못합니다.

왼쪽 사이드바에서 맨 위에 있는 새 프로젝트/저장소 생성 ()를 선택하세요.
템플릿에서 생성을 선택하세요.
Ruby on Rails 템플릿을 선택하세요.
프로젝트에 이름을 지정하고 설명을 추가로 입력한 다음, GitLab Ultimate 요금제에서 사용 가능한 기능을 활용할 수 있도록 공개로 설정하세요.
프로젝트 생성을 선택하세요.

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

에이전트를 구성하세요

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

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

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

인그레스를 설치하세요

클러스터가 운영 중인 경우, 인터넷으로부터 트래픽을 애플리케이션으로 라우팅하기 위해 로드 밸런서로 NGINX 인그레스 컨트롤러를 설치해야 합니다. NGINX 인그레스 컨트롤러를 GitLab 클러스터 관리 프로젝트 템플릿을 통해 설치하거나 명령줄을 통해 수동으로 설치합니다:

머신에 kubectl 및 Helm이 설치되어 있는지 확인하세요.
클러스터에 액세스할 수 있는 IAM 역할을 만드세요.
클러스터에 액세스할 수 있는 액세스 토큰을 생성하세요.

다음 명령어를 사용하여 클러스터에 연결하세요:

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에 필요한 기본 도메인 및 기타 설정을 구성하는 단계를 따르세요.

NGINX를 설치한 후 몇 분 후에 로드 밸런서가 IP 주소를 획들하고 다음 명령어로 외부 IP 주소를 얻을 수 있습니다:
```
kubectl get all -n gitlab-managed-apps --selector app.kubernetes.io/instance=ingress-nginx
```
네임스페이스를 재정의한 경우 gitlab-managed-apps를 변경하세요.
다음 명령으로 클러스터의 실제 외부 IP 주소를 찾으세요:
```
nslookup [외부 IP]
```
[외부 IP]는 이전 명령으로 찾은 호스트 이름입니다.
IP 주소는 응답의 Non-authoritative answer: 섹션에 나열될 수 있습니다.
이 IP 주소를 복사하여 다음 단계에 사용하세요.
애플리케이션 프로젝트로 돌아가세요.
왼쪽 사이드바에서 설정 > CI/CD를 선택하고 변수를 확장하세요.
- KUBE_INGRESS_BASE_DOMAIN이라는 키를 추가하고 애플리케이션 배포 도메인을 값으로 설정하세요. 이 예에서는 <IP 주소>.nip.io 도메인을 사용하세요.
- KUBE_NAMESPACE라는 키를 추가하고 배포 대상의 Kubernetes 네임스페이스를 값으로 설정하세요. 환경 별로 다른 네임스페이스를 사용할 수 있습니다. 환경을 구성하고 환경 범위를 지정하세요.
- KUBE_CONTEXT라는 키를 추가하고 path/to/agent/project:eks-agent와 같은 값을 설정하세요. 사용하려는 환경 범위를 선택하세요.
- 변경 사항 저장을 선택하세요.

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

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

왼쪽 사이드바에서 검색 또는 이동을 선택하고 응용 프로그램 프로젝트를 찾습니다.
설정 > CI/CD를 선택합니다.
자동 DevOps를 펼칩니다.
기본 자동 DevOps 파이프라인으로 설정을 선택하여 더 많은 옵션을 표시합니다.
배포 전략에서 원하는 지속적 배포 전략을 선택하여 기본 브랜치에서 파이프라인이 성공적으로 실행된 후 애플리케이션을 프로덕션 환경에 배포합니다.
변경 사항 저장을 선택합니다.
.gitlab-ci.yml 파일을 편집하여 자동 DevOps 템플릿을 포함하고 변경 사항을 기본 브랜치에 커밋합니다.
```
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 작업이 포함됩니다.

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

프로젝트 모니터링

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

실시간 환경 열기 () - 프로덕션 환경에 배포된 애플리케이션의 URL 열기
모니터링 () - Prometheus가 수집한 Kubernetes 클러스터 및 애플리케이션의 메모리 사용, CPU 사용 및 지연시간과 관련된 데이터를 표시하는 메트릭 페이지 열기
배포 대상 ( ) - 배포할 수 있는 환경 목록 표시
터미널 () - 애플리케이션이 실행 중인 컨테이너 내부의 웹 터미널 세션 열기
환경 다시 배포 () - 추가 정보는 재시도 및 롤백 참조
환경 중지 () - 추가 정보는 환경 중지 참조

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

예제에서는 현재 시점에서 애플리케이션을 호스트하는 하나의 포드만 표시되지만, 설정 > CI/CD > 변수에서 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>
```
파일을 Staging 합니다. 커밋 메시지를 추가한 후 Commit을 선택하여 새 브랜치와 병합 요청을 생성하세요.

병합 요청을 제출한 후에는 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

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

병합 요청으로 돌아갑니다.
오른쪽 상단에서 Code를 선택한 후 Open in Gitpod을 선택하세요.
파일 디렉터리에서 test/controllers/welcome_controller_test.rb 파일을 찾아 선택하여 엽니다.
7번째 라인을 You're on Rails! Powered by GitLab Auto DevOps.로 변경하세요.
Commit을 선택하세요.
Unstaged changes 아래에서 체크마크 아이콘()을 선택하여 변경 사항을 Staging하세요.
커밋 메시지를 작성하고 Commit을 선택하세요.

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

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

결론

본 프로젝트를 구현한 후에 자동 DevOps의 기본 사항에 대해 확실한 이해를 얻을 것입니다. 빌드 및 테스트에서부터 배포 및 모니터링까지 모두 GitLab에서 수행했습니다. 자동적인 성격에도 불구하고, 자동 DevOps는 워크플로우에 맞게 구성 및 사용자 정의할 수도 있습니다. 추가 읽기 자료로 몇 가지 유용한 리소스가 있습니다: