Save tuto corrections
This commit is contained in:
parent
f5ee6b8534
commit
10448a6c8d
115 changed files with 1425 additions and 1291 deletions
|
|
@ -3,4 +3,4 @@
|
|||
Déploiement
|
||||
===========
|
||||
|
||||
TODO il faudrait pouvoir cliquer sur le bouton pour mettre à jour l'image docker qui tourne localement ? en passant par Ansible ?
|
||||
TODO il faudrait pouvoir cliquer sur le bouton pour mettre à jour l'image docker qui tourne localement ? en passant par Ansible ?
|
||||
|
|
|
|||
|
|
@ -21,11 +21,11 @@ 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 !
|
||||
dans le vif du sujet : faire de l'intégration continue sur notre premier projet !
|
||||
|
||||
### Créez un dépôt pour `linky2influx`
|
||||
|
||||
Après avoir créé (ou migré pour les plus malins !) le dépôt
|
||||
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`.
|
||||
|
||||
|
|
@ -57,33 +57,33 @@ 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
|
||||
**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 !
|
||||
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é !
|
||||
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
|
||||
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 :
|
||||
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 !
|
||||
Attention à ne pas stocker votre clef d'API dans le fichier YAML !
|
||||
|
||||
{height=8cm}
|
||||
|
||||
|
|
@ -95,16 +95,16 @@ l'interface de Drone.
|
|||
:::::
|
||||
|
||||
|
||||
### Publier pour plusieurs architectures ?
|
||||
### 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 !
|
||||
vérifier que cela fonctionne bien !
|
||||
|
||||
Un exemple est donné tout en haut de cette page :
|
||||
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
|
||||
|
|
|
|||
|
|
@ -3,24 +3,26 @@
|
|||
## 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 !
|
||||
dans le vif du sujet : faire de l'intégration continue sur notre premier projet !
|
||||
|
||||
### 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.
|
||||
Reprenez les travaux déjà réalisés : nous allons notamment avoir besoin du
|
||||
`Dockerfile` que nous avons réalisé pour ce projet `youp0m`.
|
||||
|
||||
Après avoir créé (ou migré pour les plus malins !) le dépôt
|
||||
[`youp0m`](https://git.nemunai.re/nemunaire/youp0m) dans Drone,
|
||||
synchronisez les dépôts, puis activez la surveillance de `youp0m`.
|
||||
Après avoir créé (ou migré pour les plus malins !) le dépôt
|
||||
`youp0m`[^urlyoup0m] dans gitea, synchronisez les dépôts dans Drone, puis
|
||||
activez la surveillance de `youp0m`.
|
||||
|
||||
Nous allons devoir rédiger un fichier `.drone.yml`, que l'on placera à la racine
|
||||
[^urlyoup0m]: <https://git.nemunai.re/nemunaire/youp0m>
|
||||
|
||||
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
|
||||
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
|
||||
|
|
@ -32,11 +34,11 @@ 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/).
|
||||
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 lors du TP précédent.
|
||||
écrit précédemment.
|
||||
|
||||
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.
|
||||
|
|
@ -44,23 +46,22 @@ 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
|
||||
**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 !
|
||||
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é !
|
||||
Lorsqu'apparaît enfin la ligne `git.nemunai.re/youp0m`, le projet est compilé !
|
||||
|
||||
|
||||
### Inspection qualité
|
||||
|
||||
Nous n'avons pas encore de test à proprement parler. Nous allons utiliser
|
||||
[Sonarqube](https://www.sonarqube.org/) pour faire une revue qualité du code !
|
||||
[Sonarqube](https://www.sonarqube.org/) pour faire une revue qualité du code !
|
||||
|
||||
Tout d'abord, il faut lancer le conteneur Sonarqube (SRS, pensez à l'ajouter à
|
||||
votre playbook !) :
|
||||
Tout d'abord, il faut lancer le conteneur Sonarqube :
|
||||
|
||||
<div lang="en-US">
|
||||
```bash
|
||||
|
|
@ -72,7 +73,7 @@ Le service met un bon moment avant de démarrer, dès qu'il se sera initialisé,
|
|||
nous pourrons accéder à l'interface sur <http://localhost:9000>.
|
||||
|
||||
En attendant qu'il démarre, nous pouvons commencer à ajouter le nécessaire à
|
||||
notre `.drone.yml` : <http://plugins.drone.io/aosapps/drone-sonar-plugin/>.
|
||||
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
|
||||
|
|
@ -86,18 +87,18 @@ qui en fera une analyse minutieuse. Rendez-vous sur
|
|||
### 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
|
||||
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échargeables aux côtés des tags.
|
||||
|
||||
Vous aurez sans doute besoin de :
|
||||
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 !
|
||||
Attention à ne pas stocker votre clef d'API dans le fichier YAML !
|
||||
|
||||
{height=8cm}
|
||||
|
||||
|
|
|
|||
|
|
@ -4,13 +4,13 @@ Le mouvement DevOps
|
|||
===================
|
||||
|
||||
Jusqu'à récemment, et encore dans de nombreuses entreprises, les développeurs
|
||||
et les administrateurs système faisaient partie de deux équipes différentes :
|
||||
et les administrateurs système faisaient partie 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
|
||||
(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.\
|
||||
Ces contraintes : tant liées à la **sécurité** (il faut s'assurer
|
||||
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
|
||||
|
|
@ -19,13 +19,13 @@ pâtissent).
|
|||
|
||||
Une guerre faisait donc rage entre les développeurs qui ne comprenaient pas que
|
||||
les administrateurs système ne pouvaient pas maintenir autant de versions d'une
|
||||
bibliothèque qu'il y avait de services : par exemple dans le cas de plusieurs
|
||||
bibliothèque qu'il y avait de services : par exemple dans le cas de plusieurs
|
||||
services en PHP, on pouvait leur demander de déployer des applications
|
||||
utilisant la version 5.6, et la 7.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
|
||||
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ème n'ont alors pas de paquets stables
|
||||
dans la distribution. En effet, les distributions stables telles que Debian,
|
||||
|
|
@ -64,10 +64,10 @@ charges, les pannes, ...
|
|||
|
||||
::::: {.warning}
|
||||
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 :
|
||||
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
|
||||
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 à
|
||||
|
|
@ -77,14 +77,14 @@ faire du DevOps.
|
|||
|
||||
## Intégration continue
|
||||
|
||||
L'**intégration continue** est la première brique à mettre en place : le but
|
||||
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
|
||||
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.
|
||||
|
||||
|
|
@ -101,7 +101,7 @@ 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
|
||||
d'*assets*), il est possible de déclencher un déploiement : il s'agit de rendre
|
||||
accessible aux utilisateurs finaux le service ou les objets.
|
||||
|
||||
Dans le cas d'un programme à télécharger
|
||||
|
|
@ -113,15 +113,15 @@ 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 : par exemple, [le
|
||||
Parfois les deux seront à faire : à la fois publier un paquet ou un
|
||||
conteneur et mettre à jour un service en ligne : par exemple, [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), tous deux
|
||||
publient des paquets à destination de leurs communautés, et mettent à
|
||||
jour leur service en ligne.\
|
||||
|
||||
Il existe pour cela de très nombreuses stratégies : lorsque l'on n'a pas
|
||||
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
|
||||
|
|
@ -133,11 +133,11 @@ 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 !).\
|
||||
cause d'une ligne commentée par erreur !).\
|
||||
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.
|
||||
section suivante !) soient constantes.
|
||||
|
||||
|
||||
## Monitoring et supervision
|
||||
|
|
@ -145,16 +145,16 @@ section suivante !) soient constantes.
|
|||
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 informe d'un problème... (sur Twitter !?)
|
||||
|
||||
Nous avons réalisé précédemment une partie collecte de métriques, avec nos
|
||||
conteneurs TICK. Nous n'allons donc pas nous en occuper aujourd'hui.
|
||||
\
|
||||
|
||||
Notez tout de même qu'il y a deux grandes catégories de logiciels de
|
||||
supervision :
|
||||
supervision :
|
||||
|
||||
**Basée sur des états** comme Nagios, Zabbix, ... : ces logiciels vont
|
||||
**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.
|
||||
|
|
@ -163,8 +163,8 @@ Il y a rarement beaucoup d'intelligence ou d'anticipation automatique dans ces
|
|||
outils.
|
||||
\
|
||||
|
||||
**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
|
||||
**Basée sur les métriques** comme ELK, Prometheus, InfluxDB, ... : dans la
|
||||
stack TICK que nous avons mis en place précédemment, 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
|
||||
|
|
@ -196,4 +196,4 @@ 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 !).
|
||||
aucun impact sur la production (enfin on espère !).
|
||||
|
|
|
|||
|
|
@ -7,13 +7,12 @@ 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
|
||||
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` ou `linky2influx` sont à la fois des programmes que l'on
|
||||
peut télécharger et des services qu'il faut déployer pour les mettre à
|
||||
jour. Pour simplifier le déploiement, nous utilisons des images Docker. Il faut
|
||||
cependant les générer ...
|
||||
À 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. Pour simplifier le
|
||||
déploiement, nous utilisons une image Docker. Il faut cependant la générer ...
|
||||
|
||||
|
||||
## Mise en place du registre
|
||||
|
|
@ -25,7 +24,7 @@ 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 :
|
||||
comme suit :
|
||||
|
||||
<div lang="en-US">
|
||||
```bash
|
||||
|
|
@ -37,7 +36,7 @@ Vous trouverez davantage d'informations pour le déploiement
|
|||
[ici](https://docs.docker.com/registry/deploying/).
|
||||
|
||||
Nous pouvons tester le bon fonctionnement de notre registre avec la commande
|
||||
suivante :
|
||||
suivante :
|
||||
|
||||
<div lang="en-US">
|
||||
```bash
|
||||
|
|
@ -50,7 +49,7 @@ suivante :
|
|||
## 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 :
|
||||
publication de l'image Docker. Cela se fait au moyen du plugin suivant :\
|
||||
<http://plugins.drone.io/drone-plugins/drone-docker/>.
|
||||
|
||||
Sans plus de configuration, le registre que nous avons démarré
|
||||
|
|
@ -62,7 +61,7 @@ pour utiliser `https`, il est nécessaire de définir l'option
|
|||
## Test de l'image
|
||||
|
||||
Sur l'hôte, nous pouvons tester que l'image a bien été publiée grâce à la
|
||||
commande suivante :
|
||||
commande suivante :
|
||||
|
||||
<div lang="en-US">
|
||||
```bash
|
||||
|
|
@ -92,8 +91,8 @@ une machine virtuelle avec une connexion SSH. N'hésitez pas à l'ajouter à vot
|
|||
`.droneci.yml`.
|
||||
|
||||
|
||||
## Profitons !
|
||||
## 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 !
|
||||
action !
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ Mettons de côté le déploiement continu, pour nous concentrer sur la manière
|
|||
dont nous allons pouvoir exécuter notre module de relevé de compteur Linky.
|
||||
\
|
||||
|
||||
Le binaire de notre module se lance de la manière suivante :
|
||||
Le binaire de notre module se lance de la manière suivante :
|
||||
|
||||
<div lang="en-US">
|
||||
```shell
|
||||
|
|
@ -35,7 +35,7 @@ retient votre attention.
|
|||
Vous êtes tenu de retenir au minimum 2 solutions distinctes (on considère que
|
||||
les technologies listées sur la même lignes sont similaires).
|
||||
|
||||
La liste de technologies proposées est à la suivante :
|
||||
La liste de technologies proposées est à la suivante :
|
||||
|
||||
- conteneur Docker ou podman,
|
||||
- conteneur LXC (avec base alpine ou nu),
|
||||
|
|
@ -83,7 +83,7 @@ login_x-TP5/lxc/run.sh
|
|||
</div>
|
||||
|
||||
En complément, vous pouvez inclure au dépôt de `linky2influx` le modèle
|
||||
permettant de créer le conteneur LXC, ainsi qu'un exemple de configuration :
|
||||
permettant de créer le conteneur LXC, ainsi qu'un exemple de configuration :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
|
|
@ -107,7 +107,7 @@ vous pourriez écrire le script `systemd` et profiter de l'utiliser dans votre
|
|||
recette `bitbake`.
|
||||
|
||||
Un service basé sur `nspawn` peut par contre être potentiellement intéressant,
|
||||
il pourra être intégré au dépôt :
|
||||
il pourra être intégré au dépôt :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
|
|
@ -121,7 +121,7 @@ login_x-TP5/linky2influx/systemd/linky2influx.nspawn
|
|||
Vous pourriez vouloir écrire une recette Bitbake pour créer et déployer le
|
||||
module via un paquet `.ipk` ou similaire en fonction de votre configuration.
|
||||
|
||||
Écrivez la recette au sein de `meta-electropcool` :
|
||||
Écrivez la recette au sein de `meta-electropcool` :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
|
|
@ -146,7 +146,7 @@ utiliser le package Nix ensuite.
|
|||
|
||||
### Snap, Flatpack, AppImage
|
||||
|
||||
Intégrez au dépôt le fichier de description, par exemple :
|
||||
Intégrez au dépôt le fichier de description, par exemple :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
|
|
@ -155,7 +155,7 @@ login_x-TP5/linky2influx/snapcraft.yaml
|
|||
</div>
|
||||
|
||||
Il faudra également préciser avec un fichier `run.sh` la manière dont lancer
|
||||
votre conteneur :
|
||||
votre conteneur :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
|
|
@ -168,7 +168,7 @@ 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 :
|
||||
connaissez déjà, vous pourriez vouloir écrire un *Chart* Helm :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
|
|
@ -176,7 +176,7 @@ login_x-TP5/k3s/linky2influx.yaml
|
|||
```
|
||||
</div>
|
||||
|
||||
Inutile de vous casser la tête avec ça si vous ne connaissez pas !
|
||||
Inutile de vous casser la tête avec ça si vous ne connaissez pas !
|
||||
|
||||
|
||||
### Votre solution
|
||||
|
|
@ -191,4 +191,4 @@ login_x-TP5/k3s/linky2influx.yaml
|
|||
</div>
|
||||
\
|
||||
|
||||
À vous de jouer !
|
||||
À vous de jouer !
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
Voici à quoi pourrait ressembler le playbook Ansible démarrant notre conteneur
|
||||
Drone :
|
||||
Drone :
|
||||
|
||||
<div lang="en-US">
|
||||
```yaml
|
||||
|
|
|
|||
|
|
@ -1,26 +1,36 @@
|
|||
Voici à quoi pourrait ressembler la ligne de commande démarrant notre conteneur
|
||||
Drone :
|
||||
Tout comme Gitea, Drone tire un certain nombre de paramètres depuis son
|
||||
environnement. Nous allons donc commencer par indiquer l'identifiant et le
|
||||
secret de l'application que l'on a créé précédemment dans Gitea :
|
||||
|
||||
<div lang="en-US">
|
||||
```shell
|
||||
export DRONE_GITEA_CLIENT_ID=#FIXME
|
||||
export DRONE_GITEA_CLIENT_SECRET=#FIXME
|
||||
export DRONE_RPC_SECRET=$(openssl rand -base64 30)
|
||||
|
||||
docker container run --name droneci -d \
|
||||
-v /var/lib/drone:/data \
|
||||
--network gitea -p 80:80 \
|
||||
-e DRONE_GITEA_CLIENT_ID -e DRONE_GITEA_CLIENT_SECRET -e DRONE_GITEA_SERVER=http://gitea:3000 \
|
||||
-e DRONE_RPC_SECRET -e DRONE_SERVER_HOST=droneci -e DRONE_SERVER_PROTO=http \
|
||||
drone/drone:1
|
||||
|
||||
docker network connect drone droneci
|
||||
```
|
||||
</div>
|
||||
|
||||
La dernière commande permet à notre conteneur Drone d'être à la fois présent
|
||||
dans le réseau `gitea` et `drone`, ce qui permet de garder les deux réseaux
|
||||
distincts.
|
||||
Puis, tout comme pour Gitea, nous allons générer un secret. Ce secret est
|
||||
utilisé par les différents *worker*s pour s'authentifier :
|
||||
|
||||
<div lang="en-US">
|
||||
```shell
|
||||
export DRONE_RPC_SECRET=$(openssl rand -base64 30)
|
||||
```
|
||||
</div>
|
||||
|
||||
Lançons enfin Drone avec les deux commandes suivantes :
|
||||
|
||||
<div lang="en-US">
|
||||
```shell
|
||||
docker volume create drone_data
|
||||
|
||||
docker container run --name droneci -d -v drone_data:/data --network my_ci_net
|
||||
-p 80:80 -e DRONE_GITEA_CLIENT_ID -e DRONE_GITEA_CLIENT_SECRET \
|
||||
-e DRONE_GITEA_SERVER=http://gitea:3000 -e DRONE_SERVER_PROTO=http \
|
||||
-e DRONE_RPC_SECRET -e DRONE_SERVER_HOST=droneci \
|
||||
drone/drone:2
|
||||
```
|
||||
</div>
|
||||
|
||||
Gardez la variable d'environnement `DRONE_RPC_SECRET` dans un coin, nous en
|
||||
aurons encore besoin juste après.
|
||||
|
|
|
|||
|
|
@ -1,15 +1,7 @@
|
|||
::::: {.question}
|
||||
|
||||
La version 2 de Drone, encore plus pratique et sympathique est disponible en
|
||||
test. Vous pouvez tout à fait l'utiliser pour la suite du TP. Cela ne change
|
||||
pas la version des *runners* à utiliser.
|
||||
|
||||
:::::
|
||||
|
||||
Une fois lancé, rendez-vous sur l'interface de DroneCI : <http://droneci/>
|
||||
Une fois lancé, rendez-vous sur l'interface de DroneCI : <http://droneci/>
|
||||
|
||||
Vous serez automatiquement redirigé vers la page d'authentification de Gitea,
|
||||
puis vers l'autorisation OAuth d'accès de Drone à Gitea. Il faut bien
|
||||
évidemment valider cette demande, afin que Drone ait accès à nos dépôts.
|
||||
|
||||
{width=9cm}
|
||||
{width=9cm}
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
Voici à quoi pourrait ressembler le playbook Ansible démarrant notre agent Drone :
|
||||
Voici à quoi pourrait ressembler le playbook Ansible démarrant notre agent Drone :
|
||||
|
||||
<div lang="en-US">
|
||||
```yaml
|
||||
|
|
|
|||
|
|
@ -1,11 +1,13 @@
|
|||
Voici à quoi pourrait ressembler la ligne de commande démarrant notre agent Drone :
|
||||
\
|
||||
|
||||
Voici La ligne de commande permettant de démarrer notre agent :
|
||||
|
||||
<div lang="en-US">
|
||||
```shell
|
||||
docker container run --name droneci-runner -d \
|
||||
-v /var/run/docker.sock:/var/run/docker.sock --network drone \
|
||||
-e DRONE_RPC_PROTO=http -e DRONE_RPC_HOST=droneci -e DRONE_RPC_SECRET \
|
||||
-e DRONE_RUNNER_CAPACITY=2 -e DRONE_RUNNER_NAME=my-runner -e DRONE_RUNNER_NETWORKS=drone,gitea \
|
||||
docker container run --name droneci-runner -d --network my_ci_net \
|
||||
-v /var/run/docker.sock:/var/run/docker.sock -e DRONE_RPC_PROTO=http
|
||||
-e DRONE_RPC_HOST=droneci -e DRONE_RPC_SECRET -e DRONE_RUNNER_CAPACITY=2 \
|
||||
-e DRONE_RUNNER_NAME=my-runner -e DRONE_RUNNER_NETWORKS=my_ci_net \
|
||||
drone/drone-runner-docker:1
|
||||
```
|
||||
</div>
|
||||
|
|
|
|||
9
tutorial/devops/tools-drone-runner-end.md
Normal file
9
tutorial/devops/tools-drone-runner-end.md
Normal file
|
|
@ -0,0 +1,9 @@
|
|||
::::: {.more}
|
||||
|
||||
On remarquera que l'on partage notre socket Docker : l'exécution de code
|
||||
arbitraire n'aura pas lieu directement dans le conteneur, en fait il s'agit
|
||||
d'un petit orchetrateur qui lancera d'autres conteneurs en fonction des tâches
|
||||
qu'on lui demandera. Le code arbitraire sera donc toujours exécuté dans un
|
||||
conteneur moins privilégié.
|
||||
|
||||
:::::
|
||||
|
|
@ -2,14 +2,13 @@
|
|||
|
||||
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.
|
||||
résultats retournés par les agents chargés d'exécuter les tâches.
|
||||
|
||||
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*.
|
||||
arbitraire s'exécutent à part et peuvent être de différents types.
|
||||
|
||||
Nous allons lancer un *runner* Docker : il s'agit d'un type d'agent qui va
|
||||
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 !)
|
||||
disait que Drone était conçu autour de Docker, c'était pas pour rire !)
|
||||
|
|
|
|||
|
|
@ -8,6 +8,10 @@ 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 !
|
||||
|
||||
Deux conteneurs sont à lancer : nous aurons d'un côté l'interface de contrôle
|
||||
et de l'autre un agent (*runner* dans le vocabulaire de Drone) chargé
|
||||
d'exécuter les tests. Dans un environnement de production, on aura généralement
|
||||
plusieurs agents, et ceux-ci seront situé sur des machines distinctes.
|
||||
|
||||
### Interface de contrôle et de dispatch des tâches
|
||||
|
||||
|
|
@ -19,6 +23,8 @@ Drone va avoir besoin d'authentifier les utilisateurs afin d'accéder aux dépô
|
|||
privés (avec l'autorisation des utilisateurs). Pour cela, comme l'indique la
|
||||
documentation de Drone, on va utiliser OAuth2 : dans Gitea, il va falloir créer
|
||||
une *application OAuth2*. Le formulaire de création se trouve dans la
|
||||
configuration du compte utilisateur, sous l'onglet *Applications*. Drone aura
|
||||
également besoin d'une URL de redirection. Dans notre cas, ce sera :
|
||||
configuration du compte utilisateur, sous l'onglet *Applications*.
|
||||
|
||||
Drone aura également besoin d'une URL de redirection. Dans notre cas,
|
||||
ce sera :\
|
||||
`http://droneci/login`.
|
||||
|
|
|
|||
|
|
@ -1 +1 @@
|
|||
L'environnement étant prêt, il ne reste plus qu'à nous lancer dans nos projets !
|
||||
L'environnement étant prêt, il ne reste plus qu'à nous lancer dans nos projets !
|
||||
|
|
|
|||
|
|
@ -1,13 +1,17 @@
|
|||
Votre playbook ressemblera à quelque chose comme ça :
|
||||
Votre playbook ressemblera à quelque chose comme ça :
|
||||
|
||||
<div lang="en-US">
|
||||
```yaml
|
||||
- name: Launch gitea container
|
||||
- name: Create a volume for storing repositories
|
||||
docker_volume:
|
||||
name: gitea-data
|
||||
|
||||
- name: launch gitea container
|
||||
docker_container:
|
||||
name: gitea
|
||||
image: "gitea/gitea:{{ version }}"
|
||||
volumes:
|
||||
- /var/lib/gitea:/data
|
||||
- gitea-data:/data
|
||||
- /etc/localtime:/etc/localtime:ro
|
||||
- /etc/timezone:/etc/timezone:ro
|
||||
state: started
|
||||
|
|
@ -27,3 +31,5 @@ Votre playbook ressemblera à quelque chose comme ça :
|
|||
SECRET_KEY: "{{ secret_key }}"
|
||||
```
|
||||
</div>
|
||||
|
||||
Plus d'infos sur cette page : <https://docs.gitea.io/en-us/install-with-docker/>.
|
||||
|
|
|
|||
|
|
@ -1,13 +1,33 @@
|
|||
La ligne de commande pour lancer Gitea ressemblera à quelque chose comme ça :
|
||||
Commençons par créer un nouveau volume `gitea-data`, celui-ci contiendra
|
||||
les données de `gitea` (nos dépôts Git, mais également la configuration propre
|
||||
à `gitea`) :
|
||||
|
||||
<div lang="en-US">
|
||||
```shell
|
||||
docker volume create gitea-data
|
||||
```
|
||||
</div>
|
||||
|
||||
Afin de simplifier l'installation de notre conteneur, nous allons utiliser un
|
||||
maximum de paramètres par défaut. Il faudra toutefois générer une clef secrète
|
||||
propre à l'installation. Puisque c'est temporaire, on peut se contenter de ne
|
||||
pas la stocker (elle sera perdue si on ferme notre terminal) :
|
||||
|
||||
<div lang="en-US">
|
||||
```shell
|
||||
export SECRET_KEY=$(openssl rand -base64 30)
|
||||
```
|
||||
</div>
|
||||
|
||||
docker container run --name gitea -d \
|
||||
-v /var/lib/gitea:/data -v /etc/timezone:/etc/timezone:ro -v /etc/localtime:/etc/localtime:ro \
|
||||
--network gitea -p 2222:22 -p 3000:3000 \
|
||||
-e RUN_MODE=prod -e DOMAIN=gitea -e SSH_DOMAIN=gitea -e INSTALL_LOCK=true -e SECRET_KEY \
|
||||
Pour finir, lançons notre conteneur `gitea` :
|
||||
|
||||
<div lang="en-US">
|
||||
```shell
|
||||
docker container run --name gitea --network my_ci_net -p 2222:22 -p 3000:3000 \
|
||||
-v /etc/localtime:/etc/localtime:ro -v /etc/timezone:/etc/timezone:ro \
|
||||
-v gitea-data:/data \
|
||||
-e RUN_MODE=prod -e DOMAIN=gitea -e SSH_DOMAIN=gitea -e INSTALL_LOCK=true \
|
||||
-e SECRET_KEY -d \
|
||||
gitea/gitea:1
|
||||
```
|
||||
</div>
|
||||
|
|
|
|||
|
|
@ -1,15 +1,15 @@
|
|||
Plus d'infos sur cette page : <https://docs.gitea.io/en-us/install-with-docker/>.
|
||||
Une fois le conteneur lancé, vous pouvez accéder à l'interface de votre
|
||||
gestionnaire de versions sur le port 3000 de votre machine (à moins que vous
|
||||
n'ayez opté pour un autre port).
|
||||
\
|
||||
|
||||
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 :
|
||||
Vous pouvez ajouter un nouvel administrateur avec la commande suivante :
|
||||
|
||||
<div lang="en-US">
|
||||
```bash
|
||||
docker exec gitea gitea admin user create --username "${USER}" --random-password \
|
||||
--must-change-password=false --admin --email "${USER}@epita.fr"
|
||||
docker exec gitea gitea admin user create --username "${USER}" --admin \
|
||||
--must-change-password=false --random-password --email "${USER}@example.com"
|
||||
```
|
||||
</div>
|
||||
|
||||
Notez le mot de passe généré pour [vous y connecter](http://localhost:3000/user/login).
|
||||
Notez le mot de passe généré pour ensuite vous y connecter.
|
||||
|
|
|
|||
|
|
@ -21,7 +21,7 @@ que l'on peut lier avec ses dépôts. Une fonctionnalité que GitLab propose
|
|||
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 ...`, ...
|
||||
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
|
||||
|
|
@ -33,11 +33,11 @@ Dans un premier temps, nous allons nous contenter de publier un binaire associé
|
|||
|
||||
### Installation et configuration
|
||||
|
||||
Allez c'est parti ! première chose à faire : installer et configurer
|
||||
Allez 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 sera
|
||||
moins guidée).
|
||||
|
||||
Nous allons utiliser l'image :
|
||||
Nous allons utiliser l'image :
|
||||
[`gitea/gitea`](https://hub.docker.com/r/gitea/gitea) (ou
|
||||
[`gitlab/gitlab-ce`](https://hub.docker.com/r/gitlab/gitlab-ce)).
|
||||
|
|
|
|||
16
tutorial/devops/what-ansible.md
Normal file
16
tutorial/devops/what-ansible.md
Normal file
|
|
@ -0,0 +1,16 @@
|
|||
## Préparer le terrain
|
||||
|
||||
Tous les déploiements sont à faire sur votre machine en utilisant des
|
||||
conteneurs Docker, qui seront regroupés au sein de réseaux
|
||||
Docker. Cela vous permettra d’utiliser la résolution de noms entre vos
|
||||
conteneurs.
|
||||
|
||||
Dans votre playbook Ansible, vous pourrez procéder ainsi :
|
||||
|
||||
<div lang="en-US">
|
||||
```yaml
|
||||
- name: Create virli network
|
||||
docker_network:
|
||||
name: virli3
|
||||
```
|
||||
</div>
|
||||
15
tutorial/devops/what-cmd.md
Normal file
15
tutorial/devops/what-cmd.md
Normal file
|
|
@ -0,0 +1,15 @@
|
|||
## Préparer le terrain
|
||||
|
||||
Tous les déploiements sont à faire sur votre machine ; la plate-forme de CI
|
||||
utilisera massivement les conteneurs Docker, qui seront regroupés au sein de
|
||||
réseaux Docker : cela nous permettra de profiter de la résolution de noms entre
|
||||
les conteneurs.
|
||||
|
||||
Dès à présent, nous pouvons commencer par créer un réseau, dans lequel nous
|
||||
placerons tous nos conteneurs de CI/CD :
|
||||
|
||||
<div lang="en-US">
|
||||
```shell
|
||||
docker network create my_ci_net
|
||||
```
|
||||
</div>
|
||||
|
|
@ -3,7 +3,7 @@
|
|||
Électropcool
|
||||
============
|
||||
|
||||
Bienvenue dans la société Électropcool !
|
||||
Bienvenue dans la société Électropcool !
|
||||
|
||||
Électropcool est une société française spécialisée dans
|
||||
l'[immotique](https://fr.wikipedia.org/wiki/Immotique), elle vend des
|
||||
|
|
@ -20,14 +20,14 @@ en combustible (liés à la météo)[^HOMEASSISTANT].
|
|||
|
||||
[^HOMEASSISTANT]: Si ça vous met l'eau à la bouche, jettez un œil du côté du
|
||||
projet <https://www.home-assistant.io/> qui fait un peu moins de
|
||||
*bullshit*, mais est bien réel !
|
||||
*bullshit*, mais est bien réel !
|
||||
|
||||
La principale difficulté que rencontre Électropcool est qu'aucun bâtiment ne
|
||||
dispose des mêmes références de pièces et qu'en dehors des nouveaux bâtiments
|
||||
pour lesquels la société peut imposer des équipements électroniques
|
||||
spécifiquement supportés et compatibles avec la plate-forme qu'elle vend, il lui
|
||||
est bien souvent nécessaire de faire des développements spécifiques pour
|
||||
s'interfacer avec de l'électronique existant : c'est notamment le cas pour les
|
||||
s'interfacer avec de l'électronique existant : c'est notamment le cas pour les
|
||||
chaudières et les
|
||||
[VMC](https://fr.wikipedia.org/wiki/Ventilation_m%C3%A9canique_contr%C3%B4l%C3%A9e),
|
||||
qui, compte tenu de leur coût de remplacement prohibitif, nécessitent souvent
|
||||
|
|
@ -74,7 +74,7 @@ retiendrez.)
|
|||
\
|
||||
|
||||
Le projet qui vous servira de base pour vos tests sera
|
||||
[`linky2influx`](https://git.nemunai.re/nemunaire/linky2influx) : à partir d'un
|
||||
[`linky2influx`](https://git.nemunai.re/nemunaire/linky2influx) : à partir d'un
|
||||
compteur [Linky](https://fr.wikipedia.org/wiki/Linky), branché sur les bornes
|
||||
de [téléinformation client du
|
||||
compteur](https://hallard.me/demystifier-la-teleinfo/) et [lisant le
|
||||
|
|
@ -92,36 +92,3 @@ gestionnaire de versions.
|
|||
|
||||
Nous testerons enfin différentes solution pour déployer notre binaire, afin
|
||||
d'établir quelle est la solution adéquate.
|
||||
|
||||
|
||||
## Préparer le terrain
|
||||
|
||||
Tous les déploiements sont à faire sur votre machine et la plate-forme de CI
|
||||
utilisera massivement les 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.
|
||||
|
||||
Vous devriez dès maintenant créer les deux réseaux suivants sur votre machines :
|
||||
|
||||
<div lang="en-US">
|
||||
```shell
|
||||
docker network create gitea
|
||||
docker network create drone
|
||||
```
|
||||
</div>
|
||||
|
||||
|
||||
Étant donné que votre machine ne dispose pas de domaine sur Internet et que
|
||||
l'on va essayer de simplifier au maximum l'installation, vous devriez ajouter
|
||||
cette ligne à votre fichier `/etc/hosts` (ou
|
||||
`\Windows\System32\drivers\etc\hosts`) :
|
||||
|
||||
<div lang="en-US">
|
||||
```conf
|
||||
127.0.0.1 gitea droneci
|
||||
```
|
||||
</div>
|
||||
|
||||
Cette ligne va vous permettre de résoudre les noms des conteneurs. Cela
|
||||
permettra aux requêtes OAuth de se faire de manière transparente pour vous
|
||||
lorsque vous serez dans votre navigateur.
|
||||
|
|
|
|||
14
tutorial/devops/what-hosts.md
Normal file
14
tutorial/devops/what-hosts.md
Normal file
|
|
@ -0,0 +1,14 @@
|
|||
É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` (ou
|
||||
`\Windows\System32\drivers\etc\hosts`) :
|
||||
|
||||
<div lang="en-US">
|
||||
```conf
|
||||
127.0.0.1 gitea droneci
|
||||
```
|
||||
</div>
|
||||
|
||||
Cette ligne va vous permettre de résoudre les noms des conteneurs. Cela
|
||||
permettra aux requêtes OAuth de se faire de manière transparente pour vous
|
||||
lorsque vous serez dans votre navigateur.
|
||||
32
tutorial/devops/what-srs.md
Normal file
32
tutorial/devops/what-srs.md
Normal file
|
|
@ -0,0 +1,32 @@
|
|||
\newpage
|
||||
|
||||
But du TP
|
||||
=========
|
||||
|
||||
Nous allons nous mettre aujourd’hui dans la peau d’une équipe DevOps et
|
||||
réaliser une solution complète d’intégration/déploiement continu (le fameux
|
||||
CI/CD, pour *Continuous Integration* et *Continuous Delivery*).
|
||||
|
||||
Le résultat attendu d’ici la fin de cette partie sera de mettre en place toutes
|
||||
les briques décrites dans la section précédente.
|
||||
\
|
||||
|
||||
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~~
|
||||
(merci Nabih !).
|
||||
|
||||
Il est également attendu que vous rendiez un playbook Ansible, permettant de
|
||||
retrouver un environnement similaire. Car on pourra s’en resservir par la
|
||||
suite.
|
||||
\
|
||||
|
||||
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 associée. C’est à partir de cette image Docker
|
||||
que l’on va commencer à déployer automatiquement...
|
||||
|
|
@ -1,64 +1,25 @@
|
|||
\newpage
|
||||
|
||||
But du TP
|
||||
=========
|
||||
La journée DevOps
|
||||
=================
|
||||
|
||||
Nous allons nous mettre aujourd'hui dans la peau d'une équipe DevOps et
|
||||
Nous allons maintenant nous mettre dans la peau d'une équipe DevOps et
|
||||
réaliser une solution complète d'intégration/déploiement continu (le fameux
|
||||
CI/CD, pour *Continuous Integration* et *Continuous Delivery*).
|
||||
|
||||
Le résultat attendu d'ici la fin de cette partie sera de mettre en place toutes
|
||||
les briques décrites dans la section précédente.
|
||||
\
|
||||
|
||||
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~~
|
||||
(merci Nabih !).
|
||||
|
||||
Il est également attendu que vous rendiez un playbook Ansible, permettant de
|
||||
retrouver un environnement similaire. Car on pourra s'en resservir par la suite.
|
||||
les briques décrites au chapitre précédent. Nous allons pour cela automatiser
|
||||
le projet `youp0m`, que l'on connaît déjà bien.
|
||||
\
|
||||
|
||||
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.
|
||||
que chaque *commmit* poussé ne contient pas d'erreur de compilation (dans
|
||||
l'environnement défini comme étant celui de production, donc avec une version
|
||||
précise des outils de compilation). Ensuite, nous ajouterons quelques tests
|
||||
automatiques, puis nous publierons automatiquement le binaire `youp0m` comme
|
||||
fichier associé à un tag au sein de l'interface web d'un gestionnaire de
|
||||
versions.
|
||||
|
||||
Enfin, nous mettrons en place un registre Docker qui nous permettra de publier
|
||||
automatiquement l'image Docker associée. C'est à partir de cette image Docker
|
||||
que l'on va commencer à déployer automatiquement...
|
||||
|
||||
|
||||
## Préparer le terrain
|
||||
|
||||
Tous les déploiements sont à faire sur votre machine en utilisant des
|
||||
conteneurs Docker, qui seront regroupés au sein de réseaux Docker. Cela vous
|
||||
permettra d'utiliser la résolution de noms entre vos conteneurs.
|
||||
|
||||
Dans votre playbook Ansible, vous pourrez procéder ainsi :
|
||||
|
||||
<div lang="en-US">
|
||||
```yaml
|
||||
- name: Create virli network
|
||||
docker_network:
|
||||
name: virli3
|
||||
```
|
||||
</div>
|
||||
|
||||
|
||||
Étant donné que votre machine ne dispose pas de domaine sur Internet et que
|
||||
l'on va essayer de simplifier au maximum l'installation, vous devriez ajouter
|
||||
cette ligne à votre fichier `/etc/hosts` (ou
|
||||
`\Windows\System32\drivers\etc\hosts`) :
|
||||
|
||||
<div lang="en-US">
|
||||
```conf
|
||||
127.0.0.1 gitea droneci
|
||||
```
|
||||
</div>
|
||||
|
||||
Cette ligne va vous permettre de résoudre les noms des conteneurs. Cela
|
||||
permettra aux requêtes OAuth de se faire de manière transparente pour vous
|
||||
lorsque vous serez dans votre navigateur.
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue