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

CI/CD 변수

자동 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. 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

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

일반적으로 Kubernetes Pod에서 환경 변수는 변경할 수 없습니다. 애플리케이션 비밀을 업데이트한 후 수동으로 새 파이프라인을 생성하면 실행 중인 애플리케이션은 업데이트된 비밀을 받지 않습니다.

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

• Kubernetes 배포를 다시 만들기 위해 GitLab에 코드 업데이트를 푸시합니다.
• 업데이트된 시크릿으로 새로운 Pod를 생성하도록 실행 중인 Pod를 수동으로 삭제합니다.

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

레플리카 변수 구성

배포를 확장하려면 레플리카 변수를 추가합니다:

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

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

   경고: 쿠버네티스를 직접 사용하여 응용 프로그램을 확장하지 마십시오. Helm은 변경 사항을 감지하지 못할 수 있으며, 그 후의 Auto DevOps 배포가 변경 사항을 취소할 수 있습니다.

사용자 정의 레플리카 변수

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

• <TRACK>은 Helm Chart 앱 정의에 설정된 track의 대문자 값입니다. Kubernetes 레이블 만약 track이 설정되지 않았다면 사용자 정의 변수에서 <TRACK>을 생략합니다.
• <ENV>는 .gitlab-ci.yml에 설정된 배포 작업의 대문자 환경 이름입니다.

예를 들어, 환경이 qa이고 트랙이 foo인 경우, FOO_QA_REPLICAS라는 환경 변수를 만듭니다:

QA 테스트:
  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가 활성화된 경우:

프로덕션으로의 시간별 점진적인 롤아웃

일부 파드만 사용하여 애플리케이션을 지속적으로 배포하기 위해 시간별 점진적인 롤아웃을 사용합니다.

프로젝트 설정에서 시간별 점진적 배포를 활성화하거나 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분의 지연이 있습니다.