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

• Rédaction d'une documentation docker : 1h

 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 : 3h

 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é) : 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)

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

Déploiement complet sur Openshift

• Pair programming avec Louis afin de débloquer le back (Bug critique des data-sources avec Mysql) : 7h

 ==> 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é) : 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.

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

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)

• Création d'un serveur d'intégration continue Jeckins sur Openshift (échec) : 20h

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é) : 3h

• Embarquement du front basé sur angular avec le serveur : 5h

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é) : 13h

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 : 2h

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

• Apprentissage et installation de la techno Jmeter et nombreux tests : 6h

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

• Configuration du HAproxy et des serveurs wildfly afin d'utiliser plusieurs base de données Mysql : 2h

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) : 18h

Mode Master/Master, puis Mode cluster, puis de nouveau Mode Master/Master, puis et encore Mode cluster Problème de configuration

• Mise au propre du journal : 3h

• Préparation soutenance

Temps total : environ 160h