Rapport hebdomadaire

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.

Réunion avec l'ensemble du service.
Travail sur la présentation Docker/Owncloud.

Élaboration d’un document technique qui recense les ressources nécessaire au maquettage des solutions (CF: Ressources nécessaires au maquettage)
Réunion de cadrage du projet, point sur les spécificités techniques.

Amélioration de la présentation, ajout de correctif suite à la réunion.
Installation des VMs sous SUSE 12

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.

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…

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

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

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

Fix du bug ownCloud ⇒ PHP mal config, cgi.fix_pathinfo=0 → cgi.fix_pathinfo=1
Début de la customisation du ownCloud

Documentation sur le 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.

Tout faire fonctionner sous SLES ! ⇒ OK
Ajout des docs sur le wiki
Volume → Conteneur de données??

• Synchro fichiers??
• ⇒ TODO

Des problèmes pour la configuration du cluster Postgres.
Commencer les recherches pour synchroniser les fichiers entre les deux hôtes.

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.

Mise à jour de la doc maquettage
Solution de montage NFS pour les data. Problème de propriétaire/groupe

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

Montage NFS fonctionnelle + modification permissions/propriétaire/groupe
Cluster Postgresql master-master ne fonctionne pas

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

Recherche sur le cluster postgres

Continuer la présentation → rajouter des diapo pour le cluster docker (avec Swarm) + l’interface de gestion Shipyard
Cluster postgres, again

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

Réunion de début de mois avec les employées du service.
Correction des différents documents produit sur le wiki.

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

Gestions des incidents :

• Logiciels de ticketing : Isilog

Prise en main à distance :

• Poste Sirius (Seven) : Novel ZENworks
• Poste Comet (XP) : Novel ConsoleOne

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

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

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

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.

Débogage des scripts d'installation CloudUnit

Ajout du rapport hebdo sur le wiki
Mise à disposition de la documentation sur l'espace co du département

Mise en forme du rapport hebdomadaire sur le wiki
Finission de nos rapport personnelle

Redaction d’un document sur cloudunit