Commit ae170a99 authored by Rémi Cailletaud's avatar Rémi Cailletaud

fix readme

parent 564f2e82
......@@ -6,9 +6,9 @@ Le TP consiste en une suite de petits exercices consistant à écrire à chaque
Le code source est fourni. Après l'échauffement, nous travaillerons sur deux (tout) petits codes :
* python-extension : une extension python en C, pour voir un peu de vraie compilation, quand même ;
* python-dice : un module pur python d'une ligne, qui tire les dés. Avec lui nous irons des tests au déploiement en production en passant par la mise ne ligne de la documentation et la publication sur pypi.
* python-dice : un module pur python d'une ligne, qui tire les dés. Avec lui nous irons des tests au déploiement en production en passant par la mise en ligne de la documentation et la publication sur pypi.
À chaque fois, nous fournissons les mots-clés à chercher dans la [documentation très complète de gitlab](https://docs.gitlab.com/ee/ci/yaml/README.html). Comme nous sommes gentils, nous fournissons aussi les solutions dans les fichiers .gitlab-ci-\*.yml. Vous pouvez tricher !
À chaque étape, nous fournissons les mots-clés à chercher dans la [documentation très complète de gitlab](https://docs.gitlab.com/ee/ci/yaml/README.html). Comme nous sommes gentils, nous fournissons aussi les solutions dans les fichiers .gitlab-ci-\*.yml. Vous pouvez tricher !
*Note* : Nous conseillons fortement l'utilisation de virtualenv pour les tests locaux.
......@@ -65,7 +65,7 @@ Observer le comportement dans l'interface, puis ajouter autoriser l'échec pour
### 4. Une étape manuelle ###
Le mot-clé [when](https://docs.gitlab.com/ee/ci/yaml/#when) permet de définir quand le job est exécuté : en cas de succès(comportement par défaut), d'échec, quoi qu'il arrive, ou manuellement.
Le mot-clé [when](https://docs.gitlab.com/ee/ci/yaml/#when) permet de définir quand le job est exécuté : en cas de succès (comportement par défaut), d'échec, quoi qu'il arrive, ou manuellement.
**But** : Ajouter un job manuel au pipeline. Lancer son exécution depuis l'interface.
......@@ -74,7 +74,7 @@ Le mot-clé [when](https://docs.gitlab.com/ee/ci/yaml/#when) permet de définir
### 5. Pousser des modifications sans lancer le pipeline ###
Dans certains cas, on veut pouvoir pousser des changements sans lancer le pipeline. Pour cela, il suffit de spécifier [skpi-ci] ou [ci-skip] dans le message de commit.
Dans certains cas, on veut pouvoir pousser des changements sans lancer le pipeline. Pour cela, il suffit de spécifier [skip-ci] ou [ci-skip] dans le message de commit.
**But** : Après une modification, pousser le changement en précisant [skip-ci] dans le message de commit. Observer le comportement dans l'interface.
......@@ -82,7 +82,7 @@ Dans certains cas, on veut pouvoir pousser des changements sans lancer le pipeli
On peut programmer des pipelines pour qu'ils soient lancés à intervalles réguliers (par exemple pour les *Nightly Builds*).
**But** : Programmer un pipeline dans *CI/CD -> Schedule*. Puis, ajouter un job qui ne sera exécuté que lors des pipeliens programmés à l'aide du mot-clé [only](https://docs.gitlab.com/ee/ci/yaml/#only-and-except-simplified)
**But** : Programmer un pipeline dans *CI/CD -> Schedule*. Puis, ajouter un job qui ne sera exécuté que lors des pipelines programmés à l'aide du mot-clé [only](https://docs.gitlab.com/ee/ci/yaml/#only-and-except-simplified)
## Compilation python ##
......@@ -126,7 +126,7 @@ Nous allons maintenant travailler avec un petit module en pur python créé pour
### 11. Tests et publication de la documentation à l'aide de Gitlab Pages ###
Nous allons écrire un pipeline complet, qui teste la fonctionnalité et le style du code (avec *pycodestyle*, disponible dans *pip*) et qui génère et déploie la documentation (avec *sphinx*, disponible lui aussi dans *pip*). Pour la partie documentation, on utilisera [only](https://docs.gitlab.com/ee/ci/yaml/#only-and-except-complex) pour ne la générer que si le message de commit commence par `[doc]`. Cette étape un peu spéciale est appelée [pages](https://docs.gitlab.com/ee/ci/yaml/#pages) et s'appuie sur une fonctionnalité appelée [Gitlab Pages](https://docs.gitlab.com/ee/user/project/pages/index.html) (original !).
Nous allons écrire un pipeline complet, qui teste la fonctionnalité et le style du code (avec *pycodestyle*, disponible dans *pip*) et qui génère et déploie la documentation (avec *sphinx*, disponible lui aussi dans *pip*). Pour la partie documentation, on utilisera [only](https://docs.gitlab.com/ee/ci/yaml/#only-and-except-complex) pour ne la générer que si le message de commit commence par `[doc]`. Cette étape spéciale est appelée [pages](https://docs.gitlab.com/ee/ci/yaml/#pages) et s'appuie sur une fonctionnalité appelée [Gitlab Pages](https://docs.gitlab.com/ee/user/project/pages/index.html) (original !).
**But** : Écrire un fichier .gitlab-ci.yml qui comporte deux étapes.
* La première étape comporte deux jobs, l'un qui teste le code à l'aide du test unitaire, et l'autre qui teste son style à l'aide de pycodestyle. Comme nous ne sommes pas des orthodoxes, admettons que dans certains cas le *coding style* peut ne pas être respecté...
......@@ -171,40 +171,46 @@ pip wheel . -w wheelhouse
*Note 3* : On ne peut déployer plusieurs fois la même version d'un paquet sur Pypi. Utilisez un numéro de version majeure correspondant au numéro de votre dépôt (ex : version 1.x pour le groupe formation-ci-01).
*Note 4* : Pour les gros projets multi-dépô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/)).
*Note 4* : Installer une version particulière d'un paquet Pypi :
```bash
pip install paquet==version
```
*Note 5* : Pour les gros projets multi-dépôts, il est conseillé d'utiliser des outils dédiés pour la gestion de secrets (comme [Hashicorp Vault](https://www.vaultproject.io/)) plutôt que les [variables Gitlab](https://docs.gitlab.com/ee/ci/variables/#variables).
### 14. Dockerception ###
[dice-http-server](python-dice/dice-http-server) est un petit serveur web qui permet d'utiliser dice. Par exemple, l'appel à la page http://server/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](https://docs.gitlab.com/ee/ci/variables/#variables) pour spécifier les identifiants.
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 à nouveau les [variables Gitlab](https://docs.gitlab.com/ee/ci/variables/#variables) pour spécifier les identifiants.
**But** : Construire une image docker grâce au Dockerfile fourni, la pousser sur DockerHub, et permettre son déploiement en production manuel. Lors de la mise à jour, utiliser docker pull afin de 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* : 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 formation-ci-01).
*Note 2* : Évidemment, dans la réalité nous ne déploierons pas en production depuis le master... Jetez aussi donc un oeil aux [Environments](https://docs.gitlab.com/ee/ci/environments.html).
*Note 3* : Évidemment, dans la réalité nous ne déploierons pas en production depuis le master... Jetez donc un oeil aux [Environments](https://docs.gitlab.com/ee/ci/environments.html).
*Note 3* : Idéalement, notre conteneur doit lui aussi recevoir une série de tests avant d'être déployé !
*Note 4* : 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.
[^1]: [Martin Fowler, BlueGreenDeployment](https://martinfowler.com/bliki/BlueGreenDeployment.html)
![canary](img/canary-release.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.
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 le code.
**But** : Dé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 1* : 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...
*Note 2*: Utilisez les ports 80x0 et 80x1...
[^1]: [Martin Fowler, BlueGreenDeployment](https://martinfowler.com/bliki/BlueGreenDeployment.html)
### 16. Bonus : HAProxy, docker-compose.yml ###
......
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