tuto5 done for GISTRE, split files
This commit is contained in:
parent
0954504a60
commit
d5aea43abf
|
|
@ -18,15 +18,26 @@ SOURCES_SRS = tutorial-srs.md \
|
|||
../devops/tools-drone-runner-end.md \
|
||||
../devops/tools-end.md \
|
||||
../devops/ci.md \
|
||||
../devops/ci-about-webhook.md \
|
||||
../devops/ci-define-steps.md \
|
||||
../devops/ci-define-steps-end.md \
|
||||
../devops/ci-qa.md \
|
||||
../devops/ci-tags.md \
|
||||
../devops/publish-docker.md \
|
||||
../devops/publish-docker-intro-end.md \
|
||||
../devops/publish-docker-howto.md \
|
||||
../devops/publish-docker-howto-sample.md \
|
||||
../devops/publish-docker-publish.md \
|
||||
../devops/publish-docker-test.md \
|
||||
../devops/publish-docker-end.md \
|
||||
../devops/renovate.md ../devops/renovate-ansible.md ../devops/renovate-end.md \
|
||||
rendu-srs.md
|
||||
|
||||
SOURCES_GISTRE = tutorial-gistre.md \
|
||||
../devops/devops.md \
|
||||
../devops/what-gistre.md \
|
||||
../devops/what-cmd.md \
|
||||
../devops/what-hosts.md \
|
||||
../devops/what-gistre-see-srs.md \
|
||||
../devops/tools.md \
|
||||
../devops/tools-gitea.md \
|
||||
../devops/tools-gitea-cmd.md \
|
||||
|
|
@ -39,7 +50,18 @@ SOURCES_GISTRE = tutorial-gistre.md \
|
|||
../devops/tools-drone-runner-end.md \
|
||||
../devops/tools-end.md \
|
||||
../devops/ci-gistre.md \
|
||||
../devops/ci-about-webhook.md \
|
||||
../devops/ci-define-steps.md \
|
||||
../devops/ci-define-steps-end-gistre.md \
|
||||
../devops/ci-tags.md \
|
||||
../devops/ci-multiarch.md \
|
||||
../devops/run-gistre.md \
|
||||
../devops/publish-docker.md \
|
||||
../devops/publish-docker-howto.md \
|
||||
../devops/publish-docker-howto-sample-gistre.md \
|
||||
../devops/publish-docker-publish.md \
|
||||
../devops/publish-docker-test-gistre.md \
|
||||
../devops/publish-docker-end-gistre.md \
|
||||
rendu-gistre.md
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -3,60 +3,72 @@
|
|||
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.
|
||||
|
||||
Afin d'orienter correctement votre rendu, ajoutez une balise `[TP5]` au sujet
|
||||
de votre courriel. N'hésitez pas à indiquer dans le corps du message votre
|
||||
ressenti et vos difficultés ou bien alors écrivez votre meilleure histoire
|
||||
drôle si vous n'avez rien à dire.
|
||||
|
||||
Par ailleurs, n'oubliez pas de répondre à
|
||||
[l'évaluation du cours](https://virli.nemunai.re/quiz/17).
|
||||
|
||||
|
||||
Tarball
|
||||
Arborescence attendue
|
||||
-------
|
||||
|
||||
Tous les fichiers identifiés comme étant à rendre pour ce TP sont à
|
||||
placer dans une tarball (pas d'archive ZIP, RAR, ...).
|
||||
Tous les fichiers identifiés comme étant à rendre sont à placer dans un dépôt
|
||||
Git privé, que vous partagerez avec [votre
|
||||
professeur](https://gitlab.cri.epita.fr/nemunaire/).
|
||||
|
||||
Voici une arborescence type (vous pourriez avoir des fichiers
|
||||
supplémentaires) :
|
||||
Voici une arborescence type (vous pourriez avoir des fichiers supplémentaires) :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
login_x-TP5/
|
||||
login_x-TP5/linky2influx/
|
||||
login_x-TP5/linky2influx/.drone.yml
|
||||
login_x-TP5/linky2influx/Dockerfile
|
||||
login_x-TP5/linky2influx/.dockerignore
|
||||
login_x-TP5/linky2influx/...
|
||||
login_x-TP5/linky2influx/linky2influx.nix
|
||||
login_x-TP5/linky2influx/snapcraft.yaml
|
||||
login_x-TP5/linky2influx/lxc-scripts/template.sh
|
||||
login_x-TP5/linky2influx/lxc-scripts/sample.config
|
||||
login_x-TP5/linky2influx/systemd/linky2influx.nspawn
|
||||
login_x-TP5/linky2influx/systemd/linky2influx.service
|
||||
login_x-TP5/docker/run.sh
|
||||
login_x-TP5/lxc/run.sh
|
||||
login_x-TP5/k3s/linky2influx.yaml
|
||||
login_x-TP5/meta-electropcool/recipes-support/linky2influx/linky2influx_9999.bb
|
||||
login_x-TP5/runc/config.json
|
||||
login_x-TP5/runc/runtime.json
|
||||
login_x-TP5/snap/run.sh
|
||||
login_x-TP5/...
|
||||
./linky2influx/
|
||||
./linky2influx/.drone.yml
|
||||
./linky2influx/Dockerfile
|
||||
./linky2influx/.dockerignore
|
||||
./linky2influx/...
|
||||
./linky2influx/linky2influx.nix
|
||||
./linky2influx/snapcraft.yaml
|
||||
./linky2influx/lxc-scripts/template.sh
|
||||
./linky2influx/lxc-scripts/sample.config
|
||||
./linky2influx/systemd/linky2influx.nspawn
|
||||
./linky2influx/systemd/linky2influx.service
|
||||
./docker/run.sh
|
||||
./lxc/run.sh
|
||||
./k3s/linky2influx.yaml
|
||||
./meta-electropcool/recipes-support/linky2influx/linky2influx_9999.bb
|
||||
./runc/config.json
|
||||
./runc/runtime.json
|
||||
./snap/run.sh
|
||||
./...
|
||||
```
|
||||
</div>
|
||||
|
||||
Votre rendu sera pris en compte en faisant un [tag **signé par votre clef
|
||||
PGP**](https://lessons.nemunai.re/keys). Consultez les détails du rendu (nom du
|
||||
tag, ...) sur la page dédiée au projet sur la plateforme de rendu.
|
||||
|
||||
::::: {.question}
|
||||
|
||||
Si vous utilisez un seul dépôt pour tous vos rendus, vous **DEVRIEZ**
|
||||
créer une branche distincte pour chaque rendu :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
42sh$ git checkout --orphan renduX
|
||||
42sh$ git reset
|
||||
42sh$ rm -r *
|
||||
42sh$ # Créer l'arborescence de rendu ici
|
||||
```
|
||||
</div>
|
||||
|
||||
Pour retrouver ensuite vos rendus des travaux précédents :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
42sh$ git checkout renduY
|
||||
-- ou --
|
||||
42sh$ git checkout master
|
||||
...
|
||||
```
|
||||
</div>
|
||||
|
||||
Chaque branche est complètement indépendante l'une de l'autre. Vous
|
||||
pouvez avoir les exercices du TP1 sur `master`, les exercices du TP6
|
||||
sur `rendu6`, ... ce qui vous permet d'avoir une arborescence
|
||||
correspondant à ce qui est demandé, sans pour autant perdre votre
|
||||
travail (ou le rendre plus difficile d'accès).
|
||||
|
||||
::::
|
||||
|
|
|
|||
|
|
@ -10,8 +10,8 @@ abstract: |
|
|||
|
||||
\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
|
||||
Les exercices de ce cours sont à rendre au plus tard le dimanche 18
|
||||
décembre 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.
|
||||
...
|
||||
|
|
|
|||
|
|
@ -0,0 +1,21 @@
|
|||
::::: {.question}
|
||||
|
||||
#### Que fait Drone pour « surveiller » un dépôt ? {-}
|
||||
\
|
||||
|
||||
Grâce aux permissions de que Drone a récupéré lors de la connexion OAuth à
|
||||
Gitea, il peut non seulement lire et récupérer le code des différents dépôts
|
||||
auxquels vous avez accès, mais il peut aussi changer certains paramètres.
|
||||
|
||||
L'activation d'un dépôt dans Drone se traduit par la configuration d'un
|
||||
*webhook* sur le dépôt en question. On peut le voir dans les paramètres du
|
||||
dépôt, sous l'onglet *Déclencheurs Web*.
|
||||
|
||||
:::::
|
||||
|
||||
{height=6cm}
|
||||
|
||||
À chaque fois qu'un événement va se produire sur le dépôt, Gitea va prévenir
|
||||
Drone qui décidera si l'évènement doit conduire à lancer l'intégration continue
|
||||
ou non, selon les instructions qu'on lui a donné dans la configuration du
|
||||
dépôt.
|
||||
|
|
@ -0,0 +1,17 @@
|
|||
Les étapes sont sensiblement les mêmes que dans le `Dockerfile` présent sur le
|
||||
dépôt.
|
||||
|
||||
Committons puis poussons notre travail. Dès qu'il sera reçu par Gitea, nous
|
||||
devrions voir l'interface de Drone lancer les étapes décrites dans le fichier.
|
||||
|
||||
{height=7.5cm}
|
||||
|
||||
::::: {.warning}
|
||||
**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 !
|
||||
:::::
|
||||
|
||||
Lorsqu'apparaît enfin la ligne `git.nemunai.re/linky2influx`, le projet est compilé !
|
||||
|
|
@ -0,0 +1,26 @@
|
|||
Les étapes sont sensiblement les mêmes que dans le `Dockerfile` que nous avons
|
||||
écrit précédemment.
|
||||
|
||||
::::: {.exercice}
|
||||
|
||||
Commencez à partir de l'exemple donné dans la documentation de Drone. Par
|
||||
rapport au `Dockerfile`, n'ajoutez pas `tags dev`, cela permettra d'embarquer
|
||||
tout le contenu statique (pages HTML, feuilles de style CSS, Javascript, ...)
|
||||
directement dans le binaire, ce qui simplifiera la distribution.
|
||||
|
||||
*Committons* puis poussons notre travail. Dès qu'il sera reçu par Gitea, nous
|
||||
devrions voir l'interface de Drone lancer les étapes décrites dans le fichier.
|
||||
|
||||
:::::
|
||||
|
||||
{height=6cm}
|
||||
|
||||
::::: {.warning}
|
||||
**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 !
|
||||
:::::
|
||||
|
||||
Lorsqu'apparaît enfin la ligne `git.nemunai.re/youp0m`, le projet est compilé !
|
||||
|
|
@ -0,0 +1,19 @@
|
|||
### Définir les étapes d'intégration
|
||||
|
||||
Nous allons devoir rédiger un fichier `drone.yml`, que l'on placera à la racine
|
||||
du dépôt. C'est ce fichier qui sera traité par DroneCI pour savoir comment
|
||||
compiler et tester le projet.
|
||||
|
||||
::::: {.warning}
|
||||
Un fichier `drone.yml` existe déjà à la racine du dépôt. Celui-ci pourra vous
|
||||
servir d'inspiration, mais il ne fonctionnera pas directement dans votre
|
||||
installation.
|
||||
|
||||
**Vous rencontrerez des problèmes inattendus si vous utilisez le fichier
|
||||
`.drone.yml` du dépôt.** Vous **DEVEZ** partir d'un fichier vide et suivre la
|
||||
documentation pour obtenir un `.drone.yml` fonctionnel.
|
||||
:::::
|
||||
|
||||
Toutes les informations nécessaires à l'écriture du fichier `.drone.yml` se
|
||||
trouvent dans l'excellente documentation du projet :\
|
||||
<https://docs.drone.io/pipeline/docker/examples/languages/golang/>.
|
||||
|
|
@ -2,120 +2,15 @@
|
|||
|
||||
## Intégration continue
|
||||
|
||||
::::: {.question}
|
||||
|
||||
La mise en place de l'environnement de CI/CD n'est pas le cœur de la version
|
||||
GISTRE du TP (elle l'est pour les SRS). Aussi cette partie est aussi guidée que
|
||||
possible et toutes les commandes vous sont données pour réduire les frictions
|
||||
de mise en œuvre.
|
||||
|
||||
Mais comme indiqué dans l'introduction au DevOps, vous serez susceptibles
|
||||
d'arriver dans une entreprise qui pratique correctement le DevOps. Dans cette
|
||||
situation, l'ensemble des développeurs et des administrateurs système (les
|
||||
*Ops*), doivent faire en sorte que leurs travaux soient intégrés dans les
|
||||
outils d'intégration continue. Les *Ops* vont évidemment plutôt gérer la mise
|
||||
en place des outils, proprement, c'est ce que demande de faire le TP SRS. Pour
|
||||
vous il s'agit plus de savoir interagir avec, en sachant manipuler la
|
||||
configuration des dépôts.
|
||||
|
||||
:::::
|
||||
|
||||
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 !
|
||||
|
||||
### Créez un dépôt pour `linky2influx`
|
||||
|
||||
::::: {.exercice}
|
||||
|
||||
Après avoir créé (ou migré pour les plus malins !) le dépôt
|
||||
[`linky2influx`](https://git.nemunai.re/nemunaire/linky2influx) dans Drone,
|
||||
synchronisez les dépôts, puis activez la surveillance de `linky2influx`.
|
||||
[`linky2influx`](https://git.nemunai.re/nemunaire/linky2influx) dans gitea,
|
||||
synchronisez les dépôts dans Drone, puis activez la surveillance de `linky2influx`.
|
||||
|
||||
Nous allons devoir rédiger un fichier `.drone.yml`, que l'on placera à la racine
|
||||
du dépôt. C'est ce fichier qui sera traité par DroneCI pour savoir comment
|
||||
compiler et tester le projet.
|
||||
|
||||
::::: {.warning}
|
||||
Un fichier `.drone.yml` existe déjà à la racine du dépôt. Celui-ci pourra vous
|
||||
servir d'inspiration, mais il ne fonctionnera pas directement sur votre
|
||||
installation.
|
||||
|
||||
**Vous rencontrerez des problèmes inattendus si vous utilisez le fichier
|
||||
`.drone.yml` du dépôt.** Vous **DEVEZ** partir d'un fichier vide et suivre la
|
||||
documentation pour obtenir un `.drone.yml` fonctionnel.
|
||||
:::::
|
||||
|
||||
|
||||
### Définir les étapes d'intégration
|
||||
|
||||
Toutes les informations nécessaires à 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` présent sur le
|
||||
dépôt.
|
||||
|
||||
Committons puis poussons notre travail. Dès qu'il sera reçu par Gitea, nous
|
||||
devrions voir l'interface de Drone lancer les étapes décrites dans le fichier.
|
||||
|
||||
::::: {.warning}
|
||||
**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=7.5cm}
|
||||
|
||||
Lorsqu'apparaît enfin la ligne `git.nemunai.re/linky2influx`, le projet est compilé !
|
||||
|
||||
|
||||
### 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}
|
||||
|
||||
::::: {.more}
|
||||
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 `linky2influx` pour plusieurs architectures 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 `mips`, `powerpc`, ... nous pouvons générer les
|
||||
binaires correspondant à chaque architecture et système.
|
||||
|
||||
Ajoutez à votre fichier `.drone.yml` les deux architectures pour lesquelles les
|
||||
Raspberry Pi d'Électropcool sont compatibles. Nommez les fichiers selon
|
||||
l'architecture que pourrait renvoyer `uname -m`, cela pourrait nous simplifier la tâche ensuite...
|
||||
\
|
||||
|
||||
Une fois taggé et poussé sur notre dépôt, nous aurons une version exécutable
|
||||
utilisable à la fois sur notre machine de développement, mais aussi sur les
|
||||
Raspberry Pi déjà déployées dans les bâtiments. Nous avons atteint l'un des
|
||||
deux objectifs qui nous était demandé. Tâchons maintenant de trouver un
|
||||
|
|
|
|||
|
|
@ -0,0 +1,26 @@
|
|||
### 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 `linky2influx` pour plusieurs architectures 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 `mips`, `powerpc`, ... nous pouvons générer les
|
||||
binaires correspondant à chaque architecture et système.
|
||||
|
||||
Ajoutez à votre fichier `.drone.yml` les deux architectures pour lesquelles les
|
||||
Raspberry Pi d'Électropcool sont compatibles. Nommez les fichiers selon
|
||||
l'architecture que pourrait renvoyer `uname -m`, cela pourrait nous simplifier la tâche ensuite...
|
||||
\
|
||||
|
||||
Une fois taggé et poussé sur notre dépôt, nous aurons une version exécutable
|
||||
utilisable à la fois sur notre machine de développement, mais aussi sur les
|
||||
Raspberry Pi déjà déployées dans les bâtiments.
|
||||
|
||||
Nous avons atteint l'un des deux objectifs qui nous était demandé. Tâchons
|
||||
maintenant de trouver une manière de faciliter la distribution du binaire.
|
||||
|
|
@ -0,0 +1,30 @@
|
|||
### Inspection qualité
|
||||
|
||||
`youp0m` n'a pas de suite de tests fonctionnels, mais nous allons utiliser
|
||||
[Sonarqube](https://www.sonarqube.org/) pour faire une revue qualité du code !
|
||||
|
||||
Tout d'abord, il faut lancer le conteneur Sonarqube :
|
||||
|
||||
<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>.
|
||||
|
||||
::::: {.exercice}
|
||||
|
||||
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.
|
||||
|
|
@ -0,0 +1,35 @@
|
|||
### 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.
|
||||
|
||||
::::: {.exercice}
|
||||
|
||||
Ajoutons donc une nouvelle règle à notre `.droneci.yml` pour placer le binaire
|
||||
au sein de la liste des fichiers téléchargeables 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/>
|
||||
|
||||
::::: {.warning}
|
||||
|
||||
#### Attention à ne pas stocker votre clef d'API dans le fichier YAML ! {-}
|
||||
\
|
||||
|
||||
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.
|
||||
|
||||
Pour notre exercice, nous n'avons pas besoin de créer un utilisateur dédié,
|
||||
mais il est impératif d'utiliser les *secrets* de Drone pour ne pas que la clef
|
||||
d'API apparaisse dans l'historique du dépôt.
|
||||
|
||||
:::::
|
||||
|
||||
:::::
|
||||
|
||||
{height=8cm}
|
||||
|
|
@ -21,142 +21,3 @@ activez la surveillance de `youp0m`.
|
|||
[^urlyoup0m]: <https://git.nemunai.re/nemunaire/youp0m>
|
||||
|
||||
:::::
|
||||
|
||||
::::: {.question}
|
||||
|
||||
#### Que fait Drone pour « surveiller » un dépôt ? {-}
|
||||
\
|
||||
|
||||
Grâce aux permissions de que Drone a récupéré lors de la connexion OAuth à
|
||||
Gitea, il peut non seulement lire et récupérer le code des différents dépôts
|
||||
auxquels vous avez accès, mais il peut aussi changer certains paramètres.
|
||||
|
||||
L'activation d'un dépôt dans Drone se traduit par la configuration d'un
|
||||
*webhook* sur le dépôt en question. On peut le voir dans les paramètres du
|
||||
dépôt, sous l'onglet *Déclencheurs Web*.
|
||||
|
||||
:::::
|
||||
|
||||
{height=6cm}
|
||||
|
||||
À chaque fois qu'un événement va se produire sur le dépôt, Gitea va prévenir
|
||||
Drone qui décidera si l'évènement doit conduire à lancer l'intégration continue
|
||||
ou non, selon les instructions qu'on lui a donné dans la configuration du
|
||||
dépôt.
|
||||
|
||||
|
||||
### Définir les étapes d'intégration
|
||||
|
||||
Nous allons devoir rédiger un fichier `drone.yml`, que l'on placera à la racine
|
||||
du dépôt. C'est ce fichier qui sera traité par DroneCI pour savoir comment
|
||||
compiler et tester le projet.
|
||||
|
||||
::::: {.warning}
|
||||
Un fichier `drone.yml` existe déjà à la racine du dépôt. Celui-ci pourra vous
|
||||
servir d'inspiration, mais il ne fonctionnera pas directement dans votre
|
||||
installation.
|
||||
|
||||
**Vous rencontrerez des problèmes inattendus si vous utilisez le fichier
|
||||
`.drone.yml` du dépôt.** Vous **DEVEZ** partir d'un fichier vide et suivre la
|
||||
documentation pour obtenir un `.drone.yml` fonctionnel.
|
||||
:::::
|
||||
|
||||
Toutes les informations nécessaires à 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 nous avons
|
||||
écrit précédemment.
|
||||
|
||||
::::: {.exercice}
|
||||
|
||||
Commencez à partir de l'exemple donné dans la documentation de Drone. Par
|
||||
rapport au `Dockerfile`, n'ajoutez pas `tags dev`, cela permettra d'embarquer
|
||||
tout le contenu statique (pages HTML, feuilles de style CSS, Javascript, ...)
|
||||
directement dans le binaire, ce qui simplifiera la distribution.
|
||||
|
||||
*Committons* puis poussons notre travail. Dès qu'il sera reçu par Gitea, nous
|
||||
devrions voir l'interface de Drone lancer les étapes décrites dans le fichier.
|
||||
|
||||
:::::
|
||||
|
||||
{height=6cm}
|
||||
|
||||
::::: {.warning}
|
||||
**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 !
|
||||
:::::
|
||||
|
||||
Lorsqu'apparaît enfin la ligne `git.nemunai.re/youp0m`, le projet est compilé !
|
||||
|
||||
|
||||
### Inspection qualité
|
||||
|
||||
`youp0m` n'a pas de suite de tests fonctionnels, mais nous allons utiliser
|
||||
[Sonarqube](https://www.sonarqube.org/) pour faire une revue qualité du code !
|
||||
|
||||
Tout d'abord, il faut lancer le conteneur Sonarqube :
|
||||
|
||||
<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>.
|
||||
|
||||
::::: {.exercice}
|
||||
|
||||
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.
|
||||
|
||||
::::: {.exercice}
|
||||
|
||||
Ajoutons donc une nouvelle règle à notre `.droneci.yml` pour placer le binaire
|
||||
au sein de la liste des fichiers téléchargeables 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/>
|
||||
|
||||
::::: {.warning}
|
||||
|
||||
#### Attention à ne pas stocker votre clef d'API dans le fichier YAML ! {-}
|
||||
\
|
||||
|
||||
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.
|
||||
|
||||
Pour notre exercice, nous n'avons pas besoin de créer un utilisateur dédié,
|
||||
mais il est impératif d'utiliser les *secrets* de Drone pour ne pas que la clef
|
||||
d'API apparaisse dans l'historique du dépôt.
|
||||
|
||||
:::::
|
||||
|
||||
:::::
|
||||
|
||||
{height=8cm}
|
||||
|
|
|
|||
Binary file not shown.
|
After Width: | Height: | Size: 121 KiB |
|
|
@ -0,0 +1,4 @@
|
|||
### Et ensuite ?
|
||||
|
||||
Nous avons vu une manière possible de distribuer notre projet. Essayons-en une
|
||||
autre parmis celles proposées.
|
||||
|
|
@ -0,0 +1,17 @@
|
|||
### Vers le déploiement
|
||||
|
||||
Nous n'allons pas faire le déploiement aujourd'hui, car nous n'avons pas
|
||||
d'environnement de production sur lequel déployer notre service.
|
||||
|
||||
Vous pouvez néanmoins 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 !
|
||||
|
|
@ -0,0 +1,14 @@
|
|||
Nous pouvons ensuite envoyer une image pour s'assurer que tout va bien :
|
||||
|
||||
<div lang="en-US">
|
||||
```bash
|
||||
docker build -t localhost:3000/${USER}/linky2influxdb .
|
||||
docker push localhost:3000/${USER}/linky2influxdb
|
||||
```
|
||||
</div>
|
||||
|
||||
Rendez-vous ensuite sur la page <http://gitea:3000/${USER}/-/packages> pour
|
||||
attribuer l'image au dépôt `linky2influxdb` (voir pour cela dans les paramètres de
|
||||
l'image).
|
||||
|
||||
{height=6cm}
|
||||
|
|
@ -0,0 +1,14 @@
|
|||
Nous pouvons ensuite envoyer une image pour s'assurer que tout va bien :
|
||||
|
||||
<div lang="en-US">
|
||||
```bash
|
||||
docker build -t localhost:3000/${USER}/youp0m .
|
||||
docker push localhost:3000/${USER}/youp0m
|
||||
```
|
||||
</div>
|
||||
|
||||
Rendez-vous ensuite sur la page <http://gitea:3000/${USER}/-/packages> pour
|
||||
attribuer l'image au dépôt `youp0m` (voir pour cela dans les paramètres de
|
||||
l'image).
|
||||
|
||||
{height=6cm}
|
||||
|
|
@ -0,0 +1,31 @@
|
|||
#### Fonctionnement du registre de Gitea \
|
||||
|
||||
Gitea intègre un registre d'images Docker (depuis la version 1.17,
|
||||
mi-2022). Pour le moment, les images sont uniquement liées à un compte
|
||||
utilisateur ou à une organisation, pas directement à un dépôt. Une page permet
|
||||
de rattacher l'image envoyée à un dépôt, ce que l'on fera dans un deuxième
|
||||
temps.
|
||||
|
||||
Afin de pouvoir envoyer une image nous-même, nous devons nous connecter au
|
||||
registre :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
docker login localhost:3000
|
||||
```
|
||||
</div>
|
||||
|
||||
::::: {.question}
|
||||
|
||||
#### N'a-t-on pas besoin d'un certificat TLS pour utiliser un registre Docker ? {-}
|
||||
\
|
||||
|
||||
Ceci est possible exclusivement parce que le registre `localhost` est considéré
|
||||
non-sûr par défaut. C'est-à-dire qu'il n'a pas besoin de certificat TLS valide
|
||||
sur sa connexion HTTP pour être utilisé.\
|
||||
|
||||
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/).
|
||||
|
||||
:::::
|
||||
|
|
@ -0,0 +1,3 @@
|
|||
À l'inverse, `youp0m` est à la fois un programme que l'on peut télécharger et
|
||||
un service qu'il faut déployer pour le mettre à jour. Afin de simplifier son
|
||||
déploiement en production, nous utiliserons une image Docker.
|
||||
|
|
@ -0,0 +1,18 @@
|
|||
#### Publication de l'image \
|
||||
|
||||
Une fois le registre testé, 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/>.
|
||||
|
||||
::::: {.exercice}
|
||||
|
||||
Continuons d'éditer le fichier `.drone.yml` du dépôt pour faire générer à Drone
|
||||
l'image Docker, et la publier.
|
||||
|
||||
Attention dans Drone, le domaine à utiliser pour contacter Gitea (et donc le
|
||||
registre), n'est pas `localhost`, mais `gitea`. Comme notre registre n'a pas de
|
||||
certificat TLS pour utiliser `https`, il est nécessaire de définir l'option
|
||||
`insecure` à `true`. Utilisez les *secrets* de Drone pour stocker le nom
|
||||
d'utilisateur et le mot de passe d'accès au registre.
|
||||
|
||||
:::::
|
||||
|
|
@ -0,0 +1,12 @@
|
|||
#### Test de l'image \
|
||||
|
||||
Sur notre hôte, nous pouvons tester que l'image a bien été publiée grâce à la
|
||||
commande suivante :
|
||||
|
||||
<div lang="en-US">
|
||||
```bash
|
||||
docker pull localhost:3000/${USER}/linky2influxdb
|
||||
```
|
||||
</div>
|
||||
|
||||
Si une nouvelle image est bien récupérée du dépôt, bravo, vous avez réussi !
|
||||
|
|
@ -0,0 +1,13 @@
|
|||
#### Test de l'image \
|
||||
|
||||
Sur notre hôte, nous pouvons tester que l'image a bien été publiée grâce à la
|
||||
commande suivante :
|
||||
|
||||
<div lang="en-US">
|
||||
```bash
|
||||
docker pull localhost:3000/${USER}/youp0m
|
||||
docker run --rm -p 8080:8080 localhost:3000/${USER}/youp0m
|
||||
```
|
||||
</div>
|
||||
|
||||
Si une nouvelle image est bien récupérée du dépôt, bravo, vous avez réussi !
|
||||
|
|
@ -6,109 +6,3 @@ 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 qu'il faut déployer pour le mettre à jour. Afin de simplifier son
|
||||
déploiement en production, nous utiliserons une image Docker.
|
||||
|
||||
|
||||
#### Fonctionnement du registre de Gitea \
|
||||
|
||||
Gitea intègre un registre d'images Docker (depuis la version 1.17,
|
||||
mi-2022). Pour le moment, les images sont uniquement liées à un compte
|
||||
utilisateur ou à une organisation, pas directement à un dépôt. Une page permet
|
||||
de rattacher l'image envoyée à un dépôt, ce que l'on fera dans un deuxième
|
||||
temps.
|
||||
|
||||
Afin de pouvoir envoyer une image nous-même, nous devons nous connecter au
|
||||
registre :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
docker login localhost:3000
|
||||
```
|
||||
</div>
|
||||
|
||||
::::: {.question}
|
||||
|
||||
#### N'a-t-on pas besoin d'un certificat TLS pour utiliser un registre Docker ? {-}
|
||||
\
|
||||
|
||||
Ceci est possible exclusivement parce que le registre `localhost` est considéré
|
||||
non-sûr par défaut. C'est-à-dire qu'il n'a pas besoin de certificat TLS valide
|
||||
sur sa connexion HTTP pour être utilisé.\
|
||||
|
||||
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/).
|
||||
|
||||
:::::
|
||||
|
||||
Nous pouvons ensuite envoyer une image pour s'assurer que tout va bien :
|
||||
|
||||
<div lang="en-US">
|
||||
```bash
|
||||
docker build -t localhost:3000/${USER}/youp0m .
|
||||
docker push localhost:3000/${USER}/youp0m
|
||||
```
|
||||
</div>
|
||||
|
||||
Rendez-vous ensuite sur la page <http://gitea:3000/${USER}/-/packages> pour
|
||||
attribuer l'image au dépôt `youp0m` (voir pour cela dans les paramètres de
|
||||
l'image).
|
||||
|
||||
{height=6cm}
|
||||
|
||||
|
||||
#### Publication de l'image \
|
||||
|
||||
Une fois le registre testé, 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/>.
|
||||
|
||||
::::: {.exercice}
|
||||
|
||||
Continuons d'éditer le fichier `.drone.yml` du dépôt pour faire générer à Drone
|
||||
l'image Docker, et la publier.
|
||||
|
||||
Attention dans Drone, le domaine à utiliser pour contacter Gitea (et donc le
|
||||
registre), n'est pas `localhost`, mais `gitea`. Comme notre registre n'a pas de
|
||||
certificat TLS pour utiliser `https`, il est nécessaire de définir l'option
|
||||
`insecure` à `true`. Utilisez les *secrets* de Drone pour stocker le nom
|
||||
d'utilisateur et le mot de passe d'accès au registre.
|
||||
|
||||
:::::
|
||||
|
||||
|
||||
#### Test de l'image \
|
||||
|
||||
Sur notre hôte, nous pouvons tester que l'image a bien été publiée grâce à la
|
||||
commande suivante :
|
||||
|
||||
<div lang="en-US">
|
||||
```bash
|
||||
docker pull localhost:3000/${USER}/youp0m
|
||||
docker run --rm -p 8080:8080 localhost:3000/${USER}/youp0m
|
||||
```
|
||||
</div>
|
||||
|
||||
Si une nouvelle image est bien récupérée du dépôt, bravo, vous avez réussi !
|
||||
|
||||
|
||||
### Vers le déploiement
|
||||
|
||||
Nous n'allons pas faire le déploiement aujourd'hui, car nous n'avons pas
|
||||
d'environnement de production sur lequel déployer notre service.
|
||||
|
||||
Vous pouvez néanmoins 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 !
|
||||
|
|
|
|||
|
|
@ -1,5 +1,3 @@
|
|||
\newpage
|
||||
|
||||
## Lancement du module sur la machine cible
|
||||
|
||||
Mettons de côté le déploiement continu, pour nous concentrer sur la manière
|
||||
|
|
@ -25,9 +23,9 @@ l'entrée correspondante dans `/dev`.
|
|||
|
||||
L'objectif est d'établir la méthode qui sera la plus efficace pour
|
||||
Électropcool, car elle devra sans doute demander à chacune des équipes de
|
||||
réaliser le packaging des modules qu'elles maintiennent. Il faut pour cela en
|
||||
tester plusieurs. Certaines peuvent sans doute déjà être éliminées car
|
||||
inadaptés, c'est à vous de déterminer parmi les technologies d'empacketages
|
||||
réaliser le packaging des modules qu'elles maintiennent. Il faut pour cela
|
||||
tester plusieurs solutions. Certaines peuvent sans doute déjà être éliminées car
|
||||
inadaptées, c'est à vous de déterminer parmi les technologies d'empacketages
|
||||
proposées, et celles que vous connaissez, lesquelles vous écartez d'emblée,
|
||||
lesquelles vous souhaitez garder pour explorer davantage, et enfin laquelle
|
||||
retient votre attention.
|
||||
|
|
@ -59,7 +57,7 @@ accès au périphérique correspondant au compteur.
|
|||
|
||||
<div lang="en-US">
|
||||
```
|
||||
login_x-TP5/docker/run.sh
|
||||
./docker/run.sh
|
||||
```
|
||||
</div>
|
||||
|
||||
|
|
@ -78,7 +76,7 @@ au moins un script pour lancer notre conteneur, s'il est différent d'un
|
|||
|
||||
<div lang="en-US">
|
||||
```
|
||||
login_x-TP5/lxc/run.sh
|
||||
./lxc/run.sh
|
||||
```
|
||||
</div>
|
||||
|
||||
|
|
@ -87,8 +85,8 @@ permettant de créer le conteneur LXC, ainsi qu'un exemple de configuration :
|
|||
|
||||
<div lang="en-US">
|
||||
```
|
||||
login_x-TP5/linky2influx/lxc-scripts/template.sh
|
||||
login_x-TP5/linky2influx/lxc-scripts/sample.config
|
||||
./linky2influx/lxc-scripts/template.sh
|
||||
./linky2influx/lxc-scripts/sample.config
|
||||
```
|
||||
</div>
|
||||
|
||||
|
|
@ -111,7 +109,7 @@ il pourra être intégré au dépôt :
|
|||
|
||||
<div lang="en-US">
|
||||
```
|
||||
login_x-TP5/linky2influx/systemd/linky2influx.nspawn
|
||||
./linky2influx/systemd/linky2influx.nspawn
|
||||
```
|
||||
</div>
|
||||
|
||||
|
|
@ -125,7 +123,7 @@ module via un paquet `.ipk` ou similaire en fonction de votre configuration.
|
|||
|
||||
<div lang="en-US">
|
||||
```
|
||||
login_x-TP5/meta-electropcool/recipes-support/linky2influx/linky2influx_9999.bb
|
||||
./meta-electropcool/recipes-support/linky2influx/linky2influx_9999.bb
|
||||
```
|
||||
</div>
|
||||
|
||||
|
|
@ -136,7 +134,7 @@ L'expression Nix correspondant au paquet pourra être intégré au dépôt
|
|||
|
||||
<div lang="en-US">
|
||||
```
|
||||
login_x-TP5/linky2influx/linky2influx.nix
|
||||
./linky2influx/linky2influx.nix
|
||||
```
|
||||
</div>
|
||||
|
||||
|
|
@ -150,7 +148,7 @@ Intégrez au dépôt le fichier de description, par exemple :
|
|||
|
||||
<div lang="en-US">
|
||||
```
|
||||
login_x-TP5/linky2influx/snapcraft.yaml
|
||||
./linky2influx/snapcraft.yaml
|
||||
```
|
||||
</div>
|
||||
|
||||
|
|
@ -159,7 +157,7 @@ votre conteneur :
|
|||
|
||||
<div lang="en-US">
|
||||
```
|
||||
login_x-TP5/{snap,flatpack}/run.sh
|
||||
./{snap,flatpack}/run.sh
|
||||
```
|
||||
</div>
|
||||
|
||||
|
|
@ -167,28 +165,25 @@ login_x-TP5/{snap,flatpack}/run.sh
|
|||
|
||||
### k3s
|
||||
|
||||
Nous en apprendrons davantage sur Kubernetes au prochain TP, mais si vous
|
||||
connaissez déjà, vous pourriez vouloir écrire un *Chart* Helm :
|
||||
Si vous connaissez déjà Kubernetes, vous pourriez vouloir écrire un *Chart*
|
||||
Helm :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
login_x-TP5/k3s/linky2influx.yaml
|
||||
./k3s/linky2influx.yaml
|
||||
```
|
||||
</div>
|
||||
|
||||
Inutile de vous casser la tête avec ça si vous ne connaissez pas !
|
||||
|
||||
### *Votre solution ici*
|
||||
|
||||
### Votre solution
|
||||
|
||||
N'hésitez pas à apporter une autre solution originale, que celles qui seraient
|
||||
listées ici.
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
login_x-TP5/k3s/linky2influx.yaml
|
||||
```
|
||||
</div>
|
||||
N'hésitez pas à apporter une autre solution originale, mais tout de même
|
||||
adaptée à l'objectif, que celles qui seraient listées ici.
|
||||
\
|
||||
|
||||
À vous de jouer !
|
||||
Commençons par appréhender la publication d'image Docker, que nous maîtrisons
|
||||
plutôt bien normalement.
|
||||
|
||||
|
||||
\newpage
|
||||
## Déploiement via Docker
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
\
|
||||
|
||||
Voici La ligne de commande permettant de démarrer notre agent :
|
||||
Voici la ligne de commande permettant de démarrer notre agent :
|
||||
|
||||
<div lang="en-US">
|
||||
```shell
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
### Pour aller plus loin
|
||||
|
||||
Le mouvement DevOps tend à utiliser mettre en avant la CI/CD, ce ne leur est
|
||||
Le mouvement DevOps tend à utiliser massivement la CI/CD, mais ce ne leur est
|
||||
évidemment pas exclusivement réservé. Toute entreprise ayant une méthodologie
|
||||
de développement saine dispose d'outils automatisés de construction et de
|
||||
tests.
|
||||
|
|
|
|||
|
|
@ -42,8 +42,8 @@ qui arrive sur le marché.
|
|||
L'entreprise utilise principalement de nombreux équipements de la *Raspberry Pi
|
||||
fundation*, notamment les [Compute Module 3 et
|
||||
4](https://www.raspberrypi.com/products/compute-module-4/) et les [Raspberry Pi
|
||||
Zero W](https://www.raspberrypi.com/products/raspberry-pi-zero-w/), ainsi que
|
||||
de nombreux PCB fait par l'entreprise, à base de micro-contrôleurs AVR,
|
||||
Zero 2 W](https://www.raspberrypi.com/products/raspberry-pi-zero-2-w/), ainsi
|
||||
que de nombreux PCB fait par l'entreprise, à base de micro-contrôleurs AVR,
|
||||
lorsqu'il est nécessaire de pour s'interfacer avec des équipements
|
||||
propriétaires non prévu pour l'immotique.
|
||||
|
||||
|
|
@ -51,11 +51,11 @@ Une grosse partie des travaux est donc réalisé avec un noyau Linux, sur du
|
|||
matériel très performant, pour de l'embarqué.
|
||||
\
|
||||
|
||||
Tous les modules logiciels qui interagissent avec les capteurs sont
|
||||
aujourd'hui intégrés dans un système construit à l'aide de
|
||||
[`bitbake`](https://www.yoctoproject.org/). L'entreprise grossissant à vue d'œil,
|
||||
il devient de plus en plus difficile de synchroniser les équipes concilier la
|
||||
stabilité des *releases* avec le besoin de déployer de nouvelles
|
||||
Tous les modules logiciels qui interagissent avec les capteurs sont aujourd'hui
|
||||
intégrés dans un système construit à l'aide de
|
||||
[`bitbake`](https://www.yoctoproject.org/). L'entreprise grossissant à vue
|
||||
d'œil, il devient de plus en plus difficile de synchroniser les équipes pour
|
||||
concilier la stabilité des *releases* avec le besoin de déployer de nouvelles
|
||||
fonctionnalités chaque semaine.
|
||||
|
||||
Vous avez été chargés d'étudier la meilleure façon de déployer les différents
|
||||
|
|
|
|||
Loading…
Reference in New Issue