Auto DevOps의 스테이지

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

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

자동 빌드

참고: 오픈쉬프트 클러스터와 같은 GitLab 러너에서 도커 인 도커를 사용할 수 없는 경우 Auto Build는 지원되지 않습니다. GitLab의 오픈쉬프트 지원은 특별한 에픽에서 추적됩니다.

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

Dockerfile을 사용한 자동 빌드

프로젝트 저장소에 Dockerfile이 포함되어 있는 경우, 자동 빌드는 docker build를 사용하여 Docker 이미지를 생성합니다.

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

Cloud Native 빌드팩을 사용한 자동 빌드

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

각 빌드팩에는 Auto Build가 애플리케이션을 성공적으로 빌드하기 위해 프로젝트 저장소에 특정 파일을 포함해야 합니다. 구조는 선택한 빌더 및 빌드팩에 특화됩니다. 예를 들어, 기본값인 Heroku 빌더를 사용하는 경우, 애플리케이션의 루트 디렉토리에 해당 언어에 맞는 파일이 포함되어 있어야 합니다:

  • 파이썬 프로젝트의 경우, Pipfile이나 requirements.txt 파일.
  • 루비 프로젝트의 경우, Gemfile이나 Gemfile.lock 파일.

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

참고: 아직 Cloud Native Buildpack 사양에 테스트 스위트 감지가 포함되어 있지 않기 때문에 Auto Test는 여전히 Herokuish를 사용합니다. 자세한 정보는 이슈 212689를 참조하세요.

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

변수 BUILDPACK_VOLUMES를 사용하여 볼륨 마운트 정의를 pack 명령에 전달할 수 있습니다. 각 마운트는 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 Build에서 지원하는 빌드팩이 모두 Auto Test에서 지원되는 것은 아닙니다. Auto Test는 Herokuish를 사용하며, Cloud Native Buildpacks를 지원하지 않고 테스트 스위트 감지를 구현한 빌드팩만 지원합니다.

현재 지원되는 언어

모든 빌드팩이 아직 상대적으로 새로운 개선 사항인 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

당신의 애플리케이션이 위 목록에 없는 빌드팩이 필요하다면, 사용자 정의 빌드팩을 사용하는 것이 좋습니다.

자동 코드 품질

자동 코드 품질은 현재 코드에 대해 정적 분석 및 기타 코드 검사를 실행하는 Code Quality 이미지를 사용합니다. 보고서를 생성한 후, 나중에 다운로드하여 확인할 수 있도록 artifact로 업로드됩니다. 머지 요청 위젯은 또한 소스 및 대상 브랜치 간의 차이를 표시합니다.

자동 SAST

  • GitLab Ultimate 10.3에서 도입되었습니다.
  • 13.1에서 모든 티어에서의 특정 기능이 제공되기 시작했습니다.

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

보고서를 생성한 후, artifact로 업로드되어 나중에 다운로드하고 확인할 수 있습니다. 머지 요청 위젯은 Ultimate 라이선스에서 검색된 보안 경고를 표시합니다.

세부 정보는 정적 응용프로그램 보안 테스트(SAST)에서 확인하세요.

자동 시크릿 감지

시크릿 감지는 현재 코드에 대해 시크릿 감지를 실행하고 누출된 시크릿을 확인하는 시크릿 감지 도커 이미지를 사용합니다.

보고서를 생성한 후, artifact로 업로드되어 나중에 다운로드하고 평가할 수 있습니다. 머지 요청 위젯은 Ultimate 라이선스에서 검색된 보안 경고를 표시합니다.

세부 정보는 시크릿 감지에서 확인하세요.

자동 의존성 스캐닝

Tier: Ultimate Offering: GitLab.com, 자체 관리, GitLab 전용

의존성 스캐닝은 프로젝트의 의존성에 대해 분석을 실행하고 잠재적인 보안 문제를 확인합니다. 자동 의존성 스캐닝 단계는 Ultimate 이외의 라이선스에서 제외됩니다.

보고서를 생성한 후, artifact로 업로드되어 나중에 다운로드하고 확인할 수 있습니다. 머지 요청 위젯은 검출된 보안 경고를 표시합니다.

세부 정보는 의존성 스캐닝에서 확인하세요.

자동 컨테이너 스캐닝

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

보고서를 생성한 후, artifact로 업로드되어 나중에 다운로드하고 확인할 수 있습니다. 머지 요청 위젯은 검출된 보안 문제를 표시합니다.

세부 정보는 컨테이너 스캐닝에서 확인하세요.

자동 리뷰 앱

이 단계는 많은 프로젝트가 Kubernetes 클러스터를 사용할 수 없기 때문에 선택적인 단계입니다. 요구 사항이 충족되지 않으면 작업이 무시됩니다.

리뷰 앱은 브랜치의 코드를 기반으로 한 일시적인 애플리케이션 환경으로, 개발자, 디자이너, QA, 제품 관리자 및 기타 리뷰어가 실제로 코드 변경 사항을 검토 과정의 일부로 볼 수 있고 상호 작용할 수 있습니다. 자동 리뷰 앱은 각 브랜치에 대해 리뷰 앱을 생성합니다.

자동 리뷰 앱은 애플리케이션을 Kubernetes 클러스터에 배포합니다. 클러스터가 사용할 수 없는 경우, 배포가 발생하지 않습니다.

리뷰 앱은 프로젝트 ID, 브랜치 또는 태그 이름, 고유 번호 및 Auto DevOps 기본 도메인에 기반한 고유한 URL을 갖습니다. 예: 13083-review-project-branch-123456.example.com. 머지 요청 위젯은 쉬운 검색을 위해 리뷰 앱에 대한 링크를 표시합니다. 브랜치 또는 태그가 삭제되면, 예를 들어 머지 요청 후에 삭제되면 리뷰 앱도 삭제됩니다.

리뷰 앱은 Helm을 사용하여 배포됩니다. 사용자 정의할 수 있는 Helm 차트가 있습니다. 애플리케이션은 환경에 대한 Kubernetes 네임스페이스에 배포됩니다.

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

경고: 앱은 Helm 이외의 방법(순수하게 Kubernetes를 사용함)으로 조작해서는 안 됩니다. Helm이 변경 사항을 감지하지 못해 Auto DevOps가 변경 사항을 취소하거나 이전 설정을 다시 적용할 수 없을 수 있습니다. 변경 사항을 수정하고 다시 배포하는 경우에도 Helm이 처음부터 변경 사항을 감지하지 못할 수 있으므로 다시 적용해야 하는 것을 알아차리지 못할 수 있습니다.

자동 DAST

Tier: Ultimate Offering: GitLab.com, 자체 관리, GitLab 전용

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

  • 기본 브랜치에서는 DAST가 해당 목적을 위해 따로 배포된 애플리케이션에 대해 스캔을 실행합니다. 이후 앱은 삭제됩니다(목표 브랜치 재정의할 수 있음).
  • 기능 브랜치에서는 리뷰 앱을 대상으로 DAST가 스캔을 실행합니다.

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

세부 정보는 동적 응용프로그램 보안 테스팅(DAST)에서 확인하세요.

DAST 대상 재정의

자동으로 배포된 리뷰 앱 대신 사용자 정의 대상을 사용하려면 DAST_WEBSITE CI/CD 변수를 DAST가 스캔해야 하는 URL로 설정하세요.

경고: DAST 전체 스캔이 활성화되어 있는 경우 GitLab은 DAST_WEBSITE를 스테이징 또는 프로덕션 환경으로 설정하지 말 것을 강력히 권장합니다. DAST 전체 스캔은 대상을 적극적으로 공격하며, 이로 인해 응용 프로그램이 다운되거나 데이터가 손실되거나 손상될 수 있습니다.

자동 DAST 비활성화

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

  • DAST_DISABLED CI/CD 변수를 "true"로 설정하여 모든 브랜치에서.
  • DAST_DISABLED_FOR_DEFAULT_BRANCH 변수를 "true"로 설정하여 기본 브랜치에서만.
  • REVIEW_DISABLED 변수를 "true"로 설정하여 기능 브랜치에서만. 이는 리뷰 앱도 비활성화합니다.

자동 브라우저 성능 테스트

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

자동 브라우저 성능 테스트는 Sitespeed.io 컨테이너로 웹 페이지의 브라우저 성능을 측정하여 각 페이지의 전체 성능 점수를 포함한 JSON 보고서를 작성하고 이를 artifact로 업로드합니다. 기본적으로 리뷰 및 프로덕션 환경의 루트 페이지를 테스트합니다. 추가 URL을 테스트하려면 루트 디렉터리에 .gitlab-urls.txt로 경로를 개행하여 입력하세요. 예를들어: 

/
/features
/direction

소스 및 대상 브랜치 간의 브라우저 성능 차이 또한 병합 요청 위젯에 표시됩니다.

자동 부하 성능 테스트

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

자동 부하 성능 테스트는 k6 컨테이너로 응용 프로그램의 서버 성능을 측정하여 여러 주요 결과 지표를 포함한 JSON 보고서를 작성하고 이를 artifact로 업로드합니다.

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

소스 및 대상 브랜치 간의 부하 성능 테스트 결과 차이 또한 병합 요청 위젯에 표시됩니다.

자동 배포

Kubernetes 클러스터에 함께 Amazon Elastic Compute Cloud (Amazon EC2)에 배포할 수 있는 선택권이 있습니다.

자동 배포는 Auto DevOps의 옵션 단계입니다. 요구 사항이 충족되지 않으면 작업이 건너뛰어집니다.

프로젝트의 기본 브랜치로 병합 요청이 병합되면 자동 배포는 프로젝트 이름과 고유 프로젝트 ID를 기반으로 하는 production 환경에 응용 프로그램을 배포합니다. 기본적으로 스테이징 또는 카나리아 환경에 배포되지 않지만 Auto DevOps 템플릿에 해당 작업을 활성화하려면 작업 정의가 포함되어 있습니다.

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

Helm은 auto-deploy-app 차트를 사용하여 응용 프로그램을 Kubernetes 네임스페이스에 배포합니다.

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

경고: 응용 프로그램에는 Helm 이외(Kubernetes 직접 사용 포함)에서 조작해서는 안 됩니다. 이로 인해 Helm에서 변경 사항을 감지하지 못하고, 그로 인해 Auto DevOps가 변경 사항을 취소할 수 있습니다. 또한, 무엇인가를 변경하고 다시 배포해야 하는 경우, Helm은 처음에 변경이 감지되지 않았다고 인지하지 못할 수 있으며 따라서 이전 구성을 다시 적용해야 한다는 사실을 깨닫지 못할 것입니다.

GitLab 배포 토큰

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

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

참고: CI_REGISTRY_PASSWORD은 배포하는 동안에만 유효합니다. Kubernetes는 배포 중에 컨테이너 이미지를 성공적으로 가져올 수 있지만, pod 에이브케이션과 같이 이미지를 다시 가져와야 하는 경우 CI_REGISTRY_PASSWORD를 사용하여 이미지를 가져올 수 없습니다.

Kubernetes 1.16+

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

Kubernetes 1.16 이후, Deployment에 대한 지원을 포함한 여러 API가 제거되었습니다.

Kubernetes 1.16 이상에서 Auto Deploy를 사용하려면:

  1. GitLab 13.0 이후에 응용 프로그램을 처음으로 배포하는 경우, 구성은 필요하지 않습니다.
  2. AUTO_DEVOPS_POSTGRES_CHANNEL이 1로 설정된 내부 PostgreSQL 데이터베이스에 대한 설치가 있는 경우, PostgreSQL을 업그레이드하는 안내에 따르세요.

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

마이그레이션

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

존재하는 경우, 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를 접두어로 사용해야 합니다.

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

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

작업자

일부 웹 응용 프로그램은 “작업자 프로세스”용으로 추가 배포를 실행해야 할 수 있습니다. 예를 들어 Rails 애플리케이션은 일반적으로 이메일 보내기와 같은 백그라운드 작업을 실행하기 위해 별도의 작업자 프로세스를 사용합니다.

자동 배포에서 사용되는 기본 Helm 차트는 작업자 프로세스 실행을 지원합니다.

작업자를 실행하려면, 작업자가 5000번 포트에서 성공적인 HTTP 응답을 기대하는 기본 건강 체크에 응답할 수 있어야 합니다. Sidekiq의 경우, sidekiq_alive gem을 사용할 수 있습니다.

Sidekiq과 작업하기 위해서는 배포들이 Redis 인스턴스에 액세스할 수 있도록 해야 합니다. Auto DevOps는 이 인스턴스를 귀하를 위해 배포하지 않으므로, 다음을 수행해야 합니다: - 본인의 Redis 인스턴스를 유지하십시오. - CI/CD 변수 K8S_SECRET_REDIS_URL를 설정하여, 이 인스턴스의 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을 포함하지 않는다면, 자동 빌드로 빌드된 응용 프로그램은 다음과 같이 명령어를 래핑해야 할 수도 있습니다: 

/cnb/lifecycle/launcher $COMMAND

명령을 래핑해야 하는 이유 중 일부: - kubectl exec를 사용하여 첨부. - GitLab 웹 터미널을 사용합니다.

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

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

자동 코드 지능

GitLab 코드 지능은 상호 작용적인 개발 환경(IDE)에 일반적으로 있는 코드 탐색 기능을 추가하여, 타입 서명, 심벌 문서 및 정의 위치로 구동됩니다. 이것은 LSIF로 구동되며, 오직 Go 언어를 사용하는 Auto DevOps 프로젝트에서 사용할 수 있습니다. 더 많은 LSIF 인덱서가 사용 가능해지면 GitLab은 더 많은 언어를 지원하도록 추가할 계획입니다. 업데이트를 위해서는 코드 지능 에픽을 팔로우할 수 있습니다.

이 스테이지는 기본으로 활성화되어 있습니다. CODE_INTELLIGENCE_DISABLED CI/CD 변수를 추가함으로써 비활성화할 수 있습니다. Auto DevOps 작업 비활성화에 대해 더 읽어보세요.