virli/tutorial/docker-orchestration/project.md

227 lines
8.3 KiB
Markdown
Raw Normal View History

2015-10-29 04:45:40 +00:00
\newpage
2016-09-15 00:46:46 +00:00
Rendu
=====
2015-10-29 04:45:40 +00:00
2016-09-15 00:46:46 +00:00
## Projet
2015-10-29 04:45:40 +00:00
2017-10-18 13:09:44 +00:00
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>
2017-10-23 20:25:51 +00:00
### Palier 0 : Récupérer les images
2017-10-18 13:09:44 +00:00
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`
2017-10-17 23:59:55 +00:00
2017-10-19 01:14:30 +00:00
Faites-vous la main sur ces trois images : lancez les ; l'ordre suggéré par les
notes du prestataire devraient vous aider.
2017-10-17 23:59:55 +00:00
2017-10-19 01:14:30 +00:00
Pensez à inspecter les conteneurs pour voir les objets Docker qu'ils créent
et/ou exposent.
2017-10-17 23:59:55 +00:00
2017-10-19 01:14:30 +00:00
Vous devriez pouvoir lancer `docker container run nemunaire/fic-IMAGE --help`
sur les images.
2017-10-17 23:59:55 +00:00
2017-10-19 01:14:30 +00:00
Durant la durée du projet, les images seront peut-être amenés à être mis à
jour, si vous vous trouvez bloqué, commencez par vérifier que vous avez bien la
dernière version disponible de l'image :
2017-10-17 23:59:55 +00:00
2017-10-19 01:14:30 +00:00
```shell
docker pull nemunaire/fic-admin nemunaire/fic-backend nemunaire/fic-frontend
```
2017-10-17 23:59:55 +00:00
2017-10-23 20:25:51 +00:00
### Palier 1 : `docker-compose.yml`
2017-10-17 23:59:55 +00:00
2017-10-19 01:14:30 +00:00
Maintenant que vous arrivez à lancer les images, rendez cela reproductible en
inscrivant tout ça dans un fichier YAML, compréhensible par `docker-compose` !
Vous devriez avoir ces services :
* `mariadb` (ou `mysql`)
* `admin`
* `backend`
* `frontend`
* `nginx` (ou `apache`, ...)
2017-10-17 23:59:55 +00:00
2017-10-23 20:25:51 +00:00
### Palier 2 : retrouver les `Dockerfile`
2017-10-19 01:14:30 +00:00
Maintenant que vous êtes en mesure de lancer le service, il serait temps de ne
plus dépendre d'une image que l'on ne peut plus modifier facilement.
Pour ce palier, vous allez devoir réécrire les trois fichiers `Dockerfile`,
pour chacun des service :
2017-10-18 13:09:44 +00:00
* admin
* backend
* frontend
2017-10-19 01:14:30 +00:00
Arriverez-vous à générer des images plus propres que celles du prestataire
disparu ?!
2017-10-18 13:09:44 +00:00
2017-10-19 01:14:30 +00:00
#### Astuces
2017-10-17 23:59:55 +00:00
2017-10-19 01:14:30 +00:00
Les différents projets sont organisés au sein d'un
[dépôt monolithique](https://danluu.com/monorepo/). Les projets ont des
dépendances entre les dossiers qui se trouvent à la racine (qui sont
l'équivalent de bibliothèques). Vous allez sans doute vouloir placer les trois
`Dockerfile` à la racine pour simplifier les étapes de construction des images :
```shell
docker image build --file Dockerfile-admin .
```
Les
[*multi-stage builds*](https://docs.docker.com/engine/userguide/eng-image/multistage-build/)
vous seront d'une grande aide.
Si vous n'avez pas le choix d'utiliser une vieille version de Docker qui ne
supporte pas la syntaxe au sein d'un seul fichier, vous pouvez ajouter des
scripts et autant de `Dockerfile` que nécessaire à la tarball (mais vous
devriez considérer l'option de mettre à jour votre Docker).
2017-10-23 20:25:51 +00:00
### Palier 3 : `fic-server.yml` prêt pour le déploiement
2017-10-19 01:14:30 +00:00
À présent, faites les éventuelles adaptations nécessaires pour que votre
fichier `docker-compose.yml` puisse s'exécuter au sein d'un cluster de
plusieurs machines. Via `docker stack deploy`.
2017-10-23 20:25:51 +00:00
### Palier 4 : `fic-server.yml` prêt pour la production
2017-10-19 01:14:30 +00:00
Comme indiqué dans les notes du prestataire, en production, le frontend se
trouve sur une machine distincte du backend.
À vous de trouvez une solution élégante pour gérer la synchronisation des
données ! Il est fort probable que vous ayez à ajouter des services à votre
fichier YAML.
2017-10-23 20:25:51 +00:00
### Palier 5 (bonus) : `fic-server.yml` sécurisé
2017-10-19 01:14:30 +00:00
Vous avez indiqués des mots de passes bidons dans votre YAML ? Rangez les
informations sensibles au sein de
[`docker secret`](https://docs.docker.com/engine/swarm/secrets/) et les
éléments de configuration qui pourraient être changés au sein de
[`docker config`](https://docs.docker.com/engine/swarm/configs/).
2017-10-17 23:59:55 +00:00
2015-10-29 04:45:40 +00:00
2016-09-15 00:46:46 +00:00
## Modalité de rendu
2015-10-29 04:45:40 +00:00
2017-10-19 01:14:30 +00:00
Un service automatique s'occupe de réceptionner vos rendus, de faire des
vérifications élémentaires et de vous envoyer un accusé de réception (ou de
2016-09-15 00:46:46 +00:00
rejet).
2015-10-29 04:45:40 +00:00
2016-09-15 00:46:46 +00:00
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
2017-10-19 01:14:30 +00:00
envoyé à une autre adresse et/ou non signé et/ou reçu après la correction ne
sera pas pris en compte.
Par ailleurs, n'oubliez pas de répondre à
[l'évaluation du cours](https://www.epitaf.fr/moodle/mod/quiz/view.php?id=33).
2015-10-29 04:45:40 +00:00
2016-09-15 00:46:46 +00:00
## Tarball
2015-10-29 04:45:40 +00:00
2016-09-15 00:46:46 +00:00
Tous les fichiers identifiés comme étant à rendre pour ce TP sont à
placer dans une tarball (pas d'archive ZIP, RAR, ...).
2015-10-29 04:45:40 +00:00
2017-10-19 01:14:30 +00:00
Voici une arborescence type (vous pourriez avoir des fichiers supplémentaires,
cela dépendra de votre avancée dans le projet) :
2015-10-29 04:45:40 +00:00
2017-10-17 06:29:07 +00:00
<div lang="en-US">
2015-10-29 04:45:40 +00:00
```
2017-10-19 01:14:30 +00:00
login_x-TP2/tp/docker-compose.yml
login_x-TP2/tp/mymonitoring-stack.yml
2017-10-16 01:10:34 +00:00
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
2015-10-29 04:45:40 +00:00
```
2017-10-17 06:29:07 +00:00
</div>