방화벽 뒤에 IBM Blockchain Platform 2.5.2 배치

다른 버전의 IBM Blockchain Platform을 실행하고 있습니까? 2.1.3, 2.5, 2.5.1, 2.5.2 버전으로 전환하십시오.

이러한 지시사항을 사용하여 인터넷 연결 없이 방화벽 뒤에 IBM Blockchain Platform 2.5.2를 배치할 수 있습니다. 외부 인터넷에 대한 액세스 권한이 있는 클러스터에 플랫폼을 배치하는 경우 IBM Blockchain Platform 2.5.2배치에 대한 기본 지시사항을 사용하십시오.

다음 지시사항을 사용하여 v1.20 - v1.23에서 실행 중인 모든 x86_64 Kubernetes 클러스터에 IBM® Blockchain Platform 2.5.2를 배치할 수 있습니다. 오픈 소스 Kubernetes 또는 Rancher와 같은 배포를 사용하는 경우에는 다음 지시사항을 사용하십시오. IBM Blockchain Platform 은 Kubernetes 연산자 를 사용하여 클러스터에 IBM Blockchain Platform 콘솔을 설치하고 전개 및 블록체인 노드를 관리합니다. IBM Blockchain Platform 콘솔이 클러스터에서 실행 중인 경우 콘솔을 사용하여 블록체인 노드를 작성하고 멀티클라우드 블록체인 네트워크를 운영할 수 있습니다.

알아두어야 할 사항

Kubernetes 클러스터는 IBM Blockchain Platform 의 최신 버전을 자동으로 다운로드하여 갱신하지 않습니다. 최신 업데이트를 가져오려면 새 클러스터 및 새 서비스 인스턴스를 작성해야 합니다.

필수 리소스

Kubernetes 클러스터에 IBM Blockchain 콘솔 및 사용자가 작성하는 블록체인 노드에 대한 충분한 자원이 있는지 확인하십시오. 필요한 리소스 양은 인프라, 네트워크 디자인 및 성능 요구사항에 따라 달라질 수 있습니다. 적절한 크기의 클러스터를 배치하는 데 도움을 주기 위해, 다음 표에 각 컴포넌트 유형에 대한 기본 CPU, 메모리 및 스토리지 요구사항이 제공되어 있습니다. 실제 리소스 할당은 노드를 배치할 때 블록체인 콘솔에 표시되며, 비즈니스 요구사항에 따라 배치 시 또는 배치 후에 조정할 수 있습니다.

표 1. 기본 리소스 할당
컴포넌트(모든 컨테이너) CPU * * 메모리(GB) 스토리지(GB)
피어(Hyperledger Fabric v1.4) 1.1 2.8 200(피어용 100GB 및 상태 데이터베이스용 100GB 포함)
피어(Hyperledger Fabric v2.x) 0.7 2.0 200(피어용 100GB 및 상태 데이터베이스용 100GB 포함)
CA 0.1 0.2 20
순서 지정 노드 0.35 0.7 100
운영자 0.1 0.2 0
콘솔 1.2 2.4 10
웹훅 0.1 0.2 0

** 이 값은 약간 다를 수 있습니다. 실제 VPC 할당은 노드가 배치될 때 블록체인 콘솔에 표시됩니다.

스마트 계약이 Fabric v2.x 이미지를 실행하는 피어에 설치되면 피어에 필요한 리소스의 양을 더 적게 차지하는 피어의 별도 컨테이너 대신 자체 팟(Pod)에서 스마트 계약이 시작됩니다.

브라우저

IBM Blockchain Platform 콘솔이 다음 브라우저에서 성공적으로 테스트되었습니다.

스토리지

IBM Blockchain Platform 은 IBM Blockchain 콘솔에 필요한 스토리지 외에 사용자가 배치하는 각 CA, 피어 및 주문 노드에 지속적인 스토리지를 필요로 합니다. IBM Blockchain Platform 콘솔은 동적 프로비저닝 을 사용하여 사전 정의된 스토리지 클래스를 사용하여 배치하는 각 블록체인 노드에 스토리지를 할당합니다.

IBM Blockchain Platform 콘솔을 배치하기 전에, 사용자가 작성하는 노드 및 IBM Blockchain 콘솔에 충분한 지원 스토리지가 있는 스토리지 클래스를 작성해야 합니다. 이 스토리지 클래스를 Kubernetes 클러스터의 기본 스토리지 클래스로 설정하거나 IBM Blockchain Platform 콘솔에서 사용하는 새 클래스를 작성할 수 있습니다. 다중 구역 클러스터를 사용하는 경우에는 각 구역에 대한 기본 스토리지 클래스를 구성해야 합니다. 스토리지 클래스를 작성한 후에는 kubectl patch storageclass 명령을 실행하여 다중 구역 지역의 스토리지 클래스를 기본 스토리지 클래스로 설정하십시오.

지속적 스토리지 옵션을 선택하지 않으려는 경우에는 Kubernetes 클러스터의 기본 스토리지 클래스가 사용됩니다.

인타이틀먼트 키 가져오기

PPA에서 IBM Blockchain Platform 을 구입하면 소프트웨어에 대한 자격 부여 키가 MyDIT 계정과 연관됩니다. 플랫폼을 배치하려면 이 키에 액세스하여 저장해야 합니다.

  1. 자격이 있는 소프트웨어와 연관된 IBMid 사용하여 MyBM 컨테이너 소프트웨어 라이브러리 에 로그인하십시오.

  2. 인타이틀먼트 키 섹션에서 키 복사를 선택하여 인타이틀먼트 키를 클립보드에 복사한 후 다음 단계에서 나중에 사용하도록 이 값을 저장하십시오.

시작하기 전에

  1. IBM Blockchain Platform 은 지원되는 플랫폼에만 설치할 수 있습니다.

  2. IBM Blockchain Platform v2.1.x 및 2.5.x 인스턴스를 동일한 클러스터에 배치할 수 없습니다. 제품의 두 인스턴스를 실행해야 하는 경우에는 별도의 클러스터에서 실행되어야 합니다.

  3. kubectl CLI 를 사용하여 플랫폼을 배치하여 클러스터에 설치하고 연결해야 합니다.

  4. If you are not running the platform on Red Hat OpenShift Container Platform or Red Hat Open Kubernetes Distribution then you need to set up the NGINX Ingress controller and it needs to be running in SSL 패스스루 모드. 자세한 정보는 Kubernetes 분포 사용 시 고려사항을 참조하십시오.

  5. CA, 피어 또는 순서 지정 노드에 대한 개인 키를 생성하고 저장하는 데 사용할 HSM(Hardware Security Module)이 있는 경우에는 HSM 클라이언트 이미지를 작성하고 이를 컨테이너 레지스트리에 푸시해야 합니다. 고급 배치 주제의 지시사항에 따라 이미지를 빌드하십시오.

IBM Blockchain Platform 이미지를 가져오십시오.

IBM 권한 부여 레지스트리에서 IBM Blockchain Platform 이미지의 전체 세트를 다운로드할 수 있습니다. 공용 인터넷에 액세스하지 않고 플랫폼을 배치하려면 IBM 이미지를 가져와 방화벽 뒤에서 액세스할 수 있는 컨테이너 레지스트리에 이미지를 밀어넣어야 합니다.

플랫폼에서는 skopeo 유틸리티를 사용하여 이미지를 다운로드하고 이를 로컬 컨테이너 레지스트리에 복사할 것을 권장합니다. skopeo 는 다양한 유형의 컨테이너 스토리지 간에 컨테이너 이미지를 이동하기 위한 도구입니다. 플랫폼 이미지를 다운로드하여 방화벽 뒤의 컨테이너 레지스트리에 복사하려면 먼저 skopeo를 설치해야 합니다.

이 지시사항을 따르기 전에 IBM Blockchain Platform 인타이틀먼트 키 및 컨테이너 레지스트리 사용자 ID와 비밀번호가 사용 가능해야 합니다. IBM Blockchain Platform을 구입한 후 내 IBM 에 액세스하여 오퍼링에 대한 자격 부여 키를 얻을 수 있습니다. 그런 다음 이 키를 사용하여 IBM Blockchain Platform 이미지에 액세스할 수 있습니다.

이미지를 다운로드하고 이를 레지스트리에 푸시하려면 다음 명령 세트를 실행하십시오.

바꾸기

다음 명령은 Docker 컨테이너 레지스트리에 대해서만 작동합니다. 이미지의 대상 위치에 필요한 권한의 레벨에 따라 각 명령의 접두부를 sudo로 지정해야 할 수 있습니다.

skopeo copy docker://cp.icr.io/cp/ibp-operator:2.5.2-20220405 docker://<LOCAL_REGISTRY>/ibp-operator:2.5.2-20220405 -q --src-creds cp:<ENTITLEMENT_KEY> --dest-creds <LOCAL_REGISTRY_USER>:<LOCAL_REGISTRY_PASSWORD> --all
skopeo copy docker://cp.icr.io/cp/ibp-init:2.5.2-20220405 docker://<LOCAL_REGISTRY>/ibp-init:2.5.2-20220405 -q --src-creds cp:<ENTITLEMENT_KEY> --dest-creds <LOCAL_REGISTRY_USER>:<LOCAL_REGISTRY_PASSWORD> --all
skopeo copy docker://cp.icr.io/cp/ibp-console:2.5.2-20220405 docker://<LOCAL_REGISTRY>/ibp-console:2.5.2-20220405 -q --src-creds cp:<ENTITLEMENT_KEY> --dest-creds <LOCAL_REGISTRY_USER>:<LOCAL_REGISTRY_PASSWORD> --all
skopeo copy docker://cp.icr.io/cp/ibp-grpcweb:2.5.2-20220405 docker://<LOCAL_REGISTRY>/ibp-grpcweb:2.5.2-20220405 -q --src-creds cp:<ENTITLEMENT_KEY> --dest-creds <LOCAL_REGISTRY_USER>:<LOCAL_REGISTRY_PASSWORD> --all
skopeo copy docker://cp.icr.io/cp/ibp-deployer:2.5.2-20220405 docker://<LOCAL_REGISTRY>/ibp-deployer:2.5.2-20220405 -q --src-creds cp:<ENTITLEMENT_KEY> --dest-creds <LOCAL_REGISTRY_USER>:<LOCAL_REGISTRY_PASSWORD> --all
skopeo copy docker://cp.icr.io/cp/ibp-fluentd:2.5.2-20220405 docker://<LOCAL_REGISTRY>/ibp-fluentd:2.5.2-20220405 -q --src-creds cp:<ENTITLEMENT_KEY> --dest-creds <LOCAL_REGISTRY_USER>:<LOCAL_REGISTRY_PASSWORD> --all
skopeo copy docker://cp.icr.io/cp/ibp-couchdb:2.3.1-20220405 docker://<LOCAL_REGISTRY>/ibp-couchdb:2.3.1-20220405 -q --src-creds cp:<ENTITLEMENT_KEY> --dest-creds <LOCAL_REGISTRY_USER>:<LOCAL_REGISTRY_PASSWORD> --all
skopeo copy docker://cp.icr.io/cp/ibp-couchdb:3.1.1-20220405 docker://<LOCAL_REGISTRY>/ibp-couchdb:3.1.1-20220405 -q --src-creds cp:<ENTITLEMENT_KEY> --dest-creds <LOCAL_REGISTRY_USER>:<LOCAL_REGISTRY_PASSWORD> --all
skopeo copy docker://cp.icr.io/cp/ibp-peer:1.4.12-20220405 docker://<LOCAL_REGISTRY>/ibp-peer:1.4.12-20220405 -q --src-creds cp:<ENTITLEMENT_KEY> --dest-creds <LOCAL_REGISTRY_USER>:<LOCAL_REGISTRY_PASSWORD> --all
skopeo copy docker://cp.icr.io/cp/ibp-orderer:1.4.12-20220405 docker://<LOCAL_REGISTRY>/ibp-orderer:1.4.12-20220405 -q --src-creds cp:<ENTITLEMENT_KEY> --dest-creds <LOCAL_REGISTRY_USER>:<LOCAL_REGISTRY_PASSWORD> --all
skopeo copy docker://cp.icr.io/cp/ibp-ca:1.5.2-20220405 docker://<LOCAL_REGISTRY>/ibp-ca:1.5.2-20220405 -q --src-creds cp:<ENTITLEMENT_KEY> --dest-creds <LOCAL_REGISTRY_USER>:<LOCAL_REGISTRY_PASSWORD> --all
skopeo copy docker://cp.icr.io/cp/ibp-dind:1.4.12-20220405 docker://<LOCAL_REGISTRY>/ibp-dind:1.4.12-20220405 -q --src-creds cp:<ENTITLEMENT_KEY> --dest-creds <LOCAL_REGISTRY_USER>:<LOCAL_REGISTRY_PASSWORD> --all
skopeo copy docker://cp.icr.io/cp/ibp-utilities:1.4.12-20220405 docker://<LOCAL_REGISTRY>/ibp-utilities:1.4.12-20220405 -q --src-creds cp:<ENTITLEMENT_KEY> --dest-creds <LOCAL_REGISTRY_USER>:<LOCAL_REGISTRY_PASSWORD> --all
skopeo copy docker://cp.icr.io/cp/ibp-peer:2.2.5-20220405 docker://<LOCAL_REGISTRY>/ibp-peer:2.2.5-20220405 -q --src-creds cp:<ENTITLEMENT_KEY> --dest-creds <LOCAL_REGISTRY_USER>:<LOCAL_REGISTRY_PASSWORD> --all
skopeo copy docker://cp.icr.io/cp/ibp-orderer:2.2.5-20220405 docker://<LOCAL_REGISTRY>/ibp-orderer:2.2.5-20220405 -q --src-creds cp:<ENTITLEMENT_KEY> --dest-creds <LOCAL_REGISTRY_USER>:<LOCAL_REGISTRY_PASSWORD> --all
skopeo copy docker://cp.icr.io/cp/ibp-chaincode-launcher:2.2.5-20220405 docker://<LOCAL_REGISTRY>/ibp-chaincode-launcher:2.2.5-20220405 -q --src-creds cp:<ENTITLEMENT_KEY> --dest-creds <LOCAL_REGISTRY_USER>:<LOCAL_REGISTRY_PASSWORD> --all
skopeo copy docker://cp.icr.io/cp/ibp-utilities:2.2.5-20220405 docker://<LOCAL_REGISTRY>/ibp-utilities:2.2.5-20220405 -q --src-creds cp:<ENTITLEMENT_KEY> --dest-creds <LOCAL_REGISTRY_USER>:<LOCAL_REGISTRY_PASSWORD> --all
skopeo copy docker://cp.icr.io/cp/ibp-ccenv:2.2.5-20220405 docker://<LOCAL_REGISTRY>/ibp-ccenv:2.2.5-20220405 -q --src-creds cp:<ENTITLEMENT_KEY> --dest-creds <LOCAL_REGISTRY_USER>:<LOCAL_REGISTRY_PASSWORD> --all
skopeo copy docker://cp.icr.io/cp/ibp-goenv:2.2.5-20220405 docker://<LOCAL_REGISTRY>/ibp-goenv:2.2.5-20220405 -q --src-creds cp:<ENTITLEMENT_KEY> --dest-creds <LOCAL_REGISTRY_USER>:<LOCAL_REGISTRY_PASSWORD> --all
skopeo copy docker://cp.icr.io/cp/ibp-nodeenv:2.2.5-20220405 docker://<LOCAL_REGISTRY>/ibp-nodeenv:2.2.5-20220405 -q --src-creds cp:<ENTITLEMENT_KEY> --dest-creds <LOCAL_REGISTRY_USER>:<LOCAL_REGISTRY_PASSWORD> --all
skopeo copy docker://cp.icr.io/cp/ibp-javaenv:2.2.5-20220405 docker://<LOCAL_REGISTRY>/ibp-javaenv:2.2.5-20220405 -q --src-creds cp:<ENTITLEMENT_KEY> --dest-creds <LOCAL_REGISTRY_USER>:<LOCAL_REGISTRY_PASSWORD> --all
skopeo copy docker://cp.icr.io/cp/ibp-crdwebhook:2.5.2-20220405 docker://<LOCAL_REGISTRY>/ibp-crdwebhook:2.5.2-20220405 -q --src-creds cp:<ENTITLEMENT_KEY> --dest-creds <LOCAL_REGISTRY_USER>:<LOCAL_REGISTRY_PASSWORD> --all
skopeo copy docker://cp.icr.io/cp/ibp-ccenv:1.4.12-20220405 docker://<LOCAL_REGISTRY>/ibp-ccenv:1.4.12-20220405 -q --src-creds cp:<ENTITLEMENT_KEY> --dest-creds <LOCAL_REGISTRY_USER>:<LOCAL_REGISTRY_PASSWORD> --all
skopeo copy docker://cp.icr.io/cp/ibp-goenv:1.4.12-20220405 docker://<LOCAL_REGISTRY>/ibp-goenv:1.4.12-20220405 -q --src-creds cp:<ENTITLEMENT_KEY> --dest-creds <LOCAL_REGISTRY_USER>:<LOCAL_REGISTRY_PASSWORD> --all
skopeo copy docker://cp.icr.io/cp/ibp-nodeenv:1.4.12-20220405 docker://<LOCAL_REGISTRY>/ibp-nodeenv:1.4.12-20220405 -q --src-creds cp:<ENTITLEMENT_KEY> --dest-creds <LOCAL_REGISTRY_USER>:<LOCAL_REGISTRY_PASSWORD> --all
skopeo copy docker://cp.icr.io/cp/ibp-javaenv:1.4.12-20220405 docker://<LOCAL_REGISTRY>/ibp-javaenv:1.4.12-20220405 -q --src-creds cp:<ENTITLEMENT_KEY> --dest-creds <LOCAL_REGISTRY_USER>:<LOCAL_REGISTRY_PASSWORD> --all
skopeo copy docker://cp.icr.io/cp/ibp-enroller:2.5.2-20220405 docker://<LOCAL_REGISTRY>/ibp-enroller:2.5.2-20220405 -q --src-creds cp:<ENTITLEMENT_KEY> --dest-creds <LOCAL_REGISTRY_USER>:<LOCAL_REGISTRY_PASSWORD> --all

이러한 단계를 완료하면 다음 지시사항을 사용하여 레지스트리의 이미지와 함께 IBM Blockchain Platform 을 배치할 수 있습니다.

Kubernetes 클러스터에 로그인

다음 단계를 완료하려면 먼저 kubectl CLI를 사용하여 클러스터에 로그인해야 합니다. 클러스터에 로그인하기 위한 지시사항을 수행하십시오. 명령이 성공하면 다음 명령을 실행하여 터미널에서 클러스터에 있는 네임스페이스의 목록을 터미널에서 확인할 수 있습니다.

kubectl get pods

명령이 성공하면 기본 네임스페이스에서 실행 중인 팟(Pod)이 표시됩니다.

docker-registry-7d8875c7c5-5fv5j    1/1       Running   0          7d
docker-registry-7d8875c7c5-x8dfq    1/1       Running   0          7d
registry-console-6c74fc45f9-nl5nw   1/1       Running   0          7d
router-6cc88df47c-hqjmk             1/1       Running   0          7d
router-6cc88df47c-mwzbq             1/1       Running   0          7d

웹훅에 대한 ibpinfra 네임스페이스 작성

플랫폼이 내부 apiversion을 이전 버전의 v1alpha1에서 v1beta1로 업데이트했으므로 CA, 피어, 오퍼레이터 및 콘솔을 새 API 버전으로 업데이트하려면 Kubernetes 변환 웹훅이 필요합니다. 이 웹훅은 나중에 계속 사용되므로 계속 배치하려면 플랫폼의 새 배치가 필요합니다. 웹훅은 다음 지시사항에 따라 ibpinfra라는 해당 고유 네임스페이스에 배치됩니다.

클러스터에 로그인한 후 kubectl CLI를 사용하여 Kubernetes 변환 웹훅에 대한 새 ibpinfra 네임스페이스를 작성할 수 있습니다. 새 네임스페이스는 클러스터 관리자가 작성해야 합니다.

다음 명령을 실행하여 네임스페이스를 작성하십시오.

kubectl create namespace ibpinfra

로컬 레지스트리에 대한 권한 설정

IBM Blockchain Platform 이미지를 사용자의 Docker 레지스트리에 밀어넣은 후 Kubernetes Secret을 작성하여 클러스터의 해당 레지스트리에 암호를 저장해야 합니다. Kubernetes 시크릿을 사용하면 클러스터에 키를 안전하게 저장하고 오퍼레이터 및 콘솔 배치에 전달할 수 있습니다.

다음 명령을 실행하여 시크릿을 작성하고 ibpinfra 네임스페이스 또는 프로젝트에 추가하십시오.

kubectl create secret docker-registry docker-key-secret --docker-server=<LOCAL_REGISTRY> --docker-username=<USER> --docker-password=<LOCAL_REGISTRY_PASSWORD> --docker-email=<EMAIL> -n <NAMESPACE>

작성하는 시크릿의 이름은 docker-key-secret입니다. 이는 나중에 배치할 웹훅에 필요합니다. 작성한 시크릿의 이름을 변경하는 경우에는 나중 단계에서 해당 이름을 변경해야 합니다.

OpenShift 클러스터에 웹훅 및 사용자 정의 리소스 정의 배치

기존 2.1.x 네트워크를 2.5.x로 업그레이드하거나 플랫폼의 새 인스턴스를 Kubernetes 클러스터에 배치하려면, 이 절의 단계를 완료하여 변환 웹훅을 작성해야 합니다. 웹훅은 다음 지시사항에 따라 ibpinfra라는 해당 고유 네임스페이스 또는 프로젝트에 배치됩니다.

처음 세 단계는 웹훅 배치를 위한 단계입니다. 마지막 단계는 IBM Blockchain Platform 에 필요한 CA, 피어, orderer및 콘솔 구성요소에 대한 사용자 정의 자원 정의에 대한 것입니다. 웹훅 및 사용자 정의 리소스 정의를 클러스터당 한 번만 배치하면 됩니다. 이 웹훅 및 사용자 정의 리소스 정의를 클러스터에 이미 배치한 경우 아래의 네 단계는 건너뛸 수 있습니다.

1. 웹훅에 대한 RBAC(Role-Based Access Control) 구성

먼저, 다음 텍스트를 로컬 시스템의 파일에 복사한 후 해당 파일을 rbac.yaml로 저장하십시오. 이 단계를 통해 웹훅은 고유 프로젝트에서 TLS 시크릿을 읽고 작성할 수 있습니다.

apiVersion: v1
kind: ServiceAccount
metadata:
  name: webhook
  namespace: ibpinfra
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: webhook
rules:
- apiGroups:
  - "*"
  resources:
  - secrets
  verbs:
  - "*"
---
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: ibpinfra
subjects:
- kind: ServiceAccount
  name: webhook
  namespace: ibpinfra
roleRef:
  kind: Role
  name: webhook
  apiGroup: rbac.authorization.k8s.io

다음 명령을 실행하여 클러스터 정의에 파일을 추가하십시오.

kubectl apply -f rbac.yaml -n ibpinfra

명령이 성공적으로 완료되면 다음과 유사한 내용이 표시됩니다.

serviceaccount/webhook created
role.rbac.authorization.k8s.io/webhook created
rolebinding.rbac.authorization.k8s.io/ibpinfra created

2. (OpenShift 클러스터 전용) 보안 컨텍스트 제한조건 적용

OpenShift를 사용하지 않는 경우 이 단계를 건너뛰십시오. IBM Blockchain Platform 에는 ibpinfra 프로젝트에 추가할 특정 보안 및 액세스 정책이 필요합니다. 아래 보안 컨텍스트 제한조건 오브젝트를 복사하고 ibpinfra-scc.yaml로 자신의 로컬 시스템에 저장하십시오.

<PROJECT_NAME>ibpinfra로 바꾸십시오.

allowHostDirVolumePlugin: false
allowHostIPC: false
allowHostNetwork: false
allowHostPID: false
allowHostPorts: false
allowPrivilegeEscalation: true
allowPrivilegedContainer: true
allowedCapabilities:
- NET_BIND_SERVICE
- CHOWN
- DAC_OVERRIDE
- SETGID
- SETUID
- FOWNER
apiVersion: security.openshift.io/v1
defaultAddCapabilities: []
fsGroup:
  type: RunAsAny
groups:
- system:serviceaccounts:<PROJECT_NAME>
kind: SecurityContextConstraints
metadata:
  name: <PROJECT_NAME>
readOnlyRootFilesystem: false
requiredDropCapabilities: []
runAsUser:
  type: RunAsAny
seLinuxContext:
  type: RunAsAny
supplementalGroups:
  type: RunAsAny
users:
- system:serviceaccounts:<PROJECT_NAME>
volumes:
- "*"

파일을 저장한 후에는 다음 명령을 실행하여 파일을 클러스터에 추가하고 정책을 프로젝트에 추가하십시오.

oc apply -f ibpinfra-scc.yaml -n ibpinfra
oc adm policy add-scc-to-user ibpinfra system:serviceaccounts:ibpinfra

명령이 성공하면 다음 예와 비슷한 응답이 표시됩니다.

securitycontextconstraints.security.openshift.io/ibpinfra created
clusterrole.rbac.authorization.k8s.io/system:openshift:scc:ibpinfra added: "system:serviceaccounts:ibpinfra"

3. 웹훅 배치

웹훅을 배치하려면 2개의 .yaml 파일을 작성하고 Kubernetes 클러스터에 해당 파일을 적용해야 합니다.

deployment.yaml

다음 텍스트를 로컬 시스템의 파일에 복사하고 해당 파일을 deployment.yaml로 저장하십시오. LinuxONE 기반의 OpenShift Container Platform에 배치하는 경우 amd64s390x로 대체해야 합니다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: "ibp-webhook"
  labels:
    helm.sh/chart: "ibm-ibp"
    app.kubernetes.io/name: "ibp"
    app.kubernetes.io/instance: "ibp-webhook"
spec:
  replicas: 1
  selector:
    matchLabels:
      app.kubernetes.io/instance: "ibp-webhook"
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        helm.sh/chart: "ibm-ibp"
        app.kubernetes.io/name: "ibp"
        app.kubernetes.io/instance: "ibp-webhook"
      annotations:
        productName: "IBM Blockchain Platform"
        productID: "54283fa24f1a4e8589964e6e92626ec4"
        productVersion: "2.5.2"
    spec:
      serviceAccountName: webhook
      imagePullSecrets:
        - name: docker-key-secret
        - name: ibm-entitlement-key
      hostIPC: false
      hostNetwork: false
      hostPID: false
      securityContext:
        runAsNonRoot: true
        runAsUser: 1000
        fsGroup: 2000
      containers:
        - name: "ibp-webhook"
          image: "cp.icr.io/cp/ibp-crdwebhook:2.5.2-20220111-amd64"
          imagePullPolicy: Always
          securityContext:
            privileged: false
            allowPrivilegeEscalation: false
            readOnlyRootFilesystem: true
            runAsNonRoot: true
            runAsUser: 1000
            capabilities:
              drop:
                - ALL
              add:
                - NET_BIND_SERVICE
          env:
            - name: "LICENSE"
              value: "accept"
            - name: NAMESPACE
              valueFrom:
                fieldRef:
                  fieldPath: metadata.namespace
          ports:
            - name: server
              containerPort: 3000
          livenessProbe:
            httpGet:
              path: /healthz
              port: server
              scheme: HTTPS
            initialDelaySeconds: 30
            timeoutSeconds: 5
            failureThreshold: 6
          readinessProbe:
            httpGet:
              path: /healthz
              port: server
              scheme: HTTPS
            initialDelaySeconds: 26
            timeoutSeconds: 5
            periodSeconds: 5
          resources:
            requests:
              cpu: 0.1
              memory: "100Mi"

다음 명령을 실행하여 클러스터 정의에 파일을 추가하십시오.

kubectl apply -n ibpinfra -f deployment.yaml

명령이 성공적으로 완료되면 다음과 유사한 내용이 표시됩니다.

deployment.apps/ibp-webhook created

service.yaml

두 번째, 다음 텍스트를 로컬 시스템의 파일에 복사하고 해당 파일을 service.yaml로 저장하십시오.

apiVersion: v1
kind: Service
metadata:
  name: "ibp-webhook"
  labels:
    type: "webhook"
    app.kubernetes.io/name: "ibp"
    app.kubernetes.io/instance: "ibp-webhook"
    helm.sh/chart: "ibm-ibp"
spec:
  type: ClusterIP
  ports:
    - name: server
      port: 443
      targetPort: server
      protocol: TCP
  selector:
    app.kubernetes.io/instance: "ibp-webhook"

다음 명령을 실행하여 클러스터 정의에 파일을 추가하십시오.

kubectl apply -n ibpinfra -f service.yaml

명령이 성공적으로 완료되면 다음과 유사한 내용이 표시됩니다.

service/ibp-webhook created

4. 인증서 추출 및 사용자 정의 리소스 정의 작성

  1. 다음 명령을 실행하여 ibpinfra 네임스페이스에서 웹훅 TLS 인증서를 추출하십시오.

    TLS_CERT=$(kubectl get secret/webhook-tls-cert -n ibpinfra -o jsonpath={'.data.cert\.pem'})
    
  2. IBM Blockchain Platform 2.5.2를 배치하는 경우 CA, 피어, orderer및 콘솔에 다음과 같은 네 개의 CRD를 적용해야 합니다. 2.5.2로 업그레이드하는 경우 오퍼레이터를 업데이트하기 전에 새 v1beta1 섹션과 TLS_CERT 환경 변수에 저장한 TLS 인증서를 포함하도록 CRD를 업데이트해야 합니다. 두 경우 모두 각 CRD를 적용하거나 업데이트하려면 다음 네 개의 명령을 실행해야 합니다.

CA CRD를 업데이트하려면 다음 명령을 실행하십시오.

cat <<EOF | kubectl apply  -f -
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: ibpcas.ibp.com
  labels:
    app.kubernetes.io/instance: ibpca
    app.kubernetes.io/managed-by: ibp-operator
    app.kubernetes.io/name: ibp
    helm.sh/chart: ibm-ibp
    release: operator
spec:
  conversion:
    strategy: Webhook
    webhook:
      clientConfig:
        caBundle: "${TLS_CERT}"
        service:
          name: ibp-webhook
          namespace: ibpinfra
          path: /crdconvert
      conversionReviewVersions:
      - v1beta1
      - v1alpha2
      - v1alpha1
  group: ibp.com
  names:
    kind: IBPCA
    listKind: IBPCAList
    plural: ibpcas
    singular: ibpca
  scope: Namespaced
  versions:
  - name: v1beta1
    schema:
      openAPIV3Schema:
        x-kubernetes-preserve-unknown-fields: true
    served: true
    storage: true
    subresources:
      status: {}
  - name: v1alpha2
    schema:
      openAPIV3Schema:
        x-kubernetes-preserve-unknown-fields: true
    served: true
    storage: false
    subresources:
      status: {}
  - name: v210
    schema:
      openAPIV3Schema:
        x-kubernetes-preserve-unknown-fields: true
    served: false
    storage: false
    subresources:
      status: {}
  - name: v212
    schema:
      openAPIV3Schema:
        x-kubernetes-preserve-unknown-fields: true
    served: false
    storage: false
    subresources:
      status: {}
  - name: v1alpha1
    schema:
      openAPIV3Schema:
        x-kubernetes-preserve-unknown-fields: true
    served: true
    storage: false
    subresources:
      status: {}
status:
  acceptedNames:
    kind: IBPCA
    listKind: IBPCAList
    plural: ibpcas
    singular: ibpca
  conditions: []
  storedVersions:
  - v1beta1
EOF

성공하면 CRD를 작성하거나 업데이트하는지에 따라 다음이 표시됩니다.

customresourcedefinition.apiextensions.k8s.io/ibpcas.ibp.com created

또는

customresourcedefinition.apiextensions.k8s.io/ibpcas.ibp.com configured

피어 CRD를 업데이트하려면 다음 명령을 실행하십시오.

cat <<EOF | kubectl apply  -f -
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: ibppeers.ibp.com
  labels:
    release: "operator"
    helm.sh/chart: "ibm-ibp"
    app.kubernetes.io/name: "ibp"
    app.kubernetes.io/instance: "ibppeer"
    app.kubernetes.io/managed-by: "ibp-operator"
spec:
  conversion:
    strategy: Webhook
    webhook:
      clientConfig:
        caBundle: "${TLS_CERT}"
        service:
          name: ibp-webhook
          namespace: ibpinfra
          path: /crdconvert
      conversionReviewVersions:
      - v1beta1
      - v1alpha2
      - v1alpha1
  group: ibp.com
  names:
    kind: IBPPeer
    listKind: IBPPeerList
    plural: ibppeers
    singular: ibppeer
  scope: Namespaced
  versions:
  - name: v1beta1
    schema:
      openAPIV3Schema:
        x-kubernetes-preserve-unknown-fields: true
    served: true
    storage: true
    subresources:
      status: {}
  - name: v1alpha2
    schema:
      openAPIV3Schema:
        x-kubernetes-preserve-unknown-fields: true
    served: true
    storage: false
    subresources:
      status: {}
  - name: v1alpha1
    schema:
      openAPIV3Schema:
        x-kubernetes-preserve-unknown-fields: true
    served: true
    storage: false
    subresources:
      status: {}
status:
  acceptedNames:
    kind: IBPPeer
    listKind: IBPPeerList
    plural: ibppeers
    singular: ibppeer
  conditions: []
  storedVersions:
  - v1beta1
EOF

성공하면 다음이 표시됩니다.

customresourcedefinition.apiextensions.k8s.io/ibppeers.ibp.com created

또는

customresourcedefinition.apiextensions.k8s.io/ibppeers.ibp.com configured

콘솔 CRD를 업데이트하려면 다음 명령을 실행하십시오.

cat <<EOF | kubectl apply  -f -
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: ibpconsoles.ibp.com
  labels:
    release: "operator"
    helm.sh/chart: "ibm-ibp"
    app.kubernetes.io/name: "ibp"
    app.kubernetes.io/instance: "ibpconsole"
    app.kubernetes.io/managed-by: "ibp-operator"
spec:
  conversion:
    strategy: Webhook
    webhook:
      clientConfig:
        caBundle: "${TLS_CERT}"
        service:
          name: ibp-webhook
          namespace: ibpinfra
          path: /crdconvert
      conversionReviewVersions:
      - v1beta1
      - v1alpha2
      - v1alpha1
  group: ibp.com
  names:
    kind: IBPConsole
    listKind: IBPConsoleList
    plural: ibpconsoles
    singular: ibpconsole
  scope: Namespaced
  versions:
  - name: v1beta1
    schema:
      openAPIV3Schema:
        x-kubernetes-preserve-unknown-fields: true
    served: true
    storage: true
    subresources:
      status: {}
  - name: v1alpha2
    schema:
      openAPIV3Schema:
        x-kubernetes-preserve-unknown-fields: true
    served: true
    storage: false
    subresources:
      status: {}
  - name: v1alpha1
    schema:
      openAPIV3Schema:
        x-kubernetes-preserve-unknown-fields: true
    served: true
    storage: false
    subresources:
      status: {}
status:
  acceptedNames:
    kind: IBPConsole
    listKind: IBPConsoleList
    plural: ibpconsoles
    singular: ibpconsole
  conditions: []
  storedVersions:
  - v1beta1

EOF

성공하면 다음이 표시됩니다.

customresourcedefinition.apiextensions.k8s.io/ibpconsoles.ibp.com created

또는

customresourcedefinition.apiextensions.k8s.io/ibpconsoles.ibp.com configured

순서 지정자 CRD를 업데이트하려면 다음 명령을 실행하십시오.

cat <<EOF | kubectl apply  -f -
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: ibporderers.ibp.com
  labels:
    release: "operator"
    helm.sh/chart: "ibm-ibp"
    app.kubernetes.io/name: "ibp"
    app.kubernetes.io/instance: "ibporderer"
    app.kubernetes.io/managed-by: "ibp-operator"
spec:
  conversion:
    strategy: Webhook
    webhook:
      clientConfig:
        caBundle: "${TLS_CERT}"
        service:
          name: ibp-webhook
          namespace: ibpinfra
          path: /crdconvert
      conversionReviewVersions:
      - v1beta1
      - v1alpha2
      - v1alpha1
  group: ibp.com
  names:
    kind: IBPOrderer
    listKind: IBPOrdererList
    plural: ibporderers
    singular: ibporderer
  scope: Namespaced
  versions:
  - name: v1beta1
    schema:
      openAPIV3Schema:
        x-kubernetes-preserve-unknown-fields: true
    served: true
    storage: true
    subresources:
      status: {}
  - name: v1alpha2
    schema:
      openAPIV3Schema:
        x-kubernetes-preserve-unknown-fields: true
    served: true
    storage: false
    subresources:
      status: {}
  - name: v1alpha1
    schema:
      openAPIV3Schema:
        x-kubernetes-preserve-unknown-fields: true
    served: true
    storage: false
    subresources:
      status: {}
status:
  acceptedNames:
    kind: IBPOrderer
    listKind: IBPOrdererList
    plural: ibporderers
    singular: ibporderer
  conditions: []
  storedVersions:
  - v1beta1
EOF

성공하면 다음이 표시됩니다.

customresourcedefinition.apiextensions.k8s.io/ibporderers.ibp.com created

또는

customresourcedefinition.apiextensions.k8s.io/ibporderers.ibp.com configured

IBM Blockchain Platform 배치를 위한 새 네임스페이스를 작성합니다.

다음으로 IBM Blockchain Platform의 배치를 위한 두 번째 프로젝트를 작성해야 합니다. kubectl CLI를 사용하여 네임스페이스를 작성할 수 있습니다. 클러스터 관리자가 네임스페이스를 작성해야 합니다.

CLI를 사용 중인 경우 다음 명령으로 새 네임스페이스를 작성하십시오.

kubectl create namespace <NAMESPACE>

<NAMESPACE> 를 IBM Blockchain Platform 배치 네임스페이스에 사용할 이름으로 바꾸십시오.

IBM Blockchain Platform을 사용하여 배치하는 각 블록체인 네트워크에 대한 네임스페이스를 작성해야 합니다. 예를 들어 개발, 스테이징 및 프로덕션용으로 각각 서로 다른 네트워크를 작성하려는 경우에는 각 환경에 대해 고유한 네임스페이스를 작성해야 합니다. 별도의 네임스페이스를 사용하면 각 네트워크에 별도의 리소스가 제공되며 각 네트워크에 대해 고유 액세스 정책을 설정할 수 있습니다. 각 네임스페이스에 대해 별도의 오퍼레이터 및 콘솔을 배치하려면 이러한 배치 지시사항을 따라야 합니다.

CLI를 사용하여 네임스페이스에 사용 가능한 스토리지 클래스를 찾을 수도 있습니다. 배치를 위한 새 스토리지 클래스를 작성한 경우에는 다음 명령의 출력에 해당 스토리지 클래스가 표시되어야 합니다.

kubectl get storageclasses

기본 스토리지 클래스를 사용하지 않는 경우에는 추가 구성이 필요합니다. 고려사항은 스토리지 를 참조하십시오.

로컬 레지스트리에 대한 권한 설정

이미 ibpinfra 네임스페이스 또는 프로젝트에서 로컬 레지스트리에 대한 인타이틀먼트를 설정했습니다. 이제 IBM Blockchain Platform 네임스페이스 또는 프로젝트에서 하나를 작성해야 합니다. IBM Blockchain Platform을 구입한 후 내 IBM 에 액세스하여 오퍼링에 대한 자격 부여 키를 얻을 수 있습니다. Kubernetes Secret을 작성하여 인타이틀먼트 키를 클러스터에 저장해야 합니다. 키를 클러스터에 안전하게 저장하고 오퍼레이터 및 콘솔 배치에 전달하는 데 Kubernetes 시크릿이 사용됩니다.

다음 명령을 실행하여 시크릿을 작성하고 네임스페이스에 추가하십시오.

kubectl create secret docker-registry docker-key-secret --docker-server=<LOCAL_REGISTRY> --docker-username=<USER> --docker-password=<LOCAL_REGISTRY_PASSWORD> --docker-email=<EMAIL> -n <NAMESPACE>

작성하는 시크릿의 이름은 docker-key-secret입니다. 이 값은 나중 단계에서 오퍼레이터가 오퍼링을 배치하는 데 사용됩니다. 작성한 시크릿의 이름을 변경하는 경우에는 나중 단계에서 해당 이름을 변경해야 합니다.

보안 및 액세스 정책 추가

IBM Blockchain Platform 에는 네임스페이스에 추가할 특정 보안 및 액세스 정책이 필요합니다. 보안 정책을 정의하기 위해 복사하고 편집할 수 있도록 여기에 .yaml 파일 세트의 컨텐츠가 제공됩니다. 이러한 파일을 로컬 시스템에 저장한 후 kubectl CLI를 사용하여 여기에 네임스페이스를 추가해야 합니다. 이러한 단계는 클러스터 관리자가 완료해야 합니다. 또한 배치된 피어 initdind 컨테이너는 권한 있는 모드로 실행해야 한다는 점을 유의하십시오.

팟(Pod) 보안 정책 적용

아래 PodSecurityPolicy 오브젝트를 복사하여 로컬 시스템에 ibp-psp.yaml로 저장하십시오.

apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: ibm-blockchain-platform-psp
spec:
  hostIPC: false
  hostNetwork: false
  hostPID: false
  privileged: true
  allowPrivilegeEscalation: true
  readOnlyRootFilesystem: false
  seLinux:
    rule: RunAsAny
  supplementalGroups:
    rule: RunAsAny
  runAsUser:
    rule: RunAsAny
  fsGroup:
    rule: RunAsAny
  requiredDropCapabilities:
  - ALL
  allowedCapabilities:
  - NET_BIND_SERVICE
  - CHOWN
  - DAC_OVERRIDE
  - SETGID
  - SETUID
  - FOWNER
  volumes:
  - '*'

파일을 저장하고 편집한 후에는 다음 명령을 실행하여 파일을 클러스터에 추가하고 정책을 네임스페이스에 추가하십시오.

kubectl apply -f ibp-psp.yaml

ClusterRole 적용

다음 텍스트를 로컬 시스템의 파일에 복사하고 해당 파일을 ibp-clusterrole.yaml로 저장하십시오. 이 파일은 PodSecurityPolicy에 필요한 ClusterRole을 정의합니다. 파일을 편집하고 <NAMESPACE> 을 IBM Blockchain Platform 배치 네임스페이스의 이름으로 대체하십시오.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: <NAMESPACE>
  labels:
    release: "operator"
    helm.sh/chart: "ibm-ibp"
    app.kubernetes.io/name: "ibp"
    app.kubernetes.io/instance: "ibp"
    app.kubernetes.io/managed-by: "ibp-operator"
rules:
- apiGroups:
  - extensions
  resourceNames:
  - ibm-blockchain-platform-psp
  resources:
  - podsecuritypolicies
  verbs:
  - use
- apiGroups:
  - apiextensions.k8s.io
  resources:
  - persistentvolumeclaims
  - persistentvolumes
  verbs:
  - get
  - list
  - create
  - update
  - patch
  - watch
  - delete
  - deletecollection
- apiGroups:
  - apiextensions.k8s.io
  resources:
  - customresourcedefinitions
  verbs:
  - get
- apiGroups:
  - route.openshift.io
  resources:
  - routes
  - routes/custom-host
  verbs:
  - get
  - list
  - create
  - update
  - patch
  - watch
  - delete
  - deletecollection
- apiGroups:
  - ""
  resources:
  - pods
  - pods/log
  - persistentvolumeclaims
  - persistentvolumes
  - services
  - endpoints
  - events
  - configmaps
  - secrets
  - nodes
  - serviceaccounts
  verbs:
  - get
  - list
  - create
  - update
  - patch
  - watch
  - delete
  - deletecollection
- apiGroups:
  - "batch"
  resources:
  - jobs
  verbs:
  - get
  - list
  - create
  - update
  - patch
  - watch
  - delete
  - deletecollection
- apiGroups:
  - "authorization.openshift.io"
  - "rbac.authorization.k8s.io"
  resources:
  - roles
  - rolebindings
  verbs:
  - get
  - list
  - create
  - update
  - patch
  - watch
  - delete
  - deletecollection
  - bind
  - escalate
- apiGroups:
  - ""
  resources:
  - namespaces
  verbs:
  - get
- apiGroups:
  - apps
  resources:
  - deployments
  - daemonsets
  - replicasets
  - statefulsets
  verbs:
  - get
  - list
  - create
  - update
  - patch
  - watch
  - delete
  - deletecollection
- apiGroups:
  - monitoring.coreos.com
  resources:
  - servicemonitors
  verbs:
  - get
  - create
- apiGroups:
  - apps
  resourceNames:
  - ibp-operator
  resources:
  - deployments/finalizers
  verbs:
  - update
- apiGroups:
  - ibp.com
  resources:
  - ibpcas.ibp.com
  - ibppeers.ibp.com
  - ibporderers.ibp.com
  - ibpconsoles.ibp.com
  - ibpcas
  - ibppeers
  - ibporderers
  - ibpconsoles
  - ibpcas/finalizers
  - ibppeers/finalizers
  - ibporderers/finalizers
  - ibpconsoles/finalizers
  - ibpcas/status
  - ibppeers/status
  - ibporderers/status
  - ibpconsoles/status
  verbs:
  - get
  - list
  - create
  - update
  - patch
  - watch
  - delete
  - deletecollection
- apiGroups:
  - extensions
  - networking.k8s.io
  - config.openshift.io
  resources:
  - ingresses
  verbs:
  - get
  - list
  - create
  - update
  - patch
  - watch
  - delete
  - deletecollection

파일을 저장하고 편집한 후에는 다음 명령을 실행하십시오.

kubectl apply -f ibp-clusterrole.yaml -n <NAMESPACE>

<NAMESPACE> 를 IBM Blockchain Platform 전개 이름 공간의 이름으로 바꾸십시오.

ClusterRoleBinding 적용

다음 텍스트를 로컬 시스템의 파일에 복사하고 해당 파일을 ibp-clusterrolebinding.yaml로 저장하십시오. 이 파일은 ClusterRoleBinding을 정의합니다. 파일을 편집하고 <NAMESPACE> 을 IBM Blockchain Platform 배치 네임스페이스의 이름으로 대체하십시오.

kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: <NAMESPACE>
  labels:
    release: "operator"
    helm.sh/chart: "ibm-ibp"
    app.kubernetes.io/name: "ibp"
    app.kubernetes.io/instance: "ibp"
    app.kubernetes.io/managed-by: "ibp-operator"
subjects:
- kind: ServiceAccount
  name: default
  namespace: <NAMESPACE>
roleRef:
  kind: ClusterRole
  name: <NAMESPACE>
  apiGroup: rbac.authorization.k8s.io

파일을 저장하고 편집한 후에는 다음 명령을 실행하십시오.

kubectl apply -f ibp-clusterrolebinding.yaml -n <NAMESPACE>

<NAMESPACE> 를 IBM Blockchain Platform 전개 이름 공간의 이름으로 바꾸십시오.

역할 바인딩 작성

정책을 적용한 후에는 서비스 계정에 콘솔을 배치하기 위해 필요한 레벨의 권한을 부여해야 합니다. 대상 네임스페이스의 이름을 사용하여 다음 명령을 실행하십시오.

kubectl -n <NAMESPACE> create rolebinding ibp-operator-rolebinding --clusterrole=<NAMESPACE> --group=system:serviceaccounts:<NAMESPACE>

IBM Blockchain Platform 운영자를 배치하십시오.

IBM Blockchain Platform 은 운영자를 사용하여 IBM Blockchain Platform 콘솔을 설치합니다. kubectl CLI를 사용하여 사용자 정의 리소스를 네임스페이스에 추가하여 클러스터에 오퍼레이터를 배치할 수 있습니다. 사용자 정의 리소스는 Docker 레지스트리에서 오퍼레이터 이미지를 가져와 클러스터에서 시작합니다.

다음 텍스트를 로컬 시스템의 파일에 복사하고 해당 파일을 ibp-operator.yaml로 저장하십시오.

image: cp.icr.io/cp/image: <LOCAL_REGISTRY>/로 바꾸고 로컬 레지스트리의 URL을 삽입하십시오.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: ibp-operator
  labels:
    release: "operator"
    helm.sh/chart: "ibm-ibp"
    app.kubernetes.io/name: "ibp"
    app.kubernetes.io/instance: "ibp"
    app.kubernetes.io/managed-by: "ibp-operator"
spec:
  replicas: 1
  strategy:
    type: "Recreate"
  selector:
    matchLabels:
      name: ibp-operator
  template:
    metadata:
      labels:
        name: ibp-operator
        release: "operator"
        helm.sh/chart: "ibm-ibp"
        app.kubernetes.io/name: "ibp"
        app.kubernetes.io/instance: "ibp"
        app.kubernetes.io/managed-by: "ibp-operator"
      annotations:
        productName: "IBM Blockchain Platform"
        productID: "54283fa24f1a4e8589964e6e92626ec4"
        productVersion: "2.5.2"
        productChargedContainers: ""
        productMetric: "VIRTUAL_PROCESSOR_CORE"
    spec:
      hostIPC: false
      hostNetwork: false
      hostPID: false
      serviceAccountName: default
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
              - matchExpressions:
                  - key: beta.kubernetes.io/arch
                    operator: In
                    values:
                      - amd64
      securityContext:
        runAsNonRoot: true
        runAsUser: 1001
        fsGroup: 2000
      imagePullSecrets:
        - name: docker-key-secret
        - name: ibm-entitlement-key
      containers:
        - name: ibp-operator
          image: cp.icr.io/cp/ibp-operator:2.5.2-20220111-amd64
          command:
            - ibp-operator
          imagePullPolicy: Always
          securityContext:
            privileged: false
            allowPrivilegeEscalation: false
            readOnlyRootFilesystem: false
            runAsNonRoot: false
            runAsUser: 1001
            capabilities:
              drop:
                - ALL
              add:
                - CHOWN
                - FOWNER
          livenessProbe:
            tcpSocket:
              port: 8383
            initialDelaySeconds: 10
            timeoutSeconds: 5
            failureThreshold: 5
          readinessProbe:
            tcpSocket:
              port: 8383
            initialDelaySeconds: 10
            timeoutSeconds: 5
            periodSeconds: 5
          env:
            - name: WATCH_NAMESPACE
              valueFrom:
                fieldRef:
                  fieldPath: metadata.namespace
            - name: POD_NAME
              valueFrom:
                fieldRef:
                  fieldPath: metadata.name
            - name: OPERATOR_NAME
              value: "ibp-operator"
            - name: CLUSTERTYPE
              value: K8S
          resources:
            requests:
              cpu: 100m
              memory: 200Mi
            limits:
              cpu: 100m
              memory: 200Mi

그런 다음 kubectl CLI를 사용하여 사용자 정의 리소스를 네임스페이스에 추가하십시오.

kubectl apply -f ibp-operator.yaml -n <NAMESPACE>

<NAMESPACE> 를 IBM Blockchain Platform 전개 이름 공간의 이름으로 바꾸십시오.

kubectl get deployment -n <NAMESPACE>명령을 실행하여 운영자가 배치되었는지 확인할 수 있습니다. 오퍼레이터 배치가 성공한 경우에는 네 개의 1이 표시된 다음과 같은 테이블을 볼 수 있습니다. 오퍼레이터 배치에는 약 1분이 소요됩니다.

NAME           READY   UP-TO-DATE   AVAILABLE   AGE
ibp-operator   1/1     1            1           1m

IBM Blockchain Platform 콘솔 배치

운영자가 사용자 네임스페이스에서 실행 중인 경우 사용자 정의 자원을 적용하여 클러스터에서 IBM Blockchain Platform 콘솔을 시작할 수 있습니다. 그 후에는 브라우저에서 콘솔에 액세스할 수 있습니다. Kubernetes 네임스페이스당 하나의 콘솔만 배치할 수 있습니다.

아래 사용자 정의 리소스 정의를 ibp-console.yaml로 로컬 시스템에 저장하십시오.

apiVersion: ibp.com/v1beta1
kind: IBPConsole
metadata:
  name: ibpconsole
spec:
  arch:
    - amd64
  license:
    accept: false
  serviceAccountName: default
  email: "<EMAIL>"
  password: "<PASSWORD>"
  registryURL: cp.icr.io/cp
  imagePullSecrets:
    - docker-key-secret
    - ibm-entitlement-key
  networkinfo:
    domain: <DOMAIN>
  storage:
    console:
      class: ""
      size: 5Gi
  version: 2.5.2

라이센스 동의:

ibp-console.yaml 파일에 콘솔의 외부 엔드포인트 정보를 지정하십시오.

콘솔에 처음으로 액세스하는 데 사용되는 사용자 이름 및 비밀번호를 제공하십시오.

배치 프로세스의 선택사항에 따라 파일을 추가로 편집해야 할 수 있습니다.

다음 명령은 한 번만 실행할 수 있으므로 콘솔을 설치하기 전에 구성과 관련된 옵션이 있는 경우에는 고급 배치 옵션 을 검토해야 합니다. 예를 들어 다중 구역 클러스터에 콘솔을 배치하는 경우 콘솔을 설치하기 위해 다음 단계를 실행하기 전에 해당 콘솔을 구성해야 합니다.

파일을 업데이트한 후에는 CLI를 사용하여 콘솔을 설치할 수 있습니다.

kubectl apply -f ibp-console.yaml -n <NAMESPACE>

<NAMESPACE> 를 IBM Blockchain Platform 전개 이름 공간의 이름으로 바꾸십시오. 콘솔을 설치하기 전에 다음 섹션에서 고급 배치 옵션을 검토할 수 있습니다. 콘솔을 배치하는 데는 몇 분 정도 소요될 수 있습니다.

고급 배치 옵션

ibp-console.yaml 파일을 편집하여 더 많은 리소스를 콘솔에 할당하거나 다중 구역 클러스터에서 고가용성을 위해 구역을 사용할 수 있습니다. 이 배치 옵션을 활용하기 위해 추가된 resources:clusterdata: 섹션을 사용하여 콘솔 리소스 정의를 사용할 수 있습니다.

apiVersion: ibp.com/v1beta1
kind: IBPConsole
metadata:
  name: ibpconsole
spec:
  arch:
    - amd64
  license:
    accept: false
  serviceAccountName: default
  email: "<EMAIL>"
  password: "<PASSWORD>"
  registryURL: cp.icr.io/cp
  imagePullSecrets:
    - docker-key-secret
    - ibm-entitlement-key
  networkinfo:
    domain: <DOMAIN>
  storage:
    console:
      class: ""
      size: 5Gi
  clusterdata:
    zones:
  resources:
    console:
      requests:
        cpu: 500m
        memory: 1000Mi
      limits:
        cpu: 500m
        memory: 1000Mi
    configtxlator:
      limits:
        cpu: 25m
        memory: 50Mi
      requests:
        cpu: 25m
        memory: 50Mi
    couchdb:
      limits:
        cpu: 500m
        memory: 1000Mi
      requests:
        cpu: 500m
        memory: 1000Mi
    deployer:
      limits:
        cpu: 100m
        memory: 200Mi
      requests:
        cpu: 100m
        memory: 200Mi
  version: 2.5.2

파일 편집을 완료하면 이를 클러스터에 적용하십시오.

kubectl apply -f ibp-console.yaml -n <NAMESPACE>

리소스 할당과 달리 구역을 실행 중인 네트워크에 추가할 수 없습니다. 이미 콘솔을 배치했고 이를 사용하여 클러스터에서 노드를 작성한 경우 이전 작업이 손실됩니다. 콘솔이 다시 시작된 후 새 노드를 배치해야 합니다.

사용자 고유 TLS 인증서 사용(선택사항)

IBM Blockchain Platform 콘솔은 TLS 인증을 사용하여 콘솔 및 블록체인 노드와 콘솔과 브라우저 사이의 통신을 안전하게 합니다. 고유한 TLS 인증서를 작성한 후 Kubernetes 시크릿을 사용하여 콘솔에 해당 인증서를 제공하는 옵션도 존재합니다. 이 단계를 건너뛰는 경우 콘솔은 배치 중에 고유한 자체 서명 TLS 인증서를 작성합니다.

이 단계는 콘솔이 배치되기 전에 수행해야 합니다.

인증 기관 또는 도구를 사용하여 콘솔에 대한 TLS 인증서를 작성할 수 있습니다. TLS 인증서는 주체 이름 또는 대체 도메인 이름에 콘솔 및 프록시의 호스트 이름을 포함해야 합니다. 콘솔 및 프록시 호스트 이름은 다음 형식입니다.

콘솔 호스트 이름: <NAMESPACE>-ibpconsole-console.<DOMAIN>
프록시 호스트 이름: <NAMESPACE>-ibpconsole-proxy.<DOMAIN>

로컬 시스템에서 사용하려는 TLS 인증서로 이동하십시오. TLS 인증서의 이름을 tlscert.pem으로 지정하고 대응하는 개인 키의 이름을 tlskey.pem으로 지정하십시오. 다음 명령을 실행하여 Kubernetes 시크릿을 작성하고 Kubernetes 네임스페이스에 추가하십시오. TLS 인증서 및 키는 PEM 형식이어야 합니다.

kubectl create secret generic console-tls-secret --from-file=tls.crt=./tlscert.pem --from-file=tls.key=./tlskey.pem -n <NAMESPACE>

시크릿을 작성한 후 고급 배치 옵션의 resources:clusterdata: 섹션과 동일한 레벨에서 다음 필드를 ibp-console.yamlspec: 섹션에 한 칸 들여쓰기를 사용하여 추가하십시오. 해당 필드에 작성된 TLS 시크릿의 이름을 제공해야 합니다. The following example deploys a console with the TLS certificate and key stored in a secret named "console-tls-secret". 본인확인정보에 다른 이름을 사용하지 않는 한 "<CONSOLE_TLS_SECRET_NAME>""console-tls-secret" 로 바꾸십시오.

apiVersion: ibp.com/v1beta1
kind: IBPConsole
metadata:
  name: ibpconsole
spec:
  arch:
    - amd64
  license:
    accept: false
  serviceAccountName: default
  email: "<EMAIL>"
  password: "<PASSWORD>"
  registryURL: cp.icr.io/cp
  imagePullSecrets:
    - docker-key-secret
    - ibm-entitlement-key
  networkinfo:
    domain: <DOMAIN>
  storage:
    console:
      class: default
      size: 10Gi
  tlsSecretName: "<CONSOLE_TLS_SECRET_NAME>"

파일 편집이 완료되면 고유한 TLS 인증서를 사용하여 통신에 보안을 설정하기 위해 클러스터에 해당 파일을 적용할 수 있습니다.

kubectl apply -f ibp-console.yaml -n <NAMESPACE>

콘솔 설치 확인

kubectl get deployment -n <NAMESPACE>명령을 실행하여 운영자가 배치되었는지 확인할 수 있습니다. 콘솔 배치가 성공한 경우에는 배치 테이블에 추가된 ibpconsole과 네 개의 1이 표시된 것을 볼 수 있습니다. 콘솔을 배치하는 데는 몇 분 정도 소요됩니다. 사용자는 새로 고치기를 클릭하고 테이블이 업데이트될 때까지 기다려야 할 수 있습니다.

NAME           READY   UP-TO-DATE   AVAILABLE   AGE
ibp-operator   1/1     1            1           10m
ibpconsole     1/1     1            1           4m

콘솔은 하나의 팟(Pod)에 배치된 네 개의 컨테이너로 구성됩니다.

배치에 문제가 있는 경우에는 개별 컨테이너의 로그를 볼 수 있습니다. 먼저 다음 명령을 실행하여 콘솔 팟(Pod)의 이름을 가져오십시오.

kubectl get pods -n <NAMESPACE>

그 후 다음 명령을 사용하여 팟(Pod)에 있는 네 개의 컨테이너 중 하나에서 로그를 가져오십시오.

kubectl logs -f <pod_name> <container_name> -n <NAMESPACE>

UI 컨테이너에서 로그를 가져오는 명령은 다음 예와 같습니다.

kubectl logs -f ibpconsole-55cf9db6cc-856nz console -n blockchain-project

콘솔에 로그인

브라우저를 사용하여 콘솔 URL을 통해 콘솔에 액세스할 수 있습니다.

https://<NAMESPACE>-ibpconsole-console.<DOMAIN>:443

콘솔 URL은 다음 예제와 유사합니다.

https://blockchain-project-ibpconsole-console.xyz.abc.com:443

브라우저에서 콘솔 URL로 이동하는 경우 화면에 콘솔 로그가 표시됩니다.

로그인할 수 없으면 Firefox의 ESR 버전을 사용하고 있지 않은지 확인하십시오. 사용 중인 경우에는 Chrome 등의 다른 브라우저로 전환한 후 로그인하십시오. 그렇지 않으면 브라우저 캐시를 지우고 다시 로그인해 보십시오.

콘솔을 프로비저닝하는 관리자는 다른 사용자에게 액세스 권한을 부여하고 이들이 수행할 수 있는 조치를 제한할 수 있습니다. 자세한 정보는 콘솔에서 사용자 관리를 참조하십시오.

다음 단계

콘솔에 액세스하면 콘솔 UI의 노드 탭을 볼 수 있습니다. 이 화면을 사용하여 콘솔을 배치한 클러스터에 컴포넌트를 배치할 수 있습니다. 콘솔을 시작하려면 네트워크 학습서 빌드 를 참조하십시오. 이 탭에서는 다른 클라우드에 작성된 노드를 조작할 수도 있습니다. 자세한 정보는 노드 가져오기를 참조하십시오.

콘솔에 액세스할 수 있는 사용자를 관리하는 방법, 콘솔 로그 및 블록체인 컴포넌트를 보려면 콘솔 관리를 참조하십시오.

Kubernetes 배포판 사용 시 고려사항

Azure Kubernetes Service, Amazon Web Services, Rancher, Amazon Elastic Kubernetes Service또는 Google 에 IBM Blockchain Platform 을 설치하기 전에 Kubernetes 엔진에서는 다음 단계를 수행해야 합니다. 세부사항은 Kubernetes 배포판 문서를 참조하십시오.

  1. 공용 IP를 사용하는 로드 밸런서가 Kubernetes 클러스터 앞에 구성되어 있는지 확인하십시오.
  2. 로드 밸런서의 IP 주소에 대한 DNS 항목을 작성하십시오.
  3. 로드 밸런서에 대한 DNS에 와일드카드 호스트 항목을 작성하십시오. 이 항목은 와일드카드 호스트가 있는 DNS A 레코드입니다.

    예를 들어, 로드 밸런서에 대한 DNS 항목이 test.example.com인 경우 DNS 항목은 다음과 같으며

    *.test.example.com
    

    결국 다음으로 해석됩니다.

    test.example.com
    

    이 호스트 항목이 구성되어 있는 경우 다음 예제는 모두 test.example.com로 해석해야 합니다.

    console.test.example.com
    peer.test.example.com
    

    nslookup을 사용하여 DNS가 올바르게 구성되었는지 확인할 수 있습니다.

    $ nslookup console.test.example.com
    
  4. 로드 밸런서에 대한 DNS 항목은 IBM Blockchain Platform의 설치 동안 도메인 이름으로 사용되어야 합니다.

  5. NGINX Ingress 제어기를 사용해야 합니다. 대부분의 Kubernetes 분포에 사용할 수 있는 ingress 제어기 설치 안내서 를 참조하십시오. IBM Cloud Kubernetes Service를 사용하는 경우 특정 구성 정보에 대해서는 다음 지시사항 을 참조하십시오.

  6. 다음 지시사항을 사용하여 ssl-passthrough를 사용 가능하게 하거나 Kubernetes 지시사항을 참조하도록 NGINX ingress 제어기 배치를 편집하십시오.

이 예제는 사용자 설치에 대해 정확하지 않을 수 있습니다. 핵심은 ssl-passthrough를 사용으로 설정하는 마지막 행이 있어야 한다는 것입니다.

   /nginx-ingress-controller
   --configmap=$(POD_NAMESPACE)/nginx-configuration
   --tcp-services-configmap=$(POD_NAMESPACE)/tcp-services
   --udp-services-configmap=$(POD_NAMESPACE)/udp-services
   --publish-service=$(POD_NAMESPACE)/ingress-nginx
   --annotations-prefix=nginx.ingress.kubernetes.io
   --enable-ssl-passthrough=true
  1. IBM Blockchain Platform를 설치하다 로 시도하기 전에 모든 포드가 실행 중인지 확인하십시오.

이제 설치를 재개하기를 수행할 수 있습니다.

IBM Cloud Kubernetes Service 사용 시 고려사항

Kubernetes 클러스터가 IBM Cloud에 배치된 경우, IBM Blockchain Platform 의 인스턴스를 배치하고 이를 Kubernetes 클러스터에 링크할 수 있습니다. 그러나 소프트웨어 인타이틀먼트를 구입하여 IBM Cloud Kubernetes Service와 함께 사용하려는 경우 플랫폼을 배치하기 전에 추가 구성 단계가 필요합니다.

IBM Blockchain Platform 서비스에서는 Kubernetes Ingress 이미지가 클러스터에 대해 구성되어 있고 SSL 패스스루가 사용 가능해야 합니다. 이는 모든 데이터가 이를 암호 해독하지 않고 로드 밸런서에 전달할 수 있도록 합니다. 2020년 12월 01이후에 IBM Cloud Kubernetes Service 클러스터를 작성한 경우, 기본적으로 Kubernetes Ingress 애플리케이션 로드 밸런서 (ALBs) 로 구성됩니다. 그러나 SSL 패스스루는 구성에서 기본적으로 사용으로 설정되지 않으며 따라서 이를 사용으로 설정해야 합니다.

IBM Cloud의 OpenShift 에서 플랫폼을 실행하려는 경우 이 절의 단계를 수행할 필요가 없습니다.

Kubernetes Ingress 구성

클러스터가 2020년 12월 01이전에 작성된 경우 IBM Cloud Ingress를 사용하고 IBM Cloud Kubernetes Service 문서 의 지시사항에 따라 클러스터에서 Kubernetes Ingress 이미지를 구성해야 합니다.

어떤 유형의 Ingress를 사용 중인지 확실하지 않으십니까? IBM Cloud CLI에서 다음 명령을 실행하여 사용 가능한 유입 버전을 확인하십시오.

ibmcloud ks alb versions

출력은 다음과 유사하게 표시됩니다.

IBM Cloud Ingress: 'auth' version   
426   

IBM Cloud Ingress versions   
658 (default)   
652   
651   

Community Ingress versions   
0.35.0_474_iks (default)   
0.34.1_475_iks   
0.33.0_476_iks

이제 클러스터가 사용 중인 버전을 확인하려면 다음 명령을 실행하십시오. <cluster> 를 IBM Cloud Kubernetes Service 클러스터의 이름으로 바꾸십시오.

ibmcloud ks alb ls --cluster <cluster>

출력에서 Build 컬럼의 컨텐츠가 이전 목록의 IBM Cloud Ingress version 를 포함하는 경우, 클러스터는 IBM Cloud Ingress에 대해 구성됩니다.

ALB ID                                Enabled   Status     Type      ALB IP           Zone    Build                          ALB VLAN ID   NLB Version   
public-crbn5uqm1d0bdugc65mhe0-alb1    true      enabled    public    208.43.36.82     dal13   ingress:658/ingress-auth:426   2748052       1.0   
public-crbn5uqm1d0bdugc65mhe0-alb2    true      enabled    public    150.238.10.157   dal10   ingress:658/ingress-auth:426   2636539       1.0   
public-crbn5uqm1d0bdugc65mhe0-alb3    true      enabled    public    169.47.96.189    dal12   ingress:658/ingress-auth:426   2683458       1.0

IBM Cloud Ingress에서 커뮤니티 Kubernetes Ingress로 Ingress를 변경하려면 단계를 따라야 합니다.

그렇지 않으면 Build 열에 목록의 Community Ingress version이 포함된 경우 클러스터가 Kubernetes Ingress에 대해 구성됩니다.

ALB ID                                Enabled   Status     Type      ALB IP           Zone    Build                                  ALB VLAN ID   NLB Version   
public-crbukohphd0ps6erapoulg-alb1    true      enabled    public    150.239.57.190   dal10   ingress:0.35.0_474_iks/ingress-auth:   2415385       1.0

이 경우, 다음 SSL passthrough 사용섹션을 건너뛸 수 있습니다.

SSL 패스스루 사용

Kubernetes Ingress 구성을 겹쳐쓰고 SSL passthrough를 사용하려면 구성 맵을 작성하고 이를 클러스터에 적용하여 ALB 배치를 사용자 정의 하기 위한 지시사항을 따르십시오. 각 ALB에 대해 다음과 같이 "enableSslPassthrough""ingressClass" 의 값을 설정해야 합니다.

<alb*-id>: '{"enableSslPassthrough":"true", "ingressClass":"nginx"}'

configmap을 작성하고 ALB를 업데이트한 후에는 클러스터에서 ALB 배치를 확인하여 변경되었는지 확인할 수 있습니다. 팟(Pod)이 다시 시작될 때까지 기다려야 합니다. 일반적으로 ALB가 새 변경사항을 채택하는 데 5 - 10분이 소요됩니다. 업데이트 명령을 실행하고 5 - 10분 동안 기다린 후 다음 명령을 통해 ALB에 대한 배치 스펙을 확인하여 ALB가 업데이트되었는지 확인하십시오.

kubectl get deploy -n kube-system <alb-id> -o yaml

클러스터의 각 ALB에 대해 명령을 반복하여 <alb-id> 를 각 로드 밸런서의 ID로 대체하십시오.

출력에서 containersargs 섹션을 살펴보십시오. 다음과 같이 표시됩니다.

containers:
      - args:
        - /nginx-ingress-controller
        - --configmap=kube-system/ibm-k8s-controller-config
        - --annotations-prefix=nginx.ingress.kubernetes.io
        - --default-ssl-certificate=default/community-ingress-ibp-68e10f583f026529fe7a89da40169ef4-0000
        - --ingress-class=nginx
        - --http-port=80
        - --https-port=443
        - --enable-ssl-passthrough=true
        - --default-backend-service=kube-system/ibm-k8s-controller-default-backend
        - --tcp-services-configmap=kube-system/tcp-services
        - --publish-service=kube-system/public-crbukohphd0ps6erapoulg-alb1

- --ingress-class=nginx- --enable-ssl-passthrough=true를 확인하십시오.

이 결과는 SSL 패스스루를 성공적으로 사용하고 연관된 ingress 클래스가 nginx로 이름 지정되었음을 표시합니다. 이는 플랫폼의 소프트웨어 버전이 IBM Cloud Kubernetes Service 클러스터에 설치될 수 있도록 하기 위해 필요한 것입니다. IBM Blockchain Platform를 설치하다 로 시도하기 전에 모든 포드가 실행 중인지 확인하십시오.