https://isig-wiki.ens-lyon.fr/api.php?action=feedcontributions&feedformat=atom&user=SdunesmeWiki ISIG - Contributions [fr]2026-05-12T23:53:02ZContributionsMediaWiki 1.43.6https://isig-wiki.ens-lyon.fr/index.php?title=Fichier:Plan_Salle_Stagiaire.png&diff=1213Fichier:Plan Salle Stagiaire.png2026-03-06T12:03:51Z<p>Sdunesme : </p>
<hr />
<div></div>Sdunesmehttps://isig-wiki.ens-lyon.fr/index.php?title=Materiel&diff=1207Materiel2026-02-12T09:57:45Z<p>Sdunesme : /* Liste du matériel */</p>
<hr />
<div>La plateforme ISIG dispose de matériel disponible à l'emprunt pour les membres de l'UMR5600. L'emprunt se fait via la plateforme [[Grraou]]. Les points de contact concernant les ressources sont les [[Responsables matériel|groupes de responsables]].<br />
<br />
== Liste du matériel ==<br />
Attention : cette section n'est plus mise à jour automatiquement. La liste à jour est accessible ici : https://grraou-isig.ens-lyon.fr/Web/view_resources.php</div>Sdunesmehttps://isig-wiki.ens-lyon.fr/index.php?title=Materiel&diff=1206Materiel2026-02-12T09:57:17Z<p>Sdunesme : /* Liste du matériel */</p>
<hr />
<div>La plateforme ISIG dispose de matériel disponible à l'emprunt pour les membres de l'UMR5600. L'emprunt se fait via la plateforme [[Grraou]]. Les points de contact concernant les ressources sont les [[Responsables matériel|groupes de responsables]].<br />
<br />
== Liste du matériel ==<br />
Attention : cette section n'est plus mise à jour automatiquement. La liste à jour est accessible ici : https://grraou-isig.ens-lyon.fr/Web/view_resources.php<br />
<!-- GrraouBot content below -->{| class="wikitable sortable"<br />
|+<br />
!Type de ressource<br />
!Nom<br />
!Description<br />
|-<br />
|Capteurs de données divers<br />
|ADC Snap (Tetracam) PIR<br />
|None<br />
|-<br />
|Outils de bricolage<br />
|Aspirateur de chantier<br />
|None<br />
|-<br />
|Appareils de mesures<br />
|Benne Ekman<br />
|None<br />
|-<br />
|Appareils de mesures<br />
|Benne Scooper 20L<br />
|None<br />
|-<br />
|Appareils de mesures<br />
|Benne Scooper 60L<br />
|None<br />
|-<br />
|Bateau<br />
|Bombard AX n°1<br />
|None<br />
|-<br />
|Bateau<br />
|Bombard AX n°2<br />
|None<br />
|-<br />
|Bateau<br />
|Bombard Commando C4<br />
|None<br />
|-<br />
|Bateau<br />
|Bombard Typhoon<br />
|None<br />
|-<br />
|Capteurs de données divers<br />
|Cadre granulo photo<br />
|None<br />
|-<br />
|Outils de bricolage<br />
|Caisse à outils FACOM<br />
|None<br />
|-<br />
|Appareil photo<br />
|Camera Blackmagic Pocket Cinema Camera 4K n°1<br />
|None<br />
|-<br />
|Appareil photo<br />
|Camera Blackmagic Pocket Cinema Camera 4K n°2<br />
|None<br />
|-<br />
|Capteurs de données divers<br />
|Camera thermique VarioCAM HR600 (InfraTec)<br />
|None<br />
|-<br />
|Appareil photo<br />
|Caméscope JVC<br />
|None<br />
|-<br />
|Camion du laboratoire<br />
|Camion Peugeot Expert<br />
|Le camion n'est empruntable que si vous disposez d'une autorisation de conduite de l'ENS à jour.<br />
|-<br />
|Canoë<br />
|Canoë plastique rigide une place<br />
|None<br />
|-<br />
|Appareil photo<br />
|Canon PowerShot A25000<br />
|None<br />
|-<br />
|Appareil photo<br />
|Canon PowerShot G9<br />
|None<br />
|-<br />
|Appareil photo<br />
|Canon PowerShot S3 IS<br />
|None<br />
|-<br />
|Vêtements (hors EPI)<br />
|Cape de pluie<br />
|None<br />
|-<br />
|Equipements de Protection Individuelle<br />
|Casque (3 unités disponibles)<br />
|<br />
|-<br />
|Outils de bricolage<br />
|Chalumeau<br />
|None<br />
|-<br />
|Equipements de Protection Individuelle<br />
|Chaussures de sécurité [taille 38]<br />
|None<br />
|-<br />
|Equipements de Protection Individuelle<br />
|Chaussures de sécurité [taille 40]<br />
|None<br />
|-<br />
|Equipements de Protection Individuelle<br />
|Chaussures de sécurité [taille 44]<br />
|None<br />
|-<br />
|Vêtements (hors EPI)<br />
|Combinaison de plongée [taille 42]<br />
|None<br />
|-<br />
|Vêtements (hors EPI)<br />
|Combinaison de plongée [taille 46]<br />
|None<br />
|-<br />
|Vêtements (hors EPI)<br />
|Combinaison manches courtes [taille 42]<br />
|None<br />
|-<br />
|Appareil photo<br />
|Compact étanche WG-50 (Ricoh)<br />
|None<br />
|-<br />
|Appareil photo<br />
|Compact étanche WG-60 (Ricoh)<br />
|None<br />
|-<br />
|Appareil photo<br />
|Compact Pro G9 n°1<br />
|None<br />
|-<br />
|Outils de bricolage<br />
|Coupe boulon<br />
|None<br />
|-<br />
|Vêtements (hors EPI)<br />
|Coupe vent [taille 2]<br />
|None<br />
|-<br />
|Appareil photo<br />
|D7000 (Nikon)<br />
|None<br />
|-<br />
|Appareils de mesures<br />
|Échantillonneur McNeil (2 unités disponibles)<br />
|Tube cylindrique de 15 cm de diamètre utiliser pour prélever la couche et la sous-couche du lit en eau (profondeur max. 40 cm)<br />
|-<br />
|Outils de bricolage<br />
|Échelle télescopique 2m90<br />
|Echelle télescopique.<br />
|-<br />
|Capteurs de données divers<br />
|Enregistreur (ancien) lunettes SMI eye-tracker<br />
|None<br />
|-<br />
|Outils de bricolage<br />
|Escabeau<br />
|None<br />
|-<br />
|Outils de bricolage<br />
|Fer à souder<br />
|None<br />
|-<br />
|Capteurs de données divers<br />
|Flow tracker ADCPro<br />
|None<br />
|-<br />
|Appareils de mesures<br />
|Gabarits granulométriques<br />
|None<br />
|-<br />
|GPS<br />
|Garmin eTrex 30x n°1<br />
|None<br />
|-<br />
|GPS<br />
|GEO XH 6000 (Trimble)<br />
|None<br />
|-<br />
|Vêtements (hors EPI)<br />
|Gilet de pêche multipoche [taille L]<br />
|None<br />
|-<br />
|Vêtements (hors EPI)<br />
|Gilet de pêche multipoche [taille M]<br />
|None<br />
|-<br />
|Vêtements (hors EPI)<br />
|Gilet de pêche multipoche [taille XL]<br />
|None<br />
|-<br />
|Equipements de Protection Individuelle<br />
|Gilet de sauvetage seul<br />
|Réservez un ou plusieurs gilets de sauvetage sans bateau.<br />
|-<br />
|Appareil photo<br />
|GoPro Hero 2<br />
|None<br />
|-<br />
|Capteurs de données divers<br />
|Grande antenne RFID rectangulaire<br />
|None<br />
|-<br />
|Appareils de mesures<br />
|Haglöf Transpondeur Télémètre à ultrason<br />
|Manque potentiellement des pièces<br />
|-<br />
|Capteurs de données divers<br />
|IML RESI PowerDrill Wood<br />
|None<br />
|-<br />
|Outils de bricolage<br />
|Jeu de clés mixtes Facom<br />
|None<br />
|-<br />
|Vêtements (hors EPI)<br />
|Long John de plongée [taille 42]<br />
|None<br />
|-<br />
|Capteurs de données divers<br />
|Lunettes SMI Eye tracker (ancien)<br />
|None<br />
|-<br />
|Capteurs de données divers<br />
|Lunettes SMI Eye tracking (nouveau) + enregistreur<br />
|None<br />
|-<br />
|Outils de bricolage<br />
|Machette<br />
|None<br />
|-<br />
|Outils de bricolage<br />
|Maillet<br />
|None<br />
|-<br />
|Outils de bricolage<br />
|Malette à visser AllRound<br />
|None<br />
|-<br />
|Outils de bricolage<br />
|Malette à visser Eckmann<br />
|None<br />
|-<br />
|Outils de bricolage<br />
|Masse<br />
|None<br />
|-<br />
|Accessoires informatiques<br />
|Microphone 360° USB n°1<br />
|None<br />
|-<br />
|Accessoires informatiques<br />
|Microphone 360° USB n°2<br />
|None<br />
|-<br />
|Capteurs de données divers<br />
|Moyenne antenne RFID rectangulaire<br />
|None<br />
|-<br />
|Enregistreurs vocaux<br />
|NAGRA ARES-ML<br />
|Enregistreur audio<br />
|-<br />
|Enregistreurs vocaux<br />
|NAGRA SD<br />
|Enregistreur audio<br />
|-<br />
|Outils de bricolage<br />
|Niveau à bulle (3 unités disponibles)<br />
|None<br />
|-<br />
|Outils de bricolage<br />
|Outillage divers<br />
|Divers outils disponibles au local bateau<br />
|-<br />
|Laptop empruntable à l'heure<br />
|PC portable Eustache<br />
|None<br />
|-<br />
|Laptop empruntable à l'heure<br />
|PC portable Félicie<br />
|PC détenu par Kristell pour le moment<br />
|-<br />
|Laptop empruntable à l'heure<br />
|PC portable Gérard<br />
|Inventaire DSI : L100599<br />
|-<br />
|Laptop empruntable à l'heure<br />
|PC portable Jean-Luc<br />
|Utilisé par Hossein actuellement<br />
|-<br />
|Laptop empruntable à l'heure<br />
|PC portable Marguerite<br />
|None<br />
|-<br />
|PC de terrain empruntable à la demi-journée<br />
|PC Terrain Panasonic Touchbook CF-19<br />
|None<br />
|-<br />
|Capteurs de données divers<br />
|Pénétromètre PANDA<br />
|None<br />
|-<br />
|Outils de bricolage<br />
|Perceuse-visseuse Bosh PSB 18<br />
|None<br />
|-<br />
|Capteurs de données divers<br />
|Perche graduée pour granulo photo<br />
|None<br />
|-<br />
|Outils de bricolage<br />
|Perforateur Bosh sans fil 18V<br />
|Perforateur sans fil avec 2 batteries.<br />
|-<br />
|Appareils de mesures<br />
|Peson Kern<br />
|Résolution 5g, Maximum 6kg<br />
|-<br />
|Outils de bricolage<br />
|Petit maillet<br />
|None<br />
|-<br />
|Capteurs de données divers<br />
|Petite antenne RFID circulaire<br />
|None<br />
|-<br />
|Outils de bricolage<br />
|Pistolet à cartouches (2 unités disponibles)<br />
|None<br />
|-<br />
|Accessoires informatiques<br />
|Pointeur Laser n°1<br />
|None<br />
|-<br />
|Accessoires informatiques<br />
|Pointeur Laser n°2<br />
|None<br />
|-<br />
|GPS<br />
|R8 (Trimble) DGPS (chargeur boîte noire)<br />
|None<br />
|-<br />
|GPS<br />
|R8 (Trimble) GNSS (chargeur boîte noire)<br />
|None<br />
|-<br />
|Capteurs de données divers<br />
|RFID boitier TAG Passif : Datamax + boitier Cipam + 2 petits GPS + cables<br />
|None<br />
|-<br />
|Capteurs de données divers<br />
|RFID TAG Actif a-UHF (2 caisses)<br />
|None<br />
|-<br />
|Vêtements (hors EPI)<br />
|Sac à dos étanche ITIWI<br />
|None<br />
|-<br />
|Appareils de mesures<br />
|Sonde Pressler<br />
|None<br />
|-<br />
|PC de terrain empruntable à la demi-journée<br />
|Tablette Terrain Panasonic Touchbook CF-D1<br />
|None<br />
|-<br />
|Enregistreurs vocaux<br />
|Tascam DR-07 n°1<br />
|None<br />
|-<br />
|Vêtements (hors EPI)<br />
|Top thermique de plongée [taille L]<br />
|None<br />
|-<br />
|Vêtements (hors EPI)<br />
|Top thermique de plongée [taille S]<br />
|None<br />
|-<br />
|Accessoires informatiques<br />
|Tour de visioconférence n°1<br />
|None<br />
|-<br />
|Accessoires informatiques<br />
|Tour de visioconférence n°2<br />
|None<br />
|-<br />
|Accessoires photo<br />
|Trépied photo n°1<br />
|<br />
|-<br />
|Accessoires photo<br />
|Trépied photo n°2<br />
|<br />
|-<br />
|Outils de bricolage<br />
|Treuil (2 unités disponibles)<br />
|None<br />
|-<br />
|Equipements de Protection Individuelle<br />
|Trousse de secours terrain<br />
|None<br />
|-<br />
|Vélo<br />
|Vélo cargo Douze Cycles<br />
|None<br />
|-<br />
|Vêtements (hors EPI)<br />
|Veste de plongée [taille 42]<br />
|None<br />
|-<br />
|Vêtements (hors EPI)<br />
|Veste imperméable Quechua [taille L] (2 unités disponibles)<br />
|Veste imperméable achetée en 2022<br />
|-<br />
|Vêtements (hors EPI)<br />
|Veste Millet [taille L]<br />
|None<br />
|-<br />
|Vidéoprojecteur<br />
|Vidéoprojecteur Acer<br />
|None<br />
|-<br />
|Vidéoprojecteur<br />
|Vidéoprojecteur Optoma<br />
|None<br />
|-<br />
|Vêtements (hors EPI)<br />
|Waders néoprène [taille 38-39]<br />
|None<br />
|-<br />
|Vêtements (hors EPI)<br />
|Waders néoprène [taille 40-41] (2 unités disponibles)<br />
|None<br />
|-<br />
|Vêtements (hors EPI)<br />
|Waders néoprène [taille 42-43] (3 unités disponibles)<br />
|Waders achetées en novembre 2022<br />
|-<br />
|Vêtements (hors EPI)<br />
|Waders néoprène [taille 46-47]<br />
|None<br />
|-<br />
|Vêtements (hors EPI)<br />
|Waders [taille 38-39] (5 unités disponibles)<br />
|None<br />
|-<br />
|Vêtements (hors EPI)<br />
|Waders [taille 40-41] (3 unités disponibles)<br />
|None<br />
|-<br />
|Vêtements (hors EPI)<br />
|Waders [taille 42-43] (4 unités disponibles)<br />
|None<br />
|-<br />
|Vêtements (hors EPI)<br />
|Waders [taille 44-45] (2 unités disponibles)<br />
|None<br />
|-<br />
|Bateau<br />
|Yamaha Yam 310 S<br />
|None<br />
|-<br />
|GPS<br />
|Zenith 35 Pro (Geomax) composé de 3 caisses<br />
|None<br />
|}</div>Sdunesmehttps://isig-wiki.ens-lyon.fr/index.php?title=Materiel&diff=1205Materiel2026-02-12T09:55:36Z<p>Sdunesme : </p>
<hr />
<div>La plateforme ISIG dispose de matériel disponible à l'emprunt pour les membres de l'UMR5600. L'emprunt se fait via la plateforme [[Grraou]]. Les points de contact concernant les ressources sont les [[Responsables matériel|groupes de responsables]].<br />
<br />
== Liste du matériel ==<br />
Attention : cette section n'est plus mise à jour automatiquement.<br />
<!-- GrraouBot content below -->{| class="wikitable sortable"<br />
|+<br />
!Type de ressource<br />
!Nom<br />
!Description<br />
|-<br />
|Capteurs de données divers<br />
|ADC Snap (Tetracam) PIR<br />
|None<br />
|-<br />
|Outils de bricolage<br />
|Aspirateur de chantier<br />
|None<br />
|-<br />
|Appareils de mesures<br />
|Benne Ekman<br />
|None<br />
|-<br />
|Appareils de mesures<br />
|Benne Scooper 20L<br />
|None<br />
|-<br />
|Appareils de mesures<br />
|Benne Scooper 60L<br />
|None<br />
|-<br />
|Bateau<br />
|Bombard AX n°1<br />
|None<br />
|-<br />
|Bateau<br />
|Bombard AX n°2<br />
|None<br />
|-<br />
|Bateau<br />
|Bombard Commando C4<br />
|None<br />
|-<br />
|Bateau<br />
|Bombard Typhoon<br />
|None<br />
|-<br />
|Capteurs de données divers<br />
|Cadre granulo photo<br />
|None<br />
|-<br />
|Outils de bricolage<br />
|Caisse à outils FACOM<br />
|None<br />
|-<br />
|Appareil photo<br />
|Camera Blackmagic Pocket Cinema Camera 4K n°1<br />
|None<br />
|-<br />
|Appareil photo<br />
|Camera Blackmagic Pocket Cinema Camera 4K n°2<br />
|None<br />
|-<br />
|Capteurs de données divers<br />
|Camera thermique VarioCAM HR600 (InfraTec)<br />
|None<br />
|-<br />
|Appareil photo<br />
|Caméscope JVC<br />
|None<br />
|-<br />
|Camion du laboratoire<br />
|Camion Peugeot Expert<br />
|Le camion n'est empruntable que si vous disposez d'une autorisation de conduite de l'ENS à jour.<br />
|-<br />
|Canoë<br />
|Canoë plastique rigide une place<br />
|None<br />
|-<br />
|Appareil photo<br />
|Canon PowerShot A25000<br />
|None<br />
|-<br />
|Appareil photo<br />
|Canon PowerShot G9<br />
|None<br />
|-<br />
|Appareil photo<br />
|Canon PowerShot S3 IS<br />
|None<br />
|-<br />
|Vêtements (hors EPI)<br />
|Cape de pluie<br />
|None<br />
|-<br />
|Equipements de Protection Individuelle<br />
|Casque (3 unités disponibles)<br />
|<br />
|-<br />
|Outils de bricolage<br />
|Chalumeau<br />
|None<br />
|-<br />
|Equipements de Protection Individuelle<br />
|Chaussures de sécurité [taille 38]<br />
|None<br />
|-<br />
|Equipements de Protection Individuelle<br />
|Chaussures de sécurité [taille 40]<br />
|None<br />
|-<br />
|Equipements de Protection Individuelle<br />
|Chaussures de sécurité [taille 44]<br />
|None<br />
|-<br />
|Vêtements (hors EPI)<br />
|Combinaison de plongée [taille 42]<br />
|None<br />
|-<br />
|Vêtements (hors EPI)<br />
|Combinaison de plongée [taille 46]<br />
|None<br />
|-<br />
|Vêtements (hors EPI)<br />
|Combinaison manches courtes [taille 42]<br />
|None<br />
|-<br />
|Appareil photo<br />
|Compact étanche WG-50 (Ricoh)<br />
|None<br />
|-<br />
|Appareil photo<br />
|Compact étanche WG-60 (Ricoh)<br />
|None<br />
|-<br />
|Appareil photo<br />
|Compact Pro G9 n°1<br />
|None<br />
|-<br />
|Outils de bricolage<br />
|Coupe boulon<br />
|None<br />
|-<br />
|Vêtements (hors EPI)<br />
|Coupe vent [taille 2]<br />
|None<br />
|-<br />
|Appareil photo<br />
|D7000 (Nikon)<br />
|None<br />
|-<br />
|Appareils de mesures<br />
|Échantillonneur McNeil (2 unités disponibles)<br />
|Tube cylindrique de 15 cm de diamètre utiliser pour prélever la couche et la sous-couche du lit en eau (profondeur max. 40 cm)<br />
|-<br />
|Outils de bricolage<br />
|Échelle télescopique 2m90<br />
|Echelle télescopique.<br />
|-<br />
|Capteurs de données divers<br />
|Enregistreur (ancien) lunettes SMI eye-tracker<br />
|None<br />
|-<br />
|Outils de bricolage<br />
|Escabeau<br />
|None<br />
|-<br />
|Outils de bricolage<br />
|Fer à souder<br />
|None<br />
|-<br />
|Capteurs de données divers<br />
|Flow tracker ADCPro<br />
|None<br />
|-<br />
|Appareils de mesures<br />
|Gabarits granulométriques<br />
|None<br />
|-<br />
|GPS<br />
|Garmin eTrex 30x n°1<br />
|None<br />
|-<br />
|GPS<br />
|GEO XH 6000 (Trimble)<br />
|None<br />
|-<br />
|Vêtements (hors EPI)<br />
|Gilet de pêche multipoche [taille L]<br />
|None<br />
|-<br />
|Vêtements (hors EPI)<br />
|Gilet de pêche multipoche [taille M]<br />
|None<br />
|-<br />
|Vêtements (hors EPI)<br />
|Gilet de pêche multipoche [taille XL]<br />
|None<br />
|-<br />
|Equipements de Protection Individuelle<br />
|Gilet de sauvetage seul<br />
|Réservez un ou plusieurs gilets de sauvetage sans bateau.<br />
|-<br />
|Appareil photo<br />
|GoPro Hero 2<br />
|None<br />
|-<br />
|Capteurs de données divers<br />
|Grande antenne RFID rectangulaire<br />
|None<br />
|-<br />
|Appareils de mesures<br />
|Haglöf Transpondeur Télémètre à ultrason<br />
|Manque potentiellement des pièces<br />
|-<br />
|Capteurs de données divers<br />
|IML RESI PowerDrill Wood<br />
|None<br />
|-<br />
|Outils de bricolage<br />
|Jeu de clés mixtes Facom<br />
|None<br />
|-<br />
|Vêtements (hors EPI)<br />
|Long John de plongée [taille 42]<br />
|None<br />
|-<br />
|Capteurs de données divers<br />
|Lunettes SMI Eye tracker (ancien)<br />
|None<br />
|-<br />
|Capteurs de données divers<br />
|Lunettes SMI Eye tracking (nouveau) + enregistreur<br />
|None<br />
|-<br />
|Outils de bricolage<br />
|Machette<br />
|None<br />
|-<br />
|Outils de bricolage<br />
|Maillet<br />
|None<br />
|-<br />
|Outils de bricolage<br />
|Malette à visser AllRound<br />
|None<br />
|-<br />
|Outils de bricolage<br />
|Malette à visser Eckmann<br />
|None<br />
|-<br />
|Outils de bricolage<br />
|Masse<br />
|None<br />
|-<br />
|Accessoires informatiques<br />
|Microphone 360° USB n°1<br />
|None<br />
|-<br />
|Accessoires informatiques<br />
|Microphone 360° USB n°2<br />
|None<br />
|-<br />
|Capteurs de données divers<br />
|Moyenne antenne RFID rectangulaire<br />
|None<br />
|-<br />
|Enregistreurs vocaux<br />
|NAGRA ARES-ML<br />
|Enregistreur audio<br />
|-<br />
|Enregistreurs vocaux<br />
|NAGRA SD<br />
|Enregistreur audio<br />
|-<br />
|Outils de bricolage<br />
|Niveau à bulle (3 unités disponibles)<br />
|None<br />
|-<br />
|Outils de bricolage<br />
|Outillage divers<br />
|Divers outils disponibles au local bateau<br />
|-<br />
|Laptop empruntable à l'heure<br />
|PC portable Eustache<br />
|None<br />
|-<br />
|Laptop empruntable à l'heure<br />
|PC portable Félicie<br />
|PC détenu par Kristell pour le moment<br />
|-<br />
|Laptop empruntable à l'heure<br />
|PC portable Gérard<br />
|Inventaire DSI : L100599<br />
|-<br />
|Laptop empruntable à l'heure<br />
|PC portable Jean-Luc<br />
|Utilisé par Hossein actuellement<br />
|-<br />
|Laptop empruntable à l'heure<br />
|PC portable Marguerite<br />
|None<br />
|-<br />
|PC de terrain empruntable à la demi-journée<br />
|PC Terrain Panasonic Touchbook CF-19<br />
|None<br />
|-<br />
|Capteurs de données divers<br />
|Pénétromètre PANDA<br />
|None<br />
|-<br />
|Outils de bricolage<br />
|Perceuse-visseuse Bosh PSB 18<br />
|None<br />
|-<br />
|Capteurs de données divers<br />
|Perche graduée pour granulo photo<br />
|None<br />
|-<br />
|Outils de bricolage<br />
|Perforateur Bosh sans fil 18V<br />
|Perforateur sans fil avec 2 batteries.<br />
|-<br />
|Appareils de mesures<br />
|Peson Kern<br />
|Résolution 5g, Maximum 6kg<br />
|-<br />
|Outils de bricolage<br />
|Petit maillet<br />
|None<br />
|-<br />
|Capteurs de données divers<br />
|Petite antenne RFID circulaire<br />
|None<br />
|-<br />
|Outils de bricolage<br />
|Pistolet à cartouches (2 unités disponibles)<br />
|None<br />
|-<br />
|Accessoires informatiques<br />
|Pointeur Laser n°1<br />
|None<br />
|-<br />
|Accessoires informatiques<br />
|Pointeur Laser n°2<br />
|None<br />
|-<br />
|GPS<br />
|R8 (Trimble) DGPS (chargeur boîte noire)<br />
|None<br />
|-<br />
|GPS<br />
|R8 (Trimble) GNSS (chargeur boîte noire)<br />
|None<br />
|-<br />
|Capteurs de données divers<br />
|RFID boitier TAG Passif : Datamax + boitier Cipam + 2 petits GPS + cables<br />
|None<br />
|-<br />
|Capteurs de données divers<br />
|RFID TAG Actif a-UHF (2 caisses)<br />
|None<br />
|-<br />
|Vêtements (hors EPI)<br />
|Sac à dos étanche ITIWI<br />
|None<br />
|-<br />
|Appareils de mesures<br />
|Sonde Pressler<br />
|None<br />
|-<br />
|PC de terrain empruntable à la demi-journée<br />
|Tablette Terrain Panasonic Touchbook CF-D1<br />
|None<br />
|-<br />
|Enregistreurs vocaux<br />
|Tascam DR-07 n°1<br />
|None<br />
|-<br />
|Vêtements (hors EPI)<br />
|Top thermique de plongée [taille L]<br />
|None<br />
|-<br />
|Vêtements (hors EPI)<br />
|Top thermique de plongée [taille S]<br />
|None<br />
|-<br />
|Accessoires informatiques<br />
|Tour de visioconférence n°1<br />
|None<br />
|-<br />
|Accessoires informatiques<br />
|Tour de visioconférence n°2<br />
|None<br />
|-<br />
|Accessoires photo<br />
|Trépied photo n°1<br />
|<br />
|-<br />
|Accessoires photo<br />
|Trépied photo n°2<br />
|<br />
|-<br />
|Outils de bricolage<br />
|Treuil (2 unités disponibles)<br />
|None<br />
|-<br />
|Equipements de Protection Individuelle<br />
|Trousse de secours terrain<br />
|None<br />
|-<br />
|Vélo<br />
|Vélo cargo Douze Cycles<br />
|None<br />
|-<br />
|Vêtements (hors EPI)<br />
|Veste de plongée [taille 42]<br />
|None<br />
|-<br />
|Vêtements (hors EPI)<br />
|Veste imperméable Quechua [taille L] (2 unités disponibles)<br />
|Veste imperméable achetée en 2022<br />
|-<br />
|Vêtements (hors EPI)<br />
|Veste Millet [taille L]<br />
|None<br />
|-<br />
|Vidéoprojecteur<br />
|Vidéoprojecteur Acer<br />
|None<br />
|-<br />
|Vidéoprojecteur<br />
|Vidéoprojecteur Optoma<br />
|None<br />
|-<br />
|Vêtements (hors EPI)<br />
|Waders néoprène [taille 38-39]<br />
|None<br />
|-<br />
|Vêtements (hors EPI)<br />
|Waders néoprène [taille 40-41] (2 unités disponibles)<br />
|None<br />
|-<br />
|Vêtements (hors EPI)<br />
|Waders néoprène [taille 42-43] (3 unités disponibles)<br />
|Waders achetées en novembre 2022<br />
|-<br />
|Vêtements (hors EPI)<br />
|Waders néoprène [taille 46-47]<br />
|None<br />
|-<br />
|Vêtements (hors EPI)<br />
|Waders [taille 38-39] (5 unités disponibles)<br />
|None<br />
|-<br />
|Vêtements (hors EPI)<br />
|Waders [taille 40-41] (3 unités disponibles)<br />
|None<br />
|-<br />
|Vêtements (hors EPI)<br />
|Waders [taille 42-43] (4 unités disponibles)<br />
|None<br />
|-<br />
|Vêtements (hors EPI)<br />
|Waders [taille 44-45] (2 unités disponibles)<br />
|None<br />
|-<br />
|Bateau<br />
|Yamaha Yam 310 S<br />
|None<br />
|-<br />
|GPS<br />
|Zenith 35 Pro (Geomax) composé de 3 caisses<br />
|None<br />
|}</div>Sdunesmehttps://isig-wiki.ens-lyon.fr/index.php?title=Grraou&diff=1204Grraou2026-02-12T09:54:39Z<p>Sdunesme : </p>
<hr />
<div>Gestion et Réservation des Ressources Actuellement Opérationnelles et Utilisées d'ISIG (grraou ISIG) est la nouvelle plateforme de réservation du matériel d'ISIG. Cette plateforme remplace l'ancien GRR qui ne répondait pas à toutes les attentes, notamment en termes d'ergonomie. <br />
<br />
Elle est accessible à l'adresse https://grraou-isig.ens-lyon.fr :<br />
<br />
* A toute personne ayant un compte ENS de Lyon affecté à EVS.<br />
* A tout personne ayant un compte Personnel des Unités CNRS affecté à EVS.<br />
<br />
Cette plateforme nous permet de suivre l'utilisation du matériel et d'assurer le remplacement du matériel défectueux ou perdu. Son utilisation est obligatoire si vous souhaitez emprunter du [[Materiel|matériel géré par ISIG]]. <br />
<br />
La [[Materiel|liste du matériel]] disponible via Grraou est accessible publiquement [[Materiel|ici]]. <br />
<br />
== Guide d'utilisation ==<br />
<br />
=== Connexion ===<br />
La connexion se fait avec votre nom d'utilisateur et mot de passe ENS habituel. Si vous n'avez pas de compte ENS, un compte externe peut vous être créé par un administrateur grraou.<br />
<br />
=== Tableau de bord ===<br />
[[Fichier:Tableau de bord Grraou.png|centré|sans_cadre|574x574px]]<br />
Les actualités concernant le matériel (pannes, indisponibilités, etc.) s'affichent dans le panneau '''Annonces'''. <br />
<br />
Vos réservations à venir s'affichent dans le panneau '''Réservations à venir''', et les réservations des autres s'affichent dans le dernier panneau '''Toutes les Réservations à venir'''.<br />
<br />
Il est possible d'accéder directement au formulaire de réservation d'une ressource via le panneau '''Disponibilité des Ressources'''. Cependant, l'usage du planning est plus pratique.<br />
<br />
=== Planning et réservation ===<br />
L'onglet Planning vous permet d'accéder au calendrier de vos réservations ('''Mon Calendrier''') ou au calendrier de toutes les réservations d'une ressource ('''Calendrier des Ressources'''). Vous pouvez créer une réservation directement via ces calendriers si vous le souhaitez. Un moteur de recherche de créneaux disponibles est également proposé ('''Trouver une Disponibilité''').<br />
<br />
L'interface principale de réservation est accessible via ce même onglet Planning > '''Réservations'''.<br />
<br />
Deux plannings sont disponibles : le matériel de terrain réservable à la demi-journée et le matériel de labo réservable à l'heure. On passe d'un planning à l'autre avec le menu déroulant en haut de la page.<br />
[[Fichier:Changement de planning.png|centré|sans_cadre]]<br />
Par défaut, une semaine est affichée sur le planning. On change de semaine via le calendrier à côté de ce menu déroulant. Il est également possible d'afficher uniquement certaines dates spécifiques en cochant la case '''Show specific dates''' et en cliquant sur les jours demandés.<br />
<br />
Il y a 4 modes de visualisation du planning : <br />
<br />
* Le '''mode standard''' : les ressources s'affichent en ligne et les créneaux en colonnes.<br />
* Le '''mode étroit''' : les ressources s'affichent en colonnes et les créneaux en lignes.<br />
* Le '''mode large''' : comme le mode standard mais toute la semaine est sur la même ligne.<br />
* Le '''mode compact''' (par défaut) : les jours de la semaine s'affichent en colonnes, les ressources en lignes, et les créneaux dans chaque case.<br />
<br />
On passe d'un mode à l'autre avec les boutons en haut à gauche, au-dessus des filtres. Lorsque vous avez choisi votre préféré, enregistrez le comme par défaut en cliquant sur l'étoile. <br />
[[Fichier:Modes de visualisation du planning.png|centré|sans_cadre]]<br />
Les '''filtres''' à gauche permettent d'alléger le tableau en '''n'affichant que certains types de ressources'''. Des '''packages thématiques''' sont également disponibles pour faciliter votre choix de matériel en fonction de la sortie terrain envisagée.<br />
<br />
En mode standard, étroit ou large, vous pouvez '''cliquer-glisser dans le tableau pour réserver plusieurs créneaux d'un seul coup.''' <br />
<br />
=== Formulaire de réservation ===<br />
[[Fichier:Formulaire de réservation Grraou.png|centré|sans_cadre|539x539px]]<br />
Sur le formulaire de réservation, vous devez choisir une '''date et heure de début et de fin de réservation'''. La durée de la réservation est alors automatiquement calculée. Vous devez également renseigner un '''motif de réservation dans le champ ''Libellé de la réservation'''''.<br />
<br />
Vous pouvez '''ajouter plusieurs ressources''' à votre réservation pour éviter d'avoir à la dupliquer en cliquant sur ''Modifier+'' (au-dessus de la liste des ressources réservées).<br />
<br />
Si vous avez choisi une ressource qui nécessite de '''répartir les coûts de fonctionnement sur les lignes budgétaires''' des utilisateurs, le champ '''''Projet de recherche''''' apparaitra et devra être obligatoirement renseigné avec les détails de votre ligne de budget. <br />
<br />
Vous pouvez également '''ajouter des accessoires''' aux ressources réservées (à côté de la liste des ressources). '''Certains accessoires sont obligatoires avec certaines ressources''' (des rames avec un bateau par exemple). Si c'est le cas, un message d'erreur avec le détail des accessoires obligatoires apparaitra à la validation du formulaire. Certaines ressources sont aussi disponibles en plusieurs exemplaires. Il faudra donc préciser le nombre d'unités empruntées en ajoutant des accessoires.<br />
<br />
Vous pouvez '''ajouter des participants''' à votre réservation dans le champ ''Liste des participants'' si ces derniers ont déjà un compte Grraou. Si ce n'est pas le cas, ajoutez-les en tant que ''Guest'' dans le champ ''Invités''.<br />
<br />
Enfin, vous avez la possibilité de '''régler un rappel par mail''' avant le début et la fin de votre réservation dans la section ''Send Reminder''.<br />
<br />
En cliquant sur le bouton ''Créer'', si une des ressources choisies nécessite validation, votre réservation passera en mode "en attente de modération" (les modérateurs reçoivent automatiquement une notification). Si ce n'est pas le cas, elle sera directement validée et visible par tous.<br />
<br />
=== Éditer votre réservation ===<br />
En passant par le tableau de bord, le planning ou les calendriers, vous avez la possibilité d''''éditer vos réservations vous-même'''. Si une des ressources choisies nécessite validation, il faudra que les responsables matos concernés valident votre modification. <br />
<br />
Pour '''annuler une réservation''', cliquez sur le bouton ''Plus'', puis sur ''Effacer''.<br />
[[Fichier:Annuler une réservation.png|centré|sans_cadre|253x253px]]<br />
<br />
== Guide d'administration ==<br />
Cette section s'adresse uniquement aux administrateurs et aux responsables matos.<br />
<br />
=== Utilisateurs et groupes ===<br />
Il y a trois niveaux de droits d'utilisateurs :<br />
<br />
* Les administrateurs de l'application<br />
* Les responsables de matériel<br />
* Les utilisateurs</div>Sdunesmehttps://isig-wiki.ens-lyon.fr/index.php?title=Accueil&diff=1203Accueil2026-02-12T09:52:48Z<p>Sdunesme : /* ✍️ Contribuer */</p>
<hr />
<div>__NOTOC__<br />
<br />
Bienvenue sur le wiki d'[[ISIG]] !<br />
== Objectifs==<br />
Ce site, conçu comme un '''carnet de notes partagé''' au sein de l'équipe et des collaborateurs d'[[ISIG]], est destiné à rassembler les informations relatives aux<br />
* 🤝 <strong>fonctionnement de laboratoire</strong>, <br />
* 🔧 <strong>notes techniques</strong> <br />
* 📃 <strong>documentation et liens</strong><br />
<br />
Le monde entier peut <strong>lire et modifier</strong> ce wiki (à l'exception de quelques pages à l'accès restreint)! Vous êtes bien entendus invités à l'enrichir vous aussi !<br />
<br />
<div id="l2" class="mainpage_row"><br />
<div class="mainpage_box"><br />
<h3>🧑🤝🧑<span> Vie d'ISIG</span></h3><br />
* 🕸️ [[reseaux| Réseaux scientifiques (séminaires, formations)]]<br />
<br />
🔑 [[Pages à accès restreint|Accès réservé]] aux utilisateurs identifiés:<br />
<br />
* 💸 [[Restreint:Idees achats|Besoins matériels et suggestions d'achats]]<br />
* 📝 [[Restreint:Procedures admin|Procédures administratives]]<br />
* 💰 [[Restreint:Appels à projets|Appels à projets]]<br />
* 🚶 [[Restreint:Historique des contrats courts|Historique des contrats courts]]<br />
* 🙋♂️ [[Restreint:PresenceLabo|Présence au labo]]<br />
* 👷 [[Restreint:ISIG pages internes|ISIG: pages internes]]<br />
<br />
</div><br />
<div class="mainpage_box"><br />
<h3>📃<span> Ressources d'ISIG</span></h3><br />
<br />
🗃️ [[:Catégorie:Tutoriel|Tutothèque]]<br />
<br />
🤯 [[Formations]]<br />
<br />
📜 [[Inventaires]] de données<br />
<br />
🔨 [[Materiel|Matériel empruntable]]<br />
<br />
🗣️ [[Discord ISIG|Discord ISIG et discussions]]<br />
<br />
👶 [[Guide des nouveaux arrivants]]<br />
</div><br />
<div class="mainpage_box"><br />
<h3>🖥️ <span>Outils d'ISIG</span></h3><br />
🗣️ [[Discord ISIG]]<br />
<br />
🗄️ [[Serveur de fichiers EVS]]<br />
<br />
⚙️ [[Serveurs de calcul|Serveurs de calcul et machines à grosses configurations]]<br />
<br />
💧 [[Fluvial Corridor Toolbox]]<br />
<br />
📦 [[Packages R]]<br />
<br />
💿 [[:Catégorie:Licences logicielles|Licences logicielles]]<br />
<br />
<br />
[[:Catégorie:Outils|🔧 Voir tous les outils]]<br />
<br />
</div></div><br />
<br />
== ✍️ <span>Contribuer</span> ==<br />
Vous souhaitez contribuer au wiki [[ISIG]] ? C'est une excellente nouvelle ! 🎉<br />
<br />
Pour bien débuter, vous pouvez vous aider des 👉 [[tuto_wiki| quelques conseils listés ici]]. <br />
<br />
Bonne rédaction !<br />
== Actualités ==<br />
ℹ️ Nouveauté : Il est désormais nécessaire de se connecter au wiki via idEVS, avec votre compte ENS ou votre compte Personnel des Unités CNRS affecté à EVS. <br />
<br />
<br />
Vous trouverez ci-dessous les modifications récentes qui ont eu lieues sur le wiki.<br />
<br />
{{Special:RecentChanges/50}}</div>Sdunesmehttps://isig-wiki.ens-lyon.fr/index.php?title=Accueil&diff=1202Accueil2026-02-12T09:51:57Z<p>Sdunesme : /* Actualités */</p>
<hr />
<div>__NOTOC__<br />
<br />
Bienvenue sur le wiki d'[[ISIG]] !<br />
== Objectifs==<br />
Ce site, conçu comme un '''carnet de notes partagé''' au sein de l'équipe et des collaborateurs d'[[ISIG]], est destiné à rassembler les informations relatives aux<br />
* 🤝 <strong>fonctionnement de laboratoire</strong>, <br />
* 🔧 <strong>notes techniques</strong> <br />
* 📃 <strong>documentation et liens</strong><br />
<br />
Le monde entier peut <strong>lire et modifier</strong> ce wiki (à l'exception de quelques pages à l'accès restreint)! Vous êtes bien entendus invités à l'enrichir vous aussi !<br />
<br />
<div id="l2" class="mainpage_row"><br />
<div class="mainpage_box"><br />
<h3>🧑🤝🧑<span> Vie d'ISIG</span></h3><br />
* 🕸️ [[reseaux| Réseaux scientifiques (séminaires, formations)]]<br />
<br />
🔑 [[Pages à accès restreint|Accès réservé]] aux utilisateurs identifiés:<br />
<br />
* 💸 [[Restreint:Idees achats|Besoins matériels et suggestions d'achats]]<br />
* 📝 [[Restreint:Procedures admin|Procédures administratives]]<br />
* 💰 [[Restreint:Appels à projets|Appels à projets]]<br />
* 🚶 [[Restreint:Historique des contrats courts|Historique des contrats courts]]<br />
* 🙋♂️ [[Restreint:PresenceLabo|Présence au labo]]<br />
* 👷 [[Restreint:ISIG pages internes|ISIG: pages internes]]<br />
<br />
</div><br />
<div class="mainpage_box"><br />
<h3>📃<span> Ressources d'ISIG</span></h3><br />
<br />
🗃️ [[:Catégorie:Tutoriel|Tutothèque]]<br />
<br />
🤯 [[Formations]]<br />
<br />
📜 [[Inventaires]] de données<br />
<br />
🔨 [[Materiel|Matériel empruntable]]<br />
<br />
🗣️ [[Discord ISIG|Discord ISIG et discussions]]<br />
<br />
👶 [[Guide des nouveaux arrivants]]<br />
</div><br />
<div class="mainpage_box"><br />
<h3>🖥️ <span>Outils d'ISIG</span></h3><br />
🗣️ [[Discord ISIG]]<br />
<br />
🗄️ [[Serveur de fichiers EVS]]<br />
<br />
⚙️ [[Serveurs de calcul|Serveurs de calcul et machines à grosses configurations]]<br />
<br />
💧 [[Fluvial Corridor Toolbox]]<br />
<br />
📦 [[Packages R]]<br />
<br />
💿 [[:Catégorie:Licences logicielles|Licences logicielles]]<br />
<br />
<br />
[[:Catégorie:Outils|🔧 Voir tous les outils]]<br />
<br />
</div></div><br />
<br />
== ✍️ <span>Contribuer</span> ==<br />
Vous souhaitez contribuer au wiki [[ISIG]] ? C'est une excellente nouvelle ! 🎉<br />
<br />
Pour bien débuter, nous vous conseillons de [[Spécial:Créer un compte|créer un compte]] afin de pouvoir suivre vos pages modifiées, vous identifier auprès de vos lecteurs, etc. <br />
<br />
Ensuite, vous pouvez vous lancer en vous aidant des 👉 [[tuto_wiki| quelques conseils listés ici]].<br />
<br />
Bonne rédaction !<br />
== Actualités ==<br />
ℹ️ Nouveauté : Il est désormais nécessaire de se connecter au wiki via idEVS, avec votre compte ENS ou votre compte Personnel des Unités CNRS affecté à EVS. <br />
<br />
<br />
Vous trouverez ci-dessous les modifications récentes qui ont eu lieues sur le wiki.<br />
<br />
{{Special:RecentChanges/50}}</div>Sdunesmehttps://isig-wiki.ens-lyon.fr/index.php?title=Fichier:Glourbee.png&diff=1201Fichier:Glourbee.png2026-01-26T09:15:49Z<p>Sdunesme : </p>
<hr />
<div></div>Sdunesmehttps://isig-wiki.ens-lyon.fr/index.php?title=Fichier:Chrono-Rhone.png&diff=1200Fichier:Chrono-Rhone.png2026-01-26T08:42:04Z<p>Sdunesme : </p>
<hr />
<div></div>Sdunesmehttps://isig-wiki.ens-lyon.fr/index.php?title=ISIG&diff=1189ISIG2025-12-17T09:43:01Z<p>Sdunesme : </p>
<hr />
<div>{{#evu:https://www.youtube.com/watch?v=lDOx8D-VHSo<br />
|alignment=right<br />
}}<br />
<br />
La plateforme ISIG est un lieu de production, de partage, d'échanges et de mise en réseau des membres de l'UMR 5600 "Environnement Ville Société" travaillant dans le domaine de l'imagerie, de la géomatique et de champs connexes.<br />
[[Fichier:Compétences ISIG.png|gauche|vignette]]<br />
<br />
Elle est composée d’ingénieur.e.s dont les compétences couvrent l’ensemble des compétences du domaine de la géomatique et proposent aux membres de l’UMR :<br />
<br />
* un soutien technique et méthodologique en géomatique,<br />
* le développement d’outils génériques de traitement de l’information spatialisée,<br />
* des cycles de formation méthodologiques et techniques à destination des chercheurs et des ateliers spécifiques pour les doctorants,<br />
* une veille technologique dans le domaine de la télédétection et des Systèmes d'Information Géographique.<br />
<br />
La plateforme a pour vocation de construire des outils spécifiques transversaux, comme par exemple des portails collaboratifs pour la mutualisation des données. Elle s’articule avec une équipe de recherche active dans ce domaine regroupée au sein de l'atelier Spatialités Numériques et Géomatique (SN&G).<br />
[[Catégorie:Vie du laboratoire]]</div>Sdunesmehttps://isig-wiki.ens-lyon.fr/index.php?title=Fichier:Comp%C3%A9tences_ISIG.png&diff=1188Fichier:Compétences ISIG.png2025-12-17T09:41:39Z<p>Sdunesme : </p>
<hr />
<div></div>Sdunesmehttps://isig-wiki.ens-lyon.fr/index.php?title=ShinyProxy&diff=1106ShinyProxy2025-06-03T09:03:11Z<p>Sdunesme : /* Configuration de l'application sur le serveur ShinyProxy de production */</p>
<hr />
<div>'''<big>Attention : Page en cours de rédaction</big>'''<br />
<br />
ISIG-Apps passe sous ShinyProxy pour améliorer la stabilité et l'isolation de vos applications pendant les montées en charge. Le fonctionnement est très différent par rapport à l'ancien Shiny-Server et nécessite quelques bases dans l'utilisation de Docker. L'objectif de cette page est de vous guider, rapidement et simplement, dans le nouveau workflow dev > prod en partant du principe que vous ne connaissez encore pas grand-chose à Docker.<br />
<br />
== Principe de fonctionnement de ShinyProxy (et Docker) ==<br />
ShinyProxy fonctionne comme un orchestrateur de conteneurs Docker. Chaque appli configurée doit avoir une image Docker associée présente sur le serveur qui exécute ShinyProxy. C'est ShinyProxy qui s'occupera ensuite de lancer et stopper un conteneur à chaque fois qu'un internaute se connectera ou se déconnectera de votre appli. <br />
[[Fichier:Schéma Docker.png|centré|sans_cadre|1054x1054px]] <br />
<br />
Afin que votre application puisse fonctionner sur ShinyProxy, il va donc falloir créer une '''image''' qui permettra au serveur ShinyProxy de lancer des '''containers''' de votre application. <br />
<br />
Vous n'aurez généralement pas besoin de volume pour stocker des données pérennes dans le cas d'une application Shiny. Si votre application utilise une base de données, celle-ci devra être externalisée (hébergée sur le serveur de bases de données d'ISIG par exemple). <br />
<br />
ShinyProxy fera en sorte qu'un certain nombre de containers (à définir dans la configuration décrite à la fin de ce tutoriel) soient toujours disponibles pour de nouveaux utilisateurs qui se connecteraient à votre application. Il s'occupera également de supprimer les containers quand vos utilisateurs se déconnectent. <br />
<br />
== Conteneurisation de votre appli Shiny ==<br />
La conteneurisation peut se faire directement sur votre machine personelle si vous y avez installé Docker (https://docs.docker.com/engine/install/), ou sur le serveur isig-apps de dev via [https://rstudio.evs.ens-lyon.fr Rstudio server] et son terminal intégré.<br />
<br />
=== Fixer le port ===<br />
Pour fonctionner en mode conteneurisé, votre application devra écouter toujours sur le même port (ce qui n'est pas le comportement par défaut d'une application Shiny). <br />
<br />
Afin de s'en assurer, il faut : <br />
<br />
* Dans le cas d'un appli Shiny classique, ajouter dans <code>options(..)</code>, avant l'appel de <code>shinyApp(..)</code>, les options suivantes : <code>"shiny.port"=3841</code> et <code>"shiny.host"="0.0.0.0"</code>. Par exemple :<br />
<syntaxhighlight lang="r"><br />
library(shiny)<br />
library(glourbi)<br />
<br />
# Dans cet exemple, l'application écoutera systématiquement sur le port 3838<br />
options("shiny.port" = 3838, "shiny.host" = "0.0.0.0", "golem.app.prod" = TRUE)<br />
<br />
shinyApp(ui=glourbapp:::app_ui,server=glourbapp:::app_server)<br />
</syntaxhighlight><br />
<br />
* Dans le cas d'un document Rmarkdown, ........<br />
<br />
=== Choisir l'image source ===<br />
La construction d'une image Docker se fait sur la base... d'une autre. On choisi en général son image de base en fonction de ce qu'on va faire avec. Pour une application Shiny, nous aurons besoin d'une image Docker spécialisée en R. <br />
<br />
Le [https://rocker-project.org/images/ projet Rocker] propose plusieurs images de base avec différentes quantités de packages pré-installés. Lorsque l'on choisi son image de base, il faut trouver le bon compromis entre une image légère et une image avec suffisamment de dépendances pré-installées pour qu'elle soit pratique.<br />
<br />
L'image [https://eddelbuettel.github.io/r2u/ r2u] est une bonne base assez simple à utiliser, car elle va chercher des binaires précompilés des packages R que l'on souhaite installer et toutes leurs dépendances, librairies système incluses ! Pratiquement rien n'y est pré-installé, il faudra donc bien préciser toutes les dépendances dont vous avez besoin. En contrepartie, l'image sera plutôt légère, ce qui est une bonne chose ! L'inconvénient de cette fonctionnalité est (à ma connaissance) qu'elle ne fonctionne qu'avec la fonction <code>install.packages(...)</code>. Il n'est donc pas possible d'installer une version spécifique d'un package avec <code>remotes::install_version(...)</code> par exemple (la fonction reste utilisable de manière classique). <br />
<br />
=== Écrire le Dockerfile ===<br />
<br />
La création d'une image Docker repose sur l'écriture d'un fichier texte appelé '''Dockerfile''' (sans extension).<br />
<br />
Voici un exemple de Dockerfile pour l'application GloUrb :<syntaxhighlight lang="dockerfile"><br />
# On commence par définir l'image sur laquelle va se baser la notre<br />
FROM rocker/r2u:jammy<br />
<br />
# On précise quelques infos qui permettrons d'identifier l'image<br />
LABEL org.opencontainers.image.authors="Lise Vaudor <lise.vaudor@ens-lyon.fr>, Samuel Dunesme <samuel.dunesme@ens-lyon.fr>"<br />
LABEL org.opencontainers.image.source="https://github.com/glourb/glourbapp"<br />
LABEL org.opencontainers.image.documentation="https://evs-gis.github.io/glourbdoc/"<br />
LABEL org.opencontainers.image.version="0.0.0.9000"<br />
LABEL org.opencontainers.image.description="An app for the GloUrb project"<br />
<br />
# On peut éventuellement générer des locales supplémentaires si notre appli utilise d'autres langues que l'anglais<br />
RUN locale-gen fr_FR.UTF-8<br />
<br />
# On liste maintenant toutes les dépendances R à installer<br />
RUN Rscript -e 'install.packages("tidyr")'<br />
RUN Rscript -e 'install.packages("shiny")'<br />
RUN Rscript -e 'install.packages("config")'<br />
RUN Rscript -e 'install.packages("testthat")'<br />
RUN Rscript -e 'install.packages("tibble")'<br />
RUN Rscript -e 'install.packages("purrr")'<br />
RUN Rscript -e 'install.packages("dplyr")'<br />
RUN Rscript -e 'install.packages("ggplot2")'<br />
RUN Rscript -e 'install.packages("forcats")'<br />
RUN Rscript -e 'install.packages("magrittr")'<br />
RUN Rscript -e 'install.packages("golem")'<br />
RUN Rscript -e 'install.packages("sf")'<br />
RUN Rscript -e 'install.packages("plotly")'<br />
RUN Rscript -e 'install.packages("spelling")'<br />
RUN Rscript -e 'install.packages("mclust")'<br />
RUN Rscript -e 'install.packages("leaflet")'<br />
RUN Rscript -e 'install.packages("cluster")'<br />
RUN Rscript -e 'install.packages("cowplot")'<br />
RUN Rscript -e 'install.packages("FactoMineR")'<br />
RUN Rscript -e 'install.packages("glue")'<br />
RUN Rscript -e 'install.packages("grDevices")'<br />
RUN Rscript -e 'install.packages("RColorBrewer")'<br />
RUN Rscript -e 'install.packages("remotes")'<br />
RUN Rscript -e 'install.packages("cicerone")'<br />
RUN Rscript -e 'install.packages("RPostgres")'<br />
RUN Rscript -e 'install.packages("DBI")'<br />
RUN Rscript -e 'install.packages("DT")'<br />
<br />
RUN Rscript -e 'remotes::install_github("glourb/glourbi")'<br />
<br />
# On copie l'arborescence de fichiers dans un dossier app à la racine de l'image. Ce sera le working directory des containers lancés avec notre image<br />
RUN mkdir /app<br />
ADD . /app<br />
WORKDIR /app<br />
<br />
# Si besoin, on peut installer notre package<br />
RUN R -e 'remotes::install_local()'<br />
<br />
# On détermine le port qui sera exposé (attention à bien fixer le port sur lequel votre appli écoute, cf. ci-dessus)<br />
EXPOSE 3838<br />
<br />
# Pour plus de sécurité, on fait en sorte que les containers ne se lancent pas avec l'utilisateur "root", mais avec un utilisateur "app" dédié<br />
RUN groupadd -g 1010 app && useradd -c 'app' -u 1010 -g 1010 -m -d /home/app -s /sbin/nologin app<br />
USER app<br />
<br />
# Enfin, on précise la commande qui permet de lancer notre appli. C'est cette commande qui sera lancée par défaut par tout nouveau container lancé avec notre image<br />
CMD ["R", "-f", "app.R"]<br />
</syntaxhighlight><br />
<br />
=== Construire l'image Docker ===<br />
Pour construire l'image docker à l'aide du Dockerfile, il faut lancer la commande <code>docker build</code>. C'est à ce moment que l'on va versionner l'image en la taguant avec l'argument <code>-t</code>. On peut mettre directement plusieurs tags à une image, ou les ajouter à posteriori en relançant la commande <code>docker build</code>. Si le Dockerfile n'a pas changé depuis le dernier build, <code>docker build</code> ne fera qu'ajouter les tags à l'image existante. <br />
<br />
Pour que la CLI Docker trouve bien le Dockerfile, on lance le terminal dans le dossier ou ce Dockerfile est enregistré. <br />
<br />
<code>docker build . -t ghcr.io/evs-gis/mapdoapp:latest -t ghcr.io/evs-gis/mapdoapp:2.0.1 -t ghcr.io/evs-gis/mapdoapp:$(git rev-parse --short HEAD)</code><br />
<br />
Remarquez que le tag doit contenir le chemin complet vers le registre où sera poussée l'image (étape suivante). Si vous ne précisez pas le chemin (par exemple <code>mapdoapp:latest</code>), le registre utilisé sera DockerHub. <br />
<br />
Notez le tag <code>$(git rev-parse --short HEAD)</code> qui permet de taguer l'image avec le hash (la référence) du commit actuel (ne fonctionne que si vous êtes dans un dépôt git). Ce tag est bien pratique si vous n'incrémentez pas un numéro de version par ailleurs (<code>2.0.1</code> dans l'exemple ci-dessus). <br />
<br />
Le tag <code>latest</code> est à mettre sur la dernière version de votre image. Il sera automatiquement retiré de toutes les autres versions de votre image. <br />
<br />
La commande <code>docker images</code> permet ensuite de lister les tags disponibles localement. Si le build a réussi, vous devriez y voir votre image.<syntaxhighlight lang="bash"><br />
~$ docker images<br />
REPOSITORY TAG IMAGE ID CREATED SIZE<br />
ghcr.io/evs-gis/mapdoapp 2.0.1 b2b999e7d781 3 days ago 1.27GB<br />
ghcr.io/evs-gis/mapdoapp 7ad814c b2b999e7d781 3 days ago 1.27GB<br />
ghcr.io/evs-gis/mapdoapp latest b2b999e7d781 3 days ago 1.27GB<br />
ghcr.io/glourb/glourbapp 642e23b 8a3daa97546e 4 days ago 1.38GB<br />
ghcr.io/glourb/glourbapp latest 8a3daa97546e 4 days ago 1.38GB<br />
ghcr.io/glourb/glourbapp 502564d 9a2050fc09d4 4 days ago 1.38GB<br />
semaphoreui/semaphore v2.12.4 136bec584184 2 weeks ago 727MB<br />
ghcr.io/mastergeonum/cartondes main a95ee654e34a 5 weeks ago 205MB<br />
dockurr/windows latest c3419fd6e55a 2 months ago 384MB<br />
docker.osgeo.org/geoserver 2.26.1 a91188b23092 3 months ago 608MB<br />
rocker/verse 4.4.1 202c993befdc 3 months ago 3.77GB<br />
ghcr.io/evs-gis/glourbee-ui 1.1.0 03e05bed5617 4 months ago 1.47GB<br />
<br />
</syntaxhighlight>Remarquez que <code>ghcr.io/evs-gis/mapdoapp</code> est présente plusieurs fois avec des tags différents, mais le même IMAGE ID. Il s'agit bien de la même image et elle n'est pas dupliquée sur le disque.<br />
<br />
Pour supprimer un tag, on utilisera la commande <code>docker image rm ghcr.io/evs-gis/mapdoapp:2.0.1</code>. Si plus aucun tag n'existe pour l'image, elle sera complètement supprimée du disque local. <br />
<br />
=== Tester l'image ===<br />
Pour tester son image, on peut utiliser la commande <code>docker run</code> :<br />
<br />
<code>docker run --rm -p 3838:3838 ghcr.io/evs-gis/mapdoapp:latest</code><br />
<br />
* --rm : Supprimer le container lorsqu'il est arrêté.<br />
* -p 3838:3838 : exposer le port 3838 local et le faire pointer vers le port 3838 dans le container.<br />
<br />
Les logs de l'application s'affichent dans le terminal et l'application est accessible dans un navigateur à l'adresse http://localhost:3838. Pour stopper le container, '''Ctrl+C'''.<br />
<br />
=== Faire du ménage localement ===<br />
Il arrive que des vieilles images sans tag, de vieux volumes et de vieux containers plantés restent sur le disque au fil du temps. Tester la commande <code>docker ps --all</code> par exemple, pour lister tous les containers locaux (lancés ou stoppés). La commande <code>docker system prune</code> permet de faire le grand ménage.<br />
<br />
=== Pousser l'image sur un registre ===<br />
Pour que le serveur ShinyProxy (ainsi que le monde entier !) puisse accéder à votre image, il faut la pousser sur un registre. Si vous ne souhaitez pas que votre image soit publique, vous pouvez utiliser le registre ghcr.io/evs-gis (le serveur ShinyProxy y a accès même si les images sont privées). <br />
<br />
Il faut d'abord se loguer sur le registre avec son login GitHub habituel, et un ''Personal Access Token'' en guise de mot de passe. Pour [https://github.com/settings/tokens/new obtenir un ''Personal Access Token''], rendez-vous [https://github.com/settings/tokens/new ici] et activez bien le droit <code>write:packages</code> pour votre token. <syntaxhighlight lang="sh"><br />
# La commande suivante est à lancer pour se loguer sur le registre. Il n'est pas nécessaire de la relancer à chaque fois.<br />
docker login ghcr.io<br />
<br />
# Pour pousser tous les tags de notre image sur le registre, on utilise ensuite la commande suivante.<br />
docker push ghcr.io/evs-gis/mapdoapp -a<br />
<br />
# Pour pousser seulement un tag spécifique, on préfèrera la commande suivante.<br />
docker push ghcr.io/evs-gis/mapdoapp:latest<br />
</syntaxhighlight><br />
<br />
== Configuration de l'application sur le serveur ShinyProxy de production ==<br />
La configuration initiale de l'application doit être faite par l'administrateur du serveur.<br />
<br />
== Mise à jour d'une appli ==<br />
La mise à jour d'une appli sur le serveur de prod ne nécessite généralement pas de modifier la configuration. Il suffit de '''pousser la nouvelle version de votre image sur votre registre''' (avec le tag latest), puis de '''lancer le job ''Mise à jour d'une application en production sous ShinyProxy'' sur Jenkins''' pour forcer le redémarrage des containers d'attente déjà lancés. Si l'intégration continue a été correctement configurée, le job Jenkins de mise à jour devrait se lancer automatiquement dès que la nouvelle version de l'image arrive sur le registre. <br />
[[Catégorie:Tutoriel]]</div>Sdunesmehttps://isig-wiki.ens-lyon.fr/index.php?title=Formations&diff=1098Formations2025-03-27T13:24:30Z<p>Sdunesme : </p>
<hr />
<div>== Formations ISIG 2025 ==<br />
Les formations proposées par ISIG en 2025 sont visibles sur l'[https://umr5600.cnrs.fr/fr/support-technique/imagerie-et-systemes-dinformation-geographiques/isig-les-formations/isig-agenda-des-formations/ Agenda des formations ISIG].<br />
<br />
== Anciennes formations ISIG ==<br />
{| class="wikitable"<br />
|+<br />
!Formation<br />
!Dates<br />
!Format.eur.rice.s<br />
!Description<br />
|-<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
|<br />
|<br />
|<br />
|<br />
|-<br />
|<br />
|<br />
|<br />
|<br />
|}</div>Sdunesmehttps://isig-wiki.ens-lyon.fr/index.php?title=ShinyProxy&diff=1086ShinyProxy2025-03-24T12:02:06Z<p>Sdunesme : /* Pousser l'image sur un registre */</p>
<hr />
<div>'''<big>Attention : Page en cours de rédaction</big>'''<br />
<br />
ISIG-Apps passe sous ShinyProxy pour améliorer la stabilité et l'isolation de vos applications pendant les montées en charge. Le fonctionnement est très différent par rapport à l'ancien Shiny-Server et nécessite quelques bases dans l'utilisation de Docker. L'objectif de cette page est de vous guider, rapidement et simplement, dans le nouveau workflow dev > prod en partant du principe que vous ne connaissez encore pas grand-chose à Docker.<br />
<br />
== Principe de fonctionnement de ShinyProxy (et Docker) ==<br />
ShinyProxy fonctionne comme un orchestrateur de conteneurs Docker. Chaque appli configurée doit avoir une image Docker associée présente sur le serveur qui exécute ShinyProxy. C'est ShinyProxy qui s'occupera ensuite de lancer et stopper un conteneur à chaque fois qu'un internaute se connectera ou se déconnectera de votre appli. <br />
[[Fichier:Schéma Docker.png|centré|sans_cadre|1054x1054px]] <br />
<br />
Afin que votre application puisse fonctionner sur ShinyProxy, il va donc falloir créer une '''image''' qui permettra au serveur ShinyProxy de lancer des '''containers''' de votre application. <br />
<br />
Vous n'aurez généralement pas besoin de volume pour stocker des données pérennes dans le cas d'une application Shiny. Si votre application utilise une base de données, celle-ci devra être externalisée (hébergée sur le serveur de bases de données d'ISIG par exemple). <br />
<br />
ShinyProxy fera en sorte qu'un certain nombre de containers (à définir dans la configuration décrite à la fin de ce tutoriel) soient toujours disponibles pour de nouveaux utilisateurs qui se connecteraient à votre application. Il s'occupera également de supprimer les containers quand vos utilisateurs se déconnectent. <br />
<br />
== Conteneurisation de votre appli Shiny ==<br />
La conteneurisation peut se faire directement sur votre machine personelle si vous y avez installé Docker (https://docs.docker.com/engine/install/), ou sur le serveur isig-apps de dev via [https://rstudio.evs.ens-lyon.fr Rstudio server] et son terminal intégré.<br />
<br />
=== Fixer le port ===<br />
Pour fonctionner en mode conteneurisé, votre application devra écouter toujours sur le même port (ce qui n'est pas le comportement par défaut d'une application Shiny). <br />
<br />
Afin de s'en assurer, il faut : <br />
<br />
* Dans le cas d'un appli Shiny classique, ajouter dans <code>options(..)</code>, avant l'appel de <code>shinyApp(..)</code>, les options suivantes : <code>"shiny.port"=3841</code> et <code>"shiny.host"="0.0.0.0"</code>. Par exemple :<br />
<syntaxhighlight lang="r"><br />
library(shiny)<br />
library(glourbi)<br />
<br />
# Dans cet exemple, l'application écoutera systématiquement sur le port 3838<br />
options("shiny.port" = 3838, "shiny.host" = "0.0.0.0", "golem.app.prod" = TRUE)<br />
<br />
shinyApp(ui=glourbapp:::app_ui,server=glourbapp:::app_server)<br />
</syntaxhighlight><br />
<br />
* Dans le cas d'un document Rmarkdown, ........<br />
<br />
=== Choisir l'image source ===<br />
La construction d'une image Docker se fait sur la base... d'une autre. On choisi en général son image de base en fonction de ce qu'on va faire avec. Pour une application Shiny, nous aurons besoin d'une image Docker spécialisée en R. <br />
<br />
Le [https://rocker-project.org/images/ projet Rocker] propose plusieurs images de base avec différentes quantités de packages pré-installés. Lorsque l'on choisi son image de base, il faut trouver le bon compromis entre une image légère et une image avec suffisamment de dépendances pré-installées pour qu'elle soit pratique.<br />
<br />
L'image [https://eddelbuettel.github.io/r2u/ r2u] est une bonne base assez simple à utiliser, car elle va chercher des binaires précompilés des packages R que l'on souhaite installer et toutes leurs dépendances, librairies système incluses ! Pratiquement rien n'y est pré-installé, il faudra donc bien préciser toutes les dépendances dont vous avez besoin. En contrepartie, l'image sera plutôt légère, ce qui est une bonne chose ! L'inconvénient de cette fonctionnalité est (à ma connaissance) qu'elle ne fonctionne qu'avec la fonction <code>install.packages(...)</code>. Il n'est donc pas possible d'installer une version spécifique d'un package avec <code>remotes::install_version(...)</code> par exemple (la fonction reste utilisable de manière classique). <br />
<br />
=== Écrire le Dockerfile ===<br />
<br />
La création d'une image Docker repose sur l'écriture d'un fichier texte appelé '''Dockerfile''' (sans extension).<br />
<br />
Voici un exemple de Dockerfile pour l'application GloUrb :<syntaxhighlight lang="dockerfile"><br />
# On commence par définir l'image sur laquelle va se baser la notre<br />
FROM rocker/r2u:jammy<br />
<br />
# On précise quelques infos qui permettrons d'identifier l'image<br />
LABEL org.opencontainers.image.authors="Lise Vaudor <lise.vaudor@ens-lyon.fr>, Samuel Dunesme <samuel.dunesme@ens-lyon.fr>"<br />
LABEL org.opencontainers.image.source="https://github.com/glourb/glourbapp"<br />
LABEL org.opencontainers.image.documentation="https://evs-gis.github.io/glourbdoc/"<br />
LABEL org.opencontainers.image.version="0.0.0.9000"<br />
LABEL org.opencontainers.image.description="An app for the GloUrb project"<br />
<br />
# On peut éventuellement générer des locales supplémentaires si notre appli utilise d'autres langues que l'anglais<br />
RUN locale-gen fr_FR.UTF-8<br />
<br />
# On liste maintenant toutes les dépendances R à installer<br />
RUN Rscript -e 'install.packages("tidyr")'<br />
RUN Rscript -e 'install.packages("shiny")'<br />
RUN Rscript -e 'install.packages("config")'<br />
RUN Rscript -e 'install.packages("testthat")'<br />
RUN Rscript -e 'install.packages("tibble")'<br />
RUN Rscript -e 'install.packages("purrr")'<br />
RUN Rscript -e 'install.packages("dplyr")'<br />
RUN Rscript -e 'install.packages("ggplot2")'<br />
RUN Rscript -e 'install.packages("forcats")'<br />
RUN Rscript -e 'install.packages("magrittr")'<br />
RUN Rscript -e 'install.packages("golem")'<br />
RUN Rscript -e 'install.packages("sf")'<br />
RUN Rscript -e 'install.packages("plotly")'<br />
RUN Rscript -e 'install.packages("spelling")'<br />
RUN Rscript -e 'install.packages("mclust")'<br />
RUN Rscript -e 'install.packages("leaflet")'<br />
RUN Rscript -e 'install.packages("cluster")'<br />
RUN Rscript -e 'install.packages("cowplot")'<br />
RUN Rscript -e 'install.packages("FactoMineR")'<br />
RUN Rscript -e 'install.packages("glue")'<br />
RUN Rscript -e 'install.packages("grDevices")'<br />
RUN Rscript -e 'install.packages("RColorBrewer")'<br />
RUN Rscript -e 'install.packages("remotes")'<br />
RUN Rscript -e 'install.packages("cicerone")'<br />
RUN Rscript -e 'install.packages("RPostgres")'<br />
RUN Rscript -e 'install.packages("DBI")'<br />
RUN Rscript -e 'install.packages("DT")'<br />
<br />
RUN Rscript -e 'remotes::install_github("glourb/glourbi")'<br />
<br />
# On copie l'arborescence de fichiers dans un dossier app à la racine de l'image. Ce sera le working directory des containers lancés avec notre image<br />
RUN mkdir /app<br />
ADD . /app<br />
WORKDIR /app<br />
<br />
# Si besoin, on peut installer notre package<br />
RUN R -e 'remotes::install_local()'<br />
<br />
# On détermine le port qui sera exposé (attention à bien fixer le port sur lequel votre appli écoute, cf. ci-dessus)<br />
EXPOSE 3838<br />
<br />
# Pour plus de sécurité, on fait en sorte que les containers ne se lancent pas avec l'utilisateur "root", mais avec un utilisateur "app" dédié<br />
RUN groupadd -g 1010 app && useradd -c 'app' -u 1010 -g 1010 -m -d /home/app -s /sbin/nologin app<br />
USER app<br />
<br />
# Enfin, on précise la commande qui permet de lancer notre appli. C'est cette commande qui sera lancée par défaut par tout nouveau container lancé avec notre image<br />
CMD ["R", "-f", "app.R"]<br />
</syntaxhighlight><br />
<br />
=== Construire l'image Docker ===<br />
Pour construire l'image docker à l'aide du Dockerfile, il faut lancer la commande <code>docker build</code>. C'est à ce moment que l'on va versionner l'image en la taguant avec l'argument <code>-t</code>. On peut mettre directement plusieurs tags à une image, ou les ajouter à posteriori en relançant la commande <code>docker build</code>. Si le Dockerfile n'a pas changé depuis le dernier build, <code>docker build</code> ne fera qu'ajouter les tags à l'image existante. <br />
<br />
Pour que la CLI Docker trouve bien le Dockerfile, on lance le terminal dans le dossier ou ce Dockerfile est enregistré. <br />
<br />
<code>docker build . -t ghcr.io/evs-gis/mapdoapp:latest -t ghcr.io/evs-gis/mapdoapp:2.0.1 -t ghcr.io/evs-gis/mapdoapp:$(git rev-parse --short HEAD)</code><br />
<br />
Remarquez que le tag doit contenir le chemin complet vers le registre où sera poussée l'image (étape suivante). Si vous ne précisez pas le chemin (par exemple <code>mapdoapp:latest</code>), le registre utilisé sera DockerHub. <br />
<br />
Notez le tag <code>$(git rev-parse --short HEAD)</code> qui permet de taguer l'image avec le hash (la référence) du commit actuel (ne fonctionne que si vous êtes dans un dépôt git). Ce tag est bien pratique si vous n'incrémentez pas un numéro de version par ailleurs (<code>2.0.1</code> dans l'exemple ci-dessus). <br />
<br />
Le tag <code>latest</code> est à mettre sur la dernière version de votre image. Il sera automatiquement retiré de toutes les autres versions de votre image. <br />
<br />
La commande <code>docker images</code> permet ensuite de lister les tags disponibles localement. Si le build a réussi, vous devriez y voir votre image.<syntaxhighlight lang="bash"><br />
~$ docker images<br />
REPOSITORY TAG IMAGE ID CREATED SIZE<br />
ghcr.io/evs-gis/mapdoapp 2.0.1 b2b999e7d781 3 days ago 1.27GB<br />
ghcr.io/evs-gis/mapdoapp 7ad814c b2b999e7d781 3 days ago 1.27GB<br />
ghcr.io/evs-gis/mapdoapp latest b2b999e7d781 3 days ago 1.27GB<br />
ghcr.io/glourb/glourbapp 642e23b 8a3daa97546e 4 days ago 1.38GB<br />
ghcr.io/glourb/glourbapp latest 8a3daa97546e 4 days ago 1.38GB<br />
ghcr.io/glourb/glourbapp 502564d 9a2050fc09d4 4 days ago 1.38GB<br />
semaphoreui/semaphore v2.12.4 136bec584184 2 weeks ago 727MB<br />
ghcr.io/mastergeonum/cartondes main a95ee654e34a 5 weeks ago 205MB<br />
dockurr/windows latest c3419fd6e55a 2 months ago 384MB<br />
docker.osgeo.org/geoserver 2.26.1 a91188b23092 3 months ago 608MB<br />
rocker/verse 4.4.1 202c993befdc 3 months ago 3.77GB<br />
ghcr.io/evs-gis/glourbee-ui 1.1.0 03e05bed5617 4 months ago 1.47GB<br />
<br />
</syntaxhighlight>Remarquez que <code>ghcr.io/evs-gis/mapdoapp</code> est présente plusieurs fois avec des tags différents, mais le même IMAGE ID. Il s'agit bien de la même image et elle n'est pas dupliquée sur le disque.<br />
<br />
Pour supprimer un tag, on utilisera la commande <code>docker image rm ghcr.io/evs-gis/mapdoapp:2.0.1</code>. Si plus aucun tag n'existe pour l'image, elle sera complètement supprimée du disque local. <br />
<br />
=== Tester l'image ===<br />
Pour tester son image, on peut utiliser la commande <code>docker run</code> :<br />
<br />
<code>docker run --rm -p 3838:3838 ghcr.io/evs-gis/mapdoapp:latest</code><br />
<br />
* --rm : Supprimer le container lorsqu'il est arrêté.<br />
* -p 3838:3838 : exposer le port 3838 local et le faire pointer vers le port 3838 dans le container.<br />
<br />
Les logs de l'application s'affichent dans le terminal et l'application est accessible dans un navigateur à l'adresse http://localhost:3838. Pour stopper le container, '''Ctrl+C'''.<br />
<br />
=== Faire du ménage localement ===<br />
Il arrive que des vieilles images sans tag, de vieux volumes et de vieux containers plantés restent sur le disque au fil du temps. Tester la commande <code>docker ps --all</code> par exemple, pour lister tous les containers locaux (lancés ou stoppés). La commande <code>docker system prune</code> permet de faire le grand ménage.<br />
<br />
=== Pousser l'image sur un registre ===<br />
Pour que le serveur ShinyProxy (ainsi que le monde entier !) puisse accéder à votre image, il faut la pousser sur un registre. Si vous ne souhaitez pas que votre image soit publique, vous pouvez utiliser le registre ghcr.io/evs-gis (le serveur ShinyProxy y a accès même si les images sont privées). <br />
<br />
Il faut d'abord se loguer sur le registre avec son login GitHub habituel, et un ''Personal Access Token'' en guise de mot de passe. Pour [https://github.com/settings/tokens/new obtenir un ''Personal Access Token''], rendez-vous [https://github.com/settings/tokens/new ici] et activez bien le droit <code>write:packages</code> pour votre token. <syntaxhighlight lang="sh"><br />
# La commande suivante est à lancer pour se loguer sur le registre. Il n'est pas nécessaire de la relancer à chaque fois.<br />
docker login ghcr.io<br />
<br />
# Pour pousser tous les tags de notre image sur le registre, on utilise ensuite la commande suivante.<br />
docker push ghcr.io/evs-gis/mapdoapp -a<br />
<br />
# Pour pousser seulement un tag spécifique, on préfèrera la commande suivante.<br />
docker push ghcr.io/evs-gis/mapdoapp:latest<br />
</syntaxhighlight><br />
<br />
== Configuration de l'application sur le serveur ShinyProxy de production ==<br />
La configuration de l'application se fait dans le '''fichier shinyapps.yml sur le dépôt privé''' https://github.com/EVS-GIS/isig-apps (un compte GitHub associé à l'organisation EVS-GIS est nécessaire). La branche prod de ce dépôt est synchronisée avec le serveur. Une erreur dans cette configuration pouvant potentiellement tout faire planter, cette branche prod est protégée et nécessite que vous fassiez un '''pull request''' validé par Samuel lorsque vous voulez mettre à jour cette configuration.<br />
<br />
L'intégralité des paramètres qu'il est possible de configurer est disponible [https://www.shinyproxy.io/documentation/configuration/#apps ici]. Voici les principaux que je vous recommande de configurer : <syntaxhighlight lang="yaml"><br />
- id: mapdoapp # Identifiant unique de l'application<br />
display-name: "Mapd'O App" # Nom d'affichage<br />
container-image: ghcr.io/evs-gis/mapdoapp:latest # Image Docker à utiliser (bien utiliser un tag "latest" pour faciliter la mise à jour)<br />
port: 3838 # Le port à écouter dans le container (dépend du port choisi au moment de la création de l'image)<br />
minimum-seats-available: 3 # Le nombre de containers en attente d'utilisateur que ShinyProxy doit assurer<br />
container-env: # Définitions de variables d'environnement<br />
MA_VARIABLE_1: valeur1<br />
MA_VARIABLE_2: valeur2<br />
</syntaxhighlight>N'hésitez pas à demander mon aide pour cette étape qui ne sera généralement à faire qu'une seule fois au moment du premier déploiement de l'appli. Dans certains cas où vous prévoyez un pic d'affluence sur votre appli (un cours ou une conférence par exemple), vous pouvez ajuster le <code>minimum-seats-available</code> pour éviter du temps de chargement à vos visiteurs.<br />
<br />
== Mise à jour d'une appli ==<br />
La mise à jour d'une appli sur le serveur de prod ne nécessite généralement pas de modifier le fichier de configuration (décrit ci-dessus). Il suffit de '''pousser la nouvelle version de votre image sur votre registre''' (avec le tag latest), puis de '''lancer le job ''Mise à jour d'une application en production sous ShinyProxy'' sur Jenkins''' pour forcer le redémarrage des containers d'attente déjà lancés.<br />
[[Catégorie:Tutoriel]]</div>Sdunesmehttps://isig-wiki.ens-lyon.fr/index.php?title=ShinyProxy&diff=1065ShinyProxy2025-02-24T09:56:26Z<p>Sdunesme : /* Principe de fonctionnement de ShinyProxy (et Docker) */</p>
<hr />
<div>'''<big>Attention : Page en cours de rédaction</big>'''<br />
<br />
ISIG-Apps passe sous ShinyProxy pour améliorer la stabilité et l'isolation de vos applications pendant les montées en charge. Le fonctionnement est très différent par rapport à l'ancien Shiny-Server et nécessite quelques bases dans l'utilisation de Docker. L'objectif de cette page est de vous guider, rapidement et simplement, dans le nouveau workflow dev > prod en partant du principe que vous ne connaissez encore pas grand-chose à Docker.<br />
<br />
== Principe de fonctionnement de ShinyProxy (et Docker) ==<br />
ShinyProxy fonctionne comme un orchestrateur de conteneurs Docker. Chaque appli configurée doit avoir une image Docker associée présente sur le serveur qui exécute ShinyProxy. C'est ShinyProxy qui s'occupera ensuite de lancer et stopper un conteneur à chaque fois qu'un internaute se connectera ou se déconnectera de votre appli. <br />
[[Fichier:Schéma Docker.png|centré|sans_cadre|1054x1054px]] <br />
<br />
Afin que votre application puisse fonctionner sur ShinyProxy, il va donc falloir créer une '''image''' qui permettra au serveur ShinyProxy de lancer des '''containers''' de votre application. <br />
<br />
Vous n'aurez généralement pas besoin de volume pour stocker des données pérennes dans le cas d'une application Shiny. Si votre application utilise une base de données, celle-ci devra être externalisée (hébergée sur le serveur de bases de données d'ISIG par exemple). <br />
<br />
ShinyProxy fera en sorte qu'un certain nombre de containers (à définir dans la configuration décrite à la fin de ce tutoriel) soient toujours disponibles pour de nouveaux utilisateurs qui se connecteraient à votre application. Il s'occupera également de supprimer les containers quand vos utilisateurs se déconnectent. <br />
<br />
== Conteneurisation de votre appli Shiny ==<br />
La conteneurisation peut se faire directement sur votre machine personelle si vous y avez installé Docker (https://docs.docker.com/engine/install/), ou sur le serveur isig-apps de dev via [https://rstudio.evs.ens-lyon.fr Rstudio server] et son terminal intégré.<br />
<br />
=== Fixer le port ===<br />
Pour fonctionner en mode conteneurisé, votre application devra écouter toujours sur le même port (ce qui n'est pas le comportement par défaut d'une application Shiny). <br />
<br />
Afin de s'en assurer, il faut : <br />
<br />
* Dans le cas d'un appli Shiny classique, ajouter dans <code>options(..)</code>, avant l'appel de <code>shinyApp(..)</code>, les options suivantes : <code>"shiny.port"=3841</code> et <code>"shiny.host"="0.0.0.0"</code>. Par exemple :<br />
<syntaxhighlight lang="r"><br />
library(shiny)<br />
library(glourbi)<br />
<br />
# Dans cet exemple, l'application écoutera systématiquement sur le port 3838<br />
options("shiny.port" = 3838, "shiny.host" = "0.0.0.0", "golem.app.prod" = TRUE)<br />
<br />
shinyApp(ui=glourbapp:::app_ui,server=glourbapp:::app_server)<br />
</syntaxhighlight><br />
<br />
* Dans le cas d'un document Rmarkdown, ........<br />
<br />
=== Choisir l'image source ===<br />
La construction d'une image Docker se fait sur la base... d'une autre. On choisi en général son image de base en fonction de ce qu'on va faire avec. Pour une application Shiny, nous aurons besoin d'une image Docker spécialisée en R. <br />
<br />
Le [https://rocker-project.org/images/ projet Rocker] propose plusieurs images de base avec différentes quantités de packages pré-installés. Lorsque l'on choisi son image de base, il faut trouver le bon compromis entre une image légère et une image avec suffisamment de dépendances pré-installées pour qu'elle soit pratique.<br />
<br />
L'image [https://eddelbuettel.github.io/r2u/ r2u] est une bonne base assez simple à utiliser, car elle va chercher des binaires précompilés des packages R que l'on souhaite installer et toutes leurs dépendances, librairies système incluses ! Pratiquement rien n'y est pré-installé, il faudra donc bien préciser toutes les dépendances dont vous avez besoin. En contrepartie, l'image sera plutôt légère, ce qui est une bonne chose ! L'inconvénient de cette fonctionnalité est (à ma connaissance) qu'elle ne fonctionne qu'avec la fonction <code>install.packages(...)</code>. Il n'est donc pas possible d'installer une version spécifique d'un package avec <code>remotes::install_version(...)</code> par exemple (la fonction reste utilisable de manière classique). <br />
<br />
=== Écrire le Dockerfile ===<br />
<br />
La création d'une image Docker repose sur l'écriture d'un fichier texte appelé '''Dockerfile''' (sans extension).<br />
<br />
Voici un exemple de Dockerfile pour l'application GloUrb :<syntaxhighlight lang="dockerfile"><br />
# On commence par définir l'image sur laquelle va se baser la notre<br />
FROM rocker/r2u:jammy<br />
<br />
# On précise quelques infos qui permettrons d'identifier l'image<br />
LABEL org.opencontainers.image.authors="Lise Vaudor <lise.vaudor@ens-lyon.fr>, Samuel Dunesme <samuel.dunesme@ens-lyon.fr>"<br />
LABEL org.opencontainers.image.source="https://github.com/glourb/glourbapp"<br />
LABEL org.opencontainers.image.documentation="https://evs-gis.github.io/glourbdoc/"<br />
LABEL org.opencontainers.image.version="0.0.0.9000"<br />
LABEL org.opencontainers.image.description="An app for the GloUrb project"<br />
<br />
# On peut éventuellement générer des locales supplémentaires si notre appli utilise d'autres langues que l'anglais<br />
RUN locale-gen fr_FR.UTF-8<br />
<br />
# On liste maintenant toutes les dépendances R à installer<br />
RUN Rscript -e 'install.packages("tidyr")'<br />
RUN Rscript -e 'install.packages("shiny")'<br />
RUN Rscript -e 'install.packages("config")'<br />
RUN Rscript -e 'install.packages("testthat")'<br />
RUN Rscript -e 'install.packages("tibble")'<br />
RUN Rscript -e 'install.packages("purrr")'<br />
RUN Rscript -e 'install.packages("dplyr")'<br />
RUN Rscript -e 'install.packages("ggplot2")'<br />
RUN Rscript -e 'install.packages("forcats")'<br />
RUN Rscript -e 'install.packages("magrittr")'<br />
RUN Rscript -e 'install.packages("golem")'<br />
RUN Rscript -e 'install.packages("sf")'<br />
RUN Rscript -e 'install.packages("plotly")'<br />
RUN Rscript -e 'install.packages("spelling")'<br />
RUN Rscript -e 'install.packages("mclust")'<br />
RUN Rscript -e 'install.packages("leaflet")'<br />
RUN Rscript -e 'install.packages("cluster")'<br />
RUN Rscript -e 'install.packages("cowplot")'<br />
RUN Rscript -e 'install.packages("FactoMineR")'<br />
RUN Rscript -e 'install.packages("glue")'<br />
RUN Rscript -e 'install.packages("grDevices")'<br />
RUN Rscript -e 'install.packages("RColorBrewer")'<br />
RUN Rscript -e 'install.packages("remotes")'<br />
RUN Rscript -e 'install.packages("cicerone")'<br />
RUN Rscript -e 'install.packages("RPostgres")'<br />
RUN Rscript -e 'install.packages("DBI")'<br />
RUN Rscript -e 'install.packages("DT")'<br />
<br />
RUN Rscript -e 'remotes::install_github("glourb/glourbi")'<br />
<br />
# On copie l'arborescence de fichiers dans un dossier app à la racine de l'image. Ce sera le working directory des containers lancés avec notre image<br />
RUN mkdir /app<br />
ADD . /app<br />
WORKDIR /app<br />
<br />
# Si besoin, on peut installer notre package<br />
RUN R -e 'remotes::install_local()'<br />
<br />
# On détermine le port qui sera exposé (attention à bien fixer le port sur lequel votre appli écoute, cf. ci-dessus)<br />
EXPOSE 3838<br />
<br />
# Pour plus de sécurité, on fait en sorte que les containers ne se lancent pas avec l'utilisateur "root", mais avec un utilisateur "app" dédié<br />
RUN groupadd -g 1010 app && useradd -c 'app' -u 1010 -g 1010 -m -d /home/app -s /sbin/nologin app<br />
USER app<br />
<br />
# Enfin, on précise la commande qui permet de lancer notre appli. C'est cette commande qui sera lancée par défaut par tout nouveau container lancé avec notre image<br />
CMD ["R", "-f", "app.R"]<br />
</syntaxhighlight><br />
<br />
=== Construire l'image Docker ===<br />
Pour construire l'image docker à l'aide du Dockerfile, il faut lancer la commande <code>docker build</code>. C'est à ce moment que l'on va versionner l'image en la taguant avec l'argument <code>-t</code>. On peut mettre directement plusieurs tags à une image, ou les ajouter à posteriori en relançant la commande <code>docker build</code>. Si le Dockerfile n'a pas changé depuis le dernier build, <code>docker build</code> ne fera qu'ajouter les tags à l'image existante. <br />
<br />
Pour que la CLI Docker trouve bien le Dockerfile, on lance le terminal dans le dossier ou ce Dockerfile est enregistré. <br />
<br />
<code>docker build . -t ghcr.io/evs-gis/mapdoapp:latest -t ghcr.io/evs-gis/mapdoapp:2.0.1 -t ghcr.io/evs-gis/mapdoapp:$(git rev-parse --short HEAD)</code><br />
<br />
Remarquez que le tag doit contenir le chemin complet vers le registre où sera poussée l'image (étape suivante). Si vous ne précisez pas le chemin (par exemple <code>mapdoapp:latest</code>), le registre utilisé sera DockerHub. <br />
<br />
Notez le tag <code>$(git rev-parse --short HEAD)</code> qui permet de taguer l'image avec le hash (la référence) du commit actuel (ne fonctionne que si vous êtes dans un dépôt git). Ce tag est bien pratique si vous n'incrémentez pas un numéro de version par ailleurs (<code>2.0.1</code> dans l'exemple ci-dessus). <br />
<br />
Le tag <code>latest</code> est à mettre sur la dernière version de votre image. Il sera automatiquement retiré de toutes les autres versions de votre image. <br />
<br />
La commande <code>docker images</code> permet ensuite de lister les tags disponibles localement. Si le build a réussi, vous devriez y voir votre image.<syntaxhighlight lang="bash"><br />
~$ docker images<br />
REPOSITORY TAG IMAGE ID CREATED SIZE<br />
ghcr.io/evs-gis/mapdoapp 2.0.1 b2b999e7d781 3 days ago 1.27GB<br />
ghcr.io/evs-gis/mapdoapp 7ad814c b2b999e7d781 3 days ago 1.27GB<br />
ghcr.io/evs-gis/mapdoapp latest b2b999e7d781 3 days ago 1.27GB<br />
ghcr.io/glourb/glourbapp 642e23b 8a3daa97546e 4 days ago 1.38GB<br />
ghcr.io/glourb/glourbapp latest 8a3daa97546e 4 days ago 1.38GB<br />
ghcr.io/glourb/glourbapp 502564d 9a2050fc09d4 4 days ago 1.38GB<br />
semaphoreui/semaphore v2.12.4 136bec584184 2 weeks ago 727MB<br />
ghcr.io/mastergeonum/cartondes main a95ee654e34a 5 weeks ago 205MB<br />
dockurr/windows latest c3419fd6e55a 2 months ago 384MB<br />
docker.osgeo.org/geoserver 2.26.1 a91188b23092 3 months ago 608MB<br />
rocker/verse 4.4.1 202c993befdc 3 months ago 3.77GB<br />
ghcr.io/evs-gis/glourbee-ui 1.1.0 03e05bed5617 4 months ago 1.47GB<br />
<br />
</syntaxhighlight>Remarquez que <code>ghcr.io/evs-gis/mapdoapp</code> est présente plusieurs fois avec des tags différents, mais le même IMAGE ID. Il s'agit bien de la même image et elle n'est pas dupliquée sur le disque.<br />
<br />
Pour supprimer un tag, on utilisera la commande <code>docker image rm ghcr.io/evs-gis/mapdoapp:2.0.1</code>. Si plus aucun tag n'existe pour l'image, elle sera complètement supprimée du disque local. <br />
<br />
=== Tester l'image ===<br />
Pour tester son image, on peut utiliser la commande <code>docker run</code> :<br />
<br />
<code>docker run --rm -p 3838:3838 ghcr.io/evs-gis/mapdoapp:latest</code><br />
<br />
* --rm : Supprimer le container lorsqu'il est arrêté.<br />
* -p 3838:3838 : exposer le port 3838 local et le faire pointer vers le port 3838 dans le container.<br />
<br />
Les logs de l'application s'affichent dans le terminal et l'application est accessible dans un navigateur à l'adresse http://localhost:3838. Pour stopper le container, '''Ctrl+C'''.<br />
<br />
=== Faire du ménage localement ===<br />
Il arrive que des vieilles images sans tag, de vieux volumes et de vieux containers plantés restent sur le disque au fil du temps. Tester la commande <code>docker ps --all</code> par exemple, pour lister tous les containers locaux (lancés ou stoppés). La commande <code>docker system prune</code> permet de faire le grand ménage.<br />
<br />
=== Pousser l'image sur un registre ===<br />
Pour que le serveur ShinyProxy (ainsi que le monde entier !) puisse accéder à votre image, il faut la pousser sur un registre. Si vous ne souhaitez pas que votre image soit publique, vous pouvez utiliser le registre ghcr.io/evs-gis (le serveur ShinyProxy y a accès même si les images sont privées). <br />
<br />
== Configuration de l'application sur le serveur ShinyProxy de production ==<br />
La configuration de l'application se fait dans le '''fichier shinyapps.yml sur le dépôt privé''' https://github.com/EVS-GIS/isig-apps (un compte GitHub associé à l'organisation EVS-GIS est nécessaire). La branche prod de ce dépôt est synchronisée avec le serveur. Une erreur dans cette configuration pouvant potentiellement tout faire planter, cette branche prod est protégée et nécessite que vous fassiez un '''pull request''' validé par Samuel lorsque vous voulez mettre à jour cette configuration.<br />
<br />
L'intégralité des paramètres qu'il est possible de configurer est disponible [https://www.shinyproxy.io/documentation/configuration/#apps ici]. Voici les principaux que je vous recommande de configurer : <syntaxhighlight lang="yaml"><br />
- id: mapdoapp # Identifiant unique de l'application<br />
display-name: "Mapd'O App" # Nom d'affichage<br />
container-image: ghcr.io/evs-gis/mapdoapp:latest # Image Docker à utiliser (bien utiliser un tag "latest" pour faciliter la mise à jour)<br />
port: 3838 # Le port à écouter dans le container (dépend du port choisi au moment de la création de l'image)<br />
minimum-seats-available: 3 # Le nombre de containers en attente d'utilisateur que ShinyProxy doit assurer<br />
container-env: # Définitions de variables d'environnement<br />
MA_VARIABLE_1: valeur1<br />
MA_VARIABLE_2: valeur2<br />
</syntaxhighlight>N'hésitez pas à demander mon aide pour cette étape qui ne sera généralement à faire qu'une seule fois au moment du premier déploiement de l'appli. Dans certains cas où vous prévoyez un pic d'affluence sur votre appli (un cours ou une conférence par exemple), vous pouvez ajuster le <code>minimum-seats-available</code> pour éviter du temps de chargement à vos visiteurs.<br />
<br />
== Mise à jour d'une appli ==<br />
La mise à jour d'une appli sur le serveur de prod ne nécessite généralement pas de modifier le fichier de configuration (décrit ci-dessus). Il suffit de '''pousser la nouvelle version de votre image sur votre registre''' (avec le tag latest), puis de '''lancer le job ''Mise à jour d'une application en production sous ShinyProxy'' sur Jenkins''' pour forcer le redémarrage des containers d'attente déjà lancés.<br />
[[Catégorie:Tutoriel]]</div>Sdunesmehttps://isig-wiki.ens-lyon.fr/index.php?title=Fichier:Sch%C3%A9ma_Docker.png&diff=1064Fichier:Schéma Docker.png2025-02-24T09:43:04Z<p>Sdunesme : Sdunesme a téléversé une nouvelle version de Fichier:Schéma Docker.png</p>
<hr />
<div>Schéma de fonctionnement basique d'une application sous Docker</div>Sdunesmehttps://isig-wiki.ens-lyon.fr/index.php?title=ShinyProxy&diff=1063ShinyProxy2025-02-21T16:20:13Z<p>Sdunesme : /* Configuration de l'application sur le serveur ShinyProxy de production */</p>
<hr />
<div>'''<big>Attention : Page en cours de rédaction</big>'''<br />
<br />
ISIG-Apps passe sous ShinyProxy pour améliorer la stabilité et l'isolation de vos applications pendant les montées en charge. Le fonctionnement est très différent par rapport à l'ancien Shiny-Server et nécessite quelques bases dans l'utilisation de Docker. L'objectif de cette page est de vous guider, rapidement et simplement, dans le nouveau workflow dev > prod en partant du principe que vous ne connaissez encore pas grand-chose à Docker.<br />
<br />
== Principe de fonctionnement de ShinyProxy (et Docker) ==<br />
ShinyProxy fonctionne comme un orchestrateur de conteneurs Docker. Chaque appli configurée doit avoir une image Docker associée présente sur le serveur qui exécute ShinyProxy. C'est ShinyProxy qui s'occupera ensuite de lancer et stopper un conteneur à chaque fois qu'un internaute se connectera ou se déconnectera de votre appli. <br />
[[Fichier:Schéma Docker.png|centré|sans_cadre|1054x1054px]] <br />
<br />
Afin que votre application puisse fonctionner sur ShinyProxy, il va donc falloir créer une '''image''' qui permettra au serveur ShinyProxy de lancer des '''containers''' de votre application. <br />
<br />
Vous n'aurez généralement pas besoin de volume pour stocker des données pérennes dans le cas d'une application Shiny. Si votre application utilise une base de données, celle-ci devra être externalisée (hébergée sur le serveur de bases de données d'ISIG par exemple). <br />
<br />
== Conteneurisation de votre appli Shiny ==<br />
La conteneurisation peut se faire directement sur votre machine personelle si vous y avez installé Docker (https://docs.docker.com/engine/install/), ou sur le serveur isig-apps de dev via [https://rstudio.evs.ens-lyon.fr Rstudio server] et son terminal intégré.<br />
<br />
=== Fixer le port ===<br />
Pour fonctionner en mode conteneurisé, votre application devra écouter toujours sur le même port (ce qui n'est pas le comportement par défaut d'une application Shiny). <br />
<br />
Afin de s'en assurer, il faut : <br />
<br />
* Dans le cas d'un appli Shiny classique, ajouter dans <code>options(..)</code>, avant l'appel de <code>shinyApp(..)</code>, les options suivantes : <code>"shiny.port"=3841</code> et <code>"shiny.host"="0.0.0.0"</code>. Par exemple :<br />
<syntaxhighlight lang="r"><br />
library(shiny)<br />
library(glourbi)<br />
<br />
# Dans cet exemple, l'application écoutera systématiquement sur le port 3838<br />
options("shiny.port" = 3838, "shiny.host" = "0.0.0.0", "golem.app.prod" = TRUE)<br />
<br />
shinyApp(ui=glourbapp:::app_ui,server=glourbapp:::app_server)<br />
</syntaxhighlight><br />
<br />
* Dans le cas d'un document Rmarkdown, ........<br />
<br />
=== Choisir l'image source ===<br />
La construction d'une image Docker se fait sur la base... d'une autre. On choisi en général son image de base en fonction de ce qu'on va faire avec. Pour une application Shiny, nous aurons besoin d'une image Docker spécialisée en R. <br />
<br />
Le [https://rocker-project.org/images/ projet Rocker] propose plusieurs images de base avec différentes quantités de packages pré-installés. Lorsque l'on choisi son image de base, il faut trouver le bon compromis entre une image légère et une image avec suffisamment de dépendances pré-installées pour qu'elle soit pratique.<br />
<br />
L'image [https://eddelbuettel.github.io/r2u/ r2u] est une bonne base assez simple à utiliser, car elle va chercher des binaires précompilés des packages R que l'on souhaite installer et toutes leurs dépendances, librairies système incluses ! Pratiquement rien n'y est pré-installé, il faudra donc bien préciser toutes les dépendances dont vous avez besoin. En contrepartie, l'image sera plutôt légère, ce qui est une bonne chose ! L'inconvénient de cette fonctionnalité est (à ma connaissance) qu'elle ne fonctionne qu'avec la fonction <code>install.packages(...)</code>. Il n'est donc pas possible d'installer une version spécifique d'un package avec <code>remotes::install_version(...)</code> par exemple (la fonction reste utilisable de manière classique). <br />
<br />
=== Écrire le Dockerfile ===<br />
<br />
La création d'une image Docker repose sur l'écriture d'un fichier texte appelé '''Dockerfile''' (sans extension).<br />
<br />
Voici un exemple de Dockerfile pour l'application GloUrb :<syntaxhighlight lang="dockerfile"><br />
# On commence par définir l'image sur laquelle va se baser la notre<br />
FROM rocker/r2u:jammy<br />
<br />
# On précise quelques infos qui permettrons d'identifier l'image<br />
LABEL org.opencontainers.image.authors="Lise Vaudor <lise.vaudor@ens-lyon.fr>, Samuel Dunesme <samuel.dunesme@ens-lyon.fr>"<br />
LABEL org.opencontainers.image.source="https://github.com/glourb/glourbapp"<br />
LABEL org.opencontainers.image.documentation="https://evs-gis.github.io/glourbdoc/"<br />
LABEL org.opencontainers.image.version="0.0.0.9000"<br />
LABEL org.opencontainers.image.description="An app for the GloUrb project"<br />
<br />
# On peut éventuellement générer des locales supplémentaires si notre appli utilise d'autres langues que l'anglais<br />
RUN locale-gen fr_FR.UTF-8<br />
<br />
# On liste maintenant toutes les dépendances R à installer<br />
RUN Rscript -e 'install.packages("tidyr")'<br />
RUN Rscript -e 'install.packages("shiny")'<br />
RUN Rscript -e 'install.packages("config")'<br />
RUN Rscript -e 'install.packages("testthat")'<br />
RUN Rscript -e 'install.packages("tibble")'<br />
RUN Rscript -e 'install.packages("purrr")'<br />
RUN Rscript -e 'install.packages("dplyr")'<br />
RUN Rscript -e 'install.packages("ggplot2")'<br />
RUN Rscript -e 'install.packages("forcats")'<br />
RUN Rscript -e 'install.packages("magrittr")'<br />
RUN Rscript -e 'install.packages("golem")'<br />
RUN Rscript -e 'install.packages("sf")'<br />
RUN Rscript -e 'install.packages("plotly")'<br />
RUN Rscript -e 'install.packages("spelling")'<br />
RUN Rscript -e 'install.packages("mclust")'<br />
RUN Rscript -e 'install.packages("leaflet")'<br />
RUN Rscript -e 'install.packages("cluster")'<br />
RUN Rscript -e 'install.packages("cowplot")'<br />
RUN Rscript -e 'install.packages("FactoMineR")'<br />
RUN Rscript -e 'install.packages("glue")'<br />
RUN Rscript -e 'install.packages("grDevices")'<br />
RUN Rscript -e 'install.packages("RColorBrewer")'<br />
RUN Rscript -e 'install.packages("remotes")'<br />
RUN Rscript -e 'install.packages("cicerone")'<br />
RUN Rscript -e 'install.packages("RPostgres")'<br />
RUN Rscript -e 'install.packages("DBI")'<br />
RUN Rscript -e 'install.packages("DT")'<br />
<br />
RUN Rscript -e 'remotes::install_github("glourb/glourbi")'<br />
<br />
# On copie l'arborescence de fichiers dans un dossier app à la racine de l'image. Ce sera le working directory des containers lancés avec notre image<br />
RUN mkdir /app<br />
ADD . /app<br />
WORKDIR /app<br />
<br />
# Si besoin, on peut installer notre package<br />
RUN R -e 'remotes::install_local()'<br />
<br />
# On détermine le port qui sera exposé (attention à bien fixer le port sur lequel votre appli écoute, cf. ci-dessus)<br />
EXPOSE 3838<br />
<br />
# Pour plus de sécurité, on fait en sorte que les containers ne se lancent pas avec l'utilisateur "root", mais avec un utilisateur "app" dédié<br />
RUN groupadd -g 1010 app && useradd -c 'app' -u 1010 -g 1010 -m -d /home/app -s /sbin/nologin app<br />
USER app<br />
<br />
# Enfin, on précise la commande qui permet de lancer notre appli. C'est cette commande qui sera lancée par défaut par tout nouveau container lancé avec notre image<br />
CMD ["R", "-f", "app.R"]<br />
</syntaxhighlight><br />
<br />
=== Construire l'image Docker ===<br />
Pour construire l'image docker à l'aide du Dockerfile, il faut lancer la commande <code>docker build</code>. C'est à ce moment que l'on va versionner l'image en la taguant avec l'argument <code>-t</code>. On peut mettre directement plusieurs tags à une image, ou les ajouter à posteriori en relançant la commande <code>docker build</code>. Si le Dockerfile n'a pas changé depuis le dernier build, <code>docker build</code> ne fera qu'ajouter les tags à l'image existante. <br />
<br />
Pour que la CLI Docker trouve bien le Dockerfile, on lance le terminal dans le dossier ou ce Dockerfile est enregistré. <br />
<br />
<code>docker build . -t ghcr.io/evs-gis/mapdoapp:latest -t ghcr.io/evs-gis/mapdoapp:2.0.1 -t ghcr.io/evs-gis/mapdoapp:$(git rev-parse --short HEAD)</code><br />
<br />
Remarquez que le tag doit contenir le chemin complet vers le registre où sera poussée l'image (étape suivante). Si vous ne précisez pas le chemin (par exemple <code>mapdoapp:latest</code>), le registre utilisé sera DockerHub. <br />
<br />
Notez le tag <code>$(git rev-parse --short HEAD)</code> qui permet de taguer l'image avec le hash (la référence) du commit actuel (ne fonctionne que si vous êtes dans un dépôt git). Ce tag est bien pratique si vous n'incrémentez pas un numéro de version par ailleurs (<code>2.0.1</code> dans l'exemple ci-dessus). <br />
<br />
Le tag <code>latest</code> est à mettre sur la dernière version de votre image. Il sera automatiquement retiré de toutes les autres versions de votre image. <br />
<br />
La commande <code>docker images</code> permet ensuite de lister les tags disponibles localement. Si le build a réussi, vous devriez y voir votre image.<syntaxhighlight lang="bash"><br />
~$ docker images<br />
REPOSITORY TAG IMAGE ID CREATED SIZE<br />
ghcr.io/evs-gis/mapdoapp 2.0.1 b2b999e7d781 3 days ago 1.27GB<br />
ghcr.io/evs-gis/mapdoapp 7ad814c b2b999e7d781 3 days ago 1.27GB<br />
ghcr.io/evs-gis/mapdoapp latest b2b999e7d781 3 days ago 1.27GB<br />
ghcr.io/glourb/glourbapp 642e23b 8a3daa97546e 4 days ago 1.38GB<br />
ghcr.io/glourb/glourbapp latest 8a3daa97546e 4 days ago 1.38GB<br />
ghcr.io/glourb/glourbapp 502564d 9a2050fc09d4 4 days ago 1.38GB<br />
semaphoreui/semaphore v2.12.4 136bec584184 2 weeks ago 727MB<br />
ghcr.io/mastergeonum/cartondes main a95ee654e34a 5 weeks ago 205MB<br />
dockurr/windows latest c3419fd6e55a 2 months ago 384MB<br />
docker.osgeo.org/geoserver 2.26.1 a91188b23092 3 months ago 608MB<br />
rocker/verse 4.4.1 202c993befdc 3 months ago 3.77GB<br />
ghcr.io/evs-gis/glourbee-ui 1.1.0 03e05bed5617 4 months ago 1.47GB<br />
<br />
</syntaxhighlight>Remarquez que <code>ghcr.io/evs-gis/mapdoapp</code> est présente plusieurs fois avec des tags différents, mais le même IMAGE ID. Il s'agit bien de la même image et elle n'est pas dupliquée sur le disque.<br />
<br />
Pour supprimer un tag, on utilisera la commande <code>docker image rm ghcr.io/evs-gis/mapdoapp:2.0.1</code>. Si plus aucun tag n'existe pour l'image, elle sera complètement supprimée du disque local. <br />
<br />
=== Tester l'image ===<br />
Pour tester son image, on peut utiliser la commande <code>docker run</code> :<br />
<br />
<code>docker run --rm -p 3838:3838 ghcr.io/evs-gis/mapdoapp:latest</code><br />
<br />
* --rm : Supprimer le container lorsqu'il est arrêté.<br />
* -p 3838:3838 : exposer le port 3838 local et le faire pointer vers le port 3838 dans le container.<br />
<br />
Les logs de l'application s'affichent dans le terminal et l'application est accessible dans un navigateur à l'adresse http://localhost:3838. Pour stopper le container, '''Ctrl+C'''.<br />
<br />
=== Faire du ménage localement ===<br />
Il arrive que des vieilles images sans tag, de vieux volumes et de vieux containers plantés restent sur le disque au fil du temps. Tester la commande <code>docker ps --all</code> par exemple, pour lister tous les containers locaux (lancés ou stoppés). La commande <code>docker system prune</code> permet de faire le grand ménage.<br />
<br />
=== Pousser l'image sur un registre ===<br />
Pour que le serveur ShinyProxy (ainsi que le monde entier !) puisse accéder à votre image, il faut la pousser sur un registre. Si vous ne souhaitez pas que votre image soit publique, vous pouvez utiliser le registre ghcr.io/evs-gis (le serveur ShinyProxy y a accès même si les images sont privées). <br />
<br />
== Configuration de l'application sur le serveur ShinyProxy de production ==<br />
La configuration de l'application se fait dans le fichier shinyapps.yml sur le dépôt privé https://github.com/EVS-GIS/isig-apps (un compte GitHub associé à l'organisation EVS-GIS est nécessaire). La branche prod de ce dépôt est synchronisée avec le serveur. Une erreur dans cette configuration pouvant potentiellement tout faire planter, cette branche prod est protégée et nécessite que vous fassiez une pull request validée par Samuel lorsque vous voulez mettre à jour cette configuration.<br />
<br />
L'intégralité des paramètres qu'il est possible de configurer est disponible [https://www.shinyproxy.io/documentation/configuration/#apps ici].<br />
<br />
== Mise à jour d'une appli ==<br />
La mise à jour d'une appli sur le serveur de prod ne nécessite généralement pas de modifier le fichier de configuration (décrit ci-dessus). Il suffit de pousser la nouvelle version de votre image sur votre registre (avec le tag latest), puis de lancer le job "Mise...... " sur Jenkins pour forcer le redémarrage des containers d'attente déjà lancés.<br />
[[Catégorie:Tutoriel]]</div>Sdunesmehttps://isig-wiki.ens-lyon.fr/index.php?title=ShinyProxy&diff=1062ShinyProxy2025-02-21T16:17:59Z<p>Sdunesme : /* Configuration sur l'instance de dev */</p>
<hr />
<div>'''<big>Attention : Page en cours de rédaction</big>'''<br />
<br />
ISIG-Apps passe sous ShinyProxy pour améliorer la stabilité et l'isolation de vos applications pendant les montées en charge. Le fonctionnement est très différent par rapport à l'ancien Shiny-Server et nécessite quelques bases dans l'utilisation de Docker. L'objectif de cette page est de vous guider, rapidement et simplement, dans le nouveau workflow dev > prod en partant du principe que vous ne connaissez encore pas grand-chose à Docker.<br />
<br />
== Principe de fonctionnement de ShinyProxy (et Docker) ==<br />
ShinyProxy fonctionne comme un orchestrateur de conteneurs Docker. Chaque appli configurée doit avoir une image Docker associée présente sur le serveur qui exécute ShinyProxy. C'est ShinyProxy qui s'occupera ensuite de lancer et stopper un conteneur à chaque fois qu'un internaute se connectera ou se déconnectera de votre appli. <br />
[[Fichier:Schéma Docker.png|centré|sans_cadre|1054x1054px]] <br />
<br />
Afin que votre application puisse fonctionner sur ShinyProxy, il va donc falloir créer une '''image''' qui permettra au serveur ShinyProxy de lancer des '''containers''' de votre application. <br />
<br />
Vous n'aurez généralement pas besoin de volume pour stocker des données pérennes dans le cas d'une application Shiny. Si votre application utilise une base de données, celle-ci devra être externalisée (hébergée sur le serveur de bases de données d'ISIG par exemple). <br />
<br />
== Conteneurisation de votre appli Shiny ==<br />
La conteneurisation peut se faire directement sur votre machine personelle si vous y avez installé Docker (https://docs.docker.com/engine/install/), ou sur le serveur isig-apps de dev via [https://rstudio.evs.ens-lyon.fr Rstudio server] et son terminal intégré.<br />
<br />
=== Fixer le port ===<br />
Pour fonctionner en mode conteneurisé, votre application devra écouter toujours sur le même port (ce qui n'est pas le comportement par défaut d'une application Shiny). <br />
<br />
Afin de s'en assurer, il faut : <br />
<br />
* Dans le cas d'un appli Shiny classique, ajouter dans <code>options(..)</code>, avant l'appel de <code>shinyApp(..)</code>, les options suivantes : <code>"shiny.port"=3841</code> et <code>"shiny.host"="0.0.0.0"</code>. Par exemple :<br />
<syntaxhighlight lang="r"><br />
library(shiny)<br />
library(glourbi)<br />
<br />
# Dans cet exemple, l'application écoutera systématiquement sur le port 3838<br />
options("shiny.port" = 3838, "shiny.host" = "0.0.0.0", "golem.app.prod" = TRUE)<br />
<br />
shinyApp(ui=glourbapp:::app_ui,server=glourbapp:::app_server)<br />
</syntaxhighlight><br />
<br />
* Dans le cas d'un document Rmarkdown, ........<br />
<br />
=== Choisir l'image source ===<br />
La construction d'une image Docker se fait sur la base... d'une autre. On choisi en général son image de base en fonction de ce qu'on va faire avec. Pour une application Shiny, nous aurons besoin d'une image Docker spécialisée en R. <br />
<br />
Le [https://rocker-project.org/images/ projet Rocker] propose plusieurs images de base avec différentes quantités de packages pré-installés. Lorsque l'on choisi son image de base, il faut trouver le bon compromis entre une image légère et une image avec suffisamment de dépendances pré-installées pour qu'elle soit pratique.<br />
<br />
L'image [https://eddelbuettel.github.io/r2u/ r2u] est une bonne base assez simple à utiliser, car elle va chercher des binaires précompilés des packages R que l'on souhaite installer et toutes leurs dépendances, librairies système incluses ! Pratiquement rien n'y est pré-installé, il faudra donc bien préciser toutes les dépendances dont vous avez besoin. En contrepartie, l'image sera plutôt légère, ce qui est une bonne chose ! L'inconvénient de cette fonctionnalité est (à ma connaissance) qu'elle ne fonctionne qu'avec la fonction <code>install.packages(...)</code>. Il n'est donc pas possible d'installer une version spécifique d'un package avec <code>remotes::install_version(...)</code> par exemple (la fonction reste utilisable de manière classique). <br />
<br />
=== Écrire le Dockerfile ===<br />
<br />
La création d'une image Docker repose sur l'écriture d'un fichier texte appelé '''Dockerfile''' (sans extension).<br />
<br />
Voici un exemple de Dockerfile pour l'application GloUrb :<syntaxhighlight lang="dockerfile"><br />
# On commence par définir l'image sur laquelle va se baser la notre<br />
FROM rocker/r2u:jammy<br />
<br />
# On précise quelques infos qui permettrons d'identifier l'image<br />
LABEL org.opencontainers.image.authors="Lise Vaudor <lise.vaudor@ens-lyon.fr>, Samuel Dunesme <samuel.dunesme@ens-lyon.fr>"<br />
LABEL org.opencontainers.image.source="https://github.com/glourb/glourbapp"<br />
LABEL org.opencontainers.image.documentation="https://evs-gis.github.io/glourbdoc/"<br />
LABEL org.opencontainers.image.version="0.0.0.9000"<br />
LABEL org.opencontainers.image.description="An app for the GloUrb project"<br />
<br />
# On peut éventuellement générer des locales supplémentaires si notre appli utilise d'autres langues que l'anglais<br />
RUN locale-gen fr_FR.UTF-8<br />
<br />
# On liste maintenant toutes les dépendances R à installer<br />
RUN Rscript -e 'install.packages("tidyr")'<br />
RUN Rscript -e 'install.packages("shiny")'<br />
RUN Rscript -e 'install.packages("config")'<br />
RUN Rscript -e 'install.packages("testthat")'<br />
RUN Rscript -e 'install.packages("tibble")'<br />
RUN Rscript -e 'install.packages("purrr")'<br />
RUN Rscript -e 'install.packages("dplyr")'<br />
RUN Rscript -e 'install.packages("ggplot2")'<br />
RUN Rscript -e 'install.packages("forcats")'<br />
RUN Rscript -e 'install.packages("magrittr")'<br />
RUN Rscript -e 'install.packages("golem")'<br />
RUN Rscript -e 'install.packages("sf")'<br />
RUN Rscript -e 'install.packages("plotly")'<br />
RUN Rscript -e 'install.packages("spelling")'<br />
RUN Rscript -e 'install.packages("mclust")'<br />
RUN Rscript -e 'install.packages("leaflet")'<br />
RUN Rscript -e 'install.packages("cluster")'<br />
RUN Rscript -e 'install.packages("cowplot")'<br />
RUN Rscript -e 'install.packages("FactoMineR")'<br />
RUN Rscript -e 'install.packages("glue")'<br />
RUN Rscript -e 'install.packages("grDevices")'<br />
RUN Rscript -e 'install.packages("RColorBrewer")'<br />
RUN Rscript -e 'install.packages("remotes")'<br />
RUN Rscript -e 'install.packages("cicerone")'<br />
RUN Rscript -e 'install.packages("RPostgres")'<br />
RUN Rscript -e 'install.packages("DBI")'<br />
RUN Rscript -e 'install.packages("DT")'<br />
<br />
RUN Rscript -e 'remotes::install_github("glourb/glourbi")'<br />
<br />
# On copie l'arborescence de fichiers dans un dossier app à la racine de l'image. Ce sera le working directory des containers lancés avec notre image<br />
RUN mkdir /app<br />
ADD . /app<br />
WORKDIR /app<br />
<br />
# Si besoin, on peut installer notre package<br />
RUN R -e 'remotes::install_local()'<br />
<br />
# On détermine le port qui sera exposé (attention à bien fixer le port sur lequel votre appli écoute, cf. ci-dessus)<br />
EXPOSE 3838<br />
<br />
# Pour plus de sécurité, on fait en sorte que les containers ne se lancent pas avec l'utilisateur "root", mais avec un utilisateur "app" dédié<br />
RUN groupadd -g 1010 app && useradd -c 'app' -u 1010 -g 1010 -m -d /home/app -s /sbin/nologin app<br />
USER app<br />
<br />
# Enfin, on précise la commande qui permet de lancer notre appli. C'est cette commande qui sera lancée par défaut par tout nouveau container lancé avec notre image<br />
CMD ["R", "-f", "app.R"]<br />
</syntaxhighlight><br />
<br />
=== Construire l'image Docker ===<br />
Pour construire l'image docker à l'aide du Dockerfile, il faut lancer la commande <code>docker build</code>. C'est à ce moment que l'on va versionner l'image en la taguant avec l'argument <code>-t</code>. On peut mettre directement plusieurs tags à une image, ou les ajouter à posteriori en relançant la commande <code>docker build</code>. Si le Dockerfile n'a pas changé depuis le dernier build, <code>docker build</code> ne fera qu'ajouter les tags à l'image existante. <br />
<br />
Pour que la CLI Docker trouve bien le Dockerfile, on lance le terminal dans le dossier ou ce Dockerfile est enregistré. <br />
<br />
<code>docker build . -t ghcr.io/evs-gis/mapdoapp:latest -t ghcr.io/evs-gis/mapdoapp:2.0.1 -t ghcr.io/evs-gis/mapdoapp:$(git rev-parse --short HEAD)</code><br />
<br />
Remarquez que le tag doit contenir le chemin complet vers le registre où sera poussée l'image (étape suivante). Si vous ne précisez pas le chemin (par exemple <code>mapdoapp:latest</code>), le registre utilisé sera DockerHub. <br />
<br />
Notez le tag <code>$(git rev-parse --short HEAD)</code> qui permet de taguer l'image avec le hash (la référence) du commit actuel (ne fonctionne que si vous êtes dans un dépôt git). Ce tag est bien pratique si vous n'incrémentez pas un numéro de version par ailleurs (<code>2.0.1</code> dans l'exemple ci-dessus). <br />
<br />
Le tag <code>latest</code> est à mettre sur la dernière version de votre image. Il sera automatiquement retiré de toutes les autres versions de votre image. <br />
<br />
La commande <code>docker images</code> permet ensuite de lister les tags disponibles localement. Si le build a réussi, vous devriez y voir votre image.<syntaxhighlight lang="bash"><br />
~$ docker images<br />
REPOSITORY TAG IMAGE ID CREATED SIZE<br />
ghcr.io/evs-gis/mapdoapp 2.0.1 b2b999e7d781 3 days ago 1.27GB<br />
ghcr.io/evs-gis/mapdoapp 7ad814c b2b999e7d781 3 days ago 1.27GB<br />
ghcr.io/evs-gis/mapdoapp latest b2b999e7d781 3 days ago 1.27GB<br />
ghcr.io/glourb/glourbapp 642e23b 8a3daa97546e 4 days ago 1.38GB<br />
ghcr.io/glourb/glourbapp latest 8a3daa97546e 4 days ago 1.38GB<br />
ghcr.io/glourb/glourbapp 502564d 9a2050fc09d4 4 days ago 1.38GB<br />
semaphoreui/semaphore v2.12.4 136bec584184 2 weeks ago 727MB<br />
ghcr.io/mastergeonum/cartondes main a95ee654e34a 5 weeks ago 205MB<br />
dockurr/windows latest c3419fd6e55a 2 months ago 384MB<br />
docker.osgeo.org/geoserver 2.26.1 a91188b23092 3 months ago 608MB<br />
rocker/verse 4.4.1 202c993befdc 3 months ago 3.77GB<br />
ghcr.io/evs-gis/glourbee-ui 1.1.0 03e05bed5617 4 months ago 1.47GB<br />
<br />
</syntaxhighlight>Remarquez que <code>ghcr.io/evs-gis/mapdoapp</code> est présente plusieurs fois avec des tags différents, mais le même IMAGE ID. Il s'agit bien de la même image et elle n'est pas dupliquée sur le disque.<br />
<br />
Pour supprimer un tag, on utilisera la commande <code>docker image rm ghcr.io/evs-gis/mapdoapp:2.0.1</code>. Si plus aucun tag n'existe pour l'image, elle sera complètement supprimée du disque local. <br />
<br />
=== Tester l'image ===<br />
Pour tester son image, on peut utiliser la commande <code>docker run</code> :<br />
<br />
<code>docker run --rm -p 3838:3838 ghcr.io/evs-gis/mapdoapp:latest</code><br />
<br />
* --rm : Supprimer le container lorsqu'il est arrêté.<br />
* -p 3838:3838 : exposer le port 3838 local et le faire pointer vers le port 3838 dans le container.<br />
<br />
Les logs de l'application s'affichent dans le terminal et l'application est accessible dans un navigateur à l'adresse http://localhost:3838. Pour stopper le container, '''Ctrl+C'''.<br />
<br />
=== Faire du ménage localement ===<br />
Il arrive que des vieilles images sans tag, de vieux volumes et de vieux containers plantés restent sur le disque au fil du temps. Tester la commande <code>docker ps --all</code> par exemple, pour lister tous les containers locaux (lancés ou stoppés). La commande <code>docker system prune</code> permet de faire le grand ménage.<br />
<br />
=== Pousser l'image sur un registre ===<br />
Pour que le serveur ShinyProxy (ainsi que le monde entier !) puisse accéder à votre image, il faut la pousser sur un registre. Si vous ne souhaitez pas que votre image soit publique, vous pouvez utiliser le registre ghcr.io/evs-gis (le serveur ShinyProxy y a accès même si les images sont privées). <br />
<br />
== Configuration de l'application sur le serveur ShinyProxy de production ==<br />
La configuration de l'application se fait dans le fichier shinyapps.yml sur le dépôt privé https://github.com/EVS-GIS/isig-apps (un compte GitHub associé à l'organisation EVS-GIS est nécessaire). La branche prod de ce dépôt est synchronisée avec le serveur. Une erreur dans cette configuration pouvant potentiellement tout faire planter, cette branche prod est protégée et nécessite que vous fassiez une pull request validée par Samuel lorsque vous voulez mettre à jour cette configuration.<br />
<br />
== Mise à jour d'une appli ==<br />
La mise à jour d'une appli sur le serveur de prod ne nécessite généralement pas de modifier le fichier de configuration (décrit ci-dessus). Il suffit de pousser la nouvelle version de votre image sur votre registre (avec le tag latest), puis de lancer le job "Mise...... " sur Jenkins pour forcer le redémarrage des containers d'attente déjà lancés.<br />
[[Catégorie:Tutoriel]]</div>Sdunesmehttps://isig-wiki.ens-lyon.fr/index.php?title=ShinyProxy&diff=1061ShinyProxy2025-02-21T16:04:28Z<p>Sdunesme : /* Tester l'image */</p>
<hr />
<div>'''<big>Attention : Page en cours de rédaction</big>'''<br />
<br />
ISIG-Apps passe sous ShinyProxy pour améliorer la stabilité et l'isolation de vos applications pendant les montées en charge. Le fonctionnement est très différent par rapport à l'ancien Shiny-Server et nécessite quelques bases dans l'utilisation de Docker. L'objectif de cette page est de vous guider, rapidement et simplement, dans le nouveau workflow dev > prod en partant du principe que vous ne connaissez encore pas grand-chose à Docker.<br />
<br />
== Principe de fonctionnement de ShinyProxy (et Docker) ==<br />
ShinyProxy fonctionne comme un orchestrateur de conteneurs Docker. Chaque appli configurée doit avoir une image Docker associée présente sur le serveur qui exécute ShinyProxy. C'est ShinyProxy qui s'occupera ensuite de lancer et stopper un conteneur à chaque fois qu'un internaute se connectera ou se déconnectera de votre appli. <br />
[[Fichier:Schéma Docker.png|centré|sans_cadre|1054x1054px]] <br />
<br />
Afin que votre application puisse fonctionner sur ShinyProxy, il va donc falloir créer une '''image''' qui permettra au serveur ShinyProxy de lancer des '''containers''' de votre application. <br />
<br />
Vous n'aurez généralement pas besoin de volume pour stocker des données pérennes dans le cas d'une application Shiny. Si votre application utilise une base de données, celle-ci devra être externalisée (hébergée sur le serveur de bases de données d'ISIG par exemple). <br />
<br />
== Conteneurisation de votre appli Shiny ==<br />
La conteneurisation peut se faire directement sur votre machine personelle si vous y avez installé Docker (https://docs.docker.com/engine/install/), ou sur le serveur isig-apps de dev via [https://rstudio.evs.ens-lyon.fr Rstudio server] et son terminal intégré.<br />
<br />
=== Fixer le port ===<br />
Pour fonctionner en mode conteneurisé, votre application devra écouter toujours sur le même port (ce qui n'est pas le comportement par défaut d'une application Shiny). <br />
<br />
Afin de s'en assurer, il faut : <br />
<br />
* Dans le cas d'un appli Shiny classique, ajouter dans <code>options(..)</code>, avant l'appel de <code>shinyApp(..)</code>, les options suivantes : <code>"shiny.port"=3841</code> et <code>"shiny.host"="0.0.0.0"</code>. Par exemple :<br />
<syntaxhighlight lang="r"><br />
library(shiny)<br />
library(glourbi)<br />
<br />
# Dans cet exemple, l'application écoutera systématiquement sur le port 3838<br />
options("shiny.port" = 3838, "shiny.host" = "0.0.0.0", "golem.app.prod" = TRUE)<br />
<br />
shinyApp(ui=glourbapp:::app_ui,server=glourbapp:::app_server)<br />
</syntaxhighlight><br />
<br />
* Dans le cas d'un document Rmarkdown, ........<br />
<br />
=== Choisir l'image source ===<br />
La construction d'une image Docker se fait sur la base... d'une autre. On choisi en général son image de base en fonction de ce qu'on va faire avec. Pour une application Shiny, nous aurons besoin d'une image Docker spécialisée en R. <br />
<br />
Le [https://rocker-project.org/images/ projet Rocker] propose plusieurs images de base avec différentes quantités de packages pré-installés. Lorsque l'on choisi son image de base, il faut trouver le bon compromis entre une image légère et une image avec suffisamment de dépendances pré-installées pour qu'elle soit pratique.<br />
<br />
L'image [https://eddelbuettel.github.io/r2u/ r2u] est une bonne base assez simple à utiliser, car elle va chercher des binaires précompilés des packages R que l'on souhaite installer et toutes leurs dépendances, librairies système incluses ! Pratiquement rien n'y est pré-installé, il faudra donc bien préciser toutes les dépendances dont vous avez besoin. En contrepartie, l'image sera plutôt légère, ce qui est une bonne chose ! L'inconvénient de cette fonctionnalité est (à ma connaissance) qu'elle ne fonctionne qu'avec la fonction <code>install.packages(...)</code>. Il n'est donc pas possible d'installer une version spécifique d'un package avec <code>remotes::install_version(...)</code> par exemple (la fonction reste utilisable de manière classique). <br />
<br />
=== Écrire le Dockerfile ===<br />
<br />
La création d'une image Docker repose sur l'écriture d'un fichier texte appelé '''Dockerfile''' (sans extension).<br />
<br />
Voici un exemple de Dockerfile pour l'application GloUrb :<syntaxhighlight lang="dockerfile"><br />
# On commence par définir l'image sur laquelle va se baser la notre<br />
FROM rocker/r2u:jammy<br />
<br />
# On précise quelques infos qui permettrons d'identifier l'image<br />
LABEL org.opencontainers.image.authors="Lise Vaudor <lise.vaudor@ens-lyon.fr>, Samuel Dunesme <samuel.dunesme@ens-lyon.fr>"<br />
LABEL org.opencontainers.image.source="https://github.com/glourb/glourbapp"<br />
LABEL org.opencontainers.image.documentation="https://evs-gis.github.io/glourbdoc/"<br />
LABEL org.opencontainers.image.version="0.0.0.9000"<br />
LABEL org.opencontainers.image.description="An app for the GloUrb project"<br />
<br />
# On peut éventuellement générer des locales supplémentaires si notre appli utilise d'autres langues que l'anglais<br />
RUN locale-gen fr_FR.UTF-8<br />
<br />
# On liste maintenant toutes les dépendances R à installer<br />
RUN Rscript -e 'install.packages("tidyr")'<br />
RUN Rscript -e 'install.packages("shiny")'<br />
RUN Rscript -e 'install.packages("config")'<br />
RUN Rscript -e 'install.packages("testthat")'<br />
RUN Rscript -e 'install.packages("tibble")'<br />
RUN Rscript -e 'install.packages("purrr")'<br />
RUN Rscript -e 'install.packages("dplyr")'<br />
RUN Rscript -e 'install.packages("ggplot2")'<br />
RUN Rscript -e 'install.packages("forcats")'<br />
RUN Rscript -e 'install.packages("magrittr")'<br />
RUN Rscript -e 'install.packages("golem")'<br />
RUN Rscript -e 'install.packages("sf")'<br />
RUN Rscript -e 'install.packages("plotly")'<br />
RUN Rscript -e 'install.packages("spelling")'<br />
RUN Rscript -e 'install.packages("mclust")'<br />
RUN Rscript -e 'install.packages("leaflet")'<br />
RUN Rscript -e 'install.packages("cluster")'<br />
RUN Rscript -e 'install.packages("cowplot")'<br />
RUN Rscript -e 'install.packages("FactoMineR")'<br />
RUN Rscript -e 'install.packages("glue")'<br />
RUN Rscript -e 'install.packages("grDevices")'<br />
RUN Rscript -e 'install.packages("RColorBrewer")'<br />
RUN Rscript -e 'install.packages("remotes")'<br />
RUN Rscript -e 'install.packages("cicerone")'<br />
RUN Rscript -e 'install.packages("RPostgres")'<br />
RUN Rscript -e 'install.packages("DBI")'<br />
RUN Rscript -e 'install.packages("DT")'<br />
<br />
RUN Rscript -e 'remotes::install_github("glourb/glourbi")'<br />
<br />
# On copie l'arborescence de fichiers dans un dossier app à la racine de l'image. Ce sera le working directory des containers lancés avec notre image<br />
RUN mkdir /app<br />
ADD . /app<br />
WORKDIR /app<br />
<br />
# Si besoin, on peut installer notre package<br />
RUN R -e 'remotes::install_local()'<br />
<br />
# On détermine le port qui sera exposé (attention à bien fixer le port sur lequel votre appli écoute, cf. ci-dessus)<br />
EXPOSE 3838<br />
<br />
# Pour plus de sécurité, on fait en sorte que les containers ne se lancent pas avec l'utilisateur "root", mais avec un utilisateur "app" dédié<br />
RUN groupadd -g 1010 app && useradd -c 'app' -u 1010 -g 1010 -m -d /home/app -s /sbin/nologin app<br />
USER app<br />
<br />
# Enfin, on précise la commande qui permet de lancer notre appli. C'est cette commande qui sera lancée par défaut par tout nouveau container lancé avec notre image<br />
CMD ["R", "-f", "app.R"]<br />
</syntaxhighlight><br />
<br />
=== Construire l'image Docker ===<br />
Pour construire l'image docker à l'aide du Dockerfile, il faut lancer la commande <code>docker build</code>. C'est à ce moment que l'on va versionner l'image en la taguant avec l'argument <code>-t</code>. On peut mettre directement plusieurs tags à une image, ou les ajouter à posteriori en relançant la commande <code>docker build</code>. Si le Dockerfile n'a pas changé depuis le dernier build, <code>docker build</code> ne fera qu'ajouter les tags à l'image existante. <br />
<br />
Pour que la CLI Docker trouve bien le Dockerfile, on lance le terminal dans le dossier ou ce Dockerfile est enregistré. <br />
<br />
<code>docker build . -t ghcr.io/evs-gis/mapdoapp:latest -t ghcr.io/evs-gis/mapdoapp:2.0.1 -t ghcr.io/evs-gis/mapdoapp:$(git rev-parse --short HEAD)</code><br />
<br />
Remarquez que le tag doit contenir le chemin complet vers le registre où sera poussée l'image (étape suivante). Si vous ne précisez pas le chemin (par exemple <code>mapdoapp:latest</code>), le registre utilisé sera DockerHub. <br />
<br />
Notez le tag <code>$(git rev-parse --short HEAD)</code> qui permet de taguer l'image avec le hash (la référence) du commit actuel (ne fonctionne que si vous êtes dans un dépôt git). Ce tag est bien pratique si vous n'incrémentez pas un numéro de version par ailleurs (<code>2.0.1</code> dans l'exemple ci-dessus). <br />
<br />
Le tag <code>latest</code> est à mettre sur la dernière version de votre image. Il sera automatiquement retiré de toutes les autres versions de votre image. <br />
<br />
La commande <code>docker images</code> permet ensuite de lister les tags disponibles localement. Si le build a réussi, vous devriez y voir votre image.<syntaxhighlight lang="bash"><br />
~$ docker images<br />
REPOSITORY TAG IMAGE ID CREATED SIZE<br />
ghcr.io/evs-gis/mapdoapp 2.0.1 b2b999e7d781 3 days ago 1.27GB<br />
ghcr.io/evs-gis/mapdoapp 7ad814c b2b999e7d781 3 days ago 1.27GB<br />
ghcr.io/evs-gis/mapdoapp latest b2b999e7d781 3 days ago 1.27GB<br />
ghcr.io/glourb/glourbapp 642e23b 8a3daa97546e 4 days ago 1.38GB<br />
ghcr.io/glourb/glourbapp latest 8a3daa97546e 4 days ago 1.38GB<br />
ghcr.io/glourb/glourbapp 502564d 9a2050fc09d4 4 days ago 1.38GB<br />
semaphoreui/semaphore v2.12.4 136bec584184 2 weeks ago 727MB<br />
ghcr.io/mastergeonum/cartondes main a95ee654e34a 5 weeks ago 205MB<br />
dockurr/windows latest c3419fd6e55a 2 months ago 384MB<br />
docker.osgeo.org/geoserver 2.26.1 a91188b23092 3 months ago 608MB<br />
rocker/verse 4.4.1 202c993befdc 3 months ago 3.77GB<br />
ghcr.io/evs-gis/glourbee-ui 1.1.0 03e05bed5617 4 months ago 1.47GB<br />
<br />
</syntaxhighlight>Remarquez que <code>ghcr.io/evs-gis/mapdoapp</code> est présente plusieurs fois avec des tags différents, mais le même IMAGE ID. Il s'agit bien de la même image et elle n'est pas dupliquée sur le disque.<br />
<br />
Pour supprimer un tag, on utilisera la commande <code>docker image rm ghcr.io/evs-gis/mapdoapp:2.0.1</code>. Si plus aucun tag n'existe pour l'image, elle sera complètement supprimée du disque local. <br />
<br />
=== Tester l'image ===<br />
Pour tester son image, on peut utiliser la commande <code>docker run</code> :<br />
<br />
<code>docker run --rm -p 3838:3838 ghcr.io/evs-gis/mapdoapp:latest</code><br />
<br />
* --rm : Supprimer le container lorsqu'il est arrêté.<br />
* -p 3838:3838 : exposer le port 3838 local et le faire pointer vers le port 3838 dans le container.<br />
<br />
Les logs de l'application s'affichent dans le terminal et l'application est accessible dans un navigateur à l'adresse http://localhost:3838. Pour stopper le container, '''Ctrl+C'''.<br />
<br />
=== Faire du ménage localement ===<br />
Il arrive que des vieilles images sans tag, de vieux volumes et de vieux containers plantés restent sur le disque au fil du temps. Tester la commande <code>docker ps --all</code> par exemple, pour lister tous les containers locaux (lancés ou stoppés). La commande <code>docker system prune</code> permet de faire le grand ménage.<br />
<br />
=== Pousser l'image sur un registre ===<br />
Pour que le serveur ShinyProxy (ainsi que le monde entier !) puisse accéder à votre image, il faut la pousser sur un registre. Si vous ne souhaitez pas que votre image soit publique, vous pouvez utiliser le registre ghcr.io/evs-gis (le serveur ShinyProxy y a accès même si les images sont privées). <br />
<br />
== Configuration sur l'instance de dev ==<br />
Forcer le redémarrage de tous les containers de votre appli (utile uniquement dans le cas où vous avez paramétré un nombre minimum de sièges supérieur à 0)<br />
<br />
<code>docker container restart $(docker ps -q -f ancestor="ghcr.io/evs-gis/mapdoapp:latest")</code><br />
<br />
== Configuration sur l'instance de prod ==<br />
<br />
== Mise à jour d'une appli ==<br />
[[Catégorie:Tutoriel]]</div>Sdunesmehttps://isig-wiki.ens-lyon.fr/index.php?title=ShinyProxy&diff=1060ShinyProxy2025-02-21T15:52:15Z<p>Sdunesme : /* Pousser l'image sur un registre */</p>
<hr />
<div>'''<big>Attention : Page en cours de rédaction</big>'''<br />
<br />
ISIG-Apps passe sous ShinyProxy pour améliorer la stabilité et l'isolation de vos applications pendant les montées en charge. Le fonctionnement est très différent par rapport à l'ancien Shiny-Server et nécessite quelques bases dans l'utilisation de Docker. L'objectif de cette page est de vous guider, rapidement et simplement, dans le nouveau workflow dev > prod en partant du principe que vous ne connaissez encore pas grand-chose à Docker.<br />
<br />
== Principe de fonctionnement de ShinyProxy (et Docker) ==<br />
ShinyProxy fonctionne comme un orchestrateur de conteneurs Docker. Chaque appli configurée doit avoir une image Docker associée présente sur le serveur qui exécute ShinyProxy. C'est ShinyProxy qui s'occupera ensuite de lancer et stopper un conteneur à chaque fois qu'un internaute se connectera ou se déconnectera de votre appli. <br />
[[Fichier:Schéma Docker.png|centré|sans_cadre|1054x1054px]] <br />
<br />
Afin que votre application puisse fonctionner sur ShinyProxy, il va donc falloir créer une '''image''' qui permettra au serveur ShinyProxy de lancer des '''containers''' de votre application. <br />
<br />
Vous n'aurez généralement pas besoin de volume pour stocker des données pérennes dans le cas d'une application Shiny. Si votre application utilise une base de données, celle-ci devra être externalisée (hébergée sur le serveur de bases de données d'ISIG par exemple). <br />
<br />
== Conteneurisation de votre appli Shiny ==<br />
La conteneurisation peut se faire directement sur votre machine personelle si vous y avez installé Docker (https://docs.docker.com/engine/install/), ou sur le serveur isig-apps de dev via [https://rstudio.evs.ens-lyon.fr Rstudio server] et son terminal intégré.<br />
<br />
=== Fixer le port ===<br />
Pour fonctionner en mode conteneurisé, votre application devra écouter toujours sur le même port (ce qui n'est pas le comportement par défaut d'une application Shiny). <br />
<br />
Afin de s'en assurer, il faut : <br />
<br />
* Dans le cas d'un appli Shiny classique, ajouter dans <code>options(..)</code>, avant l'appel de <code>shinyApp(..)</code>, les options suivantes : <code>"shiny.port"=3841</code> et <code>"shiny.host"="0.0.0.0"</code>. Par exemple :<br />
<syntaxhighlight lang="r"><br />
library(shiny)<br />
library(glourbi)<br />
<br />
options("shiny.port" = 3841, "shiny.host" = "0.0.0.0", "golem.app.prod" = TRUE)<br />
<br />
shinyApp(ui=glourbapp:::app_ui,server=glourbapp:::app_server)<br />
</syntaxhighlight><br />
<br />
* Dans le cas d'un document Rmarkdown, ........<br />
<br />
=== Choisir l'image source ===<br />
La construction d'une image Docker se fait sur la base... d'une autre. On choisi en général son image de base en fonction de ce qu'on va faire avec. Pour une application Shiny, nous aurons besoin d'une image Docker spécialisée en R. <br />
<br />
Le [https://rocker-project.org/images/ projet Rocker] propose plusieurs images de base avec différentes quantités de packages pré-installés. Lorsque l'on choisi son image de base, il faut trouver le bon compromis entre une image légère et une image avec suffisamment de dépendances pré-installées pour qu'elle soit pratique.<br />
<br />
L'image [https://eddelbuettel.github.io/r2u/ r2u] est une bonne base assez simple à utiliser, car elle va chercher des binaires précompilés des packages R que l'on souhaite installer et toutes leurs dépendances, librairies système incluses ! Pratiquement rien n'y est pré-installé, il faudra donc bien préciser toutes les dépendances dont vous avez besoin. En contrepartie, l'image sera plutôt légère, ce qui est une bonne chose ! L'inconvénient de cette fonctionnalité est (à ma connaissance) qu'elle ne fonctionne qu'avec la fonction <code>install.packages(...)</code>. Il n'est donc pas possible d'installer une version spécifique d'un package avec <code>remotes::install_version(...)</code> par exemple (la fonction reste utilisable de manière classique). <br />
<br />
=== Écrire le Dockerfile ===<br />
<br />
La création d'une image Docker repose sur l'écriture d'un fichier texte appelé '''Dockerfile''' (sans extension).<br />
<br />
Voici un exemple de Dockerfile pour l'application GloUrb :<syntaxhighlight lang="dockerfile"><br />
# On commence par définir l'image sur laquelle va se baser la notre<br />
FROM rocker/r2u:jammy<br />
<br />
# On précise quelques infos qui permettrons d'identifier l'image<br />
LABEL org.opencontainers.image.authors="Lise Vaudor <lise.vaudor@ens-lyon.fr>, Samuel Dunesme <samuel.dunesme@ens-lyon.fr>"<br />
LABEL org.opencontainers.image.source="https://github.com/glourb/glourbapp"<br />
LABEL org.opencontainers.image.documentation="https://evs-gis.github.io/glourbdoc/"<br />
LABEL org.opencontainers.image.version="0.0.0.9000"<br />
LABEL org.opencontainers.image.description="An app for the GloUrb project"<br />
<br />
# On peut éventuellement générer des locales supplémentaires si notre appli utilise d'autres langues que l'anglais<br />
RUN locale-gen fr_FR.UTF-8<br />
<br />
# On liste maintenant toutes les dépendances R à installer<br />
RUN Rscript -e 'install.packages("tidyr")'<br />
RUN Rscript -e 'install.packages("shiny")'<br />
RUN Rscript -e 'install.packages("config")'<br />
RUN Rscript -e 'install.packages("testthat")'<br />
RUN Rscript -e 'install.packages("tibble")'<br />
RUN Rscript -e 'install.packages("purrr")'<br />
RUN Rscript -e 'install.packages("dplyr")'<br />
RUN Rscript -e 'install.packages("ggplot2")'<br />
RUN Rscript -e 'install.packages("forcats")'<br />
RUN Rscript -e 'install.packages("magrittr")'<br />
RUN Rscript -e 'install.packages("golem")'<br />
RUN Rscript -e 'install.packages("sf")'<br />
RUN Rscript -e 'install.packages("plotly")'<br />
RUN Rscript -e 'install.packages("spelling")'<br />
RUN Rscript -e 'install.packages("mclust")'<br />
RUN Rscript -e 'install.packages("leaflet")'<br />
RUN Rscript -e 'install.packages("cluster")'<br />
RUN Rscript -e 'install.packages("cowplot")'<br />
RUN Rscript -e 'install.packages("FactoMineR")'<br />
RUN Rscript -e 'install.packages("glue")'<br />
RUN Rscript -e 'install.packages("grDevices")'<br />
RUN Rscript -e 'install.packages("RColorBrewer")'<br />
RUN Rscript -e 'install.packages("remotes")'<br />
RUN Rscript -e 'install.packages("cicerone")'<br />
RUN Rscript -e 'install.packages("RPostgres")'<br />
RUN Rscript -e 'install.packages("DBI")'<br />
RUN Rscript -e 'install.packages("DT")'<br />
<br />
RUN Rscript -e 'remotes::install_github("glourb/glourbi")'<br />
<br />
# On copie l'arborescence de fichiers dans un dossier app à la racine de l'image. Ce sera le working directory des containers lancés avec notre image<br />
RUN mkdir /app<br />
ADD . /app<br />
WORKDIR /app<br />
<br />
# Si besoin, on peut installer notre package<br />
RUN R -e 'remotes::install_local()'<br />
<br />
# On détermine le port qui sera exposé (attention à bien fixer le port sur lequel votre appli écoute, cf. ci-dessus)<br />
EXPOSE 3838<br />
<br />
# Pour plus de sécurité, on fait en sorte que les containers ne se lancent pas avec l'utilisateur "root", mais avec un utilisateur "app" dédié<br />
RUN groupadd -g 1010 app && useradd -c 'app' -u 1010 -g 1010 -m -d /home/app -s /sbin/nologin app<br />
USER app<br />
<br />
# Enfin, on précise la commande qui permet de lancer notre appli. C'est cette commande qui sera lancée par défaut par tout nouveau container lancé avec notre image<br />
CMD ["R", "-f", "app.R"]<br />
</syntaxhighlight><br />
<br />
=== Construire l'image Docker ===<br />
Pour construire l'image docker à l'aide du Dockerfile, il faut lancer la commande <code>docker build</code>. C'est à ce moment que l'on va versionner l'image en la taguant avec l'argument <code>-t</code>. On peut mettre directement plusieurs tags à une image, ou les ajouter à posteriori en relançant la commande <code>docker build</code>. Si le Dockerfile n'a pas changé depuis le dernier build, <code>docker build</code> ne fera qu'ajouter les tags à l'image existante. <br />
<br />
Pour que la CLI Docker trouve bien le Dockerfile, on lance le terminal dans le dossier ou ce Dockerfile est enregistré. <br />
<br />
<code>docker build . -t ghcr.io/evs-gis/mapdoapp:latest -t ghcr.io/evs-gis/mapdoapp:2.0.1 -t ghcr.io/evs-gis/mapdoapp:$(git rev-parse --short HEAD)</code><br />
<br />
Remarquez que le tag doit contenir le chemin complet vers le registre où sera poussée l'image (étape suivante). Si vous ne précisez pas le chemin (par exemple <code>mapdoapp:latest</code>), le registre utilisé sera DockerHub. <br />
<br />
Notez le tag <code>$(git rev-parse --short HEAD)</code> qui permet de taguer l'image avec le hash (la référence) du commit actuel (ne fonctionne que si vous êtes dans un dépôt git). Ce tag est bien pratique si vous n'incrémentez pas un numéro de version par ailleurs (<code>2.0.1</code> dans l'exemple ci-dessus). <br />
<br />
Le tag <code>latest</code> est à mettre sur la dernière version de votre image. Il sera automatiquement retiré de toutes les autres versions de votre image. <br />
<br />
La commande <code>docker images</code> permet ensuite de lister les tags disponibles localement. Si le build a réussi, vous devriez y voir votre image.<syntaxhighlight lang="bash"><br />
~$ docker images<br />
REPOSITORY TAG IMAGE ID CREATED SIZE<br />
ghcr.io/evs-gis/mapdoapp 2.0.1 b2b999e7d781 3 days ago 1.27GB<br />
ghcr.io/evs-gis/mapdoapp 7ad814c b2b999e7d781 3 days ago 1.27GB<br />
ghcr.io/evs-gis/mapdoapp latest b2b999e7d781 3 days ago 1.27GB<br />
ghcr.io/glourb/glourbapp 642e23b 8a3daa97546e 4 days ago 1.38GB<br />
ghcr.io/glourb/glourbapp latest 8a3daa97546e 4 days ago 1.38GB<br />
ghcr.io/glourb/glourbapp 502564d 9a2050fc09d4 4 days ago 1.38GB<br />
semaphoreui/semaphore v2.12.4 136bec584184 2 weeks ago 727MB<br />
ghcr.io/mastergeonum/cartondes main a95ee654e34a 5 weeks ago 205MB<br />
dockurr/windows latest c3419fd6e55a 2 months ago 384MB<br />
docker.osgeo.org/geoserver 2.26.1 a91188b23092 3 months ago 608MB<br />
rocker/verse 4.4.1 202c993befdc 3 months ago 3.77GB<br />
ghcr.io/evs-gis/glourbee-ui 1.1.0 03e05bed5617 4 months ago 1.47GB<br />
<br />
</syntaxhighlight>Remarquez que <code>ghcr.io/evs-gis/mapdoapp</code> est présente plusieurs fois avec des tags différents, mais le même IMAGE ID. Il s'agit bien de la même image et elle n'est pas dupliquée sur le disque.<br />
<br />
Pour supprimer un tag, on utilisera la commande <code>docker image rm ghcr.io/evs-gis/mapdoapp:2.0.1</code>. Si plus aucun tag n'existe pour l'image, elle sera complètement supprimée du disque local. <br />
<br />
=== Tester l'image ===<br />
<br />
=== Pousser l'image sur un registre ===<br />
Pour que le serveur ShinyProxy (ainsi que le monde entier !) puisse accéder à votre image, il faut la pousser sur un registre. Si vous ne souhaitez pas que votre image soit publique, vous pouvez utiliser le registre ghcr.io/evs-gis (le serveur ShinyProxy y a accès même si les images sont privées). <br />
<br />
== Configuration sur l'instance de dev ==<br />
Forcer le redémarrage de tous les containers de votre appli (utile uniquement dans le cas où vous avez paramétré un nombre minimum de sièges supérieur à 0)<br />
<br />
<code>docker container restart $(docker ps -q -f ancestor="ghcr.io/evs-gis/mapdoapp:latest")</code><br />
<br />
== Configuration sur l'instance de prod ==<br />
<br />
== Mise à jour d'une appli ==<br />
[[Catégorie:Tutoriel]]</div>Sdunesmehttps://isig-wiki.ens-lyon.fr/index.php?title=ShinyProxy&diff=1059ShinyProxy2025-02-21T15:35:29Z<p>Sdunesme : /* Principe de fonctionnement de ShinyProxy (et Docker) */</p>
<hr />
<div>'''<big>Attention : Page en cours de rédaction</big>'''<br />
<br />
ISIG-Apps passe sous ShinyProxy pour améliorer la stabilité et l'isolation de vos applications pendant les montées en charge. Le fonctionnement est très différent par rapport à l'ancien Shiny-Server et nécessite quelques bases dans l'utilisation de Docker. L'objectif de cette page est de vous guider, rapidement et simplement, dans le nouveau workflow dev > prod en partant du principe que vous ne connaissez encore pas grand-chose à Docker.<br />
<br />
== Principe de fonctionnement de ShinyProxy (et Docker) ==<br />
ShinyProxy fonctionne comme un orchestrateur de conteneurs Docker. Chaque appli configurée doit avoir une image Docker associée présente sur le serveur qui exécute ShinyProxy. C'est ShinyProxy qui s'occupera ensuite de lancer et stopper un conteneur à chaque fois qu'un internaute se connectera ou se déconnectera de votre appli. <br />
[[Fichier:Schéma Docker.png|centré|sans_cadre|1054x1054px]] <br />
<br />
Afin que votre application puisse fonctionner sur ShinyProxy, il va donc falloir créer une '''image''' qui permettra au serveur ShinyProxy de lancer des '''containers''' de votre application. <br />
<br />
Vous n'aurez généralement pas besoin de volume pour stocker des données pérennes dans le cas d'une application Shiny. Si votre application utilise une base de données, celle-ci devra être externalisée (hébergée sur le serveur de bases de données d'ISIG par exemple). <br />
<br />
== Conteneurisation de votre appli Shiny ==<br />
La conteneurisation peut se faire directement sur votre machine personelle si vous y avez installé Docker (https://docs.docker.com/engine/install/), ou sur le serveur isig-apps de dev via [https://rstudio.evs.ens-lyon.fr Rstudio server] et son terminal intégré.<br />
<br />
=== Fixer le port ===<br />
Pour fonctionner en mode conteneurisé, votre application devra écouter toujours sur le même port (ce qui n'est pas le comportement par défaut d'une application Shiny). <br />
<br />
Afin de s'en assurer, il faut : <br />
<br />
* Dans le cas d'un appli Shiny classique, ajouter dans <code>options(..)</code>, avant l'appel de <code>shinyApp(..)</code>, les options suivantes : <code>"shiny.port"=3841</code> et <code>"shiny.host"="0.0.0.0"</code>. Par exemple :<br />
<syntaxhighlight lang="r"><br />
library(shiny)<br />
library(glourbi)<br />
<br />
options("shiny.port" = 3841, "shiny.host" = "0.0.0.0", "golem.app.prod" = TRUE)<br />
<br />
shinyApp(ui=glourbapp:::app_ui,server=glourbapp:::app_server)<br />
</syntaxhighlight><br />
<br />
* Dans le cas d'un document Rmarkdown, ........<br />
<br />
=== Choisir l'image source ===<br />
La construction d'une image Docker se fait sur la base... d'une autre. On choisi en général son image de base en fonction de ce qu'on va faire avec. Pour une application Shiny, nous aurons besoin d'une image Docker spécialisée en R. <br />
<br />
Le [https://rocker-project.org/images/ projet Rocker] propose plusieurs images de base avec différentes quantités de packages pré-installés. Lorsque l'on choisi son image de base, il faut trouver le bon compromis entre une image légère et une image avec suffisamment de dépendances pré-installées pour qu'elle soit pratique.<br />
<br />
L'image [https://eddelbuettel.github.io/r2u/ r2u] est une bonne base assez simple à utiliser, car elle va chercher des binaires précompilés des packages R que l'on souhaite installer et toutes leurs dépendances, librairies système incluses ! Pratiquement rien n'y est pré-installé, il faudra donc bien préciser toutes les dépendances dont vous avez besoin. En contrepartie, l'image sera plutôt légère, ce qui est une bonne chose ! L'inconvénient de cette fonctionnalité est (à ma connaissance) qu'elle ne fonctionne qu'avec la fonction <code>install.packages(...)</code>. Il n'est donc pas possible d'installer une version spécifique d'un package avec <code>remotes::install_version(...)</code> par exemple (la fonction reste utilisable de manière classique). <br />
<br />
=== Écrire le Dockerfile ===<br />
<br />
La création d'une image Docker repose sur l'écriture d'un fichier texte appelé '''Dockerfile''' (sans extension).<br />
<br />
Voici un exemple de Dockerfile pour l'application GloUrb :<syntaxhighlight lang="dockerfile"><br />
# On commence par définir l'image sur laquelle va se baser la notre<br />
FROM rocker/r2u:jammy<br />
<br />
# On précise quelques infos qui permettrons d'identifier l'image<br />
LABEL org.opencontainers.image.authors="Lise Vaudor <lise.vaudor@ens-lyon.fr>, Samuel Dunesme <samuel.dunesme@ens-lyon.fr>"<br />
LABEL org.opencontainers.image.source="https://github.com/glourb/glourbapp"<br />
LABEL org.opencontainers.image.documentation="https://evs-gis.github.io/glourbdoc/"<br />
LABEL org.opencontainers.image.version="0.0.0.9000"<br />
LABEL org.opencontainers.image.description="An app for the GloUrb project"<br />
<br />
# On peut éventuellement générer des locales supplémentaires si notre appli utilise d'autres langues que l'anglais<br />
RUN locale-gen fr_FR.UTF-8<br />
<br />
# On liste maintenant toutes les dépendances R à installer<br />
RUN Rscript -e 'install.packages("tidyr")'<br />
RUN Rscript -e 'install.packages("shiny")'<br />
RUN Rscript -e 'install.packages("config")'<br />
RUN Rscript -e 'install.packages("testthat")'<br />
RUN Rscript -e 'install.packages("tibble")'<br />
RUN Rscript -e 'install.packages("purrr")'<br />
RUN Rscript -e 'install.packages("dplyr")'<br />
RUN Rscript -e 'install.packages("ggplot2")'<br />
RUN Rscript -e 'install.packages("forcats")'<br />
RUN Rscript -e 'install.packages("magrittr")'<br />
RUN Rscript -e 'install.packages("golem")'<br />
RUN Rscript -e 'install.packages("sf")'<br />
RUN Rscript -e 'install.packages("plotly")'<br />
RUN Rscript -e 'install.packages("spelling")'<br />
RUN Rscript -e 'install.packages("mclust")'<br />
RUN Rscript -e 'install.packages("leaflet")'<br />
RUN Rscript -e 'install.packages("cluster")'<br />
RUN Rscript -e 'install.packages("cowplot")'<br />
RUN Rscript -e 'install.packages("FactoMineR")'<br />
RUN Rscript -e 'install.packages("glue")'<br />
RUN Rscript -e 'install.packages("grDevices")'<br />
RUN Rscript -e 'install.packages("RColorBrewer")'<br />
RUN Rscript -e 'install.packages("remotes")'<br />
RUN Rscript -e 'install.packages("cicerone")'<br />
RUN Rscript -e 'install.packages("RPostgres")'<br />
RUN Rscript -e 'install.packages("DBI")'<br />
RUN Rscript -e 'install.packages("DT")'<br />
<br />
RUN Rscript -e 'remotes::install_github("glourb/glourbi")'<br />
<br />
# On copie l'arborescence de fichiers dans un dossier app à la racine de l'image. Ce sera le working directory des containers lancés avec notre image<br />
RUN mkdir /app<br />
ADD . /app<br />
WORKDIR /app<br />
<br />
# Si besoin, on peut installer notre package<br />
RUN R -e 'remotes::install_local()'<br />
<br />
# On détermine le port qui sera exposé (attention à bien fixer le port sur lequel votre appli écoute, cf. ci-dessus)<br />
EXPOSE 3838<br />
<br />
# Pour plus de sécurité, on fait en sorte que les containers ne se lancent pas avec l'utilisateur "root", mais avec un utilisateur "app" dédié<br />
RUN groupadd -g 1010 app && useradd -c 'app' -u 1010 -g 1010 -m -d /home/app -s /sbin/nologin app<br />
USER app<br />
<br />
# Enfin, on précise la commande qui permet de lancer notre appli. C'est cette commande qui sera lancée par défaut par tout nouveau container lancé avec notre image<br />
CMD ["R", "-f", "app.R"]<br />
</syntaxhighlight><br />
<br />
=== Construire l'image Docker ===<br />
Pour construire l'image docker à l'aide du Dockerfile, il faut lancer la commande <code>docker build</code>. C'est à ce moment que l'on va versionner l'image en la taguant avec l'argument <code>-t</code>. On peut mettre directement plusieurs tags à une image, ou les ajouter à posteriori en relançant la commande <code>docker build</code>. Si le Dockerfile n'a pas changé depuis le dernier build, <code>docker build</code> ne fera qu'ajouter les tags à l'image existante. <br />
<br />
Pour que la CLI Docker trouve bien le Dockerfile, on lance le terminal dans le dossier ou ce Dockerfile est enregistré. <br />
<br />
<code>docker build . -t ghcr.io/evs-gis/mapdoapp:latest -t ghcr.io/evs-gis/mapdoapp:2.0.1 -t ghcr.io/evs-gis/mapdoapp:$(git rev-parse --short HEAD)</code><br />
<br />
Remarquez que le tag doit contenir le chemin complet vers le registre où sera poussée l'image (étape suivante). Si vous ne précisez pas le chemin (par exemple <code>mapdoapp:latest</code>), le registre utilisé sera DockerHub. <br />
<br />
Notez le tag <code>$(git rev-parse --short HEAD)</code> qui permet de taguer l'image avec le hash (la référence) du commit actuel (ne fonctionne que si vous êtes dans un dépôt git). Ce tag est bien pratique si vous n'incrémentez pas un numéro de version par ailleurs (<code>2.0.1</code> dans l'exemple ci-dessus). <br />
<br />
Le tag <code>latest</code> est à mettre sur la dernière version de votre image. Il sera automatiquement retiré de toutes les autres versions de votre image. <br />
<br />
=== Pousser l'image sur un registre ===<br />
Pour que le serveur ShinyProxy (ainsi que le monde entier !) puisse accéder à votre image, il faut la pousser sur un registre. Si vous ne souhaitez pas que votre image soit publique, vous pouvez utiliser le registre ghcr.io/evs-gis (le serveur ShinyProxy y a accès même si les images sont privées). <br />
<br />
== Configuration sur l'instance de dev ==<br />
Forcer le redémarrage de tous les containers de votre appli (utile uniquement dans le cas où vous avez paramétré un nombre minimum de sièges supérieur à 0)<br />
<br />
<code>docker container restart $(docker ps -q -f ancestor="ghcr.io/evs-gis/mapdoapp:latest")</code><br />
<br />
== Configuration sur l'instance de prod ==<br />
<br />
== Mise à jour d'une appli ==<br />
[[Catégorie:Tutoriel]]</div>Sdunesmehttps://isig-wiki.ens-lyon.fr/index.php?title=ShinyProxy&diff=1058ShinyProxy2025-02-21T15:33:29Z<p>Sdunesme : /* Construire l'image Docker */</p>
<hr />
<div>'''<big>Attention : Page en cours de rédaction</big>'''<br />
<br />
ISIG-Apps passe sous ShinyProxy pour améliorer la stabilité et l'isolation de vos applications pendant les montées en charge. Le fonctionnement est très différent par rapport à l'ancien Shiny-Server et nécessite quelques bases dans l'utilisation de Docker. L'objectif de cette page est de vous guider, rapidement et simplement, dans le nouveau workflow dev > prod en partant du principe que vous ne connaissez encore pas grand-chose à Docker.<br />
<br />
== Principe de fonctionnement de ShinyProxy (et Docker) ==<br />
ShinyProxy fonctionne comme un orchestrateur de conteneurs Docker. Chaque appli configurée doit avoir une image Docker associée présente sur le serveur qui exécute ShinyProxy. C'est ShinyProxy qui s'occupera ensuite de lancer et stopper un conteneur à chaque fois qu'un internaute se connectera ou se déconnectera de votre appli. <br />
<br />
Afin que votre application puisse fonctionner sur ShinyProxy, il va donc falloir créer une '''image''' qui permettra au serveur ShinyProxy de lancer des '''containers''' de votre application. <br />
<br />
Vous n'aurez généralement pas besoin de volume pour stocker des données pérennes dans le cas d'une application Shiny. Si votre application utilise une base de données, celle-ci devra être externalisée (hébergée sur le serveur de bases de données d'ISIG par exemple). <br />
<br />
== Conteneurisation de votre appli Shiny ==<br />
La conteneurisation peut se faire directement sur votre machine personelle si vous y avez installé Docker (https://docs.docker.com/engine/install/), ou sur le serveur isig-apps de dev via [https://rstudio.evs.ens-lyon.fr Rstudio server] et son terminal intégré.<br />
<br />
=== Fixer le port ===<br />
Pour fonctionner en mode conteneurisé, votre application devra écouter toujours sur le même port (ce qui n'est pas le comportement par défaut d'une application Shiny). <br />
<br />
Afin de s'en assurer, il faut : <br />
<br />
* Dans le cas d'un appli Shiny classique, ajouter dans <code>options(..)</code>, avant l'appel de <code>shinyApp(..)</code>, les options suivantes : <code>"shiny.port"=3841</code> et <code>"shiny.host"="0.0.0.0"</code>. Par exemple :<br />
<syntaxhighlight lang="r"><br />
library(shiny)<br />
library(glourbi)<br />
<br />
options("shiny.port" = 3841, "shiny.host" = "0.0.0.0", "golem.app.prod" = TRUE)<br />
<br />
shinyApp(ui=glourbapp:::app_ui,server=glourbapp:::app_server)<br />
</syntaxhighlight><br />
<br />
* Dans le cas d'un document Rmarkdown, ........<br />
<br />
=== Choisir l'image source ===<br />
La construction d'une image Docker se fait sur la base... d'une autre. On choisi en général son image de base en fonction de ce qu'on va faire avec. Pour une application Shiny, nous aurons besoin d'une image Docker spécialisée en R. <br />
<br />
Le [https://rocker-project.org/images/ projet Rocker] propose plusieurs images de base avec différentes quantités de packages pré-installés. Lorsque l'on choisi son image de base, il faut trouver le bon compromis entre une image légère et une image avec suffisamment de dépendances pré-installées pour qu'elle soit pratique.<br />
<br />
L'image [https://eddelbuettel.github.io/r2u/ r2u] est une bonne base assez simple à utiliser, car elle va chercher des binaires précompilés des packages R que l'on souhaite installer et toutes leurs dépendances, librairies système incluses ! Pratiquement rien n'y est pré-installé, il faudra donc bien préciser toutes les dépendances dont vous avez besoin. En contrepartie, l'image sera plutôt légère, ce qui est une bonne chose ! L'inconvénient de cette fonctionnalité est (à ma connaissance) qu'elle ne fonctionne qu'avec la fonction <code>install.packages(...)</code>. Il n'est donc pas possible d'installer une version spécifique d'un package avec <code>remotes::install_version(...)</code> par exemple (la fonction reste utilisable de manière classique). <br />
<br />
=== Écrire le Dockerfile ===<br />
<br />
La création d'une image Docker repose sur l'écriture d'un fichier texte appelé '''Dockerfile''' (sans extension).<br />
<br />
Voici un exemple de Dockerfile pour l'application GloUrb :<syntaxhighlight lang="dockerfile"><br />
# On commence par définir l'image sur laquelle va se baser la notre<br />
FROM rocker/r2u:jammy<br />
<br />
# On précise quelques infos qui permettrons d'identifier l'image<br />
LABEL org.opencontainers.image.authors="Lise Vaudor <lise.vaudor@ens-lyon.fr>, Samuel Dunesme <samuel.dunesme@ens-lyon.fr>"<br />
LABEL org.opencontainers.image.source="https://github.com/glourb/glourbapp"<br />
LABEL org.opencontainers.image.documentation="https://evs-gis.github.io/glourbdoc/"<br />
LABEL org.opencontainers.image.version="0.0.0.9000"<br />
LABEL org.opencontainers.image.description="An app for the GloUrb project"<br />
<br />
# On peut éventuellement générer des locales supplémentaires si notre appli utilise d'autres langues que l'anglais<br />
RUN locale-gen fr_FR.UTF-8<br />
<br />
# On liste maintenant toutes les dépendances R à installer<br />
RUN Rscript -e 'install.packages("tidyr")'<br />
RUN Rscript -e 'install.packages("shiny")'<br />
RUN Rscript -e 'install.packages("config")'<br />
RUN Rscript -e 'install.packages("testthat")'<br />
RUN Rscript -e 'install.packages("tibble")'<br />
RUN Rscript -e 'install.packages("purrr")'<br />
RUN Rscript -e 'install.packages("dplyr")'<br />
RUN Rscript -e 'install.packages("ggplot2")'<br />
RUN Rscript -e 'install.packages("forcats")'<br />
RUN Rscript -e 'install.packages("magrittr")'<br />
RUN Rscript -e 'install.packages("golem")'<br />
RUN Rscript -e 'install.packages("sf")'<br />
RUN Rscript -e 'install.packages("plotly")'<br />
RUN Rscript -e 'install.packages("spelling")'<br />
RUN Rscript -e 'install.packages("mclust")'<br />
RUN Rscript -e 'install.packages("leaflet")'<br />
RUN Rscript -e 'install.packages("cluster")'<br />
RUN Rscript -e 'install.packages("cowplot")'<br />
RUN Rscript -e 'install.packages("FactoMineR")'<br />
RUN Rscript -e 'install.packages("glue")'<br />
RUN Rscript -e 'install.packages("grDevices")'<br />
RUN Rscript -e 'install.packages("RColorBrewer")'<br />
RUN Rscript -e 'install.packages("remotes")'<br />
RUN Rscript -e 'install.packages("cicerone")'<br />
RUN Rscript -e 'install.packages("RPostgres")'<br />
RUN Rscript -e 'install.packages("DBI")'<br />
RUN Rscript -e 'install.packages("DT")'<br />
<br />
RUN Rscript -e 'remotes::install_github("glourb/glourbi")'<br />
<br />
# On copie l'arborescence de fichiers dans un dossier app à la racine de l'image. Ce sera le working directory des containers lancés avec notre image<br />
RUN mkdir /app<br />
ADD . /app<br />
WORKDIR /app<br />
<br />
# Si besoin, on peut installer notre package<br />
RUN R -e 'remotes::install_local()'<br />
<br />
# On détermine le port qui sera exposé (attention à bien fixer le port sur lequel votre appli écoute, cf. ci-dessus)<br />
EXPOSE 3838<br />
<br />
# Pour plus de sécurité, on fait en sorte que les containers ne se lancent pas avec l'utilisateur "root", mais avec un utilisateur "app" dédié<br />
RUN groupadd -g 1010 app && useradd -c 'app' -u 1010 -g 1010 -m -d /home/app -s /sbin/nologin app<br />
USER app<br />
<br />
# Enfin, on précise la commande qui permet de lancer notre appli. C'est cette commande qui sera lancée par défaut par tout nouveau container lancé avec notre image<br />
CMD ["R", "-f", "app.R"]<br />
</syntaxhighlight><br />
<br />
=== Construire l'image Docker ===<br />
Pour construire l'image docker à l'aide du Dockerfile, il faut lancer la commande <code>docker build</code>. C'est à ce moment que l'on va versionner l'image en la taguant avec l'argument <code>-t</code>. On peut mettre directement plusieurs tags à une image, ou les ajouter à posteriori en relançant la commande <code>docker build</code>. Si le Dockerfile n'a pas changé depuis le dernier build, <code>docker build</code> ne fera qu'ajouter les tags à l'image existante. <br />
<br />
Pour que la CLI Docker trouve bien le Dockerfile, on lance le terminal dans le dossier ou ce Dockerfile est enregistré. <br />
<br />
<code>docker build . -t ghcr.io/evs-gis/mapdoapp:latest -t ghcr.io/evs-gis/mapdoapp:2.0.1 -t ghcr.io/evs-gis/mapdoapp:$(git rev-parse --short HEAD)</code><br />
<br />
Remarquez que le tag doit contenir le chemin complet vers le registre où sera poussée l'image (étape suivante). Si vous ne précisez pas le chemin (par exemple <code>mapdoapp:latest</code>), le registre utilisé sera DockerHub. <br />
<br />
Notez le tag <code>$(git rev-parse --short HEAD)</code> qui permet de taguer l'image avec le hash (la référence) du commit actuel (ne fonctionne que si vous êtes dans un dépôt git). Ce tag est bien pratique si vous n'incrémentez pas un numéro de version par ailleurs (<code>2.0.1</code> dans l'exemple ci-dessus). <br />
<br />
Le tag <code>latest</code> est à mettre sur la dernière version de votre image. Il sera automatiquement retiré de toutes les autres versions de votre image. <br />
<br />
=== Pousser l'image sur un registre ===<br />
Pour que le serveur ShinyProxy (ainsi que le monde entier !) puisse accéder à votre image, il faut la pousser sur un registre. Si vous ne souhaitez pas que votre image soit publique, vous pouvez utiliser le registre ghcr.io/evs-gis (le serveur ShinyProxy y a accès même si les images sont privées). <br />
<br />
== Configuration sur l'instance de dev ==<br />
Forcer le redémarrage de tous les containers de votre appli (utile uniquement dans le cas où vous avez paramétré un nombre minimum de sièges supérieur à 0)<br />
<br />
<code>docker container restart $(docker ps -q -f ancestor="ghcr.io/evs-gis/mapdoapp:latest")</code><br />
<br />
== Configuration sur l'instance de prod ==<br />
<br />
== Mise à jour d'une appli ==<br />
[[Catégorie:Tutoriel]]</div>Sdunesmehttps://isig-wiki.ens-lyon.fr/index.php?title=Fichier:Sch%C3%A9ma_Docker.png&diff=1057Fichier:Schéma Docker.png2025-02-21T15:33:11Z<p>Sdunesme : </p>
<hr />
<div>Schéma de fonctionnement basique d'une application sous Docker</div>Sdunesmehttps://isig-wiki.ens-lyon.fr/index.php?title=ShinyProxy&diff=1056ShinyProxy2025-02-21T15:22:50Z<p>Sdunesme : /* Choisir l'image source */</p>
<hr />
<div>'''<big>Attention : Page en cours de rédaction</big>'''<br />
<br />
ISIG-Apps passe sous ShinyProxy pour améliorer la stabilité et l'isolation de vos applications pendant les montées en charge. Le fonctionnement est très différent par rapport à l'ancien Shiny-Server et nécessite quelques bases dans l'utilisation de Docker. L'objectif de cette page est de vous guider, rapidement et simplement, dans le nouveau workflow dev > prod en partant du principe que vous ne connaissez encore pas grand-chose à Docker.<br />
<br />
== Principe de fonctionnement de ShinyProxy (et Docker) ==<br />
ShinyProxy fonctionne comme un orchestrateur de conteneurs Docker. Chaque appli configurée doit avoir une image Docker associée présente sur le serveur qui exécute ShinyProxy. C'est ShinyProxy qui s'occupera ensuite de lancer et stopper un conteneur à chaque fois qu'un internaute se connectera ou se déconnectera de votre appli. <br />
<br />
Afin que votre application puisse fonctionner sur ShinyProxy, il va donc falloir créer une '''image''' qui permettra au serveur ShinyProxy de lancer des '''containers''' de votre application. <br />
<br />
Vous n'aurez généralement pas besoin de volume pour stocker des données pérennes dans le cas d'une application Shiny. Si votre application utilise une base de données, celle-ci devra être externalisée (hébergée sur le serveur de bases de données d'ISIG par exemple). <br />
<br />
== Conteneurisation de votre appli Shiny ==<br />
La conteneurisation peut se faire directement sur votre machine personelle si vous y avez installé Docker (https://docs.docker.com/engine/install/), ou sur le serveur isig-apps de dev via [https://rstudio.evs.ens-lyon.fr Rstudio server] et son terminal intégré.<br />
<br />
=== Fixer le port ===<br />
Pour fonctionner en mode conteneurisé, votre application devra écouter toujours sur le même port (ce qui n'est pas le comportement par défaut d'une application Shiny). <br />
<br />
Afin de s'en assurer, il faut : <br />
<br />
* Dans le cas d'un appli Shiny classique, ajouter dans <code>options(..)</code>, avant l'appel de <code>shinyApp(..)</code>, les options suivantes : <code>"shiny.port"=3841</code> et <code>"shiny.host"="0.0.0.0"</code>. Par exemple :<br />
<syntaxhighlight lang="r"><br />
library(shiny)<br />
library(glourbi)<br />
<br />
options("shiny.port" = 3841, "shiny.host" = "0.0.0.0", "golem.app.prod" = TRUE)<br />
<br />
shinyApp(ui=glourbapp:::app_ui,server=glourbapp:::app_server)<br />
</syntaxhighlight><br />
<br />
* Dans le cas d'un document Rmarkdown, ........<br />
<br />
=== Choisir l'image source ===<br />
La construction d'une image Docker se fait sur la base... d'une autre. On choisi en général son image de base en fonction de ce qu'on va faire avec. Pour une application Shiny, nous aurons besoin d'une image Docker spécialisée en R. <br />
<br />
Le [https://rocker-project.org/images/ projet Rocker] propose plusieurs images de base avec différentes quantités de packages pré-installés. Lorsque l'on choisi son image de base, il faut trouver le bon compromis entre une image légère et une image avec suffisamment de dépendances pré-installées pour qu'elle soit pratique.<br />
<br />
L'image [https://eddelbuettel.github.io/r2u/ r2u] est une bonne base assez simple à utiliser, car elle va chercher des binaires précompilés des packages R que l'on souhaite installer et toutes leurs dépendances, librairies système incluses ! Pratiquement rien n'y est pré-installé, il faudra donc bien préciser toutes les dépendances dont vous avez besoin. En contrepartie, l'image sera plutôt légère, ce qui est une bonne chose ! L'inconvénient de cette fonctionnalité est (à ma connaissance) qu'elle ne fonctionne qu'avec la fonction <code>install.packages(...)</code>. Il n'est donc pas possible d'installer une version spécifique d'un package avec <code>remotes::install_version(...)</code> par exemple (la fonction reste utilisable de manière classique). <br />
<br />
=== Écrire le Dockerfile ===<br />
<br />
La création d'une image Docker repose sur l'écriture d'un fichier texte appelé '''Dockerfile''' (sans extension).<br />
<br />
Voici un exemple de Dockerfile pour l'application GloUrb :<syntaxhighlight lang="dockerfile"><br />
# On commence par définir l'image sur laquelle va se baser la notre<br />
FROM rocker/r2u:jammy<br />
<br />
# On précise quelques infos qui permettrons d'identifier l'image<br />
LABEL org.opencontainers.image.authors="Lise Vaudor <lise.vaudor@ens-lyon.fr>, Samuel Dunesme <samuel.dunesme@ens-lyon.fr>"<br />
LABEL org.opencontainers.image.source="https://github.com/glourb/glourbapp"<br />
LABEL org.opencontainers.image.documentation="https://evs-gis.github.io/glourbdoc/"<br />
LABEL org.opencontainers.image.version="0.0.0.9000"<br />
LABEL org.opencontainers.image.description="An app for the GloUrb project"<br />
<br />
# On peut éventuellement générer des locales supplémentaires si notre appli utilise d'autres langues que l'anglais<br />
RUN locale-gen fr_FR.UTF-8<br />
<br />
# On liste maintenant toutes les dépendances R à installer<br />
RUN Rscript -e 'install.packages("tidyr")'<br />
RUN Rscript -e 'install.packages("shiny")'<br />
RUN Rscript -e 'install.packages("config")'<br />
RUN Rscript -e 'install.packages("testthat")'<br />
RUN Rscript -e 'install.packages("tibble")'<br />
RUN Rscript -e 'install.packages("purrr")'<br />
RUN Rscript -e 'install.packages("dplyr")'<br />
RUN Rscript -e 'install.packages("ggplot2")'<br />
RUN Rscript -e 'install.packages("forcats")'<br />
RUN Rscript -e 'install.packages("magrittr")'<br />
RUN Rscript -e 'install.packages("golem")'<br />
RUN Rscript -e 'install.packages("sf")'<br />
RUN Rscript -e 'install.packages("plotly")'<br />
RUN Rscript -e 'install.packages("spelling")'<br />
RUN Rscript -e 'install.packages("mclust")'<br />
RUN Rscript -e 'install.packages("leaflet")'<br />
RUN Rscript -e 'install.packages("cluster")'<br />
RUN Rscript -e 'install.packages("cowplot")'<br />
RUN Rscript -e 'install.packages("FactoMineR")'<br />
RUN Rscript -e 'install.packages("glue")'<br />
RUN Rscript -e 'install.packages("grDevices")'<br />
RUN Rscript -e 'install.packages("RColorBrewer")'<br />
RUN Rscript -e 'install.packages("remotes")'<br />
RUN Rscript -e 'install.packages("cicerone")'<br />
RUN Rscript -e 'install.packages("RPostgres")'<br />
RUN Rscript -e 'install.packages("DBI")'<br />
RUN Rscript -e 'install.packages("DT")'<br />
<br />
RUN Rscript -e 'remotes::install_github("glourb/glourbi")'<br />
<br />
# On copie l'arborescence de fichiers dans un dossier app à la racine de l'image. Ce sera le working directory des containers lancés avec notre image<br />
RUN mkdir /app<br />
ADD . /app<br />
WORKDIR /app<br />
<br />
# Si besoin, on peut installer notre package<br />
RUN R -e 'remotes::install_local()'<br />
<br />
# On détermine le port qui sera exposé (attention à bien fixer le port sur lequel votre appli écoute, cf. ci-dessus)<br />
EXPOSE 3838<br />
<br />
# Pour plus de sécurité, on fait en sorte que les containers ne se lancent pas avec l'utilisateur "root", mais avec un utilisateur "app" dédié<br />
RUN groupadd -g 1010 app && useradd -c 'app' -u 1010 -g 1010 -m -d /home/app -s /sbin/nologin app<br />
USER app<br />
<br />
# Enfin, on précise la commande qui permet de lancer notre appli. C'est cette commande qui sera lancée par défaut par tout nouveau container lancé avec notre image<br />
CMD ["R", "-f", "app.R"]<br />
</syntaxhighlight><br />
<br />
=== Construire l'image Docker ===<br />
Pour construire l'image docker à l'aide du Dockerfile, il faut lancer la commande <code>docker build</code>. C'est à ce moment que l'on va versionner l'image en la taguant avec l'argument <code>-t</code>. On peut mettre directement plusieurs tags à une image, ou les ajouter à posteriori en relançant la commande <code>docker build</code>. Si le Dockerfile n'a pas changé depuis le dernier build, <code>docker build</code> ne fera qu'ajouter les tags à l'image existante. <br />
<br />
Pour que la CLI Docker trouve bien le Dockerfile, on lance le terminal dans le dossier ou ce Dockerfile est enregistré. <br />
<br />
<code>docker build . -t ghcr.io/evs-gis/mapdoapp:latest -t ghcr.io/evs-gis/mapdoapp:2.0.1 -t ghcr.io/evs-gis/mapdoapp:$(git rev-parse --short HEAD)</code><br />
<br />
Remarquez que le tag doit contenir le chemin complet vers le registre où sera poussée l'image (étape suivante). Si vous ne précisez pas le chemin (par exemple <code>mapdoapp:latest</code>), le registre utilisé sera DockerHub. <br />
<br />
=== Pousser l'image sur un registre ===<br />
<br />
== Configuration sur l'instance de dev ==<br />
Forcer le redémarrage de tous les containers de votre appli (utile uniquement dans le cas où vous avez paramétré un nombre minimum de sièges supérieur à 0)<br />
<br />
<code>docker container restart $(docker ps -q -f ancestor="ghcr.io/evs-gis/mapdoapp:latest")</code><br />
<br />
== Configuration sur l'instance de prod ==<br />
<br />
== Mise à jour d'une appli ==<br />
[[Catégorie:Tutoriel]]</div>Sdunesmehttps://isig-wiki.ens-lyon.fr/index.php?title=ShinyProxy&diff=1055ShinyProxy2025-02-21T15:08:14Z<p>Sdunesme : </p>
<hr />
<div>'''<big>Attention : Page en cours de rédaction</big>'''<br />
<br />
ISIG-Apps passe sous ShinyProxy pour améliorer la stabilité et l'isolation de vos applications pendant les montées en charge. Le fonctionnement est très différent par rapport à l'ancien Shiny-Server et nécessite quelques bases dans l'utilisation de Docker. L'objectif de cette page est de vous guider, rapidement et simplement, dans le nouveau workflow dev > prod en partant du principe que vous ne connaissez encore pas grand-chose à Docker.<br />
<br />
== Principe de fonctionnement de ShinyProxy (et Docker) ==<br />
ShinyProxy fonctionne comme un orchestrateur de conteneurs Docker. Chaque appli configurée doit avoir une image Docker associée présente sur le serveur qui exécute ShinyProxy. C'est ShinyProxy qui s'occupera ensuite de lancer et stopper un conteneur à chaque fois qu'un internaute se connectera ou se déconnectera de votre appli. <br />
<br />
Afin que votre application puisse fonctionner sur ShinyProxy, il va donc falloir créer une '''image''' qui permettra au serveur ShinyProxy de lancer des '''containers''' de votre application. <br />
<br />
Vous n'aurez généralement pas besoin de volume pour stocker des données pérennes dans le cas d'une application Shiny. Si votre application utilise une base de données, celle-ci devra être externalisée (hébergée sur le serveur de bases de données d'ISIG par exemple). <br />
<br />
== Conteneurisation de votre appli Shiny ==<br />
La conteneurisation peut se faire directement sur votre machine personelle si vous y avez installé Docker (https://docs.docker.com/engine/install/), ou sur le serveur isig-apps de dev via [https://rstudio.evs.ens-lyon.fr Rstudio server] et son terminal intégré.<br />
<br />
=== Fixer le port ===<br />
Pour fonctionner en mode conteneurisé, votre application devra écouter toujours sur le même port (ce qui n'est pas le comportement par défaut d'une application Shiny). <br />
<br />
Afin de s'en assurer, il faut : <br />
<br />
* Dans le cas d'un appli Shiny classique, ajouter dans <code>options(..)</code>, avant l'appel de <code>shinyApp(..)</code>, les options suivantes : <code>"shiny.port"=3841</code> et <code>"shiny.host"="0.0.0.0"</code>. Par exemple :<br />
<syntaxhighlight lang="r"><br />
library(shiny)<br />
library(glourbi)<br />
<br />
options("shiny.port" = 3841, "shiny.host" = "0.0.0.0", "golem.app.prod" = TRUE)<br />
<br />
shinyApp(ui=glourbapp:::app_ui,server=glourbapp:::app_server)<br />
</syntaxhighlight><br />
<br />
* Dans le cas d'un document Rmarkdown, ........<br />
<br />
=== Choisir l'image source ===<br />
https://rocker-project.org/images/<br />
<br />
L'image r2u est une bonne base assez simple à utiliser, car elle va chercher des binaires précompilés des packages R que l'on souhaite installer et toutes leurs dépendances, librairies système incluses ! Pratiquement rien n'y est pré-installé, il faudra donc bien préciser toutes les dépendances dont vous avez besoin. En contrepartie, l'image sera plutôt légère, ce qui est une bonne chose ! <br />
<br />
=== Écrire le Dockerfile ===<br />
<br />
<br />
Voici un exemple de Dockerfile pour l'application GloUrb :<syntaxhighlight lang="dockerfile"><br />
# On commence par définir l'image sur laquelle va se baser la notre<br />
FROM rocker/r2u:jammy<br />
<br />
# On précise quelques infos qui permettrons d'identifier l'image<br />
LABEL org.opencontainers.image.authors="Lise Vaudor <lise.vaudor@ens-lyon.fr>, Samuel Dunesme <samuel.dunesme@ens-lyon.fr>"<br />
LABEL org.opencontainers.image.source="https://github.com/glourb/glourbapp"<br />
LABEL org.opencontainers.image.documentation="https://evs-gis.github.io/glourbdoc/"<br />
LABEL org.opencontainers.image.version="0.0.0.9000"<br />
LABEL org.opencontainers.image.description="An app for the GloUrb project"<br />
<br />
# On peut éventuellement générer des locales supplémentaires si notre appli utilise d'autres langues que l'anglais<br />
RUN locale-gen fr_FR.UTF-8<br />
<br />
# On liste maintenant toutes les dépendances R à installer<br />
RUN Rscript -e 'install.packages("tidyr")'<br />
RUN Rscript -e 'install.packages("shiny")'<br />
RUN Rscript -e 'install.packages("config")'<br />
RUN Rscript -e 'install.packages("testthat")'<br />
RUN Rscript -e 'install.packages("tibble")'<br />
RUN Rscript -e 'install.packages("purrr")'<br />
RUN Rscript -e 'install.packages("dplyr")'<br />
RUN Rscript -e 'install.packages("ggplot2")'<br />
RUN Rscript -e 'install.packages("forcats")'<br />
RUN Rscript -e 'install.packages("magrittr")'<br />
RUN Rscript -e 'install.packages("golem")'<br />
RUN Rscript -e 'install.packages("sf")'<br />
RUN Rscript -e 'install.packages("plotly")'<br />
RUN Rscript -e 'install.packages("spelling")'<br />
RUN Rscript -e 'install.packages("mclust")'<br />
RUN Rscript -e 'install.packages("leaflet")'<br />
RUN Rscript -e 'install.packages("cluster")'<br />
RUN Rscript -e 'install.packages("cowplot")'<br />
RUN Rscript -e 'install.packages("FactoMineR")'<br />
RUN Rscript -e 'install.packages("glue")'<br />
RUN Rscript -e 'install.packages("grDevices")'<br />
RUN Rscript -e 'install.packages("RColorBrewer")'<br />
RUN Rscript -e 'install.packages("remotes")'<br />
RUN Rscript -e 'install.packages("cicerone")'<br />
RUN Rscript -e 'install.packages("RPostgres")'<br />
RUN Rscript -e 'install.packages("DBI")'<br />
RUN Rscript -e 'install.packages("DT")'<br />
<br />
RUN Rscript -e 'remotes::install_github("glourb/glourbi")'<br />
<br />
# On copie l'arborescence de fichiers dans un dossier app à la racine de l'image. Ce sera le working directory des containers lancés avec notre image<br />
RUN mkdir /app<br />
ADD . /app<br />
WORKDIR /app<br />
<br />
# Si besoin, on peut installer notre package<br />
RUN R -e 'remotes::install_local()'<br />
<br />
# On détermine le port qui sera exposé (attention à bien fixer le port sur lequel votre appli écoute, cf. ci-dessus)<br />
EXPOSE 3838<br />
<br />
# Pour plus de sécurité, on fait en sorte que les containers ne se lancent pas avec l'utilisateur "root", mais avec un utilisateur "app" dédié<br />
RUN groupadd -g 1010 app && useradd -c 'app' -u 1010 -g 1010 -m -d /home/app -s /sbin/nologin app<br />
USER app<br />
<br />
# Enfin, on précise la commande qui permet de lancer notre appli. C'est cette commande qui sera lancée par défaut par tout nouveau container lancé avec notre image<br />
CMD ["R", "-f", "app.R"]<br />
</syntaxhighlight><br />
<br />
=== Construire l'image Docker ===<br />
Pour construire l'image docker à l'aide du Dockerfile, il faut lancer la commande docker build. Il est important de taguer l'image avec l'option -t.<br />
<br />
<code>docker build ./Dockerfile -t ghcr.io/evs-gis/mapdoapp:latest -t ghcr.io/evs-gis/mapdoapp:2.0.1 -t ghcr.io/evs-gis/mapdoapp:$(git rev-parse --short HEAD)</code><br />
<br />
=== Pousser l'image sur un registre ===<br />
<br />
== Configuration sur l'instance de dev ==<br />
Forcer le redémarrage de tous les containers de votre appli (utile uniquement dans le cas où vous avez paramétré un nombre minimum de sièges supérieur à 0)<br />
<br />
<code>docker container restart $(docker ps -q -f ancestor="ghcr.io/evs-gis/mapdoapp:latest")</code><br />
<br />
== Configuration sur l'instance de prod ==<br />
<br />
== Mise à jour d'une appli ==<br />
[[Catégorie:Tutoriel]]</div>Sdunesmehttps://isig-wiki.ens-lyon.fr/index.php?title=ShinyProxy&diff=1054ShinyProxy2025-02-21T14:59:44Z<p>Sdunesme : </p>
<hr />
<div>'''<big>Attention : Page en cours de rédaction</big>'''<br />
<br />
ISIG-Apps passe sous ShinyProxy pour améliorer la stabilité et l'isolation de vos applications pendant les montées en charge. Le fonctionnement est très différent par rapport à l'ancien Shiny-Server et nécessite quelques bases dans l'utilisation de Docker. L'objectif de cette page est de vous guider, rapidement et simplement, dans le nouveau workflow dev > prod en partant du principe que vous ne connaissez encore pas grand-chose à Docker.<br />
<br />
== Principe de fonctionnement de ShinyProxy (et Docker) ==<br />
ShinyProxy fonctionne comme un orchestrateur de conteneurs Docker. Chaque appli configurée doit avoir une image Docker associée présente sur le serveur qui exécute ShinyProxy. C'est ShinyProxy qui s'occupera ensuite de lancer et stopper un conteneur à chaque fois qu'un internaute se connectera ou se déconnectera de votre appli. <br />
<br />
Afin que votre application puisse fonctionner sur ShinyProxy, il va donc falloir créer une '''image''' qui permettra au serveur ShinyProxy de lancer des '''containers''' de votre application. <br />
<br />
Vous n'aurez généralement pas besoin de volume pour stocker des données pérennes dans le cas d'une application Shiny. Si votre application utilise une base de données, celle-ci devra être externalisée (hébergée sur le serveur de bases de données d'ISIG par exemple). <br />
<br />
== Conteneurisation de votre appli Shiny ==<br />
La conteneurisation peut se faire directement sur votre machine personelle si vous y avez installé Docker (https://docs.docker.com/engine/install/), ou sur le serveur isig-apps de dev via [https://rstudio.evs.ens-lyon.fr Rstudio server] et son terminal intégré.<br />
<br />
=== Fixer le port ===<br />
Pour fonctionner en mode conteneurisé, votre application devra écouter toujours sur le même port (ce qui n'est pas le comportement par défaut d'une application Shiny). <br />
<br />
Afin de s'en assurer, il faut ..........<br />
<br />
=== Choisir l'image source ===<br />
https://rocker-project.org/images/<br />
<br />
L'image r2u est une bonne base assez simple à utiliser, car elle va chercher des binaires précompilés des packages R que l'on souhaite installer et toutes leurs dépendances, librairies système incluses ! Pratiquement rien n'y est pré-installé, il faudra donc bien préciser toutes les dépendances dont vous avez besoin. En contrepartie, l'image sera plutôt légère, ce qui est une bonne chose ! <br />
<br />
=== Écrire le Dockerfile ===<br />
<br />
<br />
Voici un exemple de Dockerfile pour l'application GloUrb :<syntaxhighlight lang="dockerfile"><br />
# On commence par définir l'image sur laquelle va se baser la notre<br />
FROM rocker/r2u:jammy<br />
<br />
# On précise quelques infos qui permettrons d'identifier l'image<br />
LABEL org.opencontainers.image.authors="Lise Vaudor <lise.vaudor@ens-lyon.fr>, Samuel Dunesme <samuel.dunesme@ens-lyon.fr>"<br />
LABEL org.opencontainers.image.source="https://github.com/glourb/glourbapp"<br />
LABEL org.opencontainers.image.documentation="https://evs-gis.github.io/glourbdoc/"<br />
LABEL org.opencontainers.image.version="0.0.0.9000"<br />
LABEL org.opencontainers.image.description="An app for the GloUrb project"<br />
<br />
# On peut éventuellement générer des locales supplémentaires si notre appli utilise d'autres langues que l'anglais<br />
RUN locale-gen fr_FR.UTF-8<br />
<br />
# On liste maintenant toutes les dépendances R à installer<br />
RUN Rscript -e 'install.packages("tidyr")'<br />
RUN Rscript -e 'install.packages("shiny")'<br />
RUN Rscript -e 'install.packages("config")'<br />
RUN Rscript -e 'install.packages("testthat")'<br />
RUN Rscript -e 'install.packages("tibble")'<br />
RUN Rscript -e 'install.packages("purrr")'<br />
RUN Rscript -e 'install.packages("dplyr")'<br />
RUN Rscript -e 'install.packages("ggplot2")'<br />
RUN Rscript -e 'install.packages("forcats")'<br />
RUN Rscript -e 'install.packages("magrittr")'<br />
RUN Rscript -e 'install.packages("golem")'<br />
RUN Rscript -e 'install.packages("sf")'<br />
RUN Rscript -e 'install.packages("plotly")'<br />
RUN Rscript -e 'install.packages("spelling")'<br />
RUN Rscript -e 'install.packages("mclust")'<br />
RUN Rscript -e 'install.packages("leaflet")'<br />
RUN Rscript -e 'install.packages("cluster")'<br />
RUN Rscript -e 'install.packages("cowplot")'<br />
RUN Rscript -e 'install.packages("FactoMineR")'<br />
RUN Rscript -e 'install.packages("glue")'<br />
RUN Rscript -e 'install.packages("grDevices")'<br />
RUN Rscript -e 'install.packages("RColorBrewer")'<br />
RUN Rscript -e 'install.packages("remotes")'<br />
RUN Rscript -e 'install.packages("cicerone")'<br />
RUN Rscript -e 'install.packages("RPostgres")'<br />
RUN Rscript -e 'install.packages("DBI")'<br />
RUN Rscript -e 'install.packages("DT")'<br />
<br />
RUN Rscript -e 'remotes::install_github("glourb/glourbi")'<br />
<br />
# On copie l'arborescence de fichiers dans un dossier app à la racine de l'image. Ce sera le working directory des containers lancés avec notre image<br />
RUN mkdir /app<br />
ADD . /app<br />
WORKDIR /app<br />
<br />
# Si besoin, on peut installer notre package<br />
RUN R -e 'remotes::install_local()'<br />
<br />
# On détermine le port qui sera exposé (attention à bien fixer le port sur lequel votre appli écoute, cf. ci-dessus)<br />
EXPOSE 3838<br />
<br />
# Pour plus de sécurité, on fait en sorte que les containers ne se lancent pas avec l'utilisateur "root", mais avec un utilisateur "app" dédié<br />
RUN groupadd -g 1010 app && useradd -c 'app' -u 1010 -g 1010 -m -d /home/app -s /sbin/nologin app<br />
USER app<br />
<br />
# Enfin, on précise la commande qui permet de lancer notre appli. C'est cette commande qui sera lancée par défaut par tout nouveau container lancé avec notre image<br />
CMD ["R", "-f", "app.R"]<br />
</syntaxhighlight><br />
<br />
=== Construire l'image Docker ===<br />
Pour construire l'image docker à l'aide du Dockerfile, il faut lancer la commande docker build. Il est important de taguer l'image avec l'option -t.<br />
<br />
<code>docker build ./Dockerfile -t ghcr.io/evs-gis/mapdoapp:latest -t ghcr.io/evs-gis/mapdoapp:2.0.1 -t ghcr.io/evs-gis/mapdoapp:$(git rev-parse --short HEAD)</code><br />
<br />
=== Pousser l'image sur un registre ===<br />
<br />
== Configuration sur l'instance de dev ==<br />
Forcer le redémarrage de tous les containers de votre appli (utile uniquement dans le cas où vous avez paramétré un nombre minimum de sièges supérieur à 0)<br />
<br />
<code>docker container restart $(docker ps -q -f ancestor="ghcr.io/evs-gis/mapdoapp:latest")</code><br />
<br />
== Configuration sur l'instance de prod ==<br />
<br />
== Mise à jour d'une appli ==<br />
[[Catégorie:Tutoriel]]</div>Sdunesmehttps://isig-wiki.ens-lyon.fr/index.php?title=ShinyProxy&diff=1053ShinyProxy2025-02-21T14:38:00Z<p>Sdunesme : </p>
<hr />
<div>'''<big>Attention : Page en cours de rédaction</big>'''<br />
<br />
ISIG-Apps passe sous ShinyProxy pour améliorer la stabilité et l'isolation de vos applications pendant les montées en charge. Le fonctionnement est très différent par rapport à l'ancien Shiny-Server et nécessite quelques bases dans l'utilisation de Docker. L'objectif de cette page est de vous guider, rapidement et simplement, dans le nouveau workflow dev > prod en partant du principe que vous ne connaissez encore pas grand-chose à Docker.<br />
<br />
== Principe de fonctionnement de ShinyProxy ==<br />
ShinyProxy fonctionne comme un orchestrateur de conteneurs Docker. Chaque appli configurée doit avoir une image Docker associée présente sur le serveur qui exécute ShinyProxy. C'est ShinyProxy qui s'occupera ensuite de lancer et stopper un conteneur à chaque fois qu'un internaute se connectera ou se déconnectera de votre appli. <br />
<br />
== Conteneurisation de votre appli Shiny ==<br />
La conteneurisation peut se faire directement sur votre machine personelle si vous y avez installé Docker (https://docs.docker.com/engine/install/), ou sur le serveur isig-apps de dev via [https://rstudio.evs.ens-lyon.fr Rstudio server] et son terminal intégré.<br />
<br />
=== Fixer le port ===<br />
<br />
=== Choisir l'image source ===<br />
https://rocker-project.org/images/<br />
<br />
L'image r2u est une bonne base assez simple à utiliser, car elle va chercher des binaires précompilés des packages R que l'on souhaite installer et toutes leurs dépendances, librairies système incluses ! Pratiquement rien n'y est pré-installé, il faudra donc bien préciser toutes les dépendances dont vous avez besoin. En contrepartie, l'image sera plutôt légère, ce qui est une bonne chose ! <br />
<br />
=== Écrire le Dockerfile ===<br />
<br />
<br />
Voici un exemple de Dockerfile pour l'application GloUrb :<syntaxhighlight lang="dockerfile"><br />
# On commence par définir l'image sur laquelle va se baser la notre<br />
FROM rocker/r2u:jammy<br />
<br />
# On précise quelques infos qui permettrons d'identifier l'image<br />
LABEL org.opencontainers.image.authors="Lise Vaudor <lise.vaudor@ens-lyon.fr>, Samuel Dunesme <samuel.dunesme@ens-lyon.fr>"<br />
LABEL org.opencontainers.image.source="https://github.com/glourb/glourbapp"<br />
LABEL org.opencontainers.image.documentation="https://evs-gis.github.io/glourbdoc/"<br />
LABEL org.opencontainers.image.version="0.0.0.9000"<br />
LABEL org.opencontainers.image.description="An app for the GloUrb project"<br />
<br />
# On peut éventuellement générer des locales supplémentaires si notre appli utilise d'autres langues que l'anglais<br />
RUN locale-gen fr_FR.UTF-8<br />
<br />
# On liste maintenant toutes les dépendances R à installer<br />
RUN Rscript -e 'install.packages("tidyr")'<br />
RUN Rscript -e 'install.packages("shiny")'<br />
RUN Rscript -e 'install.packages("config")'<br />
RUN Rscript -e 'install.packages("testthat")'<br />
RUN Rscript -e 'install.packages("tibble")'<br />
RUN Rscript -e 'install.packages("purrr")'<br />
RUN Rscript -e 'install.packages("dplyr")'<br />
RUN Rscript -e 'install.packages("ggplot2")'<br />
RUN Rscript -e 'install.packages("forcats")'<br />
RUN Rscript -e 'install.packages("magrittr")'<br />
RUN Rscript -e 'install.packages("golem")'<br />
RUN Rscript -e 'install.packages("sf")'<br />
RUN Rscript -e 'install.packages("plotly")'<br />
RUN Rscript -e 'install.packages("spelling")'<br />
RUN Rscript -e 'install.packages("mclust")'<br />
RUN Rscript -e 'install.packages("leaflet")'<br />
RUN Rscript -e 'install.packages("cluster")'<br />
RUN Rscript -e 'install.packages("cowplot")'<br />
RUN Rscript -e 'install.packages("FactoMineR")'<br />
RUN Rscript -e 'install.packages("glue")'<br />
RUN Rscript -e 'install.packages("grDevices")'<br />
RUN Rscript -e 'install.packages("RColorBrewer")'<br />
RUN Rscript -e 'install.packages("remotes")'<br />
RUN Rscript -e 'install.packages("cicerone")'<br />
RUN Rscript -e 'install.packages("RPostgres")'<br />
RUN Rscript -e 'install.packages("DBI")'<br />
RUN Rscript -e 'install.packages("DT")'<br />
<br />
RUN Rscript -e 'remotes::install_github("glourb/glourbi")'<br />
<br />
# On copie l'arborescence de fichiers dans un dossier app à la racine de l'image. Ce sera le working directory des containers lancés avec notre image<br />
RUN mkdir /app<br />
ADD . /app<br />
WORKDIR /app<br />
<br />
# Si besoin, on peut installer notre package<br />
RUN R -e 'remotes::install_local()'<br />
<br />
# On détermine le port qui sera exposé (attention à bien fixer le port sur lequel votre appli écoute, cf. ci-dessus)<br />
EXPOSE 3838<br />
<br />
# Pour plus de sécurité, on fait en sorte que les containers ne se lancent pas avec l'utilisateur "root", mais avec un utilisateur "app" dédié<br />
RUN groupadd -g 1010 app && useradd -c 'app' -u 1010 -g 1010 -m -d /home/app -s /sbin/nologin app<br />
USER app<br />
<br />
# Enfin, on précise la commande qui permet de lancer notre appli. C'est cette commande qui sera lancée par défaut par tout nouveau container lancé avec notre image<br />
CMD ["R", "-f", "app.R"]<br />
</syntaxhighlight><br />
<br />
=== Construire l'image Docker ===<br />
Pour construire l'image docker à l'aide du Dockerfile, il faut lancer la commande docker build. Il est important de taguer l'image avec l'option -t.<br />
<br />
<code>docker build ./Dockerfile -t ghcr.io/evs-gis/mapdoapp:latest -t ghcr.io/evs-gis/mapdoapp:2.0.1 -t ghcr.io/evs-gis/mapdoapp:$(git rev-parse --short HEAD)</code><br />
<br />
=== Pousser l'image sur un registre ===<br />
<br />
== Configuration sur l'instance de dev ==<br />
Forcer le redémarrage de tous les containers de votre appli (utile uniquement dans le cas où vous avez paramétré un nombre minimum de sièges supérieur à 0)<br />
<br />
<code>docker container restart $(docker ps -q -f ancestor="ghcr.io/evs-gis/mapdoapp:latest")</code><br />
<br />
== Configuration sur l'instance de prod ==<br />
<br />
== Mise à jour d'une appli ==<br />
[[Catégorie:Tutoriel]]</div>Sdunesmehttps://isig-wiki.ens-lyon.fr/index.php?title=ShinyProxy&diff=1052ShinyProxy2025-02-12T21:08:00Z<p>Sdunesme : /* Conteneurisation de votre appli Shiny */</p>
<hr />
<div>'''<big>Attention : Page en cours de rédaction</big>'''<br />
<br />
ISIG-Apps passe sous ShinyProxy pour améliorer la stabilité et l'isolation de vos applications pendant les montées en charge. Le fonctionnement est très différent par rapport à l'ancien Shiny-Server et nécessite quelques bases dans l'utilisation de Docker. L'objectif de cette page est de vous guider, rapidement et simplement, dans le nouveau workflow dev > prod en partant du principe que vous ne connaissez encore pas grand-chose à Docker.<br />
<br />
== Principe de fonctionnement de ShinyProxy ==<br />
ShinyProxy fonctionne comme un orchestrateur de conteneurs Docker. Chaque appli configurée doit avoir une image Docker associée présente sur le serveur qui exécute ShinyProxy. C'est ShinyProxy qui s'occupera ensuite de lancer et stopper un conteneur à chaque fois qu'un internaute se connectera ou se déconnectera de votre appli. <br />
<br />
== Conteneurisation de votre appli Shiny ==<br />
<br />
=== Fixer le port ===<br />
<br />
=== Choisir l'image source ===<br />
https://rocker-project.org/images/<br />
<br />
L'image r2u est une bonne base assez simple à utiliser, car elle va chercher des binaires précompilés des packages R que l'on souhaite installer et toutes leurs dépendances, librairies système incluses ! Pratiquement rien n'y est pré-installé, il faudra donc bien préciser toutes les dépendances dont vous avez besoin. En contrepartie, l'image sera plutôt légère, ce qui est une bonne chose ! <br />
<br />
=== Écrire le Dockerfile ===<br />
<br />
<br />
Voici un exemple de Dockerfile pour l'application GloUrb :<syntaxhighlight lang="dockerfile"><br />
# On commence par définir l'image sur laquelle va se baser la notre<br />
FROM rocker/r2u:jammy<br />
<br />
# On précise quelques infos qui permettrons d'identifier l'image<br />
LABEL org.opencontainers.image.authors="Lise Vaudor <lise.vaudor@ens-lyon.fr>, Samuel Dunesme <samuel.dunesme@ens-lyon.fr>"<br />
LABEL org.opencontainers.image.source="https://github.com/glourb/glourbapp"<br />
LABEL org.opencontainers.image.documentation="https://evs-gis.github.io/glourbdoc/"<br />
LABEL org.opencontainers.image.version="0.0.0.9000"<br />
LABEL org.opencontainers.image.description="An app for the GloUrb project"<br />
<br />
# On peut éventuellement générer des locales supplémentaires si notre appli utilise d'autres langues que l'anglais<br />
RUN locale-gen fr_FR.UTF-8<br />
<br />
# On liste maintenant toutes les dépendances R à installer<br />
RUN Rscript -e 'install.packages("tidyr")'<br />
RUN Rscript -e 'install.packages("shiny")'<br />
RUN Rscript -e 'install.packages("config")'<br />
RUN Rscript -e 'install.packages("testthat")'<br />
RUN Rscript -e 'install.packages("tibble")'<br />
RUN Rscript -e 'install.packages("purrr")'<br />
RUN Rscript -e 'install.packages("dplyr")'<br />
RUN Rscript -e 'install.packages("ggplot2")'<br />
RUN Rscript -e 'install.packages("forcats")'<br />
RUN Rscript -e 'install.packages("magrittr")'<br />
RUN Rscript -e 'install.packages("golem")'<br />
RUN Rscript -e 'install.packages("sf")'<br />
RUN Rscript -e 'install.packages("plotly")'<br />
RUN Rscript -e 'install.packages("spelling")'<br />
RUN Rscript -e 'install.packages("mclust")'<br />
RUN Rscript -e 'install.packages("leaflet")'<br />
RUN Rscript -e 'install.packages("cluster")'<br />
RUN Rscript -e 'install.packages("cowplot")'<br />
RUN Rscript -e 'install.packages("FactoMineR")'<br />
RUN Rscript -e 'install.packages("glue")'<br />
RUN Rscript -e 'install.packages("grDevices")'<br />
RUN Rscript -e 'install.packages("RColorBrewer")'<br />
RUN Rscript -e 'install.packages("remotes")'<br />
RUN Rscript -e 'install.packages("cicerone")'<br />
RUN Rscript -e 'install.packages("RPostgres")'<br />
RUN Rscript -e 'install.packages("DBI")'<br />
RUN Rscript -e 'install.packages("DT")'<br />
<br />
RUN Rscript -e 'remotes::install_github("glourb/glourbi")'<br />
<br />
# On copie l'arborescence de fichiers dans un dossier app à la racine de l'image. Ce sera le working directory des containers lancés avec notre image<br />
RUN mkdir /app<br />
ADD . /app<br />
WORKDIR /app<br />
<br />
# Si besoin, on peut installer notre package<br />
RUN R -e 'remotes::install_local()'<br />
<br />
# On détermine le port qui sera exposé (attention à bien fixer le port sur lequel votre appli écoute, cf. ci-dessus)<br />
EXPOSE 3838<br />
<br />
# Pour plus de sécurité, on fait en sorte que les containers ne se lancent pas avec l'utilisateur "root", mais avec un utilisateur "app" dédié<br />
RUN groupadd -g 1010 app && useradd -c 'app' -u 1010 -g 1010 -m -d /home/app -s /sbin/nologin app<br />
USER app<br />
<br />
# Enfin, on précise la commande qui permet de lancer notre appli. C'est cette commande qui sera lancée par défaut par tout nouveau container lancé avec notre image<br />
CMD ["R", "-f", "app.R"]<br />
</syntaxhighlight><br />
<br />
=== Construire l'image Docker ===<br />
Pour construire l'image docker à l'aide du Dockerfile, il faut lancer la commande docker build. Il est important de taguer l'image avec l'option -t.<br />
<br />
<code>docker build ./Dockerfile -t ghcr.io/evs-gis/mapdoapp:latest -t ghcr.io/evs-gis/mapdoapp:2.0.1 -t ghcr.io/evs-gis/mapdoapp:$(git rev-parse --short HEAD)</code><br />
<br />
=== Pousser l'image sur un registre ===<br />
<br />
== Configuration sur l'instance de dev ==<br />
Forcer le redémarrage de tous les containers de votre appli (utile uniquement dans le cas où vous avez paramétré un nombre minimum de sièges supérieur à 0)<br />
<br />
<code>docker container restart $(docker ps -q -f ancestor="ghcr.io/evs-gis/mapdoapp:latest")</code><br />
<br />
== Configuration sur l'instance de prod ==<br />
<br />
== Mise à jour d'une appli ==<br />
[[Catégorie:Tutoriel]]</div>Sdunesmehttps://isig-wiki.ens-lyon.fr/index.php?title=ShinyProxy&diff=1051ShinyProxy2025-02-12T21:04:11Z<p>Sdunesme : /* Conteneurisation de votre appli Shiny */</p>
<hr />
<div>'''<big>Attention : Page en cours de rédaction</big>'''<br />
<br />
ISIG-Apps passe sous ShinyProxy pour améliorer la stabilité et l'isolation de vos applications pendant les montées en charge. Le fonctionnement est très différent par rapport à l'ancien Shiny-Server et nécessite quelques bases dans l'utilisation de Docker. L'objectif de cette page est de vous guider, rapidement et simplement, dans le nouveau workflow dev > prod en partant du principe que vous ne connaissez encore pas grand-chose à Docker.<br />
<br />
== Principe de fonctionnement de ShinyProxy ==<br />
ShinyProxy fonctionne comme un orchestrateur de conteneurs Docker. Chaque appli configurée doit avoir une image Docker associée présente sur le serveur qui exécute ShinyProxy. C'est ShinyProxy qui s'occupera ensuite de lancer et stopper un conteneur à chaque fois qu'un internaute se connectera ou se déconnectera de votre appli. <br />
<br />
== Conteneurisation de votre appli Shiny ==<br />
https://rocker-project.org/images/<br />
<br />
L'image r2u est une bonne base assez simple à utiliser, car elle va chercher des binaires précompilés des packages R que l'on souhaite installer et toutes leurs dépendances, librairies système incluses ! Pratiquement rien n'y est pré-installé, il faudra donc bien préciser toutes les dépendances dont vous avez besoin. En contrepartie, l'image sera plutôt légère, ce qui est une bonne chose ! <br />
<br />
Voici un exemple de Dockerfile pour l'application GloUrb :<syntaxhighlight lang="dockerfile"><br />
# On commence par définir l'image sur laquelle va se baser la notre<br />
FROM rocker/r2u:jammy<br />
<br />
# On précise quelques infos qui permettrons d'identifier l'image<br />
LABEL org.opencontainers.image.authors="Lise Vaudor <lise.vaudor@ens-lyon.fr>, Samuel Dunesme <samuel.dunesme@ens-lyon.fr>"<br />
LABEL org.opencontainers.image.source="https://github.com/glourb/glourbapp"<br />
LABEL org.opencontainers.image.documentation="https://evs-gis.github.io/glourbdoc/"<br />
LABEL org.opencontainers.image.version="0.0.0.9000"<br />
LABEL org.opencontainers.image.description="An app for the GloUrb project"<br />
<br />
# On peut éventuellement générer des locales supplémentaires si notre appli utilise d'autres langues que l'anglais<br />
RUN locale-gen fr_FR.UTF-8<br />
<br />
# On liste maintenant toutes les dépendances R à installer<br />
RUN Rscript -e 'install.packages("tidyr")'<br />
RUN Rscript -e 'install.packages("shiny")'<br />
RUN Rscript -e 'install.packages("config")'<br />
RUN Rscript -e 'install.packages("testthat")'<br />
RUN Rscript -e 'install.packages("tibble")'<br />
RUN Rscript -e 'install.packages("purrr")'<br />
RUN Rscript -e 'install.packages("dplyr")'<br />
RUN Rscript -e 'install.packages("ggplot2")'<br />
RUN Rscript -e 'install.packages("forcats")'<br />
RUN Rscript -e 'install.packages("magrittr")'<br />
RUN Rscript -e 'install.packages("golem")'<br />
RUN Rscript -e 'install.packages("sf")'<br />
RUN Rscript -e 'install.packages("plotly")'<br />
RUN Rscript -e 'install.packages("spelling")'<br />
RUN Rscript -e 'install.packages("mclust")'<br />
RUN Rscript -e 'install.packages("leaflet")'<br />
RUN Rscript -e 'install.packages("cluster")'<br />
RUN Rscript -e 'install.packages("cowplot")'<br />
RUN Rscript -e 'install.packages("FactoMineR")'<br />
RUN Rscript -e 'install.packages("glue")'<br />
RUN Rscript -e 'install.packages("grDevices")'<br />
RUN Rscript -e 'install.packages("RColorBrewer")'<br />
RUN Rscript -e 'install.packages("remotes")'<br />
RUN Rscript -e 'install.packages("cicerone")'<br />
RUN Rscript -e 'install.packages("RPostgres")'<br />
RUN Rscript -e 'install.packages("DBI")'<br />
RUN Rscript -e 'install.packages("DT")'<br />
<br />
RUN Rscript -e 'remotes::install_github("glourb/glourbi")'<br />
<br />
# On copie l'arborescence de fichiers dans un dossier app à la racine de l'image. Ce sera le working directory des containers lancés avec notre image<br />
RUN mkdir /app<br />
ADD . /app<br />
WORKDIR /app<br />
<br />
# Si besoin, on peut installer notre package<br />
RUN R -e 'remotes::install_local()'<br />
<br />
# On détermine le port qui sera exposé<br />
EXPOSE 3838<br />
<br />
# Pour plus de sécurité, on fait en sorte que les containers ne se lancent pas avec l'utilisateur "root", mais avec un utilisateur "app" dédié<br />
RUN groupadd -g 1010 app && useradd -c 'app' -u 1010 -g 1010 -m -d /home/app -s /sbin/nologin app<br />
USER app<br />
<br />
# Enfin, on précise la commande qui permet de lancer notre appli. C'est cette commande qui sera lancée par défaut par tout nouveau container lancé avec notre image<br />
CMD ["R", "-f", "app.R"]<br />
</syntaxhighlight>Pour construire l'image docker à l'aide du Dockerfile, il faut lancer la commande docker build. Il est important de taguer l'image avec l'option -t.<br />
<br />
<code>docker build ./Dockerfile -t ghcr.io/evs-gis/mapdoapp:latest -t ghcr.io/evs-gis/mapdoapp:2.0.1 -t ghcr.io/evs-gis/mapdoapp:$(git rev-parse --short HEAD)</code><br />
<br />
== Configuration sur l'instance de dev ==<br />
Forcer le redémarrage de tous les containers de votre appli (utile uniquement dans le cas où vous avez paramétré un nombre minimum de sièges supérieur à 0)<br />
<br />
<code>docker container restart $(docker ps -q -f ancestor="ghcr.io/evs-gis/mapdoapp:latest")</code><br />
<br />
== Configuration sur l'instance de prod ==<br />
<br />
== Mise à jour d'une appli ==<br />
[[Catégorie:Tutoriel]]</div>Sdunesmehttps://isig-wiki.ens-lyon.fr/index.php?title=ShinyProxy&diff=1050ShinyProxy2025-02-06T12:59:54Z<p>Sdunesme : /* Conteneurisation de votre appli Shiny */</p>
<hr />
<div>'''<big>Attention : Page en cours de rédaction</big>'''<br />
<br />
ISIG-Apps passe sous ShinyProxy pour améliorer la stabilité et l'isolation de vos applications pendant les montées en charge. Le fonctionnement est très différent par rapport à l'ancien Shiny-Server et nécessite quelques bases dans l'utilisation de Docker. L'objectif de cette page est de vous guider, rapidement et simplement, dans le nouveau workflow dev > prod en partant du principe que vous ne connaissez encore pas grand-chose à Docker.<br />
<br />
== Principe de fonctionnement de ShinyProxy ==<br />
ShinyProxy fonctionne comme un orchestrateur de conteneurs Docker. Chaque appli configurée doit avoir une image Docker associée présente sur le serveur qui exécute ShinyProxy. C'est ShinyProxy qui s'occupera ensuite de lancer et stopper un conteneur à chaque fois qu'un internaute se connectera ou se déconnectera de votre appli. <br />
<br />
== Conteneurisation de votre appli Shiny ==<br />
https://rocker-project.org/images/<br />
<br />
Pour construire l'image docker à l'aide du Dockerfile, il faut lancer la commande docker build. Il est important de taguer l'image avec l'option -t.<br />
<br />
<code>docker build ./Dockerfile -t ghcr.io/evs-gis/mapdoapp:latest -t ghcr.io/evs-gis/mapdoapp:2.0.1 -t ghcr.io/evs-gis/mapdoapp:$(git rev-parse --short HEAD)</code><br />
<br />
== Configuration sur l'instance de dev ==<br />
Forcer le redémarrage de tous les containers de votre appli (utile uniquement dans le cas où vous avez paramétré un nombre minimum de sièges supérieur à 0)<br />
<br />
<code>docker container restart $(docker ps -q -f ancestor="ghcr.io/evs-gis/mapdoapp:latest")</code><br />
<br />
== Configuration sur l'instance de prod ==<br />
<br />
== Mise à jour d'une appli ==<br />
[[Catégorie:Tutoriel]]</div>Sdunesmehttps://isig-wiki.ens-lyon.fr/index.php?title=ShinyProxy&diff=1049ShinyProxy2025-02-06T10:38:51Z<p>Sdunesme : /* Configuration sur l'instance de dev */</p>
<hr />
<div>'''<big>Attention : Page en cours de rédaction</big>'''<br />
<br />
ISIG-Apps passe sous ShinyProxy pour améliorer la stabilité et l'isolation de vos applications pendant les montées en charge. Le fonctionnement est très différent par rapport à l'ancien Shiny-Server et nécessite quelques bases dans l'utilisation de Docker. L'objectif de cette page est de vous guider, rapidement et simplement, dans le nouveau workflow dev > prod en partant du principe que vous ne connaissez encore pas grand-chose à Docker.<br />
<br />
== Principe de fonctionnement de ShinyProxy ==<br />
ShinyProxy fonctionne comme un orchestrateur de conteneurs Docker. Chaque appli configurée doit avoir une image Docker associée présente sur le serveur qui exécute ShinyProxy. C'est ShinyProxy qui s'occupera ensuite de lancer et stopper un conteneur à chaque fois qu'un internaute se connectera ou se déconnectera de votre appli. <br />
<br />
== Conteneurisation de votre appli Shiny ==<br />
Pour construire l'image docker à l'aide du Dockerfile, il faut lancer la commande docker build. Il est important de taguer l'image avec l'option -t.<br />
<br />
<code>docker build ./Dockerfile -t ghcr.io/evs-gis/mapdoapp:latest -t ghcr.io/evs-gis/mapdoapp:2.0.1 -t ghcr.io/evs-gis/mapdoapp:$(git rev-parse --short HEAD)</code><br />
<br />
== Configuration sur l'instance de dev ==<br />
Forcer le redémarrage de tous les containers de votre appli (utile uniquement dans le cas où vous avez paramétré un nombre minimum de sièges supérieur à 0)<br />
<br />
<code>docker container restart $(docker ps -q -f ancestor="ghcr.io/evs-gis/mapdoapp:latest")</code><br />
<br />
== Configuration sur l'instance de prod ==<br />
<br />
== Mise à jour d'une appli ==<br />
[[Catégorie:Tutoriel]]</div>Sdunesmehttps://isig-wiki.ens-lyon.fr/index.php?title=ShinyProxy&diff=1048ShinyProxy2025-02-05T15:13:36Z<p>Sdunesme : </p>
<hr />
<div>'''<big>Attention : Page en cours de rédaction</big>'''<br />
<br />
ISIG-Apps passe sous ShinyProxy pour améliorer la stabilité et l'isolation de vos applications pendant les montées en charge. Le fonctionnement est très différent par rapport à l'ancien Shiny-Server et nécessite quelques bases dans l'utilisation de Docker. L'objectif de cette page est de vous guider, rapidement et simplement, dans le nouveau workflow dev > prod en partant du principe que vous ne connaissez encore pas grand-chose à Docker.<br />
<br />
== Principe de fonctionnement de ShinyProxy ==<br />
ShinyProxy fonctionne comme un orchestrateur de conteneurs Docker. Chaque appli configurée doit avoir une image Docker associée présente sur le serveur qui exécute ShinyProxy. C'est ShinyProxy qui s'occupera ensuite de lancer et stopper un conteneur à chaque fois qu'un internaute se connectera ou se déconnectera de votre appli. <br />
<br />
== Conteneurisation de votre appli Shiny ==<br />
<br />
== Configuration sur l'instance de dev ==<br />
<br />
== Configuration sur l'instance de prod ==<br />
<br />
== Mise à jour d'une appli ==<br />
[[Catégorie:Tutoriel]]</div>Sdunesmehttps://isig-wiki.ens-lyon.fr/index.php?title=ShinyProxy&diff=1047ShinyProxy2025-02-05T15:13:01Z<p>Sdunesme : </p>
<hr />
<div>ISIG-Apps passe sous ShinyProxy pour améliorer la stabilité et l'isolation de vos applications pendant les montées en charge. Le fonctionnement est très différent par rapport à l'ancien Shiny-Server et nécessite quelques bases dans l'utilisation de Docker. L'objectif de cette page est de vous guider, rapidement et simplement, dans le nouveau workflow dev > prod en partant du principe que vous ne connaissez encore pas grand-chose à Docker.<br />
<br />
== Principe de fonctionnement de ShinyProxy ==<br />
ShinyProxy fonctionne comme un orchestrateur de conteneurs Docker. Chaque appli configurée doit avoir une image Docker associée présente sur le serveur qui exécute ShinyProxy. C'est ShinyProxy qui s'occupera ensuite de lancer et stopper un conteneur à chaque fois qu'un internaute se connectera ou se déconnectera de votre appli. <br />
<br />
== Conteneurisation de votre appli Shiny ==<br />
<br />
== Configuration sur l'instance de dev ==<br />
<br />
== Configuration sur l'instance de prod ==<br />
<br />
== Mise à jour d'une appli ==<br />
[[Catégorie:Tutoriel]]</div>Sdunesmehttps://isig-wiki.ens-lyon.fr/index.php?title=ShinyProxy&diff=1046ShinyProxy2025-02-05T15:08:59Z<p>Sdunesme : Page créée avec « ISIG-Apps passe sous ShinyProxy pour améliorer la stabilité et l'isolation de vos applications pendant les montées en charge. Le fonctionnement est très différent par rapport à l'ancien Shiny-Server et nécessite quelques bases dans l'utilisation de Docker. L'objectif de cette page est de vous guider dans le nouveau workflow dev > prod en partant du principe que vous ne connaissez encore rien à Docker. == Principe de fonctionnement de ShinyProxy == == Co... »</p>
<hr />
<div>ISIG-Apps passe sous ShinyProxy pour améliorer la stabilité et l'isolation de vos applications pendant les montées en charge. Le fonctionnement est très différent par rapport à l'ancien Shiny-Server et nécessite quelques bases dans l'utilisation de Docker. L'objectif de cette page est de vous guider dans le nouveau workflow dev > prod en partant du principe que vous ne connaissez encore rien à Docker.<br />
<br />
== Principe de fonctionnement de ShinyProxy ==<br />
<br />
== Conteneurisation de votre appli Shiny ==<br />
<br />
== Configuration sur l'instance de dev ==<br />
<br />
== Configuration sur l'instance de prod ==<br />
<br />
== Mise à jour d'une appli ==</div>Sdunesmehttps://isig-wiki.ens-lyon.fr/index.php?title=Fichier:Elvis_notext.png&diff=1036Fichier:Elvis notext.png2025-01-30T14:28:23Z<p>Sdunesme : </p>
<hr />
<div></div>Sdunesmehttps://isig-wiki.ens-lyon.fr/index.php?title=Fichier:FactoViz.png&diff=1034Fichier:FactoViz.png2025-01-17T15:54:49Z<p>Sdunesme : </p>
<hr />
<div></div>Sdunesme