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

CI/CD 변수

Auto DevOps 도메인을 설정하거나 사용자 정의 Helm 차트를 제공하거나 응용 프로그램을 확장하는 데 CI/CD 변수를 사용하세요.

빌드 및 배포 변수

이러한 변수를 사용하여 빌드를 사용자 정의하고 배포하세요.

데이터베이스 변수

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

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

작업 비활성화 변수

CI/CD 작업을 비활성화하는 데 이 변수들을 사용하세요.

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

일부 배포된 애플리케이션에는 비밀 변수에 대한 액세스가 필요합니다. Auto DevOps는 K8S_SECRET_로 시작하는 CI/CD 변수를 감지하고 배포된 애플리케이션에서 환경 변수로 사용할 수 있게 합니다.

전제 조건:

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

비밀 변수를 구성하려면:

1. 왼쪽 사이드바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
2. 설정 > CI/CD를 선택합니다.
3. 변수를 확장합니다.
4. prefix K8S_SECRET_를 사용하여 CI/CD 변수를 생성합니다. 예를 들어, K8S_SECRET_RAILS_MASTER_KEY라는 변수를 만들 수 있습니다.
5. Auto DevOps 파이프라인을 실행합니다. 새 파이프라인을 수동으로 생성하거나 GitLab에 코드 변경을 푸시하여 실행할 수 있습니다.

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

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

일반적으로 쿠버네티스 팟에서는 환경 변수가 변경되지 않습니다. 애플리케이션 비밀을 업데이트하고 수동으로 새 파이프라인을 생성한 경우, 실행 중인 애플리케이션은 업데이트된 비밀을 받지 않습니다.

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

• 쿠버네티스 배포를 다시 생성하도록 GitLab에 코드를 업데이트합니다.
• 실행 중인 팟을 수동으로 삭제하여 쿠버네티스가 업데이트된 비밀을 사용하여 새 팟을 생성하도록 합니다.

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

레플리카 변수 구성

배포를 확장하려면 레플리카 변수를 추가하세요:

1. 프로젝트 CI/CD 변수로 레플리카 변수를 추가합니다.

2. 애플리케이션을 확장하려면 재배포하세요.

   경고: 쿠버네티스를 직접 사용하여 애플리케이션을 확장하지 마세요. Helm이 변경을 감지하지 못할 수 있으며, 이후의 Auto DevOps 배포는 변경사항을 취소할 수 있습니다.

사용자 정의 레플리카 변수

<TRACK>_<ENV>_REPLICAS 형식의 사용자 정의 레플리카 변수를 만들 수 있습니다:

• <TRACK>은 Helm Chart 앱 정의에서 설정된 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 - 애플리케이션을 프로덕션 환경으로 배포합니다.

프로덕션으로의 점진적 배포

일부 팟으로 시작하여 애플리케이션을 지속적으로 배포하려면 점진적 배포를 사용할 수 있습니다. 이후 수동으로 팟의 수를 늘릴 수 있습니다.

프로젝트 설정에서 수동 배포를 활성화할 수도 있으며, 또는 INCREMENTAL_ROLLOUT_MODE를 manual로 설정할 수 있습니다.

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

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

백분율은 REPLICAS CI/CD 변수를 기반으로 하며 배포에 사용될 팟의 수를 정의합니다. 예를 들어, 값이 10인 경우 10% 롤아웃 작업을 실행하면 애플리케이션이 한 팟에만 배포됩니다.

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

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

예시 증분적 롤아웃 구성

INCREMENTAL_ROLLOUT_MODE 및 STAGING_ENABLED 없이:

INCREMENTAL_ROLLOUT_MODE 없이, 그리고 STAGING_ENABLED으로:

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

INCREMENTAL_ROLLOUT_MODE을 manual로 설정하고 STAGING_ENABLED으로:

프로덕션으로의 시간별 증분적 롤아웃

타임드 증분적 롤아웃을 사용하여 응용 프로그램을 지속적으로 배포하며, 일부 pod부터 시작하세요.

프로젝트 설정에서 타임드 증분 배포를 활성화하거나, 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분의 지연이 있습니다.