Voraussetzungen
Workstation-Anforderungen, erforderliche Tools und Zugriff, OpenShift-Cluster-Abhängigkeiten und LLM-Konfiguration, die vor der Installation von IBM Bob On-Premises erforderlich sind.
Um IBM Bob On-Premises zu installieren, benötigst du eine dedizierte administrative Workstation mit Netzwerkkonnektivität zum OpenShift-Cluster. Die Workstation muss über die erforderlichen CLI-Tools verfügen und Zugriff haben, um das Bob-Release-Bundle und die zugehörigen Deployment-Assets herunterzuladen.
Bob-Release-Bundle herunterladen
Stelle vor Beginn sicher, dass du über Folgendes verfügst:
- Eine gültige Berechtigung für IBM Bob On-Premises.
- Zugriff auf IBM Passport Advantage zum Herunterladen des IBM Bob-Release-Bundles.
- Zugriff auf die IBM Entitled Container Registry (
cp.icr.io), um berechtigte Container-Images zu erhalten. - Eine administrative Workstation mit Netzwerkkonnektivität zum Ziel-OpenShift-Cluster.
Das Release-Bundle enthält die Kubernetes-Manifeste, Helm-Charts, Konfigurationsvorlagen und das bobctl-Installationsskript, das für das Deployment erforderlich ist.
Beziehe das Release-Bundle aus einer der folgenden Quellen:
- Open VSX Registry — verwende diese Option zum Herunterladen öffentlich verfügbarer Bob-Client-Assets, -Erweiterungen und unterstützender Pakete.
- Passport Advantage — verwende diese Option zum Herunterladen berechtigter Bob-Release-Bundles und Installations-Assets, die mit deiner IBM Lizenzvereinbarung verknüpft sind.
Die folgende Tabelle beschreibt die Installations-Assets und ihre Distributionskanäle.
| Komponente | Beschreibung | Distributionskanal |
|---|---|---|
| Bob-Release-Bundle | Deployment-Manifeste, Helm-Charts, Konfigurationsvorlagen und Installationsskripte | IBM Passport Advantage |
| Bob-Backend-Container-Images | Runtime-Services, die im OpenShift-Cluster deployed werden | IBM Entitled Container Registry (cp.icr.io) |
| Bob-IDE-Erweiterungen und -Add-ons | IDE-Integrationen und optionale clientseitige Komponenten | Open VSX Registry |
Das Release-Bundle enthält nicht die Backend-Container-Images. Beziehe vor Beginn der Installation sowohl das Release-Bundle als auch die entsprechenden Container-Images separat.
Extrahiere nach dem Herunterladen des Release-Bundles das Archiv und navigiere zum Release-Verzeichnis:
tar -xvf ibm-bob-bundle-<version>.tar.gz
cd ibm-bob-bundle/releaseDas extrahierte Release-Verzeichnis enthält die Dateien und Skripte, die zum Konfigurieren und Deployen von IBM Bob On-Premises erforderlich sind.
Erforderliche Workstation-Tools
Stelle sicher, dass auf deiner Workstation die folgenden Tools installiert und im System-PATH verfügbar sind, bevor du das Release-Bundle installierst. Diese Tools werden während des gesamten Installations-, Konfigurations- und Management-Lifecycles verwendet.
| Tool | Version | Zweck |
|---|---|---|
bobctl | Im Release-Bundle enthalten (./bobctl) | Primäre Bob-CLI, die zum Installieren, Konfigurieren, Aktualisieren und Verwalten des Deployments verwendet wird. Wird aus dem release/-Verzeichnis als ./bobctl ausgeführt. |
oc | Kompatibel mit deiner OCP-Cluster-Version (mindestens OCP 4.20) | OpenShift-CLI, die zur Authentifizierung bei und Verwaltung des Zielclusters verwendet wird. Die oc-Client-Version sollte mit der Cluster-Version übereinstimmen oder innerhalb einer Minor-Version liegen. |
helm | 3.14.0 oder neuer | Kubernetes-Paketmanager, der von bobctl während Deployment- und Konfigurationsoperationen verwendet wird. |
bash | 3.2 oder neuer | Shell-Interpreter, der zum Ausführen von bobctl und unterstützenden Skripten erforderlich ist. Muss als bash in $PATH verfügbar sein. Auf macOS, wo zsh die Standard-Shell ist, installiere bash (z. B. mit brew install bash) und stelle sicher, dass es von $PATH aus zugänglich ist. |
openssl | 3.5 oder neuer (oder die vom Betriebssystem bereitgestellte Version) | Wird für zertifikatsbezogene Operationen verwendet, einschließlich bobctl get-ca-cert, setup-route und reset-route. Muss in $PATH verfügbar sein. |
Führe die folgenden Befehle aus, um zu überprüfen, ob alle Tools installiert und zugänglich sind:
bobctl --help
oc version
helm version
bash --version
openssl versionStelle sicher, dass jeder Befehl erfolgreich abgeschlossen wird, bevor du mit der Installation fortfährst.
Zugriff und Berechtigungen
Stelle sicher, dass du über den folgenden Zugriff und die folgenden Berechtigungen verfügst, bevor du mit der Installation beginnst.
| Anforderung | Beschreibung |
|---|---|
| GitHub-Zugriff | Zugriff zum Herunterladen des Bob-Release-Bundles aus dem IBM-Bob-Repository. |
| Cluster-Berechtigungen | cluster-admin-Berechtigungen oder gleichwertige RBAC-Berechtigungen auf dem Ziel-OpenShift-Cluster. |
| IBM Container Registry Berechtigung | Zugriff auf die IBM Container Registry (cp.icr.io oder icr.io) und die erforderlichen Berechtigungsnachweise zum Abrufen von Bob-Container-Images. |
| Cluster-Ressourcen | Ausreichend CPU, Memory, Storage und Worker-Node-Kapazität zur Unterstützung von Bob und optionaler Komponenten, die du deployen möchtest. Siehe Cluster-Dimensionierung. |
Bestätige vor der Installation, dass du folgendes kannst:
- Das Bob-Release-Bundle herunterladen.
- Dich beim Ziel-OpenShift-Cluster authentifizieren.
- Auf die IBM Container Registry zugreifen und Container-Images abrufen.
- Cluster-weite Ressourcen mit einem Konto mit
cluster-admin-Berechtigungen erstellen und verwalten. - Die erforderlichen Compute-, Storage- und Netzwerkressourcen für das Deployment zuweisen.
Rollenbasierte Zugriffskontrolle (RBAC) und Berechtigungstrennung
Das Bob-Release-Bundle trennt clusterweite Ressourcen von ressourcenbezogenen Namespaces. Dieses Design ermöglicht es Sicherheits- und Plattformadministratoren, clusterweite Ressourcen unabhängig vom Bob-Operator und dem Anwendungs-Deployment zu überprüfen und zu genehmigen.
Bob verwendet zwei Namespaces:
| Namespace | Zweck |
|---|---|
| Operator-Namespace | Hostet den ibm-bob-operator, der den Bob-Lifecycle und die Abgleichprozesse verwaltet. |
| Operand-Namespace | Hostet die Bob-Anwendungs-Workloads, einschließlich Services, Pods und unterstützender Komponenten, die vom Operator verwaltet werden. |
Beide Namespaces werden von bobctl install erstellt und verwaltet. Alle während der Installation erstellten RBAC-Ressourcen — einschließlich Role-, RoleBinding- und ServiceAccount-Objekten — sind auf diese beiden Namespaces beschränkt.
Struktur des Release-Bundles
Das Release-Bundle ist in separate clusterweite und namespacebezogene Komponenten gegliedert.
| Verzeichnis | Bereich | Inhalt |
|---|---|---|
ibm-bob-cluster-scoped/ | Clusterweit | Custom Resource Definitions (CRDs), ClusterRole, ClusterRoleBinding und andere clusterweite Ressourcen, die eine administrative Überprüfung und Genehmigung erfordern. |
ibm-bob/ | Namespacebezogen | Operator-Deployment, RBAC-Ressourcen auf Namespace-Ebene, Service-Accounts und Bob-Anwendungs-Workloads. |
Installations-Workflow
Deploye Bob mit dem folgenden zweistufigen Prozess:
| Schritt | Aktion | Bereich | Erforderliche Berechtigungen |
|---|---|---|---|
| 1 | Clusterweite Ressourcen generieren und anwenden | Clusterweit | cluster-admin oder eine Rolle mit Berechtigungen zum Erstellen von CRDs, ClusterRole- und ClusterRoleBinding-Ressourcen |
| 2 | bobctl install ausführen | Nur Operator- und Operand-Namespaces | Namespace-Administratorberechtigungen auf den Ziel-Namespaces |
Generiere und wende die clusterweiten Ressourcen an:
./bobctl generate-cluster-resources
oc apply -f work/cluster-resources.yamlDie generierte Datei work/cluster-resources.yaml enthält nur die clusterweiten Ressourcen aus dem Verzeichnis ibm-bob-cluster-scoped/. Nachdem die clusterweiten Ressourcen angewendet wurden, wird bobctl install vollständig innerhalb der beiden Bob-Namespaces ausgeführt und erfordert keine zusätzlichen clusterweiten Berechtigungen.
IBM empfiehlt, dass ein Cluster-Administrator oder ein Sicherheitsteam die generierte Datei work/cluster-resources.yaml überprüft, bevor sie auf den Cluster angewendet wird. Die aus dem Verzeichnis ibm-bob/ deployten Ressourcen erfordern keine separate Sicherheitsüberprüfung auf Clusterebene, da alle RBAC-Berechtigungen auf die Operator- und Operand-Namespaces beschränkt sind.
Cluster-Voraussetzungen
Stelle vor der Installation von Bob sicher, dass der Ziel-OpenShift-Cluster die folgenden Software-, Konnektivitäts- und Service-Voraussetzungen erfüllt.
cert-manager installieren
Bob verwendet cert-manager v1.14 oder neuer, um TLS-Zertifikate für Komponenten auszustellen und zu verwalten, die im Cluster ausgeführt werden. Installiere und validiere cert-manager vor dem Deployment.
Was passiert, wenn cert-manager fehlt?
Der Befehl bobctl install überprüft beim Start das Vorhandensein von cert-manager-CRDs. Wenn cert-manager nicht installiert ist oder die erforderlichen CRDs nicht gefunden werden können, wird die Installation sofort mit einer klaren Fehlermeldung beendet und es werden keine Deployment-Aktionen durchgeführt.
Installiere cert-manager mit einer der folgenden Optionen:
Option 1: Red Hat cert-manager Operator für OpenShift (empfohlen)
Installiere den Red Hat cert-manager Operator für OpenShift aus OperatorHub mit dem stable-v1-Kanal. Dies wird für OpenShift-Umgebungen empfohlen, da er durch den OpenShift-Operator-Lifecycle unterstützt und gepflegt wird. Anleitungen findest du unter cert-manager Operator for Red Hat OpenShift.
Option 2: Upstream cert-manager
Installiere das Upstream-cert-manager-Release mit Helm-Charts oder Kubernetes-Manifesten. Stelle sicher, dass die deployete Version v1.14 oder neuer ist. Anleitungen findest du unter cert-manager Installation.
Wenn cert-manager bereits auf dem Cluster in Version v1.14 oder neuer installiert ist, kann es wiederverwendet werden — keine zusätzliche Installation ist erforderlich.
Überprüfe, ob cert-manager installiert und fehlerfrei ist:
# Überprüfe, ob alle cert-manager-Pods laufen
oc get pods -n cert-manager
# Überprüfe, ob die erforderlichen cert-manager-CRDs vorhanden sind
oc get crd | grep cert-manager.ioEine erfolgreiche Validierung zeigt die cert-manager-Controller-Pods im Running-Zustand und die wichtigsten cert-manager-CRDs auf dem Cluster.
Ein Large Language Model bereitstellen und konfigurieren
Bob On-Premises erfordert Zugriff auf ein oder mehrere unterstützte Large Language Models (LLMs). Bob verwaltet die Verbindung zum Model-Endpoint, aber das Bereitstellen, Hosten, Skalieren und Warten der Modellinfrastruktur liegt außerhalb des Umfangs der Bob-Core-Installation.
Konfiguriere die folgenden Model-Endpoints vor der Installation:
- Core-Inferenz-Modell — verarbeitet Benutzeranfragen und generiert Antworten. Deploye ein unterstütztes Modell aus der zugelassenen Inferenz-Modellliste (z. B. Mistral 3.5).
- Guardrail-Modell — wendet Sicherheits-, Richtlinien- und Content-Governance-Prüfungen auf Anfragen und Antworten an. Deploye ein Guardrail-Modell für die Anfrage- und Antwortmoderation (z. B.
openai/gpt-oss-20b).
Weitere Informationen zur Modellkonfiguration findest du unter Model-Gateway-Konfiguration.
Stelle sicher, dass das Bob-Backend und die konfigurierten Modell-Services über das Netzwerk kommunizieren können. Überprüfe, ob Firewalls, Netzwerkrichtlinien, Sicherheitsgruppen, Proxies und Routing-Regeln Traffic zwischen dem OpenShift-Cluster und den Model-Endpoints erlauben, bevor du mit der Installation fortfährst.
Bob bietet keine Funktionen für das Logging von Sicherheitsereignissen. Du bist dafür verantwortlich, Sicherheitslogging, Audit-Logging und Überwachung über OpenShift und zugehörige Unternehmenssicherheitstools zu konfigurieren.