ECOM RICM5 Groupe2 2017 Journal L9 Journal DELISE

<<<< Retour

Journal de Bord DELISE Antoine Analyse du sujet : 10h

Travail de conception : 10h

Apprentissage de l'outil docker : 5h

Rédaction d'une documentation docker : 45m Afin de permettre à l'équipe un démarrage rapide.

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

Découverte de l'outil Jenkins, apprentissage des bases : 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 la platforme openshift et premier déploiement (terminé) : 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)

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

Pair programming avec Louis afin de débloquer le back (Bug critique des data-sources avec Mysql) : ==> 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

Tentative des 1001 manières de faire de l'auto build sous l’architecture openshift (Non terminé) :

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).

Découverte et apprentissage du système de déploiement sur Openshift directement à base d'image docker (Terminé) :

Création d'un serveur d'intégration continue Jeckins sur Openshift (échec) : 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)

Mise à jour des Jenkins locaux afin de construire et déployer automatiquement sur Openshift (Terminé) : 10/10/12

Embarquement du front basé sur angular avec le serveur : 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)

Tentative de monitoring, réplication etc sur openshift (mitigé) : 6h 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.

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

Apprentissage et installation de la techno HAproxy : 3h 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 ec2 auto-déploiment : 1h 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)

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

Apprentissage et installation des techno telegraf influxdb grafana : 5h + 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

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

Configuration du HAproxy et des serveurs wildfly afin d'utiliser plusieurs base de données Mysql : 1h30 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 !...

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