Différences

Ci-dessous, les différences entre deux révisions de la page.

--- sio:stage2:rapport_hebdo [11/02/2016 09:55]
charly [Lundi 4 Janvier]
+++ sio:stage2:rapport_hebdo [18/09/2016 02:54]
@@ Ligne 1: / Ligne 1: @@
-====== Rapport hebdomadaire ======
-===== Semaine 1 =====
-==== Lundi 4 Janvier ====
-Arrivé dans les locaux. \\
-Mise en place du poste de travail et réception d'un matricule permettant l'identification. Contacter l'assistance pour obtenir un mot de passe temporaire à changer dès la connexion. \\
-Réception d'un badge permettant l'accès au bâtiments. \\
-Découverte et analyse du Système d'information.
-==== Mardi 5 Janvier ====
-Réunion avec l'ensemble du service. \\
-Travail sur la présentation Docker/Owncloud.
-==== Mercredi 6 Janvier ====
-Élaboration d’un document technique qui recense les ressources nécessaire au maquettage des solutions
-(CF: [[sio:stage2:ressources|]]) \\
-Réunion de cadrage du projet, point sur les spécificités techniques.
-==== Jeudi 7 Janvier ====
-Amélioration de la présentation, ajout de correctif suite à la réunion. \\
-Installation des VMs sous SUSE 12
-==== Vendredi 8 Janvier ====
-Complément de la présentation, création de docs supplémentaire pour l’installation de SUSE \\
-Déploiement des 2 machines ainsi que l’installation et la configuration de SUSE, installation de docker ainsi que les premiers tests.
-----
-===== Semaine 2 =====
-==== Lundi 11 Janvier ====
-Documentation d’installation de docker + configuration. \\
-Recherche d’une solution au problème de réseau de la VM slesdockerdev1 -> Problème résolu ! Mauvaise configuration des identifiants du proxy : il faut préciser le domaine dans le login sinon l’authentification ne fonctionne pas. (>1h de travail) problème pas totalement résolus quelques coupures (à 11h) affaire à suivre...
-==== Mardi 12 Janvier ====
-On fait un snapshot de la VM (slesdockerdev2) dans son état actuel, et on fait une fresh install Debian 8.2 pour tester si cela est plus stable que SLES 12. \\
-[Après-midi] Actuellement Debian parait beaucoup plus stable, aucune déconnexion ou latence recensé pour le moment, c’est bon signe ! \\
-Nous avons donc créer une image custom de Debian 8.2 sur docker avec un Dockerfile pour pouvoir y renseigner le proxy dans la config d’apt. Nous utiliserons cette image pour tout les autres conteneurs. \\
-Image PHP créer + apache2 en cours
-==== Mercredi 13 Janvier ====
-Communication entre les conteneurs Apache et PHP => Après pas mal de configuration c'est maintenant fonctionnel \\
-Le conteneur Postgres fonctionne aussi mais il nous reste un problème de rewrite pour ownCloud \\
-Eric a chercher a comprendre pour le bug de la SLES : remplacement de Wicked par network manager \\
-==== Jeudi 14 Janvier ====
-Rebuild image Apache2 -> des dossier qui traine à cause du problème de volume. Corrigé ! \\
-Rebuild image Postgres et test avec le entrypoint \\
-Bug rewrite ownCloud
-==== Vendredi 15 Janvier ====
-Fix du bug ownCloud => PHP mal config, ''cgi.fix_pathinfo=0'' -> ''cgi.fix_pathinfo=1'' \\
-Début de la customisation du ownCloud
-----
-===== Semaine 3 =====
-==== Lundi 18 Janvier ====
-Documentation sur le [[sio:stage2:oc_theme|thème ownCloud]] \\
-On a commenter les Dockerfile : faut les mettre sur le wiki maintenant \\
-Test VM SLES \\
-Commencer à regarder pour CloudUnit suite au mail de Yann : conteneur Tomcat ; CloudUnit utilise java.
-==== Mardi 19 Janvier ====
-Tout faire fonctionner sous SLES ! => OK \\
-Ajout des docs sur le wiki \\
-Volume -> Conteneur de données??
-  * Synchro fichiers??
-  * => TODO
-==== Mercredi 20 Janvier ====
-Des problèmes pour la configuration du cluster Postgres. \\
-Commencer les recherches pour synchroniser les fichiers entre les deux hôtes.
-==== Jeudi 21 Janvier ====
-Docker (SLES & debian)
-  * Conteneur full -> OK
-  * Conteneur brick -> OK
-Cluster
-  * Un disque pour les deux machines
-  * Synchro de données
-    * Peut-être utiliser rsync (surement même) → rsync unidir ⇒ poubelle mais alternatives bidir :
-    * unison (https://www.cis.upenn.edu/~bcpierce/unison/)
-    * Syncthing (https://syncthing.net/)
-    * Sync (BitTorrent) (https://www.getsync.com/)
-  * Autre?
-Problème pour gérer les ressources partager (accès disque) \\
-Les permissions sont synchronisées correctement MAIS pas le propriétaire et le groupe -> pas utilisable.
-==== Vendredi 22 Janvier ====
-Mise à jour de la doc maquettage \\
-Solution de montage NFS pour les data. Problème de propriétaire/groupe
-----
-===== Semaine 4 =====
-==== lundi 25 Janvier ====
-Trouver le moyens de changer les permissions ainsi que propriétaire/groupe sur le partage NFS sans passer par le serveur mais en passant par les clients
-Mise en place d’un gestionnaire de conteneurs/images/repositories docker : Shipyard
-  * Il utilise docker Swarm pour gérer le(s) nœud(s) du cluster
-  * Il utilise docker top pour récupérer les infos sur les conteneurs et ainsi créer des graphes
-  * Il est capable de lancer démarrer/arrêter/détruire/créer un conteneur ainsi que de push/delete une image
-Mise en place d'un registry privé : déploiement d'un conteneur fourni par Docker
-==== Mardi 26 Janvier ====
-Montage NFS fonctionnelle + modification permissions/propriétaire/groupe \\
-Cluster Postgresql master-master ne fonctionne pas
-==== Mercredi 27 Janvier ====
-Sur le wiki créer une page docker avec fichier de config commenter + bash de lancement de conteneur \\
-Expliquer dans les grandes lignes les commandes. Doc qui sera porter dans l’espace co. \\
-Fixe le problème avec postgres -> mode master-slave
-Sur le mode full, le partage de doc fonctionne entre les deux instances + il accepte les modifs que d’un coter donc pas de conflit good ; sur le mode brick, juste un cluster postgres devrait suffire
-==== Jeudi 28 Janvier ====
-Recherche sur le cluster postgres
-==== Vendredi 29 Janvier ====
-Continuer la présentation -> rajouter des diapo pour le cluster docker (avec Swarm) + l’interface de gestion Shipyard \\
-Cluster postgres, again
-----
-===== Semaine 5 =====
-==== Lundi 1 Février ====
-Termine le cluster postgres
-Mise à jour du script de gestion de notre mode brick
-Mise à jour du registry dans les scripts de démarrage des conteneurs
-  sed -i 's,localhost,registry.cg44.fr,g' $(find ./ -name *.sh)
-Visite de stage… done
-==== Mardi 2 Février ====
-Réunion de début de mois avec les employées du service. \\
-Correction des différents documents produit sur le wiki.
-==== Mercredi 3 février ====
-Vérification avant la restitution orale :
-  * ☑ Owncloud Full
-  * ☐ Owncloud Birck
-    * ☑ Apache
-    * ☑ Php
-    * ☐ Postgres
-  * ☑ Shipyard
-Vérifier le diapo au plus tôt
-  * ☑ Vérifier orthographe
-  * ☑ Ajouter des diapo pour shipyard / registry
-Bug fix de docker sur SLES : impossible de start docker à cause de l’initialisation du network -> Supprimer ''/var/lib/docker/network'' pour fixer le problème
-==== Jeudi 4 février ====
-Gestions des incidents :
-  * Logiciels de ticketing : Isilog
-{{ :sio:stage2:isilog.jpg?500 |}}
-Prise en main à distance :
-  * Poste Sirius (Seven) : Novel ZENworks
-  * Poste Comet (XP) : Novel ConsoleOne
-{{ :sio:stage2:novell.jpg?500 |}}
-Arriver des premiers techniciens à 8h00 vérifier l’état des infra/serveurs/réseau \\
-Création d’un rapport météo de la journée précédente (doc en mail) \\
-Ouverture du service à 8h30 pour les utilisateurs
-{{ :sio:stage2:weather.jpg?500 |}}
-{{ :sio:stage2:weather2.jpg |}}
-N1 :
-  * Le point d’entré du centre d’appel
-  * Réponse aux incidents
-  * Réponse aux demandes de services
-N2 :
-  * Incidents non gérer en N1 ou lorsque que la demande est trop forte
-==== Vendredi 5 février ====
-Réunion avec le chef du service. \\
-Stade actuel d'ITIL au seins du service d’assistance numérique :
-  * OK : Incidents
-  * OK : Requêtes -> DDS (Demande de Service) / Dossier
-  * ~~ : Problèmes -> Réactive (Récurrent / Majeur) / pro-active (Anticipation)
-  * OK : Changements (poste user)
-  * KO : Mise en prod (lier changements, opérationnel)
-  * ~~ : Gestion configuration
-  * OK : Catalogue des services (exposer services/permettre requêtes)
-               Proxy
-  N1 ----> N2 ----> N3
-Incident = rupture \\
-Problème = incident récurent qui pourrais être résolu par le biais d'un projet
-But : rétablir le plus vite possible, de façon nominal le service ; satisfaction utilisateur
-Dimensionnement du N1 en fonction du nombre de personne susceptible d'appeler
-N1
-  * Durée/appel : 5-10min
-  * Procédurale
-  * Coût : ~5€
-N2
-  * Durée/appel : 10min-1h
-  * Résolution / diagnostic qui demande plus de temps
-  * Coût : ~50€
-N3
-  * Durée/appel : >1h
-  * Coût : ~500€
-Coût : ~1M€/an
-----
-===== Semaine 6 =====
-==== Lundi 8 Février ====
-Projet primaire terminé, projet secondaire CloudUnit.
-Cloudunit > trouver un moyens de config le proxy de cloudunit git pour réussir l’installation => Demande orale pour une connexion directe.
-==== Mardi 9 Février ====
-Débogage des scripts d'installation CloudUnit
-==== Mercredi 10 février ====
-Mise en forme du rapport hebdomadaire sur le wiki
-Mise à disposition de la documentation sur l'espace co du département

Viper61's Wiki

Outils pour utilisateurs

Outils du site

Différences

Outils de la page