Infrastructure

Toutes les informations liées à l'infrastructure dydu sont disponibles sur cette page.

Occupation disque et bande passante

Le fichier javascript de la boîte de dialogue complète (quelle que soit l'intégration choisie) pèse aux alentours de 250 kilo octets.

Dans le cas particulier d'intégration de la boîte de dialogue en popin, le code javascript de la boîte de dialogue est découpé en deux fichiers.

Le premier fichier contient le strict nécessaire pour effectuer la demande du téléchargement du second qui contient l'intégralité de la boîte de dialogue. Ce premier fichier pèse moins de 10 kilo octets.

Ainsi, la bande passante nécessaire pour la boîte de dialogue est réduite puisque seuls les internautes qui sollicitent le bot déclencheront le téléchargement du fichier javascript de la boîte de dialogue complète.

Connexions serveurs internes

• Serveur principal → Serveur applicatif de backup ou inversement :

  • Connexion HTTPS.

• Serveur principal → Serveur des backups des dumps :

  • Connexion SSH par clé.

• Serveur principal → Serveur antivirus :

  • Connexion non sécurisée.

• Serveur principal → app1.mercury :

  • Connexion HTTPS.

Important : toutes les applications établissement une connexion sécurisée (HTTPS). Cependant, il se peut que certains de vos services web fonctionnent en HTTP en fonction de vos paramétrages.

Haute disponibilité

En cas de panne du serveur principal, un serveur de secours est configuré pour prendre la relève.

Le passage du serveur principal au serveur de secours doit être le plus transparent possible pour l'utilisateur et c'est à l'interface cliente (c'est à dire côté chatbox) d'adresser l'un ou l'autre des serveurs.

Il existe deux cas particuliers :

• Le premier cas concerne les utilisateurs d'une interface web (chatbox). Les requêtes sont automatiquement redirigées vers le serveur de secours, que ce soit au cours d'une conversation avec un bot ou en Livechat :

  • Techniquement, une nouvelle conversation est initiée sur le serveur de secours et elle se poursuivra tant qu'elle ne sera pas terminée, même si le serveur principal est de nouveau joignable.

• Le second cas concerne les opérateurs connectés sur le pupitre Livechat. Un changement de serveur est effectué de manière transparente par un rechargement de la page. Cette opération s'effectue uniquement lorsque l'opérateur est connecté sur une URL de type « app1.xxx.com/router ». Dans le cas contraire (l'opérateur est connecté sur une URL de type app1.xxxx.com/livechat2), l'opérateur doit manuellement basculer vers le serveur de secours (changement d'adresse de app1.xxxx vers app2.xxxx). Ce dernier cas ne devrait plus apparaître aujourd'hui car il existe une redirection automatique de « app1.xxxx.com/livechat2 » vers « app1.xxxx.com/router ».

Les conversations effectuées sur le serveur de secours sont automatiquement rapatriées vers le serveur principal grâce à une synchronisation toutes les heures. Cela entraîne alors un doublon des conversations - dans l'historique des conversations et des statistiques - initiées sur le serveur principal et recommencées sur le serveur de secours par un même utilisateur.

La synchronisation entre le serveur principal et le serveur de secours (base de connaissances, configuration du bot, accès, etc.) est effectuée de manière hebdomadaire mais des copies complètes sont effectuées de manière quotidienne pour une restauration manuelle en cas de problème.

Pour les clients On-Premise, cette disposition requiert une configuration particulière :

• Création d'un serveur de secours (Action client) ;

• Installation de l'application dydu sur ce serveur en mode « serveur de secours » (les informations doivent être fournies par le client pour la génération d'une image Docker spécifique par dydu) ;

• Mise à jour du serveur principal avec l'adresse du serveur de secours (mise à jour de l'image Docker par dydu puis mise à jour du serveur par le client) ;

• Nouvelle génération de la chatbox sur le serveur principal afin qu'elle puisse orienter ses requêtes vers le serveur principal ou le serveur de secours (Action client) ;

• Création d'une tâche régulière pour faire un dump du serveur principal et le restaurer sur le serveur de secours (Action client avec arrêt du serveur de secours nécessaire lors de la restauration).

Configuration du proxy (environnement On-premise)

Pour effectuer la configuration du proxy, vous devez utiliser le fichier suivant (disponible dans les dernières version des docker-compose (43.3050+)) :

env_file:

• ~/.dydu/options.env

Les variables suivantes sont disponibles (variables Java standards) :

• http.proxyHost

• http.proxyPort

• http.proxyUser

• http.proxyPassword

• http.nonProxyHosts

• https.proxyHost

• https.proxyPort

• https.proxyUser

• https.proxyPassword

Notes :

• "https.nonProxyHosts" n'existe pas et doit utiliser "http.nonProxyHosts" ;

• Les valeurs ne peuvent pas être entrées ni entre guillemets ni en citation ;

• Les valeurs ne doivent pas comporter d'espace.

Exemple de configuration

• http.proxyHost=*.localdomain.com

• http.proxyPort=80

• http.proxyUser=login

• http.proxyPassword=mdp

Important : un redémarrage de la plateforme est nécessaire pour que la configuration soit fonctionnelle.