- 자동 빌드
- 자동 테스트
- 자동 코드 품질
- Auto SAST
- Auto Secret Detection
- Auto Dependency Scanning
- Auto Container Scanning
- Auto Review Apps
- Auto DAST
- Auto Browser Performance Testing
- Auto Load Performance Testing
- 자동 배포
- 자동 코드 지능
Auto DevOps 스테이지
다음 섹션들은 Auto DevOps의 스테이지를 설명합니다. 각각이 어떻게 작동하는지 이해하기 위해 주의 깊게 읽어보세요.
자동 빌드
Auto Build는 기존의 Dockerfile
이나
Heroku 빌드팩을 사용하여 애플리케이션의 빌드를 생성합니다. 결과 Docker 이미지는 커밋 SHA나 태그와 함께 컨테이너 레지스트리에 푸시됩니다.
Dockerfile을 사용한 Auto Build
프로젝트 리포지터리에 Dockerfile
이 포함되어 있는 경우, Auto Build는 docker build
를 사용하여 Docker 이미지를 생성합니다.
또한 Auto Review Apps 및 Auto Deploy를 사용하고 자체 Dockerfile
을 제공하는 경우, 다음 중 하나를 해야 합니다:
- 애플리케이션을 포트
5000
에 노출합니다. 기본 Helm 차트는 해당 포트를 사용할 수 있다고 가정합니다. - 자동 배포 Helm 차트를 사용자 정의합니다. 기본값을 재정의해야 합니다.
클라우드 네이티브 빌드팩을 사용한 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 빌드팩 문서를 참조하세요.
빌드 컨테이너에 볼륨 마운트
변수 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 위젯은 소스와 대상 브랜치 사이의 차이를 표시합니다.
현재 지원되는 언어
모든 빌드팩이 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
의존성 스캔은 프로젝트의 의존성에 대해 분석을 수행하고 잠재적인 보안 문제를 확인합니다. 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가 있었습니다.
Auto DAST
동적 응용 프로그램 보안 테스트(DAST)는 인기있는 오픈 소스 도구 OWASP ZAProxy를 사용하여 현재 코드를 분석하고 잠재적 보안 문제를 확인합니다. Auto DAST 단계는 Ultimate 라이선스 이외의 라이선스에서는 건너뛰어집니다.
- 기본 브랜치에서, DAST는 특별한 목적으로 배포된 애플리케이션을 검사합니다. 이후에는 DAST 대상 브랜치를 덮어쓰기하지 않는 한, 앱이 삭제됩니다.
- 기능 브랜치에서는 Review App을 검사합니다.
DAST 스캔이 완료되면, 모든 보안 경고가 보안 대시보드 및 머지 요청 위젯에 표시됩니다.
자세한 내용은 동적 응용 프로그램 보안 테스트(DAST)를 참조하십시오.
DAST 대상 덮어쓰기
자동으로 배포된 Review Apps 대신에 사용자 정의 대상을 사용하려면 DAST_WEBSITE
CI/CD 변수를 대상 URL로 설정하십시오.
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
자동 Browser Performance Testing은 Sitespeed.io container를 사용하여 웹 페이지의 브라우저 성능을 메트릭하고, 각 페이지의 전반적인 성능 점수를 포함한 JSON 보고서를 생성하고, 보고서를 artifact로 업로드합니다. 기본적으로 리뷰 및 프로덕션 환경의 루트 페이지를 테스트합니다. 추가 URL을 테스트하려면 루트 디렉터리에 .gitlab-urls.txt
라는 파일을 만들고 각 행에 하나의 파일 경로를 추가하십시오. 예를 들어:
/
/features
/direction
소스와 타깃 브랜치 간의 브라우저 성능 차이 또한 머지 요청 위젯에서 표시됩니다.
Auto Load Performance Testing
자동 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가 설치되어 있었습니다.
GitLab 배포 토큰
내부 및 비공개 프로젝트에 대해 GitLab이 활성화되면 GitLab Deploy 토큰이 생성되고 Auto DevOps 설정이 저장됩니다. 레지스트리에 대한 영구 액세스에 배포 토큰을 사용할 수 있습니다. 매뉴얼으로 GitLab Deploy 토큰을 취소한 후에는 자동으로 생성되지 않습니다.
GitLab Deploy 토큰을 찾을 수 없는 경우 CI_REGISTRY_PASSWORD
을 사용합니다.
CI_REGISTRY_PASSWORD
은 배포 중에만 유효합니다. Kubernetes는 배포 중에 컨테이너 이미지를 성공적으로 가져올 수 있지만, 포드 이전과 같이 이미지를 다시 가져와야 하는 경우, Kubernetes는 CI_REGISTRY_PASSWORD
를 사용하여 이미지를 가져오려고 시도하지만 이때 성공하지 못할 수 있습니다.Kubernetes 1.16+
deploymentApiVersion
설정의 기본값이 extensions/v1beta
에서 apps/v1
로 변경되었습니다.Kubernetes 1.16 이상에서 extensions/v1beta1
버전에서 Deployment
를 지원하는 등 여러 API가 제거되었습니다.
Kubernetes 1.16+ 클러스터에서 Auto Deploy를 사용하려면:
-
GitLab 13.0 이상에서 애플리케이션을 처음으로 배포하는 경우 변경 구성이 필요하지 않습니다.
-
AUTO_DEVOPS_POSTGRES_CHANNEL
이1
로 설정된 클러스터에 인클러스터 PostgreSQL 데이터베이스가 설치되어 있는 경우, PostgreSQL을 업그레이드하는 안내에 따르세요.
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 작업 비활성화에 대해 더 읽어보세요.