Procedure-Systel/Docker/CRIMSON/Déploiement de SGO Crimson Stack.md

Guide de déploiement — SGO Crimson Stack

Vue d'ensemble

Cette stack déploie les services suivants :

Service	Rôle
rabbitmq	Broker de messages AMQP et interface d'administration
cts-backend	Backend du simulateur Crimson Tactics (Spring)
cts-frontend	Frontend du simulateur Crimson Tactics (Angular)

Le routage est assuré par une instance de Traefik 3 déjà déployée dans le Swarm.

Prérequis

• Docker Swarm doit être initialisé et opérationnel.
• Traefik doit être déployé avec les points d'entrée https (443) et admin (8443).

Étape 1 — Créer les répertoires de données et de journaux RabbitMQ

RabbitMQ nécessite un stockage persistant pour ses données et ses journaux. Créez les répertoires suivants sur chaque nœud du Swarm ou sur un stockage partagé, si disponible :

sudo mkdir -p /mnt/data/crimson/{rabbitmq-data,rabbitmq-logs,rabbitmq-ssl}

Étape 2 — Créer la configuration RabbitMQ du Swarm

La configuration complémentaire de RabbitMQ est stockée dans un objet de configuration Swarm. Cela évite d'intégrer directement ces paramètres dans le fichier de stack.

Exécutez les commandes suivantes sur un manager Swarm :

cat > /tmp/crimson-rabbitmq.conf <<EOF
# Configuration du plugin d'administration
management.path_prefix = /rabbitmq

# Configuration du listener AMQPS
listeners.ssl.default = 5671
ssl_options.certfile   = /etc/rabbitmq/ssl/cert.pem
ssl_options.keyfile    = /etc/rabbitmq/ssl/key.pem
ssl_options.verify     = verify_none
ssl_options.fail_if_no_peer_cert = false
EOF

docker config create crimson_rabbitmq_management /tmp/crimson-rabbitmq.conf

rm /tmp/crimson-rabbitmq.conf

Vérifiez que la configuration a bien été créée :

docker config ls
# L'objet crimson_rabbitmq_management doit apparaître dans la liste

Étape 3 — Préparer le certificat TLS et sa clé privée

Le listener AMQPS de RabbitMQ nécessite un certificat et une clé privée. Placez-les sur le stockage partagé : ils seront montés en lecture seule dans le conteneur, dans /etc/rabbitmq/ssl/.

Remarque : si vous disposez déjà d'un certificat valide, délivré par une autorité de certification de confiance pour cet hôte, passez directement à l'étape suivante.

Générer un certificat auto-signé (validité de 10 ans)

Exécutez les commandes suivantes sur chaque nœud ou une seule fois si vous utilisez un stockage partagé :

DNS="saas-crimson.localhost"
sudo openssl req -x509 -newkey rsa:4096 -sha256 \
  -days 3650 \
  -nodes \
  -keyout /mnt/data/crimson/rabbitmq-ssl/key.pem \
  -out    /mnt/data/crimson/rabbitmq-ssl/cert.pem \
  -subj   "/CN=${DNS}" \
  -addext "subjectAltName=DNS:${DNS},IP:127.0.0.1"

Si nécessaire, adaptez les valeurs de CN et de subjectAltName au nom d'hôte ou à l'adresse IP utilisés.

Définir le propriétaire et les permissions

# RabbitMQ s'exécute avec l'UID 100 et le GID 101 dans le conteneur
sudo chown 100:101 /mnt/data/crimson/rabbitmq-ssl/cert.pem
sudo chown 100:101 /mnt/data/crimson/rabbitmq-ssl/key.pem
sudo chmod 440 /mnt/data/crimson/rabbitmq-ssl/cert.pem
sudo chmod 400 /mnt/data/crimson/rabbitmq-ssl/key.pem

Étape 4 — Créer les identifiants RabbitMQ

Les identifiants RabbitMQ sont transmis au conteneur sous la forme d'un secret Swarm, monté dans /etc/rabbitmq/conf.d/credentials.conf.

Créez un fichier temporaire local, puis supprimez-le après avoir créé le secret :

cat > /tmp/crimson-rabbitmq-credentials.conf <<EOF
default_user = admin
default_pass = ChangeMe!
EOF

vim /tmp/crimson-rabbitmq-credentials.conf  # Modifiez le fichier pour définir les identifiants souhaités

docker secret create crimson_rabbitmq_credentials /tmp/crimson-rabbitmq-credentials.conf

rm /tmp/crimson-rabbitmq-credentials.conf

Vérifiez que le secret a bien été créé :

docker secret ls
# Le secret crimson_rabbitmq_credentials doit apparaître dans la liste

Étape 5 — Créer les identifiants du backend CTS

Le backend CTS doit se connecter à RabbitMQ afin de simuler la consommation des messages comme le ferait Crimson Tactics en production.

Utilisez les identifiants de l'utilisateur Crimson (par exemple, crimson_sdis123) et attribuez-lui les permissions nécessaires sur le virtual host RabbitMQ. Consultez la section « Configuration » pour connaître les paramètres requis.

Les identifiants sont transmis sous la forme d'un secret Swarm, monté dans /run/secrets/cts.properties à l'intérieur du conteneur. Spring Boot le lit comme un fichier de propriétés grâce à SPRING_CONFIG_IMPORT.

Créez un fichier temporaire local, puis supprimez-le après avoir créé le secret :

cat > /tmp/crimson-cts-credentials.properties <<EOF
spring.rabbitmq.username=crimson_sdis123
spring.rabbitmq.password=ChangeMe!
spring.rabbitmq.virtual-host=sdis123
EOF

vim /tmp/crimson-cts-credentials.properties  # Modifiez le fichier pour définir les identifiants et le virtual host souhaités

docker secret create crimson_cts_credentials /tmp/crimson-cts-credentials.properties

rm /tmp/crimson-cts-credentials.properties

Vérifiez que le secret a bien été créé :

docker secret ls
# Le secret crimson_cts_credentials doit apparaître dans la liste

Étape 6 — Déployer la stack avec Portainer

1. Ouvrez Portainer, puis accédez à Stacks → Add stack.
2. Sélectionnez Upload et fournissez les deux fichiers suivants :
   • stack/stack.yml
   • stack/stack.env (à utiliser comme fichier d'environnement)
3. Indiquez le nom de la stack (par exemple, crimson-tactics).
4. Dans le fichier stack.env, renseignez la valeur de DOMAIN (par exemple, sdisXX.fr).
5. Cliquez sur Deploy the stack.

Si le déploiement échoue parce que le réseau overlay admin est absent, connectez-vous à un manager du Swarm et créez le réseau avec la commande suivante :

docker network create --driver overlay --attachable admin

Vous pouvez également effectuer le déploiement depuis l'interface en ligne de commande :

docker stack deploy \
  -c stack/stack.yml \
  --env-file stack/stack.env \
  crimson-tactics

Étape 7 — Configurer HAProxy

Les instances HAProxy assurent la terminaison TLS du trafic AMQP et transfèrent les connexions vers les managers Swarm. Ajoutez l'extrait suivant à la configuration HAProxy sur les deux nœuds (généralement dans /etc/haproxy/haproxy.cfg) :

# Crimson Tactics : terminaison TLS AMQP et transfert vers RabbitMQ via Docker Swarm.
# Le certificat backend n'est pas vérifié.
listen LISTEN_CRIMSON_AMQP_SSL
  mode tcp

  bind *:5671 ssl crt /etc/ssl/private/"$DOMAIN".pem
  # Si la configuration précédente est incompatible avec d'anciens clients Java (par exemple, Sun JDK 8),
  # utilisez plutôt la configuration suivante (TLS 1.2 et suites de chiffrement compatibles uniquement).
  #bind *:5671 ssl crt /etc/ssl/private/"$DOMAIN".pem ssl-min-ver TLSv1.2 ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA384

  options tcplog

  ### Managers Swarm ###
  server SWARM-MANAGER-01 ${IP_RANGE}.51:5671 ssl verify none
  server SWARM-MANAGER-02 ${IP_RANGE}.52:5671 ssl verify none

Vérifiez que les valeurs utilisées correspondent à votre environnement :

• $DOMAIN doit correspondre au nom du certificat présent dans /etc/ssl/private/.
• ${IP_RANGE} doit correspondre au préfixe réseau des managers Swarm (par exemple, 172.17.6 pour les adresses 172.17.6.51 et 172.17.6.52).

Si vous gérez l'extrait séparément dans conf/haproxy.snippet.cfg, copiez-y également cette configuration et appliquez-la sur les deux nœuds HAProxy.

Vérifiez la validité de la configuration :

sudo haproxy -c -f /etc/haproxy/haproxy.cfg

Rechargez HAProxy sur les deux nœuds :

sudo systemctl reload haproxy

Étape 8 — Vérifier le déploiement

Vérifiez que tous les services sont opérationnels :

docker stack services crimson-tactics

Vérifiez l'état de RabbitMQ en consultant ses journaux :

docker service logs crimson-tactics_rabbitmq --tail 50

Les services sont accessibles aux adresses suivantes :

Service	URL
Interface d'administration RabbitMQ	https://${DOMAIN_PREFIX}crimson.${DOMAIN}:8443/rabbitmq/
Frontend CTS	https://${DOMAIN_PREFIX}crimson.${DOMAIN}/
AMQPS RabbitMQ	amqps://${DOMAIN_PREFIX}crimson.${DOMAIN}:5671