Boomi on Docker : Concevoir une Plateforme iPaaS Conteneurisée de A à Z

Il y a une question qui revient souvent quand on parle de Boomi en entreprise : peut-on le faire tourner soi-même, en dehors du cloud Boomi ? La réponse est oui — et c’est même l’un des atouts majeurs de la plateforme. Boomi propose trois modes de runtime : Atom (instance unique), Molecule (cluster haute disponibilité) et Gateway (point d’entrée API public). Tous peuvent être déployés on-premise, sur VM, ou dans des conteneurs.

Ce projet est né d’un besoin concret : disposer d’un environnement de démonstration complet, reproductible, qui simule fidèlement ce qu’on déploie chez nos clients. Pas un seul Atom sur une VM, mais une vraie architecture en cluster, avec reverse proxy, gestion des identités, observabilité. Le genre d’infra qu’on présente lors d’un avant-vente, ou qu’on utilise comme référence technique pour onboarder une équipe.

Voici ce que ça donne, comment ça fonctionne, et ce que ça m’a appris.

La Stack en un Coup d’Œil

Sept services, deux réseaux Docker isolés, un seul point d’entrée HTTPS. L’idée directrice : aucun service interne ne doit être accessible directement depuis Internet.

Le schéma se lit de haut en bas : le trafic entre par Traefik External, qui ne laisse passer que ce qu’il connaît. Tout le reste — Molecule, Keycloak, base de données, collecteur de métriques — vit dans le réseau interne, inaccessible depuis l’extérieur.

Deux Réseaux, Une Règle

Le principe de segmentation réseau est simple mais strict :

Réseau	Contenu	Exposé à Internet
gateway-network	Traefik External + Boomi Gateway	Oui, ports 80 et 443
molecule-network	Molecule, Keycloak, PostgreSQL, OTEL	Non — jamais directement

Traefik Internal est le seul service connecté aux deux réseaux. Il joue le rôle de pont contrôlé : il reçoit les requêtes que Traefik External lui délègue et les route vers les bons services internes. Rien ne traverse sans passer par lui.

C’est une décision d’architecture qui peut sembler lourde pour un environnement de démo, mais qui reflète exactement ce qu’on met en place chez les clients. La reproduire en local, c’est s’assurer qu’on a vraiment compris ce qu’on explique.

La Couche Reverse Proxy : Traefik v3

J’ai choisi Traefik v3 plutôt que Nginx pour deux raisons : la découverte dynamique de services, et le support natif de l’OTLP pour la télémétrie. La configuration est déclarative, divisée en deux fichiers dynamic/ — un par instance.

Traefik External — Ce que voit Internet

Chaque route applique automatiquement un middleware security-headers : HSTS 1 an, X-Frame-Options: DENY, Content Security Policy, Referrer-Policy. La seule exception est Keycloak, qui a besoin d’un CSP plus permissif pour charger ses propres assets.

Traefik Internal — Le Chef d’Orchestre

Traefik Internal gère trois types de trafic simultanément :

• HTTP/HTTPS vers Molecule, Keycloak, le collecteur OTEL
• TCP passthrough vers PostgreSQL sur le port 5432 — sans déchiffrement, la connexion est relayée telle quelle jusqu’au conteneur de base de données
• OTLP pour recevoir les traces et métriques de Traefik External

Le routage TCP de PostgreSQL mérite qu’on s’y arrête. Keycloak a besoin d’accéder à sa base, mais la base ne doit pas être exposée directement (même sur le réseau interne). Traefik agit comme un proxy TCP transparent : Keycloak se connecte à internal.jeanmarccoupin.com:5432, Traefik relaie vers keycloak-db:5432. Propre, sans configuration supplémentaire dans PostgreSQL.

Boomi Gateway et Molecule : le Cœur de l’iPaaS

Les deux clusters Boomi tournent sur des images custom basées sur RHEL, publiées sur Docker Hub (soundjata01/boomi-gateway et soundjata01/boomi-molecule). Le processus de provisioning Boomi repose sur un token d’installation à usage unique, généré depuis la console Boomi AtomSphere.

Configuration et Lancement

Avant de démarrer les conteneurs, deux prérequis côté hôte :

# Réseaux Docker externes (créés une seule fois)
docker network create gateway-network
docker network create molecule-network

# Répertoires de données persistantes
mkdir -p /srv/docker/boomi/data/gateway
mkdir -p /srv/docker/boomi/data/molecule

Le fichier .env à la racine du projet concentre toutes les variables sensibles :

# Nom logique affiché dans AtomSphere
BOOMI_MOLECULENAME=LOCAL_DOK_MOL_PRD_01
BOOMI_GATEWAYNAME=LOCAL_DCK_GTW_PRD_01

# Tokens d'installation générés depuis AtomSphere
# Attention : valides 30 min à 24h seulement
INSTALL_GATEWAYTOKEN=gateway-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
INSTALL_MOLECULETOKEN=molecule-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

# Domaine de base
DOMAIN_NAME=jeanmarccoupin.com

Le docker-compose.yml utilise des YAML anchors (&gateway, &molecule) pour éviter la duplication entre node-0 et node-1. Voici la structure clé :

# Ancre partagée — appliquée aux deux nœuds Gateway
x-gateway: &gateway
  image: soundjata01/boomi-gateway:sj-rhel-v1.0
  volumes:
    - gateway_data:/mnt/boomi:Z
    - /srv/docker/traefik/cert/letsencrypt:/mnt/boomi/cert
  restart: unless-stopped

services:
  gateway-node-0:
    <<: *gateway                          # hérite de l'ancre
    hostname: gateway-0.${DOMAIN_NAME}
    environment:
      BOOMI_ATOMNAME: ${BOOMI_GATEWAYNAME}
      ATOM_LOCALHOSTID: gateway-0.${DOMAIN_NAME}   # ID unique et persistant
      INSTALL_TOKEN: ${INSTALL_GATEWAYTOKEN}        # token usage unique, node-0 seul
    networks:
      - gateway-network
    healthcheck:
      test: ["CMD", "wget",
             "--ca-certificate=/mnt/boomi/cert/cert4.pem",
             "https://gateway-0.${DOMAIN_NAME}:8077/_admin/status",
             "-O", "/dev/null"]
      interval: 15s
      retries: 5

  gateway-node-1:
    <<: *gateway
    hostname: gateway-1.${DOMAIN_NAME}
    environment:
      BOOMI_ATOMNAME: ${BOOMI_GATEWAYNAME}
      ATOM_LOCALHOSTID: gateway-1.${DOMAIN_NAME}
    depends_on:
      gateway-node-0:
        condition: service_healthy        # attend que node-0 soit opérationnel
    networks:
      - gateway-network

Le cluster Molecule suit exactement la même structure, sur molecule-network avec son propre endpoint de santé :

x-molecule: &molecule
  image: soundjata01/boomi-molecule:sj-rhel-v1.0
  volumes:
    - molecule_data:/mnt/boomi:Z
    - /srv/docker/traefik/cert/letsencrypt:/mnt/boomi/cert
  restart: unless-stopped

services:
  molecule-node-0:
    <<: *molecule
    hostname: molecule-0.${DOMAIN_NAME}
    environment:
      BOOMI_ATOMNAME: ${BOOMI_MOLECULENAME}
      ATOM_LOCALHOSTID: molecule-0.${DOMAIN_NAME}
      INSTALL_TOKEN: ${INSTALL_MOLECULETOKEN}       # token usage unique, node-0 seul
    networks:
      - molecule-network
    healthcheck:
      test: ["CMD", "wget",
             "--ca-certificate=/mnt/boomi/cert/cert4.pem",
             "https://molecule-0.${DOMAIN_NAME}:9093/_admin/readiness",
             "-O", "/dev/null"]
      interval: 15s
      retries: 5

  molecule-node-1:
    <<: *molecule
    hostname: molecule-1.${DOMAIN_NAME}
    environment:
      BOOMI_ATOMNAME: ${BOOMI_MOLECULENAME}
      ATOM_LOCALHOSTID: molecule-1.${DOMAIN_NAME}
    depends_on:
      molecule-node-0:
        condition: service_healthy
    networks:
      - molecule-network

Une fois Traefik et Keycloak démarrés, le lancement Boomi se fait en une commande :

docker compose up -d

Pour suivre la progression du provisioning (la première fois, Boomi télécharge et installe le runtime) :

docker logs -f LOCAL_DCK_GTW_PRD_01-0   # Gateway node-0
docker logs -f LOCAL_DOK_MOL_PRD_01-0   # Molecule node-0

Healthchecks en Cascade

Un détail important dans la configuration Docker Compose : les nœuds démarrent en séquence, pas en parallèle.

Boomi Molecule est un vrai cluster : les nœuds doivent se “connaître” pour partager l’état et répartir les exécutions de processus. Si node-1 démarre avant que node-0 soit opérationnel, le cluster ne se forme pas correctement. La dépendance condition: service_healthy dans Docker Compose gère ça sans script supplémentaire.

Les endpoints de santé exposés par Boomi :

• Gateway : /_admin/status (HTTPS)
• Molecule : /_admin/readiness (HTTPS)

Traefik surveille ces endpoints et n’envoie du trafic qu’aux nœuds qui répondent 200. En pratique, si un nœud perd la connexion à AtomSphere, il sort automatiquement de la rotation.

Keycloak : Gestion des Identités

Keycloak 24 assure la gestion des identités pour les APIs exposées par la Gateway. La configuration Docker reflète plusieurs contraintes réelles :

• KC_PROXY_HEADERS: xforwarded — Keycloak est derrière Traefik, il doit faire confiance aux headers X-Forwarded-For et X-Forwarded-Proto pour connaître l’IP réelle du client et savoir qu’il est servi en HTTPS
• KC_HTTP_ENABLED: false — HTTPS uniquement, même en interne
• Certificats montés depuis le volume Traefik — les certs Let’s Encrypt sont partagés entre Traefik et Keycloak via un bind mount, évitant de gérer deux sources de vérité pour les certificats

La connexion à PostgreSQL transite par le proxy TCP de Traefik Internal (décrit ci-dessus), ce qui permet d’isoler la base dans le réseau interne sans la rendre directement accessible à Keycloak.

Observabilité : OpenTelemetry → New Relic

La chaîne d’observabilité est entièrement basée sur OpenTelemetry (OTEL). Le collecteur reçoit logs, traces et métriques depuis Traefik (et potentiellement depuis Boomi via ses connecteurs OTLP), puis exporte vers New Relic.

Le fait que l’OTEL Collector exporte via Traefik (et non directement vers New Relic) peut sembler contre-intuitif. La raison : le collecteur est dans molecule-network, un réseau isolé sans accès Internet direct. Traefik External, lui, est sur gateway-network et peut joindre l’extérieur. L’export OTLP passe donc par la chaîne Traefik Internal → Traefik External → New Relic. Légèrement plus complexe, mais cohérent avec le modèle de sécurité.

Dans l’état actuel, l’export OTLP de Traefik lui-même est commenté dans la configuration — l’infrastructure est prête, mais désactivée pour éviter le bruit en environnement de démo. C’est exactement le type de décision qu’on prend aussi en production : instrumenter d’abord, activer quand on sait quoi chercher.

Ce que ce Projet m’a Appris

Sur Boomi : le runtime Molecule est vraiment conçu pour la haute disponibilité. Le mécanisme de cluster, les healthchecks natifs, la persistance du state sur volume partagé — tout est là. Ce qu’on ajoute autour (reverse proxy, auth, observabilité), c’est le reste de l’architecture d’entreprise, pas Boomi.

Sur Docker Compose : la combinaison depends_on: condition: service_healthy + healthcheck sur l’endpoint applicatif (pas juste TCP) est bien plus robuste qu’un restart: always couplé à une logique de retry dans l’application. Les services démarrent dans le bon ordre, point.

Sur la sécurité réseau : deux réseaux Docker avec un seul pont contrôlé, c’est suffisant pour reproduire le modèle DMZ qu’on implémente sur des infrastructures physiques. La surface d’attaque est réduite sans complexité excessive.

Sur Traefik : le proxy TCP est souvent sous-estimé. Gérer PostgreSQL comme un simple flux TCP sans avoir à configurer pg_hba.conf ou SSL côté base de données, c’est un gain de temps réel sur les environnements containerisés.

---

Ce projet est disponible à titre de référence d’architecture. Si tu travailles sur un déploiement Boomi on-premise et que tu cherches un point de départ solide — ou si tu veux simplement comprendre comment les pièces s’assemblent — n’hésite pas à me contacter.