Proxy de relais
Le proxy de relais App Configuration se situe entre vos clients SDK et le service IBM Cloud App Configuration. Au lieu que chaque SDK se connecte directement à IBM Cloud, les clients SDK se connectent au proxy au sein de votre propre réseau. Le proxy récupère et met en cache la configuration depuis IBM Cloud App Configuration, puis la transmet à tous les clients connectés.
Pourquoi utiliser Relay Proxy?
Envisagez d'utiliser Relay Proxy dans les cas suivants :
- Réduire le nombre d'appels sortants vers IBM Cloud — Le proxy ouvre une connexion en amont par combinaison de collection et d'environnement configurée, quel que soit le nombre d'instances SDK déployées dans votre parc.
- Déploiements en air-gap ou sur réseau privé: les clients SDK communiquent uniquement avec le proxy au sein de votre réseau. Le proxy gère l'ensemble de la connectivité vers IBM Cloud.
- Point d'authentification unique — Une clé API IAM d' IBM Cloud est requise sur le proxy. Les clients SDK s'authentifient auprès du proxy à l'aide d'une clé que vous définissez.
- Basculement entre l'instance principale et l'instance de secours — Le proxy bascule automatiquement vers une instance de secours d' IBM Cloud App Configuration lorsque l'instance principale n'est pas disponible, puis se rétablit automatiquement.
- Démarrage en douceur à partir d'un fichier de configuration local — En mode démarrage rapide, le proxy fournit immédiatement la configuration à partir d'un fichier de configuration local tout en récupérant en arrière-plan les données actualisées depuis IBM Cloud.
Comment les clients SDK se connectent au Relay Proxy
Les clients SDK utilisent les mêmes types de connexion que ceux qu’ils utilisent pour se connecter directement à IBM Cloud App Configuration, mais ils ciblent plutôt l’hôte et le port du proxy :
| Type SDK | Type de connexion | Objectif |
|---|---|---|
| serveur de kits de développement de logiciels (SDK) | WebSocket | Recevez des notifications en temps réel concernant les modifications de configuration |
| SDK client | Événements envoyés par le serveur (SSE) | Recevez des instantanés de configuration et des mises à jour |
| Tous les SDK | REST | Récupérer la configuration initiale |
Multiplexage des connexions
L'un des principaux avantages du Relay Proxy est le multiplexage des connexions. Des centaines, voire des milliers d’instances SDK peuvent se connecter au proxy, mais celui-ci n’ouvre qu’une seule connexion en amont WebSocket par combinaison
collection × environment vers IBM Cloud App Configuration. Ce nombre de connexions en amont est déterminé par votre configuration et n'augmente jamais en fonction de la taille de votre parc.
Par exemple, si vous configurez deux collections (inventory et payments) utilisées chacune dans deux environnements (dev et prod), le proxy maintient exactement quatre sessions en amont WebSocket,
quel que soit le nombre d'instances SDK qui s'y connectent :
| Session WebSocket en amont | Collection | Environnement |
|---|---|---|
| Session 1 | inventaire | dév |
| Session 2 | inventaire | prod |
| Session 3 | paiements | dév |
| Session 4 | paiements | prod |
Lorsqu' IBM Cloud App Configuration envoie un événement de modification sur une connexion en amont, le proxy le diffuse instantanément à tous les clients SDK abonnés à cette combinaison.
Chaque collection × environment combinaison dispose de son propre emplacement de cache isolé et de sa propre session d' WebSocket en amont au sein du proxy.
Modes de démarrage
Le proxy Relay prend en charge deux modes de démarrage selon qu'un fichier de graines est configuré ou non.
Début normal
En mode de démarrage normal, le proxy doit réussir à se connecter à IBM Cloud App Configuration avant de traiter toute requête. Si la récupération d'une configuration échoue, le démarrage est interrompu. Ce mode garantit que les clients reçoivent toujours des données fiables dès leur première requête.
La séquence de démarrage est la suivante :
- Récupérer la configuration depuis IBM Cloud App Configuration — toutes les combinaisons configurées sont récupérées de manière synchrone.
- Mettre en cache toutes les configurations en mémoire.
- Démarrez le serveur HTTP et acceptez les requêtes des clients.
- Ouvrez des sessions WebSocket en amont pour recevoir des notifications de modification en temps réel, à raison d’une par combinaison.
Un démarrage rapide
En mode démarrage rapide, un fichier de préchargement préchauffe le cache afin que le proxy puisse commencer à traiter les requêtes immédiatement, sans attendre l' IBM Cloud. La nouvelle configuration est récupérée en arrière-plan et transmise à tous les clients déjà connectés dès qu'elle est disponible. Ce mode est adapté aux environnements air-gap et aux déploiements résilients.
La séquence de démarrage est la suivante :
- Charger le fichier d'amorçage depuis le disque : le cache est préchauffé instantanément, aucun appel réseau n'est nécessaire.
- Démarrez immédiatement le serveur d' HTTP.
- Récupère en arrière-plan la nouvelle configuration depuis IBM Cloud App Configuration — remplace les données de départ et en informe tous les clients connectés.
- Ouvrez des sessions WebSocket en amont pour recevoir des notifications de modification en temps réel, à raison d’une par combinaison.
Pour le format du fichier de départ et les options de configuration, consultez la référence de l'API App Configuration.
Comment une modification de configuration est répercutée dans vos SDK
Lorsqu'une modification de configuration est publiée dans la console d' App Configuration, celle-ci est transmise à vos clients SDK selon la séquence suivante :
- IBM Cloud App Configuration envoie un message WebSocket au proxy de la session en amont concernée.
- Le proxy récupère à nouveau la configuration mise à jour pour cette combinaison et la stocke dans le cache.
- Le proxy diffuse la configuration mise à jour à tous les clients connectés :
- Les SDK des serveurs reçoivent un événement WebSocket.
- Les SDK clients reçoivent un événement SSE contenant la charge utile de configuration mise à jour.
Basculement entre le système principal et le système de secours
Lorsqu'une instance de sauvegarde est configurée, le proxy assure un basculement automatique pour les sessions d' WebSocket s et les récupérations de configuration.
- WebSocket sessions — Chaque combinaison conserve sa propre WebSocket en amont. Lorsque l'instance principale devient indisponible, le proxy se connecte immédiatement à l'instance de secours. Le proxy effectue une nouvelle tentative de connexion à l'instance principale toutes les 15 secondes et ferme la connexion de secours dès que l'instance principale est rétablie.
- Récupération des configurations — Les récupérations de configuration d' HTTP suivent un ordre principal puis de secours.
Configuration de vos SDK pour qu'ils utilisent le proxy Relay
Pour connecter vos clients SDK au Relay Proxy plutôt qu' IBM Cloud directement :
- Remplacez le nom d'hôte IBM Cloud dans l'initialisation de votre SDK par l'hôte et le port du proxy.
- Les paramètres region, guid, API key, collection_id et environment_id doivent correspondre à ceux indiqués dans la configuration du proxy de relais.
Aucune autre modification du code du SDK n'est nécessaire.
Pour commencer à utiliser Relay Proxy, contactez le support App Configuration.