virli/tutorial/docker-basis/ex-flask.md

128 lines
3.4 KiB
Markdown
Raw Normal View History

2018-10-03 08:56:33 +00:00
\newpage
Mon premier webservice
======================
C'est parti, nous allons déployer notre premier service !
Il s'agit d'un service montrant une image aléatoire à chaque chargement de
page : <https://you.p0m.fr/>.
Nous pouvons télécharger et lancer le service grâce à :
<div lang="en-US">
```bash
docker container run -i nemunaire/youp0m
2018-10-03 08:56:33 +00:00
```
</div>
Cette fois-ci, ce n'est pas un shell que nous obtenons[^defaultcmd] : il semblerait que le
service soit lancé et écoute sur le port 8080. Est-ce le cas ?
<http://localhost:8080>
[^defaultcmd]: Chaque conteneur dispose d'une commande par défaut : les images
de base telles que les distributions vont lancer un shell, tandis que les
conteneurs de service vont lancer leur service directement.
Non ! Car le service est contenerisé ! Il s'exécute dans son coin, sans
interférer avec son hôte.
## Redirection de ports
Nous pouvons rediriger le port avec l'argument <span lang="en-US">`-p dst_host:src_cntr`</span> :
<div lang="en-US">
```bash
docker container run -i -p 8080:8080 nemunaire/youp0m
2018-10-03 08:56:33 +00:00
```
</div>
Cette fois, nous pouvons accéder au service.
Pour le moment, le service ne dispose d'aucune image à afficher, vous pouvez
utiliser cette syntaxe pour ajouter une image :
<div lang="en-US">
```bash
base64 monimage.jpg | curl --data @- http://localhost:8080/api/images/monimage
2018-10-03 08:56:33 +00:00
```
</div>
Si vous n'êtes pas particulièrement inspiré, vous pouvez ajouter ces images :
<div lang="en-US">
```bash
2019-10-01 09:03:15 +00:00
for IMG in lynx4 otters DNcrZ6u raccoons; do
wget -O- https://you.p0m.fr/images/$IMG | base64 | \
curl --data @- http://localhost:8080/api/images/$IMG
done
2018-10-03 08:56:33 +00:00
```
</div>
## Prêt pour la production ?
Avec l'option `-i`, nous pouvons encore transmettre les signaux de terminaison
au conteneur. C'est pratique lorsque l'on développe, mais en production, notre
service ne s'exécutera pas dans notre terminal !
On utilise l'option `-d` pour lancer le conteneur en tâche de fond :
<div lang="en-US">
```bash
docker container run -d -p 8080:8080 nemunaire/youp0m
2018-10-03 08:56:33 +00:00
```
</div>
À partir de l'identifiant renvoyé par cette commande (que l'on peut également
obtenir avec un `docker container ls`), nous pouvons consulter les logs du
service (en fait, les sorties standard et d'erreur) :
<div lang="en-US">
```bash
docker container logs 0123456789abcdef
2018-10-03 08:56:33 +00:00
```
</div>
## Une autre instance ?
Maintenant que nous avons un clone de <https://you.p0m.fr/>, nous voulons
absolument un clone de <https://food.p0m.fr/> !
Il s'agit du même service, mais ce n'est pas les mêmes images.
On ne peut pas utiliser le même port sur la machine hôte, mais pour le reste,
2019-10-01 09:03:15 +00:00
il s'agit des mêmes options\ :
2018-10-03 08:56:33 +00:00
<div lang="en-US">
```bash
docker container run -d -p 8080:8081 nemunaire/youp0m
2018-10-03 08:56:33 +00:00
```
</div>
Voyons le résultat : <http://localhost:8081>
Nous avons réussi à lancer deux conteneurs à partir de la même image, et on
2019-10-01 09:03:15 +00:00
voit bien que ceux-ci ne partagent pas leur système de fichiers : notre
nouvelle instance est encore immaculée.
2018-10-03 08:56:33 +00:00
## Arrêt des conteneurs et persistance des données
Lorsque l'on souhaite stopper un conteneur lancé en tâche de fond, on utilise
son identifiant dans la commande suivante :
<div lang="en-US">
```bash
docker container stop 0123456789abcdef
2018-10-03 08:56:33 +00:00
```
</div>
Maintenant, si l'on relance un conteneur `youp0m`, il aura perdu toutes les
magnifiques images que l'on aura ajouté. Nous allons voir dans la partie
suivante comment rendre les données persistantes entre deux lancements.