Prérequis
Exigences du poste de travail, outils et accès requis, dépendances du cluster OpenShift, et configuration LLM nécessaires avant d'installer IBM Bob on-premises.
Pour installer IBM Bob on-premises, vous avez besoin d'un poste de travail administratif dédié avec une connectivité réseau vers le cluster OpenShift. Le poste de travail doit avoir les outils CLI requis installés et l'accès pour télécharger le bundle de version Bob et les ressources de déploiement associées.
Télécharger le bundle de version Bob
Avant de commencer, assurez-vous de disposer des éléments suivants :
- Un droit IBM Bob on-premises valide.
- L'accès à IBM Passport Advantage pour télécharger le bundle de version IBM Bob.
- L'accès à IBM Entitled Container Registry (
cp.icr.io) pour obtenir les images de conteneurs auxquelles vous avez droit. - Un poste de travail administratif avec une connectivité réseau vers le cluster OpenShift cible.
Le bundle de version contient les manifestes Kubernetes, les charts Helm, les modèles de configuration et le script d'installation bobctl requis pour le déploiement.
Obtenez le bundle de version à partir de l'une des sources suivantes :
- Open VSX Registry — utilisez cette option pour télécharger les ressources client Bob publiquement disponibles, les extensions et les packages de support.
- Passport Advantage — utilisez cette option pour télécharger les bundles de version Bob auxquels vous avez droit et les ressources d'installation associées à votre contrat de licence IBM.
Le tableau suivant décrit les ressources d'installation et leurs canaux de distribution.
| Composant | Description | Canal de distribution |
|---|---|---|
| Bundle de version Bob | Manifestes de déploiement, charts Helm, modèles de configuration et scripts d'installation | IBM Passport Advantage |
| Images de conteneurs backend Bob | Services d'exécution déployés sur le cluster OpenShift | IBM Entitled Container Registry (cp.icr.io) |
| Extensions et add-ons Bob IDE | Intégrations IDE et composants client optionnels | Open VSX Registry |
Le bundle de version ne contient pas les images de conteneurs backend. Avant de démarrer l'installation, obtenez séparément le bundle de version et les images de conteneurs correspondantes.
Après avoir téléchargé le bundle de version, extrayez l'archive et accédez au répertoire de version :
tar -xvf ibm-bob-bundle-<version>.tar.gz
cd ibm-bob-bundle/releaseLe répertoire de version extrait contient les fichiers et scripts requis pour configurer et déployer IBM Bob on-premises.
Outils requis sur le poste de travail
Assurez-vous que votre poste de travail dispose des outils suivants installés et disponibles dans le PATH système avant d'installer le bundle de version. Ces outils sont utilisés tout au long du cycle de vie d'installation, de configuration et de gestion.
| Outil | Version | Objectif |
|---|---|---|
bobctl | Inclus dans le bundle de version (./bobctl) | CLI Bob principal utilisé pour installer, configurer, mettre à jour et gérer le déploiement. À exécuter depuis le répertoire release/ avec ./bobctl. |
oc | Compatible avec la version de votre cluster OCP (minimum OCP 4.20) | CLI OpenShift utilisé pour s'authentifier et gérer le cluster cible. La version du client oc doit correspondre, ou être dans une version mineure, de la version du cluster. |
helm | 3.14.0 ou ultérieur | Gestionnaire de packages Kubernetes utilisé par bobctl lors des opérations de déploiement et de configuration. |
bash | 3.2 ou ultérieur | Interpréteur de commandes requis pour exécuter bobctl et les scripts de support. Doit être disponible dans $PATH en tant que bash. Sur macOS, où zsh est le shell par défaut, installez bash (par exemple avec brew install bash) et assurez-vous qu'il est accessible depuis $PATH. |
openssl | 3.5 ou ultérieur (ou la version fournie par le système d'exploitation) | Utilisé pour les opérations liées aux certificats, notamment bobctl get-ca-cert, setup-route et reset-route. Doit être disponible dans $PATH. |
Exécutez les commandes suivantes pour vérifier que tous les outils sont installés et accessibles :
bobctl --help
oc version
helm version
bash --version
openssl versionAssurez-vous que chaque commande se termine avec succès avant de procéder à l'installation.
Accès et permissions
Assurez-vous de disposer des accès et permissions suivants avant de démarrer l'installation.
| Exigence | Description |
|---|---|
| Accès GitHub | Accès pour télécharger le bundle de version Bob depuis le référentiel IBM Bob. |
| Permissions de cluster | Privilèges cluster-admin, ou permissions RBAC équivalentes, sur le cluster OpenShift cible. |
| Droit d'accès à IBM Container Registry | Accès à IBM Container Registry (cp.icr.io ou icr.io) et les credentials d'autorisation requis pour extraire les images de conteneurs Bob. |
| Ressources du cluster | CPU, mémoire, stockage et capacité de nœuds de travail suffisants pour prendre en charge Bob et les composants optionnels que vous prévoyez de déployer. Voir Dimensionnement du cluster. |
Avant l'installation, confirmez que vous pouvez :
- Télécharger le bundle de version Bob.
- S'authentifier sur le cluster OpenShift cible.
- Accéder à IBM Container Registry et extraire des images de conteneurs.
- Créer et gérer des ressources à portée cluster avec un compte disposant de privilèges
cluster-admin. - Allouer les ressources de calcul, de stockage et de réseau requises pour le déploiement.
Contrôle d'accès basé sur les rôles (RBAC) et séparation des permissions
Le bundle de version Bob sépare les ressources à portée cluster des ressources à portée namespace. Cette conception permet aux administrateurs de sécurité et de plateforme d'examiner et d'approuver les ressources à portée cluster indépendamment de l'opérateur Bob et du déploiement de l'application.
Bob utilise deux namespaces :
| Namespace | Objectif |
|---|---|
| Namespace de l'opérateur | Héberge l'ibm-bob-operator, qui gère le cycle de vie de Bob et les processus de réconciliation. |
| Namespace de l'opérande | Héberge les charges de travail de l'application Bob, notamment les services, les pods et les composants de support gérés par l'opérateur. |
Les deux namespaces sont créés et gérés par bobctl install. Toutes les ressources RBAC créées lors de l'installation — y compris les objets Role, RoleBinding et ServiceAccount — sont limitées à ces deux namespaces.
Structure du bundle de version
Le bundle de version est organisé en composants séparés à portée cluster et à portée namespace.
| Répertoire | Portée | Contenu |
|---|---|---|
ibm-bob-cluster-scoped/ | Portée cluster | Définitions de ressources personnalisées (CRDs), ClusterRole, ClusterRoleBinding, et autres ressources à portée cluster nécessitant un examen et une approbation administratifs. |
ibm-bob/ | Portée namespace | Déploiement de l'opérateur, ressources RBAC au niveau du namespace, comptes de service et charges de travail de l'application Bob. |
Processus d'installation
Déployez Bob selon le processus en deux étapes suivant :
| Étape | Action | Portée | Privilèges requis |
|---|---|---|---|
| 1 | Générer et appliquer les ressources à portée cluster | À l'échelle du cluster | cluster-admin, ou un rôle avec les permissions pour créer des CRDs, ClusterRole et ClusterRoleBinding |
| 2 | Exécuter bobctl install | Namespaces de l'opérateur et de l'opérande uniquement | Permissions d'administrateur de namespace sur les namespaces cibles |
Générez et appliquez les ressources à portée cluster :
./bobctl generate-cluster-resources
oc apply -f work/cluster-resources.yamlLe fichier work/cluster-resources.yaml généré contient uniquement les ressources à portée cluster issues du répertoire ibm-bob-cluster-scoped/. Une fois les ressources à portée cluster appliquées, bobctl install s'exécute entièrement dans les deux namespaces Bob et ne nécessite pas de privilèges supplémentaires à l'échelle du cluster.
IBM recommande qu'un administrateur de cluster ou une équipe de sécurité examine le fichier work/cluster-resources.yaml généré avant de l'appliquer au cluster. Les ressources déployées depuis le répertoire ibm-bob/ ne nécessitent pas d'examen de sécurité distinct au niveau du cluster, car toutes les permissions RBAC sont limitées aux namespaces de l'opérateur et de l'opérande.
Prérequis du cluster
Avant d'installer Bob, assurez-vous que le cluster OpenShift cible satisfait aux prérequis logiciels, de connectivité et de service suivants.
Installer cert-manager
Bob utilise cert-manager v1.14 ou ultérieur pour émettre et gérer les certificats TLS pour les composants s'exécutant dans le cluster. Installez et validez cert-manager avant le déploiement.
Que se passe-t-il si cert-manager est manquant ?
La commande bobctl install valide la présence des CRDs cert-manager au démarrage. Si cert-manager n'est pas installé ou si les CRDs requis sont introuvables, l'installation se termine immédiatement avec un message d'erreur clair et aucune action de déploiement n'est effectuée.
Installez cert-manager en utilisant l'une des options suivantes :
Option 1 : Opérateur Red Hat cert-manager pour OpenShift (recommandé)
Installez l'opérateur Red Hat cert-manager pour OpenShift depuis OperatorHub en utilisant le canal stable-v1. Ceci est recommandé pour les environnements OpenShift car il est pris en charge et maintenu via le cycle de vie de l'opérateur OpenShift. Pour les instructions, voir cert-manager Operator for Red Hat OpenShift.
Option 2 : cert-manager upstream
Installez la version cert-manager upstream en utilisant des charts Helm ou des manifestes Kubernetes. Assurez-vous que la version déployée est v1.14 ou ultérieure. Pour les instructions, voir cert-manager Installation.
Si cert-manager est déjà installé sur le cluster en v1.14 ou ultérieure, il peut être réutilisé — aucune installation supplémentaire n'est requise.
Vérifiez que cert-manager est installé et en bon état :
# Vérifier que tous les pods cert-manager sont en cours d'exécution
oc get pods -n cert-manager
# Vérifier que les CRDs cert-manager requis existent
oc get crd | grep cert-manager.ioUne validation réussie affiche les pods du contrôleur cert-manager à l'état Running et les CRDs cert-manager principaux présents sur le cluster.
Provisionner et configurer un grand modèle de langage
Bob on-premises nécessite l'accès à un ou plusieurs grands modèles de langage (LLMs) pris en charge. Bob gère la connexion à l'endpoint du modèle, mais le provisionnement, l'hébergement, la mise à l'échelle et la maintenance de l'infrastructure du modèle sont en dehors de la portée de l'installation principale de Bob.
Configurez les endpoints de modèles suivants avant l'installation :
- Modèle d'inférence principal — traite les demandes des utilisateurs et génère des réponses. Déployez un modèle pris en charge de la liste de modèles d'inférence approuvés (par exemple, Mistral 3.5).
- Modèle de guardrail — applique des vérifications de sécurité, de politique et de gouvernance du contenu aux demandes et réponses. Déployez un modèle de guardrail pour la modération des demandes et des réponses (par exemple,
openai/gpt-oss-20b).
Pour plus d'informations sur la configuration des modèles, voir Configuration du Model Gateway.
Assurez-vous que le backend Bob et les services de modèles configurés peuvent communiquer sur le réseau. Vérifiez que les pare-feux, les politiques réseau, les groupes de sécurité, les proxies et les règles de routage autorisent le trafic entre le cluster OpenShift et les endpoints de modèles avant de procéder à l'installation.
Bob ne fournit pas de fonctionnalités de journalisation des événements de sécurité. Vous êtes responsable de la configuration de la journalisation de sécurité, de la journalisation d'audit et de la surveillance via OpenShift et tout outil de sécurité d'entreprise associé.