Utilisateurs autorisés, Bureaucrates, Ingénieurs ISIG, Administrateurs d’interface, Utilisateurs autorisés automatiquement, Administrateurs
354
modifications
« ShinyProxy » : différence entre les versions
Aller à la navigation
Aller à la recherche
→Choisir l'image source
Aucun résumé des modifications |
|||
| Ligne 31 : | Ligne 31 : | ||
=== Choisir l'image source === | === Choisir l'image source === | ||
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. | |||
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 ! | 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. | ||
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). | |||
=== Écrire le Dockerfile === | === Écrire le Dockerfile === | ||
La création d'une image Docker repose sur l'écriture d'un fichier texte appelé '''Dockerfile''' (sans extension). | |||
Voici un exemple de Dockerfile pour l'application GloUrb :<syntaxhighlight lang="dockerfile"> | Voici un exemple de Dockerfile pour l'application GloUrb :<syntaxhighlight lang="dockerfile"> | ||
| Ligne 103 : | Ligne 106 : | ||
=== Construire l'image Docker === | === Construire l'image Docker === | ||
Pour construire l'image docker à l'aide du Dockerfile, il faut lancer la commande docker build. | 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. | ||
Pour que la CLI Docker trouve bien le Dockerfile, on lance le terminal dans le dossier ou ce Dockerfile est enregistré. | |||
<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> | |||
<code> | 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. | ||
=== Pousser l'image sur un registre === | === Pousser l'image sur un registre === | ||