Installer Atom et Molecule Boomi sur Linux en bash

Installer un Atom Boomi sur une VM Linux propre, c’est une procédure qui tient en quelques étapes documentées. Mais l’installer correctement — avec un user dédié, des limites système adaptées, un service systemd qui redémarre proprement, et un token d’installation récupéré via l’API — c’est une autre histoire. Et quand on recommence ça sur dix environnements clients différents, on finit par automatiser.

C’est l’origine de Boomi-Installer : un toolkit bash qui gère le cycle de vie complet d’un runtime Boomi sur Linux, de l’installation initiale jusqu’à la désinstallation.

Le Problème Concret

L’installateur officiel de Boomi (atom_install64.sh) fait son travail : il décompresse le runtime, crée la structure de répertoires, enregistre le nœud dans AtomSphere. Ce qu’il ne fait pas :

Créer un user Linux dédié avec les bonnes permissions
Configurer les limites système (nofile) indispensables pour un runtime qui ouvre des milliers de fichiers simultanément
Générer le service systemd avec les bons paramètres (LimitNOFILE, TimeoutSec, KillMode)
Récupérer automatiquement le token d’installation via l’API AtomSphere
Gérer les spécificités de la Molecule (script de redémarrage restart-systemd.sh) et de la Gateway

Ces étapes sont manuelles, documentées en plusieurs endroits dans la base de connaissance Boomi, et faciles à rater. Une limite nofile mal positionnée se traduit par des erreurs de connexion silencieuses en production. Un service systemd sans KillMode=process fait des redémarrages approximatifs sur les Molecules en cluster.

Architecture du Toolkit

Boomi-Installer/
  script/
    install.sh          # Bootstrap — téléchargé et exécuté en one-liner
    menu.sh             # TUI interactif — point d'entrée principal
    bin/
      exports.sh        # Configuration centrale (toutes les variables)
      common.sh         # Fonctions partagées, helpers couleur, appels API
      installerToken.sh # Génère le token via l'API AtomSphere
      installAtom.sh    # Installation Atom
      installMolecule.sh
      installGateway.sh
      createUserGroup.sh
      createUserService.sh
      createBoomiAtomService.sh
      createBoomiMoleculeService.sh
      createBoomiGatewayService.sh
      createRestarMoleculetSystemd.sh
      createRestarGatewaySystemd.sh
    conf/
      container.properties          # Propriétés Atom
      molecule_container.properties
      gateway_container.properties
    json/
      installerToken.json           # Payload API pour la génération de token

Le découpage est volontaire : chaque bin/*.sh est une unité atomique qui fait une seule chose. menu.sh orchestre, les scripts exécutent.

Démarrage en Une Ligne

Sur un serveur Linux vierge avec accès Internet, l’installation du toolkit se déclenche ainsi :

bash <(wget -qO- https://raw.githubusercontent.com/Soundjata/Boomi-Installer/refs/heads/main/script/install.sh)

install.sh fait quatre choses :

Installe les dépendances système (git, nano, jq, unzip)
Clone le dépôt dans /etc/Boomi-Installer
Configure les limites de fichiers ouverts dans /etc/security/limits.conf (65 536 soft et hard) — avec un verrou pour éviter les race conditions si le script est lancé en parallèle
Supprime git après clonage (surface d’attaque réduite)

Après ça : cd /etc/Boomi-Installer/script && ./menu.sh.

Le TUI est construit avec tput — pas de dépendance à dialog ou whiptail. Chaque entrée affiche son statut en temps réel (vert/rouge) selon l’état réel du système :

  ┌──────────────────────────────────────────────────────────┐
  │  atomType    : MOLECULE                                  │
  │  atomName    : MOL_PRD_01                                │
  │  INSTALL_DIR : /opt/boomi                                │
  │  service     : boomiuser:boomigroup                      │
  │  accountId   : soundjata-GKKV2Z                          │
  └──────────────────────────────────────────────────────────┘

  a. Editer la configuration
  b. [ROUGE] Télécharger molecule_install64.sh
  c. [ROUGE] Lancer l'installation de la molecule MOL_PRD_01
  d. [VERT]  Le groupe user 'boomigroup' existe.
  e. [VERT]  Le user de service 'boomiuser' existe.
  f. [ROUGE] Créer le service Boomi 'MOL_PRD_01'.
  g. [ROUGE] Créer le script de redémarrage 'restart-systemd.sh'.

L’ordre des étapes correspond au workflow d’installation complet. On voit d’un coup d’œil ce qui manque.

La Mécanique Interne

Token d’Installation via l’API

Boomi requiert un token d’installation à usage unique pour enregistrer un runtime dans AtomSphere. Le générer à la main via la console, c’est une étape de plus — et un token qui expire après 24h.

installerToken.sh appelle l’API REST AtomSphere (POST /InstallerToken) avec le payload approprié selon le type de runtime (ATOM, MOLECULE, GATEWAY) et stocke le tokenId en variable d’environnement. L’appel est fait directement depuis le serveur cible, juste avant l’installation.

// json/installerToken.json
{
  "atomType": "ATOM"
}

Isolation User/Group

Le runtime Boomi ne tourne pas en root. createUserGroup.sh et createUserService.sh créent :

Le groupe boomigroup
L’utilisateur boomiuser (shell /sbin/nologin, home /var/boomi)

Après installation, chown -R boomiuser:boomigroup sur le répertoire d’installation. Le service systemd s’exécute sous cet utilisateur — si le runtime est compromis, le rayon d’action est limité.

Service systemd — Molecule vs Atom

Le service Atom est simple :

[Service]
Type=forking
User=boomiuser
Group=boomigroup
Restart=always
ExecStart=/opt/boomi/Atom_MON_ATOM/bin/atom start
ExecStop=/opt/boomi/Atom_MON_ATOM/bin/atom stop
ExecReload=/opt/boomi/Atom_MON_ATOM/bin/atom restart

La Molecule a des besoins spécifiques :

[Service]
LimitNOFILE=65536
LimitNPROC=65536
Environment="INSTALL4J_JAVA_HOME_OVERRIDE=/opt/boomi/Molecule_MOL_PRD_01/jre"
Type=forking
TimeoutSec=5min      # La Molecule met du temps à s'arrêter proprement
IgnoreSIGPIPE=no
KillMode=process     # N'envoie SIGKILL qu'au processus principal, pas au groupe
GuessMainPID=yes
RemainAfterExit=yes  # systemd considère le service actif même si le PID change

KillMode=process est critique sur une Molecule : sans ça, systemd envoie SIGKILL à tout le groupe de processus au stop, ce qui peut corrompre l’état du cluster. RemainAfterExit=yes gère le cas où le processus principal se détache après le démarrage.

Script de Redémarrage Molecule

La Molecule Boomi intègre un mécanisme de mise à jour automatique qui nécessite un redémarrage via un script spécifique (restart-systemd.sh), pas via systemctl restart. Ce script est généré par createRestarMoleculetSystemd.sh et placé dans le répertoire bin/ du runtime. Sans lui, les mises à jour de la Molecule se font mal — le processus redémarre en dehors du contrôle de systemd.

Configuration Centrale

Tout passe par bin/exports.sh — un fichier qu’on édite directement depuis le menu (option a, qui ouvre nano). Les variables essentielles :

export atomType="MOLECULE"          # ATOM | MOLECULE | GATEWAY
export atomName="MOL_PRD_01"
export INSTALL_DIR="/opt/boomi"
export service_user="boomiuser"
export service_group="boomigroup"
export accountId="soundjata-GKKV2Z"
export authToken="BOOMI_TOKEN.user@soundjata.com:xxx"
export SLEEP_TIMER=0.2              # Throttle les appels API (< 5 req/s)

# Optionnel
export JRE_HOME="/usr/lib/jvm/java-11-openjdk-amd64"
export proxyHost="proxy.soundjata.com"
export proxyPort="8080"

L’authToken est le seul secret sensible. En production, on peut le passer via une variable d’environnement injectée par le système de secrets (Vault, AWS SSM, etc.) plutôt que de le stocker dans le fichier.

Ce que ça Règle en Pratique

Sur un déploiement terrain typique — installation d’une Molecule sur deux VM RHEL pour un cluster HA — le workflow manuel prenait 45 à 60 minutes en comptant la documentation et les vérifications. Avec le toolkit : environ 10 minutes, dont la moitié est le temps de téléchargement du runtime Boomi.

Plus important : les erreurs silencieuses disparaissent. La limite nofile, la configuration du JRE, le script de redémarrage, le service systemd correctement paramétré — tout ça est systématiquement en place. On ne découvre plus en production qu’un nœud a été installé avec des paramètres par défaut insuffisants.

Le projet est disponible sur GitHub : Soundjata/Boomi-Installer. Les contributions sont bienvenues, notamment pour l’ajout d’un mode non-interactif (passage de tous les paramètres en ligne de commande) et le support des environnements air-gapped.

Boomi-Installer : Automatiser le Déploiement des Runtimes sur Linux