• 빌드 및 배포 변수
• 데이터베이스 변수
• 작업 비활성화 변수
• 애플리케이션 비밀 변수 구성
  • Kubernetes 비밀
• 애플리케이션 비밀 업데이트
• 복제 변수 구성
  • 사용자 지정 복제 변수
• 스테이징 및 프로덕션 환경을 위한 배포 정책
• 카나리 환경을 위한 배포 정책
• 프로덕션에 대한 점진적 롤아웃
  • 예시 점진적 롤아웃 구성
• 프로덕션에 대한 시간 제한 점진적 롤아웃

CI/CD 변수

CI/CD 변수를 사용하여 Auto DevOps 도메인을 설정하고, 사용자 정의 Helm 차트를 제공하거나, 애플리케이션을 확장할 수 있습니다.

빌드 및 배포 변수

이 변수를 사용하여 빌드를 사용자 정의하고 배포합니다.

데이터베이스 변수

경고:
GitLab 16.0부터 POSTGRES_ENABLED는 더 이상 기본값으로 설정되지 않습니다.

이 변수를 사용하여 CI/CD를 PostgreSQL 데이터베이스와 통합합니다.

작업 비활성화 변수

이 변수를 사용하여 CI/CD 작업을 비활성화합니다.

애플리케이션 비밀 변수 구성

일부 배포된 애플리케이션은 비밀 변수에 대한 액세스가 필요합니다.

Auto DevOps는 K8S_SECRET_로 시작하는 CI/CD 변수를 감지하고 이를 배포된 애플리케이션에 환경 변수로 제공합니다.

전제 조건:

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

비밀 변수를 구성하려면:

1. 왼쪽 사이드바에서 Search or go to를 선택하고 프로젝트를 찾습니다.

2. Settings > CI/CD를 선택합니다.

3. Variables를 확장합니다.

4. K8S_SECRET_ 접두사를 가진 CI/CD 변수를 생성합니다. 예를 들어, K8S_SECRET_RAILS_MASTER_KEY라는 변수를 생성할 수 있습니다.

5. 수동으로 새 파이프라인을 생성하거나 코드를 GitLab에 푸시하여 Auto DevOps 파이프라인을 실행합니다.

Kubernetes 비밀

Auto DevOps 파이프라인은 애플리케이션 비밀 변수를 사용하여 Kubernetes 비밀을 채웁니다. 이 비밀은 환경마다 고유합니다.

애플리케이션을 배포할 때, 비밀은 애플리케이션을 실행하는 컨테이너의 환경 변수로 로드됩니다. 예를 들어, K8S_SECRET_RAILS_MASTER_KEY라는 비밀을 생성하면, Kubernetes 비밀은 다음과 같을 수 있습니다:

$ 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

애플리케이션 비밀 업데이트

환경 변수는 일반적으로 Kubernetes 파드에서 불변입니다.

비밀을 업데이트하고 수동으로 새 파이프라인을 생성하면, 실행 중인 애플리케이션은 업데이트된 비밀을 수신하지 않습니다.

애플리케이션 비밀을 업데이트하려면 다음 중 하나를 수행합니다:

• Kubernetes 배포를 강제로 수행하여 GitLab에 코드 업데이트를 푸시합니다.
• 실행 중인 파드를 수동으로 삭제하여 Kubernetes가 업데이트된 비밀로 새로운 파드를 생성하게 합니다.

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

복제 변수 구성

배포를 확장할 때 복제 변수를 추가합니다:

1. 프로젝트 CI/CD 변수로 복제 변수를 추가합니다.

2. 애플리케이션을 확장하려면 다시 배포합니다.

   경고: Kubernetes를 직접 사용하여 애플리케이션을 확장하지 마십시오. Helm은 변경 사항을 감지하지 못할 수 있으며, 이후의 Auto DevOps 배포가 변경 사항을 무효화할 수 있습니다.

사용자 지정 복제 변수

형식 <TRACK>_<ENV>_REPLICAS로 사용자 지정 복제 변수를 생성할 수 있습니다:

• <TRACK>는 Helm Chart 애플리케이션 정의에 설정된 track Kubernetes 레이블의 모든 대문자 값입니다. track이 설정되지 않으면 사용자 지정 변수에서 <TRACK>을 생략합니다.
• <ENV>는 .gitlab-ci.yml에 설정된 배포 작업의 모든 대문자 환경 이름입니다.

예를 들어, 환경이 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 작업을 생성합니다.

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

카나리 환경을 위한 배포 정책

프로덕션에 변경 내용을 배포하기 전에 카나리 환경을 사용할 수 있습니다.

CANARY_ENABLED를 설정하면 GitLab은 두 개의 수동 작업을 생성합니다:

• canary - 응용 프로그램을 카나리 환경에 배포합니다.
• production_manual - 응용 프로그램을 프로덕션에 배포합니다.

프로덕션에 대한 점진적 롤아웃

점진적 롤아웃을 사용하여 응용 프로그램을 지속적으로 배포하세요, 처음에는 몇 개의 Pods만 시작합니다. Pods의 수를 수동으로 늘릴 수 있습니다.

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

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

1. rollout 10%
2. rollout 25%
3. rollout 50%
4. rollout 100%

백분율은 REPLICAS CI/CD 변수를 기반으로 하며, 배포에 사용되는 Pods의 수를 정의합니다. 예를 들어, 값이 10이고 10% 롤아웃 작업을 실행하면, 응용 프로그램은 한 개의 Pod에만 배포됩니다.

롤아웃 작업은 어떤 순서로든 실행할 수 있습니다. 축소하려면 낮은 백분율 작업을 다시 실행하세요.

rollout 100% 작업을 실행한 후에는 축소할 수 없으며, 배포를 롤백해야 합니다.

예시 점진적 롤아웃 구성

INCREMENTAL_ROLLOUT_MODE 및 STAGING_ENABLED가 없는 경우:

INCREMENTAL_ROLLOUT_MODE가 없고 STAGING_ENABLED가 있는 경우:

INCREMENTAL_ROLLOUT_MODE가 manual로 설정되고 STAGING_ENABLED가 없는 경우:

INCREMENTAL_ROLLOUT_MODE가 manual로 설정되고 STAGING_ENABLED가 있는 경우:

프로덕션에 대한 시간 제한 점진적 롤아웃

시간 제한 점진적 롤아웃을 사용하여 응용 프로그램을 지속적으로 배포하세요, 처음에는 몇 개의 Pods만 시작합니다.

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

INCREMENTAL_ROLLOUT_MODE를 timed로 설정하면 GitLab은 네 개의 작업을 생성합니다:

1. timed rollout 10%
2. timed rollout 25%
3. timed rollout 50%
4. timed rollout 100%

작업 간에는 5분의 지연이 있습니다.