Vous pouvez exécuter Autonomous Relay Agents dans votre propre réseau ou compte infonuagique plutôt que d’utiliser le service hébergé. Les requêtes, les réponses, les clés des fournisseurs et le registre d’utilisation restent alors sur une infrastructure que vous contrôlez, et vos applications appellent votre propre URL de base.
Contenu du paquet
- L’image de la passerelle : le même conteneur que nous exécutons en production. Elle sert l’API et exécute aussi les migrations de la base de données, l’entretien mensuel des partitions et l’importation du catalogue de modèles.
- L’image du tableau de bord : l’interface Web en fichiers statiques derrière nginx, qui transmet
/v1,/healthet le document OpenAPI à la passerelle, pour que tout soit servi depuis une seule origine. - Un fichier Docker Compose pour une seule machine, avec PostgreSQL 16, des vérifications d’état et des volumes nommés.
- Un chart Helm pour Kubernetes. Les migrations et l’importation du catalogue s’exécutent comme crochets avant chaque installation ou mise à niveau, et l’entretien des partitions comme CronJob mensuel.
- Un guide d’exploitation qui énumère chaque paramètre, ceux qui sont obligatoires et ce que chacun active.
Ce que vous fournissez
- PostgreSQL 16. Nous recommandons un service géré avec sauvegardes automatiques et restauration à un instant donné.
- Un point de terminaison TLS, comme votre répartiteur de charge ou votre contrôleur d’entrée, et l’adresse publique que vos utilisateurs saisiront.
- Une clé de gestion des clés pour protéger les clés des fournisseurs. Chaque clé de fournisseur est chiffrée avec sa propre clé de données, elle-même enveloppée par votre clé de gestion : une copie de la base de données seule ne révèle rien. Aujourd’hui, il s’agit d’une clé Google Cloud KMS, que la passerelle peut joindre depuis n’importe quel réseau à l’aide d’un identifiant de compte de service. Dites-nous si vous avez besoin d’un autre gestionnaire de clés.
- Redis, seulement si vous exécutez plus d’une réplique de la passerelle, pour que les limites de débit soient comptées sur l’ensemble.
- Un accès HTTPS sortant vers les fournisseurs de modèles que vous utilisez. Les alertes par courriel et la connexion Google ou GitHub sont facultatives et ne demandent un accès sortant à ces services que si vous les activez.
Aucune télémétrie
Une passerelle auto-hébergée ne nous envoie ni utilisation, ni requêtes, ni données analytiques. L’image du tableau de bord est construite sans analytique. Les seuls appels sortants sont ceux que vous configurez : les fournisseurs de modèles et, au besoin, le courriel, la connexion OAuth et les destinations que vous ajoutez pour les relevés de requêtes.
Mises à niveau
Chaque version est une nouvelle étiquette d’image. Récupérez-la, exécutez les migrations, puis redéployez la passerelle. Le chart Helm le fait dans cet ordre lors d’un helm upgrade, et une migration qui échoue arrête la mise à niveau pendant que la version précédente continue de servir. Avec Docker Compose, docker compose up -d exécute les mêmes étapes.
Sauvegardes
La base de données est le seul état : organisations, clés, identifiants de fournisseurs chiffrés et registre. Sauvegardez-la avec les instantanés de votre service géré ou avec pg_dump. Protégez la clé de gestion des clés et le sel des clés d’API aussi bien que les sauvegardes : sans eux, les clés de fournisseurs restaurées ne peuvent pas être déchiffrées et les clés d’API émises cessent de fonctionner.