New tuto 3 done
This commit is contained in:
parent
5f4880dc50
commit
ba77aca73b
@ -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
|
||||
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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/).
|
||||
...
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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
49
tutorial/3/rendu.md
Normal 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>
|
||||
@ -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/).
|
||||
...
|
||||
|
||||
@ -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::
|
||||
|
||||
@ -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.
|
||||
|
||||
@ -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.
|
||||
|
||||
@ -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
12
tutorial/5/Makefile
Normal 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
|
||||
@ -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.
|
||||
32
tutorial/5/project-rendu.md
Normal file
32
tutorial/5/project-rendu.md
Normal 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
24
tutorial/5/tutorial.md
Normal 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
6
tutorial/devops/cd.md
Normal 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
118
tutorial/devops/ci.md
Normal 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 !
|
||||
|
||||
{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 !
|
||||
|
||||
{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
196
tutorial/devops/devops.md
Normal 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 !).
|
||||
BIN
tutorial/devops/drone-run.png
Normal file
BIN
tutorial/devops/drone-run.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 61 KiB |
50
tutorial/devops/drone-youp0m.yml
Normal file
50
tutorial/devops/drone-youp0m.yml
Normal 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}
|
||||
BIN
tutorial/devops/oauth-drone.png
Normal file
BIN
tutorial/devops/oauth-drone.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 41 KiB |
94
tutorial/devops/publish-docker.md
Normal file
94
tutorial/devops/publish-docker.md
Normal 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 !
|
||||
BIN
tutorial/devops/tag-released.png
Normal file
BIN
tutorial/devops/tag-released.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 41 KiB |
197
tutorial/devops/tools.md
Normal file
197
tutorial/devops/tools.md
Normal 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.
|
||||
|
||||
{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
63
tutorial/devops/what.md
Normal 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.
|
||||
48
tutorial/docker-basis/ex-owncloud.md
Normal file
48
tutorial/docker-basis/ex-owncloud.md
Normal 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>
|
||||
@ -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
|
||||
|
||||
@ -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).
|
||||
|
||||
@ -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>
|
||||
|
||||
@ -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">
|
||||
|
||||
@ -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/).
|
||||
...
|
||||
|
||||
BIN
tutorial/dockerfiles/commit.png
Normal file
BIN
tutorial/dockerfiles/commit.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 69 KiB |
@ -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`
|
||||
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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.
|
||||
|
||||
6
tutorial/dockerfiles/working-with.md
Normal file
6
tutorial/dockerfiles/working-with.md
Normal file
@ -0,0 +1,6 @@
|
||||
\newpage
|
||||
|
||||
Développer avec Docker
|
||||
======================
|
||||
|
||||
Ajouter une feature dans le front web. Via docker run -v
|
||||
Loading…
Reference in New Issue
Block a user