tuto5: add part on renovate
This commit is contained in:
parent
4259fa785c
commit
75c35a36d1
|
|
@ -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 \
|
||||
|
|
|
|||
|
|
@ -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
|
||||
```
|
||||
</div>
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1 @@
|
|||
../devops/renovatebot-pr.png
|
||||
|
|
@ -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 à
|
||||
<virli@nemunai.re> 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.
|
||||
...
|
||||
|
|
|
|||
|
|
@ -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 à
|
||||
<virli@nemunai.re> 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.
|
||||
...
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
...
|
||||
|
|
@ -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 !
|
||||
|
|
|
|||
|
|
@ -0,0 +1,23 @@
|
|||
Voici à quoi pourrait ressembler le playbook Ansible démarrant notre conteneur
|
||||
Renovatebot :
|
||||
|
||||
<div lang="en-US">
|
||||
```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@gitea.sample>"
|
||||
RENOVATE_AUTODISCOVER: "true"
|
||||
RENOVATE_LOG_LEVEL: "info"
|
||||
```
|
||||
</div>
|
||||
|
|
@ -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 :
|
||||
<https://docs.renovatebot.com/configuration-options/>
|
||||
\
|
||||
|
||||
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) :
|
||||
<https://docs.renovatebot.com/presets-default/>
|
||||
|
||||
Voici un exemple de configuration que vous pouvez utilisé comme base de tous
|
||||
vos projets :
|
||||
|
||||
<div lang="en-US">
|
||||
```json
|
||||
{
|
||||
"$schema": "https://docs.renovatebot.com/renovate-schema.json",
|
||||
"extends": [
|
||||
"local>renovate/renovate-config"
|
||||
]
|
||||
}
|
||||
```
|
||||
</div>
|
||||
|
||||
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]: <https://docs.renovatebot.com/key-concepts/automerge/>
|
||||
|
|
@ -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.
|
||||
|
||||
{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.
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 161 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 35 KiB |
Loading…
Reference in New Issue