New tuto 3 done

This commit is contained in:
nemunaire 2020-10-28 23:16:34 +01:00
parent 5f4880dc50
commit ba77aca73b
57 changed files with 1026 additions and 137 deletions

View File

@ -2,8 +2,6 @@ include ../pandoc-opts.mk
SOURCES = tutorial.md \
../dockerfiles/interactive.md ../dockerfiles/dockerfile.md ../dockerfiles/goodpractices.md ../dockerfiles/entrypoint.md \
../docker-internals/registry.md \
../docker-internals/runc.md \
../docker-internals/clair.md \
rendu.md

View File

@ -19,7 +19,7 @@ envoyé à une autre adresse et/ou non signé et/ou reçu après la correction n
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=307).
[l'évaluation du cours](https://virli.nemunai.re/quiz/4).
Tarball
@ -39,8 +39,6 @@ login_x-TP2/youp0m/Dockerfile
login_x-TP2/youp0m/entrypoint.sh
login_x-TP2/youp0m/.dockerignore
login_x-TP2/youp0m/...
login_x-TP2/registry_play.sh
login_x-TP5/runc/config.json
login_x-TP2/clair/docker-compose.yml
login_x-TP2/clair/clair_config/config.yaml
login_x-TP2/nginx:mainline.html # rapport d'analyse PAclair

View File

@ -3,7 +3,7 @@ title: Virtualisation légère -- TP n^o^ 2
subtitle: Construire des images Docker et leur sécurité
author: Pierre-Olivier *nemunaire* [Mercier]{.smallcaps}
institute: EPITA
date: Mercredi 16 octobre 2019
date: Mardi 22 septembre 2020
abstract: |
Durant ce deuxième TP, nous allons voir comment créer nos propres
images, comment s'assurer qu'elles n'ont pas de vulnérabilités
@ -12,15 +12,14 @@ abstract: |
\vspace{1em}
Tous les éléments de ce TP (exercices et projet) sont à rendre à
<virli@nemunai.re> au plus tard le mercredi 23 octobre 2019 à 13 h
42, des questions de cours sont également à compléter avant cette
date sur Epitaf. Consultez la dernière section de chaque partie pour
plus d'information sur les éléments à rendre.
<virli@nemunai.re> au plus tard le **jeudi 22 octobre 2020 à 12 h
42**. Consultez la dernière section de chaque partie pour plus d'information
sur les éléments à rendre. Et n'oubliez pas de répondre aux [questions de
cours](https://virli.nemunai.re/quiz/4).
En tant que personnes sensibilisées à la sécurité des échanges
électroniques, vous devrez m'envoyer vos rendus signés avec votre
clef PGP. Pensez à
[me](https://keys.openpgp.org/search?q=nemunaire%40nemunai.re)
faire signer votre clef et n'hésitez pas à [faire signer la
En tant que personnes sensibilisées à la sécurité des échanges électroniques,
vous devrez m'envoyer vos rendus signés avec votre clef PGP. Pensez à
[me](https://keys.openpgp.org/search?q=nemunaire%40nemunai.re) faire signer
votre clef et n'hésitez pas à [faire signer la
votre](https://www.meetup.com/fr/Paris-certification-de-cles-PGP-et-CAcert/).
...

View File

@ -1,6 +1,14 @@
include ../pandoc-opts.mk
SOURCES = tutorial.md installation.md chroot.md pseudofs.md capabilities.md cgroups.md oom.md seccomp.md project-intro.md project-body.md project-rendu.md
SOURCES = tutorial.md \
../devops/devops.md \
../devops/what.md \
../devops/tools.md \
../devops/ci.md \
../devops/publish-docker.md \
../docker-internals/oci.md \
../docker-internals/registry.md \
rendu.md
all: tutorial.pdf

View File

@ -1,39 +0,0 @@
## 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é 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=308).
## 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 (adaptez les extensions et les éventuels
fichiers supplémentaires associés au langage que vous aurez choisi
pour chaque exercice) :
<div lang="en-US">
```
login_x-TP3/
login_x-TP3/escape.c
login_x-TP3/procinfo.sh
login_x-TP3/suspend_schedule.sh
login_x-TP3/view_caps.c
login_x-TP3/monitor.sh
login_x-TP3/monitor_init.sh
login_x-TP3/syscall_filter.c
```
</div>
Les premières étapes du projet ne sont pas à rendre et feront l'objet
d'un rendu à part.

49
tutorial/3/rendu.md Normal file
View File

@ -0,0 +1,49 @@
\newpage
Rendu
=====
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://virli.nemunai.re/quiz/5).
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) :
<div lang="en-US">
```
login_x-TP3/
login_x-TP3/cicd-playbook/
login_x-TP3/cicd-playbook/cicd-setup.yml
login_x-TP3/cicd-playbook/roles/...
login_x-TP3/youp0m/
login_x-TP3/youp0m/.drone.yml
login_x-TP3/youp0m/.ansible/... # Pour ceux qui auraient fait le 5.4 optionnel
login_x-TP3/youp0m/Dockerfile
login_x-TP3/youp0m/entrypoint.sh
login_x-TP3/youp0m/.dockerignore
login_x-TP3/youp0m/...
login_x-TP3/registry_play.sh
```
</div>

View File

@ -1,25 +1,24 @@
---
title: Virtualisation légère -- TP n^o^ 3
subtitle: Linux Internals partie 1
subtitle: DevOps, intégration et déploiement continu
author: Pierre-Olivier *nemunaire* [Mercier]{.smallcaps}
institute: EPITA
date: Mercredi 23 octobre 2019
date: Mercredi 28 octobre 2020
abstract: |
Ce premier TP consacré aux Linux Internals va nous permettre
d'appréhender les notions de pseudos systèmes de fichiers, de
cgroups ainsi que de capabilities.
Durant ce troisième TP, nous allons jouer les DevOps et déployer
automatiquement des services !
\vspace{1em}
Certains éléments de ce TP sont à rendre à <virli@nemunai.re> au
plus tard le mercredi 6 novembre 2019 à 13 h 42. Consultez la
dernière section de chaque partie pour plus d'information sur les
éléments à rendre.
Tous les éléments de ce TP (exercices et projet) sont à rendre à
<virli@nemunai.re> au plus tard le **mercredi 4 novembre 2020 à 12 h
42**. Consultez la dernière section de chaque partie pour plus d'information
sur les éléments à rendre. Et n'oubliez pas de répondre aux [questions de
cours](https://virli.nemunai.re/quiz/5).
En tant que personnes sensibilisées à la sécurité des échanges
électroniques, vous devrez m'envoyer vos rendus signés avec votre
clef PGP. Pensez à
[me](https://keys.openpgp.org/search?q=nemunaire%40nemunai.re)
faire signer votre clef et n'hésitez pas à [faire signer la
En tant que personnes sensibilisées à la sécurité des échanges électroniques,
vous devrez m'envoyer vos rendus signés avec votre clef PGP. Pensez à
[me](https://keys.openpgp.org/search?q=nemunaire%40nemunai.re) faire signer
votre clef et n'hésitez pas à [faire signer la
votre](https://www.meetup.com/fr/Paris-certification-de-cles-PGP-et-CAcert/).
...

View File

@ -1,11 +1,11 @@
include ../pandoc-opts.mk
SOURCES_TUTO = tutorial.md setup.md mount.md namespaces.md cmpns.md docker-exec.md networkns.md pidns.md mountns.md userns.md rendu.md
SOURCES = tutorial.md installation.md chroot.md pseudofs.md capabilities.md cgroups.md oom.md seccomp.md project-intro.md project-body.md project-rendu.md
all: tutorial.pdf
tutorial.pdf: ${SOURCES_TUTO}
tutorial.pdf: ${SOURCES}
pandoc ${PANDOCOPTS} -o $@ $+
clean::

View File

@ -5,20 +5,20 @@ Projet et rendu
## Sujet
**Ce projet, étalé sur ce TP et le TP précédent, constitue le cœur de la
notation de ce cours.**
Vous allez continuer aujourd'hui le projet qui s'étendra depuis le TP précédent
et qui consistera à réaliser la partie d'isolation de la moulinette des ACUs !
Vous allez commencer aujourd'hui un projet qui s'étendra au prochain TP et qui
consistera à réaliser la partie d'isolation de la moulinette des ACUs !
Cette semaine, il faudra faire en sorte de restreindre un groupe de processus
pour qu'il s'exécute indépendemment de votre système.
pour qu'il ne puisse pas faire de déni de service sur notre machine.
Il n'y a pas de restriction sur le langage utilisé, vous pouvez tout aussi bien
utiliser du C, du C++, du Python, du shell, etc.
utiliser du C, du C++, du Python, etc.
L'usage de bibliothèques **non relatives** au projet est autorisé : le but de
ce sujet est d'évaluer votre compréhension et votre utilisation de la
tuyauterie bas-niveau du noyau liée à la virtualisation légère. À partir du
moment où vous n'utilisez pas une bibliothèque qui abstrait complètement cette
plomberie, n'hésitez pas à l'utiliser !
Gardez en tête que ce projet sera à continuer au prochain TP, où il sera
principalement question de faire des appels systèmes.

View File

@ -1,32 +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.
## 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
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.
Pour différencier le rendu du TP, du rendu du projet, ajoutez une balise
`[PROJET]` au sujet de votre courriel, afin qu'il soit traité comme tel.
Par ailleurs, n'oubliez pas de répondre à
[l'évaluation du cours](https://www.epitaf.fr/moodle/mod/quiz/view.php?id=308).
Tarball
-------
Le projet à rendre pour ce cours est à placer dans une tarball (pas d'archive
ZIP, RAR, ...).
## Tarball
Voici une arborescence type:
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 (adaptez les extensions et les éventuels
fichiers supplémentaires associés au langage que vous aurez choisi
pour chaque exercice) :
<div lang="en-US">
```
login_x-mymoulette/README
login_x-mymoulette/...
login_x-TP3/
login_x-TP3/escape.c
login_x-TP3/procinfo.sh
login_x-TP3/suspend_schedule.sh
login_x-TP3/view_caps.c
login_x-TP3/monitor.sh
login_x-TP3/monitor_init.sh
login_x-TP3/syscall_filter.c
```
</div>
Les premières étapes du projet ne sont pas à rendre et feront l'objet
d'un rendu à part.

View File

@ -1,19 +1,20 @@
---
title: Virtualisation légère -- TP n^o^ 4
subtitle: Linux Internals partie 2
title: Virtualisation légère -- TP n^o^ 3
subtitle: Linux Internals partie 1
author: Pierre-Olivier *nemunaire* [Mercier]{.smallcaps}
institute: EPITA
date: Mercredi 6 novembre 2019
date: Mercredi 23 octobre 2019
abstract: |
Le but de ce second TP sur les mécanismes internes du noyau va nous
permettre d'utiliser les commandes et les appels systèmes relatifs
aux *namespaces* ainsi que d'appréhender la complexité des systèmes
de fichiers.
Ce premier TP consacré aux Linux Internals va nous permettre
d'appréhender les notions de pseudos systèmes de fichiers, de
cgroups ainsi que de capabilities.
\vspace{1em}
Tous les exercices de ce TP sont à rendre à <virli@nemunai.re> au
plus tard le mercredi 20 novembre 2017 à 13 h 42.
Certains éléments de ce TP sont à rendre à <virli@nemunai.re> au
plus tard le mercredi 6 novembre 2019 à 13 h 42. Consultez la
dernière section de chaque partie pour plus d'information sur les
éléments à rendre.
En tant que personnes sensibilisées à la sécurité des échanges
électroniques, vous devrez m'envoyer vos rendus signés avec votre

12
tutorial/5/Makefile Normal file
View File

@ -0,0 +1,12 @@
include ../pandoc-opts.mk
SOURCES_TUTO = tutorial.md setup.md mount.md namespaces.md cmpns.md docker-exec.md networkns.md pidns.md mountns.md userns.md rendu.md
all: tutorial.pdf
tutorial.pdf: ${SOURCES_TUTO}
pandoc ${PANDOCOPTS} -o $@ $+
clean::
rm tutorial.pdf

View File

@ -5,20 +5,20 @@ Projet et rendu
## Sujet
Vous allez commencer aujourd'hui un projet qui s'étendra au prochain TP et qui
consistera à réaliser la partie d'isolation de la moulinette des ACUs !
**Ce projet, étalé sur ce TP et le TP précédent, constitue le cœur de la
notation de ce cours.**
Vous allez continuer aujourd'hui le projet qui s'étendra depuis le TP précédent
et qui consistera à réaliser la partie d'isolation de la moulinette des ACUs !
Cette semaine, il faudra faire en sorte de restreindre un groupe de processus
pour qu'il ne puisse pas faire de déni de service sur notre machine.
pour qu'il s'exécute indépendemment de votre système.
Il n'y a pas de restriction sur le langage utilisé, vous pouvez tout aussi bien
utiliser du C, du C++, du Python, etc.
utiliser du C, du C++, du Python, du shell, etc.
L'usage de bibliothèques **non relatives** au projet est autorisé : le but de
ce sujet est d'évaluer votre compréhension et votre utilisation de la
tuyauterie bas-niveau du noyau liée à la virtualisation légère. À partir du
moment où vous n'utilisez pas une bibliothèque qui abstrait complètement cette
plomberie, n'hésitez pas à l'utiliser !
Gardez en tête que ce projet sera à continuer au prochain TP, où il sera
principalement question de faire des appels systèmes.

View File

@ -0,0 +1,32 @@
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 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é et/ou reçu après la correction ne
sera pas pris en compte.
Pour différencier le rendu du TP, du rendu du projet, ajoutez une balise
`[PROJET]` au sujet de votre courriel, afin qu'il soit traité comme tel.
Tarball
-------
Le projet à rendre pour ce cours est à placer dans une tarball (pas d'archive
ZIP, RAR, ...).
Voici une arborescence type:
<div lang="en-US">
```
login_x-mymoulette/README
login_x-mymoulette/...
```
</div>

24
tutorial/5/tutorial.md Normal file
View File

@ -0,0 +1,24 @@
---
title: Virtualisation légère -- TP n^o^ 4
subtitle: Linux Internals partie 2
author: Pierre-Olivier *nemunaire* [Mercier]{.smallcaps}
institute: EPITA
date: Mercredi 6 novembre 2019
abstract: |
Le but de ce second TP sur les mécanismes internes du noyau va nous
permettre d'utiliser les commandes et les appels systèmes relatifs
aux *namespaces* ainsi que d'appréhender la complexité des systèmes
de fichiers.
\vspace{1em}
Tous les exercices de ce TP sont à rendre à <virli@nemunai.re> au
plus tard le mercredi 20 novembre 2017 à 13 h 42.
En tant que personnes sensibilisées à la sécurité des échanges
électroniques, vous devrez m'envoyer vos rendus signés avec votre
clef PGP. Pensez à
[me](https://keys.openpgp.org/search?q=nemunaire%40nemunai.re)
faire signer votre clef et n'hésitez pas à [faire signer la
votre](https://www.meetup.com/fr/Paris-certification-de-cles-PGP-et-CAcert/).
...

6
tutorial/devops/cd.md Normal file
View File

@ -0,0 +1,6 @@
\newpage
Déploiement
===========
TODO il faudrait pouvoir cliquer sur le bouton pour mettre à jour l'image docker qui tourne localement ? en passant par Ansible ?

118
tutorial/devops/ci.md Normal file
View File

@ -0,0 +1,118 @@
\newpage
Intégration continue
====================
Une fois Gitea et Drone installés et configurés, nous allons pouvoir rentré
dans le vif du sujet : faire de l'intégration continue sur notre premier projet !
## `youp0m`
### Créez un dépôt pour `youp0m`
Reprenez les travaux réalisés au TP précédent. Nous allons notamment avoir
besoin du `Dockerfile` dans la section suivante.
Après avoir créé (ou migré pour les plus malins !) le dépôt
[`youp0m`](https://gitea.nemunai.re/nemunaire/youp0m), dans Drone,
synchronisez les dépôts, puis activez la surveillance de `youp0m`.
Vous allez devoir rédiger un fichier `.drone.yml`, que l'on placera à la
racine du dépôt (celui qui existe déjà dans le dépôt pourra servir
d'inspiration, mais il ne fonctionnera pas directement sur votre
installation). C'est ce fichier qui sera traité par DroneCI pour savoir comment
compiler et tester le projet.
### Définir les étapes d'intégration
Toutes les informations nécessaire à l'écriture du fichier `.drone.yml` se
trouvent dans [l'excellente documentation du
projet](https://docs.drone.io/pipeline/docker/examples/languages/golang/).
Les étapes sont sensiblement les mêmes que dans le `Dockerfile` que vous avez
écrit lors du TP précédent.
Comittez puis pousser votre travail, dès qu'il sera reçu par Gitea, vous
devriez voir l'interface de Drone lancer les étapes décrites dans le fichier.
**IMPORTANT :** si vous avez l'impression que ça ne marche pas et que vous avez
réutilisé le fichier présent sur le dépôt au lieu de partir de l'exemple donné
dans la documentation, **commencez en partant de l'exemple de la
documentation** ! Le fichier présent sur le dépôt ne fonctionnera pas dans
votre situation !
![Drone en action](../devops/drone-run.png){height=8cm}
Lorsqu'apparaît enfin la ligne `git.nemunai.re/youp0m`, le projet est compilé !
### Inspection qualité
Nous n'avons pas encore de test à proprement parlé. Nous allons utiliser
[Sonarqube](https://www.sonarqube.org/) pour faire une revue qualité du code !
Tout d'abord, il faut lancer le conteneur Sonarqube (pensez à l'ajouter à votre
playbook !) :
<div lang="en-US">
```bash
docker run --rm -d --name sonarqube --network drone -p 9000:9000 sonarqube
```
</div>
Le service met un bon moment avant de démarrer, dès qu'il se sera initialisé,
nous pourrons accéder à l'interface sur <http://localhost:9000>.
En attendant qu'il démarre, nous pouvons commencer à ajouter le nécessaire à
notre `.drone.yml` : <http://plugins.drone.io/aosapps/drone-sonar-plugin/>.
Après s'être connecté à Sonarqube (`admin:admin`), nous pouvons aller générer
un token, tel que décrit dans la [documentation du plugin
Drone](http://plugins.drone.io/aosapps/drone-sonar-plugin/).
Une fois la modification commitée et poussée, Drone enverra le code à Sonarqube
qui en fera une analyse minutieuse. Rendez-vous sur
<http://127.0.0.1:9000/projects> pour admirer le résultat.
### Publier le binaire correspondant aux tags/jalons
Nous savons maintenant que notre projet compile bien dans un environnement
différent de celui du développeur ! Néanmoins, le binaire produit est perdu dès
lors que la compilation est terminée, car nous n'en faisons rien.
Ajoutons donc une nouvelle règle à notre `.droneci.yml` pour placer le binaire
au sein de la liste des fichiers téléchargeable aux côtés des tags.
Vous aurez sans doute besoin de :
- <https://docs.drone.io/pipeline/conditions/>
- <http://plugins.drone.io/drone-plugins/drone-gitea-release/>
Attention à ne pas stocker votre clef d'API dans le fichier YAML !
![Binaire publié automatiquement sur Gitea](../devops/tag-released.png){height=8cm}
Lorsque l'on est plusieurs à travailler sur le projet ou pour accroître la
sécurité, il convient de créer, un compte *bot* qui sera responsable de la
création des *releases*. Ce sera donc sa clef d'API que l'on indiquera dans
l'interface de Drone.
### Publier pour plusieurs architectures ?
Le compilateur Go est fourni avec l'ensemble des backends des différentes
architectures matérielles qu'il supporte, nous pouvons donc aisément faire de
la compilation croisée pour d'autres architectures.
Essayons maintenant de compiler `youp0m` pour plusieurs architecture afin de
vérifier que cela fonctionne bien !
Un exemple est donné tout en haut de cette page :
<https://docs.drone.io/pipeline/environment/syntax/>.
En faisant varier `$GOARCH` en `arm`, `arm64`, `mips`, ... nous pouvons générer
les binaires correspondant à chaque architecture et système.
Ajoutez au moins 2 autres architectures à votre fichier `.drone.yml`.

196
tutorial/devops/devops.md Normal file
View File

@ -0,0 +1,196 @@
\newpage
Le mouvement DevOps
===================
Jusqu'à récemment, et encore dans de nombreuses entreprises, les développeurs
et les administrateurs systèmes faisaient partis de deux équipes différentes :
les uns développant sur leurs machines avec les dernières bibliothèques,
utilisant les derniers frameworks à la mode, sans se préoccuper de la sécurité
(ils travaillent en `root` ou avec `sudo` ;)), tandis que les autres tentaient
tant bien que mal de déployer ces services avec les contraintes opérationnelles
en tête.\newline
Ces contraintes : tant liées à la **sécurité** (il faut s'assurer
qu'un service n'utilise pas une bibliothèque vulnérable par exemple, donc soit
utilisé sur un système à jour, et qu'il ne tourne pas en `root`), qu'à la
**disponibilité** (si le service est mal codé est contient beaucoup de fuites
mémoire, il ne faut pas que les autres services présents sur la même machine en
pâtissent).
Une guerre faisait donc rage entre les développeurs qui ne comprennaient pas
que les administrateurs système ne pouvaient pas maintenir autant de version
d'une bibliothèque qu'il y avait de service : par exemple dans le cas de
plusieurs services en PHP, on pouvait leur demander de déployer des
applications utilisant la version 5.1, et la 5.2 pour d'autres, ... lorsqu'il y
avait des incompatibilités mineures et plus personne pour s'occuper de la
maintenance d'un vieux service toujours utilisé.
Le même principe est aussi valable pour Python, Ruby, ... : les développeurs
ont toujours eu tendance à vouloir utiliser les dernières améliorations d'un
langage, mais les administrateurs systèmes n'ont alors pas de paquets stables
dans la distribution. En effet, les distributions stables telles que Debian,
RedHat ou CentOS ont des cycles de vie assez long et se concentrent plus sur la
stabilité.\newline
Cette stabilité est obtenue grâce à l'utilisation de versions éprouvées des
langages et des bibliothèques, qui assurent un temps de maintenance et de
recherche de bugs réduit aux équipes opérationnelles. Si un projet fonctionne
bien avec une version donnée d'une de ces distributions, on peut être assez
confiant sur le fait que ce sera toujours le cas (du moins tant que la
distribution assure le support de sa version).
\newline
Le but du DevOps est donc de retrouver une certaine fluidité entre le
développement et l'exploitation. Il s'agit d'un mouvement qui vise à ce que les
développeurs, sans avoir à gérer au quotidien la maintenance des serveurs de
production, soient davantage impliqués dans les opérations de déploiement. Cela
passe notamment par la prise en compte de l'environnement de déploiement dès la
phase de conception du projet, puis dès les premiers développements, des tests
automatisés sont réalisés directement dans un environnement proche de la
production.
Il en résulte moins de friction entre les deux équipes. Les développeurs étant
par ailleurs amenés à écrire des recettes de déploiement, tels que des
playbooks Ansible ou bien encore des conteneurs Docker.
\newline
Chez Google (et d'autres entreprises qui ont depuis repris l'idée), des équipes
sont chargées de développer la fiabilité des systèmes d'information de
production. Ce sont les équipes SRE, pour Site Reliability Engineering. On
confie alors complètement la responsabilité de l'environnement de production
aux développeurs qui sont chargés de l'automatiser. Au delà de l'automatisation
des déploiements des services, il s'agit ici de développer des mécanismes
permettant au système de réagir face aux situations telles que les montées en
charges, les pannes, ...
Attention par contre aux entreprises qui recrutent un profil DevOps, car cela a
autant de sens que recruter un développeur Scrum ou un développeur cycle en V :
DevOps est une méthodologie. Les entreprises qui recrutent un DevOps
recherchent généralement quelqu'un qui fera à la fois du développement logiciel
d'un côté et de l'administration système de l'autre : une situation
généralement assez difficile à vivre. Alors qu'au contraire, la mouvance DevOps
doit être prise au sérieux par l'ensemble des développeurs. Lors d'un entretien
d'embauche pour ce genre de poste, assurez-vous bien de ne pas être le seul à
faire du DevOps.
## Intégration continue
L'**intégration continue** est la première brique à mettre en place : le but
est de compiler automatiquement chaque commit dans un environnement proche de
celui de production, puis de lancer les suites de tests du logiciel.
Cela permet de détecter les problèmes au plus tôt dans le cycle de
développement, mais cela permet également d'améliorer la qualité du code sur le
long terme, car on peut y ajouter facilement des outils qui vont se charger
automatiquement de réaliser des analyses : cela peut aller de la couverture des
tests, à de l'analyse statique ou dynamique de binaire, en passant par la
recherche de vulnérabilités ou de mauvaises pratiques de programmation.
À la fin du processus, il est courant d'exporter les produits de compilation
(tarballs, paquets, ISO, conteneurs, ...) ainsi que les journaux et rapports
vers un dossier accessible. Cela permet ainsi aux développeurs de voir les
problèmes et de pousser les analyses avec leurs propres outils.
Sans déploiement continu (la section suivante), c'est également ces produits de
compilation que les administrateurs systèmes vont déployer sans peine, lorsque
les développeurs considéreront avoir atteint un jalon, une version stable.
## Déploiement continu
Une fois tous les tests passés et les objets produits (on parle d'*artifact* ou
d'*assets*), il est possible de déclencher un déploiement : il s'agit de rendre
accessible aux utilisateurs finaux le services ou les objets.
Dans le cas d'un programme à télécharger
([Python](https://buildbot.python.org/all/#/), VLC,
[MariaDB](https://buildbot.askmonty.org/buildbot/), ...), on va placer les
paquets sur le site internet, éventuellement mettre à jour un fichier pointant
vers la dernière version (pour que les utilisateurs aient la notifications).
Ou bien dans le cas d'un service en ligne (GitHub, Netflix, GMail, ...), il
s'agira de mettre à jour le service.
Parfois les deux seront à faire : à la fois publier un paquet ou un conteneur
et mettre à jour un service en ligne : [le serveur
Synapse](https://buildkite.com/matrix-dot-org/synapse) du protocole de
messagerie Matrix ou encore
[Gitlab](https://gitlab.com/gitlab-org/gitlab/-/pipelines).\newline
Il existe pour cela de très nombreuses stratégies : lorsque l'on n'a pas
beaucoup de trafic ni beaucoup de machines, on peut simplement éteindre
l'ancien service et démarrer le nouveau, si ça prend quelques millisecondes en
étant automatisé, cela peut être suffisant compte tenu du faible
traffic.
Lorsque l'on a un trafic élevé, de nombreux clients et donc que le service est
réparti sur plusieurs machines, on ne peut pas se contenter de tout éteindre et
de tout rallumer. Déjà parce que trop de visiteurs vont se retrouver avec des
pages d'erreur, et aussi parce qu'en cas de bug logiciel qui n'aurait pas été
vu malgré les étapes précédentes, cela pourrait créer une situation
catastrophique (imaginez qu'on ne puisse plus valider une commande sur Amazon à
cause d'une ligne commentée par erreur !).\newline
On va donc privilégier un déploiement progressif de la nouvelle version (que
l'on va étendre sur plusieurs minutes, heures ou mêmes jours), en éteignant
tour à tour les instances, et en veillant à ce que les métriques (voir la
section suivante !) soient constantes.
## Monitoring et supervision
Une fois déployé, le service peut avoir des ratés, alors il convient de le
surveiller afin d'être le plus proactif possible dans la résolution des
problèmes. La pire situation est celle dans laquelle c'est un utilisateur qui
nous informe d'un problème... (sur Twitter !?)
Nous avons réalisé durant le précédent TP, une partie collecte de métriques,
avec nos conteneurs TICK. Nous n'allons donc pas nous en occuper aujourd'hui.
\newline
Notez tout de même qu'il y a deux grandes catégories de logiciels de
supervision :
**Basée sur des états** comme Nagios, Zabbix, ... : ces logiciels vont
simplement réaliser des séries de tests définis, à intervalles réguliers et
contacter l'administrateur d'astreinte dès qu'un test ne passe plus de manière
persistante.
Il y a rarement beaucoup d'intelligence ou d'anticipation automatique dans ces
outils.
\newline
**Basée sur les métriques** comme ELK, Prometheus, InfluxDB, ... : dans la
stack TICK que nous avons mis en place au précédent TP, nous avions placé un
agent sur la machine que nous souhaitions analyser. Outre les graphiques
présenté dans Chronograf, le dernier outil que l'on n'avait pas configuré était
Kapacitor, qui permet après avoir analysé les données, d'alerter en fonction
d'une évolution.
L'instrumentation d'une application est une bonne manière de faire remonter des
métrique (combien de clients actuellement connectés, combien de
messages/transactions traités, ...). Ce sont autant d'information que l'on peut
faire remonter dans sa base de données de métriques.
\newline
La différence entre les deux techniques est que nagios va vous alerter à partir
d'un certain seuil que vous aurez préalablement défini (s'il reste moins de 10%
d'espace disque par exemple), tandis que Kapacitor va tenter d'interpréter les
indicateurs (et donc vous alerter seulement si la courbe représentant l'espace
disque disponible augmente de telle sorte qu'il ne reste plus que quelques
heures avant d'être saturé).
Sur la base de ces indicateurs, il est possible d'engager des opérations
automatiques, comme par exemple la provision de nouvelles machines pour épauler
un service distribuable, qui est proche de la surcharge, acheter de l'espace de
stockage supplémentaire auprès du fournisseur, ...
\newline
Enfin, citons dans cette partie le [Chaos
Monkey](https://fr.wikipedia.org/wiki/Chaos_Monkey), conçu par Netflix, qui est
un programme qui va casser de manière aléatoire des éléments de l'environnement
de production. Le but est de provoquer sciemment des pannes, des latences,
... à n'importe quel niveau du produit, afin d'en tester (brulatement certes)
sa résilience. Cela oblige les développeurs, les opérationnels et les
architectes à concevoir des services hautement tolérant aux pannes, ce qui fait
que le jour où une véritable panne survient, elle n'a aucun impact sur la
production (enfin on espère !).

Binary file not shown.

After

Width:  |  Height:  |  Size: 61 KiB

View File

@ -0,0 +1,50 @@
---
kind: pipeline
type: docker
steps:
- name: code-analysis
image: aosapps/drone-sonar-plugin
settings:
sonar_host: http://sonarqube:9000
sonar_token:
from_secret: sonar_token
- name: build-amd64
image: golang:alpine
commands:
- apk --no-cache add git go-bindata
- go generate -v
- go get -v -d
- go build -v -o youp0m-linux-amd64
environment:
GOOS: linux
GOARCH: amd64
- name: build-arm64
image: golang:alpine
commands:
- go build -v -o youp0m-linux-arm64
environment:
GOOS: linux
GOARCH: arm64
- name: gitea_release
image: plugins/gitea-release
settings:
api_key:
from_secret: gitea_token
base_url: http://gitea:3000
files: youp0m-*
title: ${DRONE_TAG}
when:
event: tag
- name: publish docker image
image: plugins/docker
settings:
repo: registry:5000/youp0m
registry: registry:5000
insecure: true
auto_tag: true
auto_tag_suffix: ${DRONE_STAGE_OS}-${DRONE_STAGE_ARCH}

Binary file not shown.

After

Width:  |  Height:  |  Size: 41 KiB

View File

@ -0,0 +1,94 @@
\newpage
Publier une image Docker
========================
Toutes les tâches de publication peuvent s'assimiler à des tâches de
déploiement continu. C'est en particulier le cas lorsque le produit de
compilation sera simplement publié et qu'il n'y a pas de service à mettre à
jour ensuite (par exemple, dans le cas de Firefox ou de LibreOffice, une fois
testés, les paquets sont envoyés sur le serveur d'où ils seront distribués ; il
n'y a pas de service/docker à relancer).
À l'inverse, `youp0m` est à la fois un programme que l'on peut télécharger et
un service un ligne qu'il faut déployer pour mettre à jour facilement. Pour
simplifier le déploiement, nous utilisons des images Docker. Il faut cependant
les générer ...
## Mise en place du registre
*Si vous avez choisi Gitlab, vous pouvez utiliser directement le registre
Docker intégré. Si vous utilisez Gitea, continuez cette section.*
Afin de disposer de notre propre registre Docker sur lequel publier nos images,
nous allons utiliser l'image de registre fournie par Docker. Elle se lance
comme suit :
<div lang="en-US">
```bash
docker run --rm -d --name registry --network droneci -p 5000:5000 registry:2
```
</div>
Vous trouverez davantage d'informations
[ici](https://docs.docker.com/registry/deploying/).
Vous pouvez tester son bon fonctionnement avec la commande suivante :
<div lang="en-US">
```bash
42sh$ curl http://localhost:5000/v2/
{}
```
</div>
## Publication de l'image
Une fois le registre démarré, il ne nous reste plus qu'à ajouter une étape de
publication de l'image Docker. Cela se fait au moyen du plugin suivant :
<http://plugins.drone.io/drone-plugins/drone-docker/>.
Sans plus de configuration, le registre que nous avons démarré
n'attend pas d'authentification. Et comme il n'a pas de certificat TLS
pour utiliser `https`, il est nécessaire de définir l'option
`insecure` à `true`.
## Test de l'image
Sur l'hôte, nous pouvons tester que l'image a bien été publiée grâce à la
commande suivante :
<div lang="en-US">
```bash
docker run --rm -p 8080:8080 localhost:5000/youp0m
```
</div>
On notera que ceci est possible exclusivement parce que le registre
`localhost:5000` est considéré non-sûr par défaut. C'est à dire qu'il n'a pas
besoin de certificat TLS sur sa connexion HTTP pour être utilisé.\newline
Si on avait dû utiliser un autre nom de domaine, il aurait fallu
[l'ajouter à la liste des
`insecure-registries`](https://docs.docker.com/registry/insecure/).
## Suite du déploiement
Pour aujourd'hui, nous en resterons là pour le déploiement, car nous n'avons
pas d'environnement de production sur lequel déployer notre service.
Vous pouvez néamnoins tester les plugins
[`scp`](http://plugins.drone.io/appleboy/drone-scp/) ou
[`ansible`](http://plugins.drone.io/drone-plugins/drone-ansible/), si vous avez
une machine virtuelle avec une connexion SSH. N'hésitez pas à l'ajouter à votre
`.droneci.yml`.
## Profitons !
Sonarqube a repéré quelques erreurs dans le code de `youp0m`, essayez de les
corriger, et publiez une nouvelle version, pour observer toute la chaîne en
action !

Binary file not shown.

After

Width:  |  Height:  |  Size: 41 KiB

197
tutorial/devops/tools.md Normal file
View File

@ -0,0 +1,197 @@
\newpage
Les bons outils
===============
## Gestionnaire de versions
Avant de pouvoir commencer notre aventure, il est nécessaire d'avoir un
gestionnaire de versions. Nous allons ici utiliser Git.
### Problématique du stockage des produits de compilation
Outre les interfaces rudimentaires fournies au dessus de Git
([gitweb](https://git.wiki.kernel.org/index.php/Gitweb)), il y a de nombreux
projets qui offrent davantage que le simple hébergement de dépôts. Vous pouvez
voir sur GitHub notamment qu'il est possible d'attacher à un tag un [certain
nombre de fichiers](https://github.com/docker/compose/releases/latest).
On notera également que depuis le 1er septembre, GitHub propose un [registre
Docker](https://github.blog/2020-09-01-introducing-github-container-registry/)
que l'on peut lier avec ses dépôts. Une fonctionnalité que GitLab propose
[depuis
2016](https://about.gitlab.com/blog/2016/05/23/gitlab-container-registry/).
En effet, la problématique du stockage des produits de compilation est
vaste. Si au début on peut se satisfaire d'un simple serveur web/FTP/SSH pour
les récupérer manuellement, on a vite envie de pouvoir utiliser les outils
standards directement : `docker pull ...`, `npm install ...`, ...
Des programmes et services se sont spécialisés là dedans, citons notamment
[Artifactory](https://jfrog.com/artifactory/) ou [Nexus
Repository](https://www.sonatype.com/nexus/repository-oss) et bien d'autres.
Dans la première partie du TP, nous allons nous contenter de publier un binaire
associé à un tag de notre projet.
### Installation et configuration
Aller c'est parti ! première chose à faire : installer et configurer
[Gitea](https://gitea.io/) (ceux qui le souhaitent peuvent choisir
[gitlab](https://gitlab.org/) ou une autre plate-forme, mais la suite du TP
sera moins guidée pour eux).
Nous allons utiliser l'image : <https://hub.docker.com/r/gitea/gitea>.
Votre playbook resemblera à quelque chose comme ça :
<div lang="en-US">
```yaml
- name: Launch gitea container
docker_container:
name: gitea
image: "gitea/gitea:{{ version }}"
volumes:
- /var/lib/gitea:/data
- /etc/localtime:/etc/localtime:ro
- /etc/timezone:/etc/timezone:ro
state: started
restart_policy: unless-stopped
memory: 1G
memory_swap: 1G
networks:
- name: gitea
published_ports:
- "2222:22"
- "3000:3000"
env:
RUN_MODE: "prod"
DOMAIN: "gitea"
SSH_DOMAIN: "gitea"
INSTALL_LOCK: "true"
SECRET_KEY: "{{ secret_key }}"
```
</div>
Plus d'infos sur cette page : <https://docs.gitea.io/en-us/install-with-docker/>.
Une fois le conteneur lancé, vous pouvez accéder à l'interface de gitea sur le
port 3000 de votre machine (à moins que vous n'ayez opté pour un autre port).
Vous pouvez ajouter un nouvel administrateur avec la commande suivante :
<div lang="en-US">
```bash
docker exec gitea gitea admin user create --username "${USER}" --random-password \
--must-change-password=false --admin --email "${USER}@epita.fr"
```
</div>
Notez le mot de passe généré pour [vous y connecter](http://localhost:3000/user/login).
## Logiciel d'intégration continue
De nombreuses solutions sont disponibles sur Internet, la plupart du temps
gratuite pour les projets libres ([Travis CI](https://travis-ci.org/),
[CircleCI](https://circleci.com/), ...).
Mais nous allons déployer notre propre solution, en utilisant [Drone
CI](https://drone.io/). C'est une solution d'intégration continue libre et
moderne, conçue tout autour de Docker. Idéale pour nous !
### Interface de contrôle et de dispatch des tâches
La documentation du projet est extrêmement bien faite, suivons la marche à
suivre pour [relier Gitea à
Drone](https://docs.drone.io/server/provider/gitea/).
L'URL de redirection sera dans notre cas : `http://droneci/login`.
Voici à quoi pourrait ressemble le playbook Ansible démarrant notre conteneur
Drone :
<div lang="en-US">
```yaml
- name: Launch drone container
docker_container:
name: droneci
image: drone/drone:1
volumes:
- /var/lib/drone:/data
state: started
restart_policy: unless-stopped
memory: 1G
memory_swap: 1G
networks:
- name: drone
- name: gitea
published_ports:
- "80:80"
env:
DRONE_GITEA_CLIENT_ID: "{{ client.id }}"
DRONE_GITEA_CLIENT_SECRET: "{{ client.secret }}"
DRONE_GITEA_SERVER: "http://gitea:3000"
DRONE_RPC_SECRET: "{{ shared_secret }}"
DRONE_SERVER_HOST: "droneci"
DRONE_SERVER_PROTO: "http"
```
</div>
Une fois lancé, rendez-vous sur l'interface de DroneCI : <http://droneci/>
Vous serez automatiquement redirigé vers la page d'authentification de Gitea,
puis vers l'autorisation OAuth d'accès de Drone à Gitea. Il faut bien
évidemment valider cette demande, afin que Drone ait accès à nos dépôts.
![OAuth Drone](../devops/oauth-drone.png){width=9cm}
### *Runner*
Notre conteneur `droneci` est uniquement une interface graphique qui va
centraliser d'un côté les nouveaux commits à traiter, et de l'autre les
résultats retournés par les agents chargés d'exécuter le code.
Il serait impensable d'exécuter arbitrairement du code en parallèle d'une
application privilégiée (ici, notre conteneur `droneci` a accès aux dépôts
potentiellement privés de Gitea). Les agents qui sont amenés à traiter du code
arbitraire s'exécutent à part et peuvent être de différents types. Dans le
vocabulaire de Drone, on les appelle des ~~blade~~*runners*.
Nous allons lancer un *runner* Docker : il s'agit d'un type d'agent qui va
exécuter nos étapes de compilation dans des conteneurs Docker (oui, quand on
disait que Drone était conçu autour de Docker, c'était pas pour rire !)
Voici à quoi pourrait ressemble le playbook Ansible démarrant notre agent Drone :
<div lang="en-US">
```yaml
- name: Launch drone runer
docker_container:
name: droneci-runner
image: "drone/drone-runner-docker:1"
volumes:
- /var/run/docker.sock:/var/run/docker.sock
state: started
restart_policy: unless-stopped
memory: 2G
memory_swap: 2G
networks:
- drone
env:
DRONE_RPC_PROTO: "http"
DRONE_RPC_HOST: "droneci"
DRONE_RPC_SECRET: "{{ shared_secret }}"
DRONE_RUNNER_CAPACITY: 2
DRONE_RUNNER_NAME: "my-runner"
DRONE_RUNNER_NETWORKS: "drone,gitea"
```
</div>
L'environnement étant prêt, il ne reste plus qu'à nous lancer dans nos projets !

63
tutorial/devops/what.md Normal file
View File

@ -0,0 +1,63 @@
\newpage
But du TP
=========
Nous allons nous mettre aujourd'hui dans la peau d'une équipe DevOps et
réaliser une solution complète de intégration/déploiement continu (le fameux
CI/CD, pour *Continuous Integration* et *Continuous Delivery*).
Le résultat attendu d'ici la fin du TP sera de mettre en place toutes les
briques décrite dans la section précédente.
\newline
Nous allons commencer par automatiser le projet `youp0m`, plus simple, puis la
plate-forme du FIC dans son ensemble, ce qui représente un petit challenge.
Il est également attendu que vous rendiez un playbook Ansible, permettant de
retrouver un environnement similaire. Car on se reservira de cette installation
dans un prochain TP.
\newline
Dans un premier temps, on voudra juste compiler notre projet, pour s'assurer
que chaque commit poussé ne contient pas d'erreur de compilation, dans
l'environnement défini comme étant celui de production. Ensuite, on ajoutera
quelques tests automatiques. Puis nous publierons automatiquement le binaire
`youp0m` comme fichier associé à un tag au sein de l'interface web du
gestionnaire de versions.
Enfin, nous mettrons en place un registre Docker qui nous permettra de publier
automatiquement l'image Docker assocciée. C'est à partir de cette image Docker
que l'on va commencer à déployer automatiquement...
## Préparer le terrain
Tous les déploiements sont à faire sur votre machine en utilisant des
conteneurs Docker, qui seront regroupés au sein de réseaux Docker. Cela vous
permettra d'utiliser la résolution de noms entre vos conteneurs.
Dans votre playbook Ansible, vous pourrez procéder ainsi :
<div lang="en-US">
```yaml
- name: Create virli network
docker_network:
name: virli3
```
</div>
Étant donné que votre machine ne dispose pas de domaine sur Internet et que
l'on va essayer de simplifier au maximum l'installation, vous devriez ajouter
cette ligne à votre fichier `/etc/hosts` :
<div lang="en-US">
```conf
127.0.0.1 gitea droneci
```
</div>
Cette ligne va vous permettre de résoudre les noms des conteneurs. Cela
permettra aux requêtes OAuth de se faire de manière transparente pour vous
lorsque vous serez dans votre navigateur.

View File

@ -0,0 +1,48 @@
\newpage
Exercice
========
Pour mettre en pratiques toutes les notions que l'on a vu jusque là, écrivez un
script `mycloud-run.sh` pour automatiser le lancement de votre instance
personnelle de [`nextcloud`](https://hub.docker.com/_/nextcloud/) ou
d'[`owncloud`](https://hub.docker.com/r/owncloud/server/). Une attention
particulière devra être apportée à la manière dont vous gérerez le rappel du
script pour éventuellement relancer un conteneur qui se serait arrêté
(évidemment sans perdre les données).
À la fin de son exécution, le script affichera un lien utilisable sur l'hôte
pour se rendre sur la page de connexion. Une autre machine de votre réseau
local devrait également pouvoir accéder à la plate-forme, simplement en
renseignant l'IP de votre machine et en ajoutant éventuellement des règles de
pare-feu (mais cette dernière partie n'est pas demandée, gardez simplement en
tête que cela doit pouvoir être fait manuellement au cas par cas : sur une
machine sans pare-feu configurée, cela ne demande pas d'étape supplémentaire).
Votre script devra se limiter aux notions vues durant cette partie du TP
(ie. sans utiliser `docker-compose` ou `docker stack` que l'on verra dans la
seconde partie). Il pourra cependant faire usage des commandes `docker OBJECT
inspect` pour ne pas avoir à faire d'analyse syntaxique sur les retours des
commandes lisibles par les humains.
Cette instance devra utiliser une base de données MySQL (lancée par vos soins
dans un autre conteneur) et contenir ses données dans un ou plusieurs volumes
(afin qu'elles persistent à une mise à jour des conteneurs par exemple).
L'exécution doit être la plus sécurisée possible (pas de port MySQL exposé sur
l'hôte par exemple, etc.) et la plus respectueuse des bonnes pratiques que l'on
a pu voir durant ce premier cours.
### Exemple d'exécution
<div lang="en-US">
```bash
42sh$ ./mycloud-run.sh
http://localhost:12345/
42sh$ #docker kill db
42sh$ ./mycloud-run.sh # le script relancera une base de données,
# sans avoir perdu les données
http://localhost:12345/
```
</div>

View File

@ -1,6 +1,6 @@
include ../pandoc-opts.mk
SOURCES = tutorial.md clair.md oci.md registry.md runc.md linuxkit.md rendu.md
SOURCES = tutorial.md oci.md runc.md linuxkit.md rendu.md
all: tutorial.pdf

View File

@ -7,7 +7,7 @@ Registres
* * * * *
Dans cette partie, nous allons appréhender le fonctionnement d'un registre OCI,
Nous allons appréhender le fonctionnement d'un registre OCI,
et préparer le *rootfs* d'une image de base (Debian, Ubuntu, hello, ...) : en
nous préoccupant simplement de la couche la plus basse (qui ne contient pas de
modification ou de suppression : chaque fichier est normal).

View File

@ -30,14 +30,11 @@ cela dépendra de votre avancée dans le projet) :
<div lang="en-US">
```
login_x-TP5/
login_x-TP5/docker-compose.yml # 1. Clair
login_x-TP5/clair_config/config.yaml
login_x-TP5/nginx:mainline.html # rapport d'analyse PAclair
login_x-TP5/registry_play.sh # 3. Registre
login_x-TP5/config.json # 4. runc
login_x-TP5/... # + scripts éventuels
login_x-TP5/vault.yml # 5. LinuxKit
login_x-TP5/pkg/...
login_x-OCI/
login_x-OCI/registry_play.sh # 0. Registre
login_x-OCI/config.json # 2. runc
login_x-OCI/... # + scripts éventuels
login_x-OCI/vault.yml # 3. LinuxKit
login_x-OCI/pkg/...
```
</div>

View File

@ -22,15 +22,15 @@ essayer de lancer un shell `alpine` avec un volume dans notre home.
Vous devriez avoir le binaire `runc` ou `docker-runc`. Si ce n'est pas le cas,
vous pouvez télécharger la dernière version :
<https://github.com/opencontainers/runc/releases>. La 1.0.0-rc9 est Ok.
<https://github.com/opencontainers/runc/releases>. La 1.0.0-rc92 est Ok.
## Extraction du rootfs
À l'aide du script réalisé dans la partie précédentes, extrayons le rootfs
d'alpine : `library/alpine` dans le registre Docker.
À l'aide du script d'extraction de registre réalisé dans le TP 3, extrayons le
rootfs d'alpine : `library/alpine` dans le registre Docker.
Si vous n'avez pas eu le temps de terminer l'exercice précédent, vous pouvez
Si vous n'avez pas eu le temps de terminer le script d'extraction, vous pouvez
utiliser :
<div lang="en-US">

View File

@ -1,23 +1,24 @@
---
title: Virtualisation légère -- TP n^o^ 5
subtitle: Docker Internals
title: Virtualisation légère -- TP n^o^ 3
subtitle: Les projets de l'Open Container Initiative
author: Pierre-Olivier *nemunaire* [Mercier]{.smallcaps}
institute: EPITA
date: Mercredi 14 novembre 2018
date: Mercredi 28 octobre 2020
abstract: |
Dans ce cinquième du TP, nous allons entrer dans les sous-bassements de
Docker !
Après avoir beaucoup parlé de Docker, nous allons voir dans ce TP la
manière dont les différents projets qu'il utilise dans sa plomberie
interne interagissent.
\vspace{1em}
Tous les éléments de ce TP (exercices et projet) sont à rendre à
<virli@nemunai.re> au plus tard le dimanche 25 novembre 2018 à 23
Les éléments de ce TP constituent du contenu bonus que vous pouvez rendre à
<virli@nemunai.re> au plus tard le dimanche 22 novembre 2020 à 23
h 42. Consultez la dernière section de chaque partie pour plus d'information
sur les éléments à rendre.
En tant que personnes sensibilisées à la sécurité des échanges électroniques,
vous devrez m'envoyer vos rendus signés avec votre clef PGP. Pensez à
[me](https://pgp.mit.edu/pks/lookup?op=vindex&search=0x842807A84573CC96)
faire signer votre clef et n'hésitez pas à [faire signer votre
clef](https://www.meetup.com/fr/Paris-certification-de-cles-PGP-et-CAcert/).
[me](https://keys.openpgp.org/search?q=nemunaire%40nemunai.re) faire signer
votre clef et n'hésitez pas à [faire signer la
votre](https://www.meetup.com/fr/Paris-certification-de-cles-PGP-et-CAcert/).
...

Binary file not shown.

After

Width:  |  Height:  |  Size: 69 KiB

View File

@ -49,7 +49,8 @@ docker container run -it my_editor /bin/bash
## `RUN` dans le `Dockerfile`
Dans un `Dockerfile`, chaque ligne est exécutée indépendamment des autres et
correspondra à une nouvelle couche de notre image.
correspondra à une nouvelle couche de notre image. Exactement comme on a
réalisé le script dans la partie précédente.
Cela signifie que l'exemple suivant **ne fonctionne pas** :
@ -312,7 +313,7 @@ Pour réaliser ce genre de contribution, on ajoute généralement un `Dockerfile
à la racine du dépôt.
Vous pouvez cloner le dépôts de sources de `youp0m` à :
<https://git.nemunai.re/youp0m.git>
<https://gitea.nemunai.re/nemunaire/youp0m.git>
Pour compiler le projet, vous pouvez utiliser dans votre `Dockerfile`

View File

@ -22,7 +22,7 @@ Ce fichier fonctionne de la même manière que le `.gitignore` : vous pouvez
utiliser du globing.
Pour plus d'informations, vous pouvez consulter la documentation accessible à
<https://docs.docker.com/reference/builder/#dockerignore-file>.
<https://docs.docker.com/engine/reference/builder/#dockerignore-file>.
## N'installez rien de superflu

View File

@ -71,3 +71,27 @@ docker container run -it my_nano /bin/bash
Vous constatez cette fois que vous pouvez lancer `nano`, alors que vous ne
pouvez toujours pas le faire dans un conteneur issu d'une image `ubuntu` !
## Scripté ?
On peut automatiser les étapes ci-dessus avec un script qui ressemblerait à ça :
<div lang="en-US">
```bash
docker container run ubuntu apt-get update
docker container commit $(docker container ls -lq) my_nano_step-1
docker container run my_nano_step-1 apt-get install nano
docker container commit $(docker container ls -lq) my_nano
```
</div>
On obtiendra de la même manière notre image `my_nano` :
<div lang="en-US">
```bash
docker container run -it my_nano /bin/bash
```
</div>
Contenant notre éditeur de texte favori.

View File

@ -0,0 +1,6 @@
\newpage
Développer avec Docker
======================
Ajouter une feature dans le front web. Via docker run -v