IBM Blockchain Platform 2.5 hinter einer Firewall implementieren

Wichtig: Bei der angezeigten Produktdokumentation handelt es sich nicht um die neueste Version. Stellen Sie sicher, dass die angezeigte Dokumentation der Version der verwendeten Software entspricht. Zur Produktversion wechseln 2.1.3, 2.5, 2.5.1, 2.5.2 (spätestens)

Sie können diese Anweisungen verwenden, um IBM Blockchain Platform 2.5 hinter einer Firewall ohne Internetkonnektivität bereitzustellen. Wenn Sie die Plattform in einem Cluster mit Zugriff auf das externe Internet bereitstellen, verwenden Sie die Hauptanweisungen für IBM Blockchain Platform 2.5 implementieren.

Sie können die folgenden Anweisungen verwenden, um IBM® Blockchain Platform 2.5 in jedem x86_64 Kubernetes-Cluster bereitzustellen, der unter v1.15 - v1.18ausgeführt wird. Verwenden Sie diese Anweisungen, wenn Sie Open-Source-Distributionen von Kubernetes wie beispielsweise Rancher nutzen. Der IBM Blockchain Platform verwendet einen Kubernetes-Operator , um die IBM Blockchain Platform -Konsole in Ihrem Cluster zu installieren und die Bereitstellung und Ihre Blockchain-Knoten zu verwalten. Wenn die IBM Blockchain Platform -Konsole in Ihrem Cluster ausgeführt wird, können Sie die Konsole verwenden, um Blockchain-Knoten zu erstellen und ein Multi-Cloud-Blockchain-Netz zu betreiben.

Wichtige Hinweise

Wenn Sie IBM Blockchain Platform hinter einer Firewall ohne Zugriff auf das öffentliche Internet bereitstellen, kann Ihr JavaScript-oder TypeScript-Smart Contract keine externen Abhängigkeiten herunterladen, wenn er instanziiert wird. Sie müssen auf eine lokale NPM-Registry für den Smart Contract verweisen, um auf die erforderlichen Abhängigkeiten zugreifen zu können. Siehe Node.js -Verträge mit eingeschränktem Internetzugang erstellen. Dieses Problem tritt nicht auf, wenn Sie Smart Contracts verwenden, die in Go geschrieben wurden.
Nachdem Sie die Peer- und Anordnungsknoten bereitgestellt haben, müssen Sie die Ports der Knoten für Ihr Netz zugänglich machen, um auf Anforderungen von Anwendungen oder Knoten außerhalb Ihrer Firewall reagieren zu können. Weitere Informationen zu den Ports, die Sie zugänglich machen müssen, finden Sie unter Internet-Ports im Sicherheitshandbuch.

Erforderliche Ressourcen

Stellen Sie sicher, dass Ihr Kubernetes-Cluster über ausreichende Ressourcen für die IBM Blockchain -Konsole und für die von Ihnen erstellten Blockchain-Knoten verfügt. Der Umfang der erforderlichen Ressourcen kann je nach Infrastruktur, Netzentwurf und Leistungsanforderungen variieren. Die folgende Tabelle enthält Angaben zu den Standardwerten des CPU-, Hauptspeicher- und Speicherbedarfs, die Ihnen bei der Bereitstellung eines Clusters mit einer angemessenen Größe helfen sollen. Die tatsächlichen Ressourcenzuordnungen werden beim Bereitstellen eines Knotens in der Blockchain-Konsole angezeigt und können gemäß Ihren Geschäftsanforderungen während oder nach der Bereitstellung angepasst werden.

Komponente (alle Container)	CPU * *	Speicher (GB)	Speicher (GB)
Peer (Hyperledger Fabric v1.4)	1,1	2,8	200 (enthält 100 GB für den Peer und 100 GB für die Statusdatenbank)
Peer (Hyperledger Fabric v2.x)	0,7	2,0	200 (enthält 100 GB für den Peer und 100 GB für die Statusdatenbank)
Zertifizierungsstelle	0,1	0,2	20
Anordnungsknoten	0,35	0,7	100
Bediener	0,1	0,2	0
Konsole	1,2	2,4	10
-Webhook	0,1	0,2	0

** Diese Werte können geringfügig abweichen. Die tatsächlichen VPC-Zuordnungen werden in der Blockchain-Konsole angezeigt, wenn ein Knoten bereitgestellt wird.

Browser

Die IBM Blockchain Platform -Konsole wurde erfolgreich in den folgenden Browsern getestet:

Chrome Version 83.0.4103.97 (offizieller Build) (64-Bit)
Safari Version 13.0.3 (15608.3.10.1.4)

Speicher

IBM Blockchain Platform erfordert persistenten Speicher für jede Zertifizierungsstelle, jeden Peer und jeden Anordnungsknoten, die Sie bereitstellen, zusätzlich zu dem für die IBM Blockchain -Konsole erforderlichen Speicher. Die IBM Blockchain Platform -Konsole verwendet Speicher für jeden Blockchain-Knoten, den Sie mithilfe einer vordefinierten Speicherklasse bereitstellen.

Vor der Implementierung der IBM Blockchain Platform -Konsole müssen Sie eine Speicherklasse mit genügend Sicherungsspeicher für die IBM Blockchain -Konsole und die von Ihnen erstellten Knoten erstellen. Sie können diese Speicherklasse auf die Standardspeicherklasse Ihres Kubernetes-Clusters setzen oder eine neue Klasse erstellen, die von der IBM Blockchain Platform -Konsole verwendet wird. Wenn Sie einen Cluster mit mehreren Zonen verwenden, müssen Sie die Standardspeicherklasse für jede Zone konfigurieren. Führen Sie nach der Erstellung der Speicherklasse den Befehlkubectl patch storageclass, um die Speicherklasse der Region mit mehreren Zonen als Standardspeicherklasse festzulegen.

Wenn Sie keine Option für persistenten Speicher auswählen wollen, wird die Standardspeicherklasse Ihres Kubernetes-Clusters verwendet.

Eigenen Berechtigungsschlüssel abrufen

Wenn Sie IBM Blockchain Platform von PPA erwerben, erhalten Sie einen Berechtigungsschlüssel für die Software, die Ihrem MyIBM-Account zugeordnet ist. Sie müssen auf diesen Schlüssel zugreifen und ihn speichern, um die Plattform bereitzustellen.

Melden Sie sich bei MyIBM Container Software Bibliothek mit der IBMid und dem Kennwort an, die der berechtigten Software zugeordnet sind.
Wählen Sie im Abschnitt mit den Berechtigungsschlüsseln die Option zum Kopieren des Schlüssels aus, um den Berechtigungsschlüssel in die Zwischenablage zu kopieren und diesen Wert zur späteren Verwendung in den vorliegenden Schritten zu speichern.

Vorbereitende Schritte

IBM Blockchain Platform kann nur auf dem Unterstützte Plattformeninstalliert werden.
Es ist nicht möglich, eine IBM Blockchain Platform v2.1.x -und eine 2.5-Instanz in demselben Cluster bereitzustellen. Falls beide Instanzen des Produkts ausgeführt werden müssen, müssen diese in unterschiedlichen Clustern ausgeführt werden.
Sie müssen die Plattform mithilfe von CLI 'kubectl' installieren und eine Verbindung zu Ihrem Cluster herstellen, um die Plattform bereitzustellen.
Wenn Sie die Plattform nicht in Red Hat OpenShift Container Platform oder Red Hat Open Kubernetes-Distribution ausführen, müssen Sie den NGINX-Ingress-Controller einrichten und in SSL-Durchgriffsmodusausführen. Weitere Informationen finden Sie unter Hinweise zur Verwendung von Kubernetes-Distributionen.

IBM Blockchain Platform -Images extrahieren

Sie können alle IBM Blockchain Platform -Images aus der IBM Entitlement-Registry herunterladen. Wenn Sie die Plattform ohne Zugriff auf das öffentliche Internet bereitstellen möchten, müssen Sie die Images aus der IBM -Registry extrahieren und anschließend mit einer Push-Operation an eine Docker-Registry übertragen, auf die Sie von hinter Ihrer Firewall aus zugreifen können.

Nach dem Kauf von IBM Blockchain Platformkönnen Sie auf Dashboard 'My IBM ' zugreifen, um Ihren Berechtigungsschlüssel für das Angebot abzurufen. Anschließend können Sie mit diesem Schlüssel auf die IBM Blockchain Platform -Images zugreifen.

Melden Sie sich mit dem folgenden Befehl bei der IBM Entitlement-Registry an:

docker login --username cp --password <KEY> cp.icr.io

Ersetzen<KEY>mit Ihrem Berechtigungsschlüssel.

Verwenden Sie nach der Anmeldung den folgenden Befehl, um alle Komponentenimages von IBM Blockchain Platformzu extrahieren:

docker pull cp.icr.io/cp/ibp-operator:2.5.0-20201001-amd64
docker pull cp.icr.io/cp/ibp-init:2.5.0-20201001-amd64
docker pull cp.icr.io/cp/ibp-console:2.5.0-20201001-amd64
docker pull cp.icr.io/cp/ibp-grpcweb:2.5.0-20201001-amd64
docker pull cp.icr.io/cp/ibp-deployer:2.5.0-20201001-amd64
docker pull cp.icr.io/cp/ibp-fluentd:2.5.0-20201001-amd64
docker pull cp.icr.io/cp/ibp-couchdb:2.3.1-20201001-amd64
docker pull cp.icr.io/cp/ibp-peer:1.4.7-20201001-amd64
docker pull cp.icr.io/cp/ibp-orderer:1.4.7-20201001-amd64
docker pull cp.icr.io/cp/ibp-ca:1.4.7-20201001-amd64
docker pull cp.icr.io/cp/ibp-dind:1.4.7-20201001-amd64
docker pull cp.icr.io/cp/ibp-utilities:1.4.7-20201001-amd64
docker pull cp.icr.io/cp/ibp-peer:2.1.1-20201001-amd64
docker pull cp.icr.io/cp/ibp-orderer:2.1.1-20201001-amd64
docker pull cp.icr.io/cp/ibp-chaincode-launcher:2.1.1-20201001-amd64
docker pull cp.icr.io/cp/ibp-utilities:2.1.1-20201001-amd64
docker pull cp.icr.io/cp/ibp-ccenv:2.1.1-20201001-amd64
docker pull cp.icr.io/cp/ibp-goenv:2.1.1-20201001-amd64
docker pull cp.icr.io/cp/ibp-nodeenv:2.1.1-20201001-amd64
docker pull cp.icr.io/cp/ibp-javaenv:2.1.1-20201001-amd64
docker pull cp.icr.io/cp/ibp-crdwebhook:2.5.0-20201001-amd64
docker pull cp.icr.io/cp/ibp-ccenv:1.4.7-20201001-amd64
docker pull cp.icr.io/cp/ibp-goenv:1.4.7-20201001-amd64
docker pull cp.icr.io/cp/ibp-nodeenv:1.4.7-20201001-amd64
docker pull cp.icr.io/cp/ibp-javaenv:1.4.7-20201001-amd64

Wenn Sie die Plattform unter LinuxONE unter s390ximplementieren, ersetzen Sieamd64im Image-Tag mits390x

Nach dem Download der Images müssen Sie die Image-Tags so ändern, dass Sie auf Ihre Docker-Registry verweisen. Ersetzen<LOCAL_REGISTRY>durch die URL Ihrer lokalen Registry und führen Sie die folgenden Befehle aus:

docker tag cp.icr.io/cp/ibp-operator:2.5.0-20201001-amd64 <LOCAL_REGISTRY>/ibp-operator:2.5.0-20201001-amd64
docker tag cp.icr.io/cp/ibp-init:2.5.0-20201001-amd64 <LOCAL_REGISTRY>/ibp-init:2.5.0-20201001-amd64
docker tag cp.icr.io/cp/ibp-console:2.5.0-20201001-amd64 <LOCAL_REGISTRY>/ibp-console:2.5.0-20201001-amd64
docker tag cp.icr.io/cp/ibp-grpcweb:2.5.0-20201001-amd64 <LOCAL_REGISTRY>/ibp-grpcweb:2.5.0-20201001-amd64
docker tag cp.icr.io/cp/ibp-deployer:2.5.0-20201001-amd64 <LOCAL_REGISTRY>/ibp-deployer:2.5.0-20201001-amd64
docker tag cp.icr.io/cp/ibp-fluentd:2.5.0-20201001-amd64 <LOCAL_REGISTRY>/ibp-fluentd:2.5.0-20201001-amd64
docker tag cp.icr.io/cp/ibp-couchdb:2.3.1-20201001-amd64 <LOCAL_REGISTRY>/ibp-couchdb:2.3.1-20201001-amd64
docker tag cp.icr.io/cp/ibp-peer:1.4.7-20201001-amd64 <LOCAL_REGISTRY>/ibp-peer:1.4.7-20201001-amd64
docker tag cp.icr.io/cp/ibp-orderer:1.4.7-20201001-amd64 <LOCAL_REGISTRY>/ibp-orderer:1.4.7-20201001-amd64
docker tag cp.icr.io/cp/ibp-ca:1.4.7-20201001-amd64 <LOCAL_REGISTRY>/ibp-ca:1.4.7-20201001-amd64
docker tag cp.icr.io/cp/ibp-dind:1.4.7-20201001-amd64 <LOCAL_REGISTRY>/ibp-dind:1.4.7-20201001-amd64
docker tag cp.icr.io/cp/ibp-utilities:1.4.7-20201001-amd64 <LOCAL_REGISTRY>/ibp-utilities:1.4.7-20201001-amd64
docker tag cp.icr.io/cp/ibp-peer:2.1.1-20201001-amd64 <LOCAL_REGISTRY>/ibp-peer:2.1.1-20201001-amd64
docker tag cp.icr.io/cp/ibp-orderer:2.1.1-20201001-amd64 <LOCAL_REGISTRY>/ibp-orderer:2.1.1-20201001-amd64
docker tag cp.icr.io/cp/ibp-chaincode-launcher:2.1.1-20201001-amd64 <LOCAL_REGISTRY>/ibp-chaincode-launcher:2.1.1-20201001-amd64
docker tag cp.icr.io/cp/ibp-utilities:2.1.1-20201001-amd64 <LOCAL_REGISTRY>/ibp-utilities:2.1.1-20201001-amd64
docker tag cp.icr.io/cp/ibp-ccenv:2.1.1-20201001-amd64 <LOCAL_REGISTRY>/ibp-ccenv:2.1.1-20201001-amd64
docker tag cp.icr.io/cp/ibp-goenv:2.1.1-20201001-amd64 <LOCAL_REGISTRY>/ibp-goenv:2.1.1-20201001-amd64
docker tag cp.icr.io/cp/ibp-nodeenv:2.1.1-20201001-amd64 <LOCAL_REGISTRY>/ibp-nodeenv:2.1.1-20201001-amd64
docker tag cp.icr.io/cp/ibp-javaenv:2.1.1-20201001-amd64 <LOCAL_REGISTRY>/ibp-javaenv:2.1.1-20201001-amd64
docker tag cp.icr.io/cp/ibp-crdwebhook:2.5.0-20201001-amd64 <LOCAL_REGISTRY>/ibp-crdwebhook:2.5.0-20201001-amd64
docker tag cp.icr.io/cp/ibp-ccenv:1.4.7-20201001-amd64 <LOCAL_REGISTRY>/ibp-ccenv:1.4.7-20201001-amd64
docker tag cp.icr.io/cp/ibp-goenv:1.4.7-20201001-amd64 <LOCAL_REGISTRY>/ibp-goenv:1.4.7-20201001-amd64
docker tag cp.icr.io/cp/ibp-nodeenv:1.4.7-20201001-amd64 <LOCAL_REGISTRY>/ibp-nodeenv:1.4.7-20201001-amd64
docker tag cp.icr.io/cp/ibp-javaenv:1.4.7-20201001-amd64 <LOCAL_REGISTRY>/ibp-javaenv:1.4.7-20201001-amd64

Sie können diedocker imagesum zu überprüfen, ob die neuen Tags erstellt wurden. Sie können die Images mit den neuen Tags mithilfe einer Push-Operation in Ihre Docker-Registry übertragen. Melden Sie sich mit dem folgenden Befehl bei Ihrer Registry an:

docker login --username <USER> --password <LOCAL_REGISTRY_PASSWORD> <LOCAL_REGISTRY>

Ersetzen<USER>mit Ihrem Benutzernamen
Ersetzen<LOCAL_REGISTRY_PASSWORD>mit dem Kennwort für Ihre Registry.
Ersetzen<LOCAL_REGISTRY>durch die URL Ihrer lokalen Registry.

Führen Sie anschließend den folgenden Befehl aus, um die Images zu übertragen. Ersetzen<LOCAL_REGISTRY>durch die URL Ihrer lokalen Registry.

docker push <LOCAL_REGISTRY>/ibp-operator:2.5.0-20201001-amd64
docker push <LOCAL_REGISTRY>/ibp-init:2.5.0-20201001-amd64
docker push <LOCAL_REGISTRY>/ibp-console:2.5.0-20201001-amd64
docker push <LOCAL_REGISTRY>/ibp-grpcweb:2.5.0-20201001-amd64
docker push <LOCAL_REGISTRY>/ibp-deployer:2.5.0-20201001-amd64
docker push <LOCAL_REGISTRY>/ibp-fluentd:2.5.0-20201001-amd64
docker push <LOCAL_REGISTRY>/ibp-couchdb:2.3.1-20201001-amd64
docker push <LOCAL_REGISTRY>/ibp-peer:1.4.7-20201001-amd64
docker push <LOCAL_REGISTRY>/ibp-orderer:1.4.7-20201001-amd64
docker push <LOCAL_REGISTRY>/ibp-ca:1.4.7-20201001-amd64
docker push <LOCAL_REGISTRY>/ibp-dind:1.4.7-20201001-amd64
docker push <LOCAL_REGISTRY>/ibp-utilities:1.4.7-20201001-amd64
docker push <LOCAL_REGISTRY>/ibp-peer:2.1.1-20201001-amd64
docker push <LOCAL_REGISTRY>/ibp-orderer:2.1.1-20201001-amd64
docker push <LOCAL_REGISTRY>/ibp-chaincode-launcher:2.1.1-20201001-amd64
docker push <LOCAL_REGISTRY>/ibp-utilities:2.1.1-20201001-amd64
docker push <LOCAL_REGISTRY>/ibp-ccenv:2.1.1-20201001-amd64
docker push <LOCAL_REGISTRY>/ibp-goenv:2.1.1-20201001-amd64
docker push <LOCAL_REGISTRY>/ibp-nodeenv:2.1.1-20201001-amd64
docker push <LOCAL_REGISTRY>/ibp-javaenv:2.1.1-20201001-amd64
docker push <LOCAL_REGISTRY>/ibp-crdwebhook:2.5.0-20201001-amd64
docker push <LOCAL_REGISTRY>/ibp-ccenv:1.4.7-20201001-amd64
docker push <LOCAL_REGISTRY>/ibp-goenv:1.4.7-20201001-amd64
docker push <LOCAL_REGISTRY>/ibp-nodeenv:1.4.7-20201001-amd64
docker push <LOCAL_REGISTRY>/ibp-javaenv:1.4.7-20201001-amd64

Nachdem Sie diese Schritte ausgeführt haben, können Sie die folgenden Anweisungen verwenden, um IBM Blockchain Platform mit den Images in Ihrer Registry bereitzustellen.

Bevor Sie die nächsten Schritte ausführen können, müssen Sie sich über die Befehlszeilenschnittstelle "kubectl" bei Ihrem Cluster anmelden. Folgen Sie den Anweisungen für die Anmeldung bei Ihrem Cluster. Wenn der Befehl erfolgreich ist, wird Ihnen bei Ausführung des folgenden Befehls die Liste der Namensbereiche in Ihrem Cluster im Terminal angezeigt:

kubectl get pods

Nach erfolgreicher Ausführung des Befehls werden die Pods angezeigt, die in Ihrem Standardnamensbereich ausgeführt werden:

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

Erstellen Sie die`ibpinfra`Namensbereich für den Webhook

Da die Plattform die interne API-Version von aktualisiert hatv1alpha1in früheren Versionen zuv1alpha2In 2.5 ist ein Webhook für Kubernetes-Konvertierung erforderlich, um die Zertifizierungsstelle, den Peer, den Operator und die Konsole auf die neue API-Version zu aktualisieren. Dieser Webhook wird auch künftig weiter zum Einsatz kommen, weshalb er auch bei neuen Bereitstellungen der Plattform bereitgestellt werden muss. Der Webhook wird in seinem eigenen Namensbereich bereitgestellt, der alsibpinfrain diesen Anweisungen.

Nachdem Sie sich bei Ihrem Cluster angemeldet haben, können Sie die neueibpinfraNamensbereich für den Webhook für Kubernetes-Konvertierung unter Verwendung der Befehlszeilenschnittstelle 'kubectl'. Der neue Namensbereich muss von einem Clusteradministrator erstellt werden.

Führen Sie den folgenden Befehl aus, um den Namensbereich zu erstellen.

kubectl create namespace ibpinfra

Berechtigung für Ihre lokale Registry einrichten

Nachdem Sie die IBM Blockchain Platform -Images mit einer Push-Operation in Ihre eigene Docker-Registry übertragen haben, müssen Sie das Kennwort in dieser Registry in Ihrem Cluster speichern, indem Sie eine Geheimer Kubernetes-Schlüsselerstellen. Geheime Kubernetes-Schlüssel ermöglichen eine sichere Speicherung des Schlüssels in Ihrem Cluster und das Übergeben des Schlüssels an die Operator- und Konsolenbereitstellungen.

Führen Sie den folgenden Befehl aus, um den geheimen Schlüssel zu erstellen und Ihrem hinzuzufügen.ibpinfraNamensbereich oder Projekt:

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>

Ersetzen<USER>mit Ihrem Benutzernamen
Ersetzen<EMAIL>mit Ihrer E-Mail-Adresse.
Ersetzen<LOCAL_REGISTRY_PASSWORD>mit dem Kennwort für Ihre Registry.
Ersetzen<LOCAL_REGISTRY>durch die URL Ihrer lokalen Registry.
Ersetzen<NAMESPACE>mitibpinfra.

Der Name des geheimen Schlüssels, den Sie erstellen, lautet:docker-key-secret. Sie ist für den Webhook erforderlich, den Sie später implementieren. Wenn Sie den Namen eines von Ihnen erstellten geheimen Schlüssels ändern, müssen Sie den entsprechenden Namen auch in nachfolgenden Schritten ändern.

Webhook und angepasste Ressourcendefinitionen für den OpenShift-Cluster bereitstellen

Bevor Sie für ein vorhandenes Netz ein Upgrade auf Version 2.5 durchführen oder eine neue Instanz der Plattform für Ihren Kubernetes-Cluster bereitstellen können, müssen Sie mit den Schritten in diesem Abschnitt den Konvertierungs-Webhook erstellen. Der Webhook wird in seinem eigenen Namensbereich oder Projekt bereitgestellt, auf das verwiesen wird.ibpinfrain diesen Anweisungen.

Mit den ersten drei Schritten wird der Webhook bereitgestellt. Die letzten fünf Schritte beziehen sich auf die angepassten Ressourcendefinitionen für die CA-, Peer-, Anordnungsknoten-und Konsolenkomponenten, die für IBM Blockchain Platform erforderlich sind. Sie müssen den Webhook und die angepassten Ressourcendefinitionen nur einmal pro Cluster bereitstellen. Falls Sie diesen Webhook und die angepassten Ressourcendefinitionen bereits für Ihren Cluster bereitgestellt haben, können Sie die folgenden acht Schritte überspringen.

1. Rollenbasierte Zugriffssteuerung (RBAC) für den Webhook konfigurieren

Kopieren Sie zuerst den folgenden Text in eine Datei auf Ihrem lokalen System und speichern Sie die Datei unterrbac.yamlMit diesem Schritt kann der Webhook einen geheimen TLS-Schlüssel in seinem eigenen Projekt lesen und erstellen.

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

Führen Sie den folgenden Befehl aus, um die Datei zu Ihrer Clusterdefinition hinzuzufügen:

kubectl apply -f rbac.yaml -n ibpinfra

Wenn dieser Befehl erfolgreich ausgeführt wird, wird eine Ausgabe ähnlich der folgenden angezeigt:

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

2. (NurOpenShift -Cluster) Sicherheitskontexteinschränkung anwenden

IBM Blockchain Platform erfordert das Hinzufügen bestimmter Sicherheits-und Zugriffsrichtlinien zumibpinfraProjekt. Kopieren Sie das Objekt der Integritätsbedingung für den Sicherheitskontext unten und speichern Sie es auf Ihrem lokalen System alsibpinfra-scc.yaml.

allowHostDirVolumePlugin: true
allowHostIPC: true
allowHostNetwork: true
allowHostPID: true
allowHostPorts: true
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:ibpinfra
kind: SecurityContextConstraints
metadata:
  name: ibpinfra
readOnlyRootFilesystem: false
requiredDropCapabilities: []
runAsUser:
  type: RunAsAny
seLinuxContext:
  type: RunAsAny
supplementalGroups:
  type: RunAsAny
volumes:
- "*"
priority: 1

Nach dem Speichern der Datei führen Sie die folgenden Befehle aus, um die Datei Ihrem Cluster und die Richtlinie Ihrem Projekt hinzuzufügen.

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

Wenn die Befehle erfolgreich ausgeführt werden, wird eine Ausgabe wie die im folgenden Beispiel angezeigt:

securitycontextconstraints.security.openshift.io/ibpinfra created
scc "ibpinfra" added to: ["system:serviceaccounts:ibpinfra"]

3. Webhook bereitstellen

Um den Webhook zu implementieren, müssen Sie zwei erstellen.yamlDateien und wenden Sie sie auf Ihren Kubernetes-Cluster an

deployment.yaml

Kopieren Sie den folgenden Text in eine Datei auf Ihrem lokalen System und speichern Sie die Datei unterdeployment.yaml. Wenn Sie auf OpenShift Container Platform 4.3 unter LinuxONE implementieren, müssen Sie Folgendes ersetzen:amd64mits390x.

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:
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
    type: RollingUpdate
  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.0"
    spec:
      serviceAccountName: webhook
      imagePullSecrets:
        - name: docker-key-secret
      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.0-20201001-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"

Führen Sie den folgenden Befehl aus, um die Datei zu Ihrer Clusterdefinition hinzuzufügen:

kubectl apply -n ibpinfra -f deployment.yaml

Wenn dieser Befehl erfolgreich ausgeführt wird, wird eine Ausgabe ähnlich der folgenden angezeigt:

deployment.apps/ibp-webhook created

service.yaml

Kopieren Sie anschließend den folgenden Text in eine Datei auf Ihrem lokalen System und speichern Sie die Datei unterservice.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"

Führen Sie den folgenden Befehl aus, um die Datei zu Ihrer Clusterdefinition hinzuzufügen:

kubectl apply -n ibpinfra -f service.yaml

Wenn dieser Befehl erfolgreich ausgeführt wird, wird eine Ausgabe ähnlich der folgenden angezeigt:

service/ibp-webhook created

4. Zertifikat extrahieren

Nun muss das TLS-Zertifikat extrahiert werden, das durch die Webhook-Bereitstellung generiert wurde, damit es in den nächsten Schritten in den angepassten Ressourcendefinitionen verwendet werden kann. Führen Sie den folgenden Befehl aus, um den geheimen Schlüssel in eine Zeichenfolge mit Base64-Codierung zu extrahieren:

kubectl get secret webhook-tls-cert -n ibpinfra -o json | jq -r .data.\"cert.pem\"

Die Ausgabe dieses Befehls ist eine Zeichenfolge mit Base64-Codierung und ähnelt dem folgenden Beispiel:

LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUJoRENDQVNtZ0F3SUJBZ0lRZDNadkhZalN0KytKdTJXbFMvVDFzakFLQmdncWhrak9QUVFEQWpBU01SQXcKRGdZRFZRUUtFd2RKUWswZ1NVSlFNQjRYRFRJd01EWXdPVEUxTkRrME5sFORGsxTVZvdwpFakVRTUE0R0ExVUVDaE1IU1VKTklFbENVREJaTUJGcVRyV0Z4WFBhTU5mSUkrYUJ2RG9DQVFlTW3SUZvREFUQmdOVkhTVUVEREFLQmdncgpCZ0VGQlFjREFUQU1CZ05WSFJNQkFmOEVBakFBTUNvR0ExVWRFUVFqTUNHQ0gyTnlaQzEzWldKb2IyOXJMWE5sCmNuWnBZMlV1ZDJWaWFHOXZheTV6ZG1Nd0NnWUlLb1pJemowRUF3SURTUUF3UmdJaEFNb29kLy9zNGxYaTB2Y28KVjBOMTUrL0h6TkI1cTErSTJDdU9lb1c1RnR4MUFpRUEzOEFlVktPZnZSa0paN0R2THpCRFh6VmhJN2lBQVV3ZAo3ZStrOTA3TGFlTT0KLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLQo=

Speichern Sie die Zeichenfolge mit Base64-Codierung, die durch diesen Befehl zurückgegeben wurde und die Sie in den nächsten Schritten verwenden müssen, wenn Sie die angepassten Ressourcendefinitionen erstellen.

5. Angepasste Ressourcendefinition für die Zertifizierungsstelle erstellen

Kopieren Sie den folgenden Text in eine Datei auf Ihrem lokalen System und speichern Sie die Datei unteribpca-crd.yaml.

apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
metadata:
  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
  name: ibpcas.ibp.com
spec:
  preserveUnknownFields: false
  conversion:
    strategy: Webhook
    webhookClientConfig:
      service:
        namespace: ibpinfra
        name: ibp-webhook
        path: /crdconvert
      caBundle: "<CABUNDLE>"
  validation:
    openAPIV3Schema:
      x-kubernetes-preserve-unknown-fields: true    
  group: ibp.com
  names:
    kind: IBPCA
    listKind: IBPCAList
    plural: ibpcas
    singular: ibpca
  scope: Namespaced
  subresources:
    status: {}
  version: v1alpha2
  versions:
  - name: v1alpha2
    served: true
    storage: true
  - name: v210
    served: false
    storage: false
  - name: v212
    served: false
    storage: false
  - name: v1alpha1
    served: true
    storage: false

Ersetzen Sie den Wert von<CABUNDLE>mit der codierten base64 -Zeichenfolge, die Sie in Schritt 3 nach der Webhook-Bereitstellung extrahiert haben.

Verwenden Sie anschließend diekubectlBefehlszeilenschnittstelle zum Hinzufügen der angepassten Ressourcendefinition zu Ihrem Projekt.

kubectl apply -f ibpca-crd.yaml

Wenn der Befehl erfolgreich ausgeführt wird, sollte die folgende Ausgabe angezeigt werden:

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

6. Angepasste Ressourcendefinition für den Peer erstellen

Kopieren Sie den folgenden Text in eine Datei auf Ihrem lokalen System und speichern Sie die Datei unteribppeer-crd.yaml.

apiVersion: apiextensions.k8s.io/v1beta1
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:
  preserveUnknownFields: false
  conversion:
    strategy: Webhook
    webhookClientConfig:
      service:
        namespace: ibpinfra
        name: ibp-webhook
        path: /crdconvert
      caBundle: "<CABUNDLE>"
  validation:
    openAPIV3Schema:
      x-kubernetes-preserve-unknown-fields: true    
  group: ibp.com
  names:
    kind: IBPPeer
    listKind: IBPPeerList
    plural: ibppeers
    singular: ibppeer
  scope: Namespaced
  subresources:
    status: {}
  version: v1alpha2
  versions:
  - name: v1alpha2
    served: true
    storage: true
  - name: v1alpha1
    served: true
    storage: false

Ersetzen Sie den Wert von<CABUNDLE>mit der codierten base64 -Zeichenfolge, die Sie in Schritt 3 nach der Webhook-Bereitstellung extrahiert haben.

Verwenden Sie anschließend diekubectlBefehlszeilenschnittstelle zum Hinzufügen der angepassten Ressourcendefinition zu Ihrem Projekt.

kubectl apply -f ibppeer-crd.yaml

Wenn der Befehl erfolgreich ausgeführt wird, sollte die folgende Ausgabe angezeigt werden:

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

7. Angepasste Ressourcendefinition für den Anordnungsknoten erstellen

Kopieren Sie den folgenden Text in eine Datei auf Ihrem lokalen System und speichern Sie die Datei unteribporderer-crd.yaml.

apiVersion: apiextensions.k8s.io/v1beta1
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:
  preserveUnknownFields: false
  conversion:
    strategy: Webhook
    webhookClientConfig:
      service:
        namespace: ibpinfra
        name: ibp-webhook
        path: /crdconvert
      caBundle: "<CABUNDLE>"
  validation:
    openAPIV3Schema:
      x-kubernetes-preserve-unknown-fields: true    
  group: ibp.com
  names:
    kind: IBPOrderer
    listKind: IBPOrdererList
    plural: ibporderers
    singular: ibporderer
  scope: Namespaced
  subresources:
    status: {}
  version: v1alpha2
  versions:
  - name: v1alpha2
    served: true
    storage: true
  - name: v1alpha1
    served: true
    storage: false

Ersetzen Sie den Wert von<CABUNDLE>mit der codierten base64 -Zeichenfolge, die Sie in Schritt 3 nach der Webhook-Bereitstellung extrahiert haben.

Verwenden Sie anschließend diekubectlBefehlszeilenschnittstelle zum Hinzufügen der angepassten Ressourcendefinition zu Ihrem Projekt.

kubectl apply -f ibporderer-crd.yaml

Wenn der Befehl erfolgreich ausgeführt wird, sollte die folgende Ausgabe angezeigt werden:

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

8. Angepasste Ressourcendefinition für die Konsole erstellen

Kopieren Sie den folgenden Text in eine Datei auf Ihrem lokalen System und speichern Sie die Datei unteribpconsole-crd.yaml.

apiVersion: apiextensions.k8s.io/v1beta1
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:
  preserveUnknownFields: false
  conversion:
    strategy: Webhook
    webhookClientConfig:
      service:
        namespace: ibpinfra
        name: ibp-webhook
        path: /crdconvert
      caBundle: "<CABUNDLE>"
  validation:
    openAPIV3Schema:
      x-kubernetes-preserve-unknown-fields: true
  group: ibp.com
  names:
    kind: IBPConsole
    listKind: IBPConsoleList
    plural: ibpconsoles
    singular: ibpconsole
  scope: Namespaced
  subresources:
    status: {}
  version: v1alpha2
  versions:
  - name: v1alpha2
    served: true
    storage: true
  - name: v1alpha1
    served: true
    storage: false

Ersetzen Sie den Wert von<CABUNDLE>durch die base64 codierte Zeichenfolge, die Sie in Schritt 3 nach der Webhook-Bereitstellung extrahiert haben.
Verwenden Sie anschließend diekubectlBefehlszeilenschnittstelle zum Hinzufügen der angepassten Ressourcendefinition zu Ihrem Projekt.

kubectl apply -f ibpconsole-crd.yaml

Wenn der Befehl erfolgreich ausgeführt wird, sollte die folgende Ausgabe angezeigt werden:

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

Neuen Namensbereich für Ihre IBM Blockchain Platform -Bereitstellung erstellen

Als Nächstes müssen Sie ein zweites Projekt für Ihre Implementierung von IBM Blockchain Platformerstellen. Zum Erstellen eines Namensbereichs können Sie die Befehlszeilenschnittstelle "kubectl" verwenden. Der Namensbereich muss von einem Clusteradministrator erstellt werden.

Wenn Sie die Befehlszeilenschnittstelle verwenden, erstellen Sie einen neuen Namensbereich mithilfe des folgenden Befehls:

kubectl create namespace <NAMESPACE>

Ersetzen<NAMESPACE>durch den Namen, den Sie für Ihren IBM Blockchain Platform -Bereitstellungsnamensbereich verwenden möchten.

Es ist erforderlich, dass Sie einen Namensbereich für jedes Blockchain-Netz erstellen, das Sie mit IBM Blockchain Platformbereitstellen. Wenn Sie beispielsweise unterschiedliche Netze für Entwicklung, Staging und Produktion erstellen möchten, müssen Sie für jede Umgebung einen individuellen Namensbereich erstellen. Durch Verwendung eines separaten Namensbereichs erhält jedes Netz separate Ressourcen und sie ermöglicht das Definieren eindeutiger Zugriffsrichtlinien für jedes Netz. Sie müssen diese Bereitstellungsanweisungen befolgen, um einen separaten Operator und eine separate Konsole für jeden Namensbereich bereitzustellen.

Sie können auch die CLI verwenden, um die verfügbaren Speicherklassen für Ihren Namensbereich zu ermitteln. Wenn Sie eine neue Speicherklasse für Ihre Bereitstellung erstellt haben, muss diese Speicherklasse in der Ausgabe des folgenden Befehls erscheinen:

kubectl get storageclasses

Berechtigung für Ihre lokale Registry einrichten

Sie haben das Nutzungsrecht für eine lokale Registry bereits in deribpinfraNamensbereich oder Projekt, jetzt müssen Sie einen in Ihrem IBM Blockchain Platform -Namensbereich oder -Projekt erstellen. Nach dem Kauf von IBM Blockchain Platformkönnen Sie auf Dashboard 'My IBM ' zugreifen, um Ihren Berechtigungsschlüssel für das Angebot abzurufen. Sie müssen den Berechtigungsschlüssel in Ihrem Cluster speichern, indem Sie einen Geheimer Kubernetes-Schlüsselerstellen. Geheime Kubernetes-Schlüssel ermöglichen eine sichere Speicherung des Schlüssels in Ihrem Cluster und das Übergeben des Schlüssels an die Operator- und Konsolenbereitstellungen.

Führen Sie den folgenden Befehl aus, um den geheimen Schlüssel zu erstellen und zu Ihrem Namensbereich hinzuzufügen:

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>

Ersetzen<USER>mit Ihrem Benutzernamen
Ersetzen<EMAIL>mit Ihrer E-Mail-Adresse.
Ersetzen<LOCAL_REGISTRY_PASSWORD>mit dem Kennwort für Ihre Registry.
Ersetzen<LOCAL_REGISTRY>durch die URL Ihrer lokalen Registry.
Ersetzen<NAMESPACE>durch den Namen Ihres Projekts oder Namensbereichs.

Der Name des geheimen Schlüssels, den Sie erstellen, lautet:docker-key-secret. Dieser Wert wird vom Operator verwendet, um das Angebot in zukünftigen Schritten bereitzustellen. Wenn Sie den Namen eines von Ihnen erstellten geheimen Schlüssels ändern, müssen Sie den entsprechenden Namen auch in nachfolgenden Schritten ändern.

Sicherheits- und Zugriffsrichtlinien hinzufügen

Für IBM Blockchain Platform müssen Ihrem Namensbereich bestimmte Sicherheits-und Zugriffsrichtlinien hinzugefügt werden. Der Inhalt einer Gruppe von.yamlHier finden Sie Dateien, die Sie kopieren und bearbeiten können, um die Sicherheitsrichtlinien zu definieren. Sie müssen diese Dateien auf Ihrem lokalen System speichern und Sie anschließend mithilfe der Befehlszeilenschnittstelle "kubectl" zu Ihrem Namensbereich hinzufügen. Diese Schritte müssen von einem Clusteradministrator ausgeführt werden. Beachten Sie auch, dass der PeerinitunddindContainer, die bereitgestellt werden, müssen im privilegierten Modus ausgeführt werden.

Pod-Sicherheitsrichtlinie anwenden

Kopieren Sie das PodSecurityPolicy-Objekt unten und speichern Sie es auf Ihrem lokalen System alsibp-psp.yaml.

Wenn Sie Kubernetes v1.16 oder höherausführen, müssen Sie die Zeile ändern.apiVersion: extensions/v1beta1im folgenden PodSecurityPolicy-ObjektapiVersion: policy/v1beta1.

apiVersion: extensions/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:
  - '*'

Nach dem Speichern und Bearbeiten der Datei führen Sie die folgenden Befehle aus, um die Datei Ihrem Cluster und die Richtlinie Ihrem Namensbereich hinzuzufügen.

kubectl apply -f ibp-psp.yaml

Clusterrolle anwenden

Kopieren Sie den folgenden Text in eine Datei auf Ihrem lokalen System und speichern Sie die Datei unteribp-clusterrole.yaml. Diese Datei definiert die erforderliche Clusterrolle für die Podsicherheitsrichtlinie. Datei bearbeiten und ersetzen<NAMESPACE>durch den Namen Ihres IBM Blockchain Platform -Bereitstellungsnamensbereichs.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: <NAMESPACE>
rules:
- apiGroups:
  - extensions
  resourceNames:
  - ibm-blockchain-platform-psp
  resources:
  - podsecuritypolicies
  verbs:
  - use
- apiGroups:
  - "*"
  resources:
  - pods
  - pod/logs
  - services
  - endpoints
  - persistentvolumeclaims
  - persistentvolumes
  - events
  - configmaps
  - secrets
  - ingresses
  - roles
  - rolebindings
  - serviceaccounts
  - nodes
  verbs:
  - '*'
- apiGroups:
  - ""
  resources:
  - namespaces
  - nodes
  verbs:
  - 'get'
- apiGroups:
  - apiextensions.k8s.io
  resources:
  - customresourcedefinitions
  verbs:
  - get
- apiGroups:
  - apiextensions.k8s.io
  resources:
  - persistentvolumeclaims
  - persistentvolumes
  verbs:
  - '*'
- apiGroups:
  - ibp.com
  resources:
  - '*'
  - ibpservices
  - ibpcas
  - ibppeers
  - ibpfabproxies
  - ibporderers
  verbs:
  - '*'
- apiGroups:
  - ibp.com
  resources:
  - '*'
  verbs:
  - '*'
- apiGroups:
  - apps
  resources:
  - deployments
  - daemonsets
  - replicasets
  - statefulsets
  verbs:
  - '*'

Führen Sie nach dem Speichern und Bearbeiten der Datei die folgenden Befehle aus.

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

Ersetzen<NAMESPACE>durch den Namen Ihres IBM Blockchain Platform -Bereitstellungsnamensbereichs.

Clusterrollenbindung anwenden

Kopieren Sie den folgenden Text in eine Datei auf Ihrem lokalen System und speichern Sie die Datei unteribp-clusterrolebinding.yaml. Diese Datei definiert die Clusterrollenbindung. Datei bearbeiten und ersetzen<NAMESPACE>durch den Namen Ihres IBM Blockchain Platform -Bereitstellungsnamensbereichs.

kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: <NAMESPACE>
subjects:
- kind: ServiceAccount
  name: default
  namespace: <NAMESPACE>
roleRef:
  kind: ClusterRole
  name: <NAMESPACE>
  apiGroup: rbac.authorization.k8s.io

Führen Sie nach dem Speichern und Bearbeiten der Datei die folgenden Befehle aus.

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

Ersetzen<NAMESPACE>durch den Namen Ihres IBM Blockchain Platform -Bereitstellungsnamensbereichs.

Rollenbindung erstellen

Nachdem Sie die Richtlinien angewendet haben, müssen Sie Ihrem Servicekonto die erforderliche Berechtigungsstufe für die Bereitstellung der Konsole erteilen. Führen Sie den folgenden Befehl mit dem Namen Ihres Zielnamensbereichs aus:

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

IBM Blockchain Platform -Operator bereitstellen

IBM Blockchain Platform verwendet einen Operator, um die IBM Blockchain Platform -Konsole zu installieren. Um den Operator in Ihrem Cluster bereitzustellen, fügen Sie Ihrem Namensbereich eine angepasste Ressource hinzu. Verwenden Sie hierfür die Befehlszeilenschnittstelle "kubectl". Die angepasste Ressource extrahiert das Operatorimage aus der Docker-Registry und startet es in Ihrem Cluster.

Kopieren Sie den folgenden Text in eine Datei auf Ihrem lokalen System und speichern Sie die Datei unteribp-operator.yaml.

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"
        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
      containers:
        - name: ibp-operator
          image: <LOCAL_REGISTRY>/ibp-operator:2.5.0-20201001-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

Wenn Sie den Namen des geheimen Schlüssels für Docker-Schlüssel geändert haben, müssen Sie das Feldname: docker-key-secret.

Fügen Sie die angepasste Ressource anschließend mithilfe der Befehlszeilenschnittstelle "kubectl" zu Ihrem Namensbereich hinzu.

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

Ersetzen<NAMESPACE>durch den Namen Ihres IBM Blockchain Platform -Bereitstellungsnamensbereichs.

Sie können bestätigen, dass der Operator bereitgestellt wurde, indem Sie den folgenden Befehl ausführen:kubectl get deployment -n <NAMESPACE>. Wenn Ihre Operatorbereitstellung erfolgreich ist, werden die folgenden Tabellen mit vier Tabellen angezeigt: Die Bereitstellung des Operators dauert ca. eine Minute.

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

IBM Blockchain Platform-Konsole bereitstellen

Wenn der Operator in Ihrem Namensbereich ausgeführt wird, können Sie eine angepasste Ressource anwenden, um die IBM Blockchain Platform -Konsole in Ihrem Cluster zu starten. Anschließend können Sie über Ihren Browser auf die Konsole zugreifen. Sie können nur eine einzige Konsole pro Kubernetes-Namensbereich bereitstellen.

Speichern Sie die angepasste Ressourcendefinition unten alsibp-console.yamlauf Ihrem lokalen System.

apiVersion: ibp.com/v1alpha2
kind: IBPConsole
metadata:
  name: ibpconsole
spec:
  arch:
  - amd64
  license: accept
  serviceAccountName: default
  email: "<EMAIL>"
  password: "<PASSWORD>"
  registryURL: <LOCAL_REGISTRY>
  imagePullSecrets:
    - docker-key-secret
  networkinfo:
    domain: <DOMAIN>
  storage:
    console:
      class: default
      size: 10Gi

Sie müssen die Informationen zum externen Endpunkt der Konsole in deribp-console.yamlDatei:

Ersetzen<LOCAL_REGISTRY>durch die URL Ihrer lokalen Registry.
Ersetzen<DOMAIN>durch den Namen Ihrer Clusterdomäne. Sie müssen sicherstellen, dass diese Domäne auf die Lastausgleichsfunktion Ihres Clusters verweist.

Sie müssen außerdem den Benutzernamen und das Kennwort angeben, der bzw. das beim ersten Zugriff auf die Konsole verwendet wurde:

Ersetzen<EMAIL>durch die E-Mail-Adresse des Konsolenadministrators.
Ersetzen<PASSWORD>mit dem Kennwort Ihrer Wahl. Dieses Kennwort wird auch zum Standardkennwort der Konsole, bis es geändert wird.

Möglicherweise müssen Sie zusätzliche Änderungen in der Datei vornehmen, je nachdem, welche Auswahl Sie während des Bereitstellungsprozesses getroffen haben.

Wenn Sie den Namen Ihres geheimen Schlüssels für Docker-Schlüssel geändert haben, ändern Sie den entsprechenden Wert derimagePullSecrets:Feld.
Wenn Sie eine neue Speicherklasse für Ihr Netz erstellt haben, geben Sie die Speicherklasse, die Sie erstellt haben, für dieclass:Feld.

Da Sie den Befehl nur einmal ausführen können, sollten Sie die Datei Erweiterte Implementierungsoptionen überprüfen, falls Optionen für Ihre Konfiguration relevant sind, bevor Sie die Konsole installieren. Wenn Sie Ihre Konsole beispielsweise in einem Mehrzonencluster bereitstellen, müssen Sie diesen Cluster konfigurieren, bevor Sie den folgenden Schritt ausführen, um die Konsole zu installieren.

Nach der Aktualisierung der Datei können Sie die Konsole über die Befehlszeilenschnittstelle installieren.

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

Ersetzen<NAMESPACE>durch den Namen Ihres IBM Blockchain Platform -Bereitstellungsnamensbereichs. Vor dem Installieren der Konsole sollten Sie die erweiterten Bereitstellungsoptionen im nächsten Abschnitt prüfen. Die Bereitstellung der Konsole kann ein paar Minuten dauern.

Erweiterte Bereitstellungsoptionen

Sie können dieibp-console.yamlDatei, um Ihrer Konsole weitere Ressourcen zuzuordnen oder Zonen für Hochverfügbarkeit in einem Mehrzonencluster zu verwenden. Um diese Implementierungsoptionen zu nutzen, können Sie die Konsolenressourcendefinition mit derresources:undclusterdata:Abschnitte hinzugefügt:

apiVersion: ibp.com/v1alpha2
kind: IBPConsole
metadata:
  name: ibpconsole
spec:
  arch:
  - amd64
  license: accept
  serviceAccountName: default
  email: "<EMAIL>"
  password: "<PASSWORD>"
  registryURL: <LOCAL_REGISTRY>
  imagePullSecrets:
    - docker-key-secret
  networkinfo:
    domain: <DOMAIN>
  storage:
    console:
      class: default
      size: 10Gi
  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

Sie können dieresources:, um Ihrer Konsole weitere Ressourcen zuzuordnen. Die Werte in der Beispieldatei entsprechen den Standardwerten, die den einzelnen Containern zugeordnet sind. Wenn Sie Ihrer Konsole mehr Ressourcen zuordnen, können Sie eine größere Anzahl Knoten oder Kanäle betreiben. Sie können einer derzeit aktiven Konsole mehr Ressourcen zuordnen, indem Sie die Ressourcendatei bearbeiten und sie auf Ihren Cluster anwenden. Die Konsole wird erneut gestartet und kehrt zu ihrem vorherigen Status zurück; dadurch haben Sie die Möglichkeit, mit all Ihren bereits existierenden Knoten und Kanälen zu arbeiten.
```
 kubectl apply -f ibp-console.yaml -n <NAMESPACE>
```
Wenn Sie die Konsole mit einem Kubernetes-Cluster mit mehreren Zonen verwenden möchten, müssen Sie die Zonen zumclusterdata.zones:Abschnitt der Datei. Wenn Zonen in der Bereitstellung angegeben werden, können Sie die Zone, in der ein Knoten bereitgestellt wird, mithilfe der Konsole oder mithilfe der APIs auswählen. Wenn Sie beispielsweise in einem Cluster eine Bereitstellung in den Zonen "dal10", "dal12" und "dal13" vornehmen, würden Sie der Datei die Zonen mithilfe des untenstehenden Formats hinzufügen.
```
  clusterdata:
      zones:
        - dal10
        - dal12
        - dal13
```
Wenn Sie mit der Bearbeitung der Datei fertig sind, wenden Sie sie auf Ihren Cluster an.
```
 kubectl apply -f ibp-console.yaml -n <NAMESPACE>
```

Anders als bei der Ressourcenzuordnung können Sie einem aktiven Netz keine Zonen hinzufügen. Wenn Sie bereits eine Konsole bereitgestellt und sie für die Erstellung von Knoten in Ihrem Cluster verwendet haben, geht Ihre bisherige Arbeit verloren. Nach dem Konsolenneustart müssen Sie neue Knoten bereitstellen.

Eigene TLS-Zertifikate verwenden (optional)

Die IBM Blockchain Platform -Konsole verwendet TLS-Zertifikate, um die Kommunikation zwischen der Konsole und Ihren Blockchain-Knoten sowie zwischen der Konsole und Ihrem Browser zu schützen. Sie haben die Möglichkeit, eigene TLS-Zertifikate zu erstellen und mithilfe eines geheimen Kubernetes-Schlüssels für die Konsole bereitzustellen. Wenn Sie diesen Schritt überspringen, erstellt die Konsole ihre eigenen selbst signierten TLS-Zertifikate während der Bereitstellung.

Dieser Schritt muss ausgeführt werden, bevor die Konsole bereitgestellt wird.

Mithilfe einer Zertifizierungsstelle oder eines Tools können Sie die TLS-Zertifikate für die Konsole erstellen. Das TLS-Zertifikat muss den Hostnamen der Konsole und des Proxys im Betreffnamen oder die alternativen Domänennamen enthalten. Die Hostnamen von Konsole und Proxy weisen das folgende Format auf:

Hostname der Konsole:<NAMESPACE>-ibpconsole-console.<DOMAIN>Proxy-Hostname:<NAMESPACE>-ibpconsole-proxy.<DOMAIN>

Ersetzen<NAMESPACE>durch den Namen Ihres IBM Blockchain Platform -Bereitstellungsnamensbereichs.
Ersetzen<DOMAIN>durch den Namen Ihrer Clusterdomäne.

Navigieren Sie zu den TLS-Zertifikaten, die Sie in Ihrem lokalen System verwenden möchten. TLS-Zertifikat benennentlscert.pemund den entsprechenden privaten Schlüsseltlskey.pemFühren Sie den folgende Befehl aus, um den geheimen Kubernetes-Schlüssel zu erstellen und zu Ihrem Kubernetes-Namensbereich hinzuzufügen. Das TLS-Zertifikat und der TLS-Schlüssel müssen im PEM-Format vorliegen.

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

Nachdem Sie den geheimen Schlüssel erstellt haben, fügen Sie das folgende Feld zurspec:Abschnittibp-console.yamlmit einer hinzugefügten Einrückung auf derselben Ebene wie dieresources:undclusterdata:Abschnitte der erweiterten Implementierungsoptionen. Für dieses Feld müssen Sie den Namen des geheimen TLS-Schlüssels angeben, den Sie erstellt haben. Im folgenden Beispiel wird eine Konsole mit dem TLS-Zertifikat und dem Schlüssel bereitgestellt, die in einem geheimen Schlüssel mit dem Namen"console-tls-secret":

apiVersion: ibp.com/v1alpha2
kind: IBPConsole
metadata:
  name: ibpconsole
spec:
  arch:
  - amd64
  license: accept
  serviceAccountName: default
  email: "<EMAIL>"
  password: "<PASSWORD>"
  registryURL: <LOCAL_REGISTRY>
  imagePullSecrets:
    - docker-key-secret
  networkinfo:
        domain: <DOMAIN>
        consolePort: <CONSOLE_PORT>
        proxyPort: <PROXY_PORT>
  storage:
    console:
      class: default
      size: 10Gi
  tlsSecretName: "console-tls-secret"
  clusterdata:
    zones:
      - dal10
      - dal12
      - dal13

Nachdem Sie die Bearbeitung der Datei abgeschlossen haben, können Sie die Datei auf Ihren Cluster anwenden, um die Kommunikation durch Ihre eigenen TLS-Zertifikate zu schützen:

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

Installation der Konsole prüfen

Sie können bestätigen, dass der Operator bereitgestellt wurde, indem Sie den folgenden Befehl ausführen:kubectl get deployment -n <NAMESPACE>. Wenn Ihre Konsolenbereitstellung erfolgreich ist, können Sie sehen,ibpconsolezur Implementierungstabelle hinzugefügt, wobei vier angezeigt werden. Die Bereitstellung der Konsole dauert ein paar Minuten. Möglicherweise müssen Sie auf "Aktualisieren" klicken und warten, bis die Tabelle aktualisiert angezeigt wird.

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

Die Konsole besteht aus vier Containern, die in einem einzigen Pod bereitgestellt werden:

optools: Die Konsolenbenutzerschnittstelle.
deployer: Ein Tool, mit dem Ihre Konsole mit Ihren Bereitstellungen kommunizieren kann.
configtxlator: Ein Tool, mit dem die Konsole Kanalaktualisierungen lesen und erstellen kann.
couchdb: Eine Instanz von CouchDB, die die Daten aus Ihrer Konsole speichert, einschließlich Ihrer Berechtigungsinformationen.

Liegt ein Bereitstellungsfehler vor, können Sie die Protokolle aus einem einzelnen Container anzeigen. Zunächst führen Sie den folgenden Befehl aus, um den Namen des Konsolenpods abzurufen:

kubectl get pods -n <NAMESPACE>

Anschließend rufen Sie mit dem folgenden Befehl die Protokolle aus einem der vier Container in dem Pod ab:

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

Ein Befehl zum Abrufen der Protokolle aus dem UI-Container würde beispielsweise wie folgt aussehen:

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

Bei der Konsole anmelden

Sie können über Ihren Browser auf die Konsole zugreifen. Verwenden Sie hierfür die URL der Konsole:

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

Ersetzen<NAMESPACE>durch den Namen Ihres IBM Blockchain Platform -Bereitstellungsnamensbereichs.
Ersetzen<DOMAIN>durch den Namen Ihrer Clusterdomäne. Sie haben diesen Wert an dieDOMAIN:Feld deribp-console.yamlDatei.

Ihre Konsolen-URL hat das im folgenden Beispiel dargestellte Format:

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

Wenn Sie in Ihrem Browser die URL der Konsole aufrufen, gelangen Sie zur Anmeldeanzeige der Konsole:

Verwenden Sie für Benutzer-IDden Wert, den Sie für dieemail:Feld in deribp-console.yamlDatei.
Verwenden Sie für Passwortden Wert, den Sie für diepassword:Feld in deribp-console.yamlDatei. Dieses Kennwort wird als Standardkennwort für die Konsole festgelegt, das alle Benutzer zum Anmelden bei der Konsole verwenden. Nach dem ersten Anmeldevorgang werden Sie aufgefordert, ein neues Anmeldekennwort für die Konsole anzugeben.

Stellen Sie sicher, dass Sie nicht die ESR-Version von Firefox verwenden. Falls Sie diese Version doch verwenden, wechseln Sie zu einem anderen Browser, wie z. B. Chrome, und melden Sie sich an.

Der Administrator, der die Konsole bereitstellt, kann anderen Benutzern Zugriff gewähren und die Aktionen einschränken, die sie ausführen können. Weitere Informationen finden Sie unter Benutzer über die Konsole verwalten.

Nächste Schritte

Wenn Sie Ihre Konsole aufrufen, können Sie die Registerkarte Knoten der Konsolenbenutzerschnittstelle anzeigen. Über diese Anzeige können Sie Komponenten in dem Cluster bereitstellen, in dem Sie die Konsole bereitgestellt haben. Informationen zum Einstieg in die Konsole finden Sie im Lernprogramm zum Erstellen eines Netzes . Sie können diese Registerkarte auch verwenden, um Knoten zu steuern, die in anderen Clouds erstellt werden. Weitere Informationen finden Sie unter Knoten importieren.

Informationen zum Verwalten der Benutzer, die auf die Konsole zugreifen können, finden Sie in den Protokollen Ihrer Konsole und Ihrer Blockchain-Komponenten unter Konsole verwalten.

Hinweise zur Verwendung von Kubernetes-Distributionen

Bevor Sie versuchen, IBM Blockchain Platform in Azure Kubernetes Service, Amazon Web Services, Rancher, Amazon Elastic Kubernetes Serviceoder Google Kubernetes Engine zu installieren, sollten Sie die folgenden Schritte ausführen. Weitere Details finden Sie in der Dokumentation für Ihre Kubernetes-Distribution.

Stellen Sie sicher, dass vor dem Kubernetes-Cluster eine Lastausgleichsfunktion mit einer öffentlichen IP-Adresse konfiguriert ist.
Erstellen Sie für die IP-Adresse der Lastausgleichsfunktion einen DNS-Eintrag.
Erstellen Sie für die Lastausgleichsfunktion in DNS einen Platzhalterhosteintrag. Dieser Eintrag ist einDNS ADatensatz mit einem Platzhalterhost.

Angenommen, der DNS-Eintrag für die Lastausgleichsfunktion lautettest.example.comwürde der DNS-Eintrag wie folgt lauten:
```
*.test.example.com
```
Letztendlich wird dieser Eintrag wie folgt aufgelöst:
```
test.example.com
```
Nachdem dieser Hosteintrag konfiguriert wurde, sollten alle folgenden Beispiele in "test.example.com" aufgelöst werden:
```
console.test.example.com
peer.test.example.com
```
Sie könnennslookupum zu überprüfen, ob DNS ordnungsgemäß konfiguriert ist:
```
$ nslookup console.test.example.com
```
Der DNS-Eintrag für die Lastausgleichsfunktion sollte dann während der Installation von IBM Blockchain Platform als Domänenname verwendet werden.
Der NGINX-Ingress-Controller muss verwendet werden. Siehe die Installationshandbuch für Ingress-Controller , die für die meisten Kubernetes-Distributionen verwendet werden können.
Verwenden Sie die folgenden Anweisungen, um die Bereitstellung des NGINX-Ingress-Controllers zu bearbeiten, um ssl-passthrough zu aktivieren, oder lesen Sie den Abschnitt Kubernetes-Anweisungen.

Das folgende Beispiel bildet Ihre Installation möglicherweise nicht genau ab. Der Schlüssel besteht darin, die letzte Zeile sicherzustellen, diessl-passthroughist vorhanden.
```
/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
```
Überprüfen Sie, ob alle Pods aktiv sind, bevor Sie versuchen, IBM Blockchain Platformzu installieren.

Sie können jetzt Installation fortsetzen.

IBM Blockchain Platform 2.5 hinter einer Firewall implementieren

Wichtige Hinweise

Erforderliche Ressourcen

Browser

Speicher

Eigenen Berechtigungsschlüssel abrufen

Vorbereitende Schritte

IBM Blockchain Platform -Images extrahieren

Beim Kubernetes-Cluster anmelden

Erstellen Sie dieibpinfraNamensbereich für den Webhook

Berechtigung für Ihre lokale Registry einrichten

Webhook und angepasste Ressourcendefinitionen für den OpenShift-Cluster bereitstellen

1. Rollenbasierte Zugriffssteuerung (RBAC) für den Webhook konfigurieren

2. (NurOpenShift -Cluster) Sicherheitskontexteinschränkung anwenden

3. Webhook bereitstellen

deployment.yaml

service.yaml

4. Zertifikat extrahieren

5. Angepasste Ressourcendefinition für die Zertifizierungsstelle erstellen

6. Angepasste Ressourcendefinition für den Peer erstellen

7. Angepasste Ressourcendefinition für den Anordnungsknoten erstellen

8. Angepasste Ressourcendefinition für die Konsole erstellen

Neuen Namensbereich für Ihre IBM Blockchain Platform -Bereitstellung erstellen

Berechtigung für Ihre lokale Registry einrichten

Sicherheits- und Zugriffsrichtlinien hinzufügen

Pod-Sicherheitsrichtlinie anwenden

Clusterrolle anwenden

Clusterrollenbindung anwenden

Rollenbindung erstellen

IBM Blockchain Platform -Operator bereitstellen

IBM Blockchain Platform-Konsole bereitstellen

Erweiterte Bereitstellungsoptionen

Eigene TLS-Zertifikate verwenden (optional)

Installation der Konsole prüfen

Bei der Konsole anmelden

Nächste Schritte

Hinweise zur Verwendung von Kubernetes-Distributionen

Erstellen Sie die`ibpinfra`Namensbereich für den Webhook