4.3. 배포 전략 사용

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

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

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

배포 전략 선택

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

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

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

4.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
pre와 post는 둘 다 라이프사이클 후크입니다.

롤링 전략:

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

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

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

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

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

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

4.3.1.1. 카나리아 배포

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

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

4.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가 준비 상태가 되지 않으면 프로세스가 중단되고 배포가 이전 버전으로 롤백됩니다.

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

사전 요구 사항

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

프로세스

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

  1. 개발자 화면의 토폴로지 보기에서 애플리케이션 노드를 클릭하여 측면 패널의 개요 탭을 확인합니다. 업데이트 전략은 기본값인 롤링 전략으로 설정되어 있습니다.

  2. 작업 드롭다운 메뉴에서 롤아웃 시작을 선택하여 롤링 업데이트를 시작합니다. 롤링 배포에서는 새 버전의 애플리케이션을 실행한 다음 이전 버전을 종료합니다.

    그림 4.1. 롤링 업데이트

    odc rolling update

추가 리소스