Quand vous avez une API, et a fortiori une application, il peut être parfois nécessaire de passer l’application en mode « maintenance ». Pour certaines applications il est parfois inutile de le traiter au niveau applicatif, car ça peut être pris géré par certaines couches de sécurité ou frontaux web par ex. (Apache HTTPD, WAF) Kubernetes a introduit ( ou popularisé ) les notions de « probes » et plus particulièrement les livenessProbes et readinessProbes.

Pourquoi utiliser GPG ? Par exemple pour signer les commits GIT. Maintenant comment faire quand on est sous Windows 10 et qu’on souhaite utiliser le sous système Linux (WSL2)? Sous GNU/Linux, l’installation et l’utilisation avec git est très simple. Avec WSL2,… il faut un peu d’huile de coude 🙂 Je vais tâcher de décrire dans cet article les différentes manipulations nécessaires pour: Importer une clé GPG existante Utiliser GPG pour signer mes commits dans WSL2 1 Importer une clé GPG existante 1.

Les confinements se suivent et se ressemblent. Me voilà à installer Ubuntu sur un nouvel ordinateur. A l’instar de l’ancien laptop que j’ai acheté pour mon aînée, j’ai acheté un DELL pour ma deuxième fille.J’ai opté pour un DELL Inspiron 5301. A l’instar de mon autre laptop, je j’ai pas pris de risques. J’ai opté pour un DELL qui est pleinement compatible avec Ubuntu. Oui j’aurai pu installer un ordinateur avec Ubuntu pré-installé, mais je n’ai pas eu le temps de faire un choix « serein ».

Dès qu’on veut déployer des environnements Kubernetes, helm devient une des solutions à considérer. Le déploiement des objets standards tels que deployment, autoscaler et autres se fait aisément car ces derniers ne changent pas d’un environnement à l’autre. Généralement on déploie la même infrastructure sur tous les environnements du développement à la production. Bien évidemment on pourra limiter la taille des replicas sur l’environnement de développement par exemple mais au fond, le contenu des charts sera identique.

Depuis quelques années, Kubernetes (K8S) et son écosystème deviennent l’environnement d’ exécution à la mode. Certaines personnes veulent déployer sur cet environnement en mettant en avant ses capacités de scalabilité. D’autres font du bashing (souvent) justifié sur la complexité et le coût de mise en œuvre d’une telle plateforme. Vous l’aurez compris, cette technologie n’échappe pas au cycle du hype et à la fameuse courbe du Gartner. Après quelques expériences sur cette plateforme ( et beaucoup sur d’autres 😀 ) je vais essayer de peser le pour et le contre qui m’apparaissent importants.

Derrière ce nom pompeux qui peut effrayer, je vais essayer d’expliquer dans cet article comment on peut versionner facilement ses partitions et les publier sur le web. En cherchant comment mettre de la documentation technique avec des diagrammes PlantUml dans des repos GITLAB et générés avec des pipelines, je me suis mis dans la tête de faire la même chose avec des partitions 🙂 Depuis plusieurs années, j’utilise lilypond pour créer mes partitions.

A mes heures perdues, je travaille sur un « POC/side project qui n’aboutira pas et je m’en fiche » basé sur Quarkus. J’ ai choisi d’utiliser les langages et composants suivants : Kotlin Quarkus Gradle Kubernetes pour le déploiement Oui, tant qu’à faire, autant aller dans la hype … Mon projet est sur GITHUB. Pour automatiser certaines actions et, disons-le, par fierté personnelle, j’ai choisi d’automatiser certaines actions par la mise en œuvre de pipelines CI/CD.