Orchestration Shiny en entreprise : ShinyProxy sur un cluster Docker Swarm

Q: Que fait Traefik dans cette configuration, et pourquoi ne pas simplement utiliser nginx ?

Traefik est l’ingress — l’unique point d’entrée public qui termine le HTTPS et achemine le trafic vers le cluster. Contrairement à une configuration nginx statique, le fournisseur Swarm de Traefik découvre les services automatiquement à partir des labels Docker, de sorte qu’il achemine vers ShinyProxy où que le Swarm l’ait placé et prend en compte les nouveaux services sans rechargement de configuration. Il récupère et renouvelle aussi les certificats gratuits Let’s Encrypt tout seul. Vous pouvez utiliser nginx, mais vous géreriez le routage et les certificats à la main.

Répartissez les conteneurs d’applications sur plusieurs nœuds pour la haute disponibilité, placez Traefik en frontal, et supervisez le cluster avec Prometheus, Grafana et InfluxDB.

Programming

Shiny

Faites passer un déploiement ShinyProxy mono-hôte à un cluster multi-nœuds. Montez un Docker Swarm, placez Traefik en frontal comme ingress, exécutez ShinyProxy avec le backend de conteneurs docker-swarm, et supervisez le cluster avec une pile Prometheus, Grafana et InfluxDB. Comprend une comparaison honnête Swarm/Kubernetes et le moment où un cluster vaut vraiment les composants supplémentaires.

Date de publication

16 juillet 2026

Modifié

16 juillet 2026

Points clés

Un cluster répartit les conteneurs d’applications sur plusieurs machines. Un seul hôte vous limite au CPU et à la mémoire d’une seule machine, et il tombe d’un bloc. Un cluster Docker Swarm exécute vos conteneurs sur plusieurs nœuds, survit à la panne d’un nœud, et vous laisse ajouter de la capacité en ajoutant des machines.
Vous connaissez déjà la moitié « application » — voici la moitié « infrastructure ». ShinyProxy sert toujours un conteneur par utilisateur ; ici il tourne avec container-backend: docker-swarm au lieu du simple docker, et le cluster gère le placement et l’auto-réparation.
Traefik est la porte d’entrée. Un seul ingress termine le HTTPS et achemine le trafic vers ShinyProxy où qu’il tourne dans le cluster — sans adresses de nœuds codées en dur.
La supervision est une pile, pas un réglage. Prometheus collecte les métriques, InfluxDB stocke les événements d’usage de ShinyProxy, et Grafana représente les deux — pour que vous voyiez la charge et la capacité au lieu de deviner.
La plupart des équipes n’en ont pas besoin. Un seul hôte ShinyProxy suffit pour la majorité des applications internes. Ne passez à un cluster que lorsque vous avez vraiment besoin de haute disponibilité ou de plus de capacité qu’une seule machine.

Introduction

Votre serveur ShinyProxy fonctionne. Il sert un conteneur Docker par utilisateur derrière une connexion, sur une seule machine — vous avez mis cela en place dans la leçon ShinyProxy. Mais une seule machine a deux limites : elle vous plafonne au CPU et à la mémoire de cette machine, et si elle tombe, toutes les sessions tombent avec elle. Quand vous dépassez une seule machine, ou que vous ne pouvez pas vous permettre l’indisponibilité, vous passez à un cluster — plusieurs machines agissant comme un seul pool qui répartit les conteneurs, continue de servir quand un nœud tombe, et grandit en ajoutant du matériel.

Cette leçon prend ce ShinyProxy mono-hôte et le place sur un cluster Docker Swarm : un groupe d’hôtes Docker (appelés nœuds) gérés comme un seul. Vous monterez le Swarm, placerez Traefik en frontal comme ingress (l’unique point d’entrée public qui termine le HTTPS et achemine les requêtes vers le cluster), exécuterez ShinyProxy sur le cluster, et ajouterez une pile de supervision pour pouvoir le surveiller.

Soyez honnête avec vous-même sur le fait d’en avoir besoin d’abord. Un cluster, c’est davantage de pièces mobiles à exploiter et à déboguer. Si votre application dessert un service et que quelques minutes d’indisponibilité pendant un redémarrage ne posent pas de problème, un seul hôte ShinyProxy est la bonne réponse — arrêtez-vous ici et faites l’impasse sur la machinerie supplémentaire. Passez à un cluster quand vous avez un vrai besoin de HA (haute disponibilité — aucune machine unique dont la panne fait tomber le service) ou quand un seul serveur ne peut pas encaisser votre charge simultanée. Le reste de cette leçon suppose que vous êtes dans l’un de ces cas.

Prérequis

Il vous faut une installation ShinyProxy fonctionnelle — si vous n’en avez pas encore, faites d’abord la leçon ShinyProxy ; celle-ci s’appuie directement dessus. Il vous faut aussi Docker installé sur deux hôtes Linux ou plus capables de se joindre sur le réseau (installer Docker), et un nom DNS que vous contrôlez et qui pointe vers le cluster (pour que Traefik puisse acheminer par nom d’hôte et récupérer des certificats TLS). C’est une leçon d’infrastructure : nous ne réexpliquons pas le application.yml, l’authentification ou les spécifications d’applications de ShinyProxy — voyez la leçon ShinyProxy pour cela.

Copiez n’importe quel bloc et exécutez-le sur votre cluster

Les configurations et les commandes de cette page ne sont pas exécutées ici — un cluster est une véritable infrastructure qu’aucune page web statique ne peut monter. Copiez n’importe quel bloc sur vos machines et exécutez-le. Le vrai test, c’est le cluster en fonctionnement : quand docker node ls affiche chaque nœud Ready, que Traefik sert votre nom d’hôte en HTTPS, et que tuer un nœud ne fait pas tomber le service, vous avez prouvé que le déploiement fonctionne — the runtime is the judge. Les tags d’image ci-dessous (traefik:v3.3, openanalytics/shinyproxy:3.2.4, et les autres) sont à jour au moment de la rédaction ; vérifiez la dernière version de chaque projet avant de déployer, et épinglez toujours une version plutôt que :latest.

Le cluster en un coup d’œil

Avant les étapes, voici comment les pièces s’assemblent. Le trafic arrive par Traefik sur le nœud manager ; Traefik l’achemine vers ShinyProxy ; ShinyProxy demande au Swarm de démarrer les conteneurs d’applications, qui atterrissent sur le nœud qui a de la place ; et la pile de supervision surveille l’ensemble.

flowchart TD
    U[Utilisateurs] --> T[Ingress Traefik]
    T --> SP[ShinyProxy]
    SP --> N1[Nœud 1 : conteneurs d'applications]
    SP --> N2[Nœud 2 : conteneurs d'applications]
    SP --> N3[Nœud 3 : conteneurs d'applications]
    SP -->|métriques| P[Prometheus]
    SP -->|événements d'usage| I[InfluxDB]
    P --> G[Tableaux de bord Grafana]
    I --> G

Un nœud est une machine du cluster. Swarm a deux rôles : un nœud manager exécute le plan de contrôle du cluster (il décide où vont les conteneurs et maintient l’état souhaité), et les nœuds worker ne font qu’exécuter des conteneurs. Un petit cluster peut avoir un manager et deux ou trois workers ; le manager peut aussi exécuter des conteneurs d’applications.

Monter un cluster Swarm

Sur la machine que vous voulez comme manager, initialisez le Swarm (docker swarm init) :

# On the MANAGER node
docker swarm init --advertise-addr <manager-ip>

Cela affiche une commande docker swarm join avec un token. Exécutez-la sur chaque worker :

# On each WORKER node — paste the command docker swarm init printed
docker swarm join --token SWMTKN-1-xxxx <manager-ip>:2377

De retour sur le manager, vérifiez que chaque nœud a bien rejoint le cluster :

docker node ls    # each node should show STATUS = Ready, AVAILABILITY = Active

Créez maintenant un réseau overlay — un réseau virtuel qui couvre tous les nœuds, pour que les conteneurs de différentes machines puissent se joindre par leur nom comme s’ils étaient sur un même hôte (réseaux overlay) :

docker network create --driver overlay --attachable shiny-net

Facultativement, étiquetez des nœuds pour pouvoir fixer certains services à certaines machines (par exemple, garder la supervision avec état sur le manager). Une étiquette n’est qu’une clé que vous pourrez faire correspondre plus tard dans une contrainte de placement :

docker node update --label-add role=apps <worker-node-name>

Voilà tout le cluster. À partir d’ici, tout se déploie dessus sous forme de stack — un ensemble de services décrits dans un seul fichier YAML de style Compose et déployés avec docker stack deploy.

Placer Traefik en frontal

Traefik est l’ingress : il écoute sur les ports 80/443, termine le HTTPS, et achemine chaque nom d’hôte vers le bon service. Point crucial, dans un Swarm il découvre les services automatiquement — vous ne codez pas en dur où tourne ShinyProxy ; Traefik lit les labels Docker et l’achemine où que le Swarm l’ait placé. Traefik v3 dialogue avec un Swarm via son fournisseur swarm dédié, activé avec --providers.swarm=true.

# traefik-stack.yml
services:
  traefik:
    image: traefik:v3.3
    command:
      - --providers.swarm=true                 # discover services from the Swarm (Traefik v3)
      - --providers.swarm.exposedByDefault=false  # only route services that opt in with a label
      - --entrypoints.web.address=:80
      - --entrypoints.websecure.address=:443
      # free auto-renewing certificates from Let's Encrypt
      - --certificatesresolvers.le.acme.tlschallenge=true
      - --certificatesresolvers.le.acme.email=you@example.com
      - --certificatesresolvers.le.acme.storage=/letsencrypt/acme.json
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro   # so Traefik can read the Swarm
      - le-certs:/letsencrypt
    networks:
      - shiny-net
    deploy:
      placement:
        constraints: [node.role == manager]   # Traefik reads the Swarm on the manager

volumes:
  le-certs:

networks:
  shiny-net:
    external: true

Lisez les parties importantes :

--providers.swarm=true est ce qui rend Traefik conscient du cluster. Le montage du socket Docker (/var/run/docker.sock, en lecture seule) lui permet de lire les services du Swarm ; c’est pourquoi Traefik est fixé au manager avec node.role == manager — le manager est là où réside l’état du cluster.
exposedByDefault=false signifie qu’un service n’est acheminé que s’il s’inscrit explicitement avec traefik.enable=true — une valeur par défaut plus sûre que d’exposer tout.
Le résolveur de certificats le utilise le défi TLS ACME pour récupérer et renouveler automatiquement des certificats gratuits Let’s Encrypt, ce qui vous donne du HTTPS sans gérer de fichiers de certificats.

Déployez-le :

docker stack deploy -c traefik-stack.yml traefik

Exécuter ShinyProxy sur le cluster

ShinyProxy change à peine. La seule différence de configuration par rapport à l’installation mono-hôte est le backend de conteneurs : au lieu de docker, vous lui dites de lancer les conteneurs d’applications à travers le Swarm avec container-backend: docker-swarm — une valeur prise en charge, documentée dans la référence de configuration de ShinyProxy. Avec cela, quand un utilisateur ouvre une application, ShinyProxy demande au Swarm de planifier le conteneur, et le Swarm le place sur le nœud qui a de la capacité. Tout le reste — vos spécifications d’applications, l’authentification, les limites de ressources — est exactement ce que vous avez écrit dans la leçon ShinyProxy.

# in your ShinyProxy application.yml
proxy:
  container-backend: docker-swarm     # was 'docker' on a single host
  docker:
    internal-networking: true
    container-network: shiny-net       # the overlay network, so ShinyProxy reaches app containers
  # ... your specs, authentication, and limits from the ShinyProxy lesson ...

Déployez ShinyProxy comme un service Swarm, et attachez les labels Traefik qui l’inscrivent dans le routage. Les labels vont sous deploy.labels (le Swarm y lit les labels de service, pas les labels de premier niveau) :

# shinyproxy-stack.yml
services:
  shinyproxy:
    image: openanalytics/shinyproxy:3.2.4
    volumes:
      - ./application.yml:/opt/shinyproxy/application.yml:ro
      - /var/run/docker.sock:/var/run/docker.sock   # ShinyProxy drives the Swarm
    networks:
      - shiny-net
    deploy:
      placement:
        constraints: [node.role == manager]   # ShinyProxy needs the Swarm API on the manager
      labels:
        - traefik.enable=true
        - traefik.http.routers.sp.rule=Host(`analytics.example.com`)
        - traefik.http.routers.sp.entrypoints=websecure
        - traefik.http.routers.sp.tls.certresolver=le
        - traefik.http.services.sp.loadbalancer.server.port=8080
        - traefik.http.services.sp.loadbalancer.sticky.cookie=true   # pin each user to one ShinyProxy replica

networks:
  shiny-net:
    external: true

docker stack deploy -c shinyproxy-stack.yml shinyproxy

Les labels traefik.* disent : expose ce service, achemine https://analytics.example.com vers lui, utilise le résolveur le pour le certificat, et ShinyProxy écoute sur le port 8080. Ouvrez le nom d’hôte dans un navigateur et vous obtenez ShinyProxy en HTTPS, servant des conteneurs d’applications répartis sur le cluster. Voilà toute la moitié « application » — comme vous l’avez déjà construite une fois, la déplacer vers le cluster se résume à une valeur de backend et à un ensemble de labels.

Ajouter une pile de supervision

Sur une seule machine, vous pouviez surveiller un journal. Sur un cluster, il vous faut une vraie observabilité, et elle se présente sous forme de trois services. Prometheus collecte des métriques numériques à intervalles réguliers et les stocke sous forme de séries temporelles. InfluxDB est une base de données de séries temporelles qui stocke les événements d’usage de ShinyProxy — qui a démarré quelle application, et quand. Grafana est la couche de tableaux de bord qui lit les deux et les représente.

ShinyProxy alimente cette pile nativement. Il expose un point de terminaison de métriques que Prometheus collecte, et il peut pousser les événements d’usage vers InfluxDB via le réglage proxy.usage-stats-url (documentation des statistiques d’usage) :

# in application.yml — point ShinyProxy's usage events at InfluxDB
proxy:
  usage-stats-url: <your InfluxDB write endpoint>
  # the exact URL + credentials/token depend on your InfluxDB version's write API —
  # see the usage-statistics docs and your InfluxDB docs for the current form

Déployez les trois services comme une stack. Fixez ceux qui stockent des données sur un nœud dont vous sauvegardez le disque :

# monitoring-stack.yml
services:
  prometheus:
    image: prom/prometheus:v3.1.0
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml:ro   # tell it what to scrape
      - prom-data:/prometheus
    networks: [shiny-net]
    deploy:
      placement:
        constraints: [node.role == manager]

  influxdb:
    image: influxdb:2.7
    volumes:
      - influx-data:/var/lib/influxdb2
    networks: [shiny-net]
    deploy:
      placement:
        constraints: [node.role == manager]

  grafana:
    image: grafana/grafana:11.5.0
    volumes:
      - grafana-data:/var/lib/grafana
    networks: [shiny-net]
    deploy:
      placement:
        constraints: [node.role == manager]

volumes:
  prom-data:
  influx-data:
  grafana-data:

networks:
  shiny-net:
    external: true

docker stack deploy -c monitoring-stack.yml monitoring

Pointez Prometheus vers le point de terminaison de métriques de ShinyProxy dans prometheus.yml, ajoutez Prometheus et InfluxDB comme sources de données dans Grafana, et construisez (ou importez) un tableau de bord. Le bénéfice : vous voyez les sessions simultanées, le nombre de conteneurs et la santé des nœuds sous forme de graphiques — les chiffres dont vous avez besoin pour décider quand ajouter un nœud, au lieu d’attendre que les utilisateurs se plaignent. Le JSON complet du tableau de bord dépasse cette leçon ; l’essentiel est la forme — ShinyProxy émet, Prometheus et InfluxDB stockent, Grafana affiche.

Monter en charge et s’auto-réparer

Une fois sur un cluster, grandir et récupérer se résument à des commandes d’une ligne et à deux ou trois clés deploy.

Ajoutez de la capacité en ajoutant un nœud. Exécutez docker swarm join sur une nouvelle machine, et le planificateur du Swarm commence à y placer des conteneurs d’applications — sans changement de configuration de ShinyProxy.

Faites monter un service en charge pour en exécuter plus de copies :

docker service scale shinyproxy_shinyproxy=2

Mais faites attention à quel service vous faites monter en charge. Exécuter plus d’une réplique ShinyProxy nécessite une affinité de session — le label sticky.cookie sur le service ShinyProxy (ci-dessus) garde chaque utilisateur fixé à la réplique qui détient sa session et son conteneur d’application ; sans lui, une requête acheminée vers une deuxième réplique ne trouve aucune session et l’application casse. Et même avec des cookies collants, une réplique qui meurt emporte les sessions de ses utilisateurs avec elle, à moins d’ajouter un magasin de sessions partagé ; traitez donc une deuxième réplique ShinyProxy comme une mesure de résilience, pas comme un simple bouton de montée en charge. La façon la plus simple de grandir est d’ajouter des nœuds (étape ci-dessus) : cela donne au planificateur plus de place pour les conteneurs d’applications — un par utilisateur — tandis qu’un unique frontal ShinyProxy les achemine tous.

Déclarez l’état souhaité et laissez Swarm le maintenir dans votre fichier de stack — le nombre de répliques, la politique de redémarrage, et où un service peut s’exécuter :

    deploy:
      replicas: 2
      restart_policy:
        condition: on-failure        # restart a crashed container automatically
      update_config:
        order: start-first           # start the new version before stopping the old — no downtime
      placement:
        constraints: [node.labels.role == apps]   # run app containers on labelled worker nodes

Voilà ce que signifie « auto-réparation » : vous dites au Swarm ce que vous voulez (deux répliques, redémarrage en cas d’échec), et il réconcilie en continu la réalité pour qu’elle corresponde — si un conteneur meurt ou qu’un nœud disparaît, il replanifie le travail ailleurs. restart_policy gère les plantages ; update_config: order: start-first vous donne des mises à jour progressives, sans interruption ; placement.constraints dirige les services vers les bonnes machines.

Combien d’utilisateurs peut-il gérer ? Mesurez — ne faites pas confiance à un chiffre

Il n’existe pas de chiffre universel « N utilisateurs par serveur », et quiconque en avance un devine. Parce que ShinyProxy exécute un conteneur par session, votre capacité dépend entièrement de vos applications — un tableau de bord léger et une lourde application de modélisation ont des empreintes radicalement différentes. Plafonnez chaque session (container-memory, container-cpu-limit dans vos spécifications), surveillez la mémoire et le CPU réels par conteneur dans Grafana, et dimensionnez le cluster à votre charge mesurée avec de la marge. La bonne réponse, c’est votre supervision, pas un chiffre d’article de blog.

Docker Swarm vs Kubernetes

ShinyProxy prend en charge à la fois Swarm et Kubernetes — définissez container-backend: kubernetes et il planifie des pods au lieu de services Swarm. Le compromis honnête :

	Docker Swarm	Kubernetes
Complexité	Faible — intégré à Docker, une seule commande pour démarrer	Élevée — de nombreux composants et concepts à apprendre
Mise en place	Quelques minutes (`docker swarm init` + `join`)	Importante, ou un service géré
Bon jusqu’à	Clusters petits à moyens (des dizaines de nœuds)	Le standard à grande échelle / multi-cloud
Écosystème	Petit, stable, « ça marche tout seul »	Vaste — opérateurs, autoscalers, service meshes
ShinyProxy	`container-backend: docker-swarm`	`container-backend: kubernetes`

Choisissez Swarm pour un déploiement Shiny, sauf si vous exécutez déjà Kubernetes. Swarm vous donne le clustering, la HA et les mises à jour progressives pour une fraction du coût opérationnel, et c’est largement suffisant pour l’échelle qu’atteignent la plupart des équipes d’analyse. Choisissez Kubernetes quand vous y êtes déjà investi, que vous avez besoin de son écosystème (autoscaling avancé, opérateurs, multi-cloud), ou que vous tournez à une échelle où sa puissance paie sa complexité. N’adoptez pas Kubernetes pour une application Shiny juste parce que c’est la réponse à la mode — les composants supplémentaires représentent un vrai travail.

Problèmes fréquents

Un service refuse de se planifier — il reste à 0/1 réplique. Exécutez docker service ps <service> --no-trunc et lisez l’erreur. La cause habituelle est une contrainte de placement qu’aucun nœud ne satisfait — vous avez exigé node.labels.role == apps mais n’avez jamais étiqueté de nœud, ou vous avez fixé au manager alors que le manager est plein. Corrigez l’étiquette (docker node update --label-add) ou relâchez la contrainte. La deuxième cause fréquente est que l’image n’est pas téléchargeable sur le nœud cible — assurez-vous que chaque nœud peut atteindre votre registre.

Traefik n’achemine pas vers ShinyProxy — vous obtenez une 404. Presque toujours, Traefik ne voit pas le service. Vérifiez que vous avez bien défini --providers.swarm=true (et non l’ancien --providers.docker.swarmmode), que Traefik s’exécute sur le manager (il a besoin de l’API Swarm), que vos labels traefik.* sont sous deploy.labels dans le fichier de stack (le Swarm ignore les labels de premier niveau pour le routage), et que le service s’est inscrit avec traefik.enable=true. docker service logs traefik_traefik montre ce qu’il a découvert.

Les conteneurs sur des nœuds différents ne peuvent pas se joindre. La communication inter-nœuds ne fonctionne que sur un réseau overlay. Si vous avez utilisé un simple réseau bridge, ou oublié d’attacher un service à shiny-net, les conteneurs de machines distinctes ne peuvent pas communiquer. Vérifiez que le pilote du réseau est bien overlay (docker network ls) et que chaque service de la stack le liste sous networks.

Questions fréquentes

Ai-je besoin de Docker Swarm ou de Kubernetes pour exécuter une application Shiny en production ?

Non — la plupart des applications Shiny en production tournent très bien sur un seul hôte ShinyProxy, qui vous donne déjà l’isolation par utilisateur et une connexion d’entreprise. Vous n’avez besoin d’un orchestrateur comme Docker Swarm ou Kubernetes que lorsque vous exigez la haute disponibilité (survivre à la panne d’une machine) ou plus de capacité qu’un seul serveur n’en fournit. Entre les deux, préférez Swarm sauf si vous exécutez déjà Kubernetes — il apporte le clustering et les mises à jour progressives avec bien moins de complexité.

Comment faire monter une application Shiny pour de nombreux utilisateurs simultanés ?

Placez-la derrière ShinyProxy (un conteneur par session), puis déplacez ShinyProxy sur un cluster Docker Swarm avec container-backend: docker-swarm. Ajoutez de la capacité en rattachant davantage de nœuds — le planificateur du Swarm y répartit automatiquement les conteneurs d’applications — et plafonnez la mémoire et le CPU de chaque session pour qu’aucune application n’affame le cluster. Faites monter les services en charge avec docker service scale et laissez deploy.replicas maintenir le nombre stable.

Comment superviser un déploiement ShinyProxy ?

ShinyProxy alimente une pile de supervision nativement : il expose un point de terminaison de métriques que Prometheus collecte, et il peut pousser des événements d’usage (démarrages/arrêts d’applications par utilisateur) vers InfluxDB via le réglage proxy.usage-stats-url (documentation des statistiques d’usage). Grafana représente alors les deux pour que vous puissiez surveiller les sessions simultanées, le nombre de conteneurs et l’usage des ressources sur des tableaux de bord.

Combien d’utilisateurs un seul serveur peut-il gérer ?

Il n’y a pas de nombre fixe — cela dépend entièrement de la lourdeur de vos applications, car chaque session tourne dans son propre conteneur. Un tableau de bord léger utilise une fraction de ce dont a besoin une application de modélisation. Plafonnez les ressources de chaque session, mesurez le CPU et la mémoire réels par conteneur sous charge dans Grafana, et dimensionnez en conséquence avec de la marge. Traitez avec méfiance toute affirmation universelle « N utilisateurs par serveur » ; mesurez plutôt vos propres applications.

Que fait Traefik dans cette configuration, et pourquoi ne pas simplement utiliser nginx ?

Traefik est l’ingress — l’unique point d’entrée public qui termine le HTTPS et achemine le trafic vers le cluster. Contrairement à une configuration nginx statique, le fournisseur Swarm de Traefik découvre les services automatiquement à partir des labels Docker, de sorte qu’il achemine vers ShinyProxy où que le Swarm l’ait placé et prend en compte les nouveaux services sans rechargement de configuration. Il récupère et renouvelle aussi les certificats gratuits Let’s Encrypt tout seul. Vous pouvez utiliser nginx, mais vous géreriez le routage et les certificats à la main.

Testez vos connaissances

À vous de jouer : rendre la stack consciente du cluster

Vous déplacez un ShinyProxy mono-hôte fonctionnel vers un Swarm. Nommez les deux réglages qui rendent le déploiement conscient du cluster — un dans le application.yml de ShinyProxy, un dans la commande de Traefik — et expliquez ce que fait chacun.

Indice

L’un dit à ShinyProxy de lancer les conteneurs d’applications à travers le Swarm au lieu du Docker local. L’autre dit à Traefik de lire les services depuis le Swarm pour pouvoir les acheminer. Les deux sont des lignes uniques.

Solution

container-backend: docker-swarm dans le application.yml de ShinyProxy (c’était docker sur un hôte unique). Cela fait planifier à ShinyProxy le conteneur d’application de chaque utilisateur à travers le Swarm, si bien que les conteneurs atterrissent sur le nœud qui a de la capacité au lieu de toujours l’hôte Docker local.
--providers.swarm=true dans la commande de Traefik (le fournisseur Swarm dédié de Traefik v3). Cela fait découvrir à Traefik les services depuis le Swarm via le socket Docker et l’achemine vers ShinyProxy où qu’il tourne — ce qui explique aussi pourquoi Traefik est fixé au nœud manager, là où réside l’état du cluster.

Ensemble, ils transforment une installation mono-hôte en un déploiement en cluster : ShinyProxy répartit le travail sur les nœuds, et Traefik l’achemine sans adresses codées en dur.

Vérification rapide

Dans la pile de supervision, quel est le rôle d’InfluxDB ?

A. Il termine le HTTPS et achemine le trafic vers ShinyProxy.
B. Il stocke les événements d’usage de ShinyProxy (quelle application chaque utilisateur a démarrée, et quand) sous forme de données de séries temporelles que Grafana représente.
C. Il planifie les conteneurs d’applications sur les nœuds du cluster.
D. Il remplace l’isolation par conteneur et par utilisateur de ShinyProxy.

Afficher la réponse

B. InfluxDB est la base de données de séries temporelles qui stocke les événements d’usage de ShinyProxy, alimentée via proxy.usage-stats-url ; Grafana la lit (ainsi que Prometheus) pour représenter l’activité. A est le rôle de Traefik (l’ingress) ; C est le rôle du planificateur Swarm ; D est faux — ShinyProxy fournit toujours un conteneur par utilisateur, quelle que soit la pile de supervision.

Conclusion

Faire monter ShinyProxy sur un cluster relève surtout d’une infrastructure que vous assemblez une fois. Montez un Docker Swarm avec docker swarm init et docker swarm join, reliez les nœuds entre eux avec un réseau overlay, et placez Traefik en frontal comme ingress avec --providers.swarm=true pour qu’il découvre vos services et les achemine par-dessus HTTPS. ShinyProxy lui-même change à peine — basculez container-backend vers docker-swarm et il répartit les conteneurs d’applications sur le cluster, se réparant et replanifiant à mesure que les nœuds vont et viennent. Ajoutez Prometheus, InfluxDB et Grafana et vous pouvez enfin voir votre charge au lieu de la deviner. Préférez Swarm à Kubernetes sauf si vous exécutez déjà Kubernetes — et préférez un seul hôte à l’un ou l’autre sauf si vous avez vraiment besoin de la disponibilité ou de la capacité. Construisez le cluster quand le besoin est réel, supervisez-le, et laissez les chiffres vous dire quand ajouter le prochain nœud.

Leçons connexes

Construire jusqu’à cela et autour : ShinyProxy : auto-héberger une application Shiny pour de nombreux utilisateurs est l’installation mono-hôte que cette leçon fait monter en charge — commencez par là si ce n’est pas fait. Conteneuriser une application Shiny construit l’image même que le cluster exécute. Sécurité Shiny : renforcer votre application contre les menaces réelles couvre le TLS, l’authentification et le durcissement qu’exige un cluster public.
Aller plus loin : Applications web Shiny — tout le cursus Shiny. · Science computationnelle et IA — le pilier.

Cette page vous a-t-elle été utile ?

Prouvez que vous savez le faire. Maîtrisez toute la série Shiny en production — suivez votre parcours, construisez des projets et obtenez un certificat.

Commencer gratuitement →

Passez à Pro — Prova illimité sur vos propres données et un certificat vérifiable qui atteste la compétence.

dès 15 $/mois facturé annuellement

Passer à Pro →

✓ Vous êtes Pro — continuez. The runtime is the judge.

Réutilisation

CC BY-NC-SA 4.0

Citation

BibTeX

@online{2026,
  author = {},
  title = {Orchestration Shiny en entreprise : ShinyProxy sur un cluster
    Docker Swarm},
  date = {2026-07-16},
  url = {https://www.datanovia.com/learn/programming/shiny/production/enterprise-orchestration},
  langid = {fr}
}

Veuillez citer ce travail comme suit :

“Orchestration Shiny en entreprise : ShinyProxy sur un cluster Docker Swarm.” 2026. July 16. https://www.datanovia.com/learn/programming/shiny/production/enterprise-orchestration.