\newpage Introduction ============ Notre application du jour ------------------------- Aujourd'hui, nous allons travailler avec un mineur de pépites ... de chocolat ! Alors, on se fait un bon thé, on prend sa boîte de gâteaux pour tenir le coup, et c'est parti ! ![ChocoMiner](dockercoins-diagram.svg) Fier de respecter le paradigme des micro-services, notre ChocoMiner fonctionne ainsi : * le `worker` demande à `rng` de générer un grand nombre aléatoire, * le `worker` envoie ce grand nombre au `hasher`, qui lui retourne un hash, * si le condensat respecte les contraintes pour obtenir une pépite, on est content, * et on recommence, ainsi de suite, pour avoir le maximum de pépites. Chaque seconde, le `worker` envoie à `influxdb` le nombre de hashs et de pépites qu'il a ainsi pu obtenir. Une interface graphique (`chronograf`) permet d'interroger la base de données pour afficher des statistiques. Obtenir l'application ---------------------
```shell git clone https://gitea.nemunai.re/srs/chocominer.git ```
Rappels sur la découverte de services ------------------------------------- Dans Docker, nous avions vu que nous n'avions pas besoin de connaître les IP des conteneurs : un serveur DNS nous permettait de se connecter aux différents services à partir de leurs noms. Dans Kubernetes, le même principe s'applique : dans aucun cas, nous ne devrions coder en dur des adresses IP. Il convient d'utiliser au maximum le système de DNS, car les IP sont susceptibles de changer ! Tester avec `docker-compose` ---------------------------- ```bash docker-compose up ``` Une fois le docker-compose lancé, nous devrions pouvoir accéder à l'interface de chronograf pour voir l'avancement de recherche de pépites : Montée en puissance ------------------- ```bash docker-compose up -d --scale worker=2 ``` On remarque que le nombre de hash calculés augmente ! Génial ! ```bash docker-compose up -d --scale worker=10 ``` Mais ça atteint un palier au bout d'un moment ... Identification du goulot d'étranglement --------------------------------------- De nombreux outils existent pour réaliser des tests de performance, essayons `httping` sur nos différents services pour voir si un service ne serait pas la cause des ralentissements : - Testons `rng` : `httping -c 3 localhost:8001`, - puis testons `hasher` : `httping -c 3 localhost:8002`. Il semblerait que notre application `rng` nécessite d'être exécutée en parallèle ! Mais on ne peut pas faire de répartition de charge facilement avec `docker-compose` !