Extract project 1 from tutorial
This commit is contained in:
parent
f7f8251bd1
commit
27e6dc7863
15 changed files with 95 additions and 59 deletions
|
|
@ -1,4 +1,4 @@
|
|||
SOURCES = tutorial.md setup.md what.md manual.md compose.md machine.md swarm.md stack.md project.md
|
||||
SOURCES = tutorial.md setup.md what.md manual.md compose.md machine.md swarm.md stack.md rendu.md
|
||||
PANDOCOPTS = --latex-engine=xelatex \
|
||||
--standalone \
|
||||
--normalize \
|
||||
|
|
|
|||
|
|
@ -1,226 +0,0 @@
|
|||
\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>
|
||||
|
||||
|
||||
### Palier 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`
|
||||
|
||||
Faites-vous la main sur ces trois images : lancez les ; l'ordre suggéré par les
|
||||
notes du prestataire devraient vous aider.
|
||||
|
||||
Pensez à inspecter les conteneurs pour voir les objets Docker qu'ils créent
|
||||
et/ou exposent.
|
||||
|
||||
Vous devriez pouvoir lancer `docker container run nemunaire/fic-IMAGE --help`
|
||||
sur les images.
|
||||
|
||||
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 :
|
||||
|
||||
```shell
|
||||
docker pull nemunaire/fic-admin nemunaire/fic-backend nemunaire/fic-frontend
|
||||
```
|
||||
|
||||
|
||||
### Palier 1 : `docker-compose.yml`
|
||||
|
||||
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`, ...)
|
||||
|
||||
|
||||
### Palier 2 : retrouver les `Dockerfile`
|
||||
|
||||
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 :
|
||||
|
||||
* admin
|
||||
* backend
|
||||
* frontend
|
||||
|
||||
Arriverez-vous à générer des images plus propres que celles du prestataire
|
||||
disparu ?!
|
||||
|
||||
|
||||
#### Astuces
|
||||
|
||||
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).
|
||||
|
||||
|
||||
### Palier 3 : `fic-server.yml` prêt pour le déploiement
|
||||
|
||||
À 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`.
|
||||
|
||||
|
||||
### Palier 4 : `fic-server.yml` prêt pour la production
|
||||
|
||||
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.
|
||||
|
||||
|
||||
### Palier 5 (bonus) : `fic-server.yml` sécurisé
|
||||
|
||||
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/).
|
||||
|
||||
|
||||
## Modalité de rendu
|
||||
|
||||
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
|
||||
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é 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).
|
||||
|
||||
|
||||
## Tarball
|
||||
|
||||
Tous les fichiers identifiés comme étant à rendre pour ce TP sont à
|
||||
placer dans une tarball (pas d'archive ZIP, RAR, ...).
|
||||
|
||||
Voici une arborescence type (vous pourriez avoir des fichiers supplémentaires,
|
||||
cela dépendra de votre avancée dans le projet) :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
login_x-TP2/tp/docker-compose.yml
|
||||
login_x-TP2/tp/mymonitoring-stack.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>
|
||||
39
tutorial/docker-orchestration/rendu.md
Normal file
39
tutorial/docker-orchestration/rendu.md
Normal file
|
|
@ -0,0 +1,39 @@
|
|||
Modalités de rendu
|
||||
------------------
|
||||
|
||||
En tant que personnes sensibilisées à la sécurité des échanges électroniques,
|
||||
vous devrez m'envoyer vos rendus signés avec votre clef PGP.
|
||||
|
||||
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
|
||||
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é 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).
|
||||
|
||||
|
||||
Tarball
|
||||
-------
|
||||
|
||||
Tous les fichiers identifiés comme étant à rendre pour ce TP sont à
|
||||
placer dans une tarball (pas d'archive ZIP, RAR, ...).
|
||||
|
||||
Voici une arborescence type (vous pourriez avoir des fichiers supplémentaires,
|
||||
cela dépendra de votre avancée dans le projet) :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
login_x-TP2/tp/docker-compose.yml
|
||||
login_x-TP2/tp/mymonitoring-stack.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>
|
||||
Loading…
Add table
Add a link
Reference in a new issue