ECOM RICM5 Groupe2 2017 Journal L9 Journal DELISE

<<<< Retour

Journal de Bord DELISE Antoine

Démarrage du projet

 * Analyse du sujet : 10h


 * Travail de conception : 10h


 * Apprentissage de l'outil docker : 5h

Afin de permettre à l'équipe un démarrage rapide.
 * Rédaction d'une documentation docker : 1h


 * Mise à jour des script docker pour le build sur docker : 15m

Création d'un premier projet Jenkins en local afin de build et déployer le projet sur docker Beaucoup de difficulté à configurer Jenckins
 * Découverte de l'outil Jenkins, apprentissage des bases : 3h

Apprentissage du build and deploy automatique de openshift à l'aide de fichier de configuration et d'une modification du pom de maven (Container wilfly pré-configuré ne nécessite que d'auto-build le server JAVAEE à l'aide des fichiers de config et de correctement le formater)
 * Découverte de la platforme openshift et premier déploiement (terminé) : 3h


 * Petite amélioration du script curl afin de tester le serveur (notamment avec Jenkins) : 1h

Déploiement complet sur Openshift
==> La solution mis en place invalide la méthode de déploiement précédente Nécessite une utilisation avancé de docker hors Openshift donne directement un container Wildfly sans accès au Dockerfile ou ni aucun accès au cluster (compte gratuit) : tâche suivante pour la compréhension et tentative de contournement
 * Pair programming avec Louis afin de débloquer le back (Bug critique des data-sources avec Mysql) : 7h


 * Tentative des 1001 manières de faire de l'auto build sous l’architecture openshift (Non terminé) : 16h (inclus les pertes de temps suivantes)

cette tâche fut paralysé pendant encore un moment puisque pendant celle-ci j'ai découvert que depuis quelques jours un bug sur les serveurs openshift rendaient impossible la création de nouveaux conteneur ce qui expliquaient mes difficultés particulières récentes (j'ai tout de même perdu nombre d'heures avant de le découvrir car peu de communication de leur part plus le temps de comprendre que c'est un problème incontournable).

Entre temps j'ai tenté une migration sur aws (car la panne à duré 2 semaine au total et aucun moyen de savoir quand ils seront de nouveau viable) mais j'ai abandonné en recevant la facture de 17$ ce qui a coïncidé avec la notification du retour en état des serveurs openshift.

Openshift utilise des système propriétaire, la seule solution que j'ai trouvé pour envoyer des images docker sur le cluster est de supprimer l'application et de la re-créer Heureusement cette tâche est pas extrêmement longue et automatisé dans les script et Jenckins locaux. (J'ai tout de même chercher longtemps comment mettre à jour des images d'un registre cloné par openshift mais impossible de s'authentifier au registry openshift, nécessite d'exécuter des commande non autorisé sur les offres gratuites)
 * Découverte et apprentissage du système de déploiement sur Openshift directement à base d'image docker (Terminé) : 6h

Jusqu'à présent (et à l'avenir) Jenckins était en local sur chaque machine des devs et n'était plus capable de déployer suite au passage en mode image docker Après de très nombreuses tentative pour configurer Jenkins ainsi que ces outils intégrés (Docker et maven qui n'étaient pas embarqué) j'ai fini par arriver à l’évidence que les conteneur openshift ne sont pas assez puissant pour construire en entier un projet JAVAEE puis une image docker (principalement à cause de l'espace disque, vers la fin du projet l'image docker pesait à elle seule un peu plus de 1Go soit plus que l'espace alloué à un conteneur openshift devant contenir Jenkins et ses outils)
 * Création d'un serveur d'intégration continue Jeckins sur Openshift (échec) : 20h


 * Mise à jour des Jenkins locaux afin de construire et déployer automatiquement sur Openshift (Terminé) : 3h

Le front étant parti sur une autre technologie que celle du projet initial, le front et le back ne sont plus déployé ensemble (et posent donc accessoirement des problèmes de CROSS-ORIGIN)
 * Embarquement du front basé sur angular avec le serveur : 5h

Openshift est un service proposant trop de fonctionnalité pour tout ce qui est demandé, la réplication le monitoring la reprise de panne la montée en charge ...... sont toutes complètement gratuite est préintégré ce qui posait le problème de pas les faire nous-même. D'où les quelques heures à tenter de contourner le système qui a aboutit à un abandon, le système (en gratuit) est trop verrouillé pour faire une quelconque de ces technologies à la main (puisque tout marche déjà parfaitement et permet toutes les options voulues) Suite à un discutions il a été décidé de recommencer le déploiement sur aws afin de pouvoir faire nous-même les techno demandés.
 * Tentative de monitoring, réplication etc sur openshift (mitigé) : 13h

Migration technologique sur aws
Puisque toute ces modifications sont 100% indépendantes du reste du projet elle ne sont pas présente sur github afin de permettre à l'équipe de continuer de travailler sur le serveur openshift pendant que je travaillais sur les serveurs aws, la migration totale c'est effectué en plusieurs temps et à terminé le 18/12 avec l'abandon du server openshift.


 * Déploiement sur vm EC2 sur aws : 4h

Installation sur une vm particulière, réplication du serveur et load balancing entre les deux serveurs Activation des statistiques(sécurisées) sur le haproxy
 * Apprentissage et installation de la techno HAproxy : 3h

Script de configuration automatique de la vm lors de son lancement, passage du serveur en Auto-Scaling group avec script, redimensionnement des réplicats simplifié (2 cliques)
 * Apprentissage ec2 auto-déploiment : 2h

Le HA ajoute les nouveaux serveurs crées et retire les serveurs morts automatiquement dans ses routes load balancés.
 * Auto-détection des serveurs répliqué par le HA : 2h

+ Auto-connexion des telegraf à l'influxdb centrale Chaque serveur répliqués possède un telegraf qui pousse ses données sur la base de donnée du serveur distribué localisé sur la machine Service
 * Apprentissage et installation des techno telegraf influxdb grafana : 5h


 * Remise en état du swagger disparu depuis le merge avec le front (qui avait pris sa place) : 1h30

Problèmes lors des tests, jmeter à du mal à surcharger les serveurs, et à tendance à se surcharger lui-même (notamment la ram) entrainant des fausses erreurs
 * Apprentissage et installation de la techno Jmeter et nombreux tests : 6h

Les requêtes sont bien load balancé entre les différentes base de données (testé et approuvé, en utilisant des données différentes sur les base on voit la variation de résultats). Il reste plus qu'a synchroniser des base de données !...
 * Configuration du HAproxy et des serveurs wildfly afin d'utiliser plusieurs base de données Mysql : 2h

Mode Master/Master, puis Mode cluster, puis de nouveau Mode Master/Master, puis et encore Mode cluster Problème de configuration
 * Réplication base de données (échec) : 18h

Extinction automatique d'une vm qui ne répond plus depuis trop longtemps, le groupe d'AutoScaling se charge de relancer des serveurs pour combler la place
 * Détection des fautes et reprise de faute complète : 1h


 * Mise au propre du journal : 3h


 * Préparation soutenance

Temps total : environ 160h