Auto DevOps의 단계

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

다음 섹션들은 Auto DevOps의 각 단계를 설명합니다. 각각이 어떻게 작동하는지 이해하는 데 주의 깊게 읽으십시오.

자동 빌드

참고: Docker in Docker가 GitLab 러너에서 사용할 수 없는 경우(예: OpenShift 클러스터) Auto Build를 지원하지 않습니다. GitLab의 OpenShift 지원은 전용 에픽에서 추적됩니다.

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

Dockerfile을 사용한 자동 빌드

프로젝트 저장소에 Dockerfile이 포함되어 있으면 Auto Build는 docker build를 사용하여 Docker 이미지를 만듭니다.

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

Cloud Native Buildpacks를 사용한 자동 빌드

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

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

각 빌드팩은 Auto Build가 응용 프로그램을 성공적으로 빌드하려면 프로젝트 저장소에 특정 파일이 포함되어 있어야 합니다. 구조는 빌더 및 선택한 빌드팩에 따라 달라집니다. 예를 들어, 기본값인 Heroku 빌더를 사용할 때 응용 프로그램의 루트 디렉터리에 해당 응용 프로그램의 언어에 적합한 파일이 있어야 합니다:

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

다른 언어 및 프레임워크의 요구 사항에 대한 자세한 내용은 Heroku 빌드팩 문서를 참조하십시오.

참고: 아직 테스트 스위트 감지가 Cloud Native Buildpack 사양의 일부가 아니기 때문에 Auto Test는 여전히 Herokuish를 사용합니다. 자세한 내용은 이슈 212689를 참조하십시오.

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

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

변수 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 문서에서 볼륨 정의에 대해 자세히 읽어보세요(https://buildpacks.io/docs/for-platform-operators/how-to/integrate-ci/pack/cli/pack_build/).

Herokuish를 사용한 자동 빌드(사용 중지됨)

  • GitLab 14.0에서 클라우드 네이티브 빌드팩으로 대체되었습니다.

경고: Herokuish 지원은 GitLab 15.8에서 사용 중지되었으며, 17.0에서 제거 예정입니다. 대신 Cloud Native Buildpacks를 사용하십시오.

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

참고: 빌드팩 요구 사항을 충족하는 프로젝트라도 자동 빌드에 실패하는 경우, 문제 해결에 도움이 될 수 있는 자세한 로깅을 활성화하기 위해 프로젝트 CI/CD 변수 TRACE=true를 설정하십시오.

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로 접두사를 붙여야 합니다.

자동 테스트(사용 중지됨)

경고: GitLab 15.8에서 Herokuish 지원이 사용 중지되었으며, Auto Test도 사용 중지될 예정입니다.

Auto Test는 Herokuish와 Heroku buildpacks를 사용하여 귀하의 프로젝트를 분석하여 언어와 프레임워크를 감지한 후 응용 프로그램에 적합한 테스트를 실행합니다. 몇 가지 언어와 프레임워크는 자동으로 감지되지만 귀하의 언어가 감지되지 않은 경우 사용자 정의 빌드팩을 만들 수도 있습니다. (현재 지원되는 언어](#currently-supported-languages)를 확인하십시오.

Auto Test는 응용 프로그램 내에서 이미 가지고 있는 테스트를 사용합니다. 테스트가 없는 경우 해당 테스트를 추가하는 것은 여러분의 책임입니다.

참고: Auto Build에서 지원하는 모든 빌드팩이 Auto Test에서 지원되는 것은 아닙니다. Auto Test는 Herokuish를 사용하며 Cloud Native Buildpacks를 지원하지 않으며 Testpack API를 구현한 빌드팩만 지원됩니다.

현재 지원되는 언어

모든 빌드팩이 Auto Test를 아직 지원하지는 않으며, 이는 비교적 새로운 개선 사항이기 때문입니다. Heroku의 공식적으로 지원하는 언어](https://devcenter.heroku.com/articles/heroku-ci#supported-languages)는 모두 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

만일 귀하의 응용 프로그램이 위 목록에 없는 빌드팩이 필요한 경우 사용자 정의 빌드팩을 사용할 수 있습니다.

자동 코드 품질

  • 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 이상이 필요합니다.

보고서를 생성한 후에는 나중에 다운로드하여 확인할 수 있는 artifact로 업로드됩니다. 또한, 병합 요청 위젯은 Ultimate 라이선스에서 발생하는 보안 경고를 표시합니다.

자세한 내용은 정적 응용 프로그램 보안 테스트(SAST)를 참조하세요.

자동 시크릿 감지

  • GitLab 13.1에서 소개되었습니다.
  • GitLab 13.3에서 모든 티어에서 선택 기능을 사용할 수 있습니다.

시크릿 감지는 현재 코드에서 Secret Detection Docker 이미지를 사용하여 시크릿 감지를 실행하고 누출된 시크릿을 확인합니다. 자동 시크릿 감지에는 GitLab Runner 11.5 이상이 필요합니다.

보고서를 생성한 후에는 나중에 다운로드하여 평가할 수 있는 artifact로 업로드됩니다. 또한, 병합 요청 위젯은 Ultimate 라이선스에서 발생하는 보안 경고를 표시합니다.

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

자동 의존성 스캔

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

의존성 스캔은 프로젝트의 종속성에 대해 분석하고 잠재적인 보안 문제를 확인합니다. 자동 의존성 스캔 단계는 Ultimate 이외의 라이선스에서는 건너뛰며, GitLab Runner 11.5 이상이 필요합니다.

보고서를 생성한 후에는 나중에 다운로드하여 확인할 수 있는 artifact로 업로드됩니다. 병합 요청 위젯은 감지된 보안 경고를 표시합니다.

자세한 내용은 의존성 스캔를 참조하세요.

자동 컨테이너 스캔

컨테이너의 취약점 정적 분석은 Trivy를 사용하여 Docker 이미지의 잠재적인 보안 문제를 확인합니다. 자동 컨테이너 스캔 단계는 Ultimate 이외의 라이선스에서는 건너뛰어집니다.

보고서를 생성한 후에는 나중에 다운로드하여 확인할 수 있는 artifact로 업로드됩니다. 병합 요청은 감지된 보안 문제를 표시합니다.

자세한 내용은 컨테이너 스캔를 참조하세요.

자동 리뷰 앱

이 단계는 쿠버네티스 클러스터를 사용할 수 없는 프로젝트가 많기 때문에 선택 사항입니다. requirements가 충족되지 않으면 작업이 조용히 건너뛰어집니다.

리뷰 앱은 브랜치 코드를 기반으로 한 일시적인 응용 프로그램 환경이며, 개발자, 디자이너, QA, 제품 관리자 및 기타 리뷰어가 실제로 리뷰 프로세스의 일환으로 코드 변경을 보고 상호 작용할 수 있게 합니다. 자동 리뷰 앱은 각 브랜치에 대해 리뷰 앱을 생성합니다.

자동 리뷰 앱은 애플리케이션을 쿠버네티스 클러스터로만 배포합니다. 클러스터가 없으면 배포가 이루어지지 않습니다.

리뷰 앱은 프로젝트 ID, 브랜치 또는 태그 이름, 고유 번호 및 Auto DevOps 기본 도메인과의 결합으로 고유한 URL을 갖습니다. 예를 들면 13083-review-project-branch-123456.example.com입니다. 병합 요청 위젯은 리뷰 앱에 대한 링크를 손쉽게 찾을 수 있도록 표시합니다. 브랜치 또는 태그가 삭제되면, 예를 들어 병합 요청을 합병한 후에는 리뷰 앱도 삭제됩니다.

리뷰 앱은 Helm을 사용하여 배포되며, customization할 수 있습니다. 응용 프로그램은 환경에 대한 Kubernetes namespace로 배포됩니다.

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

경고: 앱은 반드시 Helm을 사용하여 (Kubernetes를 직접 사용하는 대신에) 조작해야 합니다. 이렇게 하면 Helm이 변경 사항을 감지하지 못하고 이로 인해 Auto DevOps가 변경 사항을 취소할 수 있습니다. 또한, 변경한 내용을 되돌리려면 다시 배포해야 하지만, Helm은 처음에 변경 사항을 감지하지 못할 수 있으므로 이전 구성을 다시 적용해야 한다는 것을 깨닫지 못할 수 있습니다.

Auto DAST

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

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

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

DAST 스캔이 완료되면 보안 경고가 보안 대시 보드와 병합 요청 위젯에 표시됩니다.

더 많은 정보는 Dynamic Application Security Testing (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"로 설정하여 기능 브랜치에서만, 리뷰 응용 프로그램도 비활성화할 수 있습니다.

Auto Browser 성능 테스트

Tier: 프리미엄, 얼티메이트 Offering: GitLab.com, 자체 관리, GitLab 전용
  • GitLab 10.4에서 도입되었습니다.

자동 브라우저 성능 테스트는 Sitespeed.io 컨테이너를 사용하여 웹 페이지의 브라우저 성능을 측정하고 각 페이지에 대한 전반적인 성능 점수를 포함한 JSON 보고서를 작성하고 아티팩트로 업로드합니다. 기본적으로 리뷰 및 프로덕션 환경의 루트 페이지를 테스트합니다. 추가 URL을 테스트하려면 루트 디렉터리에 .gitlab-urls.txt라는 이름의 파일에 한 줄에 하나씩 경로를 추가하세요. 예를 들어: 

/
/features
/direction

소스와 타깃 브랜치 간의 브라우저 성능 차이도 병합 요청 위젯에 표시됩니다.

Auto 부하 성능 테스트

Tier: 프리미엄, 얼티메이트 Offering: GitLab.com, 자체 관리, GitLab 전용
  • GitLab 13.2에서 도입되었습니다.

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

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

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

자동 배포

  • GitLab 13.6에서 도입되었습니다. Amazon Elastic Compute Cloud (Amazon EC2)에 배포할 수 있는 선택권이 제공됩니다.

자동 배포는 옵션입니다. Auto DevOps를 위한 단계입니다. 요구 사항을 충족하지 않으면 작업이 건너뜁니다.

브랜치나 병합 요청이 프로젝트의 기본 브랜치로 병합되면 Auto Deploy는 프로젝트 이름 및 고유 프로젝트 ID에 기반한 Kubernetes 클러스터의 production 환경으로 응용 프로그램을 배포합니다. Auto Deploy에는 기본적으로 스테이징 또는 캐너리 환경으로의 배포는 포함되어 있지 않지만, Auto DevOps 템플릿을 사용하여 이러한 작업을 활성화할 수 있습니다.

CI/CD 변수를 사용하여 파드 레플리카를 자동으로 확장하거나 Auto DevOps helm upgrade 명령에 사용자 정의 인수를 적용할 수 있습니다. 이는 Auto Deploy Helm 차트를 사용자 정의하는 쉬운 방법입니다.

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

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

경고: 앱은 꼭 Helm 외부에서 조작되어서는 안됩니다(Kubernetes를 직접 사용하지 마십시오). 이것은 Helm이 변경 사항을 감지하지 못하게 하여 이어지는 배포가 변경을 취소하며 혼란을 야기할 수 있습니다. 또한 무언가를 변경하고 배포를 통해 원상 복귀하려면 Helm이 처음부터 변경된 것을 감지하지 않을 수 있으며 그 결과 이전 구성을 다시 적용해야 한다는 사실을 감지하지 못할 수 있습니다.

경고: GitLab 14.0은 Auto Deploy 템플릿을 새로 갱신합니다. v2 auto-deploy-image에서 중단되는 변경으로 인해 Auto DevOps 프로젝트에서 예기치 않은 실패가 발생할 수 있습니다. GitLab 14.0으로 업그레이드하기 전에 업그레이드 가이드에 따라 환경을 업그레이드하세요.

GitLab 배포 토큰

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

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

참고: CI_REGISTRY_PASSWORD는 배포 중에만 유효합니다. 쿠버네티스는 배포 중에 컨테이너 이미지를 성공적으로 가져올 수 있지만, pod 이행 후와 같이 이미지를 다시 가져와야 하는 경우 CI_REGISTRY_PASSWORD를 사용하여 이미지를 가져올 수 없습니다.

쿠버네티스 1.16+

  • GitLab 12.8에서 소개되었습니다.
  • 쿠버네티스 1.16+를 지원하는 PostgreSQL 버전을 배포하는 기능은 GitLab 12.9에서 소개되었습니다.
  • GitLab 13.0부터는 새로운 배포에서 기본 지원됩니다.

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

쿠버네티스 1.16 이상에서 여러 API가 제거되었습니다, extensions/v1beta1 버전에서의 Deployment 지원을 포함하여.

쿠버네티스 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을 업그레이드하는 가이드에 따르십시오.

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

경고: GitLab 12.9 및 12.10에서 AUTO_DEVOPS_POSTGRES_CHANNEL 버전 2를 선택하면 버전 1 PostgreSQL 데이터베이스가 삭제됩니다. 버전 2로 변경하기 전에 데이터베이스를 백업하고 복원하려면 PostgreSQL 업그레이드 가이드를 따르십시오 (GitLab 13.0에서 데이터베이스 삭제를 트리거하는 추가 CI/CD 변수가 필요합니다).

마이그레이션

프로젝트 CI/CD 변수 DB_INITIALIZE 및 DB_MIGRATE를 설정하여 PostgreSQL을 위한 데이터베이스 초기화 및 마이그레이션을 응용 프로그램 pod 내에서 실행할 수 있습니다.

DB_INITIALIZE가 존재하는 경우, 일부 애플리케이션은 성공적인 데이터베이스 초기화 단계 없이 실행할 수 없기 때문에 GitLab은 애플리케이션 배포가 아닌 처음 릴리스를 데이터베이스 초기화 단계만 실행합니다. 데이터베이스 초기화가 완료되면 표준 애플리케이션 배포와 함께 두 번째 릴리스를 배포합니다.

포스트-인스톨 후크는 배포가 성공하면 이후에는 DB_INITIALIZE가 처리되지 않음을 의미합니다.

DB_MIGRATE가 존재하는 경우, 일부 애플리케이션은 Helm 프리-업그레이드 후크로서 애플리케이션 pod 내에서 셸 명령으로 실행됩니다.

예를 들어, 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) 애플리케이션이 실행되는 환경을 복제해야 합니다.

Auto-deploy-app 차트 업그레이드

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

Workers

일부 웹 응용 프로그램은 “작업자 프로세스”를 위해 추가 배포를 실행해야 합니다.
예를 들어, Rails 응용 프로그램은 주로 이메일을 보내는 것과 같은 백그라운드 작업을 실행하기 위해 별도의 작업자 프로세스를 사용합니다.

Auto Deploy에 사용되는 기본 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

컨테이너에서 명령어 실행

Auto Build를 사용하여 빌드된 응용 프로그램은 (repository에 사용자 정의 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 코드 인텔리전스는 상호 작용적인 개발 환경 (IDE)에서 흔히 볼 수 있는 코드 탐색 기능을 추가하며, 이는 유형 서명, 심볼 문서, 정의로 이동 등을 포함합니다. 이는 LSIF에 의해 구동되며, Go 언어만 사용하는 Auto DevOps 프로젝트에서 사용할 수 있습니다. 더 많은 LSIF 인덱서를 사용할 수 있게 되면 GitLab은 더 많은 언어를 지원할 계획입니다. 업데이트를 위해 코드 인텔리전스 epic를 따를 수 있습니다.

이 단계는 기본적으로 활성화되어 있습니다. CODE_INTELLIGENCE_DISABLED CI/CD 변수를 추가하여 비활성화할 수 있습니다. Auto DevOps jobs 비활성화에 대해 자세히 알아보세요.