Une app Docker Compose
Docker fournit un repository Github
avec plusieurs applications pour tester Docker.
Nous allons utiliser l’application dockercoins pour essayer Docker Compose.
J’ai préparé l’application dans le repo du TP.
Vous pouvez récupérer le repo sur la machine en clonant le repo git du TP.
$ git clone https://github.com/zaggash/tp-iut-docker.git
$ cd tp-iut-docker/
$ cd dockercoins/
On ne va pas rentrer dans trop de details concernant la syntaxe d’un docker-compose.yaml
.
Cela prendrait beaucoup de temps et la documentation de Docker
est un bien meilleur référentiel avec un tas d’exemples et d’explications.
Lancer l’application
Docker compose est très pratique en mode developpement.
Cela permet de lancer une stack applicative complète à partir des fichiers présents sur notre machine.
On lance l’application avec docker-compose
$ docker-compose up
Compose demande à Docker de construire l’application en créant des images, puis de lancer les conteneurs et enfin afficher les logs.
L’application est composé de 5 services:
* rng
= un service web qui génére des bits aléatoires
* hasher
= un service web qui hash les bits reçu
* worker
= Un processus qui qui fait appel a rng
et haser
* webui
= Une interface web
* redis
= La base de donnée
worker
fait appel à rng
avec un GET pour générer un byte aléatoire, puis il le renvoie avec un POST à hasher
.
Indéfiniment…worker
met à jour redis
a chaque boucle.webui
permet d’afficher les resultats.
Aucune adresse IP n’est spécifiée, que ce soit dans le code ou dans le docker-compose.yaml
.
Les applications utilisent le nom des services respectifs pour atteindre les conteneurs.
Vous pouvez voir dans worker/worker.py
redis = Redis("redis")
def get_random_bytes():
r = requests.get("http://rng/32")
return r.content
def hash_bytes(data):
r = requests.post("http://hasher/",
data=data,
headers={"Content-Type": "application/octet-stream"})
Chercher avec les commandes docker ou dans le fichier compose, le port sur lequel est exposé webui
On peut maintenant arrêter l’application avec un ctrl+c
Docker va stopper les conteneur avec un TERM puis un KILL si necessaire.
On peut forcer le KILL avec un deuxième ctrl+c
.
En arrière plan
On peut relancer l’application en arrière plan
$ docker-compose up -d
// Puis
$ docker-compose ps
$ docker-compose logs --tail 10 --follow
Scaling UP
Notre but va être d’accélérer l’application sans toucher au code. Mais avant on va chercher si il y a un bottleneck ( Pas assez de RAM, de CPU, IO ?)
Essayer de trouver par vous même, sinon rdv à la suite.
Pour le CPU et la RAM on va lancer top
, puis chercher les cycles idle et la RAM Free.vmstat 1 10
va nous donner un extrait sur 10s pour voir les IO disque.
Y a t-il assez de ressource ?
2 workers
Ajouter un nouveau worker
à l’application
$ docker-compose up -d --scale worker=2
Puis ouvrir de nouveau le navigateur sur l’interface Web.
Y a t-il un impact sur les ressources ?
10 workers alors !
On va donc augmenter les workers jusque 10 et l’application ira 10x plus vite.
$ docker-compose up -d --scale worker=10
Est ce bien le cas ?
Vérifions les ressources CPU, RAM, IO une nouvelle fois. Puis la latence des deux backend web.
$ top
$ vmstat 1 10
// Latence rng, exposé sur le port 8001
$ httping -fc 10 127.0.0.1:8001
// Latence hasher, sur le port 8002
$ httping -fc 10 127.0.0.1:8002
Quel service pose problème ? Comment peut on résoudre le problème ?
Stopper l’application
Avant de passer à autre chose, je suis disponible pour faire un point sur l’avancement et les questions que vous pourriez avoir. Des problèmes ?
On peut maintenant arrêter l’application
$ docker-compose down