- 자동 빌드
- 자동 테스트
- 자동 코드 품질
- 자동 SAST
- 자동 비밀 탐지
- 자동 종속성 스캐닝
- 자동 컨테이너 스캐닝
- 자동 리뷰 앱
- 자동 DAST
- 자동 브라우저 성능 테스트
- 자동 로드 성능 테스트
- 자동 배포
- 자동 코드 인텔리전스
Auto DevOps의 단계
다음 섹션에서는 Auto DevOps의 단계에 대해 설명합니다.
각 단계가 어떻게 작동하는지 이해할 수 있도록 주의 깊게 읽어보세요.
자동 빌드
자동 빌드는 기존의 Dockerfile 또는 Heroku 빌드팩을 사용하여 애플리케이션의 빌드를 생성합니다. 생성된 Docker 이미지는 컨테이너 레지스트리로 푸시되며 커밋 SHA 또는 태그로 태그가 지정됩니다.
Dockerfile을 사용한 자동 빌드
프로젝트의 리포지토리에 루트에 Dockerfile이 포함되어 있으면, 자동 빌드는 docker build를 사용하여 Docker 이미지를 생성합니다.
자동 리뷰 앱과 자동 배포를 함께 사용하는 경우, 자신만의 Dockerfile을 제공하기로 선택했다면 다음 중 하나를 수행해야 합니다:
-
기본 Helm 차트에서 이 포트가 사용 가능한 것으로 가정하므로 애플리케이션을 포트
5000으로 노출하세요. - 자동 배포 Helm 차트를 사용자 정의하여 기본 값을 덮어쓰세요.
클라우드 네이티브 빌드팩을 사용한 자동 빌드
자동 빌드는 프로젝트에 Dockerfile이 있는 경우 이를 사용하여 애플리케이션을 빌드합니다. Dockerfile이 없는 경우, 자동 빌드는 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로 이동하기
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로 접두사를 붙여야 합니다.
자동 테스트
자동 테스트는 Herokuish 및 Heroku 빌드팩을 사용하여 당신의 애플리케이션에 적합한 테스트를 실행하며, 프로젝트를 분석하여 언어와 프레임워크를 감지합니다. 여러 언어와 프레임워크가 자동으로 감지되지만, 언어가 감지되지 않는 경우 사용자 정의 빌드팩을 만들 수 있습니다. 현재 지원되는 언어를 확인하세요.
자동 테스트는 애플리케이션에 이미 있는 테스트를 사용합니다. 테스트가 없다면, 추가하는 것은 당신의 몫입니다.
알림: 자동 빌드에 의해 지원되는 모든 빌드팩이 자동 테스트에서 지원되는 것은 아닙니다. 자동 테스트는 Herokuish를 사용하며, Cloud Native Buildpacks가 아닙니다. 그리고 Testpack API를 구현하는 빌드팩만 지원됩니다.
현재 지원되는 언어
모든 빌드팩이 자동 테스트를 지원하는 것은 아닙니다. 이는 비교적 새로운 개선 사항이기 때문입니다. Heroku의 공식 지원 언어는 자동 테스트를 지원합니다. 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
애플리케이션에 위의 목록에 없는 빌드팩이 필요하다면, 사용자 정의 빌드팩을 사용할 수 있습니다.
자동 코드 품질
- GitLab Starter에서 GitLab Free로 13.2에 이동됨.
자동 코드 품질은 코드 품질 이미지를 사용하여 현재 코드에 대한 정적 분석 및 기타 코드 검사를 실행합니다. 보고서를 생성한 후, 아티팩트로 업로드되며, 나중에 다운로드하고 확인할 수 있습니다. 병합 요청 위젯은 또한 소스와 대상 브랜치 간의 차이를 표시합니다.
자동 SAST
- GitLab Ultimate 10.3에서 도입됨.
- 13.1부터 모든 티어에서 사용 가능한 기능 선택
정적 애플리케이션 보안 테스트(Static Application Security Testing, SAST)는 현재 코드에 대한 정적 분석을 수행하고 잠재적인 보안 문제를 확인합니다.
자동 SAST 단계는 GitLab Runner 11.5 이상이 필요합니다.
보고서를 생성한 후, 이는 아티팩트로 업로드되며, 나중에 다운로드하고 확인할 수 있습니다. 병합 요청 위젯은 Ultimate 라이선스의 보안 경고도 표시합니다.
자세한 내용은 정적 애플리케이션 보안 테스트(SAST)를 참조하세요.
자동 비밀 탐지
비밀 탐지(Secret Detection)는 현재 코드에서 비밀 탐지를 수행하고 누출된 비밀을 확인하기 위해 비밀 탐지 Docker 이미지를 사용합니다.
보고서를 생성한 후, 이는 아티팩트로 업로드되며, 나중에 다운로드하고 평가할 수 있습니다. 병합 요청 위젯은 Ultimate 라이선스의 보안 경고도 표시합니다.
자세한 내용은 비밀 탐지를 참조하세요.
자동 종속성 스캐닝
종속성 스캐닝(Dependency Scanning)은 프로젝트의 종속성에 대한 분석을 수행하고 잠재적인 보안 문제를 확인합니다.
자동 종속성 스캐닝 단계는 Ultimate가 아닌 라이선스에서는 건너뜁니다.
보고서를 생성한 후, 이는 아티팩트로 업로드되며, 나중에 다운로드하고 확인할 수 있습니다. 병합 요청 위젯은 감지된 보안 경고를 표시합니다.
자세한 내용은 종속성 스캐닝을 참조하세요.
자동 컨테이너 스캐닝
컨테이너에 대한 취약점 정적 분석은 Trivy를 사용하여 Docker 이미지의 잠재적인 보안 문제를 확인합니다.
자동 컨테이너 스캐닝 단계는 Ultimate가 아닌 라이선스에서는 건너뜁니다.
보고서를 생성한 후, 이는 아티팩트로 업로드되며, 나중에 다운로드하고 확인할 수 있습니다. 병합 요청은 감지된 보안 문제를 표시합니다.
자세한 내용은 컨테이너 스캐닝을 참조하세요.
자동 리뷰 앱
이는 선택적 단계입니다. 많은 프로젝트에서 사용 가능한 Kubernetes 클러스터가 없기 때문입니다. 요구 사항이 충족되지 않으면 작업은 조용히 건너뜁니다.
리뷰 앱은 브랜치 코드 기반의 임시 애플리케이션 환경으로, 개발자, 디자이너, QA, 제품 관리자 및 기타 리뷰어가 코드 변경 사항을 검토 과정의 일환으로 실제로 보고 상호 작용할 수 있도록 합니다. 자동 리뷰 앱은 각 브랜치에 대한 리뷰 앱을 생성합니다.
자동 리뷰 앱은 애플리케이션을 Kubernetes 클러스터로만 배포합니다. 클러스터가 없으면 배포가 발생하지 않습니다.
리뷰 앱은 프로젝트 ID, 브랜치 또는 태그 이름, 고유 번호 및 Auto DevOps 기본 도메인의 조합을 기반으로 하는 고유한 URL을 가집니다. 예를 들어 13083-review-project-branch-123456.example.com과 같은 형식입니다. 병합 요청 위젯은 쉽게 찾을 수 있도록 리뷰 앱에 대한 링크를 표시합니다. 브랜치 또는 태그가 삭제되면, 병합 요청 후 리뷰 앱도 삭제됩니다.
리뷰 앱은 Helm을 사용하여 auto-deploy-app 차트를 이용해 배포되며, 이를 사용자 정의할 수 있습니다. 애플리케이션은 환경을 위한 Kubernetes 네임스페이스로 배포됩니다.
로컬 Tiller가 사용됩니다. 이전 버전의 GitLab은 프로젝트 네임스페이스에 Tiller가 설치되었습니다.
경고: 귀하의 앱은 Helm 외부에서 (Kubernetes를 직접 사용하여) 조작되어서는 안 됩니다. 이로 인해 Helm이 변경 사항을 감지하지 못하고 Auto DevOps의 후속 배포가 변경 사항을 되돌릴 수 있습니다. 또한, 변경 사항이 있고 다시 배포하여 이를 되돌리고 싶을 경우, Helm이 처음에 아무것도 변경되지 않았다고 인식할 수 있으므로 이전 구성을 다시 적용해야 한다는 것을 알지 못할 수 있습니다.
자동 DAST
Dynamic Application Security Testing (DAST)는 인기 있는 오픈 소스 도구인
OWASP ZAProxy를 사용하여 현재 코드를 분석하고
잠재적인 보안 문제를 확인합니다. Auto DAST 단계는 Ultimate가 아닌
라이센스에서는 건너뜁니다.
- 기본 브랜치에서 DAST는 해당 용도로 배포된 애플리케이션을 스캔합니다.
단, 대상 브랜치를 오버라이드하지 않은 경우에 한합니다.
DAST가 실행된 후 애플리케이션은 삭제됩니다. - 기능 브랜치에서는 DAST가 검토 앱을 스캔합니다.
DAST 스캔이 완료되면 보안 경고가
보안 대시보드와
병합 요청 위젯에 표시됩니다.
자세한 내용은
동적 애플리케이션 보안 테스트 (DAST)를 참조하세요.
DAST 대상 오버라이드
자동으로 배포된 검토 앱 대신 사용자 정의 대상을 사용하려면,
DAST_WEBSITE CI/CD 변수를 DAST가 스캔할 URL로 설정하세요.
활성화되어 있는 경우, GitLab은 절대
DAST_WEBSITE를 어떤 스테이징 또는 프로덕션 환경으로 설정하지 말 것을 강력히 권장합니다.DAST 전체 스캔은 대상을 적극적으로 공격하며, 이로 인해 애플리케이션이 중단되거나
데이터 손실 또는 손상이 발생할 수 있습니다.
자동 DAST 비활성화
다음과 같이 DAST를 비활성화할 수 있습니다:
- 모든 브랜치에서
DAST_DISABLEDCI/CD 변수를"true"로 설정합니다. - 기본 브랜치에서만
DAST_DISABLED_FOR_DEFAULT_BRANCH변수를
"true"로 설정합니다. - 기능 브랜치에서만
REVIEW_DISABLED변수를
"true"로 설정합니다. 이 경우 검토 앱도 비활성화됩니다.
자동 브라우저 성능 테스트
자동 브라우저 성능 테스트는
웹 페이지의 브라우저 성능을 측정하고,
Sitespeed.io 컨테이너를 사용하여
각 페이지에 대한 전체 성능 점수를 포함한 JSON 보고서를 생성하고,
보고서를 아티팩트로 업로드합니다. 기본적으로 검토 및 프로덕션 환경의 루트 페이지를 테스트합니다.
추가 URL을 테스트하려면, 루트 디렉터리에 .gitlab-urls.txt라는 파일에 경로를 추가하세요.
파일당 한 줄로 입력해야 합니다. 예:
/
/features
/direction
소스 브랜치와 대상 브랜치 간의 브라우저 성능 차이는
병합 요청 위젯에도
표시됩니다.
자동 로드 성능 테스트
자동 로드 성능 테스트는
k6 컨테이너를 사용하여
애플리케이션의 서버 성능을 측정하고,
여러 주요 결과 메트릭을 포함한 JSON 보고서를 생성하여
보고서를 아티팩트로 업로드합니다.
일부 초기 설정이 필요합니다. 특정 애플리케이션에 맞춤화된
k6 테스트를 작성해야 합니다. 테스트는 환경의 동적 URL를
CI/CD 변수를 통해 찾아낼 수 있도록 구성해야 합니다.
소스 브랜치와 대상 브랜치 간의 로드 성능 테스트 결과 차이는
병합 요청 위젯에도
표시됩니다.
자동 배포
Kubernetes 클러스터 외에도 Amazon Elastic Compute Cloud (Amazon EC2)에 배포할 수 있는 선택권이 있습니다.
자동 배포는 Auto DevOps의 선택적 단계입니다. 요구 사항을 충족하지 않으면, 작업이 건너뛰어집니다.
브랜치나 머지 요청이 프로젝트의 기본 브랜치에 병합된 후, 자동 배포는 Kubernetes 클러스터의 production 환경에 애플리케이션을 배포하며, 프로젝트 이름과 고유 프로젝트 ID에 기반한 네임스페이스를 사용하여 project-4321과 같은 형식으로 됩니다.
자동 배포는 기본적으로 스테이징 또는 카나리 환경에 대한 배포를 포함하지 않지만, Auto DevOps 템플릿에는 이를 활성화하려는 경우 이러한 작업에 대한 작업 정의가 포함되어 있습니다.
CI/CD 변수를 사용하여 자동으로 팟 복제본을 확장하고 Auto DevOps의 helm upgrade 명령에 사용자 지정 인수를 적용할 수 있습니다. 이는 자동 배포 헬름 차트 사용자 지정의 쉬운 방법입니다.
Helm은 auto-deploy-app 차트를 사용하여 애플리케이션을 해당 Kubernetes 네임스페이스로 배포합니다.
로컬 Tiller가 사용됩니다. 이전 버전의 GitLab에서는 프로젝트 네임스페이스에 Tiller가 설치되었습니다.
경고:
당신의 애플리케이션은 Helm 외부에서(쿠버네티스를 직접 사용하여) 조작되지 않아야 합니다.
이로 인해 Helm이 변경 사항을 감지하지 못할 수 있으며, Auto DevOps로 인한 후속 배포는 당신의 변경 사항을 되돌릴 수 있습니다.
또한, 만약 무언가 변경하고 그것을 다시 배포하여 되돌리려면, Helm은 처음에 변경된 것이 감지되지 않을 수 있어
구버전 구성을 재적용할 필요가 있음을 인식하지 못할 수 있습니다.
GitLab 배포 토큰
GitLab 배포 토큰은 Auto DevOps가 활성화되고 Auto DevOps 설정이 저장될 때 내부 및 비공개 프로젝트에 대해 생성됩니다.
영구적으로 레지스트리에 접근할 수 있는 배포 토큰을 사용할 수 있습니다.
수동으로 GitLab 배포 토큰을 취소하면 자동으로 생성되지 않습니다.
GitLab 배포 토큰을 찾을 수 없는 경우, CI_REGISTRY_PASSWORD가 사용됩니다.
참고:
CI_REGISTRY_PASSWORD는 배포 중에만 유효합니다.
Kubernetes는 배포 중에 컨테이너 이미지를 성공적으로 가져올 수 있지만, 만약 팟 퇴거 후와 같이 이미지를 다시 끌어와야 하는 경우,
Kubernetes는 CI_REGISTRY_PASSWORD를 사용하여 이미지를 가져오려고 시도하므로 그러한 작업을 수행할 수 없습니다.
Kubernetes 1.16+
경고:
deploymentApiVersion 설정의 기본값이 extensions/v1beta에서 apps/v1으로 변경되었습니다.
Kubernetes 1.16 및 이후 버전에서는 여러 가지 API가 제거되었습니다,
extensions/v1beta1 버전의 Deployment 지원을 포함하여.
Kubernetes 1.16+ 클러스터에서 자동 배포를 사용하려면:
-
GitLab 13.0 이상에서 애플리케이션을 처음 배포하는 경우,
추가 구성은 필요하지 않아야 합니다. -
AUTO_DEVOPS_POSTGRES_CHANNEL이1로 설정된 클러스터 내 PostgreSQL 데이터베이스가 설치된 경우,
PostgreSQL 업그레이드 가이드를 따라야 합니다.
경고:
PostgreSQL 업그레이드 가이드를 따라 버전 2로 옵션을 선택하기 전에 데이터베이스를 백업하고 복원하십시오.
마이그레이션
PostgreSQL에 대한 데이터베이스 초기화 및 마이그레이션을 애플리케이션 파드 내에서 실행할 수 있도록 프로젝트 CI/CD 변수 DB_INITIALIZE 및 DB_MIGRATE를 설정할 수 있습니다.
DB_INITIALIZE가 존재하는 경우, Helm post-install 후크로 애플리케이션 파드 내에서 셸 명령으로 실행됩니다. 일부 애플리케이션은 성공적인 데이터베이스 초기화 단계 없이 실행할 수 없기 때문에 GitLab은 애플리케이션 배포 없이 첫 번째 릴리스를 배포한 후, 오직 데이터베이스 초기화 단계만 실행합니다. 데이터베이스 초기화가 완료된 후, 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 Web Terminal 사용하기 위해.
예를 들어, 애플리케이션 루트 디렉토리에서 Rails 콘솔을 시작하려면 다음을 실행합니다:
/cnb/lifecycle/launcher procfile exec bin/rails c
자동 코드 인텔리전스
GitLab 코드 인텔리전스는 코드 탐색 기능을 추가하며, 이는 인터랙티브 개발 환경(IDE)에서 일반적으로 사용되는 기능으로, 타입 서명, 심볼 문서화 및 정의로 이동하기 기능을 포함합니다.
이는 LSIF를 기반으로 하며, Go 언어만 사용하는 Auto DevOps 프로젝트에서 사용할 수 있습니다.
GitLab은 더 많은 LSIF 인덱서가 제공됨에 따라 더 많은 언어에 대한 지원을 추가할 계획입니다.
업데이트를 보려면 코드 인텔리전스 에픽을 팔로우하세요.
이 단계는 기본적으로 활성화되어 있습니다.
CODE_INTELLIGENCE_DISABLED CI/CD 변수를 추가하여 비활성화할 수 있습니다.
도움말