diff --git a/tutorial/5/Makefile b/tutorial/5/Makefile index 8269e42..7fcd0c9 100644 --- a/tutorial/5/Makefile +++ b/tutorial/5/Makefile @@ -18,6 +18,7 @@ SOURCES_SRS = tutorial-srs.md \ ../devops/tools-end.md \ ../devops/ci.md \ ../devops/publish-docker.md \ + ../devops/renovate.md ../devops/renovate-ansible.md ../devops/renovate-end.md \ rendu-srs.md SOURCES_GISTRE = tutorial-gistre.md \ diff --git a/tutorial/5/rendu-srs.md b/tutorial/5/rendu-srs.md index c46adc8..43b08ce 100644 --- a/tutorial/5/rendu-srs.md +++ b/tutorial/5/rendu-srs.md @@ -29,7 +29,8 @@ Voici une arborescence type (vous pourriez avoir des fichiers supplémentaires) ./youp0m/Dockerfile ./youp0m/entrypoint.sh ./youp0m/.dockerignore -./youp0m/... +./youp0m/renovate.json +./youp0m/... # Seuls les fichiers modifiés du dépôt original sont attendus ``` diff --git a/tutorial/5/renovatebot-pr.png b/tutorial/5/renovatebot-pr.png new file mode 120000 index 0000000..0add174 --- /dev/null +++ b/tutorial/5/renovatebot-pr.png @@ -0,0 +1 @@ +../devops/renovatebot-pr.png \ No newline at end of file diff --git a/tutorial/5/tutorial-gistre.md b/tutorial/5/tutorial-gistre.md index 73ab0a2..3328f24 100644 --- a/tutorial/5/tutorial-gistre.md +++ b/tutorial/5/tutorial-gistre.md @@ -1,33 +1,17 @@ --- -title: Virtualisation légère -- TP n^o^ 5 -subtitle: "Application des conteneurs : tests et intégration continue" +title: Virtualisation légère -- TP n^o^ 6 +subtitle: DevOps, intégration et déploiement continu author: Pierre-Olivier *nemunaire* [Mercier]{.smallcaps} institute: EPITA -date: Jeudi 4 novembre 2021 +date: Jeudi 1^er^ décembre 2022 abstract: | - Durant ce nouveau TP, appréhenderons l'intégration continue et nous - plongerons dans l'IoT pour trouver une solution innovante à des problèmes de - déploiement ! + Durant ce nouveau TP, nous allons jouer les DevOps et déployer + automatiquement des services ! \vspace{1em} - Que ce soit pour le TP ou les questions de cours, vous êtes libres - de choisir le parcours qui vous convient le plus, selon vos - préférences. Il n'est pas obligatoire pour les GISTRE de suivre ce - TP, et ceux qui ambitionnent d'être de futur devops, peuvent suivre - plutôt le TP orienté SRS. - - \vspace{1em} - - Tous les éléments de ce TP (exercices et projet) sont à rendre à - au plus tard le **jeudi 18 novembre 2021 à 23 h - 42**. Consultez la dernière section de chaque partie pour plus d'informations - sur les éléments à rendre. Et n'oubliez pas de répondre aux [questions de - cours](https://virli.nemunai.re/quiz/17). - - 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 - vôtre](https://www.meetup.com/fr/Paris-certification-de-cles-PGP-et-CAcert/). + Les exercices de ce cours sont à rendre au plus tard le mardi 29 + novembre 2022 à 23 h 42. Consultez les sections matérialisées par un + bandeau jaunes et un engrenage pour plus d'informations sur les + éléments à rendre. ... diff --git a/tutorial/5/tutorial-srs.md b/tutorial/5/tutorial-srs.md index fff7ea4..c658ab3 100644 --- a/tutorial/5/tutorial-srs.md +++ b/tutorial/5/tutorial-srs.md @@ -3,27 +3,15 @@ title: Virtualisation légère -- TP n^o^ 5 subtitle: DevOps, intégration et déploiement continu author: Pierre-Olivier *nemunaire* [Mercier]{.smallcaps} institute: EPITA -date: Jeudi 4 novembre 2021 +date: Mercredi 16 novembre 2022 abstract: | Durant ce nouveau TP, nous allons jouer les DevOps et déployer automatiquement des services ! \vspace{1em} - À la demande de Nabih, ce TP a été raccourci et reste concentré sur - un maximum d'aspects *fun*. - - \vspace{1em} - - Tous les éléments de ce TP (exercices et projet) sont à rendre à - au plus tard le **jeudi 18 novembre 2021 à 23 h - 42**. Consultez la dernière section de chaque partie pour plus d'informations - sur les éléments à rendre. Et n'oubliez pas de répondre aux [questions de - cours](https://virli.nemunai.re/quiz/13). - - 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 - vôtre](https://www.meetup.com/fr/Paris-certification-de-cles-PGP-et-CAcert/). + Les exercices de ce cours sont à rendre au plus tard le mardi 29 + novembre 2022 à 23 h 42. Consultez les sections matérialisées par un + bandeau jaunes et un engrenage pour plus d'informations sur les + éléments à rendre. ... diff --git a/tutorial/5/tutorial.md b/tutorial/5/tutorial.md deleted file mode 100644 index c658ab3..0000000 --- a/tutorial/5/tutorial.md +++ /dev/null @@ -1,17 +0,0 @@ ---- -title: Virtualisation légère -- TP n^o^ 5 -subtitle: DevOps, intégration et déploiement continu -author: Pierre-Olivier *nemunaire* [Mercier]{.smallcaps} -institute: EPITA -date: Mercredi 16 novembre 2022 -abstract: | - Durant ce nouveau TP, nous allons jouer les DevOps et déployer - automatiquement des services ! - - \vspace{1em} - - Les exercices de ce cours sont à rendre au plus tard le mardi 29 - novembre 2022 à 23 h 42. Consultez les sections matérialisées par un - bandeau jaunes et un engrenage pour plus d'informations sur les - éléments à rendre. -... diff --git a/tutorial/devops/ci.md b/tutorial/devops/ci.md index 14953ea..e996185 100644 --- a/tutorial/devops/ci.md +++ b/tutorial/devops/ci.md @@ -1,4 +1,5 @@ -## Intégration continue +Intégration continue +-------------------- Une fois Gitea et Drone installés et configurés, nous allons pouvoir rentrer dans le vif du sujet : faire de l'intégration continue sur notre premier projet ! diff --git a/tutorial/devops/renovate-ansible.md b/tutorial/devops/renovate-ansible.md new file mode 100644 index 0000000..9bffd1d --- /dev/null +++ b/tutorial/devops/renovate-ansible.md @@ -0,0 +1,23 @@ +Voici à quoi pourrait ressembler le playbook Ansible démarrant notre conteneur +Renovatebot : + +
+```yaml +- name: Launch renovate container + docker_container: + name: renovate + image: renovate/renovate + state: started + restart_policy: no + memory: 2G + networks: + - name: gitea + env: + RENOVATE_ENDPOINT: "http://gitea:3000/api/v1/" + RENOVATE_PLATFORM: "gitea" + RENOVATE_TOKEN: "{{ renovate_token }}" + RENOVATE_GIT_AUTHOR: "Renovatebot " + RENOVATE_AUTODISCOVER: "true" + RENOVATE_LOG_LEVEL: "info" +``` +
diff --git a/tutorial/devops/renovate-end.md b/tutorial/devops/renovate-end.md new file mode 100644 index 0000000..348ca59 --- /dev/null +++ b/tutorial/devops/renovate-end.md @@ -0,0 +1,78 @@ +Dès que le conteneur sera lancé, nous devrions voir apparaître une ou plusieurs +*pull-requests* pour le projet `youp0m`. Si votre CI est configurée +correctement, des tests automatiques seront lancés. + +Le conteneur s'arrête dès qu'il a terminé d'analysé tous les dépôts. Vous +devrez le relancer si vous attendez une nouvelle action de la part de +Renovatebot. Il est courant de le lancer entre chaque heure et 2 ou 4 fois par +jour. + +De très nombreuses options permettent d'adapter le comportement de Renovatebot +aux besoins de chaque projet. La configuration se fait au travers d'un fichier +`renovate.json` qui se trouve généralement à la racine du dépôt. + +Pour avoir un aperçu de toutes les possibilités offertes par renovatebot, +consultez la liste des éléments de configuration : + +\ + +Ne soyez pas effrayé par la liste interminable d'options. Il est vrai que la +première fois, on peut se sentir submergé de possibilités, mais il faut noter +que le projet arriver avec des options par défaut plutôt correctes, et que l'on +peut facilement avoir une configuration commune pour tous nos dépôts, à travers +les *presets*. + +Un certain nombre de *presets* sont distribués par défaut, voici la liste +(humainement lisible cette fois) : + + +Voici un exemple de configuration que vous pouvez utilisé comme base de tous +vos projets : + +
+```json +{ + "$schema": "https://docs.renovatebot.com/renovate-schema.json", + "extends": [ + "local>renovate/renovate-config" + ] +} +``` +
+ +Ceci ira chercher une configuration dans le fichier `default.json` du dépôt +`renovate/renovate-config`. À condition que votre utilisateur Renovatebot +s'appelle effectivement `renovate`. + +Voici un exemple de fichier `default.json` que vous pourriez vouloir utiliser : + +```json +{ + "$schema": "https://docs.renovatebot.com/renovate-schema.json", + "packageRules": [ + { + "description": "Opt-out minimum Go version updates", + "matchManagers": ["gomod"], + "matchDepTypes": ["golang"], + "enabled": false + } + ], + "extends": [ + "config:base", + ":dependencyDashboard", + ":enableVulnerabilityAlertsWithLabel('security')", + "group:recommended" + ] +} +``` + +Attention, on ne le répétera jamais assez, mais Renovatebot peut vite devenir +infernal, car il va créer de nombreuses *pull-requests*, inlassablement. Il +convient de rapidement activer la fusion automatique des mises à jour pour +lesquelles vous avez confiances et pour lesquelles vous ne feriez qu'appuyer +sur le bouton de fusion, sans même tester vous-même. La fonctionnalité est +décrite en détail dans la documentation[^RENOVATE_AUTOMERGE] et explique les +différentes stratégies. Néanmoins, il est nécessaire d'avoir une bonne suite de +tests avant d'envisager d'utiliser une telle fonctionnalité. + +[^RENOVATE_AUTOMERGE]: diff --git a/tutorial/devops/renovate.md b/tutorial/devops/renovate.md new file mode 100644 index 0000000..a97a123 --- /dev/null +++ b/tutorial/devops/renovate.md @@ -0,0 +1,60 @@ +Autres outils indispensables +---------------------------- + +### Maintient à jour des dépendances + +Une opération fastidieuse, souvent oubliée sitôt le projet envoyé en +production, c'est la mise à jour des dépendances applicatives. Fastidieux car +il faut d'une part être informé qu'une mise à jour est disponible, c'est-à-dire +qu'il faut suivre les mails, parfois nombreux, informant des nouvelles +*releases*, parfois il s'agir de newslettre, ou encore parfois aucune +notification ne peut être programmée, il faut se rendre régulièrement sur un +site pour savoir si oui ou non une mise à jour est disponible. + +Et ce n'est pas tout puisqu'une fois la nouvelle version identifiée, il faut la +récupérer, vérifier que tout compile et que les tests passent... On peut vite +comprendre que personne ne veut avoir cette tâche. + +Heureusement pour nous, des outils existent pour faire tout cela ! Dependabot +et Renovatebot sont deux projets qui vont nous aider à maintenir nos +projets. Que ce soit pour corriger une vulnérabilité dans un module NodeJS, un +nouvelle version d'un conteneur Docker ou une évolution majeure d'un framework, +nous serons alerté et pourrons agir en conséquence, en sachant si les tests +passent ou pas, avec l'aide de notre système d'intégration continue. + +Pour la suite de notre expérience, nous allons prendre en main Renovatebot qui +semble aujourd'hui la solution la plus aboutie des deux. + +![L'activité favorite de renovatebot : créer des *pull-requests*](renovatebot-pr.png){height=10cm} + + +### Installation de Renovatebot + +Une fois de plus, nous allons déployer ... un conteneur Docker ! Mais avant +cela, il va falloir créer un utilisateur dédié à Renovatebot dans notre forge. +Cet utilisateur sera utilisé par le *bot* pour participer à vos projets : il va +régulièrement cloner vos dépôts, rechercher les dépendances pour les outils +qu'il maîtrise, puis préparer des *pull-requests* dès qu'il détectera une +nouvelle version d'une dépendance. + +Dès lors que vous aurez créé le nouvel utilisateur dans Gitea, il faudra +générer un jeton d'accès, car aussi doué soit Renovatebot, il préfère utiliser +l'API HTTP plutôt que de cliquer sur les boutons. Dans les paramètres de +l'utilisateur que vous aurez créé, sous l'onglet « Applications », vous +trouverez un encadré « Gérer les jetons d'accès ». Contrairement à DroneCI pour +lequel il fallait créer une application OAuth2, ici il s'agit bien du formulaire en +haut de la page. + +::::: {.warning} + +Il est bien question de créer un jeton d'accès pour l'utilisateur renovatebot +que vous avez créé, et non pas pour votre compte utilisateur. + +Bien que cela fonctionnerait parfaitement, le bot parlerait en votre nom, il +serait alors difficile de suivre les requêtes. + +::::: + +Juste avant de lancer le conteneur, assurez-vous que votre utilisateur +Renovatebot a bien accès en écriture aux dépôts que vous souhaitez qu'il +surveille. Sans quoi il ne sera pas en mesure de vous aider. diff --git a/tutorial/devops/renovatebot-pr.png b/tutorial/devops/renovatebot-pr.png new file mode 100644 index 0000000..0d3fcf7 Binary files /dev/null and b/tutorial/devops/renovatebot-pr.png differ diff --git a/tutorial/docker-internals/overlayfs.png b/tutorial/docker-internals/overlayfs.png new file mode 100644 index 0000000..8b1db3b Binary files /dev/null and b/tutorial/docker-internals/overlayfs.png differ