README.rst

=================
 Ateliers devops
=================

C'est quoi la différence entre une formation et un atelier?

- La formation est organisée par un Sachant, qui:

  - posséde son sujet
  - prépare sa formation.
  - gère l'avancée de la session, selon les réactions des
    participants.
  - déverse donc son savoir dans les cerveaux des participants.

- L'atelier est organisé par quelqu'un qui:

  - ne maîtrise pas totalement son sujet.
  - espère trouver chez les participants une partie de la connaissance
    qui lui manque.
  - est suffisamment maitre de son sujet pour gérer l'avancée des sessions.

Définition dont la portée n'est sans doute pas universelle, mais qui
me semble assez structurante pour qu'on s'appuie dessus... en
attendant un raffinement des terminologies, souhaitable ou pas.

Le terme d'atelier a une autre dimension: il suggère des travaux
pratiques, aidant à conforter et étayer les connaissances.

Je souhaite organiser au lab des "Ateliers devops".

Devops, c'est un autre terme un peu flou, un peu (beaucoup!) buzzword,
un peu hype. Pour moi, c'est l'ensemble des techniques
d'automatisation de connexion, d'installation, de déploiement, etc,
qui permettent de réduire drastiquement les temps nécessités par ces
opérations, et donc les coûts. C'est donc à la fois:

- une opportunité pour les gafa de remplir leurs objectifs pour encore
  moins cher.
- une opportunité pour les opposants à l'uberisation générale de
  développer des alternatives, avec peu de moyens.
- et pour nous, salariés, indeps, des technos à acquérir d'urgence.

Ces technos, j'en maîtrise un certain nombre, et je commence à avoir
une vision d'ensemble. Je me sens donc en capacité de porter, au moins
au début, ces ateliers. En tout cas en démarrer plusieurs, en mode
formation.

Le terme atelier a une autre portée, plus traditionelle: c'est
l'endroit où des sachants (artisans, ouvriers):

- trouvent leurs outils rassemblés, entre autre ceux qui ne sont pas
  mobiles.
- produisent des objets, des outils, destinés à l'atelier, à la vente,
  etc.
- prennent plaisir à se retrouver, élaborent leurs stratégie, cassent
  la croute, etc.

Ça peut se traduire, ça, au niveau du lab?

C'est bien sur pas un lieu dédié, le lab n'en a pas les moyens, on
n'en a pas le besoin. Ou alors "lieu" dans le sens étroit,
informatique: mailing list, repository commun, voire group gitlab.

Ça peut être une équipe, qui dans un premier temps gère la dimension
cognitive, l'organisation des ateliers au sens étroit (sessions
d'acquisition croisée de connaissance), et progressivement se donne
d'autres objectifs:

- réalisation de projets du lab, très nécessaires mais encalminés,
  faute de dispos, de savoir-faire et d'énergie.
- croisements avec des projets open-source extérieurs au lab.

Bon, vous connaissez tous Perrette et le pot au lait, n'allons pas
trop vite en besogne.

De quelles technos parlons-nous?

- python, bien sur, c'est la lingua franca du devops, langage de base
  de beaucoup d'outils, mais surtout utilisé comme "glue langage" dans
  beaucoup de cas.
- ipython, jupiter, jupiterLabs: satellites de python.
- json, yaml: data langages, faciles et puissants, souvent vecteurs
  des échanges de données. Oublions xml, ce balourd.
- git, qu'on ne présente plus. gitlab, github, gitbucket, ses
  satellites (provoquent des marées, auraient une influence...)
- ansible, outil de configuration de masse mais pas que.
- docker, k8s, outils de "containerisation"
- les langages de markup léger: markdown, restructuredText.

C'est bien sur peine perdue d'essayer de détourer un sous ensemble qui
serait le coeur, les satellites n'occupant qu'une place mineure.

Dans le lot, je maîtrise bien python, ipython, json, yaml,
restructuredText, git; moins bien docker et k8s

Ce texte est rédigé en restructuredText, je l'ai mis dans un projet
gitlab, vous pouvez le voir sous:
https://code.electrolab.fr/Pierreg/atelierdevops/blob/master/README.rst

Depuis bientôt 10 ans que je pratique le restructuredText, je rédige
avec tous mes projets persos. D'une commande j'en fais:

- un pdf
- un fichier html
- un document latex ou docx

Pourquoi ne pas avoir fait simplement une entrée dans le forum ou le
chat?

- Réticence à d'autres markup langages, moins normalisés.
- Réticence encore plus à éditer en ligne.
- Occasion de montrer le couplage gitlab/restructuredText: J'édite le
  source, et gitlab le met en forme! (gitlab travaille aussi avec
  markdown).

C'est typiquement le type de couplage que favorisent les outils devops.

Devops, la suite
================

J'ai posté le message sur l'atelier devops il y a 4 jours, des
réactions amusées, interessées, mais je n'ai pas trouvé ma cible.

J'espérais trouver 2 à 3 personnes avec qui mener cette activité.
Mais je ne met pas en suspens! Je pense que le forum est lu par "les
habitués", j'ai moi-même été longtemps réticent au forum (je trouvais
la ml plus facile d'accès, plus inclusive, malgré la multiplicité des
sujets), bref je ne désespère pas de trouver ma cible.

En attendant je commence tout seul, espérant qu'un début de
réalisation sera plus alléchant qu'un discours. Et je me propose de
commencer par:

- des formations/ateliers.
- un atelier gitlab ci/cd

Formations / ateliers
---------------------

Je ne démarrerai une formation que si elle trouve son public.
Comment peut faire un formateur bénévole, qui envisage une formation
donnée, pour savoir si elle suscite de l'intérêt? Discussion avec
Zenos sur la question il y a quelques semaines. Zenos::

  Ah oui, on envisage d'adopter un logiciel (lequel? j'ai oublié),
  open source, bien sur. Mais en l'état il n'est pas parfaitement
  adapté au besoin, on leur a demandé des adaptations.

Bon, je trahis probablement le verbatim du propos.
Bien sur, je ne peux pas attendre, je ne vais pas attendre, et je vais

- formuler les propositions.
- faire des annonces sur les canaux idoines, ou d'autres (petites
  annonces dans les chiottes du lab? du moment que c'est pas gravé au
  couteau dans le platre, et que ça ne propose pas des détournements
  de semence, ça pourra peut être passer?).
- choisir en fonction des retours.

Formation de base python
~~~~~~~~~~~~~~~~~~~~~~~~

Une dizaines de sessions sont nécessaires pour faire le tour du
langage.

La difficulté est que tous ne pourront pas assister à toutes. Il faut
donc que le saut d'une session n'entraine pas l'abandon de la suite:

- trouver des mooc ou fragments de mooc correspondant aux sessions
  sautées.
- adresser, à chaque session, des sujets assez "orthogonaux" pour que
  le manque d'une session ne se fasse pas sentir.
- peut être: ateliers de rattrapage.

Avec une dizaine de session, un auditeur pas trop doué peut devenir
autonome. À condition de pratiquer, et rapidement! La vitesse à
laquelle les connaissances acquises fondent en l'absence de pratique,
c'est juste hallucinant.

Formation Git
~~~~~~~~~~~~~

Git s'est répandu chez les informaticiens comme la vérole sur le bas
clergé. On peut s'en passer, on peut aussi se passer de sel, de
viande, de voiture, de savon... C'est juste un peu difficile à vivre.

On peut imaginer 3 sessions:

- débutants: principes des vcs (Version Control Software). Historique.
  Commandes de base.
- git avancé; plongée dans les commandes de ouf. workflows et
  "dimension sociale".
- surcouches: github, gitbucket, gitlab: intérêt, business models,
  éthique, éco-systèmes. gitlab: Ci/Cd

Atelier python RC:
~~~~~~~~~~~~~~~~~~
Ça, c'est un peu plus ambitieux.
On est à la frontière atelier/formation, puisque:

- j'ai toutes les connaissances pour mener le truc à bien.
- mais je n'ai pas la démarche définie.
- Il s'agit d'apprendre en construisant.

On est également à la frontière informatique électronique. Il s'agit
d'explorer le circuit RC, soit résistance-capacité. On "attaque" un
circuit RC avec un signal, entre 0 volts et 5 volts. On acquière la
tension en sortie du dispositif, avec une résolution pas
déconnante. On manipule des séries de mesure, on essaie d'intuiter les
phénomènes en jeu, et on va retrouver les équations, fort simples, qui
régissent le truc.

Mais ce faisant, on aura déployé tout l'arsenal de base du data
scientiste! On aura commencé par des listes, explorations facilitées
par pandas, puis représentation graphique, etc. Les outils mis en
place sont aussi bien capables de traiter d'autres types de signaux.

Génération des signaux et analyse se font par le même ordinateur, ce
sont manifestement 2 taches indépendantes, un autre concept assez
décoiffant pour le débutant.

2 intérêts de l'atelier:

- ouvert à des débutants (mais prêts à en chier!) dans les 2 domaines.
- fusion de domaines différents dans un même atelier.

Atelier Ci/CD
-------------
Là on n'est plus dans la formation, mais une activité que je prévois
de démarrer en solo, avec un peu d'aide de l'équipe IT.

gitlab promeut en ce moment, à grand bruit, son activité Ci/CD.
je décris à grosse maille, pour plus de détail cf par exemple
https://docs.gitlab.com/ee/ci/
Il s'agit, pour un projet, de déclencher des scripts exécutés à chaque
commit, qui vont pouvoir:

- vérifier la conformité du code saisi aux standards de qualité qu'on
  s'est donnés.
- déclencher des test: tests unitaires, tests d'intégration
- en cas de succès:

  - produire automatiquement les paquets logiciels.
  - voire déployer automatiquement les logiciels en production.

gitlab permet que ça se fasse y compris sur les installations "on
premise", comme par exemple le gitlab du lab.

Dans le principe c'est génial, ça permet de tout simplifier, tout
automatiser; dans les détails c'est beaucoup moins simple:

- les soi-disants tests unitaires, supposés se faire très vite avec
  peu de ressources, peuvent être bogués, et effondrer la machine où
  ils tournent.
- il faut donc pouvoir limiter les ressources mises à disposition:
  typiquement docker ou k8s.
- quand un test déconne, il faut pouvoir le déboguer: donner au codeur
  accès à l'environnement où le test a eu lieu.

C'est ça que je veux essayer, tester, mettre en place, au lab, sur le
gitlab du lab. Intérêt:

- pour les membres: un environnement ci/cd opérationnel.
- pour le lab: l'automatisation d'opérations gérées aujourd'hui
  manuellement (ou pas gérées).

Le rêve (ou le fantasme) du développeur: il corrige le code, le
déploiement se fait tout seul! gitlab cd (continuous deployment) peut
beaucoup, beaucoup faciliter les choses au lab, du moins le crois-je;
et j'ai besoin de convaincre l'équipe IT, parce que j'ai besoin d'eux!
pour configurer gitlab, et avoir les bons containers, avec les bons
droits, pour supporter l'activité.

Bon, sinon je me met à l'amélioration des recettes de rahat
loukoum. S'est selon.