Amazon 계정 구성
Kubernetes 클러스터 생성
템플릿에서 새 프로젝트 생성
에이전트 구성
Ingress 설치
Auto DevOps 구성
Auto 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 계정 구성

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

Kubernetes 클러스터 생성

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

Amazon EKS 클러스터 생성의 단계를 따르십시오.

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

템플릿에서 새 프로젝트 생성

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

경고: 애플리케이션 프로젝트를 클러스터 관리 프로젝트와 동일한 수준 또는 그 아래의 그룹 계층 구조에 생성하십시오. 그렇지 않으면 에이전트를 승인하지 못할 수 있습니다.

왼쪽 사이드바에서 맨 위에서 새로 만들기() 및 새 프로젝트/저장소를 선택하십시오.
템플릿에서 생성을 선택하십시오.
Ruby on Rails 템플릿을 선택하십시오.
프로젝트에 이름과 선택적으로 설명을 작성하고, GitLab Ultimate 프로젝트에서 제공되는 기능을 활용할 수 있도록 프로젝트를 공개로 설정하십시오.
프로젝트 생성을 선택하십시오.

이제 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 역할을 생성하십시오.
클러스터에 액세스할 액세스 토큰을 생성하십시오.

다음 명령을 사용하여 클러스터에 연결하십시오:

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 [External 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 활성화 및 파이프라인 실행

Auto DevOps는 기본적으로 활성화되어 있지만, (셀프 관리 형 인스턴스의 경우) 전체 인스턴스 및 개별 그룹에 대해 비활성화할 수 있습니다. Auto DevOps를 비활성화한 경우 다음 단계를 따라 Auto DevOps를 활성화하십시오:

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

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

프로젝트 모니터링

애플리케이션을 성공적으로 배포한 후 운영 > 환경을 통해 웹사이트를 확인하고 건강 상태를 확인할 수 있습니다. 이 페이지에는 배포된 응용 프로그램에 대한 세부 정보가 표시되며, 오른쪽 열에는 마우스를 가져다 놓으면 공통 환경 작업으로 연결되는 아이콘들이 표시됩니다:

실시간 환경 열기 () - 프로덕션에 배포된 응용 프로그램의 URL 열기
모니터링 () - 프로메테우스가 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>

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

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

손상된 테스트를 수정하려면:

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

합병 요청의 개요 페이지로 돌아가면 테스트가 통과하지만, 애플리케이션이 리뷰 애플리케이션으로 배포되었음을 확인할 수 있습니다. 이를 통해 배포된 변경 사항을 확인할 수 있습니다.

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

결론

이 프로젝트를 구현한 후에는 Auto DevOps의 기본에 대해 탄탄한 이해를 가져야 합니다. 애플리케이션을 빌드하고 테스트하며 배포하고 모니터링하는 과정을 GitLab에서 모두 시작했습니다. 자동화된 성격에도 불구하고, Auto DevOps는 워크플로우에 맞게 구성하고 사용자 정의할 수도 있습니다. 더 읽을 자료를 찾으시려면 다음 목록을 참고하세요: