Se former ? Pratiquer surtout !

Cet article a été publié il y a 4 ans 8 mois 6 jours, il est donc possible qu’il ne soit plus à jour. Les informations proposées sont donc peut-être expirées.

Aujourd’hui j’aimerai partager avec vous un retour d’expérience sur un projet que j’ai du mener au boulot, sur les limites des formations, mon ressenti en tant qu’autodidacte qui a passé sa vie à se former dans son coin. Et si je peux glisser un ou deux conseils au passage, je vais pas m’en priver 🙂

Le projet en question qui m’a mené au questionnement de ce jour, c’est une migration de sites web php/mysql (différents CMS) installés sur des machines virtuelles, vers un cluster Kubernetes via le service Microsoft Azure Kubernetes. Pour ceux qui ne sont pas encore à jour, Kubernetes, je le décrirai comme une plateforme d’orchestration de containers Docker qui amène pas mal de concepts supplémentaires (par exemple on ne parle pas de container mais de pod), qui est pensé pour un déploiement industriel, et facilement proposé par les gros fournisseurs d’hébergements dit cloud, avec des plugins pour relier certains éléments à leur propre architecture.

On a donc dans la balance, des CMS que je ne maîtrise pas forcément (Magento, Typo3, par chance y’a aussi du WordPress), un fournisseur Cloud avec lequel je n’ai pas encore réellement travaillé, et un orchestrateur que je n’ai là aussi jamais touché en prod ni chez moi. Le tout sans support d’agences web, et sans support par le client car il n’a pas les compétences internes et les contrats avec les agences web ont été décapités à l’occasion de rachats par une entité étrangère qui pilote du coup à la place des équipes locales pas mal de choses.

Commençons par le fournisseur cloud. J’ai fait un seul WorkShop sur Azure, avec un ingénieur terrain de Microsoft, qui nous a parlé pendant 4 jours de technologies Windows. Les rares déploiements que l’on a effectués étaient en mode manuel, pour de la simple machine virtuelle, donc pas vraiment adapté. Et surtout, par la suite, je n’ai pas eu à travailler sur du déploiement Azure, juste de la gestion au quotidien sur des instances virtuelles Linux classiques. Autant dire que mes connaissances sur la plateforme Cloud étaient minimes, mais vraiment…

Pour les sites, je vais évacuer tout de suite, le code ce n’est pas mon métier à la base, au mieux j’ai une expérience que je qualifierai de solide désormais pour analyser le fonctionnement de PHP, avec naturellement un bagage un peu plus fourni sur WordPress et Drupal, donc pas un problème, même si on le verra ça ne suffit pas toujours.

Pour Kubernetes, la seule approche que j’en avais eu jusque là c’était un « atelier » de deux jours par un collègue de boulot avec qui j’adore discuter (j’ai pris grosso modo deux mois de cours avec lui en une heure d’investigation MySQL un soir, encore merci Julien 🙂 ), un workshop sur OpenShift. OpenShift repose sur Kubernetes, qui repose lui-même sur Docker, mais la solution de RedHat amène des contraintes notamment de sécurité supplémentaires, et du routing entrant qui lui sont propres et donc pas applicables ailleurs. Là aussi, à peine le workshop terminé, aucune utilisation en production sur mon pôle client et aucun projet en vue dans l’immédiat. Je l’ai surtout fait parce que je voulais compléter ce que je connaissais déjà de Docker, mais au final…

On en arrive au fameux projet, que j’ai attaqué en revenant de mon arrêt prolongé pour cause de pied cassé, on me colle le cluster Kubernetes fraîchement déployé dans les pattes, les accès au serveur vmware du client qui héberge ses machines virtuelles avec les différents sites à l’intérieur, et roulez jeunesse. A moi de définir la méthodologie, faire l’inventaire des besoins, gérer la conteneurisation des sites, etc. Pas le meilleur cadrage du monde on en conviendra.

Et là, plus d’un an voire deux après le Workshop Azure, et plus de six mois après celui d’OpenShift, eh bien, sans avoir pratiqué, j’ai du reprendre tout de zéro. Le résultat, j’y suis arrivé mais dans la douleur, avec pas mal de surprises, de tentatives, de recherches longues et pas toujours fructueuses, de déceptions et de victoires parfois surprises. Plus ou moins dans l’ordre :

• difficultés pour créer une image fonctionnelle de Docker pour les sites, notamment magento, sans support j’ai voulu rester au plus proche de l’environnement d’origine
• difficultés pour utiliser la Container Registry d’azure (on m’a dit que j’avais tous les droits, mais j’ai eu pas mal d’échecs et d’allers-retours avec les ingés pour m’assurer que j’ai bien les permissions).
• la création des différentes étapes pour un déploiement kubernetes : on entend régulièrement que Kubernetes c’est chiant, je confirme : secrets, volumes, volumes claim, déploiements, services, ingress… beaucoup d’étapes pour faire un boulot qui tient en trois lignes sur docker swarm (j’abuse mais c’est pas loin).
• les limitations sur les options de stockage fournies par azure : avec azure disk, vous êtes limités sur le nombre de volumes rattachables aux nœuds de calcul du cluster, donc vite coincé sur vous avez besoin de beaucoup de volumes (deux par magento par exemple, sans parler des limitations d’accès en RWO, pas pratique pour le rolling update), azurefile qui est l’autre option n’est tout simplement pas exploitable dans le monde réel tellement les performances sont mauvaises.
• ingress : Microsoft vous déploie un http-controller-addon qui est juste un autre nom pour l’ingress nginx de la documentation officielle de Kubernetes. Quand vous cherchez à manipuler les règles ingress, que vous ne savez pas comment paramétrer les annotations pour faire appliquer les règles au contrôleur, vous pleurez parce que Microsoft vous fournit une doc reprenant les termes officiels, pour un déploiement indépendant d’un contrôleur nginx, mais pas celui qui est fourni par défaut. Et pourtant la doc pour ce fameux contrôleur, avec les bonnes informations, elle existe aussi (mieux, elle indique qu’il n’est pas recommandé de l’utiliser en production…) !

Je passerai sur les erreurs liées au déploiement lui-même du cluster, qu’on a fait à la main dans la mauvaise région par rapport au vnet qu’on avait paramétré, ce qui complexifie la gestion du réseau des déploiements annexes. On a passé pas mal de temps à tenter de récupérer une définition de terraform qui colle à ce qu’on avait déjà en important les ressources depuis azure. Je disais de pratiquer, ah ben là j’ai mangé, et pas qu’un peu ! Surtout que le template se charge aussi de configurer le monitoring datadog et le backup velero (pratique si pour une raison ou une autre on doit redéployer le cluster de zéro, au hasard pour récupérer un réseau potable).

100 fois sur le métier…

Dans tous les cas, le problème de fond reste le même. Vous pouvez faire autant de formations que vous voulez, si vous ne pratiquez pas derrière, vous ne risquez pas de retenir vraiment les choses, au mieux vous garderez les concepts mais vous devrez passer beaucoup plus de temps à retrouver vos petits. Quand j’ai monté mon cluster docker swarm à la maison, c’est parce que je savais qu’au boulot, je ne ferai pas assez de Docker au quotidien pour en garder l’habitude et les réflexes. Un collègue ingénieur qui va devoir aussi bosser sur du K8S pour un client a installé un cluster de test chez lui pour en comprendre les rouages, et je me pose aussi la question désormais (bien que les priorités soient ailleurs en ce moment).

L’idéal pour ça, c’est d’avoir un ou plusieurs projets persos pour mieux s’approprier les technologies. J’ai codé la première version de collect en PHP/MySQL parce que je voulais apprendre sur ces deux technologies. Ce n’est pas allé très loin certes, mais ça m’a donné les clés de base pour être à l’aise par la suite quand il s’agit à la fois de les installer, de les opérer, de les approfondir, de les analyser quand ça ne fonctionne pas bien, de réparer si c’est cassé. Une sorte de gros premier pied à l’étrier si on veut. Si j’utilise un NAS ASUStor désormais, j’avais tout de même commencé par assembler une machine maison, avec plusieurs disques, ce qui m’a permis de comprendre assez profondément les notions de RAID (que je vous avais partagé d’ailleurs). Et je pourrais continuer comme ça sur pas mal de technos que j’ai fini par connaître.

Je ne suis pas le seul : Genma cherchait à s’auto-héberger, son installation sous Yunohost et sa volonté de contribution au projet font qu’il a acquis une connaissance certaines sur les différentes technologies qui lui servent de base, alors qu’il en savait très peu auparavant. Autant de bagage qui lui servent encore aujourd’hui. Reste qu’il n’a pas eu l’occasion de faire du test pour son nouveau rôle de papa, car monter un labo c’est moins évident 😛

En clair, le maitre mot pour s’assurer qu’on va retenir un max de choses d’une formation, c’est de s’en servir derrière régulièrement, que ce soit pour les clients ou pour soi-même. Et ce, quelque soit le domaine en question.

La nécessité d’une veille et d’une pratique constante

Une des caractéristiques qui me plaît beaucoup dans le métier que je fais, c’est qu’il est en situation de mouvement permanent. Ce qui veut dire qu’on doit apprendre en permanence de nouveaux concepts, de nouvelles choses, y compris sur des logiciels connus qui évoluent avec le temps. On ne peut évidemment pas tout connaître, tout tester, mais se tenir informé des évolutions est nécessaire, ne serait-ce que pour garder en tête les grandes lignes, grâce à ça, lorsque vous aurez à répondre à un nouveau besoin, vous aurez déjà en tête une ou plusieurs possibilités de réponse, que vous aurez moins peur d’appréhender.

Ma méthode préférée pour ça, ce sont les flux RSS des différentes sources que j’utilise. Si vous ne savez pas encore ce que c’est, c’est que vous ne me lisez pas depuis assez longtemps, parce que je vous avais déjà présenté cette technologie il y a quelques années (elle n’a d’ailleurs pratiquement pas bougé depuis). La liste de mes flux bouge avec le temps, les sites qui ferment, d’autres qui sont tout simplement inactifs, d’autres qui s’ouvrent, ou certaines priorités qui changent. Au final je passe toujours autant de temps à lire les infos chaque jour. Par contre, je sais que je ne pratique pas autant que je le devrais, en partie grâce à une flemme légendaire que j’ai moi-même illustrée par ma bio Twitter : procrastinateur de l’extrême. Un exemple qu’évidemment je ne vous invite pas à suivre 🙂