Commit 8dcdee29 authored by Rémi Cailletaud's avatar Rémi Cailletaud

exo 14 et 15

parent 1dd61cd5
......@@ -2,6 +2,8 @@
Le TP est une suite de petits exercices consistant à écrire à chaque fois un fichier .gitlab-ci.yml.
Prérequis : des bases de git, python, docker.
Le code source est fourni. Après l'échauffement, Nous allons travailler sur deux (tout) petits codes :
* python-extension : une extension python en C, pour voir un peu de vraie compilation, quand même ;
......@@ -140,7 +142,7 @@ Vérifier que la documentation est bien déployée (le lien est disponible dans
L'utilitaire *coverage* (disponible dans *pip*) permet d'obtenir le taux de couverture de vos tests, indicateur intéressant de la qualité du code. Cette information (ainsi que le status du pipeline) peut apparaître par exemple dans votre doc grâce aux désormais très populaires [Badges](https://docs.gitlab.com/ee/user/project/pipelines/settings.html#test-coverage-report-badge)
**But** : Ajouter les tests de couveture au job de test. Dans *Settings -> CI/CD -> General*, spécifier la regexp permettant de récupérer le taux de couverture, et récupérer le code HTMl et/ou Markdown à ajouter à la doc et/ou au fichier README.md.
**But** : Ajouter les tests de couveture au job de test. Dans *Settings -> CI/CD -> General pipelines*, spécifier la regexp permettant de récupérer le taux de couverture, et récupérer le code HTMl et/ou Markdown à ajouter à la doc et/ou au fichier README.md.
*Note 1* : Pour lancer les tests de couverture
```bash
......@@ -154,10 +156,9 @@ coverage report
TOTAL\s+\d+\s+\d+\s+(\d+\%)$
```
### 13. Le déploiement sur Pypi ###
Nous allons maintenant déployer notre module sur l'instance de test de Pypi à l'aide de *twine*, disponible dans *pip*. Le déploiement ne se fait que pour les branches ou tags nommés "version-\*", grâce à l'utilisation du mot-clé [only](https://docs.gitlab.com/ee/ci/yaml/#only-and-except-simplified). Pour éviter de spécifier les identifiants dans le dépôt, nous utilisons les variables Gitlab (*Settings -> CI/CD*).
Nous allons maintenant déployer notre module sur l'instance de test de Pypi à l'aide de *twine*, disponible dans *pip*. Le déploiement ne se fait que pour les branches ou tags nommés "version-\*", grâce à l'utilisation du mot-clé [only](https://docs.gitlab.com/ee/ci/yaml/#only-and-except-simplified). Pour éviter de spécifier les identifiants dans le dépôt, nous utilisons les variables Gitlab (*Settings -> CI/CD -> Varilables*).
But : Ajouter une étape qui va construire et déployer le paquet sur Pypi si le nom de la référence (branche ou tag) commence par *version-*. Utiliser les variables Gitlab pour les identifiants. Pousser un nouveau tag/branche, vérifier que le paquet est bien déployé, et que vous pouvez l'installer via pip.
......@@ -172,7 +173,41 @@ pip wheel . -w wheelhouse
*Note 4* : Pour les gros projets multi-depôts, il est conseillé d'utiliser plutôt des outils dédiés pour la gestion de secrets (comme [Hashicorp Vault](https://www.vaultproject.io/).
### 14. docker: construire et déployer une image docker en production - docker info pr vérfier qu'on est bien sur distant - évidemment on le fait normamlement sur une branche spéciale (production) ###
### 14. Dockerception ###
[dice-http-server](pyton-dice/dice-http-server) est un petit serveur web qui permet d'utiliser dice. Par exemple, l'appel à la page http://serveur/4-6 tirera 4 dés à 6 faces. Nous allons maintenant construire un conteneur Docker et le déployer sur notre infrastructure. Comme nous sommes prudents, le déploiement de l'image sera manuel.
Pour cela, nous allons avoir besoin du [Service](https://docs.gitlab.com/ee/ci/services/) *docker:dind*, qui permet de fournir le démon docker au conteneur exécutant notre job. Notre instance de Gitlab ne fournissant pour l'instant pas de registry, nous utiliserons Docker Hub. Nous utiliserons là encore les variables Gitlab pour spécifier les identifiants.
But : Construire une image docker grâce au Dockerfile fournit, la pousser sur DockerHub, et permettre son déploiement en production manuel. Lors de la mise à jour, utiliser docker pull stopper l'ancien conteneur avant de lancer le nouveau.
*Note 1* : Demandez le nom du serveur Docker...
*Note 2* : Afin d'éviter les conflits, exposez votre conteneur sur le port 80x0 avec x le numéro du dépôt (ex : port 8010 pour fomration-ci-01).
*Note 2* : Évidemment, dans la réalité nous ne déploierons pas en production depuis le master... Jetez aussi un oeil aux [Environments](https://gricad-gitlab.univ-grenoble-alpes.fr/help/ci/environments).
*Note 3* : Idéalement, notre conteneur doit lui aussi recevoir une série de tests avant d'être déployé !
### 15. Canary Release ###
Un des patterns du déploiement continu est le Blue/Green Deployment[^1] (et sa variante Canary Release). Il consiste à avoir plusieurs conteneurs en production, et les mettre à jour de manière progressive afin de détecter d'éventuelles anomalies.
![canary](img/canary-relase.png)
Nous allons maintenant déployer deux conteneurs (dice-green et dice-blue), en utilisant une fonctionnalité YAML appelée [Anchors](https://docs.gitlab.com/ee/ci/yaml/#anchors) qui permet de factoriser du code.
*But* : Deéployer deux conteneurs dice-blue et dice-green. Les jobs sont distincts et manuels.
*Note* : Parmi les [variables Gitlab prédéfinies](https://docs.gitlab.com/ee/ci/variables/README.html#predefined-variables-environment-variables) `$CI_JOB_NAME` pourrait vous intéresser...
*Note*: Utilisez les ports 80x0 et 80x1...
[^1]:https://martinfowler.com/bliki/BlueGreenDeployment.html
blue/green ? templates (en fait anchors YAML)
### 15. blue/green ? templates (en fait anchors YAML) ###
### 16. bonus : répertoire infra, haproxy, docker-compose.yml ###
Maintenant, montez l'infrastructure complète grâce à docker-compose, avec un HAProxy en frontend et deux (ou plus) conteneurs dice en backend....
*Note* : Si vous êtes arrivés jusque là, on ne vous aide plus !
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment