virli/tutorial/docker-orchestration/project.md

\newpage

Rendu
=====

## Projet

M. Dessi, votre DSI, vient vous voir, paniqué : une grande conférence se tient
dans deux semaines, l'entreprise avait été mandatée de longue date pour
réaliser une interface d'animation pour un des événements majeurs et cela fait
un mois maintenant qu'il est sans nouvelle du sous-traitant à qui cette tâche
avait été confiée. On ne peut pas attendre davantage, vous êtes mandaté pour
terminer le projet qui a été laissé en plan par le sous-traitant.

Heureusement pour vous, il semblerait que tout le code de l'interface ait été
envoyé sur un dépôt git de l'entreprise. Il semblerait qu'il ne reste plus qu'à
déployer la solution.

Voici les notes retrouvées dans les derniers échanges avec le sous-traitant :

<div lang="en-US">
> Pour avoir quelque chose de fonctionnel :
>
>     # Un environnement de travail Go >= 1.6 est nécessaire.
>
>     # Récupération du projet, des dépendances et build
>     git clone git://git.nemunai.re/fic/server.git $GOPATH/src/srs.epita.fr/fic-server
>
>     go get -d srs.epita.fr/fic-server/admin
>     go build -o $GOPATH/src/srs.epita.fr/fic-server/fic-admin srs.epita.fr/fic-server/admin
>
>     go get -d srs.epita.fr/fic-server/backend
>     go build -o $GOPATH/src/srs.epita.fr/fic-server/fic-backend srs.epita.fr/fic-server/backend
>
>     go get -d srs.epita.fr/fic-server/frontend
>     go build -o $GOPATH/src/srs.epita.fr/fic-server/fic-frontend srs.epita.fr/fic-server/frontend
>
>     # Configuration de la base de données : par défaut tous les composants vont se connecter à
>     # fic:fic@localhost/fic, voir l'option -dsn pour d'autres paramètres
>     mysql -u root -p <<EOF
>     CREATE DATABASE fic;
>     CREATE USER fic@localhost IDENTIFIED BY 'fic';
>     GRANT ALL ON fic.* TO fic@localhost;
>     EOF
>
>     cd $GOPATH/src/srs.epita.fr/fic-server/
>     ./fic-admin &
>     # À ce stade http://localhost:8081/ permet d'accéder à l'interface d'admin
>
>     mkdir TEAMS
>     # Ce dossier va contenir les fichiers statiques générés (themes.json, teams.json, my.json, ...)
>     # pour chaque équipe
>     ./fic-backend &
>     # Le backend génére les fichiers pour toutes les équipes puis attend des validations dans
>     # le dossier submissions.
>     # Il n'écoute que les modifications du système de fichiers, il n'a pas d'interface d'interface HTTP.
>
>     ./fic-frontend &
>     # Il s'agit d'une API qui va donner l'heure (/time.json) et qui va recevoir les validations pour
>     # les écrire dans des fichiers. Avec le moins d'intelligence possible pour éviter des vulnérabilités.
>     # Un nginx est nécessaire au dessus pour gérer l'authentification.
>
> Un exemple de conf nginx est disponible dans la branche f/ansible :
>
>   - la version utilisant un simple `htpasswd` :
>     <https://git.nemunai.re/?p=fic/server.git;a=blob;hb=refs/heads/f/ansible;f=playbooks/roles/fic-frontend/files/nginx-frontend-htpasswd.conf>
>
>   - la version utilisant PAM (c'est ce qu'on utilise dans
>     l'environnement de préproduction, on se base sur le LDAP de la boîte)
>     <https://git.nemunai.re/?p=fic/server.git;a=blob;f=playbooks/roles/fic-frontend/files/nginx-frontend-pam.conf;hb=refs/heads/f/ansible>
>
>   - la version utilisant les certificats clients : qui n'a pas été
>     commitée encore.
>
> Il faut ajouter un binding certificat/remote_user -> team, dans le
> fichier `/etc/nginx/auth.conf`.
>   - pour les certificats : <http://localhost:8081/api/teams-nginx> ;
>   - pour l'auth HTTP : <http://localhost:8081/api/teams-nginx-members>.
>
> En production, le frontend est déporté sur une autre machine et un `rsync`
> s'occupe de synchroniser les dossiers submissions et TEAMS des deux
> machines. Ainsi, la machine validant les solutions et contenant toutes
> les données n'est jamais accessible du réseau local, c'est elle qui
> initie les rsync de manière régulière.
</div>


### Stage 0 : Récupérer les images

Le sous-traitant a laissé des images Docker sur le Docker Hub, vous pourrez
vous baser dessus pour commencer.

* `nemunaire/fic-admin`
* `nemunaire/fic-backend`
* `nemunaire/fic-frontend`


### Stage 2 : `docker-compose.yml` simple

* admin
* backend
* frontend
* mysql


### Stage 2 (bis) : `docker-compose.yml` avec autentification

* admin
* backend
* frontend
* mysql
* nginx (auth)


### Stage 3 : `fic-server.yml` sécurisé

* admin
* backend
* frontend
* mysql
* nginx (auth)

Utilisant `docker secrets` et `docker config`.


### Stage 4 : retrouver les `Dockerfile`

* admin
* backend
* frontend


### Stage 5 : `fic-server.yml` production ready

ssh between back and front et sur deux machines distinctes


## Modalité de rendu

Un service automatique s'occupe de réceptionner vos rendus, de faire les
vérifications nécessaires et de vous envoyer un accusé de réception (ou de
rejet).

Ce service écoute sur l'adresse <virli@nemunai.re>, c'est donc à cette adresse
et exclusivement à celle-ci que vous devez envoyer vos rendus. Tout rendu
envoyé à une autre adresse et/ou non signé ne sera pas pris en compte.


## Tarball

Tous les fichiers identifiés comme étant à rendre pour ce TP sont à
placer dans une tarball (pas d'archive ZIP, RAR, ...).

Les réponses aux questions sont à regrouper dans un fichier `questions.txt` à
placer à la racine de votre rendu.

Voici une arborescence type:

<div lang="en-US">
```
login_x-TP2/influxdb
login_x-TP2/influxdb/Dockerfile
login_x-TP2/influxdb/influxdb.conf
login_x-TP2/docker-compose.yml
login_x-TP2/mymonitoring.yml
login_x-TP2/fic-server
login_x-TP2/fic-server/fic-server.yml
login_x-TP2/fic-server/Dockerfile-admin
login_x-TP2/fic-server/Dockerfile-backend
login_x-TP2/fic-server/Dockerfile-frontend
```
</div>