7.3. 배포 전략 사용

배포 전략은 애플리케이션을 변경하거나 업그레이드하는 방법입니다. 사용자가 개선 작업을 거의 알아채지 못하도록 다운타임 없이 변경하는 것이 목표입니다.

최종 사용자는 일반적으로 라우터에서 처리한 경로를 통해 애플리케이션에 액세스하므로 배포 전략에서는 DeploymentConfig 오브젝트 기능 또는 라우팅 기능에 중점을 둘 수 있습니다. 배포에 중점을 둔 전략은 애플리케이션을 사용하는 모든 경로에 영향을 미칩니다. 라우터 기능을 사용하는 전략은 개별 경로를 대상으로 합니다.

대다수의 배포 전략은 DeploymentConfig 오브젝트를 통해 지원되며 일부 추가 전략은 라우터 기능을 통해 지원됩니다. 이 섹션에서는 배포 전략에 대해 설명합니다.

배포 전략 선택

배포 전략을 선택할 때는 다음을 고려하십시오.

  • 장기 실행 연결은 정상적으로 처리해야 합니다.
  • 데이터베이스 변환은 복잡할 수 있으며 애플리케이션과 함께 수행하고 롤백해야 합니다.
  • 애플리케이션이 마이크로 서비스와 기존 구성 요소의 하이브리드인 경우 전환을 완료하기 위해 다운타임이 필요할 수 있습니다.
  • 이 작업을 수행하려면 인프라가 있어야 합니다.
  • 격리되지 않은 테스트 환경이 있는 경우 새 버전과 이전 버전을 모두 중단할 수 있습니다.

배포 전략에서는 준비 상태 점검을 통해 새 Pod를 사용할 준비가 되었는지 확인합니다. 준비 상태 점검이 실패하면 DeploymentConfig 오브젝트에서 타임아웃될 때까지 Pod를 다시 실행하려고 합니다. 기본 타임아웃은 dc.spec.strategy.*paramsTimeoutSeconds에 설정된 값인 10m입니다.

7.3.1. 롤링 전략

롤링 배포를 통해 이전 버전의 애플리케이션 인스턴스를 새 버전의 애플리케이션 인스턴스로 대체합니다. 롤링 전략은 DeploymentConfig 오브젝트에 전략이 지정되지 않은 경우 사용되는 기본 배포 전략입니다.

롤링 배포는 일반적으로 새 Pod가 준비 상태 점검을 통해 준비 상태가 될 때까지 기다린 후 이전 구성 요소를 축소합니다. 심각한 문제가 발생하는 경우 롤링 배포가 중단될 수 있습니다.

롤링 배포를 사용하는 경우는 다음과 같습니다.

  • 애플리케이션을 업데이트하는 동안 다운타임이 발생하지 않도록 하려는 경우
  • 애플리케이션에서 이전 코드 및 새 코드가 동시에 실행되도록 지원하는 경우

롤링 배포에서는 코드의 이전 버전과 새 버전이 동시에 실행됩니다. 이를 위해서는 일반적으로 애플리케이션에서 N-1 호환성을 처리해야 합니다.

롤링 전략 정의의 예

strategy:
  type: Rolling
  rollingParams:
    updatePeriodSeconds: 1 1
    intervalSeconds: 1 2
    timeoutSeconds: 120 3
    maxSurge: "20%" 4
    maxUnavailable: "10%" 5
    pre: {} 6
    post: {}

1
개별 Pod 업데이트 사이에 대기하는 시간입니다. 이 값을 지정하지 않는 경우 기본값은 1입니다.
2
업데이트 후 배포 상태를 폴링할 때까지 대기하는 시간입니다. 이 값을 지정하지 않는 경우 기본값은 1입니다.
3
스케일링 이벤트를 중지하기 전에 대기하는 시간입니다. 선택 사항이며 기본값은 600입니다. 여기서 중지하는 경우 이전에 완료된 배포로 자동으로 롤백합니다.
4
maxSurge는 선택 사항이며 지정하지 않는 경우 기본값은 25%입니다. 다음 절차 아래의 정보를 참조하십시오.
5
maxUnavailable은 선택 사항이며 지정하지 않는 경우 기본값은 25%입니다. 다음 절차 아래의 정보를 참조하십시오.
6
prepost는 둘 다 라이프사이클 후크입니다.

롤링 전략:

  1. pre 라이프사이클 후크를 실행합니다.
  2. 서지 수에 따라 새 복제 컨트롤러를 확장합니다.
  3. 사용할 수 없는 최대 수에 따라 이전 복제 컨트롤러를 축소합니다.
  4. 새 복제 컨트롤러가 원하는 복제본 수에 도달하고 이전 복제 컨트롤러가 0으로 스케일링될 때까지 이 스케일링을 반복합니다.
  5. post 라이프사이클 후크를 실행합니다.
중요

축소할 때는 롤링 전략이 Pod가 준비될 때까지 기다립니다. 따라서 추가 스케일링이 가용성에 영향을 미치는지 확인할 수 있습니다. 확장된 Pod가 준비되지 않으면 배포 프로세스가 결국 타임아웃되어 배포에 실패합니다.

maxUnavailable 매개변수는 업데이트 중 사용할 수 없는 최대 Pod 수입니다. maxSurge 매개변수는 원래 Pod 수 이상으로 예약할 수 있는 최대 Pod 수입니다. 두 매개변수 모두 백분율 (예: 10%) 또는 절대 값(예: 2)으로 설정할 수 있습니다. 기본값은 둘 다 25%입니다.

이러한 매개변수를 사용하면 가용성 및 속도를 위해 배포를 조정할 수 있습니다. 예를 들면 다음과 같습니다.

  • maxUnavailable*=0maxSurge*=20%를 사용하면 업데이트 및 빠른 확장 중 전체 용량을 유지 관리할 수 있습니다.
  • maxUnavailable*=10%maxSurge*=0은 추가 용량을 사용하지 않고 업데이트를 수행합니다(내부 업데이트).
  • maxUnavailable*=10%maxSurge*=10%는 빠르게 확장 및 축소하고 약간의 용량 손실 가능성이 있습니다.

일반적으로 빠른 롤아웃을 원한다면 maxSurge를 사용합니다. 리소스 할당량을 고려해야 하고 부분적인 비가용성을 허용할 수 있는 경우에는 maxUnavailable을 사용합니다.

7.3.1.1. 카나리아 배포

OpenShift Container Platform의 모든 롤링 배포는 카나리아 배포입니다. 이전 인스턴스를 모두 교체하기 전에 새 버전(카나리아)을 테스트합니다. 준비 상태 점검이 실패하면 카나리아 인스턴스가 제거되고 DeploymentConfig 오브젝트가 자동으로 롤백됩니다.

준비 상태 점검은 애플리케이션 코드의 일부이며 새 인스턴스를 사용할 준비가 되었는지 확인하는 데 필요할 정도로 정교할 수 있습니다. 더 복잡한 애플리케이션 점검을 구현해야 하는 경우(예: 실제 사용자 워크로드를 새 인스턴스로 전송) 사용자 정의 배포를 구현하거나 Blue-Green 배포 전략을 사용하는 것이 좋습니다.

7.3.1.2. 롤링 배포 생성

롤링 배포는 OpenShift Container Platform의 기본 유형입니다. CLI를 사용하여 롤링 배포를 생성할 수 있습니다.

프로세스

  1. Quay.io에 있는 배포 이미지 예제를 기반으로 애플리케이션을 생성합니다.

    $ oc new-app quay.io/openshifttest/deployment-example:latest
  2. 라우터가 설치된 경우 경로를 통해 애플리케이션을 제공하거나 서비스 IP를 직접 사용합니다.

    $ oc expose svc/deployment-example
  3. deployment-example.<project>.<router_domain>에서 애플리케이션을 검색하여 v1 이미지가 표시되는지 확인합니다.
  4. DeploymentConfig 오브젝트를 세 개의 복제본으로 확장합니다.

    $ oc scale dc/deployment-example --replicas=3
  5. 예제의 새 버전에 latest 태그를 지정하여 새 배포를 자동으로 트리거합니다.

    $ oc tag deployment-example:v2 deployment-example:latest
  6. 브라우저에서 v2 이미지가 표시될 때까지 페이지를 새로 고칩니다.
  7. CLI를 사용하는 경우 다음 명령은 버전 1의 Pod 수와 버전 2의 Pod 수를 보여줍니다. 웹 콘솔에서 Pod가 점차 v2에 추가되고 v1에서 제거됩니다.

    $ oc describe dc deployment-example

배포 프로세스 중 새 복제 컨트롤러가 점점 확장됩니다. 새 Pod가 (준비 상태 점검을 통과하여) ready 상태로 표시되면 배포 프로세스가 계속됩니다.

Pod가 준비 상태가 되지 않으면 프로세스가 중단되고 배포가 이전 버전으로 롤백됩니다.

7.3.1.3. 개발자 화면을 사용하여 롤링 배포 시작

사전 요구 사항

  • 웹 콘솔의 개발자 화면에 있는지 확인합니다.
  • 추가 보기를 사용하여 애플리케이션을 생성하고 토폴로지 보기에 배포되었는지 확인합니다.

프로세스

롤링 배포를 시작하여 애플리케이션을 업그레이드하려면 다음을 수행합니다.

  1. 개발자 화면의 토폴로지 보기에서 애플리케이션 노드를 클릭하여 측면 패널의 개요 탭을 확인합니다. 업데이트 전략은 기본값인 롤링 전략으로 설정되어 있습니다.
  2. 작업 드롭다운 메뉴에서 롤아웃 시작을 선택하여 롤링 업데이트를 시작합니다. 롤링 배포에서는 새 버전의 애플리케이션을 실행한 다음 이전 버전을 종료합니다.

    그림 7.1. 롤링 업데이트

    odc rolling update

7.3.2. 재현 전략

재현 전략에는 기본 롤아웃 동작이 있고 배포 프로세스에 코드를 삽입하는 라이프사이클 후크를 지원합니다.

재현 전략 정의의 예

strategy:
  type: Recreate
  recreateParams: 1
    pre: {} 2
    mid: {}
    post: {}

1
recreateParams는 선택 사항입니다.
2
pre, mid, post는 라이프사이클 후크입니다.

재현 전략은 다음과 같습니다.

  1. pre 라이프사이클 후크를 실행합니다.
  2. 이전 배포를 0으로 축소합니다.
  3. mid 라이프사이클 후크를 실행합니다.
  4. 새 배포를 확장합니다.
  5. post 라이프사이클 후크를 실행합니다.
중요

확장하는 동안 배포의 복제본 수가 두 개 이상인 경우 배포를 완전히 확장하기 전에 첫 번째 배포 복제본의 준비 상태를 검증합니다. 첫 번째 복제본의 검증이 실패하면 배포가 실패로 간주됩니다.

재현 배포를 사용하는 경우는 다음과 같습니다.

  • 새 코드가 시작되려면 마이그레이션 또는 기타 데이터 변환 작업을 실행해야 하는 경우
  • 새 버전과 이전 버전의 애플리케이션 코드가 동시에 실행되는 것을 지원하지 않는 경우
  • 여러 복제본에서 공유할 수 없는 RWO 볼륨을 사용하려는 경우

재현 배포에서는 잠시 동안 애플리케이션 인스턴스가 실행되지 않기 때문에 다운타임이 발생합니다. 그러나 기존 코드와 새 코드가 동시에 실행되지 않습니다.

7.3.3. 개발자 화면을 사용하여 재현 배포 시작

웹 콘솔의 개발자 화면을 사용하여 배포 전략을 기본 롤링 업데이트에서 재현 업데이트로 전환할 수 있습니다.

사전 요구 사항

  • 웹 콘솔의 개발자 화면에 있는지 확인합니다.
  • 추가 보기를 사용하여 애플리케이션을 생성하고 토폴로지 보기에 배포되었는지 확인합니다.

프로세스

재현 업데이트 전략으로 전환하고 애플리케이션을 업그레이드하려면 다음을 수행합니다.

  1. 작업 드롭다운 메뉴에서 배포 구성 편집을 선택하여 애플리케이션의 배포 구성 세부 정보를 확인합니다.
  2. YAML 편집기에서 spec.strategy.typeRecreate로 변경하고 저장을 클릭합니다.
  3. 토폴로지 보기에서 노드를 선택하여 측면 패널의 개요 탭을 확인합니다. 이제 업데이트 전략재현으로 설정되어 있습니다.
  4. 작업 드롭다운 메뉴에서 롤아웃 시작을 선택하면 재현 전략을 사용하여 업데이트가 시작됩니다. 재현 전략에서는 먼저 이전 버전 애플리케이션에 대한 Pod를 종료한 다음 새 버전에 대한 Pod를 구동합니다.

    그림 7.2. 재현 업데이트

    odc recreate update

7.3.4. 사용자 정의 전략

사용자 정의 전략을 사용하면 고유의 배포 동작을 제공할 수 있습니다.

사용자 정의 전략 정의의 예

strategy:
  type: Custom
  customParams:
    image: organization/strategy
    command: [ "command", "arg1" ]
    environment:
      - name: ENV_1
        value: VALUE_1

위 예에서 organization/strategy 컨테이너 이미지는 배포 동작을 제공합니다. 선택 사항인 command 배열은 이미지의 Dockerfile에 지정된 모든 CMD 지시문을 재정의합니다. 제공되는 선택적 환경 변수는 전략 프로세스의 실행 환경에 추가됩니다.

또한 OpenShift Container Platform에서는 배포 프로세스에 다음 환경 변수를 제공합니다.

환경 변수설명

OPENSHIFT_DEPLOYMENT_NAME

복제 컨트롤러의 새 배포 이름입니다.

OPENSHIFT_DEPLOYMENT_NAMESPACE

새 배포의 이름 공간입니다.

처음에는 새 배포의 복제본 수가 0입니다. 이 전략은 사용자의 요구에 가장 적합한 논리를 사용하여 새 배포를 활성화하는 작업을 담당합니다.

또는 customParams 오브젝트를 사용하여 기존 배포 전략에 사용자 정의 배포 논리를 삽입합니다. 사용자 정의 쉘 스크립트 논리를 제공하고 openshift-deploy 바이너리를 호출합니다. 사용자는 사용자 정의 배포 컨테이너 이미지를 제공할 필요가 없습니다. 이 경우 기본 OpenShift Container Platform 배포자 이미지가 대신 사용됩니다.

strategy:
  type: Rolling
  customParams:
    command:
    - /bin/sh
    - -c
    - |
      set -e
      openshift-deploy --until=50%
      echo Halfway there
      openshift-deploy
      echo Complete

그러면 다음 배포가 생성됩니다.

Started deployment #2
--> Scaling up custom-deployment-2 from 0 to 2, scaling down custom-deployment-1 from 2 to 0 (keep 2 pods available, don't exceed 3 pods)
    Scaling custom-deployment-2 up to 1
--> Reached 50% (currently 50%)
Halfway there
--> Scaling up custom-deployment-2 from 1 to 2, scaling down custom-deployment-1 from 2 to 0 (keep 2 pods available, don't exceed 3 pods)
    Scaling custom-deployment-1 down to 1
    Scaling custom-deployment-2 up to 2
    Scaling custom-deployment-1 down to 0
--> Success
Complete

사용자 정의 배포 전략 프로세스에서 OpenShift Container Platform API 또는 Kubernetes API에 액세스해야 하는 경우에는 전략을 실행하는 컨테이너에서 인증을 위해 컨테이너 내에 제공되는 서비스 계정 토큰을 사용하면 됩니다.

7.3.5. 라이프사이클 후크

롤링 및 재현 전략에서는 라이프사이클 후크 또는 배포 후크를 지원하므로 전략 내의 미리 정의한 지점에서 배포 프로세스에 동작을 삽입할 수 있습니다.

pre 라이프사이클 후크의 예

pre:
  failurePolicy: Abort
  execNewPod: {} 1

1
execNewPod는 Pod 기반 라이프사이클 후크입니다.

모든 후크에는 후크에 오류가 발생했을 때 전략에서 취해야 하는 조치를 정의하는 실패 정책이 있습니다.

Abort

후크가 실패하면 배포 프로세스가 실패로 간주됩니다.

Retry

성공할 때까지 후크를 다시 실행합니다.

Ignore

모든 후크 오류를 무시하고 배포를 계속 진행합니다.

후크에는 후크 실행 방법을 설명하는 유형별 필드가 있습니다. 현재는 Pod 기반 후크가 지원되는 유일한 후크 유형으로 execNewPod필드에 지정되어 있습니다.

Pod 기반 라이프사이클 후크

Pod 기반 라이프사이클 후크는 DeploymentConfig 오브젝트의 템플릿에서 파생된 새 Pod에서 후크 코드를 실행합니다.

간소화된 다음 예제 배포에서는 롤링 전략을 사용합니다. 간결성을 위해 트리거 및 몇 가지 기타 사소한 세부 정보는 생략되었습니다.

kind: DeploymentConfig
apiVersion: apps.openshift.io/v1
metadata:
  name: frontend
spec:
  template:
    metadata:
      labels:
        name: frontend
    spec:
      containers:
        - name: helloworld
          image: openshift/origin-ruby-sample
  replicas: 5
  selector:
    name: frontend
  strategy:
    type: Rolling
    rollingParams:
      pre:
        failurePolicy: Abort
        execNewPod:
          containerName: helloworld 1
          command: [ "/usr/bin/command", "arg1", "arg2" ] 2
          env: 3
            - name: CUSTOM_VAR1
              value: custom_value1
          volumes:
            - data 4
1
helloworld 이름은 spec.template.spec.containers[0].name을 나타냅니다.
2
commandopenshift/origin-ruby-sample 이미지로 정의된 모든 ENTRYPOINT를 재정의합니다.
3
env는 후크 컨테이너의 선택적 환경 변수 세트입니다.
4
volume은 후크 컨테이너의 선택적 볼륨 참조 세트입니다.

이 예제에서 pre 후크는 helloworld 컨테이너의 openshift/origin-ruby-sample 이미지를 사용하여 새 Pod에서 실행됩니다. 후크 Pod에는 다음과 같은 속성이 있습니다.

  • 후크 명령은 /usr/bin/command arg1 arg2입니다.
  • 후크 컨테이너에는 CUSTOM_VAR1=custom_value1 환경 변수가 있습니다.
  • 후크 실패 정책이Abort이므로 후크가 실패하면 배포 프로세스가 실패합니다.
  • 후크 Pod는 DeploymentConfig 오브젝트 Pod의 data 볼륨을 상속합니다.

7.3.5.1. 라이프사이클 후크 설정

CLI를 사용하여 배포에 라이프사이클 후크 또는 배포 후크를 설정할 수 있습니다.

프로세스

  1. oc set deployment-hook 명령을 사용하여 원하는 후크 유형을 --pre, --mid 또는 --post로 설정합니다. 예를 들어 사전 배포 후크를 설정하려면 다음을 실행합니다.

    $ oc set deployment-hook dc/frontend \
        --pre -c helloworld -e CUSTOM_VAR1=custom_value1 \
        --volumes data --failure-policy=abort -- /usr/bin/command arg1 arg2