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

이 튜토리얼에서는 Auto DevOps를 사용하여 Amazon Elastic Kubernetes Service (EKS)에 애플리케이션을 배포하는 예제를 통해 시작하는 방법을 안내합니다.

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

자체 호스팅된 인스턴스에서도 이 튜토리얼을 따를 수 있습니다. 러너(runner)가 구성되었는지 확인하세요.

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

  1. Amazon 계정 구성
  2. Kubernetes 클러스터 생성 및 에이전트 배포
  3. 템플릿에서 새 프로젝트 생성
  4. 에이전트 구성
  5. Ingress 설치
  6. Auto DevOps 구성
  7. Auto DevOps 활성화 및 파이프라인 실행
  8. 애플리케이션 배포

Amazon 계정 구성

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

Kubernetes 클러스터 생성

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

선호하는 경우 eksctl을 사용하여 매뉴얼으로 클러스터를 생성할 수도 있습니다.

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

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

caution
응용 프로그램 프로젝트를 만든 프로젝트와 동일한 수준 또는 그 아래에 그룹 계층 구조에 만들어야 합니다. 그렇지 않으면 에이전트를 승인할 수 없습니다.
  1. 왼쪽 사이드바에서 상단에 있는 Create new () 및 New project/repository를 선택하세요.
  2. 템플릿에서 만들기를 선택하세요.
  3. Ruby on Rails 템플릿을 선택하세요.
  4. 프로젝트에 이름을 지정하고, 선택적으로 설명을 추가하고, GitLab Ultimate plan에서 제공되는 기능을 활용할 수 있도록 공개로 설정하세요.
  5. 프로젝트 만들기를 선택하세요.

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

에이전트 구성

다음으로 GitLab Kubernetes 에이전트를 구성하여 애플리케이션 프로젝트를 배포하는 데 사용할 수 있도록 설정할 것입니다.

  1. 클러스터 관리를 위해 만든 프로젝트로 이동하세요.
  2. 에이전트 구성 파일 수정 하세요(.gitlab/agents/eks-agent/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를 통해 또는 명령줄을 통해 매뉴얼으로 설치할 수 있습니다.

  1. 로컬 머신에 kubectl 및 Helm이 설치되어 있는지 확인하세요.
  2. 클러스터에 액세스하기 위해 IAM 역할을 생성하세요.
  3. 클러스터에 액세스할 수 있는 액세스 토큰을 생성하세요.

  4. 클러스터에 연결하기 위해 kubectl을 사용하세요: 

    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 all -n gitlab-managed-apps --selector app.kubernetes.io/instance=ingress-nginx

    네임스페이스를 덮어썼다면 gitlab-managed-apps을 사용하세요.

    다음 명령을 사용하여 클러스터의 실제 외부 IP 주소를 찾으세요: 

    nslookup [외부 IP]

    [외부 IP]는 이전 명령에서 찾은 호스트명입니다.

    IP 주소는 응답의 Non-authoritative answer: 섹션에 나올 수 있습니다.

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

  2. 애플리케이션 프로젝트로 돌아가세요.
  3. 왼쪽 사이드바에서 Settings > CI/CD를 선택하고 Variables을 확장하세요.
    • 애플리케이션 배포 도메인을 값을로 하는 KUBE_INGRESS_BASE_DOMAIN 키를 추가하세요. 이 예에서는 도메인 <IP 주소>.nip.io를 사용하세요.
    • 배포할 Kubernetes 네임스페이스를 값으로 하는 KUBE_NAMESPACE 키를 추가하세요. 환경에 따라 서로 다른 네임스페이스를 사용할 수 있습니다. 환경을 구성하려면 환경 범위를 사용하세요.
    • path/to/agent/project:eks-agent와 같은 값을 가지는 KUBE_CONTEXT 키를 추가하세요. 원하는 환경 범위를 선택하세요.
    • Save changes를 선택하세요.

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

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

  1. 왼쪽 사이드바에서 검색 또는 이동하여 찾기를 선택하고 애플리케이션 프로젝트를 찾으세요.
  2. Settings > CI/CD를 선택하세요.
  3. Auto DevOps를 확장하세요.
  4. 자동 배포 전략에서 연속 배포 전략을 선택하여 기본 브랜치에서 파이프라인이 성공적으로 실행된 후 애플리케이션을 프로덕션에 배포하세요.
  5. Save changes를 선택하세요.

  6. .gitlab-ci.yml 파일을 편집하여 Auto DevOps 템플릿을 포함시키고 기본 브랜치에 변경 사항을 커밋하세요: 

    include:
- template: Auto-DevOps.gitlab-ci.yml

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

애플리케이션 배포

파이프라인이 실행될 때 무엇이 발생하는지 확인하세요.

파이프라인의 작업을 보려면 파이프라인 상태 배지를 선택하세요. 파이프라인 작업이 실행 중을 나타내는 아이콘이 표시되며, 작업이 완료되면 페이지를 새로 고치지 않고 자동으로 (성공) 또는 (실패)로 업데이트됩니다.

작업은 다음 단계로 나뉩니다:

파이프라인 단계

  • 빌드: 애플리케이션이 도커 이미지를 빌드하고 프로젝트의 컨테이너 레지스트리(자동 빌드)에 업로드합니다.

  • 테스트: GitLab은 애플리케이션에 다양한 체크를 실시하지만 test 외의 모든 작업은 실패할 수 있습니다:

    • test 작업은 언어 및 프레임워크를 감지하여 단위 및 통합 테스트를 실행합니다(자동 테스트).
    • code_quality 작업은 코드 품질을 확인하고 실패해도 됩니다(자동 코드 품질).
    • container_scanning 작업은 Docker 컨테이너에 취약점이 있는지 확인하고 실패해도 됩니다(자동 컨테이너 스캐닝).
    • dependency_scanning 작업은 취약점이 있는 의존성이 있는지 확인하고 실패해도 됩니다(자동 의존성 스캐닝).
    • -sast로 끝나는 작업은 현재 코드에 대한 정적 분석을 실행하여 잠재적인 보안 문제를 확인하고 실패해도 됩니다(자동 SAST).
    • secret-detection 작업은 누출된 비밀번호를 확인하고 실패해도 됩니다(자동 Secret Detection).

  • 리뷰: 기본 브랜치의 파이프라인에는 dast_environment_deploy 작업이 포함됩니다. 자세한 내용은 동적 애플리케이션 보안 테스트(DAST)를 참조하세요.

  • 프로덕션: 테스트와 체크가 완료된 후, 애플리케이션이 Kubernetes에 배포됩니다(자동 배포).

  • 성능: 배포된 애플리케이션에서 성능 테스트가 실행됩니다(자동 브라우저 성능 테스트).

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

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

프로젝트 모니터링

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

환경

  • 실시간 환경 열기 () - 프로덕션에 배포된 애플리케이션의 URL 열기
  • 모니터링 () - 프로메테우스가 수집한 데이터를 표시하는 메트릭 페이지 열기. 이 페이지에는 쿠버네티스 클러스터와 애플리케이션의 메모리 사용, CPU 사용 및 지연에 대한 정보가 표시됨
  • 배포 대상 ( ) - 배포할 수 있는 환경 디렉터리 표시
  • 터미널 () - 애플리케이션이 실행 중인 컨테이너 내에서 웹 터미널 세션 열기
  • 환경 재배포 () - 자세한 내용은 다시 시도 및 롤백을 참조하세요
  • 환경 중지 () - 자세한 내용은 환경 중지을 참조하세요

GitLab은 환경에 대한 배포 보드를 표시하며, 여기에는 귀하의 쿠버네티스 클러스터 내의 pod을 나타내는 사각형이 표시되며, 상태를 보여주기 위해 색으로 코드화됩니다. 배포 보드에서 사각형 위로 마우스를 가져가면 배포의 상태가 표시되고, 해당 사각형을 선택하면 pod 로그 페이지로 이동합니다.

현재 예시에서는 현재 한 개의 pod이 애플리케이션을 호스팅하고 있지만, 설정 > CI/CD > 변수에서 REPLICAS CI/CD 변수를 정의하여 더 많은 pod을 추가할 수 있습니다.

브랜치 처리

다음으로, 애플리케이션에 콘텐츠를 추가하기 위해 피처 브랜치를 생성하세요:

  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. 파일을 스테이징합니다. 커밋 메시지를 추가한 다음 커밋을 선택하여 새 브랜치 및 Merge Request을 생성합니다.

    Web IDE 커밋

Merge Request을 제출한 후, 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보다 크거나 같음이 예상되었지만 0입니다.

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

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

  1. Merge Request으로 돌아갑니다.
  2. 오른쪽 상단에서 코드를 선택한 다음 Gitpod에서 열기를 선택합니다.
  3. 파일 디렉터리에서 test/controllers/welcome_controller_test.rb 파일을 찾아 엽니다.
  4. 7번째 줄을 You're on Rails! Powered by GitLab Auto DevOps.로 수정합니다.
  5. 커밋을 선택합니다.
  6. 스테이징되지 않은 변경 사항 아래에서 변경 사항을 스테이징하기 위해 체크 표시 아이콘 ()를 선택합니다.
  7. 커밋 메시지를 작성한 다음 커밋을 선택합니다.

Merge Request의 개요 페이지로 돌아가면 테스트가 통과하고 리뷰 애플리케이션으로 애플리케이션이 배포되었음을 확인할 수 있습니다. 변경 사항이 배포된 것을 확인하기 위해 애플리케이션 보기() 버튼을 선택할 수 있습니다.

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

결론

이 프로젝트를 구현한 후, Auto DevOps의 기본 사항에 대해 soli한 이해를 얻을 것입니다. GitLab에서 애플리케이션을 빌드, 테스트, 배포 및 모니터링하는 과정을 시작으로, Auto DevOps는 자동적인 특성에도 불구하고 사용자의 워크플로우에 맞게 구성 및 사용자 정의할 수 있습니다. 추가 독서를 위한 유용한 자료는 다음과 같습니다:

  1. Auto DevOps
  2. 다중 쿠버네티스 클러스터
  3. 프로덕션으로 점진적 롤아웃
  4. 필요하지 않은 작업들을 CI/CD 변수로 비활성화
  5. 사용자 정의 빌드팩을 사용하여 응용 프로그램 빌드