2.2. 명령줄을 사용하여 OpenShift 4.x에 Fuse Console 설치 및 배포


OpenShift 4.x에서는 명령줄에서 Fuse 콘솔을 설치하고 배포할 다음 배포 옵션 중 하나를 선택할 수 있습니다.

  • 클러스터 - Fuse Console은 OpenShift 클러스터의 여러 네임스페이스(프로젝트)에 배포된 Fuse 애플리케이션을 검색하고 연결할 수 있습니다. 이 템플릿을 배포하려면 OpenShift 클러스터에 대한 관리자 역할이 있어야 합니다.
  • 역할 기반 액세스 제어가 있는 클러스터 - 구성 가능한 역할 기반 액세스 제어(RBAC)가 있는 클러스터 템플릿입니다. 자세한 내용은 OpenShift 4.x의 Fuse Console에 대한 역할 기반 액세스 제어를 참조하십시오.
  • 네임스페이스 - Fuse Console은 특정 OpenShift 프로젝트(네임스페이스)에 액세스할 수 있습니다. 이 템플릿을 배포하려면 OpenShift 프로젝트에 대한 관리자 역할이 있어야 합니다.
  • 역할 기반 액세스 제어가 있는 네임스페이스 - 구성 가능한 RBAC가 있는 네임스페이스 템플릿입니다. 자세한 내용은 OpenShift 4.x의 Fuse Console에 대한 역할 기반 액세스 제어를 참조하십시오.

Fuse Console 템플릿의 매개변수 목록을 보려면 다음 OpenShift 명령을 실행합니다.

oc process --parameters -f https://raw.githubusercontent.com/jboss-fuse/application-templates/application-templates-2.1.0.fuse-7_13_0-00014-redhat-00001/fuse-console-namespace-os4.json

프로세스

  1. 다음 명령을 사용하여 모든 템플릿 목록을 검색하여 Fuse Console 이미지 스트림이 설치되었는지 확인합니다.

    oc get template -n openshift
  2. 선택적으로 이미 설치된 이미지 스트림을 새 릴리스 태그로 업데이트하려면 다음 명령을 사용하여 Fuse Console 이미지를 openshift 네임스페이스로 가져옵니다.

    oc import-image fuse7/fuse-console-rhel8:1.10 --from=registry.redhat.io/fuse7/fuse-console-rhel8:1.10 --confirm -n openshift
  3. 다음 명령을 실행하여 Fuse Console APP_NAME 값을 가져옵니다.

    oc process --parameters -f TEMPLATE-FILENAME

    여기서 TEMPLATE-FILENAME 은 다음 템플릿 중 하나입니다.

  4. 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
  5. 다음 명령을 실행하여 Fuse Console 템플릿의 로컬 복사본을 기반으로 새 애플리케이션을 생성합니다. 여기서 myproject 는 OpenShift 프로젝트의 이름, mytemp 는 Fuse Console 템플릿이 포함된 로컬 디렉터리의 경로입니다. myhost 는 Fuse Console에 액세스할 수 있는 호스트 이름입니다.

    • 클러스터 템플릿의 경우:

      oc new-app -n myproject -f https://raw.githubusercontent.com/jboss-fuse/application-templates/application-templates-2.1.0.fuse-7_13_0-00014-redhat-00001/fuse-console-cluster-os4.json  -p ROUTE_HOSTNAME=myhost
    • RBAC 템플릿이 있는 클러스터의 경우:

      oc new-app -n myproject -f https://raw.githubusercontent.com/jboss-fuse/application-templates/application-templates-2.1.0.fuse-7_13_0-00014-redhat-00001/fuse-console-cluster-rbac.yml -p ROUTE_HOSTNAME=myhost
    • 네임스페이스 템플릿의 경우:

      oc new-app -n myproject -f https://raw.githubusercontent.com/jboss-fuse/application-templates/application-templates-2.1.0.fuse-7_13_0-00014-redhat-00001/fuse-console-namespace-os4.json
    • RBAC 템플릿이 있는 네임스페이스의 경우:

      oc new-app -n myproject -f https://raw.githubusercontent.com/jboss-fuse/application-templates/application-templates-2.1.0.fuse-7_13_0-00014-redhat-00001/fuse-console-namespace-rbac.yml
  6. 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}`
  7. 다음 명령을 실행하여 Fuse Console 배포의 상태 및 URL을 가져옵니다.

    oc status
  8. 브라우저에서 Fuse 콘솔에 액세스하려면 7단계로 반환되는 URL(예: https://fuse-console.192.168.64.12.nip.io)을 사용합니다.

2.2.1. OpenShift 4.x에서 Fuse Console을 보호하기 위한 인증서 생성

OpenShift 4.x에서 Fuse Console 프록시와 Jolokia 에이전트 보안 간의 연결을 유지하려면 Fuse Console을 배포하기 전에 클라이언트 인증서를 생성해야 합니다. 클라이언트 인증서에 서명하려면 서비스 서명 인증 기관 개인 키를 사용해야 합니다.

명령줄을 사용하여 Fuse 콘솔을 설치하고 배포하는 경우에만 다음 절차를 따라야 합니다. Fuse Console Operator를 사용하는 경우 이 작업을 처리합니다.

중요

각 OpenShift 클러스터에 대해 별도의 클라이언트 인증서를 생성하고 서명해야 합니다. 두 개 이상의 클러스터에 동일한 인증서를 사용하지 마십시오.

사전 요구 사항

  • OpenShift 클러스터에 대한 클러스터 관리자 액세스 권한이 있어야 합니다.
  • 두 개 이상의 OpenShift 클러스터에 대한 인증서를 생성하고 이전에 현재 디렉터리에 다른 클러스터에 대한 인증서를 생성한 경우 다음 중 하나를 수행하여 현재 클러스터에 대한 다른 인증서를 생성하십시오.

    • 현재 디렉터리에서 기존 인증서 파일(예: ca.crt,ca.key, ca.srl)을 삭제합니다.
    • 다른 작업 디렉터리로 변경합니다. 예를 들어 현재 작업 디렉터리 이름이 cluster1 인 경우 새 cluster2 디렉터리를 생성하고 작업 디렉터리를 해당 디렉터리로 변경합니다.

      mkdir ../cluster2

      cd ../cluster2

프로세스

  1. 클러스터 관리자 액세스 권한이 있는 사용자로 OpenShift에 로그인합니다.

    oc login -u <user_with_cluster_admin_role>
  2. 다음 명령을 실행하여 서비스 서명 인증 기관 키를 검색합니다.

    • 인증서를 검색하려면 다음을 수행합니다.

      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
  3. easyrsa,openssl 또는 cfssl 을 사용하여 Kubernetes 인증서 관리에 설명된 대로 클라이언트 인증서를 생성합니다.

    다음은 openssl을 사용하는 예제 명령입니다.

    1. 개인 키를 생성합니다.

      openssl genrsa -out server.key 2048
    2. 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

      여기에서 CN 매개변수의 값은 애플리케이션 이름과 애플리케이션에서 사용하는 네임스페이스를 나타냅니다.

    3. CSR을 생성합니다.

      openssl req -new -key server.key -out server.csr -config csr.conf
    4. 서명된 인증서를 발급합니다.

      openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out server.crt -days 10000 -extensions v3_ext -extfile csr.conf
Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

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

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

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

Red Hat 소개

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

© 2024 Red Hat, Inc.