Auto DevOps 스테이지

Tier: Free, Premium, Ultimate Offering: GitLab.com, Self-Managed, GitLab Dedicated

다음 섹션들은 Auto DevOps의 스테이지를 설명합니다. 각각이 어떻게 작동하는지 이해하기 위해 주의 깊게 읽어보세요.

자동 빌드

note
오프트코어 클러스터와 같이 GitLab 러너에서 Docker in Docker를 사용할 수 없는 경우 Auto Build는 지원되지 않습니다. GitLab의 OpenShift 지원은 전용 에픽에서 추적됩니다.

Auto Build는 기존의 Dockerfile이나 Heroku 빌드팩을 사용하여 애플리케이션의 빌드를 생성합니다. 결과 Docker 이미지는 커밋 SHA나 태그와 함께 컨테이너 레지스트리에 푸시됩니다.

Dockerfile을 사용한 Auto Build

프로젝트 리포지터리에 Dockerfile이 포함되어 있는 경우, Auto Build는 docker build를 사용하여 Docker 이미지를 생성합니다.

또한 Auto Review Apps 및 Auto Deploy를 사용하고 자체 Dockerfile을 제공하는 경우, 다음 중 하나를 해야 합니다:

클라우드 네이티브 빌드팩을 사용한 Auto Build

Auto Build는 프로젝트의 Dockerfile이 있는 경우 해당 파일을 사용하여 애플리케이션을 빌드합니다. Dockerfile이 없는 경우, Auto Build는 Cloud Native Buildpacks를 사용하여 애플리케이션을 감지하고 빌드하여 Docker 이미지로 만듭니다. 이 기능은 pack 명령을 사용합니다. 기본 빌더는 heroku/buildpacks:18이지만 CI/CD 변수 AUTO_DEVOPS_BUILD_IMAGE_CNB_BUILDER를 사용하여 다른 빌더를 선택할 수 있습니다.

각 빌드팩은 애플리케이션을 성공적으로 빌드하기 위해 프로젝트 리포지터리에 특정 파일을 포함해야 합니다. 구조는 선택한 빌더와 빌드팩에 따라 다릅니다. 예를 들어, 기본값인 Heroku 빌더를 사용하는 경우, 애플리케이션의 루트 디렉터리에 해당 언어에 대한 적절한 파일이 있어야 합니다:

  • Python 프로젝트의 경우, Pipfile 또는 requirements.txt 파일이 있어야 합니다.
  • Ruby 프로젝트의 경우, Gemfile 또는 Gemfile.lock 파일이 있어야 합니다.

다른 언어와 프레임워크의 요구 사항에 대한 자세한 내용은 Heroku 빌드팩 문서를 참조하세요.

note
아직 클라우드 네이티브 빌드팩 사양에는 테스트 스위트 감지가 포함되어 있지 않아 Auto Test는 여전히 Herokuish를 사용합니다. 자세한 내용은 이슈 212689를 참조하세요.

빌드 컨테이너에 볼륨 마운트

변수 BUILDPACK_VOLUMES를 사용하여 볼륨 마운트 정의를 pack 명령에 전달할 수 있습니다. 이들 마운트는 --volume 인수를 사용하여 pack build로 전달됩니다. 각 볼륨 정의에는 build pack이 제공하는 호스트 경로, 대상 경로, 볼륨의 쓰기 가능 여부 및 하나 이상의 볼륨 옵션과 같은 여러 가지 기능을 포함할 수 있습니다.

여러 볼륨을 전달하려면 파이프 | 문자를 사용하세요. 디렉터리의 각 항목은 별도의 --volume 인수를 사용하여 build back로 전달됩니다.

이 예제에서 컨테이너에는 /etc/foo, /opt/foo, /var/opt/foo로 세 개의 볼륨이 마운트됩니다. 

buildjob:
  variables:
    BUILDPACK_VOLUMES: /mnt/1:/etc/foo:ro|/mnt/2:/opt/foo:ro|/mnt/3:/var/opt/foo:rw

pack build 설명서에서 볼륨 정의에 대해 더 자세히 알아보세요.

Herokuish에서 클라우드 네이티브 빌드팩으로 전환

Cloud Native Buildpacks를 사용한 빌드는 다음과 같은 옵션을 지원합니다:

  • 빌드팩은 클라우드 네이티브 빌드팩이어야 합니다. Heroku 빌드팩은 Heroku의 cnb-shim을 사용하여 클라우드 네이티브 빌드팩으로 변환할 수 있습니다.
  • BUILDPACK_URL은 pack에서 지원하는 형식이어야 합니다.
  • 빌드된 이미지에 /bin/herokuish 명령이 없으며 명령 앞에 /bin/herokuish procfile exec를 붙이는 것은 더 이상 필요하지 않습니다(또는 불가능합니다). 대신 사용자 정의 명령에는 올바른 실행 환경을 받기 위해 /cnb/lifecycle/launcher를 접두어로 사용해야 합니다.

자동 테스트

Auto Test는 Herokuish와 Heroku 빌드팩을 사용하여 현재 코드에 대한 정적 분석 및 기타 코드 확인을 실행하는데 사용됩니다. 보고서를 작성한 후, 나중에 다운로드하고 확인할 수 있는 아티팩트로 업로드됩니다. Merge Request 위젯은 소스와 대상 브랜치 사이의 차이를 표시합니다.

note
Auto Build에서 지원하는 모든 빌드팩이 Auto Test에서 지원되지 않습니다. Auto Test는 Herokuish를 사용하며 Cloud Native Buildpacks를 사용하지 않으며, 테스트 팩 API를 구현한 빌드팩만 지원됩니다.

현재 지원되는 언어

모든 빌드팩이 Auto Test를 아직 지원하지 않기 때문에 상대적으로 새로운 개선 사항입니다. Heroku의 공식적으로 지원되는 언어는 모두 Auto Test를 지원합니다. Heroku의 Herokuish 빌드팩이 지원하는 언어를 지원하지만 특히 멀티 빌드팩은 지원하지 않습니다.

지원되는 빌드팩은 다음과 같습니다: 

- heroku-buildpack-multi
- heroku-buildpack-ruby
- heroku-buildpack-nodejs
- heroku-buildpack-clojure
- heroku-buildpack-python
- heroku-buildpack-java
- heroku-buildpack-gradle
- heroku-buildpack-scala
- heroku-buildpack-play
- heroku-buildpack-php
- heroku-buildpack-go
- buildpack-nginx

위 디렉터리에 없는 빌드팩이 필요한 경우, 사용자 정의 빌드팩을 사용할 수 있습니다.

자동 코드 품질

Auto Code Quality는 Code Quality 이미지를 사용하여 현재 코드에 대한 정적 분석 및 기타 코드 확인을 실행합니다. 보고서를 작성한 후, 후에 다운로드하고 확인할 수 있는 아티팩트로 업로드됩니다. Merge Request 위젯은 소스와 타겟 브랜치 사이의 차이를 표시합니다.

Auto SAST

  • GitLab Ultimate 10.3에서 소개되었습니다.
  • 13.1부터 모든 티어에서 사용할 수 있는 기능이 선택적으로 제공됩니다.

정적 응용 프로그램 보안 테스트(SAST)는 현재 코드에 대해 정적 분석을 수행하고 잠재적 보안 문제를 확인합니다. Auto SAST 단계에는 GitLab Runner 11.5 이상이 필요합니다.

보고서를 생성한 후에는 나중에 다운로드하고 확인할 수 있는 artifact로 업로드됩니다. 머지 요청 위젯은 또한 Ultimate 라이선스에서 발견된 모든 보안 경고를 표시합니다.

자세한 내용은 정적 응용 프로그램 보안 테스트(SAST)를 참조하십시오.

Auto Secret Detection

Secret Detection은 현재 코드에 대해 Secret Detection Docker image를 사용하여 비밀 감지를 실행하고 유출된 비밀을 확인합니다.

보고서를 생성한 후에는 나중에 다운로드하고 평가할 수 있는 artifact로 업로드됩니다. 머지 요청 위젯은 또한 Ultimate 라이선스에서 발견된 모든 보안 경고를 표시합니다.

자세한 내용은 Secret Detection를 참조하십시오.

Auto Dependency Scanning

Tier: Ultimate Offering: GitLab.com, Self-Managed, GitLab Dedicated

의존성 스캔은 프로젝트의 의존성에 대해 분석을 수행하고 잠재적인 보안 문제를 확인합니다. Auto Dependency Scanning 단계는 Ultimate 라이선스 이외의 라이선스에서는 건너뛰어집니다.

보고서를 생성한 후에는 나중에 다운로드하여 확인할 수 있는 artifact로 업로드됩니다. 머지 요청 위젯은 발견된 모든 보안 경고를 표시합니다.

자세한 내용은 의존성 스캔를 참조하십시오.

Auto Container Scanning

컨테이너에 대한 취약성 정적 분석은 Trivy를 사용하여 Docker 이미지에서 잠재적인 보안 문제를 확인합니다. Auto Container Scanning 단계는 Ultimate 라이선스 이외의 라이선스에서는 건너뛰어집니다.

보고서를 생성한 후에는 나중에 다운로드하여 확인할 수 있는 artifact로 업로드됩니다. 머지 요청은 발견된 모든 보안 문제를 표시합니다.

자세한 내용은 컨테이너 스캔를 참조하십시오.

Auto Review Apps

이 단계는 쿠버네티스 클러스터를 사용할 수 없는 프로젝트가 많기 때문에 선택 사항입니다. 요구 사항을 충족하지 않으면 작업이 자동으로 건너뛰어집니다.

Review apps은 브랜치의 코드를 기반으로 한 임시 애플리케이션 환경으로, 개발자, 디자이너, QA, 제품 관리자 및 기타 리뷰어가 실제로 코드 변경과 관련하여 보고 혹은 상호 작용할 수 있도록 합니다. Auto Review Apps는 각 브랜치에 대해 Review App을 생성합니다.

Auto Review Apps는 귀하의 애플리케이션을 귀하의 쿠버네티스 클러스터로만 배포합니다. 클러스터를 사용할 수 없으면 배포가 이루어지지 않습니다.

Review App은 프로젝트 ID, 브랜치 또는 태그 이름, 고유 번호, Auto DevOps 기본 도메인 등의 조합을 기반으로 한 고유한 URL을 갖습니다. (예: 13083-review-project-branch-123456.example.com). 머지 요청 위젯에서는 쉽게 찾을 수 있는 Review App으로의 링크를 표시합니다. 브랜치 또는 태그가 삭제되면, 예를 들어 머지 요청 후에는 Review App도 삭제됩니다.

Review apps는 Helm을 사용하여 auto-deploy-app 차트로 배포되며, 사용자 정의할 수 있습니다. 해당 애플리케이션은 환경용 Kubernetes namespace에 배포됩니다.

Locale Tiller가 사용됩니다. 이전 버전의 GitLab에는 프로젝트 네임스페이스에 설치된 Tiller가 있었습니다.

caution
애플리케이션은 Helm이 아닌(즉, Kubernetes를 직접 사용하는) 외부에서 수정해서는 절대로 안 됩니다. 이로 인해 Helm에서 변경 사항을 감지하지 못하고 자동으로 적용하는 변경을 되돌릴려고 할 때 혼란을 줄 수 있습니다. 또한, 무언가를 변경하고 다시 배포하여 되돌리고 싶은 경우 Helm에서 처음에 변경 사항이 감지된 걸 그때까지는 감지하지 못할 수 있으므로 이전 구성을 다시 적용해야 할 필요를 느끼지 못할 수 있습니다.

Auto DAST

Tier: Ultimate Offering: GitLab.com, Self-Managed, GitLab Dedicated

동적 응용 프로그램 보안 테스트(DAST)는 인기있는 오픈 소스 도구 OWASP ZAProxy를 사용하여 현재 코드를 분석하고 잠재적 보안 문제를 확인합니다. Auto DAST 단계는 Ultimate 라이선스 이외의 라이선스에서는 건너뛰어집니다.

  • 기본 브랜치에서, DAST는 특별한 목적으로 배포된 애플리케이션을 검사합니다. 이후에는 DAST 대상 브랜치를 덮어쓰기하지 않는 한, 앱이 삭제됩니다.
  • 기능 브랜치에서는 Review App을 검사합니다.

DAST 스캔이 완료되면, 모든 보안 경고가 보안 대시보드 및 머지 요청 위젯에 표시됩니다.

자세한 내용은 동적 응용 프로그램 보안 테스트(DAST)를 참조하십시오.

DAST 대상 덮어쓰기

자동으로 배포된 Review Apps 대신에 사용자 정의 대상을 사용하려면 DAST_WEBSITE CI/CD 변수를 대상 URL로 설정하십시오.

caution
DAST 풀 스캔이 활성화된 경우에는, GitLab은 꼭 DAST_WEBSITE를 스테이징 또는 프로덕션 환경으로 설정하고 싶지 않습니다. DAST 풀 스캔은 대상을 적극적으로 공격하며, 이는 귀하의 애플리케이션을 다운시키고 데이터 손실 또는 손상으로 이어질 수 있습니다.

자동 DAST 비활성화

DAST를 비활성화할 수 있습니다:

  • 모든 브랜치에서 DAST_DISABLED CI/CD 변수를 "true"로 설정하는 것으로
  • 기본 브랜치에서만 DAST_DISABLED_FOR_DEFAULT_BRANCH 변수를 "true"로 설정하는 것으로
  • 기능 브랜치에서만 REVIEW_DISABLED 변수를 "true"로 설정하는 것으로. 이것은 Review App을 비활성화합니다.

Auto Browser Performance Testing

Tier: Premium, Ultimate Offering: GitLab.com, Self-Managed, GitLab Dedicated

자동 Browser Performance Testing은 Sitespeed.io container를 사용하여 웹 페이지의 브라우저 성능을 메트릭하고, 각 페이지의 전반적인 성능 점수를 포함한 JSON 보고서를 생성하고, 보고서를 artifact로 업로드합니다. 기본적으로 리뷰 및 프로덕션 환경의 루트 페이지를 테스트합니다. 추가 URL을 테스트하려면 루트 디렉터리에 .gitlab-urls.txt라는 파일을 만들고 각 행에 하나의 파일 경로를 추가하십시오. 예를 들어: 

/
/features
/direction

소스와 타깃 브랜치 간의 브라우저 성능 차이 또한 머지 요청 위젯에서 표시됩니다.

Auto Load Performance Testing

Tier: Premium, Ultimate Offering: GitLab.com, Self-Managed, GitLab Dedicated

자동 Load Performance Testing은 k6 container를 사용하여 애플리케이션의 서버 성능을 메트릭하고, 여러 핵심 결과 메트릭을 포함하는 JSON 보고서를 생성하고, 보고서를 artifact로 업로드합니다.

초기 설정이 필요합니다. k6 테스트는 귀하의 특정 애플리케이션에 맞게 작성되어야 합니다. 또한, 테스트는 환경의 동적 URL을 CI/CD variable을 통해 가져올 수 있도록 구성되어야 합니다.

소스와 타깃 브랜치 간의 부하 성능 테스트 결과 차이 또한 머지 요청 위젯에서 표시됩니다.

자동 배포

Amazon Elastic Compute Cloud(Amazon EC2)로의 배포 또는 쿠버네티스 클러스터로의 배포 선택이 가능합니다.

자동 배포는 Auto DevOps의 선택 사항입니다. 요구 사항이 충족되지 않으면 작업이 건너뜁니다.

브랜치 또는 Merge Request이 프로젝트의 기본 브랜치에 Merge되면, Auto Deploy는 애플리케이션을 production 환경으로 쿠버네티스 클러스터에 배포하며 프로젝트 이름과 고유 프로젝트 ID를 기반으로 하는 네임스페이스에 배포합니다. 예를 들어 project-4321입니다.

기본적으로 Auto Deploy에는 스테이징 또는 카나리아 환경으로의 배포는 포함되어 있지 않지만, Auto DevOps 템플릿은 이러한 작업을 위한 작업 정의를 포함하고 있습니다.

CI/CD 변수를 사용하여 파드 레플리카를 자동으로 확장하고 Auto DevOps의 helm upgrade 명령에 사용자 정의 인수를 적용할 수 있습니다. 이는 Auto Deploy Helm 차트를 사용자 정의하는 쉬운 방법입니다.

Helm은 auto-deploy-app 차트를 사용하여 애플리케이션을 Kubernetes 네임스페이스로 배포합니다.

로컬 Tiller이 사용됩니다. 이전 버전의 GitLab에는 프로젝트 네임스페이스에 Tiller가 설치되어 있었습니다.

caution
Helm 외부에서(직접적으로 Kubernetes를 사용하여) 앱을 조작해서는 안 됩니다. 이로 인해 Helm에서 변경 사항을 감지하지 못하고 이후의 Auto DevOps 배포는 변경 사항을 취소할 수 있습니다. 또한, 변경한 내용을 되돌리고자 배포하는 경우, Helm은 초반에 변경 사항을 감지하지 못할 수 있고, 그 결과 이전 구성을 다시 적용해야 한다는 것을 인식하지 못할 수 있습니다.

GitLab 배포 토큰

내부 및 비공개 프로젝트에 대해 GitLab이 활성화되면 GitLab Deploy 토큰이 생성되고 Auto DevOps 설정이 저장됩니다. 레지스트리에 대한 영구 액세스에 배포 토큰을 사용할 수 있습니다. 매뉴얼으로 GitLab Deploy 토큰을 취소한 후에는 자동으로 생성되지 않습니다.

GitLab Deploy 토큰을 찾을 수 없는 경우 CI_REGISTRY_PASSWORD을 사용합니다.

note
CI_REGISTRY_PASSWORD은 배포 중에만 유효합니다. Kubernetes는 배포 중에 컨테이너 이미지를 성공적으로 가져올 수 있지만, 포드 이전과 같이 이미지를 다시 가져와야 하는 경우, Kubernetes는 CI_REGISTRY_PASSWORD를 사용하여 이미지를 가져오려고 시도하지만 이때 성공하지 못할 수 있습니다.

Kubernetes 1.16+

caution
deploymentApiVersion 설정의 기본값이 extensions/v1beta에서 apps/v1로 변경되었습니다.

Kubernetes 1.16 이상에서 extensions/v1beta1 버전에서 Deployment를 지원하는 등 여러 API가 제거되었습니다.

Kubernetes 1.16+ 클러스터에서 Auto Deploy를 사용하려면:

  1. GitLab 13.0 이상에서 애플리케이션을 처음으로 배포하는 경우 변경 구성이 필요하지 않습니다.

  2. AUTO_DEVOPS_POSTGRES_CHANNEL이 1로 설정된 클러스터에 인클러스터 PostgreSQL 데이터베이스가 설치되어 있는 경우, PostgreSQL을 업그레이드하는 안내에 따르세요.

caution
버전 2로 전환하기 전에 PostgreSQL을 업그레이드하는 안내에 따라 데이터베이스를 백업하고 복원하세요.

마이그레이션

프로젝트 CI/CD 변수 DB_INITIALIZE 및 DB_MIGRATE를 설정하여 PostgreSQL 데이터베이스의 초기화 및 마이그레이션을 애플리케이션 파드 내에서 실행할 수 있습니다.

DB_INITIALIZE가 있는 경우, DB_INITIALIZE은 Helm의 포스트 인스톨 후크로써 애플리케이션 파드 내에서 셸 명령으로 실행됩니다. 일부 애플리케이션은 성공적인 데이터베이스 초기화 단계 없이 실행할 수 없기 때문에, GitLab은 애플리케이션 배포 없이 처음 릴리스를 배포하고 데이터베이스 초기화 단계만 수행합니다. 데이터베이스 초기화가 완료되면, GitLab은 표준으로 애플리케이션 배포를 포함하는 두 번째 릴리스를 배포합니다.

포스트 인스톨 후크는 배포가 성공하면 이후에 DB_INITIALIZE를 처리하지 않습니다.

DB_MIGRATE가 있는 경우, DB_MIGRATE는 Helm의 프리 업그레이드 후크로써 애플리케이션 파드 내에서 셸 명령으로 실행됩니다.

예를 들어, Cloud Native Buildpacks로 빌드된 이미지 내에서 Rails 애플리케이션이 있는 경우:

  • DB_INITIALIZE를 RAILS_ENV=production /cnb/lifecycle/launcher bin/rails db:setup로 설정할 수 있습니다.
  • DB_MIGRATE를 RAILS_ENV=production /cnb/lifecycle/launcher bin/rails db:migrate로 설정할 수 있습니다.

만약 리포지터리에 Dockerfile이 없는 경우에는, 이미지가 Cloud Native Buildpacks로 빌드되었으며, 해당 이미지에서 실행되는 환경을 복제하기 위해 명령을 /cnb/lifecycle/launcher로 접두어를 붙여야 합니다.

자동 배포 앱 차트 업그레이드

업그레이드 가이드에 따라 자동 배포 앱 차트를 업그레이드할 수 있습니다.

Worker

일부 웹 애플리케이션은 “워커 프로세스”용으로 추가 배포를 실행해야 할 수 있습니다. 예를 들어, Rails 애플리케이션은 주로 이메일 전송과 같은 백그라운드 작업을 실행하는 별도의 워커 프로세스를 사용합니다.

Auto DevOps에서 사용되는 기본 Helm 차트는 워커 프로세스 실행을 지원합니다.

워커를 실행하려면, 워커가 기본적인 상태 확인에 응답할 수 있어야 하며, 이는 포트 5000에서 성공적인 HTTP 응답을 기대합니다. Sidekiq을 위해, sidekiq_alive gem을 사용할 수 있습니다.

Sidekiq을 사용하려면 배포가 해당 인스턴스에 액세스할 수 있도록 자체 Redis 인스턴스를 유지하고 배포에 전달되는 CI/CD 변수 K8S_SECRET_REDIS_URL을 설정해야 합니다. Auto DevOps는 이 인스턴스를 자동으로 배포하지 않기 때문입니다.

워커를 상태 확인에 응답할 수 있도록 구성한 후에, Rails 애플리케이션을 위한 Sidekiq 워커를 실행하세요. 워커를 활성화하려면 .gitlab/auto-deploy-values.yaml 파일에서 다음을 설정할 수 있습니다: 

workers:
  sidekiq:
    replicaCount: 1
    command:
      - /cnb/lifecycle/launcher
      - sidekiq
    preStopCommand:
      - /cnb/lifecycle/launcher
      - sidekiqctl
      - quiet
    terminationGracePeriodSeconds: 60

컨테이너 내에서 명령 실행

리포지터리에 커스텀 Dockerfile이 없는 경우, Auto Build로 빌드된 애플리케이션은 다음과 같이 명령을 래핑해야 할 수 있습니다: 

/cnb/lifecycle/launcher $COMMAND

명령을 래핑해야 하는 이유:

  • kubectl exec를 사용하여 첨부
  • GitLab 웹 터미널 사용

예를 들어, 애플리케이션 루트 디렉터리에서 Rails 콘솔을 시작하려면 다음 명령을 실행하세요: 

/cnb/lifecycle/launcher procfile exec bin/rails c

자동 코드 지능

GitLab 코드 지능은 대화형 개발 환경(IDE)에서 일반적으로 볼 수 있는 코드 탐색 기능을 추가합니다. 이 기능에는 타입 서명, 기호 설명, 정의로 이동 등이 포함되어 있습니다. 이는 LSIF를 통해 지원되며 Go 언어를 사용하는 Auto DevOps 프로젝트에서만 사용할 수 있습니다. GitLab은 더 많은 LSIF 인덱서가 사용 가능해짐에 따라 더 많은 언어를 지원할 계획입니다. 업데이트에 대해서는 코드 지능 에픽을 팔로우할 수 있습니다.

이 단계는 기본적으로 활성화되어 있습니다. CODE_INTELLIGENCE_DISABLED CI/CD 변수를 추가하여 비활성화할 수 있습니다. Auto DevOps 작업 비활성화에 대해 더 읽어보세요.