6.2. 배포 프로세스 관리

프로세스

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

   $ oc rollout latest dc/<name>

   참고

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

프로세스

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

   $ oc rollout history dc/<name>

2. 버전과 관련된 세부 정보를 보려면 --revision 플래그를 추가합니다.

   $ oc rollout history dc/<name> --revision=1

3. DeploymentConfig 오브젝트 및 이 오브젝트의 최신 버전에 대한 자세한 내용을 보려면 oc describe 명령을 사용합니다.

   $ oc describe dc <name>

프로세스

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

   $ oc rollout retry dc/<name>

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

   참고

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

프로세스

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

   $ oc rollout undo dc/<name>

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

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

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

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

프로세스

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

프로세스

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

   $ oc logs -f dc/<name>

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

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

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

프로세스

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가 생성되지 않습니다.

프로세스

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

   $ oc scale dc frontend --replicas=3

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

프로세스

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

프로세스

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

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

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

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

   참고

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

프로세스

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

   $ oc edit dc/<deployment_config>

2. serviceAccount 및 serviceAccountName 매개변수를 spec 필드에 추가하고 사용할 서비스 계정을 지정합니다.

   spec:
     securityContext: {}
     serviceAccount: <service_account>
     serviceAccountName: <service_account>