Skip to main content
Plusieurs instances explique le mécanisme — un mot --tenant nommant la même instance aux deux installateurs, et ce que --vhost apporte. Cette page est la même information rassemblée en une seule exécution, pour le moment où vous avez réellement un second client à ajouter. Rien ici n’est partagé avec les tenants déjà présents sur l’hôte à l’exception des paquets, Java, Node et PostgreSQL eux-mêmes — voir Ce dont chaque instance a besoin en propre. Un nouveau tenant obtient sa propre base de données, ses propres ports, ses propres jetons opérationnels et son propre choix de compte de service.
1

Choisir le nom et la disposition

Un mot, utilisé identiquement sur les deux installateurs — c’est ce qui permet à update de retrouver la bonne instance plus tard sans que vous ayez à retaper les chemins.
Deux dispositions, choisissez-en une :Optez pour --vhost lorsque le compte SSH ou SFTP propre au tenant existe déjà sous /home — c’est ce qui isole la passerelle des fichiers de ce compte, et pas seulement un chemin différent. Voir Un hôte virtuel.
Sous --vhost, --user n’est pas optionnel. Un répertoire personnel est en 0750 et appartient à son propre compte, et l’installateur ne fait délibérément pas de chown sur un répertoire qui existe déjà — de sorte qu’un service tournant sous n’importe quel autre compte ne peut pas le traverser.L’échec est tardif et se présente comme autre chose : le panneau meurt à npm ci avec can't cd to /home/<nom>/panel/app, et la passerelle démarre puis ne peut pas atteindre sa propre configuration. ProtectHome=tmpfs et BindPaths= rendent le répertoire visible à l’intérieur de l’espace de noms de l’unité ; aucun des deux ne change un bit de permission.Passez le compte propriétaire de l’hôte virtuel aux deux installateurs.
--vhost sans --tenant signifie autre chose. Seul, il conserve une disposition à plat héritée — CHEMIN/{app,conf,data} — au lieu de CHEMIN/panel. Cette forme existe pour que les panneaux installés avant --tenant continuent de fonctionner, et pour un nouveau tenant, elle place silencieusement la passerelle et le panneau dans des dispositions différentes. Passez toujours les deux drapeaux ensemble.
2

Réserver les ports

Chaque tenant existant sur l’hôte détient déjà un port SMPP, un port HTTP et un port ops. Choisissez une plage avec laquelle le nouveau ne peut pas entrer en collision :
--ops-port n’est jamais ouvert dans le pare-feu, quelle que soit la valeur passée — il se lie uniquement en loopback. --http-port est ce que l’ESME ou le client REST d’un client atteint réellement, c’est donc celui à vérifier contre ufw status avant de le choisir.
3

Sa propre base de données

Un tenant, une base de données — jamais un schéma partagé avec les lignes d’un autre tenant.
Un rôle séparé par tenant n’est pas requis — un seul rôle fireflo peut posséder plusieurs bases — mais cela signifie qu’un identifiant divulgué pour un tenant ne peut pas lire ceux d’un autre. Voir La base de données.
4

Installer la passerelle

Sous la disposition en hôte virtuel, ajoutez --vhost /home/$TENANT --user $TENANT — les deux, conformément aux avertissements de l’étape 1.Il demande d’abord et vous montre chaque décision avant d’écrire quoi que ce soit — ajoutez --yes uniquement une fois que vous avez confiance dans la réponse qu’il imprimerait. --bootstrap écrit le minimum dont a besoin une base de données neuve : une table de routage default, une table MESSAGE vide, un écouteur SMPP, un identifiant. Le mot de passe qu’il génère s’affiche une seule fois ; capturez-le.
Les drapeaux prennent des valeurs séparées par un espace. --vhost=/home/$TENANT est rejeté comme option inconnue plutôt qu’analysé, sur les deux installateurs.
--bootstrap uniquement sur une base de données véritablement vide. Il refuse dès qu’il trouve une table de routage, un worker ou un identifiant — donc réinstaller une passerelle dont la base de données existe déjà nécessite --config-source db seul. Le passer à l’envers est la façon dont une installation finit soit par refuser à mi-parcours, soit par démarrer sans rien vers quoi router.
Liste complète des drapeaux à fireflo-install.
5

Vérifier avant d'ajouter quoi que ce soit

Le code de sortie 4 ici est attendu et correct : le déploiement est sain, il n’a simplement encore rien vers quoi router. Il devient 0 une fois qu’un fournisseur et une règle existent, à la suite de l’étape suivante — voir Première configuration.
6

Installer le panneau

Sous la disposition en hôte virtuel, ajoutez --vhost /home/$TENANT --user $TENANT et pointez --gateway-conf-dir vers /home/$TENANT/gateway/conf. Installez le panneau après la passerelle — il lit ce répertoire.
--port n’est jamais dérivé de --tenant. Il reste 3000 sauf s’il est donné explicitement, donc un deuxième panneau sur le même hôte a besoin du sien ou l’installateur refuse plutôt que d’écraser l’unité du premier tenant.
Trois choses qu’il détermine tout seul à partir de --gateway-conf-dir : les deux jetons opérationnels, le METRICS_DATABASE_URL en lecture seule, et l’URL ops — qu’il construit à partir du FIREFLO_OPS_PORT enregistré de cette passerelle, de sorte qu’un --ops-port non par défaut ne nécessite aucun deuxième drapeau ici.
--config-url n’est jamais dérivé, à dessein — c’est la connexion qui peut modifier ce qui est facturé à un client. Sans elle, le panneau démarre en lecture seule pour ce tenant.Il est délibérément omis de la commande ci-dessus : passé en drapeau, le mot de passe de la base de données se retrouve dans l’historique de votre shell et dans la sortie de ps. Omettez-le et l’installateur demande à la place — et cette invite accepte le mot littéral same, signifiant « réutiliser la connexion tout juste dérivée de la passerelle », qui est la bonne réponse chaque fois qu’un seul rôle possède la base de données du tenant.
7

TLS en amont, une origine par tenant

Le panneau parle HTTP en clair sur --port (par défaut 3000, et il doit être unique par tenant sur un hôte partagé — passez-en un explicitement pour chaque tenant après le premier). Placez nginx ou équivalent devant, terminant TLS sur un nom d’hôte propre à ce tenant :
--public-url ci-dessus doit correspondre exactement à server_name — il est écrit comme AUTH_URL, et sans lui une déconnexion redirige vers localhost peu importe ce que le proxy transmet. Voir TLS en amont.
8

Terminer la configuration

bootstrap laisse délibérément de côté un fournisseur et un tarif — personne d’autre ne peut deviner les identifiants d’un fournisseur, et un prix inventé facturerait silencieusement alors qu’un prix absent apparaît comme non tarifé. Ajoutez les deux, puis une règle de routage nommant le fournisseur, puis le premier identifiant client de ce tenant — dans cet ordre, et pourquoi, à Première configuration.
9

Envoyer un message, comme le ferait un client

Un 200 signifie accepté, facturé et mis en file — surveillez l’enregistrement d’appel dans le panneau de ce tenant pour le résultat de la livraison.

​
Ce qui est vraiment nouveau, versus partagé

​
Voir aussi

Plusieurs instances sur un même hôte

Le mécanisme que --tenant et --vhost implémentent, et la garantie « la mise à jour est une recherche ».

Première configuration, dans l'ordre

Ce que bootstrap écrit, et l’ordre qui donne un sens au reste.