tuto5-srs: Done
This commit is contained in:
parent
93a652e5aa
commit
44d777f00e
|
|
@ -0,0 +1 @@
|
|||
../devops/gitea-packages.png
|
||||
|
|
@ -0,0 +1 @@
|
|||
../devops/gitea-webhooks.png
|
||||
|
|
@ -3,51 +3,69 @@
|
|||
Rendu
|
||||
=====
|
||||
|
||||
Modalités de rendu
|
||||
------------------
|
||||
Est attendu d'ici le cours suivant :
|
||||
|
||||
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/13).
|
||||
- vos réponses à l'évaluation du cours,
|
||||
- tous les exercices de ce TP.
|
||||
|
||||
|
||||
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/cicd-playbook/
|
||||
login_x-TP5/cicd-playbook/cicd-setup.yml
|
||||
login_x-TP5/cicd-playbook/roles/...
|
||||
login_x-TP5/youp0m/
|
||||
login_x-TP5/youp0m/.drone.yml
|
||||
login_x-TP5/youp0m/.ansible/... # Pour ceux qui auraient fait le 5.4 optionnel
|
||||
login_x-TP5/youp0m/Dockerfile
|
||||
login_x-TP5/youp0m/entrypoint.sh
|
||||
login_x-TP5/youp0m/.dockerignore
|
||||
login_x-TP5/youp0m/...
|
||||
./cicd-playbook/
|
||||
./cicd-playbook/cicd-setup.yml
|
||||
./cicd-playbook/roles/...
|
||||
./youp0m/
|
||||
./youp0m/.drone.yml
|
||||
./youp0m/.ansible/... # Pour ceux qui auraient fait le 5.4 optionnel
|
||||
./youp0m/Dockerfile
|
||||
./youp0m/entrypoint.sh
|
||||
./youp0m/.dockerignore
|
||||
./youp0m/...
|
||||
```
|
||||
</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 TP5
|
||||
sur `rendu5`, ... 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).
|
||||
|
||||
::::
|
||||
|
|
|
|||
|
|
@ -3,26 +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
|
||||
|
||||
\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,14 +1,17 @@
|
|||
\newpage
|
||||
|
||||
## 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 !
|
||||
|
||||
L'idée est qu'à chaque nouveau *commit* envoyé sur le dépôt, Drone fasse une
|
||||
série de tests, le compile et publie les produits de compilation.
|
||||
|
||||
### Créez un dépôt pour `youp0m`
|
||||
|
||||
Reprenez les travaux déjà réalisés : nous allons notamment avoir besoin du
|
||||
`Dockerfile` que nous avons réalisé pour ce projet `youp0m`.
|
||||
::::: {.exercice}
|
||||
|
||||
Reprenons les travaux déjà réalisés : nous allons notamment avoir besoin du
|
||||
`Dockerfile` que nous avons réalisé pour le projet `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
|
||||
|
|
@ -16,6 +19,33 @@ 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.
|
||||
|
|
@ -30,9 +60,6 @@ installation.
|
|||
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/>.
|
||||
|
|
@ -40,9 +67,18 @@ trouvent dans l'excellente documentation du projet :\
|
|||
Les étapes sont sensiblement les mêmes que dans le `Dockerfile` que nous avons
|
||||
écrit précédemment.
|
||||
|
||||
Committons puis poussons notre travail. Dès qu'il sera reçu par Gitea, nous
|
||||
::::: {.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}
|
||||
|
|
@ -58,7 +94,7 @@ 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
|
||||
`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 :
|
||||
|
|
@ -72,14 +108,18 @@ docker run --rm -d --name sonarqube --network drone -p 9000:9000 sonarqube
|
|||
Le service met un bon moment avant de démarrer, dès qu'il se sera initialisé,
|
||||
nous pourrons accéder à l'interface sur <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
|
||||
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.
|
||||
|
||||
|
|
@ -90,6 +130,8 @@ 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.
|
||||
|
||||
|
|
@ -98,13 +140,22 @@ 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 !
|
||||
::::: {.warning}
|
||||
|
||||
{height=8cm}
|
||||
#### Attention à ne pas stocker votre clef d'API dans le fichier YAML ! {-}
|
||||
\
|
||||
|
||||
::::: {.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.
|
||||
|
||||
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}
|
||||
|
|
|
|||
|
|
@ -59,7 +59,7 @@ production. Ce sont les équipes SRE, pour Site Reliability Engineering. On
|
|||
confie alors complètement la responsabilité de l'environnement de production
|
||||
aux développeurs qui sont chargés de l'automatiser. Au-delà de l'automatisation
|
||||
des déploiements de services, il s'agit ici de développer des mécanismes
|
||||
permettant au système de réagir face aux situations telles que les montées en
|
||||
permettant aux systèmes de réagir face aux situations telles que les montées en
|
||||
charges, les pannes, ...
|
||||
|
||||
::::: {.warning}
|
||||
|
|
@ -118,7 +118,7 @@ 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 à
|
||||
publient des paquets à destination de leurs communautés, et ils mettent à
|
||||
jour leur service en ligne.\
|
||||
|
||||
Il existe pour cela de très nombreuses stratégies : lorsque l'on n'a pas
|
||||
|
|
|
|||
Binary file not shown.
|
After Width: | Height: | Size: 52 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 88 KiB |
|
|
@ -1,7 +1,4 @@
|
|||
\newpage
|
||||
|
||||
Publier une image Docker
|
||||
========================
|
||||
### Publier une image Docker
|
||||
|
||||
Toutes les tâches de publication peuvent s'assimiler à des tâches de
|
||||
déploiement continu. C'est en particulier le cas lorsque le produit de
|
||||
|
|
@ -11,79 +8,97 @@ testés, les paquets sont envoyés sur le serveur d'où ils seront distribués
|
|||
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. Pour simplifier le
|
||||
déploiement, nous utilisons une image Docker. Il faut cependant la générer ...
|
||||
un service qu'il faut déployer pour le mettre à jour. Afin de simplifier son
|
||||
déploiement en production, nous utiliserons une image Docker.
|
||||
|
||||
|
||||
## Mise en place du registre
|
||||
#### Fonctionnement du registre de Gitea \
|
||||
|
||||
::::: {.more}
|
||||
Si vous avez choisi Gitlab, vous pouvez utiliser directement le registre
|
||||
Docker intégré. Si vous utilisez Gitea, continuez cette section.
|
||||
:::::
|
||||
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 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 :
|
||||
Afin de pouvoir envoyer une image nous-même, nous devons nous connecter au
|
||||
registre :
|
||||
|
||||
<div lang="en-US">
|
||||
```bash
|
||||
docker run --rm -d --name registry --network droneci -p 5000:5000 \
|
||||
registry:2
|
||||
```
|
||||
</div>
|
||||
|
||||
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 :
|
||||
|
||||
<div lang="en-US">
|
||||
```bash
|
||||
42sh$ curl http://localhost:5000/v2/
|
||||
{}
|
||||
```
|
||||
</div>
|
||||
|
||||
|
||||
## 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 :\
|
||||
<http://plugins.drone.io/drone-plugins/drone-docker/>.
|
||||
|
||||
Sans plus de configuration, le registre que nous avons démarré
|
||||
n'attend pas d'authentification. Et comme il n'a pas de certificat TLS
|
||||
pour utiliser `https`, il est nécessaire de définir l'option
|
||||
`insecure` à `true`.
|
||||
|
||||
|
||||
## Test de l'image
|
||||
|
||||
Sur l'hôte, nous pouvons tester que l'image a bien été publiée grâce à la
|
||||
commande suivante :
|
||||
|
||||
<div lang="en-US">
|
||||
```bash
|
||||
docker run --rm -p 8080:8080 localhost:5000/youp0m
|
||||
docker login localhost:3000
|
||||
```
|
||||
</div>
|
||||
|
||||
::::: {.question}
|
||||
On notera que ceci est possible exclusivement parce que le registre
|
||||
`localhost:5000` est considéré non-sûr par défaut. C'est-à-dire qu'il n'a pas
|
||||
besoin de certificat TLS sur sa connexion HTTP pour être utilisé.\
|
||||
Si on avait dû utiliser un autre nom de domaine, il aurait fallu
|
||||
[l'ajouter à la liste des
|
||||
|
||||
#### 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.
|
||||
|
||||
:::::
|
||||
|
||||
|
||||
## Suite du déploiement
|
||||
#### Test de l'image \
|
||||
|
||||
Nous en resterons là pour le déploiement, car nous n'avons
|
||||
pas d'environnement de production sur lequel déployer notre service.
|
||||
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
|
||||
|
|
@ -92,7 +107,7 @@ 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
|
||||
|
|
|
|||
|
|
@ -11,4 +11,4 @@ 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
|
||||
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, ce n'était pas pour rire !)
|
||||
|
|
|
|||
|
|
@ -32,4 +32,5 @@ Votre playbook ressemblera à quelque chose comme ça :
|
|||
```
|
||||
</div>
|
||||
|
||||
Plus d'infos sur cette page : <https://docs.gitea.io/en-us/install-with-docker/>.
|
||||
Vous trouverez plus d'infos sur cette page :
|
||||
<https://docs.gitea.io/en-us/install-with-docker/>.
|
||||
|
|
|
|||
|
|
@ -6,17 +6,19 @@ gestionnaire de versions. Nous allons ici utiliser Git.
|
|||
|
||||
### Problématique du stockage des produits de compilation
|
||||
|
||||
Outre les interfaces rudimentaires fournies au-dessus de Git
|
||||
([gitweb](https://git.wiki.kernel.org/index.php/Gitweb)), il y a de nombreux
|
||||
projets qui offrent davantage que le simple hébergement de dépôts. Vous pouvez
|
||||
voir sur GitHub notamment qu'il est possible d'attacher à un tag un [certain
|
||||
nombre de fichiers](https://github.com/docker/compose/releases/latest).
|
||||
Outre les interfaces rudimentaires fournies au-dessus de Git (gitweb[^GITWEB],
|
||||
gitolite[^GITOLITE], ...), il y a de nombreux projets qui offrent davantage que
|
||||
le simple hébergement de dépôts. Vous pouvez voir sur GitHub notamment qu'il
|
||||
est possible d'attacher à un tag un [certain nombre de
|
||||
fichiers](https://github.com/docker/compose/releases/latest).
|
||||
Mais cela ne s'arrête pas là puisque [depuis 2020 pour
|
||||
GitHub](https://github.blog/2020-09-01-introducing-github-container-registry/)
|
||||
et [2016 pour
|
||||
GitLab](https://about.gitlab.com/blog/2016/05/23/gitlab-container-registry/),
|
||||
ces gestionnaires de versions intégrent carrément un registre Docker.
|
||||
|
||||
On notera également que depuis le 1er septembre, GitHub propose un [registre
|
||||
Docker](https://github.blog/2020-09-01-introducing-github-container-registry/)
|
||||
que l'on peut lier avec ses dépôts. Une fonctionnalité que GitLab propose
|
||||
[depuis
|
||||
2016](https://about.gitlab.com/blog/2016/05/23/gitlab-container-registry/).
|
||||
[^GITWEB]: <https://git.wiki.kernel.org/index.php/Gitweb>
|
||||
[^GITOLITE]: <https://github.com/sitaramc/gitolite>
|
||||
|
||||
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
|
||||
|
|
@ -27,17 +29,11 @@ Des programmes et services se sont spécialisés là-dedans, citons notamment
|
|||
[Artifactory](https://jfrog.com/artifactory/) ou [Nexus
|
||||
Repository](https://www.sonatype.com/nexus/repository-oss) et bien d'autres.
|
||||
|
||||
Dans un premier temps, nous allons nous contenter de publier un binaire associé
|
||||
à un tag de notre projet.
|
||||
|
||||
|
||||
### Installation et configuration
|
||||
|
||||
Aller c'est parti ! première chose à faire : installer et configurer
|
||||
[Gitea](https://gitea.io/) (ceux qui le souhaitent peuvent choisir
|
||||
[gitlab](https://gitlab.org/) ou une autre plate-forme, mais la suite sera
|
||||
moins guidée).
|
||||
[Gitea](https://gitea.io/).
|
||||
|
||||
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)).
|
||||
[`gitea/gitea`](https://hub.docker.com/r/gitea/gitea).
|
||||
|
|
|
|||
|
|
@ -1 +0,0 @@
|
|||
\newpage
|
||||
|
|
@ -5,7 +5,8 @@ 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 :
|
||||
Dans votre playbook Ansible, vous pourrez procéder ainsi (il s'agit d'un
|
||||
exemple qu'il faut comprendre et adapter par rapport à la suite) :
|
||||
|
||||
<div lang="en-US">
|
||||
```yaml
|
||||
|
|
|
|||
|
|
@ -11,22 +11,20 @@ Le résultat attendu d’ici la fin de cette partie sera de mettre en place tout
|
|||
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 !).
|
||||
Nous allons pour cela automatiser le projet `youp0m`.
|
||||
|
||||
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.
|
||||
retrouver un environnement similaire. Car on pourra s’en resservir au prochain
|
||||
cours.
|
||||
\
|
||||
|
||||
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
|
||||
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...
|
||||
Enfin, `youp0m` produisant une image Docker, en plus de publier le binaire,
|
||||
nous publierons l'image produite sur un registre Docker. C’est à partir de
|
||||
cette image Docker que l’on va commencer à déployer automatiquement...
|
||||
|
|
|
|||
Loading…
Reference in New Issue