다음 섹션에서는 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을 제공하려는 경우 다음 중 하나를 수행해야 합니다:

• 기본 Helm 차트가 이 포트를 사용 가능하다고 가정하므로 애플리케이션을 포트 5000에 노출합니다.
• Auto Deploy Helm 차트 커스터마이징으로 기본값을 재정의합니다.

Cloud Native Buildpacks를 사용한 Auto Build#

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

각 빌드팩은 Auto Build가 애플리케이션을 성공적으로 빌드하기 위해 프로젝트 저장소에 특정 파일이 포함되어 있어야 합니다. 구조는 선택한 빌더와 빌드팩에 따라 다릅니다. 예를 들어, Heroku 빌더(기본값)를 사용할 때 애플리케이션의 루트 디렉토리에 애플리케이션의 언어에 적합한 파일이 있어야 합니다:

• Python 프로젝트의 경우 Pipfile 또는 requirements.txt 파일.
• Ruby 프로젝트의 경우 Gemfile 또는 Gemfile.lock 파일.

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

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

변수 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로 이동#

Cloud Native Buildpacks를 사용한 빌드는 다음 주의 사항과 함께 Herokuish를 사용한 빌드와 동일한 옵션을 지원합니다:

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

Auto Test#

Auto Test는 Herokuish와 Heroku 빌드팩을 사용하여 프로젝트를 분석하여 언어와 프레임워크를 감지하고 애플리케이션에 적합한 테스트를 실행합니다. 여러 언어와 프레임워크가 자동으로 감지되지만 언어가 감지되지 않는 경우 커스텀 빌드팩을 만들 수 있습니다. 현재 지원되는 언어를 확인하세요.

Auto Test는 애플리케이션에 이미 있는 테스트를 사용합니다. 테스트가 없는 경우 테스트를 추가하는 것은 사용자의 몫입니다.

Auto Test는 임시 PostgreSQL 데이터베이스를 프로비저닝하고 해당 데이터베이스를 가리키도록 DATABASE_URL을 설정합니다.

Auto Test 작업은 Jobs/Test.gitlab-ci.yml 템플릿에 정의되어 있습니다.

현재 지원되는 언어#

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#

히스토리

• GitLab 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 시크릿 감지#

시크릿 감지는 시크릿 감지 Docker 이미지를 사용하여 현재 코드를 스캔하고 유출된 시크릿을 확인합니다.

보고서를 만든 후 나중에 다운로드하고 평가할 수 있는 아티팩트로 업로드됩니다. 머지 리퀘스트 위젯은 Ultimate 라이선스에서 보안 경고도 표시합니다.

자세한 내용은 시크릿 감지를 참조하세요.

Auto 의존성 스캐닝#

의존성 스캐닝은 프로젝트의 의존성을 분석하고 잠재적인 보안 문제를 확인합니다. Auto 의존성 스캐닝 스테이지는 Ultimate 이외의 라이선스에서는 건너뜁니다.

보고서를 만든 후 나중에 다운로드하고 확인할 수 있는 아티팩트로 업로드됩니다. 머지 리퀘스트 위젯은 감지된 보안 경고를 표시합니다.

자세한 내용은 의존성 스캐닝을 참조하세요.

Auto 컨테이너 스캐닝#

컨테이너의 취약성 정적 분석은 Trivy를 사용하여 Docker 이미지의 잠재적인 보안 문제를 확인합니다. Auto 컨테이너 스캐닝 스테이지는 Ultimate 이외의 라이선스에서는 건너뜁니다.

보고서를 만든 후 나중에 다운로드하고 확인할 수 있는 아티팩트로 업로드됩니다. 머지 리퀘스트는 감지된 보안 문제를 표시합니다.

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

Auto Review Apps#

많은 프로젝트에서 Kubernetes 클러스터를 사용할 수 없기 때문에 이 단계는 선택 사항입니다. 요구 사항이 충족되지 않으면 작업이 자동으로 건너뜁니다.

Review Apps는 개발자, 디자이너, QA, 제품 관리자 및 기타 검토자가 리뷰 프로세스의 일부로 코드 변경 사항을 실제로 보고 상호 작용할 수 있도록 브랜치의 코드를 기반으로 하는 임시 애플리케이션 환경입니다. Auto Review Apps는 각 브랜치에 대한 Review App을 만듭니다.

Auto Review Apps는 Kubernetes 클러스터에만 애플리케이션을 배포합니다. 클러스터를 사용할 수 없는 경우 배포가 발생하지 않습니다.

Review App의 URL은 프로젝트 ID, 브랜치 또는 태그 이름, 고유 번호 및 Auto DevOps 기본 도메인의 조합을 기반으로 하며, 예를 들면 13083-review-project-branch-123456.example.com과 같습니다. 머지 리퀘스트 위젯은 쉽게 검색할 수 있도록 Review App 링크를 표시합니다. 브랜치 또는 태그가 삭제되면(예: 머지 리퀘스트 병합 후) Review App도 삭제됩니다.

Review Apps는 customize할 수 있는 auto-deploy-app 차트와 Helm을 사용하여 배포됩니다. 애플리케이션은 환경의 Kubernetes 네임스페이스에 배포됩니다.

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

Auto DAST#

동적 애플리케이션 보안 테스팅(DAST)은 널리 사용되는 오픈 소스 도구인 OWASP ZAProxy를 사용하여 현재 코드를 분석하고 잠재적인 보안 문제를 확인합니다. Auto DAST 스테이지는 Ultimate 이외의 라이선스에서는 건너뜁니다.

• 기본 브랜치에서 DAST는 대상 브랜치를 재정의하지 않는 한 해당 목적을 위해 특별히 배포된 애플리케이션을 스캔합니다. DAST가 실행된 후 앱이 삭제됩니다.
• 기능 브랜치에서 DAST는 Review App을 스캔합니다.

DAST 스캔이 완료되면 보안 경고가 보안 대시보드와 머지 리퀘스트 위젯에 표시됩니다.

자세한 내용은 DAST를 참조하세요.

DAST 대상 재정의#

자동 배포된 Review Apps 대신 커스텀 대상을 사용하려면 DAST_WEBSITE CI/CD 변수를 DAST가 스캔할 URL로 설정하세요.

Auto DAST 건너뛰기#

DAST 작업을 건너뛸 수 있습니다:

• DAST_DISABLED CI/CD 변수를 "true"로 설정하여 모든 브랜치에서 건너뜁니다.
• DAST_DISABLED_FOR_DEFAULT_BRANCH 변수를 "true"로 설정하여 기본 브랜치에서만 건너뜁니다.
• REVIEW_DISABLED 변수를 "true"로 설정하여 기능 브랜치에서만 건너뜁니다. 이렇게 하면 Review App도 건너뜁니다.

Auto Browser Performance Testing#

Auto Browser Performance Testing은 Sitespeed.io 컨테이너를 사용하여 웹 페이지의 브라우저 성능을 측정하고, 각 페이지의 전반적인 성능 점수를 포함하는 JSON 보고서를 만들고, 보고서를 아티팩트로 업로드합니다. 기본적으로 Review 및 프로덕션 환경의 루트 페이지를 테스트합니다. 추가 URL을 테스트하려면 루트 디렉토리에 있는 .gitlab-urls.txt라는 파일에 경로를 한 줄씩 추가합니다. 예를 들면:

/
/features
/direction

소스 브랜치와 대상 브랜치 간의 브라우저 성능 차이도 머지 리퀘스트 위젯에 표시됩니다.

Auto Load Performance Testing#

Auto Load Performance Testing은 k6 컨테이너를 사용하여 애플리케이션의 서버 성능을 측정하고, 여러 핵심 결과 메트릭을 포함하는 JSON 보고서를 만들고, 보고서를 아티팩트로 업로드합니다.

일부 초기 설정이 필요합니다. 특정 애플리케이션에 맞게 조정된 k6 테스트를 작성해야 합니다. 또한 테스트가 CI/CD 변수를 통해 환경의 동적 URL을 선택할 수 있도록 구성해야 합니다.

소스 브랜치와 대상 브랜치 간의 부하 성능 테스트 결과 차이도 머지 리퀘스트 위젯에 표시됩니다.

Auto Deploy#

Kubernetes 클러스터 외에도 Amazon Elastic Compute Cloud (Amazon EC2)에 배포할 수 있습니다.

Auto Deploy는 Auto DevOps의 선택적 단계입니다. 요구 사항이 충족되지 않으면 작업이 건너뜁니다.

브랜치 또는 머지 리퀘스트가 프로젝트의 기본 브랜치에 병합되면 Auto Deploy는 project-4321과 같이 프로젝트 이름과 고유한 프로젝트 ID를 기반으로 하는 네임스페이스를 사용하여 Kubernetes 클러스터의 production 환경에 애플리케이션을 배포합니다.

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

CI/CD 변수를 사용하여 파드 복제본을 자동으로 확장하고 Auto DevOps helm upgrade 명령에 커스텀 인수를 적용할 수 있습니다. 이는 Auto Deploy Helm 차트를 커스터마이징하는 쉬운 방법입니다.

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

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

GitLab 배포 토큰#

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

GitLab 배포 토큰을 찾을 수 없는 경우 CI_REGISTRY_PASSWORD가 사용됩니다.

Kubernetes 1.16+#

Kubernetes 1.16 이상에서는 extensions/v1beta1 버전의 Deployment 지원을 포함한 여러 API가 제거되었습니다.

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

1. GitLab 13.0 이상에서 처음으로 애플리케이션을 배포하는 경우 구성이 필요하지 않습니다.
2. AUTO_DEVOPS_POSTGRES_CHANNEL이 1로 설정된 클러스터 내 PostgreSQL 데이터베이스가 설치된 경우 PostgreSQL 업그레이드 가이드를 따르세요.

마이그레이션#

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

DB_INITIALIZE가 있는 경우 Helm post-install 훅으로 애플리케이션 파드 내에서 셸 명령으로 실행됩니다. 일부 애플리케이션은 성공적인 데이터베이스 초기화 단계 없이는 실행할 수 없으므로, GitLab은 애플리케이션 배포 없이 데이터베이스 초기화 단계만 포함하여 첫 번째 릴리스를 배포하고, 데이터베이스 초기화가 완료된 후 표준으로 애플리케이션 배포가 포함된 두 번째 릴리스를 배포합니다.

post-install 훅은 배포가 성공하면 이후에 DB_INITIALIZE가 처리되지 않음을 의미합니다.

DB_MIGRATE가 있는 경우 Helm pre-upgrade 훅으로 애플리케이션 파드 내에서 셸 명령으로 실행됩니다.

예를 들어, 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를 붙여야 합니다.

auto-deploy-app 차트 업그레이드#

업그레이드 가이드를 따라 auto-deploy-app 차트를 업그레이드할 수 있습니다.

워커#

일부 웹 애플리케이션은 "워커 프로세스"를 위한 추가 배포를 실행해야 합니다. 예를 들어 Rails 애플리케이션은 이메일 전송과 같은 백그라운드 작업을 실행하기 위해 별도의 워커 프로세스를 일반적으로 사용합니다.

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

워커를 실행하려면 워커가 포트 5000에서 성공적인 HTTP 응답을 기대하는 표준 상태 검사에 응답할 수 있는지 확인해야 합니다. Sidekiq의 경우 sidekiq_alive gem을 사용할 수 있습니다.

Sidekiq와 함께 작동하려면 배포에 Redis 인스턴스에 대한 액세스 권한이 있는지도 확인해야 합니다. Auto DevOps는 이 인스턴스를 배포하지 않으므로:

• 자체 Redis 인스턴스를 유지 관리해야 합니다.
• 이 인스턴스의 URL인 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

컨테이너에서 명령 실행#

저장소에 커스텀 Dockerfile이 포함되지 않은 경우 Auto Build로 빌드된 애플리케이션은 다음과 같이 명령을 래핑해야 할 수 있습니다:

/cnb/lifecycle/launcher $COMMAND

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

• kubectl exec를 사용하여 연결.
• GitLab 웹 터미널 사용.

예를 들어 애플리케이션 루트 디렉토리에서 Rails 콘솔을 시작하려면 다음을 실행합니다:

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

Auto Code Intelligence#

GitLab 코드 인텔리전스는 타입 시그니처, 심볼 문서, 정의로 이동 등 IDE(대화형 개발 환경)에 일반적인 코드 탐색 기능을 추가합니다. LSIF로 구동되며 Go 언어를 사용하는 Auto DevOps 프로젝트에서만 사용할 수 있습니다. GitLab은 더 많은 LSIF 인덱서를 사용할 수 있게 되면 더 많은 언어에 대한 지원을 추가할 계획입니다. 업데이트는 코드 인텔리전스 에픽을 따르세요.

이 스테이지는 기본적으로 활성화됩니다. CODE_INTELLIGENCE_DISABLED CI/CD 변수를 추가하여 비활성화할 수 있습니다. Auto DevOps 작업 비활성화에 대해 자세히 알아보세요.