검색

4.2. 배포 프로세스 관리

download PDF

4.2.1. DeploymentConfig 오브젝트 관리

DeploymentConfig 오브젝트는 OpenShift Container Platform 웹 콘솔의 워크로드 페이지 또는 oc CLI에서 관리할 수 있습니다. 다음 절차에서는 달리 명시하지 않는 한 CLI 사용법을 보여줍니다.

4.2.1.1. 배포 시작

롤아웃을 시작하여 애플리케이션 배포 프로세스를 시작할 수 있습니다.

프로세스

  1. 기존 DeploymentConfig 오브젝트에서 새 배포 프로세스를 시작하려면 다음 명령을 실행합니다.

    $ oc rollout latest dc/<name>
    참고

    배포 프로세스가 이미 진행 중인 경우 명령에서 메세지를 표시하고 새 복제 컨트롤러가 배포되지 않습니다.

4.2.1.2. 배포 보기

배포를 보고 애플리케이션의 모든 사용 가능한 리버전에 대한 기본 정보를 얻을 수 있습니다.

프로세스

  1. 현재 실행 중인 배포 프로세스를 포함하여 제공된 DeploymentConfig 오브젝트에 대해 최근 생성된 모든 복제 컨트롤러에 대한 세부 정보를 보려면 다음 명령을 실행합니다.

    $ oc rollout history dc/<name>
  2. 버전과 관련된 세부 정보를 보려면 --revision 플래그를 추가합니다.

    $ oc rollout history dc/<name> --revision=1
  3. DeploymentConfig 오브젝트 및 이 오브젝트의 최신 버전에 대한 자세한 내용을 보려면 oc describe 명령을 사용합니다.

    $ oc describe dc <name>

4.2.1.3. 배포 재시도

DeploymentConfig 오브젝트의 현재 리버전을 배포하지 못한 경우 배포 프로세스를 재시작할 수 있습니다.

프로세스

  1. 실패한 배포 프로세스를 재시작하려면 다음을 수행합니다.

    $ oc rollout retry dc/<name>

    최신 버전이 성공적으로 배포된 경우 명령에서 메시지를 표시하고 배포 프로세스가 다시 수행되지 않습니다.

    참고

    배포를 다시 시도하면 배포 프로세스가 다시 시작되고 새 배포 리버전이 생성되지 않습니다. 재시작한 복제 컨트롤러의 구성은 실패한 경우의 구성과 동일합니다.

4.2.1.4. 배포 롤백

롤백은 애플리케이션을 이전 리버전으로 되돌리고 REST API, CLI 또는 웹 콘솔을 사용하여 수행할 수 있습니다.

프로세스

  1. 마지막으로 성공적으로 배포된 구성 리버전으로 롤백하려면 다음을 수행합니다.

    $ oc rollout undo dc/<name>

    DeploymentConfig 오브젝트의 템플릿이 undo 명령에 지정된 배포 리버전과 일치하도록 되돌아가고 새 복제 컨트롤러가 시작됩니다. 리버전이 --to-revision을 사용하여 지정되지 않은 경우 마지막으로 성공적으로 배포된 리버전이 사용됩니다.

  2. 롤백이 완료되면 실수로 새 배포 프로세스가 시작되지 않도록 DeploymentConfig 오브젝트에서 이미지 변경 트리거가 비활성화됩니다.

    이미지 변경 트리거를 다시 활성화하려면 다음을 수행합니다.

    $ oc set triggers dc/<name> --auto
참고

배포 구성에서는 최신 배포 프로세스가 실패하는 경우 마지막으로 성공한 구성 리버전으로의 자동 롤백도 지원합니다. 이 경우 배포되지 않은 최신 템플릿은 시스템에서 그대로 유지되며 사용자가 해당 구성을 수정할 수 있습니다.

4.2.1.5. 컨테이너 내에서 명령 실행

이미지의 ENTRYPOINT 를 오버레이하여 컨테이너의 시작 동작을 수정하는 명령을 컨테이너에 추가할 수 있습니다. 이 명령은 지정된 시점에 배포당 한 번만 실행할 수 있는 라이프사이클 후크와는 다릅니다.

프로세스

  1. DeploymentConfig 오브젝트의 spec 필드에 command 매개변수를 추가합니다. 또한 command(command가 존재하지 않는 경우 ENTRYPOINT)를 수정하는 args 필드를 추가할 수 있습니다.

    spec:
      containers:
      - name: <container_name>
        image: 'image'
        command:
          - '<command>'
        args:
          - '<argument_1>'
          - '<argument_2>'
          - '<argument_3>'

    예를 들어 -jar/opt/app-root/springboots2idemo.jar 인수를 사용하여 java 명령을 실행하려면 다음을 수행합니다.

    spec:
      containers:
      - name: example-spring-boot
        image: 'image'
        command:
          - java
        args:
          - '-jar'
          - /opt/app-root/springboots2idemo.jar

4.2.1.6. 배포 로그 보기

프로세스

  1. 지정된 DeploymentConfig 오브젝트의 최신 리버전 로그를 스트리밍하려면 다음을 수행합니다.

    $ oc logs -f dc/<name>

    최신 리버전이 실행 중이거나 실패한 경우 명령에서 Pod 배포를 담당하는 프로세스의 로그를 반환합니다. 성공하는 경우 애플리케이션 Pod의 로그를 반환합니다.

  2. 또한 실패한 이전 배포 프로세스(복제 컨트롤러 및 배포 Pod)가 존재하고 이를 수동으로 정리하거나 삭제하지 않은 경우에만 이러한 프로세스의 로그를 볼 수 있습니다.

    $ oc logs --version=1 dc/<name>

4.2.1.7. 배포 트리거

DeploymentConfig 오브젝트에는 클러스터 내부 이벤트에 대한 응답으로 새 배포 프로세스 생성을 유도하는 트리거가 포함될 수 있습니다.

주의

DeploymentConfig 오브젝트에 트리거가 정의되어 있지 않은 경우 기본적으로 구성 변경 트리거가 추가됩니다. Trigger가 빈 필드로 정의되면 배포를 수동으로 시작해야 합니다.

구성 변경 배포 트리거

구성 변경 트리거를 사용하면 DeploymentConfig 오브젝트의 Pod 템플릿에서 구성 변경이 탐지될 때마다 새 복제 컨트롤러가 생성됩니다.

참고

DeploymentConfig 오브젝트에 구성 변경 트리거를 정의하면 DeploymentConfig 오브젝트 자체를 생성한 직후 첫 번째 복제 컨트롤러가 자동으로 생성되고 정지되지 않습니다.

구성 변경 배포 트리거

triggers:
  - type: "ConfigChange"

이미지 변경 배포 트리거

이미지 변경 트리거를 사용하면 이미지 스트림 태그 내용이 변경될 때마다(새 버전의 이미지를 내보낼 때) 새 복제 컨트롤러가 생성됩니다.

이미지 변경 배포 트리거

triggers:
  - type: "ImageChange"
    imageChangeParams:
      automatic: true 1
      from:
        kind: "ImageStreamTag"
        name: "origin-ruby-sample:latest"
        namespace: "myproject"
      containerNames:
        - "helloworld"

1
imageChangeParams.automatic 필드를 false로 설정하면 트리거가 비활성화됩니다.

위 예제에서 origin-ruby-sample 이미지 스트림의 latest 태그 값이 변경되고 새 이미지 값이 DeploymentConfig 오브젝트의 helloworld 컨테이너에 지정된 현재 이미지와 다른 경우 helloworld 컨테이너의 새 이미지를 사용하여 새 복제 컨트롤러가 생성됩니다.

참고

DeploymentConfig 오브젝트에 이미지 변경 트리거가 정의되고(구성 변경 트리거와 automatic=false 또는 automatic=true 사용) 이미지 변경 트리거가 가리키는 이미지 스트림 태그가 아직 존재하지 않는 경우 빌드에서 이미지를 가져오거나 이미지 스트림 태그로 내보내는 즉시 초기 배포 프로세스가 자동으로 시작됩니다.

4.2.1.7.1. 배포 트리거 설정

프로세스

  1. oc set triggers 명령을 사용하여 DeploymentConfig 오브젝트에 대한 배포 트리거를 설정할 수 있습니다. 예를 들어 이미지 변경 트리거를 설정하려면 다음 명령을 사용하십시오.

    $ oc set triggers dc/<dc_name> \
        --from-image=<project>/<image>:<tag> -c <container_name>

4.2.1.8. 배포 리소스 설정

배포는 노드에서 리소스(메모리, CPU, 임시 스토리지)를 사용하는 Pod에 의해 완료됩니다. 기본적으로 Pod는 바인딩되지 않은 노드 리소스를 사용합니다. 그러나 프로젝트에서 기본 컨테이너 제한을 지정하는 경우 Pod는 해당 제한까지 리소스를 사용합니다.

참고

배포를 위한 최소 메모리 제한은 12MB입니다. 메모리를 할당할 수 없음 Pod 이벤트로 인해 컨테이너가 시작되지 않으면 메모리 제한이 너무 낮은 것입니다. 메모리 제한을 늘리거나 제거합니다. 제한을 제거하면 Pod에서 바인딩되지 않은 노드 리소스를 사용할 수 있습니다.

리소스 제한을 배포 전략의 일부로 지정하여 리소스 사용을 제한할 수도 있습니다. 배포 리소스는 재현, 롤링 또는 사용자 정의 배포 전략과 함께 사용할 수 있습니다.

프로세스

  1. 다음 예에서 각 resources, cpu, memory, ephemeral-storage는 선택 사항입니다.

    type: "Recreate"
    resources:
      limits:
        cpu: "100m" 1
        memory: "256Mi" 2
        ephemeral-storage: "1Gi" 3
    1
    CPU 는 CPU 단위입니다. 100m은 0.1 CPU 단위(100 * 1e-3)를 나타냅니다.
    2
    메모리 는 바이트 단위입니다. 256Mi 는 268435456 바이트(256 * 2 ^ 20)를 나타냅니다.
    3
    ephemeral-storage 는 바이트 단위입니다. 1GI는 1073741824바이트(2^ 30)를 나타냅니다.

    그러나 프로젝트에 할당량을 정의한 경우 다음 두 항목 중 하나가 필요합니다.

    • requests가 명시적으로 설정된 resources 섹션:

        type: "Recreate"
        resources:
          requests: 1
            cpu: "100m"
            memory: "256Mi"
            ephemeral-storage: "1Gi"
      1
      requests 오브젝트에 할당량의 리소스 목록에 해당하는 리소스 목록이 포함되어 있습니다.
    • 프로젝트에 정의된 제한 범위: LimitRange 오브젝트의 기본값은 배포 프로세스 중 생성된 Pod에 적용됩니다.

    배포 리소스를 설정하려면 위 옵션 중 하나를 선택하십시오. 그러지 않으면 할당량을 충족하지 못하여 배포 Pod가 생성되지 않습니다.

추가 리소스

4.2.1.9. 수동 스케일링

롤백 외에도 수동으로 스케일링하여 복제본 수를 세부적으로 제어할 수 있습니다.

참고

autoscale 명령을 사용하여 Pod를 자동 스케일링할 수도 있습니다.

프로세스

  1. DeploymentConfig 오브젝트를 수동으로 스케일링하려면 oc scale 명령을 사용합니다. 예를 들어 다음 명령은 frontend DeploymentConfig 오브젝트의 복제본 수를 3으로 설정합니다.

    $ oc scale dc frontend --replicas=3

    결국 복제본 수는 DeploymentConfig 오브젝트의 frontend에서 구성한 배포의 원하는 현재 상태로 전달됩니다.

4.2.1.10. DeploymentConfig 오브젝트에서 프라이빗 리포지토리에 액세스

프라이빗 리포지토리에서 이미지에 액세스할 수 있도록 DeploymentConfig 오브젝트에 시크릿을 추가할 수 있습니다. 이 절차에서는 OpenShift Container Platform 웹 콘솔 방법을 보여줍니다.

프로세스

  1. 새 프로젝트를 생성합니다.
  2. 워크로드 페이지에서 프라이빗 이미지 리포지토리에 액세스하는 데 필요한 인증 정보가 포함된 시크릿을 생성합니다.
  3. DeploymentConfig 오브젝트를 생성합니다.
  4. DeploymentConfig 오브젝트 편집기 페이지에서 시크릿 가져오기를 설정하고 변경 사항을 저장합니다.

4.2.1.11. 특정 노드에 Pod 할당

라벨이 지정된 노드와 함께 노드 선택기를 사용하여 Pod 배치를 제어할 수 있습니다.

클러스터 관리자는 Pod 배치를 특정 노드로 제한하기 위해 프로젝트의 기본 노드 선택기를 설정할 수 있습니다. 개발자는 Pod 구성에 노드 선택기를 설정하여 노드를 추가로 제한할 수 있습니다.

프로세스

  1. Pod를 생성할 때 노드 선택기를 추가하려면 Pod 구성을 편집하고 nodeSelector 값을 추가합니다. 이 값은 단일 Pod 구성 또는 Pod 템플릿에 추가할 수 있습니다.

    apiVersion: v1
    kind: Pod
    spec:
      nodeSelector:
        disktype: ssd
    ...

    노드 선택기가 제 위치에 있으면 생성된 Pod가 라벨이 지정된 노드에 할당됩니다. 여기 지정된 라벨은 클러스터 관리자가 추가한 라벨과 함께 사용됩니다.

    예를 들어 클러스터 관리자가 프로젝트에 type=user-noderegion=east 라벨을 추가하고 위의 disktype: ssd 라벨을 Pod에 추가하는 경우 Pod는 세 라벨이 모두 있는 노드에서만 예약됩니다.

    참고

    라벨은 하나의 값으로만 설정할 수 있으므로 관리자가 설정한 기본값이 region=eastPod 구성에 region=west인 노드 선택기를 설정하면 예약되지 않는 Pod가 생성됩니다.

4.2.1.12. 다른 서비스 계정으로 Pod 실행

기본 계정 이외의 서비스 계정으로 Pod를 실행할 수 있습니다.

프로세스

  1. DeploymentConfig 오브젝트를 편집합니다.

    $ oc edit dc/<deployment_config>
  2. serviceAccountserviceAccountName 매개변수를 spec 필드에 추가하고 사용할 서비스 계정을 지정합니다.

    spec:
      securityContext: {}
      serviceAccount: <service_account>
      serviceAccountName: <service_account>
Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

© 2024 Red Hat, Inc.