2.4. OpenShift 4.x에서 Fuse 콘솔 설정
OpenShift 4.x에서 Fuse 콘솔을 설정하려면 보안, 설치 및 배포가 필요합니다.
먼저 2.4.1절. “OpenShift 4.x에서 Fuse Console을 보호하기 위한 인증서 생성” 에 설명된 대로 Fuse 콘솔을 보호할 수 있도록 클라이언트 인증서를 생성해야 합니다.
클라이언트 인증서를 생성한 후 Fuse Console을 설치하고 배포하기 위한 다음과 같은 옵션이 있습니다.
2.4.2절. “OperatorHub를 사용하여 OpenShift 4.x에 Fuse Console 설치 및 배포”
Fuse Console Operator를 사용하여 특정 네임스페이스의 Fuse 애플리케이션에 액세스할 수 있도록 Fuse Console을 설치하고 배포할 수 있습니다.
2.4.3절. “명령줄을 사용하여 OpenShift 4.x에 Fuse Console 설치 및 배포”
명령줄과 Fuse Console 템플릿 중 하나를 사용하여 Fuse Console을 설치하고 배포하여 OpenShift 클러스터 또는 특정 네임스페이스에 있는 여러 네임스페이스의 Fuse 애플리케이션에 액세스할 수 있습니다.
명령줄 옵션을 사용하여 2.4.3절. “명령줄을 사용하여 OpenShift 4.x에 Fuse Console 설치 및 배포” 에 설명된 대로 RBAC(역할 기반 액세스 제어) 중 하나를 설치하여 Fuse 콘솔에 대한 RBAC(역할 기반 액세스 제어)를 구현할 수 있습니다.
참고이번 릴리스에서는 Operator를 사용하여 Fuse Console을 설치할 때 RBAC가 지원되지 않습니다.
2.4.1. OpenShift 4.x에서 Fuse Console을 보호하기 위한 인증서 생성
OpenShift 4.x에서는 Fuse Console 프록시와 Jolokia 에이전트 간에 안전하게 연결을 유지하려면 Fuse Console을 배포하기 전에 클라이언트 인증서를 생성해야 합니다. 서비스 서명 인증 기관 개인 키를 사용하여 클라이언트 인증서에 서명해야 합니다.
각 OpenShift 클러스터에 대해 별도의 클라이언트 인증서를 생성하고 서명해야 합니다. 두 개 이상의 클러스터에 동일한 인증서를 사용하지 마십시오.
사전 요구 사항
-
OpenShift 클러스터에 대한
클러스터 관리자
액세스 권한이 있어야 합니다. 두 개 이상의 OpenShift 클러스터에 대한 인증서를 생성하고 이전에 현재 디렉터리에 다른 클러스터에 대한 인증서를 생성한 경우 다음 중 하나를 수행하여 현재 클러스터에 대한 다른 인증서를 생성하십시오.
-
현재 디렉터리에서 기존 인증서 파일(예:
ca.crt
,ca.key
,ca.srl
)을 삭제합니다. 다른 작업 디렉터리로 변경합니다. 예를 들어 현재 작업 디렉터리 이름이
cluster1
인 경우 새cluster2
디렉터리를 생성하고 작업 디렉터리를 해당 디렉터리로 변경합니다.mkdir ../cluster2
cd ../cluster2
-
현재 디렉터리에서 기존 인증서 파일(예:
절차
클러스터 관리자 액세스 권한이 있는 사용자로 OpenShift에 로그인합니다.
oc login -u <user_with_cluster_admin_role>
다음 명령을 실행하여 서비스 서명 인증 기관 키를 검색합니다.
인증서를 검색하려면 다음을 수행합니다.
oc get secrets/signing-key -n openshift-service-ca -o "jsonpath={.data['tls\.crt']}" | base64 --decode > ca.crt
개인 키를 검색하려면 다음을 수행합니다.
oc get secrets/signing-key -n openshift-service-ca -o "jsonpath={.data['tls\.key']}" | base64 --decode > ca.key
easyrsa
,openssl
또는cfssl
을 사용하여 Kubernetes 인증서 관리에 설명된 대로 클라이언트 인증서를 생성합니다.다음은 openssl을 사용하는 예제 명령입니다.
개인 키를 생성합니다.
openssl genrsa -out server.key 2048
CSR 구성 파일을 작성합니다.
cat <<EOT >> csr.conf [ req ] default_bits = 2048 prompt = no default_md = sha256 distinguished_name = dn [ dn ] CN = fuse-console.fuse.svc [ v3_ext ] authorityKeyIdentifier=keyid,issuer:always keyUsage=keyEncipherment,dataEncipherment,digitalSignature extendedKeyUsage=serverAuth,clientAuth EOT
CSR을 생성합니다.
openssl req -new -key server.key -out server.csr -config csr.conf
서명된 인증서를 발급합니다.
openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out server.crt -days 10000 -extensions v3_ext -extfile csr.conf
다음 단계
Fuse Console 설치 방법에 따라 다음 섹션에 설명된 대로 Fuse Console의 시크릿을 생성하려면 이 인증서가 필요합니다.
2.4.2. OperatorHub를 사용하여 OpenShift 4.x에 Fuse Console 설치 및 배포
OpenShift 4.x에 Fuse Console을 설치하려면 OpenShift OperatorHub에 제공된 Fuse Console Operator를 사용할 수 있습니다. Fuse 콘솔을 배포하려면 설치된 Operator의 인스턴스를 만듭니다.
사전 요구 사항
-
OpenShift 클러스터에 대한
클러스터 관리자
액세스 권한이 있어야 합니다. - OpenShift 4.x에서 Fuse 콘솔을 보호하기 위해 인증서 생성에 설명된 대로 Fuse Console의 클라이언트 인증서를 생성 했습니다.
절차
Fuse 콘솔을 설치하고 배포하려면 다음을 수행합니다.
-
웹 브라우저에서
클러스터 관리자
액세스 권한이 있는 사용자로 OpenShift 콘솔에 로그인합니다. - 홈 > 프로젝트를 선택한 다음 Fuse 콘솔을 추가할 프로젝트를 선택합니다.
- Operators 를 클릭한 다음 OperatorHub 를 클릭합니다.
- 검색 필드 창에서 Fuse Console 을 입력하여 Operator 목록을 필터링합니다.
- Fuse Console Operator 를 클릭합니다.
Fuse Console Operator 설치 창에서 설치를 클릭합니다.
Create Operator Subscription 양식이 열립니다.
설치 모드 의 경우 Fuse Console Operator를 특정 네임스페이스(현재 OpenShift 프로젝트)에 설치합니다.
그런 다음 Operator를 설치한 후 Fuse Console을 배포하여 클러스터의 모든 네임스페이스에서 애플리케이션을 모니터링하거나 Fuse Console Operator가 설치된 네임스페이스에서만 애플리케이션을 모니터링하도록 선택할 수 있습니다.
승인 전략 의 경우 자동 또는 수동 을 선택하여 OpenShift에서 Fuse Console Operator에 대한 업데이트를 처리하는 방법을 구성할 수 있습니다.
- 자동 업데이트를 선택하면 새 버전의 Fuse Console Operator가 사용 가능할 때 OLM(Operator Lifecycle Manager)은 개입 없이 Fuse Console의 실행 중인 인스턴스를 자동으로 업그레이드합니다.
- 수동 업데이트를 선택하면 최신 버전의 Operator가 사용 가능할 때 OLM에서 업데이트 요청을 생성합니다. 클러스터 관리자는 Fuse Console Operator가 새 버전으로 업데이트되도록 해당 업데이트 요청을 수동으로 승인해야 합니다.
Subscribe를 클릭합니다.
OpenShift는 현재 네임스페이스에 Fuse Console Operator를 설치합니다.
- 설치를 확인하려면 Operator를 클릭한 다음 Installed Operators 를 클릭합니다. Operator 목록에서 Fuse Console을 볼 수 있습니다.
터미널 창에서 OpenShift 4.x에서 Fuse Console 보안에서 생성한 인증서를 사용하여 시크릿을 생성하고, APP_NAME 이 Fuse Console 배포 이름(예:
fuse-console
)을 사용하여 Fuse 콘솔에 마운트합니다.oc create secret tls APP_NAME-tls-proxying --cert server.crt --key server.key
예를 들어 Fuse Console 애플리케이션의 이름이 fuse-console 인 경우 다음 명령을 입력합니다.
oc create secret tls fuse-console-tls-proxying --cert server.crt --key server.key
성공하면 이 명령은 보안이 생성되었는지 확인하는 응답을 반환합니다. 예를 들면 다음과 같습니다.
secret/fuse-console-operator-tls-proxying created
OpenShift 웹 콘솔을 사용하여 Fuse 콘솔을 배포하려면 다음을 수행합니다.
- 설치된 Operator 목록에서 이름 열에서 Fuse Console 을 클릭합니다.
제공된 API 아래의 개요 페이지에서 인스턴스 생성을 클릭합니다. 새 CRD(Custom Resource Definition) 파일이 열립니다.
기본적으로 Fuse Console은 현재 네임스페이스에 배포됩니다.
Fuse Console을 배포하여 현재 네임스페이스 내에서 애플리케이션을 검색하고 관리하려면 다음 단계로 건너뜁니다.
선택적으로 클러스터(및 인증된 사용자)에 있는 모든 네임스페이스에서 애플리케이션을 검색하고 관리하려면
spec.type
필드의 값을네임스페이스
에서클러스터로
변경하여 CRD 파일을 편집합니다.생성을 클릭합니다.
Fuse Console을 배포한 후 Fuse Console CRD 페이지가 새 Fuse Console 서비스를 표시합니다.
Fuse 7.7.0의 경우 배포된 Fuse Console은 잠시 후에 불안정해질 수 있으며 오류 활성 상태 프로브와 함께 지속적으로 중지 및 다시 시작할 수 있습니다.
이러한 불안정성은 Fuse Console pod가 OpenShift에서 메모리 할당을 초과하기 때문에 발생합니다.
불안정성을 수정하려면 다음과 같이 Fuse Console 배포의 메모리 제한을 수정합니다.
-
oc rollout pause
명령을 사용하여 Fuse Console Pod의 자동 재배포를 일시 중지합니다. -
Fuse Console의 배포 구성(YAML 파일)을 편집하여 메모리 할당을 늘립니다.
containers:resources:limits:memory
및containers:resources:requests:memory
필드의 값을 32Mi 에서 100Mi 로 변경합니다. -
oc rollout resume
명령을 사용하여 Fuse Console Pod의 자동 재배포를 다시 시작합니다.
Fuse 콘솔을 열려면 다음을 수행합니다.
네임스페이스 배포의 경우 OpenShift 웹 콘솔에서 Fuse Console Operator를 설치한 프로젝트를 열고 개요 를 선택합니다. 프로젝트 개요 페이지에서 시작 자 섹션까지 아래로 스크롤하고 Fuse Console URL을 클릭하여 엽니다.
클러스터 배포의 경우 OpenShift 웹 콘솔의 제목 표시줄에서 그리드 아이콘( )을 클릭합니다. 팝업 메뉴의 Red Hat 애플리케이션 에서 Fuse Console URL 링크를 클릭합니다.
Fuse 콘솔에 로그인합니다.
필요한 권한이 나열된 브라우저에서 권한 부여 페이지가 열립니다.
선택한 권한 허용을 클릭합니다.
브라우저에서 Fuse Console이 열리고 액세스할 수 있는 권한이 있는 Fuse 애플리케이션 포드가 표시됩니다.
확인할 애플리케이션에 대한 연결을 클릭합니다.
Fuse Console에 애플리케이션이 표시되는 새 브라우저 창이 열립니다.
2.4.3. 명령줄을 사용하여 OpenShift 4.x에 Fuse Console 설치 및 배포
OpenShift 4.x에서는 명령줄에서 Fuse 콘솔을 설치하고 배포할 다음 배포 옵션 중 하나를 선택할 수 있습니다.
- 클러스터 - Fuse Console은 OpenShift 클러스터의 여러 네임스페이스(프로젝트)에 배포된 Fuse 애플리케이션을 검색하고 연결할 수 있습니다. 이 템플릿을 배포하려면 OpenShift 클러스터에 대한 관리자 역할이 있어야 합니다.
- 역할 기반 액세스 제어가 있는 클러스터 - 구성 가능한 역할 기반 액세스 제어(RBAC)가 있는 클러스터 템플릿입니다. 자세한 내용은 OpenShift 4.x 의 Fuse Console에 대한 역할 기반 액세스 제어에서 OpenShift 4.x의 Fuse Console에 대한 역할 기반 액세스 제어를 참조하십시오.
- 네임스페이스 - Fuse Console은 특정 OpenShift 프로젝트(네임스페이스)에 액세스할 수 있습니다. 이 템플릿을 배포하려면 OpenShift 프로젝트에 대한 관리자 역할이 있어야 합니다.
- 역할 기반 액세스 제어가 있는 네임스페이스 - 구성 가능한 RBAC가 있는 네임스페이스 템플릿입니다. 자세한 내용은 OpenShift 4.x 의 Fuse Console에 대한 역할 기반 액세스 제어에서 OpenShift 4.x의 Fuse Console에 대한 역할 기반 액세스 제어를 참조하십시오.
Fuse Console 템플릿의 매개변수 목록을 보려면 다음 OpenShift 명령을 실행합니다.
oc process --parameters -f https://github.com/jboss-fuse/application-templates/blob/application-templates-2.1.0.fuse-sb2-7_11_1-00016-redhat-00002//fuse-console-namespace-os4.json
사전 요구 사항
- Fuse 콘솔을 설치하고 배포하기 전에 OpenShift 4.x에서 Fuse Console을 보호하기 위해 인증서 생성에 설명된 대로 서비스 서명 인증 기관으로 서명된 클라이언트 인증서를 생성해야 합니다.
-
OpenShift
클러스터에 대한 클러스터 관리자
역할이 있어야 합니다. - OpenShift 4.x 서버에 Fuse 이미지 스트림 설치 및 템플릿에 설명된 대로 Fuse 콘솔 이미지 스트림(다른 Fuse 이미지 스트림과 함께)이 설치됩니다.
절차
다음 명령을 사용하여 모든 템플릿 목록을 검색하여 Fuse Console 이미지 스트림이 설치되었는지 확인합니다.
oc get template -n openshift
선택적으로 이미 설치된 이미지 스트림을 새 릴리스 태그로 업데이트하려면 다음 명령을 사용하여 Fuse Console 이미지를 openshift 네임스페이스로 가져옵니다.
oc import-image fuse7/fuse7-console:1.7 --from=registry.redhat.io/fuse7/fuse-console:1.7 --confirm -n openshift
다음 명령을 실행하여 Fuse Console APP_NAME 값을 가져옵니다.
oc process --parameters -f TEMPLATE-FILENAME
여기서
TEMPLATE-FILENAME
은 다음 템플릿 중 하나입니다.클러스터 템플릿:
구성 가능한 RBAC가 있는 클러스터 템플릿:
네임스페이스 템플릿:
구성 가능한 RBAC가 있는 네임스페이스 템플릿:
예를 들어 구성 가능한 RBAC가 있는 클러스터 템플릿의 경우 다음 명령을 실행합니다.
oc process --parameters -f https://github.com/jboss-fuse/application-templates/blob/application-templates-2.1.0.fuse-sb2-7_11_1-00016-redhat-00002//fuse-console-cluster-rbac.yml
OpenShift 4.x에서 Fuse Console 보안에서 생성한 인증서에서 다음 명령을 사용하여 시크릿을 생성하고 Fuse Console에 마운트합니다(여기서 APP_NAME 은 Fuse Console 애플리케이션의 이름입니다).
oc create secret tls APP_NAME-tls-proxying --cert server.crt --key server.key
다음 명령을 실행하여 Fuse Console 템플릿의 로컬 복사본을 기반으로 새 애플리케이션을 생성합니다. 여기서 myproject 는 OpenShift 프로젝트의 이름, mytemp 는 Fuse Console 템플릿이 포함된 로컬 디렉터리의 경로입니다. myhost 는 Fuse Console에 액세스할 수 있는 호스트 이름입니다.
클러스터 템플릿의 경우:
oc new-app -n myproject -f {templates-base-url}/fuse-console-cluster-os4.json -p ROUTE_HOSTNAME=myhost”
RBAC 템플릿이 있는 클러스터의 경우:
oc new-app -n myproject -f {templates-base-url}/fuse-console-cluster-rbac.yml -p ROUTE_HOSTNAME=myhost”
네임스페이스 템플릿의 경우:
{templates-base-url}/fuse-console-namespace-os4.json
RBAC 템플릿이 있는 네임스페이스의 경우:
oc new-app -n myproject -f {templates-base-url}/fuse-console-namespace-rbac.yml
OpenShift 웹 콘솔을 열 수 있도록 Fuse Console을 구성하려면 다음 명령을 실행하여
OPENSHIFT_WEB_CONSOLE_URL
환경 변수를 설정합니다.oc set env dc/${APP_NAME} OPENSHIFT_WEB_CONSOLE_URL=`oc get -n openshift-config-managed cm console-public -o jsonpath={.data.consoleURL}`
다음 명령을 실행하여 Fuse Console 배포의 상태 및 URL을 가져옵니다.
oc status
- 브라우저에서 Fuse 콘솔에 액세스하려면 7단계로 반환되는 URL(예: https://fuse-console.192.168.64.12.nip.io)을 사용합니다.
2.4.3.1. OpenShift 4.x에서 Fuse Console에 대한 역할 기반 액세스 제어
Fuse 콘솔은 OpenShift에서 제공하는 사용자 권한에 따라 액세스를 유추하는 RBAC(역할 기반 액세스 제어)를 제공합니다. Fuse 콘솔에서 RBAC는 Pod에서 Cryostat 작업을 수행할 수 있는 사용자의 기능을 결정합니다.
OpenShift 권한 부여에 대한 자세한 내용은 OpenShift 문서의 "RBAC를 사용하여 권한 정의 및 적용" 섹션을 참조하십시오.
Fuse Console에 대한 역할 기반 액세스를 구현하려면 명령줄을 사용하여 OpenShift 4.x에 Fuse 콘솔 설치 및 배포에 설명된 대로 RBAC(fuse-console-cluster-rbac.yml
또는 fuse-console-namespace-rbac.yml
)로 구성할 수 있는 템플릿 중 하나를 사용해야 합니다.
이번 릴리스에서는 Operator를 사용하여 Fuse Console을 설치할 때 RBAC가 지원되지 않습니다.
Fuse Console RBAC는 OpenShift의 Pod 리소스에 대한 사용자 동사 액세스를 활용하여 Fuse Console에서 Pod의 작업에 대한 사용자의 액세스 권한을 결정합니다. 기본적으로 Fuse Console의 사용자 역할은 다음 두 가지가 있습니다.
admin
사용자가 OpenShift에서 포드를 업데이트할 수 있는 경우 사용자는 Fuse Console의 admin 역할을 유추합니다. 사용자는 Pod에 대해 Fuse Console에서 write Cryostat 작업을 수행할 수 있습니다.
뷰어
사용자가 OpenShift에서 포드를 가져올 수 있는 경우 사용자는 Fuse Console의 뷰어 역할을 유추합니다. 사용자는 Pod에 대해 Fuse Console에서 읽기 전용 작업을 수행할 수 있습니다.
Fuse 콘솔을 설치하는 데 RBAC 템플릿을 사용하지 않는 경우 Pod 리소스에 대한 update 동사가 부여된 OpenShift 사용자만 Fuse Console Cryostats 작업을 수행할 수 있습니다. Pod 리소스에 get 동사가 부여된 사용자는 포드를 볼 수 있지만 Fuse Console 작업을 수행할 수 없습니다.
2.4.3.2. OpenShift 4.x에서 Fuse Console에 대한 액세스 역할 확인
Fuse Console 역할 기반 액세스 제어는 Pod에 대한 사용자의 OpenShift 권한에서 유추됩니다. 특정 사용자에게 부여된 Fuse Console 액세스 역할을 확인하려면 Pod의 사용자에게 부여된 OpenShift 권한을 받으십시오.
사전 요구 사항
- 사용자 이름을 알고 있습니다.
- Pod의 이름을 알고 있습니다.
절차
사용자에게 Pod에 대한 Fuse Console admin 역할이 있는지 확인하려면 다음 명령을 실행하여 OpenShift에서 Pod를 업데이트할 수 있는지 확인합니다.
oc auth can-i update pods/<pod> --as <user>
응답이
yes
인 경우 사용자에게 포드에 대한 Fuse Console admin 역할이 있습니다. 사용자는 Pod에 대해 Fuse Console에서 write Cryostat 작업을 수행할 수 있습니다.사용자에게 Pod에 대한 Fuse Console 뷰어 역할이 있는지 확인하려면 다음 명령을 실행하여 OpenShift에서 Pod를 가져올 수 있는지 확인합니다.
oc auth can-i get pods/<pod> --as <user>
응답이
yes
인 경우 사용자에게 포드에 대한 Fuse Console viewer 역할이 있습니다. 사용자는 Pod에 대해 Fuse Console에서 읽기 전용 작업을 수행할 수 있습니다. 상황에 따라 Fuse Console은 옵션을 비활성화하거나 사용자가 쓰기를 시도할 때 "operation not allowed for this user" 메시지를 표시하여 뷰어 역할의 사용자가 쓰기를 수행하지 못하도록 합니다.응답이
없는
경우 사용자는 Fuse Console 역할에 바인딩되지 않으며 사용자는 Fuse Console의 포드를 볼 수 없습니다.
2.4.3.3. OpenShift 4.x의 Fuse Console에 대한 역할 기반 액세스 사용자 정의
deployment-cluster-rbac.yml
및 deployment-namespace-rbac.yml
템플릿은 구성 파일( ACLs.yml )이 포함된 ConfigMap을 생성합니다.
구성 파일은 Cryostat 작업에 허용되는 역할을 정의합니다.
사전 요구 사항
Fuse Console RBAC 템플릿 중 하나를 사용하여 Fuse Console을 설치했습니다(deployment-cluster-rbac.yml
또는 deployment-namespace-rbac.yml
).
절차
Fuse Console RBAC 역할을 사용자 정의하려면 다음을 수행합니다.
다음 명령을 실행하여 ConfigMap을 편집합니다.
oc edit cm $APP_NAME-rbac
- 파일을 저장하여 변경 사항을 적용합니다. OpenShift는 Fuse Console 포드를 자동으로 다시 시작합니다.
2.4.3.4. OpenShift 4.x에서 Fuse Console에 대한 역할 기반 액세스 제어 비활성화
Fuse 콘솔의 HAWTIO_ONLINE_RBAC_ACL
환경 변수는 역할 기반 액세스 제어(RBAC) ConfigMap 구성 파일 경로를 OpenShift 서버에 전달합니다. HAWTIO_ONLINE_RBAC_ACL
환경 변수가 지정되지 않은 경우 RBAC 지원이 비활성화되고 Pod 리소스(OpenShift의)에 대한 업데이트 동사가 부여된 사용자만 Fuse Console의 Pod에서 Cryostat 작업을 호출할 수 있습니다.
사전 요구 사항
Fuse Console RBAC 템플릿 중 하나를 사용하여 Fuse Console을 설치했습니다(deployment-cluster-rbac.yml
또는 deployment-namespace-rbac.yml
).
절차
Fuse Console에 대한 역할 기반 액세스를 비활성화하려면 다음을 수행합니다.
- OpenShift에서 Fuse Console의 Deployment Config 리소스를 편집합니다.
전체
HAWTIO_ONLINE_RBAC_ACL
환경 변수 정의를 삭제합니다.(값만 지우는 것만으로는 충분하지 않습니다.)
- 파일을 저장하여 변경 사항을 적용합니다. OpenShift는 Fuse Console 포드를 자동으로 다시 시작합니다.
2.4.4. OpenShift 4.x에서 Fuse Console 업그레이드
Red Hat OpenShift 4.x는 Red Hat Fuse Operator를 포함하여 Operator에 대한 업데이트를 처리합니다. 자세한 내용은 Operator OpenShift 설명서 를 참조하십시오.
Operator 업데이트는 애플리케이션 구성 방법에 따라 애플리케이션 업그레이드를 트리거할 수 있습니다.
Fuse Console 애플리케이션의 경우 애플리케이션 사용자 정의 리소스 정의의 .spec.version
필드를 편집하여 애플리케이션으로의 업그레이드를 트리거할 수도 있습니다.
OCP 4.6 이후 Fuse Console Operator의 Operator 채널 이름이 alpha
에서 fuse-console-7.7.x
로 변경되었습니다. OpenShift를 OCP 4.6으로 업그레이드한 후 새 Operator 채널을 볼 수 없는 경우 OpenShift의 OperatorHub에서 표시되는 Operator 채널을 새로 고치는 방법에 대한 자세한 내용은 알려진 문제 ENT Cryostat-15232 를 참조하십시오.
사전 요구 사항
- OpenShift 클러스터 관리자 권한이 있어야 합니다.
절차
Fuse Console 애플리케이션을 업그레이드하려면 다음을 수행합니다.
터미널 창에서 다음 명령을 사용하여 애플리케이션 사용자 정의 리소스 정의의
.spec.version
필드를 변경합니다.oc patch <project-name> <custom-resource-name> --type='merge' -p '{"spec":{"version":"1.7.1"}}'
예를 들면 다음과 같습니다.
oc patch myproject example-fuseconsole --type='merge' -p '{"spec":{"version":"1.7.1"}}'
애플리케이션 상태가 업데이트되었는지 확인합니다.
oc get myproject
응답에는 버전 번호를 포함하여 애플리케이션에 대한 정보가 표시됩니다.
NAME AGE URL IMAGE example-fuseconsole 1m https://fuseconsole.192.168.64.38.nip.io docker.io/fuseconsole/online:1.7.1
.spec.version
필드의 값을 변경하면 OpenShift에서 애플리케이션을 자동으로 재배포합니다.버전 변경으로 트리거되는 재배포 상태를 확인하려면 다음을 수행합니다.
oc rollout status deployment.v1.apps/example-fuseconsole
성공적인 배포에는 다음 응답이 표시됩니다.
deployment "example-fuseconsole" successfully rolled out