Prerequisiti
Requisiti della workstation, tool e accessi richiesti, dipendenze del cluster OpenShift e configurazione LLM necessari prima di installare IBM Bob on-premises.
Per installare IBM Bob on-premises, è necessaria una workstation amministrativa dedicata con connettività di rete al cluster OpenShift. La workstation deve avere i tool CLI richiesti installati e l'accesso per scaricare il release bundle di Bob e gli asset di deployment associati.
Scaricare il release bundle di Bob
Prima di iniziare, assicurati di avere:
- Un entitlement IBM Bob on-premises valido.
- Accesso a IBM Passport Advantage per scaricare il release bundle IBM Bob.
- Accesso all'IBM Entitled Container Registry (
cp.icr.io) per ottenere le immagini container con entitlement. - Una workstation amministrativa con connettività di rete al cluster OpenShift di destinazione.
Il release bundle contiene i manifest Kubernetes, i Helm chart, i template di configurazione e lo script di installazione bobctl necessari per il deployment.
Ottieni il release bundle da una delle seguenti fonti:
- Open VSX Registry — usa questa opzione per scaricare asset client Bob disponibili pubblicamente, estensioni e pacchetti di supporto.
- Passport Advantage — usa questa opzione per scaricare release bundle Bob con entitlement e asset di installazione associati al tuo contratto di licenza IBM.
La tabella seguente descrive gli asset di installazione e i relativi canali di distribuzione.
| Componente | Descrizione | Canale di distribuzione |
|---|---|---|
| Release bundle Bob | Manifest di deployment, Helm chart, template di configurazione e script di installazione | IBM Passport Advantage |
| Immagini container backend Bob | Servizi di runtime deployati nel cluster OpenShift | IBM Entitled Container Registry (cp.icr.io) |
| Estensioni e add-on Bob IDE | Integrazioni IDE e componenti opzionali lato client | Open VSX Registry |
Il release bundle non contiene le immagini container backend. Prima di avviare l'installazione, ottieni separatamente sia il release bundle che le immagini container corrispondenti.
Dopo aver scaricato il release bundle, estrai l'archivio e naviga nella directory di release:
tar -xvf ibm-bob-bundle-<version>.tar.gz
cd ibm-bob-bundle/releaseLa directory di release estratta contiene i file e gli script necessari per configurare e deployare IBM Bob on-premises.
Tool richiesti sulla workstation
Assicurati che la tua workstation abbia i seguenti tool installati e disponibili nel PATH di sistema prima di installare il release bundle. Questi tool vengono utilizzati durante tutto il ciclo di vita di installazione, configurazione e gestione.
| Tool | Versione | Scopo |
|---|---|---|
bobctl | Incluso nel release bundle (./bobctl) | CLI Bob principale usata per installare, configurare, aggiornare e gestire il deployment. Esegui dalla directory release/ come ./bobctl. |
oc | Compatibile con la versione del tuo cluster OCP (minimo OCP 4.20) | CLI OpenShift usata per autenticarsi e gestire il cluster di destinazione. La versione del client oc dovrebbe corrispondere, o essere entro una minor version, alla versione del cluster. |
helm | 3.14.0 o successivo | Package manager Kubernetes usato da bobctl durante le operazioni di deployment e configurazione. |
bash | 3.2 o successivo | Interprete shell richiesto per eseguire bobctl e gli script di supporto. Deve essere disponibile nel $PATH come bash. Su macOS, dove zsh è la shell predefinita, installa bash (ad esempio, con brew install bash) e assicurati che sia accessibile dal $PATH. |
openssl | 3.5 o successivo (o la versione fornita dal sistema operativo) | Usato per operazioni relative ai certificati inclusi bobctl get-ca-cert, setup-route e reset-route. Deve essere disponibile nel $PATH. |
Esegui i seguenti comandi per verificare che tutti i tool siano installati e accessibili:
bobctl --help
oc version
helm version
bash --version
openssl versionAssicurati che ogni comando venga completato correttamente prima di procedere con l'installazione.
Accesso e permessi
Assicurati di avere il seguente accesso e le seguenti autorizzazioni prima di avviare l'installazione.
| Requisito | Descrizione |
|---|---|
| Accesso GitHub | Accesso per scaricare il release bundle di Bob dal repository IBM Bob. |
| Permessi cluster | Privilegi cluster-admin, o permessi RBAC equivalenti, sul cluster OpenShift di destinazione. |
| Entitlement IBM Container Registry | Accesso a IBM Container Registry (cp.icr.io o icr.io) e le credenziali di entitlement necessarie per estrarre le immagini container Bob. |
| Risorse cluster | Capacità sufficiente di CPU, memoria, storage e nodi worker per supportare Bob e gli eventuali componenti opzionali che intendi deployare. Vedere Cluster sizing. |
Prima dell'installazione, verifica di poter:
- Scaricare il release bundle di Bob.
- Autenticarti al cluster OpenShift di destinazione.
- Accedere a IBM Container Registry ed estrarre immagini container.
- Creare e gestire risorse cluster-scoped usando un account con privilegi
cluster-admin. - Allocare le risorse di calcolo, storage e rete richieste per il deployment.
Controllo degli accessi basato sui ruoli (RBAC) e separazione dei permessi
Il release bundle di Bob separa le risorse cluster-scoped dalle risorse namespace-scoped. Questo design consente agli amministratori della sicurezza e della piattaforma di esaminare e approvare le risorse a livello di cluster indipendentemente dall'operator Bob e dal deployment dell'applicazione.
Bob usa due namespace:
| Namespace | Scopo |
|---|---|
| Namespace operatore | Ospita l'ibm-bob-operator, che gestisce il ciclo di vita Bob e i processi di riconciliazione. |
| Namespace operand | Ospita i workload dell'applicazione Bob, inclusi servizi, pod e componenti di supporto gestiti dall'operator. |
Entrambi i namespace vengono creati e gestiti da bobctl install. Tutte le risorse RBAC create durante l'installazione — inclusi gli oggetti Role, RoleBinding e ServiceAccount — sono limitate a questi due namespace.
Struttura del release bundle
Il release bundle è organizzato in componenti cluster-scoped e namespace-scoped separati.
| Directory | Scope | Contenuti |
|---|---|---|
ibm-bob-cluster-scoped/ | Cluster-scoped | Custom resource definition (CRD), ClusterRole, ClusterRoleBinding e altre risorse a livello di cluster che richiedono revisione e approvazione amministrativa. |
ibm-bob/ | Namespace-scoped | Deployment dell'operator, risorse RBAC a livello di namespace, service account e workload dell'applicazione Bob. |
Workflow di installazione
Deploya Bob usando il seguente processo in due fasi:
| Fase | Azione | Scope | Privilegi richiesti |
|---|---|---|---|
| 1 | Genera e applica le risorse cluster-scoped | Cluster-wide | cluster-admin, o un ruolo con permessi per creare CRD, ClusterRole e risorse ClusterRoleBinding |
| 2 | Esegui bobctl install | Solo namespace operatore e operand | Permessi di amministratore di namespace sui namespace di destinazione |
Genera e applica le risorse cluster-scoped:
./bobctl generate-cluster-resources
oc apply -f work/cluster-resources.yamlIl file work/cluster-resources.yaml generato contiene solo le risorse cluster-scoped dalla directory ibm-bob-cluster-scoped/. Dopo che le risorse cluster-scoped sono state applicate, bobctl install viene eseguito interamente all'interno dei due namespace Bob e non richiede ulteriori privilegi a livello di cluster.
IBM raccomanda che un amministratore del cluster o un team di sicurezza esamini il file work/cluster-resources.yaml generato prima di applicarlo al cluster. Le risorse deployate dalla directory ibm-bob/ non richiedono una revisione separata della sicurezza a livello di cluster perché tutti i permessi RBAC sono limitati ai namespace operatore e operand.
Prerequisiti del cluster
Prima di installare Bob, assicurati che il cluster OpenShift di destinazione soddisfi i seguenti prerequisiti software, di connettività e di servizio.
Installare cert-manager
Bob usa cert-manager v1.14 o successivo per emettere e gestire i certificati TLS per i componenti in esecuzione nel cluster. Installa e valida cert-manager prima del deployment.
Cosa succede se cert-manager è assente?
Il comando bobctl install verifica la presenza dei CRD di cert-manager all'avvio. Se cert-manager non è installato o i CRD richiesti non possono essere trovati, l'installazione termina immediatamente con un messaggio di errore chiaro e non viene eseguita alcuna azione di deployment.
Installa cert-manager usando una delle seguenti opzioni:
Opzione 1: Red Hat cert-manager Operator per OpenShift (consigliato)
Installa il Red Hat cert-manager Operator per OpenShift da OperatorHub usando il canale stable-v1. Questo è consigliato per gli ambienti OpenShift perché è supportato e mantenuto attraverso il ciclo di vita degli operator OpenShift. Per istruzioni, vedere cert-manager Operator for Red Hat OpenShift.
Opzione 2: cert-manager upstream
Installa la release upstream di cert-manager usando Helm chart o manifest Kubernetes. Assicurati che la versione deployata sia v1.14 o successiva. Per istruzioni, vedere cert-manager Installation.
Se cert-manager è già installato sul cluster alla versione v1.14 o successiva, può essere riutilizzato — non è richiesta alcuna installazione aggiuntiva.
Verifica che cert-manager sia installato e in buono stato:
# Verifica che tutti i pod cert-manager siano in esecuzione
oc get pods -n cert-manager
# Verifica che esistano i CRD cert-manager richiesti
oc get crd | grep cert-manager.ioUna validazione riuscita mostra i pod controller cert-manager nello stato Running e i CRD core di cert-manager presenti nel cluster.
Provisioning e configurazione di un large language model
Bob on-premises richiede l'accesso a uno o più large language model (LLM) supportati. Bob gestisce la connessione all'endpoint del modello, ma il provisioning, l'hosting, lo scaling e la manutenzione dell'infrastruttura del modello esulano dallo scope dell'installazione core di Bob.
Configura i seguenti endpoint del modello prima dell'installazione:
- Modello di inference core — elabora le richieste degli utenti e genera risposte. Deploya un modello supportato dall'elenco dei modelli di inference approvati (ad esempio, Mistral 3.5).
- Modello guardrail — applica controlli di sicurezza, policy e content-governance alle richieste e alle risposte. Deploya un modello guardrail per la moderazione di richieste e risposte (ad esempio,
openai/gpt-oss-20b).
Per ulteriori informazioni sulla configurazione del modello, vedere Configurazione del model gateway.
Assicurati che il backend Bob e i servizi modello configurati possano comunicare sulla rete. Verifica che firewall, network policy, security group, proxy e regole di routing consentano il traffico tra il cluster OpenShift e gli endpoint del modello prima di procedere con l'installazione.
Bob non fornisce funzionalità di registrazione degli eventi di sicurezza. Sei responsabile della configurazione della registrazione della sicurezza, della registrazione dell'audit e del monitoraggio tramite OpenShift e qualsiasi strumento di sicurezza enterprise associato.