diff --git a/tutorial/2/Makefile b/tutorial/2/Makefile index c52c4a3..97e271d 100644 --- a/tutorial/2/Makefile +++ b/tutorial/2/Makefile @@ -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 diff --git a/tutorial/2/rendu.md b/tutorial/2/rendu.md index 5c32640..f85725b 100644 --- a/tutorial/2/rendu.md +++ b/tutorial/2/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 diff --git a/tutorial/2/tutorial.md b/tutorial/2/tutorial.md index 467c7e4..ae399b0 100644 --- a/tutorial/2/tutorial.md +++ b/tutorial/2/tutorial.md @@ -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 à - 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. + 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/). ... diff --git a/tutorial/3/Makefile b/tutorial/3/Makefile index a085943..55a995b 100644 --- a/tutorial/3/Makefile +++ b/tutorial/3/Makefile @@ -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 diff --git a/tutorial/3/project-rendu.md b/tutorial/3/project-rendu.md deleted file mode 100644 index aa55d9b..0000000 --- a/tutorial/3/project-rendu.md +++ /dev/null @@ -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 , 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) : - -
-``` -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 -``` -
- -Les premières étapes du projet ne sont pas à rendre et feront l'objet -d'un rendu à part. diff --git a/tutorial/3/rendu.md b/tutorial/3/rendu.md new file mode 100644 index 0000000..e11ac4d --- /dev/null +++ b/tutorial/3/rendu.md @@ -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 , 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) : + +
+``` +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 +``` +
diff --git a/tutorial/3/tutorial.md b/tutorial/3/tutorial.md index e48130e..299f052 100644 --- a/tutorial/3/tutorial.md +++ b/tutorial/3/tutorial.md @@ -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 à 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 à + 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/). ... diff --git a/tutorial/4/Makefile b/tutorial/4/Makefile index 1002ae8..a085943 100644 --- a/tutorial/4/Makefile +++ b/tutorial/4/Makefile @@ -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:: diff --git a/tutorial/3/capabilities.md b/tutorial/4/capabilities.md similarity index 100% rename from tutorial/3/capabilities.md rename to tutorial/4/capabilities.md diff --git a/tutorial/3/cgroups.md b/tutorial/4/cgroups.md similarity index 100% rename from tutorial/3/cgroups.md rename to tutorial/4/cgroups.md diff --git a/tutorial/3/check.sh b/tutorial/4/check.sh similarity index 100% rename from tutorial/3/check.sh rename to tutorial/4/check.sh diff --git a/tutorial/3/chroot.md b/tutorial/4/chroot.md similarity index 100% rename from tutorial/3/chroot.md rename to tutorial/4/chroot.md diff --git a/tutorial/3/installation.md b/tutorial/4/installation.md similarity index 100% rename from tutorial/3/installation.md rename to tutorial/4/installation.md diff --git a/tutorial/3/oom.md b/tutorial/4/oom.md similarity index 100% rename from tutorial/3/oom.md rename to tutorial/4/oom.md diff --git a/tutorial/3/project-body.md b/tutorial/4/project-body.md similarity index 100% rename from tutorial/3/project-body.md rename to tutorial/4/project-body.md diff --git a/tutorial/4/project-intro.md b/tutorial/4/project-intro.md index e4a3175..1d46c98 100644 --- a/tutorial/4/project-intro.md +++ b/tutorial/4/project-intro.md @@ -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. diff --git a/tutorial/4/project-rendu.md b/tutorial/4/project-rendu.md index 3af9fc5..aa55d9b 100644 --- a/tutorial/4/project-rendu.md +++ b/tutorial/4/project-rendu.md @@ -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 . C'est donc à cette adresse +Ce service écoute sur l'adresse , 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) :
``` -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 ```
+ +Les premières étapes du projet ne sont pas à rendre et feront l'objet +d'un rendu à part. diff --git a/tutorial/3/pseudofs.md b/tutorial/4/pseudofs.md similarity index 100% rename from tutorial/3/pseudofs.md rename to tutorial/4/pseudofs.md diff --git a/tutorial/3/seccomp.md b/tutorial/4/seccomp.md similarity index 100% rename from tutorial/3/seccomp.md rename to tutorial/4/seccomp.md diff --git a/tutorial/4/tutorial.md b/tutorial/4/tutorial.md index d119d99..e48130e 100644 --- a/tutorial/4/tutorial.md +++ b/tutorial/4/tutorial.md @@ -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 à au - plus tard le mercredi 20 novembre 2017 à 13 h 42. + Certains éléments de ce TP sont à rendre à 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 diff --git a/tutorial/3/tutorial.tex b/tutorial/4/tutorial.tex similarity index 100% rename from tutorial/3/tutorial.tex rename to tutorial/4/tutorial.tex diff --git a/tutorial/5/Makefile b/tutorial/5/Makefile new file mode 100644 index 0000000..1002ae8 --- /dev/null +++ b/tutorial/5/Makefile @@ -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 diff --git a/tutorial/4/cmpns.md b/tutorial/5/cmpns.md similarity index 100% rename from tutorial/4/cmpns.md rename to tutorial/5/cmpns.md diff --git a/tutorial/4/docker-exec.md b/tutorial/5/docker-exec.md similarity index 100% rename from tutorial/4/docker-exec.md rename to tutorial/5/docker-exec.md diff --git a/tutorial/4/lesson.md b/tutorial/5/lesson.md similarity index 100% rename from tutorial/4/lesson.md rename to tutorial/5/lesson.md diff --git a/tutorial/4/mount.md b/tutorial/5/mount.md similarity index 100% rename from tutorial/4/mount.md rename to tutorial/5/mount.md diff --git a/tutorial/4/mountns.md b/tutorial/5/mountns.md similarity index 100% rename from tutorial/4/mountns.md rename to tutorial/5/mountns.md diff --git a/tutorial/4/namespaces.md b/tutorial/5/namespaces.md similarity index 100% rename from tutorial/4/namespaces.md rename to tutorial/5/namespaces.md diff --git a/tutorial/4/networkns.md b/tutorial/5/networkns.md similarity index 100% rename from tutorial/4/networkns.md rename to tutorial/5/networkns.md diff --git a/tutorial/4/pidns.md b/tutorial/5/pidns.md similarity index 100% rename from tutorial/4/pidns.md rename to tutorial/5/pidns.md diff --git a/tutorial/3/project-intro.md b/tutorial/5/project-intro.md similarity index 59% rename from tutorial/3/project-intro.md rename to tutorial/5/project-intro.md index 1d46c98..e4a3175 100644 --- a/tutorial/3/project-intro.md +++ b/tutorial/5/project-intro.md @@ -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. diff --git a/tutorial/5/project-rendu.md b/tutorial/5/project-rendu.md new file mode 100644 index 0000000..3af9fc5 --- /dev/null +++ b/tutorial/5/project-rendu.md @@ -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 . 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: + +
+``` +login_x-mymoulette/README +login_x-mymoulette/... +``` +
diff --git a/tutorial/4/rendu.md b/tutorial/5/rendu.md similarity index 100% rename from tutorial/4/rendu.md rename to tutorial/5/rendu.md diff --git a/tutorial/4/setup.md b/tutorial/5/setup.md similarity index 100% rename from tutorial/4/setup.md rename to tutorial/5/setup.md diff --git a/tutorial/5/tutorial.md b/tutorial/5/tutorial.md new file mode 100644 index 0000000..d119d99 --- /dev/null +++ b/tutorial/5/tutorial.md @@ -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 à 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/). +... diff --git a/tutorial/4/userns.md b/tutorial/5/userns.md similarity index 100% rename from tutorial/4/userns.md rename to tutorial/5/userns.md diff --git a/tutorial/devops/cd.md b/tutorial/devops/cd.md new file mode 100644 index 0000000..0a73e0a --- /dev/null +++ b/tutorial/devops/cd.md @@ -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 ? diff --git a/tutorial/devops/ci.md b/tutorial/devops/ci.md new file mode 100644 index 0000000..c912706 --- /dev/null +++ b/tutorial/devops/ci.md @@ -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 !) : + +
+```bash +docker run --rm -d --name sonarqube --network drone -p 9000:9000 sonarqube +``` +
+ +Le service met un bon moment avant de démarrer, dès qu'il se sera initialisé, +nous pourrons accéder à l'interface sur . + +En attendant qu'il démarre, nous pouvons commencer à ajouter le nécessaire à +notre `.drone.yml` : . + +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 + 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 : + + - + - + +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 : +. + +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`. diff --git a/tutorial/devops/devops.md b/tutorial/devops/devops.md new file mode 100644 index 0000000..cb97170 --- /dev/null +++ b/tutorial/devops/devops.md @@ -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 !). diff --git a/tutorial/devops/drone-run.png b/tutorial/devops/drone-run.png new file mode 100644 index 0000000..7a6918b Binary files /dev/null and b/tutorial/devops/drone-run.png differ diff --git a/tutorial/devops/drone-youp0m.yml b/tutorial/devops/drone-youp0m.yml new file mode 100644 index 0000000..6df5394 --- /dev/null +++ b/tutorial/devops/drone-youp0m.yml @@ -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} diff --git a/tutorial/devops/oauth-drone.png b/tutorial/devops/oauth-drone.png new file mode 100644 index 0000000..1857c41 Binary files /dev/null and b/tutorial/devops/oauth-drone.png differ diff --git a/tutorial/devops/publish-docker.md b/tutorial/devops/publish-docker.md new file mode 100644 index 0000000..e80f949 --- /dev/null +++ b/tutorial/devops/publish-docker.md @@ -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 : + +
+```bash +docker run --rm -d --name registry --network droneci -p 5000:5000 registry:2 +``` +
+ +Vous trouverez davantage d'informations +[ici](https://docs.docker.com/registry/deploying/). + +Vous pouvez tester son bon fonctionnement avec la commande suivante : + +
+```bash +42sh$ curl http://localhost:5000/v2/ +{} +``` +
+ + +## 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 : +. + +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 : + +
+```bash +docker run --rm -p 8080:8080 localhost:5000/youp0m +``` +
+ +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 ! diff --git a/tutorial/devops/tag-released.png b/tutorial/devops/tag-released.png new file mode 100644 index 0000000..3f60694 Binary files /dev/null and b/tutorial/devops/tag-released.png differ diff --git a/tutorial/devops/tools.md b/tutorial/devops/tools.md new file mode 100644 index 0000000..fe1d7f7 --- /dev/null +++ b/tutorial/devops/tools.md @@ -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 : . + +Votre playbook resemblera à quelque chose comme ça : + +
+```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 }}" +``` +
+ +Plus d'infos sur cette page : . + +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 : + +
+```bash +docker exec gitea gitea admin user create --username "${USER}" --random-password \ + --must-change-password=false --admin --email "${USER}@epita.fr" +``` +
+ +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 : + +
+```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" +``` +
+ +Une fois lancé, rendez-vous sur l'interface de 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 : + +
+```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" +``` +
+ + +L'environnement étant prêt, il ne reste plus qu'à nous lancer dans nos projets ! diff --git a/tutorial/devops/what.md b/tutorial/devops/what.md new file mode 100644 index 0000000..387a614 --- /dev/null +++ b/tutorial/devops/what.md @@ -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 : + +
+```yaml +- name: Create virli network + docker_network: + name: virli3 +``` +
+ + +É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` : + +
+```conf +127.0.0.1 gitea droneci +``` +
+ +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. diff --git a/tutorial/docker-basis/ex-owncloud.md b/tutorial/docker-basis/ex-owncloud.md new file mode 100644 index 0000000..ebaee74 --- /dev/null +++ b/tutorial/docker-basis/ex-owncloud.md @@ -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 + +
+```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/ +``` +
diff --git a/tutorial/docker-internals/Makefile b/tutorial/docker-internals/Makefile index 20b1510..e4deb39 100644 --- a/tutorial/docker-internals/Makefile +++ b/tutorial/docker-internals/Makefile @@ -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 diff --git a/tutorial/docker-internals/registry.md b/tutorial/docker-internals/registry.md index c19c882..1417575 100644 --- a/tutorial/docker-internals/registry.md +++ b/tutorial/docker-internals/registry.md @@ -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). diff --git a/tutorial/docker-internals/rendu.md b/tutorial/docker-internals/rendu.md index c81b4ee..97675fb 100644 --- a/tutorial/docker-internals/rendu.md +++ b/tutorial/docker-internals/rendu.md @@ -30,14 +30,11 @@ cela dépendra de votre avancée dans le projet) :
``` -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/... ```
diff --git a/tutorial/docker-internals/runc.md b/tutorial/docker-internals/runc.md index 0d45d3e..d61fd84 100644 --- a/tutorial/docker-internals/runc.md +++ b/tutorial/docker-internals/runc.md @@ -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 : -. La 1.0.0-rc9 est Ok. +. 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 :
diff --git a/tutorial/docker-internals/tutorial.md b/tutorial/docker-internals/tutorial.md index b8b4a69..af0d112 100644 --- a/tutorial/docker-internals/tutorial.md +++ b/tutorial/docker-internals/tutorial.md @@ -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 à - au plus tard le dimanche 25 novembre 2018 à 23 + Les éléments de ce TP constituent du contenu bonus que vous pouvez rendre à + 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/). ... diff --git a/tutorial/dockerfiles/commit.png b/tutorial/dockerfiles/commit.png new file mode 100644 index 0000000..eb3d307 Binary files /dev/null and b/tutorial/dockerfiles/commit.png differ diff --git a/tutorial/dockerfiles/dockerfile.md b/tutorial/dockerfiles/dockerfile.md index cad186a..b415941 100644 --- a/tutorial/dockerfiles/dockerfile.md +++ b/tutorial/dockerfiles/dockerfile.md @@ -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` à : - + Pour compiler le projet, vous pouvez utiliser dans votre `Dockerfile` diff --git a/tutorial/dockerfiles/goodpractices.md b/tutorial/dockerfiles/goodpractices.md index 833a467..bd4ea48 100644 --- a/tutorial/dockerfiles/goodpractices.md +++ b/tutorial/dockerfiles/goodpractices.md @@ -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 à -. +. ## N'installez rien de superflu diff --git a/tutorial/dockerfiles/interactive.md b/tutorial/dockerfiles/interactive.md index 3480d58..502e3d5 100644 --- a/tutorial/dockerfiles/interactive.md +++ b/tutorial/dockerfiles/interactive.md @@ -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 : + +
+```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 +``` +
+ +On obtiendra de la même manière notre image `my_nano` : + +
+```bash +docker container run -it my_nano /bin/bash +``` +
+ +Contenant notre éditeur de texte favori. diff --git a/tutorial/dockerfiles/working-with.md b/tutorial/dockerfiles/working-with.md new file mode 100644 index 0000000..4d2a891 --- /dev/null +++ b/tutorial/dockerfiles/working-with.md @@ -0,0 +1,6 @@ +\newpage + +Développer avec Docker +====================== + +Ajouter une feature dans le front web. Via docker run -v