Services gérés

Kafka, RabbitMQ, Redis et Keycloak - ce que vous obtenez, ce à quoi chaque disposition survit, et comment une application s'y connecte.

Un service géré est un élément de tuyauterie auquel vos applications s'adressent : un cache, un courtier de messages, un journal d'événements, un serveur d'authentification. Comme une base de données, il se commande séparément de toute application, depuis la page Services.

La plateforme le crée, le maintient en service et le redémarre quand il s'arrête. Ce que vous y mettez vous appartient.

Ces quatre-là ne peuvent pas tourner comme des applications ordinaires : une image de Redis, RabbitMQ, Kafka ou Keycloak y est refusée, parce qu'une application ne conserve rien sur disque d'un déploiement à l'autre.

Ce qui est proposé

Redis 7.4. Protégé par un mot de passe. Chaque écriture est aussi journalisée sur disque : les données survivent donc à un redémarrage.

RabbitMQ 3.13. Un courtier AMQP avec un utilisateur et un mot de passe. Les files durables et les messages persistants sont conservés sur disque.

Kafka 3.8. Fonctionne sans ZooKeeper. Le courtier ne demande ni nom d'utilisateur ni mot de passe : le réseau privé est sa seule frontière.

Keycloak 26.0. Un serveur d'authentification à vous, avec sa console d'administration. Ses realms et ses utilisateurs vivent dans PostgreSQL : une mini-base de données peu coûteuse par défaut, ou une instance dédiée que vous possédez déjà. Vous pouvez téléverser vos propres thèmes de connexion sous forme de .tar.gz.

Si vous n'avez besoin que de l'authentification pour une application, un realm sur un Keycloak exploité par la plateforme coûte moins cher qu'un serveur à vous. Il est proposé sur la même page.

Tailles, nœuds et prix

Les tailles sont des types d'instance nommés, par région, chacune affichée avec son prix mensuel avant le déploiement. Le prix s'entend par nœud : trois nœuds coûtent trois fois la taille.

Une région qui n'a pas fixé de prix pour un service ne le propose pas. Le formulaire le dit au lieu d'échouer à l'envoi.

Redis et Keycloak fonctionnent sur 1, 2 ou 3 nœuds. RabbitMQ et Kafka fonctionnent sur 1, 3 ou 5.

Ce à quoi chaque disposition survit

Un nœud est la valeur par défaut, et la disposition éprouvée.

Elle survit à un redémarrage : Redis, RabbitMQ et Kafka conservent leurs données sur disque, et Keycloak conserve les siennes dans sa base de données.

Elle ne survit pas à la perte de sa machine. Les données sont sur le disque de cette machine et le service y est attaché : il est donc injoignable jusqu'au retour de la machine.

Plusieurs nœuds ne sont pas une bascule aujourd'hui. Vos applications reçoivent toujours l'adresse du premier nœud, quel qu'en soit le nombre.

Redis. Les autres nœuds suivent le premier comme des copies. Rien n'en promeut un si le premier est perdu.
Kafka. Trois ou cinq courtiers forment un seul cluster et décident à la majorité, d'où le nombre impair. Les clients établissent tout de même leur premier contact par le premier courtier.
RabbitMQ. Les nœuds supplémentaires sont démarrés, mais ils ne sont pas réunis en un seul cluster pour vous. Utilisez un seul nœud.
Keycloak. Les nœuds supplémentaires partagent la même base de données, mais l'adresse mène au premier.

Si un service doit survivre à la perte d'une machine, dites-le avant de vous appuyer dessus.

Il n'y a pas de sauvegardes

Redis, RabbitMQ et Kafka ne sont pas sauvegardés. N'y gardez que ce que vous pouvez reconstruire ou vous permettre de perdre : un cache, du travail en cours, des événements qui existent aussi ailleurs.

Les realms et les utilisateurs de Keycloak sont dans sa base PostgreSQL. Protégez-les comme vous protégez n'importe quelle base de données.

Se connecter

Sur le réseau privé. Un service rejoint l'un des réseaux de votre organisation dans sa région, choisi à la création. Les applications de ce réseau l'atteignent à l'adresse interne affichée sur le service. Les applications d'un autre réseau, non.

Identifiants. Ouvrez le service et choisissez Afficher les identifiants : une chaîne de connexion, l'hôte, le port, l'utilisateur et le mot de passe. Contrairement à ceux d'une base de données, ils peuvent être affichés de nouveau plus tard, à toute personne autorisée à se connecter à ce service. La ligne de commande ne les affiche jamais.

Rien n'est défini pour vous sur votre application. Copiez la chaîne de connexion dans l'environnement de l'application, comme secret. L'exception est l'AI Studio : un Redis, un RabbitMQ ou un Keycloak lié à un projet y arrive sous la forme REDIS_URL, RABBITMQ_URL ou KEYCLOAK_URL. Kafka n'est pas lié de cette façon.

Keycloak. Les applications utilisent <adresse>/realms/<realm> comme émetteur. La console d'administration est à <adresse>/admin/.

Publier

Keycloak est public par défaut, à une adresse qui lui est propre, comme une application : un serveur d'authentification doit être joignable depuis un navigateur.

Redis, RabbitMQ et Kafka sont privés par défaut dans la console. Publier l'un d'eux lui donne un hôte et un port joignables de l'extérieur. Depuis la ligne de commande, un nouveau service est public sauf si vous passez --private.

Trois limites à connaître avant de publier :

Le chiffrement n'est pas encore en vigueur. L'interrupteur TLS enregistre votre choix. Un Redis ou un RabbitMQ publié parle son protocole en clair, protégé par son seul mot de passe.
Gardez Kafka privé. Il n'a pas de mot de passe, et un client extérieur à la plateforme est renvoyé vers une adresse qui n'existe qu'à l'intérieur.
Publier demande du crédit. Sans crédit, un service reste privé, et un Keycloak qui aurait été public est créé privé.

Un service peut être publié une fois qu'il est en service.

Redimensionner

Choisissez une autre taille et les nœuds redémarrent un par un. Avec un seul nœud, c'est une courte interruption.

Ajouter des nœuds les crée. Retirer un nœud supprime ce nœud et les données qu'il contenait.

Supprimer

Chaque nœud et toutes ses données sont supprimés, et les identifiants avec. Ce n'est pas réversible.

La base de données de Keycloak n'est pas supprimée avec lui. Une instance dédiée reste intacte, et la mini-base de données doit être supprimée séparément.

Cas particuliers à connaître avant d'y être confronté

Le service indique qu'il tourne et refuse les connexions. Redis, RabbitMQ et Kafka sont marqués comme en service dès leur création, un peu avant d'accepter des clients. Réessayez.

L'application ne trouve pas le service. Elle est sur un autre réseau. Le service rejoint un seul réseau ; placez l'application sur le même.

Un Kafka publié accepte la première connexion puis échoue. C'est la limite décrite plus haut. Utilisez-le depuis les applications de son réseau.

Vous avez retiré un nœud puis l'avez rajouté. Il démarre vide. Ses données précédentes sont parties avec lui.