6.3. 배포 프로세스 관리
6.3.1. DeploymentConfig 오브젝트 관리
AWS 4.14에서 Red Hat OpenShift Service는 더 이상
사용되지 않습니다. DeploymentConfig
오브젝트는 계속 지원되지만 새 설치에는 권장되지 않습니다. 보안 관련 및 심각한 문제만 수정됩니다.
대신 Deployment
오브젝트 또는 다른 대안을 사용하여 Pod에 선언적 업데이트를 제공합니다.
DeploymentConfig
오브젝트는 AWS 웹 콘솔의 워크로드 페이지 또는 oc
CLI를 사용하여 Red Hat OpenShift Service에서 관리할 수 있습니다. 다음 절차에서는 달리 명시하지 않는 한 CLI 사용법을 보여줍니다.
6.3.1.1. 배포 시작
롤아웃을 시작하여 애플리케이션 배포 프로세스를 시작할 수 있습니다.
프로세스
기존
DeploymentConfig
오브젝트에서 새 배포 프로세스를 시작하려면 다음 명령을 실행합니다.$ oc rollout latest dc/<name>
참고배포 프로세스가 이미 진행 중인 경우 명령에서 메세지를 표시하고 새 복제 컨트롤러가 배포되지 않습니다.
6.3.1.2. 배포 보기
배포를 보고 애플리케이션의 모든 사용 가능한 리버전에 대한 기본 정보를 얻을 수 있습니다.
프로세스
현재 실행 중인 배포 프로세스를 포함하여 제공된
DeploymentConfig
오브젝트에 대해 최근 생성된 모든 복제 컨트롤러에 대한 세부 정보를 보려면 다음 명령을 실행합니다.$ oc rollout history dc/<name>
버전과 관련된 세부 정보를 보려면
--revision
플래그를 추가합니다.$ oc rollout history dc/<name> --revision=1
DeploymentConfig
오브젝트 및 이 오브젝트의 최신 버전에 대한 자세한 내용을 보려면oc describe
명령을 사용합니다.$ oc describe dc <name>
6.3.1.3. 배포 재시도
DeploymentConfig
오브젝트의 현재 리버전을 배포하지 못한 경우 배포 프로세스를 재시작할 수 있습니다.
프로세스
실패한 배포 프로세스를 재시작하려면 다음을 수행합니다.
$ oc rollout retry dc/<name>
최신 버전이 성공적으로 배포된 경우 명령에서 메시지를 표시하고 배포 프로세스가 다시 수행되지 않습니다.
참고배포를 다시 시도하면 배포 프로세스가 다시 시작되고 새 배포 리버전이 생성되지 않습니다. 재시작한 복제 컨트롤러의 구성은 실패한 경우의 구성과 동일합니다.
6.3.1.4. 배포 롤백
롤백은 애플리케이션을 이전 리버전으로 되돌리고 REST API, CLI 또는 웹 콘솔을 사용하여 수행할 수 있습니다.
프로세스
마지막으로 성공적으로 배포된 구성 리버전으로 롤백하려면 다음을 수행합니다.
$ oc rollout undo dc/<name>
DeploymentConfig
오브젝트의 템플릿이 undo 명령에 지정된 배포 리버전과 일치하도록 되돌아가고 새 복제 컨트롤러가 시작됩니다. 리버전이--to-revision
을 사용하여 지정되지 않은 경우 마지막으로 성공적으로 배포된 리버전이 사용됩니다.롤백이 완료되면 실수로 새 배포 프로세스가 시작되지 않도록
DeploymentConfig
오브젝트에서 이미지 변경 트리거가 비활성화됩니다.이미지 변경 트리거를 다시 활성화하려면 다음을 수행합니다.
$ oc set triggers dc/<name> --auto
배포 구성에서는 최신 배포 프로세스가 실패하는 경우 마지막으로 성공한 구성 리버전으로의 자동 롤백도 지원합니다. 이 경우 배포되지 않은 최신 템플릿은 시스템에서 그대로 유지되며 사용자가 해당 구성을 수정할 수 있습니다.
6.3.1.5. 컨테이너 내에서 명령 실행
이미지의 ENTRYPOINT
를 초과하여 컨테이너의 시작 동작을 수정하는 명령을 컨테이너에 추가할 수 있습니다. 이 명령은 지정된 시점에 배포당 한 번만 실행할 수 있는 라이프사이클 후크와는 다릅니다.
프로세스
DeploymentConfig
오브젝트의spec
필드에command
매개변수를 추가합니다. 또한command
(command
가 존재하지 않는 경우ENTRYPOINT
)를 수정하는args
필드를 추가할 수 있습니다.kind: DeploymentConfig apiVersion: apps.openshift.io/v1 metadata: name: example-dc # ... spec: template: # ... spec: containers: - name: <container_name> image: 'image' command: - '<command>' args: - '<argument_1>' - '<argument_2>' - '<argument_3>'
예를 들어
-jar
및/opt/app-root/springboots2idemo.jar
인수를 사용하여java
명령을 실행하려면 다음을 수행합니다.kind: DeploymentConfig apiVersion: apps.openshift.io/v1 metadata: name: example-dc # ... spec: template: # ... spec: containers: - name: example-spring-boot image: 'image' command: - java args: - '-jar' - /opt/app-root/springboots2idemo.jar # ...
6.3.1.6. 배포 로그 보기
프로세스
지정된
DeploymentConfig
오브젝트의 최신 리버전 로그를 스트리밍하려면 다음을 수행합니다.$ oc logs -f dc/<name>
최신 리버전이 실행 중이거나 실패한 경우 명령에서 Pod 배포를 담당하는 프로세스의 로그를 반환합니다. 성공하는 경우 애플리케이션 Pod의 로그를 반환합니다.
또한 실패한 이전 배포 프로세스(복제 컨트롤러 및 배포 Pod)가 존재하고 이를 수동으로 정리하거나 삭제하지 않은 경우에만 이러한 프로세스의 로그를 볼 수 있습니다.
$ oc logs --version=1 dc/<name>
6.3.1.7. 배포 트리거
DeploymentConfig
오브젝트에는 클러스터 내부 이벤트에 대한 응답으로 새 배포 프로세스 생성을 유도하는 트리거가 포함될 수 있습니다.
DeploymentConfig
오브젝트에 트리거가 정의되어 있지 않은 경우 기본적으로 구성 변경 트리거가 추가됩니다. Trigger가 빈 필드로 정의되면 배포를 수동으로 시작해야 합니다.
구성 변경 배포 트리거
구성 변경 트리거를 사용하면 DeploymentConfig
오브젝트의 Pod 템플릿에서 구성 변경이 탐지될 때마다 새 복제 컨트롤러가 생성됩니다.
DeploymentConfig
오브젝트에 구성 변경 트리거를 정의하면 DeploymentConfig
오브젝트 자체를 생성한 직후 첫 번째 복제 컨트롤러가 자동으로 생성되고 정지되지 않습니다.
구성 변경 배포 트리거
kind: DeploymentConfig apiVersion: apps.openshift.io/v1 metadata: name: example-dc # ... spec: # ... triggers: - type: "ConfigChange"
이미지 변경 배포 트리거
이미지 변경 트리거를 사용하면 이미지 스트림 태그 내용이 변경될 때마다(새 버전의 이미지를 내보낼 때) 새 복제 컨트롤러가 생성됩니다.
이미지 변경 배포 트리거
kind: DeploymentConfig
apiVersion: apps.openshift.io/v1
metadata:
name: example-dc
# ...
spec:
# ...
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
사용) 이미지 변경 트리거가 가리키는 이미지 스트림 태그가 아직 존재하지 않는 경우 빌드에서 이미지를 가져오거나 이미지 스트림 태그로 내보내는 즉시 초기 배포 프로세스가 자동으로 시작됩니다.
6.3.1.7.1. 배포 트리거 설정
프로세스
oc set triggers
명령을 사용하여DeploymentConfig
오브젝트에 대한 배포 트리거를 설정할 수 있습니다. 예를 들어 이미지 변경 트리거를 설정하려면 다음 명령을 사용하십시오.$ oc set triggers dc/<dc_name> \ --from-image=<project>/<image>:<tag> -c <container_name>
6.3.1.8. 배포 리소스 설정
배포는 노드에서 리소스(메모리, CPU, 임시 스토리지)를 사용하는 Pod에 의해 완료됩니다. 기본적으로 Pod는 바인딩되지 않은 노드 리소스를 사용합니다. 그러나 프로젝트에서 기본 컨테이너 제한을 지정하는 경우 Pod는 해당 제한까지 리소스를 사용합니다.
배포를 위한 최소 메모리 제한은 12MB입니다. 메모리를 할당할 수 없음
Pod 이벤트로 인해 컨테이너가 시작되지 않으면 메모리 제한이 너무 낮은 것입니다. 메모리 제한을 늘리거나 제거합니다. 제한을 제거하면 Pod에서 바인딩되지 않은 노드 리소스를 사용할 수 있습니다.
리소스 제한을 배포 전략의 일부로 지정하여 리소스 사용을 제한할 수도 있습니다. 배포 리소스는 재현, 롤링 또는 사용자 정의 배포 전략과 함께 사용할 수 있습니다.
프로세스
다음 예에서 각
resources
,cpu
,memory
,ephemeral-storage
는 선택 사항입니다.kind: Deployment apiVersion: apps/v1 metadata: name: hello-openshift # ... spec: # ... type: "Recreate" resources: limits: cpu: "100m" 1 memory: "256Mi" 2 ephemeral-storage: "1Gi" 3
그러나 프로젝트에 할당량을 정의한 경우 다음 두 항목 중 하나가 필요합니다.
requests
가 명시적으로 설정된resources
섹션:kind: Deployment apiVersion: apps/v1 metadata: name: hello-openshift # ... spec: # ... type: "Recreate" resources: requests: 1 cpu: "100m" memory: "256Mi" ephemeral-storage: "1Gi"
- 1
requests
오브젝트에 할당량의 리소스 목록에 해당하는 리소스 목록이 포함되어 있습니다.
-
프로젝트에 정의된 제한 범위:
LimitRange
오브젝트의 기본값은 배포 프로세스 중 생성된 Pod에 적용됩니다.
배포 리소스를 설정하려면 위 옵션 중 하나를 선택하십시오. 그러지 않으면 할당량을 충족하지 못하여 배포 Pod가 생성되지 않습니다.
6.3.1.9. 수동 스케일링
롤백 외에도 수동으로 스케일링하여 복제본 수를 세부적으로 제어할 수 있습니다.
autoscale
명령을 사용하여 Pod를 자동 스케일링할 수도 있습니다.
프로세스
DeploymentConfig
오브젝트를 수동으로 스케일링하려면oc scale
명령을 사용합니다. 예를 들어 다음 명령은frontend
DeploymentConfig
오브젝트의 복제본 수를3
으로 설정합니다.$ oc scale dc frontend --replicas=3
결국 복제본 수는
DeploymentConfig
오브젝트의frontend
에서 구성한 배포의 원하는 현재 상태로 전달됩니다.
6.3.1.10. DeploymentConfig 오브젝트에서 프라이빗 리포지토리에 액세스
프라이빗 리포지토리에서 이미지에 액세스할 수 있도록 DeploymentConfig
오브젝트에 시크릿을 추가할 수 있습니다. 다음 절차에서는 AWS 웹 콘솔 방법의 Red Hat OpenShift Service를 보여줍니다.
프로세스
- 새 프로젝트를 생성합니다.
-
워크로드
시크릿으로 이동합니다. - 개인 이미지 리포지토리에 액세스하기 위한 인증 정보가 포함된 시크릿을 생성합니다.
- 워크로드 → DeploymentConfig로 이동합니다.
-
DeploymentConfig
오브젝트를 생성합니다. -
DeploymentConfig
오브젝트 편집기 페이지에서 시크릿 가져오기를 설정하고 변경 사항을 저장합니다.
6.3.1.11. 다른 서비스 계정으로 Pod 실행
기본 계정 이외의 서비스 계정으로 Pod를 실행할 수 있습니다.
프로세스
DeploymentConfig
오브젝트를 편집합니다.$ oc edit dc/<deployment_config>
serviceAccount
및serviceAccountName
매개변수를spec
필드에 추가하고 사용할 서비스 계정을 지정합니다.apiVersion: apps.openshift.io/v1 kind: DeploymentConfig metadata: name: example-dc # ... spec: # ... securityContext: {} serviceAccount: <service_account> serviceAccountName: <service_account>