Validez la connectivité des modèles, les identifiants, les certificats et les paramètres de configuration avant l'installation pour identifier et résoudre les problèmes du Model Gateway avant de déployer Bob on-premises.

Avant d'installer Bob on-premises, vérifiez que vos endpoints de modèles, vos identifiants d'authentification, vos certificats TLS et votre configuration du Model Gateway sont correctement configurés et accessibles depuis le cluster OpenShift cible. L'exécution de ces contrôles de validation permet d'identifier les problèmes de connectivité, les identifiants non valides, les problèmes de confiance des certificats et les erreurs de configuration avant le déploiement, réduisant ainsi les échecs d'installation et les efforts de dépannage.

Parcourez cette liste de contrôle avant d'exécuter bobctl install pour détecter au plus tôt les configurations manquantes.

Test de connectivité vers les endpoints de modèles

Vérifiez que le cluster OpenShift peut atteindre chaque endpoint de modèle avant le déploiement de tout composant Bob. Lancez un pod de débogage temporaire dans le namespace cible et testez directement l'accessibilité HTTPS :

# openai_compatible
oc run curl-test --image=curlimages/curl --restart=Never --rm -it -- \
  curl -v https://<model-endpoint>/v1/models

# bedrock
oc run curl-test --image=curlimages/curl --restart=Never --rm -it -- \
  curl -k https://bedrock.<AWS_REGION>.amazonaws.com/foundation-models \
  --aws-sigv4 "aws:amz:${REGION}:bedrock" \
  --user "$AWS_ACCESS_KEY_ID:$AWS_SECRET_ACCESS_KEY"

Pour les endpoints openai_compatible, testez par rapport à la valeur base_url issue de votre configuration de model gateway. Pour les infrastructures air-gapped ou privées, il s'agit du seul moyen de valider la connectivité puisqu'il n'y a aucune accessibilité externe par conception.

Validation de l'authentification

Validez les identifiants avant de les encoder sous forme de secrets dans config.yaml. Un identifiant erroné entraîne un échec de démarrage du service d'inférence, souvent avec un message de journal cryptique.

openai_compatible — testez la clé d'API directement depuis un pod de débogage :

curl -s https://<base_url>/v1/models \
  -H "Authorization: Bearer <api_key>" | jq '.data[].id'

bedrock — vérifiez les valeurs AWS_ACCESS_KEY et AWS_SECRET_ACCESS_KEY à l'aide de l'AWS CLI avant de les ajouter à config.yaml :
```
aws bedrock list-foundation-models --region us-east-1
```
vertex — décodez la valeur base64 GEMINI_CREDENTIALS et confirmez qu'il s'agit d'un JSON de compte de service valide avant de le fournir :
```
base64 -d <<< "$GEMINI_CREDENTIALS" | jq '.type'
# Sortie attendue : "service_account"
```

Validation du certificat TLS

En cas d'utilisation de ca_cert_pem avec un endpoint openai_compatible, validez le certificat avant de le fournir sous forme de secret.

Vérifiez que le certificat est encodé en PEM et n'est pas expiré :

echo "<cert content>" | openssl x509 -noout -dates

Confirmez que le certificat correspond à la chaîne CA de l'endpoint :

openssl s_client -connect <host>:<port> -CAfile ca.pem

Avertissement :

insecure_skip_verify: true ne doit être utilisé que temporairement lors du débogage initial de la connectivité. Supprimez-le avant le passage en production. Si ca_cert_pem fait référence à une variable d'environnement qui n'est pas présente dans bob.modelGateway.secrets, le service d'inférence démarre correctement mais TLS échoue au moment de l'inférence.

Validation de la découverte de modèles

Confirmez que l'ID de model dans votre bloc fournisseur correspond exactement à ce que le fournisseur expose. Une incohérence entraîne une erreur 404 ou modèle non trouvé au moment de l'inférence, et non au démarrage.

Pour les endpoints openai_compatible, vérifiez les ID de modèles disponibles avant l'installation :

curl -s https://<base_url>/v1/models \
  -H "Authorization: Bearer <api_key>" | jq '.data[].id'

Contrôles des erreurs de configuration courantes

Erreur de configuration	Symptôme	Contrôle
Le nom de secret dans la config du modèle ne correspond pas à la clé dans le bloc `secrets` de `config.yaml`	L'authentification échoue lors de la requête, pas au démarrage	Comparez chaque référence `env.*` de la config du modèle avec les clés de `bob.modelGateway.secrets`
`GEMINI_CREDENTIALS` non encodé en base64	Le fournisseur Vertex ne parvient pas à analyser les identifiants au démarrage	Exécutez `base64 -d <<< "$VALUE"` et confirmez qu'il s'agit d'un JSON valide avec `"type": "service_account"`
`base_url` inclut une barre oblique finale `/` ou un suffixe de chemin	Le fournisseur renvoie une erreur 404	Supprimez les barres obliques finales — la passerelle ajoute elle-même les chemins comme `/v1/chat/completions`
Valeurs de `model_name` en double dans la liste `models`	Comportement de routage indéfini	Assurez-vous que toutes les valeurs de `model_name` sont uniques dans l'ensemble de la configuration
`bobctl install` exécuté sans `--model-config`	Passerelle vide, aucune inférence	Vérifiez que `--model-config` est transmis et que le fichier est lisible à l'emplacement spécifié
Variable d'environnement `ca_cert_pem` définie dans la config du modèle mais absente de `secrets`	Échec TLS au moment de l'inférence	Vérifiez rigoureusement chaque référence `env.*` de la configuration du modèle par rapport au bloc `secrets`

Validation avant l'installation

Test de connectivité vers les endpoints de modèles

Validation de l'authentification

Validation du certificat TLS

Validation de la découverte de modèles

Contrôles des erreurs de configuration courantes

Sur cette page