• Auto Build
  • Dockerfile을 사용한 Auto Build
  • Cloud Native Buildpacks를 사용한 Auto Build
    • 빌드 컨테이너에 볼륨 마운트
  • Herokuish를 사용한 Auto Build(폐기됨)
• Auto Test (폐기됨)
  • 현재 지원되는 언어
• Auto Code Quality
• Auto SAST
• Auto Secret Detection
• Auto Dependency Scanning
• Auto Container Scanning
• Auto Review Apps
• Auto DAST
  • DAST 대상 재정의
  • Auto DAST 비활성화
• Auto Browser 성능 테스팅
• Auto 부하 성능 테스팅
• 자동 배포
  • GitLab 배포 토큰
  • Kubernetes 1.16+
  • 마이그레이션
  • 자동 배포 앱 차트 업그레이드
  • 워커
  • 컨테이너에서 명령 실행
• 자동 코드 지능

Auto DevOps의 단계

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

Auto Build

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

Dockerfile을 사용한 Auto Build

프로젝트 리포지터리에 Dockerfile이 있으면, Auto Build는 docker build를 사용하여 Docker 이미지를 만듭니다.

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

• 애플리케이션을 포트 5000에 노출합니다. 왜냐하면 기본 Helm 차트는 이 포트를 사용할 수 있다고 가정하기 때문입니다.
• Auto Deploy Helm 차트를 사용자 정의합니다.

Cloud Native Buildpacks를 사용한 Auto Build

• GitLab 12.10에 도입되었습니다.
• 기본적으로 Cloud Native Buildpacks를 사용한 Auto Build는 GitLab 14.0에 도입되었습니다.

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

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

• 파이썬 프로젝트인 경우 Pipfile 또는 requirements.txt 파일이 있어야 합니다.
• 루비 프로젝트인 경우 Gemfile 또는 Gemfile.lock 파일이 있어야 합니다.

다른 언어 및 프레임워크의 요구 사항에 대해서는 Heroku 빌드팩 문서를 참조하세요.

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

• GitLab 14.2에 도입되었습니다.
• 다중 볼륨 지원(auto-build-image v1.6.0)은 GitLab 14.6에 도입되었습니다.

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

여러 볼륨을 전달하려면 파이프 | 기호를 사용하세요. 디렉터리에서 각 항목은 별도의 --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를 사용한 Auto Build(폐기됨)

• GitLab 14.0에서 Cloud Native Buildpacks로 대체되었습니다.

GitLab 14.0 이전까지 Herokuish는 Dockerfile이 없는 프로젝트의 기본 빌드 방법이었습니다. Herokuish는 CI/CD 변수 AUTO_DEVOPS_BUILD_IMAGE_CNB_ENABLED를 false로 설정하여 여전히 사용할 수 있습니다.

Auto Test (폐기됨)

Auto Test는 프로젝트의 언어 및 프레임워크를 감지하여 Herokuish와 Heroku 빌드팩을 사용하여 응용 프로그램에 적합한 테스트를 실행합니다. 여러 언어와 프레임워크가 자동으로 감지되지만, 언어가 감지되지 않으면 사용자 정의 빌드팩을 만들 수도 있습니다. 현재 지원되는 언어를 확인하세요.

Auto Test는 응용 프로그램에 이미 있는 테스트를 사용합니다. 테스트가 없는 경우 테스트를 추가해야 합니다.

현재 지원되는 언어

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

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

- 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

• 13.2에서 GitLab Starter 에서 GitLab Free로 이동.

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

Auto SAST

• GitLab Ultimate 10.3에서 도입.
• 13.1에서 모든 티어에서 일부 기능을 사용할 수 있게 됨.

정적 애플리케이션 보안 테스트(SAST)는 현재 코드에 대해 정적 분석을 실행하고 잠재적인 보안 문제를 확인합니다. Auto SAST 단계에는 GitLab Runner 11.5 이상이 필요합니다.

보고서를 작성한 후 나중에 다운로드하여 확인할 수 있는 아티팩트로 업로드됩니다. 또한 머지 요청 위젯은 Ultimate 라이선스에서의 보안 경고를 표시합니다.

자세한 내용은 정적 애플리케이션 보안 테스트(SAST)를 참조하십시오.

Auto Secret Detection

• GitLab 13.1에서 도입.
• GitLab 13.3에서 일부 기능을 사용할 수 있음.

Secret Detection은 Secret Detection Docker 이미지를 사용하여 현재 코드에 대한 Secret Detection 및 유출된 비밀을 확인합니다. Auto Secret Detection에는 GitLab Runner 11.5 이상이 필요합니다.

보고서를 작성한 후 나중에 다운로드하여 평가할 수 있는 아티팩트로 업로드됩니다. 또한 머지 요청 위젯은 Ultimate 라이선스에서의 보안 경고를 표시합니다.

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

Auto Dependency Scanning

의존성 스캔은 프로젝트의 의존성에 대한 분석을 실행하고 잠재적인 보안 문제를 확인합니다. Auto Dependency Scanning 단계는 Ultimate 이외의 라이선스에서는 건너뛰어지며, GitLab Runner 11.5 이상이 필요합니다.

보고서를 작성한 후 나중에 다운로드하여 확인할 수 있는 아티팩트로 업로드됩니다. 머지 요청 위젯에는 감지된 보안 경고가 표시됩니다.

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

Auto Container Scanning

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

보고서를 작성한 후 나중에 다운로드하여 확인할 수 있는 아티팩트로 업로드됩니다. 머지 요청에 감지된 보안 문제가 표시됩니다.

자세한 내용은 컨테이너 스캐닝을 참조하십시오.

Auto Review Apps

이것은 선택 사항이며 많은 프로젝트에는 Kubernetes 클러스터가 없을 수 있습니다. 요구 사항을 충족하지 않으면 작업이 암묵적으로 건너뛰어집니다.

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

Auto Review Apps는 응용 프로그램을 Kubernetes 클러스터에만 배포합니다. 클러스터를 사용할 수 없으면 배포되지 않습니다.

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

Review Apps는 auto-deploy-app 차트와 Helm을 사용하여 배포되며, 사용자 정의할 수 있습니다. 응용 프로그램은 환경에 대한 Kubernetes 네임스페이스로 배포됩니다.

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

Auto DAST

Dynamic Application Security Testing (DAST)는 인기있는 오픈 소스 도구 OWASP ZAProxy를 사용하여 현재 코드를 분석하고 잠재적인 보안 문제를 확인합니다. Auto DAST 단계는 Ultimate 이외의 라이선스에서는 건너뜁니다.

• 기본 브랜치에서 DAST는 해당 목적을 위해 특별히 배포된 응용 프로그램을 스캔합니다. DAST 실행 후에 응용 프로그램은 삭제됩니다. 대상 브랜치를 재정의하지 않는 한.
• 피처 브랜치에서 DAST는 리뷰 응용 프로그램을 스캔합니다.

DAST 스캔이 완료되면 보안 경고가 보안 대시보드 및 Merge Request 위젯에 표시됩니다.

자세한 정보는 Dynamic Application Security Testing (DAST)를 참조하십시오.

DAST 대상 재정의

자동 배포된 리뷰 응용 프로그램 대신 사용자 정의 대상을 사용하려면 DAST_WEBSITE CI/CD 변수를 DAST의 스캔 대상 URL로 설정하십시오.

Auto DAST 비활성화

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

• DAST_DISABLED CI/CD 변수를 "true"로 설정하여 모든 브랜치에서.
• DAST_DISABLED_FOR_DEFAULT_BRANCH 변수를 "true"로 설정하여 기본 브랜치에서만.
• REVIEW_DISABLED 변수를 "true"로 설정하여 피처 브랜치에서만. 이는 리뷰 응용 프로그램을 비활성화합니다.

Auto Browser 성능 테스팅

• GitLab 10.4에서 소개되었습니다.

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

/
/features
/direction

소스와 대상 브랜치 간의 브라우저 성능 차이도 Merge Request 위젯에서 확인할 수 있습니다.

Auto 부하 성능 테스팅

• GitLab 13.2에서 소개되었습니다.

자동 Load Performance Testing은 k6 container를 사용하여 응용 프로그램의 서버 성능을 메트릭하고 여러 주요 결과 지표를 포함한 JSON 보고서를 작성하여 결과물을 artifact로 업로드합니다.

일부 초기 설정이 필요합니다. k6 테스트를 작성해야 하며 이는 특정 응용 프로그램에 맞게 맞춰져야 합니다. 또한 테스트는 CI/CD 변수를 통해 환경의 동적 URL을 가져올 수 있도록 설정되어야 합니다.

소스와 대상 브랜치 간의 부하 성능 테스트 결과 차이도 Merge Request 위젯에서 확인할 수 있습니다.

자동 배포

• GitLab 13.6에서 소개되었으며, 쿠버네티스 클러스터 외에 Amazon Elastic Compute Cloud (Amazon EC2)로 배포할 수 있는 선택지를 제공합니다.

자동 배포는 자동 DevOps의 선택 사항입니다. 요구 사항을 충족하지 않는 경우 작업이 건너뛰어집니다.

브랜치 또는 Merge Request이 프로젝트의 기본 브랜치로 Merge되면, 자동 배포는 프로젝트 이름과 고유 프로젝트 ID를 기반으로 한 production 환경에 응용 프로그램을 쿠버네티스 클러스터로 배포합니다.

자동 배포에는 기본적으로 스테이징 또는 캐너리 환경으로의 배포가 포함되어 있지 않지만, 자동 DevOps 템플릿에는 이러한 작업을 가능하게 하는 작업 정의가 포함되어 있습니다.

CI/CD 변수를 사용하여 자동으로 pod 복제본을 확장하거나, 자동 배포 helm upgrade 명령에 사용자 정의 인수를 적용할 수 있습니다. 이는 자동 배포 Helm 차트를 사용자 정의하는 쉬운 방법입니다.

Helm은 auto-deploy-app 차트를 사용하여 환경을 위한 쿠버네티스 네임스페이스에 응용 프로그램을 배포합니다.

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

GitLab 배포 토큰

• GitLab 11.0에서 도입되었습니다.

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

만약 GitLab 배포 토큰을 찾을 수 없다면, CI_REGISTRY_PASSWORD이 사용됩니다.

Kubernetes 1.16+

• GitLab 12.8에서 도입되었습니다.
• Kubernetes 1.16+를 지원하는 PostgreSQL 버전 배포 지원은 GitLab 12.9에서 도입되었습니다.
• GitLab 13.0에서 새로운 배포에 대해 기본적으로 지원됩니다.

Kubernetes의 1.16 버전 이상에서 여러 API가 제거되었으며, extensions/v1beta1 버전에서의 Deployment 지원도 제거되었습니다.

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

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

2. GitLab 12.10 및 이전 버전에서는 .gitlab/auto-deploy-values.yaml 파일에 다음을 설정합니다:

   deploymentApiVersion: apps/v1
   

3. AUTO_DEVOPS_POSTGRES_CHANNEL을 1로 설정하여 클러스터에 설치된 인클러스터 PostgreSQL 데이터베이스가 있는 경우, PostgreSQL을 업그레이드하는 방법은 PostgreSQL을 업그레이드하는 가이드를 확인하세요.

4. GitLab 12.9 또는 12.10을 사용하여 애플리케이션을 처음으로 배포하는 경우 AUTO_DEVOPS_POSTGRES_CHANNEL을 2로 설정합니다.

마이그레이션

• GitLab 11.4에서 도입되었습니다.

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

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

포스트 설치 후크는 배포가 한 번 성공하면, 이후로 DB_INITIALIZE이 처리되지 않습니다.

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로 프리픽스를 붙여야 합니다 (Herokuish를 사용할 때는 /bin/herokuish procfile exec로 프리픽스를 붙입니다).

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

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

워커

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

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

워커를 실행하려면, 워커가 표준 건강 확인에 응답할 수 있도록 보장해야 합니다. 예를 들어, Sidekiq의 경우, sidekiq_alive gem을 사용할 수 있습니다.

Sidekiq를 사용하려면 배포에서 Redis 인스턴스에 액세스할 수 있어야 합니다. Auto DevOps는 이 인스턴스를 자동으로 배포하지 않으므로 당신 스스로:

• 동일한 Redis 인스턴스를 유지하십시오.
• 배포에 전달되는 CI/CD 변수 K8S_SECRET_REDIS_URL을 설정하십시오.

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

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

컨테이너에서 명령 실행

Herokuish를 사용하여 자동 빌드로 구축된 응용 프로그램은 기본적으로 다음과 같이 래핑된 명령이 필요할 수 있습니다. (자체 Dockerfile을 포함하는 경우에는 사용자 정의 Dockerfile을 포함하여 기본 설정과 다를 수 있습니다.)

/bin/herokuish procfile exec $COMMAND

명령을 래핑해야 할 수 있는 몇 가지 이유:

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

예를 들어, 응용 프로그램 루트 디렉터리에서 Rails 콘솔을 시작하려면 다음을 실행하세요:

/bin/herokuish procfile exec bin/rails c

Cloud Native Buildpacks를 사용할 때, /bin/herokuish procfile exec 대신 다음을 사용하세요:

/cnb/lifecycle/launcher $COMMAND

자동 코드 지능

• 소개됨 GitLab 13.5에서.

GitLab 코드 지능은 상호 작용형 개발 환경(IDE)에서 흔히 볼 수 있는 코드 탐색 기능을 추가합니다. 이는 타입 서명, 심볼 설명, 정의로 이동을 포함합니다. 이는 LSIF에 의해 제공되며, Go 언어만 사용하는 Auto DevOps 프로젝트에 대해서만 사용할 수 있습니다. GitLab은 더 많은 LSIF 인덱서가 제공됨에 따라 더 많은 언어 지원을 추가할 계획입니다. 최신 정보를 보려면 코드 지능 에픽을 팔로우하세요.

이 단계는 기본적으로 활성화되어 있습니다. CODE_INTELLIGENCE_DISABLED CI/CD 변수를 추가하여 비활성화할 수 있습니다. Auto DevOps 작업 비활성화에 대한 자세한 내용은 여기에서 확인할 수 있습니다.