• 빌드 및 배포 변수
• 데이터베이스 변수
• 작업 비활성화 변수
• 애플리케이션 시크릿 변수 구성하기
  • Kubernetes 시크릿
• 애플리케이션 시크릿 업데이트하기
• 레플리카 변수 구성
  • 사용자 정의 레플리카 변수
• 스테이징 및 프로덕션 환경을 위한 배포 정책
• 캐너리 환경을 위한 배포 정책
• 프로덕션으로 점진적 배포
  • 점진적 배포 구성 예
• 타임드 점진적 프로덕션 배포

CI/CD 변수

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

빌드 및 배포 변수

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

데이터베이스 변수

이 변수들을 사용하여 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

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

일반적으로 쿠버네티스 파드에서 환경 변수는 변경할 수 없습니다. 애플리케이션 시크릿을 업데이트하고 새 파이프라인을 매뉴얼으로 만든 후, 실행 중인 애플리케이션은 업데이트된 시크릿을 받지 않습니다.

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

• 쿠버네티스 배포를 다시 생성하도록 GitLab에 코드 업데이트를 푸시합니다.
• 업데이트된 시크릿으로 새로운 파드를 만들도록 실행 중인 파드를 매뉴얼으로 삭제합니다.

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

레플리카 변수 구성

배포를 확장하려면 레플리카 변수를 추가하십시오:

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

2. 애플리케이션을 확장하려면 데플로이합니다.

   쿠버네티스를 직접 사용하여 애플리케이션의 규모를 조정하지 마십시오. Helm이 변경 사항을 감지하지 못할 수 있으며, Auto DevOps로 이후 배포가 변경 사항을 취소할 수 있습니다.

사용자 정의 레플리카 변수

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

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

프로덕션으로 점진적 배포

프로덕션으로 애플리케이션을 계속적으로 배포하기 위해 점진적인 배포를 사용하여 처음에는 몇 개의 pod으로 시작합니다. pod 수를 매뉴얼으로 증가시킬 수 있습니다.

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

INCREMENTAL_ROLLOUT_MODE를 manual로 설정하면 GitLab은 네 개의 매뉴얼 작업을 만듭니다:

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

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

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

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분의 지연이 있습니다.