API On-Premises de la plateforme WhatsApp Business

WhatsApp Business Platform > On-Premises API > Guides > Set up & Maintain Your API Client

Configurer la haute disponibilité

La solution standard du client de l’API WhatsApp Business s’exécute sur un seul conteneur Docker. L’exécution de plusieurs conteneurs Docker génère des problèmes et entraîne la fermeture temporaire de votre compte. La présente section vous guide dans la configuration de la haute disponibilité, qui vous permet de disposer de conteneurs Docker de secours en cas de panne du conteneur Docker principal.

Cette solution haute disponibilité nécessite au préalable l’installation d’une instance unique du client de l’API WhatsApp Business pour s’exécuter par-dessus. Si vous n’avez pas encore configuré le numéro de téléphone de votre client de l’API WhatsApp Business, consultez la documentation d’installation avant d’utiliser cette solution.

Présentation

Un cluster à haute disponibilité nécessite au moins deux nœuds maîtres et deux nœuds Coreapp, comme indiqué dans le diagramme suivant :

Cluster à haute disponibilité

Il est recommandé que tous les nœuds soient exécutés sur des ordinateurs/racks différents afin d’éviter toute défaillance d’ordinateur/de rack affectant plusieurs nœuds en même temps.

Démarrage

Lorsqu’un cluster démarre, tous les nœuds maîtres se font concurrence pour récupérer le bail principal afin de devenir principal. Un seul nœud réussira et les autres deviendront des maîtres secondaires. S’il y a un nombre N de nœuds maîtres dans le cluster, il y aura un maître principal et des maîtres secondaires N-1. Le maître principal est responsable de l’inscription, de la mise à niveau du schéma de la base de données, de la diffusion des modifications de configuration, de rapports sur les statistiques de la base de données, de la gestion des clusters, etc. Si le maître principal décède et perd le bail principal, d’autres m = maîtres secondaires s’affronteront pour occuper le poste de maître principal.

Lorsqu’un maître devient primaire, il charge d’abord la carte de partitions à partir de la base de données pour savoir qui est le Coreapp principal actuel. S’il n’y a pas de Coreapp principal dans le cluster, le maître principal promouvra une Coreapp secondaire saine en Coreapp principal et mettra à jour la carte de partitions dans la base de données afin que Webapp puisse rechercher le nœud Coreapp auquel envoyer les demandes d’API. De cette manière, même si tous les maîtres sont en panne, il peut toujours traiter les demandes d’API dans les nœuds Coreapp pour obtenir une haute disponibilité.

Lorsqu’un nœud Coreapp démarre, il s’exécute en tant que Coreapp secondaire jusqu’à ce que le maître principal le promeuve comme Coreapp principal pour se connecter au serveur WhatsApp. Il devient ensuite responsable du traitement des demandes d’API.

Surveillance de base de données

Chaque nœud Coreapp mettra à jour la base de données toutes les minutes pour assurer son fonctionnement. Le maître principal vérifie périodiquement la base de données pour détecter les nœuds Coreapp en mauvaise santé. Si un nœud Coreapp principal n’a pas mis à jour la base de données pendant plus de deux minutes, le maître principal le considère en mauvaise santé et promeut d’autres nœuds Coreapp comme nœud principal. De cette façon, le temps d’arrêt est d’environ deux minutes.

Surveillance basée sur les pulsations

Si un cluster a plusieurs maîtres en cours d’exécution, la surveillance des pulsations détecte les défaillances de nœud plus rapidement que la surveillance de la base de données. Dans la surveillance basée sur les pulsations, tous les maîtres sont chargés de surveiller les nœuds Coreapp en leur envoyant des pulsations toutes les cinq secondes (configurés par heartbeat_interval). Si un Coreapp principal n’a pas répondu au maître principal et à un maître secondaire pendant 30 secondes (configuré par unhealthy_interval), il est considéré comme étant en mauvaise santé et le maître principal promouvra un Coreapp secondaire en bonne santé en Coreapp principal. De cette façon, le temps d’arrêt est d’environ 30 secondes par défaut. Vous pouvez diminuer la valeur unhealthy_interval si vous préférez un temps d’arrêt moins important. Consultez la documentation sur les paramètres pour des exemples de charges utiles.

Configuration initiale

Un cluster Haute disponibilité contient trois types de nœud : Webapp, maître et Coreapp. Ils peuvent être démarrés séparément sur différentes machines, mais ils doivent se trouver dans le même réseau pour pouvoir communiquer entre eux.

Un nœud Webapp est chargé de gérer le trafic de l’API comme le conteneur Webapp d’origine. Un nœud Coreapp est chargé de gérer le trafic de messages de et vers WhatsApp. Enfin, un nœud maître est chargé de surveiller les nœuds Coreapp dans le cluster, de sorte que si un nœud Coreapp expire, il redirige le trafic vers un autre nœud Coreapp pour assurer une haute disponibilité. Le cluster peut comporter plusieurs nœuds Webapp, Coreapp et maître.

Les nœuds actifs ne sont plus appelés des nœuds esclaves. Il s’agit des nœuds Coreapp.

Remarque : Pour les environnements de production, dans la plupart des cas, la base de données doit être exécutée sur un serveur physique distinct depuis les conteneurs Coreapp et Webapp. Pour une véritable disponibilité, il est recommandé d’exécuter les conteneurs maître, Webapp et Coreapp sur différentes machines physiques.

Configurer un système de fichiers partagé pour les messages multimédia

Si vous n’avez pas besoin de messages multimédia, ignorez cette étape.

Afin de pouvoir envoyer et recevoir des messages multimédia, il est nécessaire de configurer un système de fichiers NFS et de le monter dans un répertoire local sur tous les nœuds Webapp, maître et Coreapp. Vérifiez que vous bénéficiez des autorisations en lecture/écriture sur le répertoire partagé.

Exemple de commande de montage de NFS :

mkdir new-local-directory
mount -t nfs nfs_server_IP_addr:/share_directory new-local-directory

Installation avec Docker Compose

Ce guide requiert Docker, une plateforme de conteneur qui vous permet d’exécuter le client de l’API WhatsApp Business. Docker Compose est également requis. Docker Compose est fourni avec Docker pour macOS et Windows, mais nécessite une installation distincte sur Linux.

Configuration de développement avec un serveur unique

Installez Docker sur votre système.
Si Docker Compose n’est pas fourni avec votre installation Docker, installez-le.
Téléchargez les fichiers de configuration multiconnect-compose.yml et db.env : WhatsApp_Configuration_Files.zip.
Ouvrez une console et accédez au répertoire dans lequel vous avez enregistré les fichiers téléchargés.
Si une installation MySQL est en cours d’exécution, remplacez les valeurs dans le fichier db.env de manière à ce qu’elles correspondent à votre configuration MySQL. Si MySQL n’est pas installé, les fichiers multiconnect-compose.yml et db.env sont configurés par défaut pour afficher une instance dans un conteneur local.
Vérifiez qu’il n’y a aucun conteneur à connexion unique qui s’exécute avant de démarrer plusieurs conteneurs pour bénéficier d’une haute disponibilité :
```
  docker-compose -f your-single-connect-yml-filename stop
```
Exécutez la commande suivante sur la console :
```
docker-compose -f multiconnect-compose.yml up
```
Vous obtenez un résultat lorsque le script télécharge les images Docker et procède à la configuration. Pour exécuter les conteneurs en arrière-plan, utilisez le paramètre -d comme suit :
```
docker-compose -f multiconnect-compose.yml up -d
```

Une fois que ces étapes sont terminées, vérifiez que les conteneurs s’exécutent à l’aide de la commande suivante :

docker-compose ps

Par défaut, le conteneur Webapp s’exécute sur le port 9090.

Configuration de production avec plusieurs serveurs pour chaque conteneur

Installez Docker sur vos systèmes.
Si Docker Compose n’est pas fourni avec vos installations Docker, installez-le.
Téléchargez les fichiers de configuration multiconnect-coreapp.yml, multiconnect-master.yml, multiconnect-webapp.yml et db.env : WhatsApp_Configuration_Files.zip, puis enregistrez chacun d’eux sur son serveur respectif.
Sur chaque serveur, ouvrez une console et accédez au répertoire dans lequel vous avez enregistré les fichiers téléchargés.
Dans une configuration de production, il est hautement recommandé d’utiliser une instance MySQL autonome. Une fois que vous en disposez d’une, remplacez les valeurs dans le fichier db.env de manière à ce qu’elles correspondent à votre configuration MySQL.
Vérifiez qu’il n’y a aucun conteneur à connexion unique qui s’exécute avant de démarrer plusieurs conteneurs pour bénéficier d’une haute disponibilité :
```
docker-compose -f your-single-connect-yml-filename stop
```
Exécutez les commandes suivantes sur la console pour chaque machine respective :
La variable d’environnement EXTERNAL_HOSTNAME doit être une adresse IP ou un nom d’hôte qui est accessible à partir des machines exécutant d’autres conteneurs. Les ports présentés dans un fichier YML de service doivent être ouverts aux connexions de machines exécutant d’autres conteneurs. Par exemple, les ports définis comme COREAPP_EXTERNAL_PORTS dans multiconnect-coreapp.yml doivent être ouverts au trafic entrant sur l’hôte qui exécute les conteneurs coreapp.
```
EXTERNAL_HOSTNAME=MACHINE_HOSTNAME docker-compose -f multiconnect-coreapp.yml up # on the Coreapp server
EXTERNAL_HOSTNAME=MACHINE_HOSTNAME docker-compose -f multiconnect-master.yml up # on the Master server
EXTERNAL_HOSTNAME=MACHINE_HOSTNAME docker-compose -f multiconnect-webapp.yml up # on the Webapp server
```
Vous obtenez un résultat lorsque le script télécharge les images Docker et procède à la configuration. Pour exécuter les conteneurs en arrière-plan, utilisez le paramètre -d comme suit :
```
EXTERNAL_HOSTNAME=MACHINE_HOSTNAME docker-compose -f multiconnect-coreapp.yml up -d # on the Coreapp server
EXTERNAL_HOSTNAME=MACHINE_HOSTNAME docker-compose -f multiconnect-master.yml up -d # on the Master server
EXTERNAL_HOSTNAME=MACHINE_HOSTNAME docker-compose -f multiconnect-webapp.yml up -d # on the Webapp server
```

Une fois ces étapes terminées, vérifiez que les conteneurs s’exécutent à l’aide de la commande suivante :

EXTERNAL_HOSTNAME=MACHINE_HOSTNAME docker-compose -f multiconnect-coreapp.yml ps # on the Coreapp server
EXTERNAL_HOSTNAME=MACHINE_HOSTNAME docker-compose -f multiconnect-master.yml ps # on the Master server
EXTERNAL_HOSTNAME=MACHINE_HOSTNAME docker-compose -f multiconnect-webapp.yml ps # on the Webapp server

L’exécution de plusieurs instances du même service (par exemple, deux Coreapps sur le même hôte) ne fonctionnera pas par défaut en raison d’un conflit avec le port hôte. Pour éviter ce conflit, vous devez modifier le fichier YAML de service respectif (ici multiconnect-coreapp.yml) afin d’exposer les différents ports hôte pour chaque instance, comme suit :

ports:

- "HOST_PORT_RANGE:6250-6253"

Par défaut, le conteneur Webapp s’exécute sur le port 9090.

Mise à jour

Configuration de développement avec un serveur unique

Le fichier multiconnect-compose.yml comporte des champs indiquant les versions des conteneurs. Par exemple :

services: ... waweb: image: docker.whatsapp.biz/web:v2.19.4 ... master: image: docker.whatsapp.biz/coreapp:v2.19.4 ... wacore: image: docker.whatsapp.biz/coreapp:v2.19.4

Pour mettre à niveau une installation, remplacez les numéros de version dans le fichier multiconnect-compose.yml :

services: ... waweb: image: docker.whatsapp.biz/web:v2.19.7 ... master: image: docker.whatsapp.biz/coreapp:v2.19.7 ... wacore: image: docker.whatsapp.biz/coreapp:v2.19.7

Redémarrez ensuite les conteneurs Docker :

docker-compose -f multiconnect-compose.yml up

Configuration de production avec plusieurs serveurs pour chaque conteneur

Les fichiers YAML comportent des champs indiquant les versions des conteneurs. Par exemple :

services: ... waweb: image: docker.whatsapp.biz/web:v2.19.4

services: ... wacore: image: docker.whatsapp.biz/coreapp:v2.19.4

services: ... master: image: docker.whatsapp.biz/coreapp:v2.19.4

Pour mettre à niveau une installation, remplacez les numéros de version dans les fichiers respectifs :

services: ... waweb: image: docker.whatsapp.biz/web:v2.19.7

services: ... wacore: image: docker.whatsapp.biz/coreapp:v2.19.7

services: ... master: image: docker.whatsapp.biz/coreapp:v2.19.7

Redémarrez ensuite les conteneurs Docker :

EXTERNAL_HOSTNAME=MACHINE_HOSTNAME docker-compose -f multiconnect-coreapp.yml up # on the Coreapp server
EXTERNAL_HOSTNAME=MACHINE_HOSTNAME docker-compose -f multiconnect-master.yml up # on the Master server
EXTERNAL_HOSTNAME=MACHINE_HOSTNAME docker-compose -f multiconnect-webapp.yml up # on the Webapp server

Association des volumes existants

Si vous disposez de volumes multimédia issus d’une précédente installation, remplacez la définition des volumes suivante dans les fichiers YAML :

volumes:
  whatsappData:
      driver: local
  whatsappMedia:
      driver: local

par :

volumes:
  whatsappData:
      external: true
  whatsappMedia:
      external: true

Montages Bind

Cette option n’est recommandée que si vous souhaitez conserver un volume de montage bind existant.

Pour monter directement un chemin d’accès à l’hôte (un emplacement existant sur votre hôte) dans le conteneur, vous pouvez modifier la ligne relative au volume dans la section de service afin qu’elle pointe vers ce chemin.

wacore:
    volumes:
        /filepath/waent/data:/usr/local/waent/data
        /filepath/wamedia:/usr/local/wamedia

Désinstallation

Configuration de développement avec un serveur unique

Vous devez répéter cette opération pour toutes les machines où s’exécutent des nœuds.

Pour réinitialiser votre environnement de développement en supprimant tous les conteneurs, exécutez la commande suivante depuis le répertoire contenant le fichier multiconnect-compose.yml :

docker-compose -f multiconnect-compose.yml down

Afin de supprimer également tous les volumes définis dans le fichier multiconnect-compose.yml, exécutez down avec le paramètre -v :

docker-compose -f multiconnect-compose.yml down -v

Configuration de production avec plusieurs serveurs pour chaque conteneur

Pour réinitialiser votre environnement de développement en supprimant tous les conteneurs, exécutez la commande suivante à partir du répertoire contenant le fichier YAML sur chaque serveur :

EXTERNAL_HOSTNAME=MACHINE_HOSTNAME docker-compose -f multiconnect-coreapp.yml down # on the Coreapp server
EXTERNAL_HOSTNAME=MACHINE_HOSTNAME docker-compose -f multiconnect-master.yml down # on the Master server
EXTERNAL_HOSTNAME=MACHINE_HOSTNAME docker-compose -f multiconnect-webapp.yml down # on the Webapp server

Afin de supprimer également tous les volumes définis dans les fichiers YAML, exécutez down avec le paramètre -v :

EXTERNAL_HOSTNAME=MACHINE_HOSTNAME docker-compose -f multiconnect-coreapp.yml down -v # on the Coreapp server
EXTERNAL_HOSTNAME=MACHINE_HOSTNAME docker-compose -f multiconnect-master.yml down -v # on the Master server
EXTERNAL_HOSTNAME=MACHINE_HOSTNAME docker-compose -f multiconnect-webapp.yml down -v # on the Webapp server

Journaux de résolution des erreurs

Pour récupérer les journaux de résolution des erreurs, exécutez la commande suivante sur vos serveurs :

  docker-compose logs > debug_output.txt

Plateforme WhatsApp Business | API Cloud | API On-Premises | API Business Management