Auto DevOps 도메인 설정, 커스텀 Helm 차트 제공, 또는 애플리케이션 스케일링을 위해 CI/CD 변수를 사용하세요.

빌드 및 배포 변수#

이 변수들을 사용해 빌드를 커스터마이징하고 배포하세요.

데이터베이스 변수#

GitLab 16.0부터 POSTGRES_ENABLED는 기본적으로 설정되지 않습니다.

CI/CD를 PostgreSQL 데이터베이스와 통합하려면 이 변수들을 사용하세요.

Job 건너뛰기 변수#

이 변수들을 사용해 특정 유형의 CI/CD job을 건너뛰세요. 건너뛴 경우 CI/CD job이 생성되거나 실행되지 않습니다.

애플리케이션 시크릿 변수 구성#

일부 배포된 애플리케이션은 시크릿 변수에 대한 액세스가 필요합니다. Auto DevOps는 K8S_SECRET_으로 시작하는 CI/CD 변수를 감지하고, 배포된 애플리케이션에 환경 변수로 제공합니다.

사전 요구사항:

• 변수 값은 한 줄이어야 합니다.

시크릿 변수를 구성하려면:

• 상단 표시줄에서 검색 또는 이동을 선택하고 프로젝트를 찾으세요.

• 왼쪽 사이드바에서 설정 > CI/CD를 선택하세요.

• 변수를 펼치세요.

• K8S_SECRET_ 접두사로 CI/CD 변수를 생성하세요. 예를 들어, K8S_SECRET_RAILS_MASTER_KEY라는 변수를 만들 수 있습니다.

• 새 파이프라인을 수동으로 생성하거나 GitLab에 코드 변경을 푸시하여 Auto DevOps 파이프라인을 실행하세요.

쿠버네티스 시크릿#

Auto DevOps 파이프라인은 애플리케이션 시크릿 변수를 사용해 쿠버네티스 시크릿을 채웁니다. 이 시크릿은 환경마다 고유합니다. 애플리케이션을 배포할 때 시크릿은 애플리케이션을 실행하는 컨테이너의 환경 변수로 로드됩니다. 예를 들어, K8S_SECRET_RAILS_MASTER_KEY라는 시크릿을 생성하면 쿠버네티스 시크릿은 다음과 같이 표시될 수 있습니다:

$ kubectl get secret production-secret -n minimal-ruby-app-54 -o yaml

apiVersion: v1
data:
  RAILS_MASTER_KEY: MTIzNC10ZXN0
kind: Secret
metadata:
  creationTimestamp: 2018-12-20T01:48:26Z
  name: production-secret
  namespace: minimal-ruby-app-54
  resourceVersion: "429422"
  selfLink: /api/v1/namespaces/minimal-ruby-app-54/secrets/production-secret
  uid: 57ac2bfd-03f9-11e9-b812-42010a9400e4
type: Opaque

애플리케이션 시크릿 업데이트#

환경 변수는 일반적으로 쿠버네티스 Pod에서 변경할 수 없습니다. 애플리케이션 시크릿을 업데이트하고 수동으로 새 파이프라인을 생성하면 실행 중인 애플리케이션은 업데이트된 시크릿을 수신하지 못합니다.

애플리케이션 시크릿을 업데이트하려면 다음 중 하나를 수행하세요:

• 코드 업데이트를 GitLab에 푸시하여 쿠버네티스 배포가 Pod를 재생성하도록 강제하세요.

• 실행 중인 Pod를 수동으로 삭제하여 쿠버네티스가 업데이트된 시크릿으로 새 Pod를 생성하도록 하세요.

Auto DevOps 스크립팅 환경의 제한으로 인해 여러 줄 값이 있는 변수는 지원되지 않습니다.

레플리카 변수 구성#

배포를 스케일링하려면 레플리카 변수를 추가하세요:

• 프로젝트 CI/CD 변수로 레플리카 변수를 추가하세요.

• 애플리케이션을 스케일링하려면 재배포하세요.

커스텀 레플리카 변수#

__REPLICAS 형식으로 커스텀 레플리카 변수를 만들 수 있습니다:

• 는 Helm Chart 앱 정의에서 설정된 track 쿠버네티스 라벨의 대문자 값입니다. track이 설정되지 않은 경우 커스텀 변수에서 를 생략하세요.

• 는 .gitlab-ci.yml에서 설정된 deploy job의 대문자 환경 이름입니다.

예를 들어, 환경이 qa이고 트랙이 foo인 경우 FOO_QA_REPLICAS라는 환경 변수를 만드세요:

QA testing:
  stage: deploy
  environment:
    name: qa
  script:
    - deploy foo

트랙 foo는 애플리케이션의 Helm 차트에 정의되어 있어야 합니다. 예를 들어:

replicaCount: 1
image:
  repository: gitlab.example.com/group/project
  tag: stable
  pullPolicy: Always
  secrets:
    - name: gitlab-registry
application:
  track: foo
  tier: web
service:
  enabled: true
  name: web
  type: ClusterIP
  url: http://my.host.com/
  externalPort: 5000
  internalPort: 5000

스테이징 및 프로덕션 환경의 배포 정책#

Auto DevOps는 일반적으로 지속적 배포를 사용하며, 기본 브랜치에서 새 파이프라인이 실행될 때마다 production 환경에 자동으로 푸시합니다. 프로덕션에 수동으로 배포하려면 STAGING_ENABLED CI/CD 변수를 사용할 수 있습니다.

STAGING_ENABLED를 설정하면 GitLab이 자동으로 애플리케이션을 staging 환경에 배포합니다. 프로덕션에 배포할 준비가 되면 GitLab이 production_manual job을 생성합니다.

프로젝트 설정에서 수동 배포를 활성화할 수도 있습니다.

Canary 환경의 배포 정책#

프로덕션에 변경 사항을 배포하기 전에 Canary 환경을 사용할 수 있습니다.

CANARY_ENABLED를 설정하면 GitLab이 두 개의 수동 job을 생성합니다:

• canary - 애플리케이션을 Canary 환경에 배포합니다.

• production_manual - 애플리케이션을 프로덕션에 배포합니다.

프로덕션으로의 점진적 롤아웃#

점진적 롤아웃을 사용해 소수의 Pod로 시작하여 애플리케이션을 지속적으로 배포하세요. Pod 수를 수동으로 늘릴 수 있습니다.

프로젝트 설정에서 수동 배포를 활성화하거나, INCREMENTAL_ROLLOUT_MODE를 manual로 설정할 수 있습니다.

INCREMENTAL_ROLLOUT_MODE를 manual로 설정하면 GitLab이 네 개의 수동 job을 생성합니다:

• rollout 10%

• rollout 25%

• rollout 50%

• rollout 100%

비율은 REPLICAS CI/CD 변수를 기반으로 하며, 배포에 사용되는 Pod 수를 정의합니다. 예를 들어, 값이 10이고 10% 롤아웃 job을 실행하면 애플리케이션은 하나의 Pod에만 배포됩니다.

롤아웃 job은 임의의 순서로 실행할 수 있습니다. 스케일 다운하려면 더 낮은 비율의 job을 다시 실행하세요.

rollout 100% job을 실행한 후에는 스케일 다운할 수 없으며, 배포를 롤백해야 합니다.

점진적 롤아웃 구성 예시#

INCREMENTAL_ROLLOUT_MODE 없이, STAGING_ENABLED 없이:

[

](/19.1/topics/autodevops/img/rollout_staging_disabled_v11_0.png)

INCREMENTAL_ROLLOUT_MODE 없이, STAGING_ENABLED 포함:

[

](/19.1/topics/autodevops/img/staging_enabled_v11_0.png)

INCREMENTAL_ROLLOUT_MODE를 manual로 설정하고 STAGING_ENABLED 없이:

[

](/19.1/topics/autodevops/img/rollout_enabled_v10_8.png)

INCREMENTAL_ROLLOUT_MODE를 manual로 설정하고 STAGING_ENABLED 포함:

[

](/19.1/topics/autodevops/img/rollout_staging_enabled_v11_0.png)

프로덕션으로의 시간 기반 점진적 롤아웃#

시간 기반 점진적 롤아웃을 사용해 소수의 Pod로 시작하여 애플리케이션을 지속적으로 배포하세요.

프로젝트 설정에서 시간 기반 점진적 배포를 활성화하거나, INCREMENTAL_ROLLOUT_MODE CI/CD 변수를 timed로 설정할 수 있습니다.

INCREMENTAL_ROLLOUT_MODE를 timed로 설정하면 GitLab이 네 개의 job을 생성합니다:

• timed rollout 10%

• timed rollout 25%

• timed rollout 50%

• timed rollout 100%

job 사이에는 5분의 지연이 있습니다.