DevOps on Valérian Pyckaert

Déploiement d'un LLM dans Kubernetes avec Minikube

Tue, 04 Aug 2026 19:00:00 +0200

Introduction

Les Large Language Models (LLM) ont révolutionné le domaine de l’intelligence artificielle, il existe désormais tout un tas de modèles opensource pouvant être déployés localement. C’est ce que nous allons voir dans cet article, nous allons déployer un LLM dans un cluster Kubernetes local en utilisant Minikube, ce qui permet de tester différents modèles sans coûts cloud et faire un premier pas dans l’IA.

Pré-requis

Avant de commencer, assurez-vous d’avoir les éléments suivants installés :

Minikube
kubectl
Docker
Helm
16 Go de RAM minimum
20 Go d’espace disque disponible

minikube version
kubectl version --client
docker --version

Étape 1 : Configuration de Minikube pour les LLM

Les LLM nécessitent des ressources importantes. Nous devons configurer Minikube avec suffisamment de mémoire et de CPU.

Démarrage de Minikube avec des ressources adaptées

# Démarrer Minikube avec 16 Go de RAM et 8 CPU
minikube start --memory=8192 --cpus=4 --disk-size=20g

# Vérifier le statut
minikube status

# Vérifier les ressources allouées
kubectl get nodes
kubectl describe node minikube | grep -A 3 "Allocatable"

Étape 2 : Choix du modèle et de l’image container

Plusieurs options s’offrent à vous pour déployer un LLM :

Option 1 : vLLM

vLLM est un framework optimisé pour le déploiement et le serving de LLM, développé par les créateurs de Ray. Il offre :

PagedAttention : Optimisation mémoire pour gérer des séquences longues
Support multi-GPU
Compatibilité avec HuggingFace
API OpenAI compatible

Option 2 : Ollama

Ollama est une solution légère et facile à utiliser pour exécuter des LLM localement. C’est l’option la plus simple pour commencer avec Minikube.

Pour cet article, nous utiliserons Ollama pour sa simplicité et son efficacité.

Étape 3 : Déploiement d’Ollama dans Minikube

Les ressources nécessaires

namespace : pour y déployer toutes les ressources liées à ce projet
pvc : pour le stockage du modèle
deployment: pour servir l’application
service: pour pouvoir exposer l’application

Helm chart & installation

Pour faciliter le déploiement j’ai écris un chart Helm qui configure toutes ces ressources. Le repository se trouve ici.

Clonez le repository puis faites :

helm install ollama . 

#Vérifier que les pods sont Running
kubectl get pods -n ollama

Les pods peuvent mettre un certain temps à démarrer car il faut télécharger le modèle ~1.3Go, j’utilise pour cela un initContainer qui va le télécharger et le stocker dans un volume que le pod pourra ensuite récupérer.

Étape 4 : Utilisation en ligne de commande

La chart déploie l’application et l’expose sur le port 11434.

Pour appeler le modèle :

kubectl -n ollama port-forward svc/ollama 11434:11434

#puis
curl http://localhost:11434/api/generate -d '{
  "model": "llama3.2.1b",
  "prompt": "Explique Kubernetes en une phrase.",
  "stream": false
}'

Vous devriez avoir un résultat de ce type :

Étape 5 : Utilisation en web UI

J’ai volontairement omis de mentionner que la chart déploie 2 ressources supplémentaires : un déploiement et un service “open-webui” pour exposer l’API d’Ollama à travers une interface web. Pour l’utiliser, rien de plus simple :

kubectl -n ollama port-forward svc/open-webui 8080:8080

Ouvrez votre navigateur.

Vous devriez voir une interface de ce type :

Cliquez sur démarrer, après un process de login vous devriez obtenir une page sensiblement ressemblante à celle de ChatGPT :

Enfin, écrivez votre prompt et constatez le résultat :

Conclusion

Déployer un LLM dans Kubernetes avec Minikube se fait sans trop de difficultés, un modèle est finalement exposé via une API comme le serait un webservice classique. Il faut garder en tête que les modèles sont lourds et nécessitent beaucoup de ressources pour les faire tourner.

Ressources supplémentaires

Setup DevOps / Cloud MacOs 2026

Thu, 30 Jul 2026 19:15:33 +0200

Suite à l’achat de mon Mac dédié à mes projets pros je vous propose un liste d’outils à installer pour démarrer rapidement vos activités DevSecOps / Cloud.

Les classiques

IDE : VsCode, GoLand, PyCharm
Docker : évidemment
Agents IA : Claude, Copilot, Codex, Mistral, choisissez celui avec lequel vous êtes à l’aise

Utilitaires

Maccy

Maccy est un gestionnaire de clipboard (presse papier en français), il permet via Ctrl + Shift + Cmd de retrouver d’anciens copier/coller.

brew install maccy

Rectangle

Je travaille avec un écran déporté et j’aime pouvoir réarranger mon espace de travail sans avoir à bouger mes mains du clavier.

Rectangle répond justement à ce besoin et permet de changer la disposition des fenêtres via des raccourcis clavier.

Terminal et CLIs

Dans la mesure où nous passons une quantité non négligeable dans le terminal, il est important d’avoir une configuration optimisée. Voici les outils que je recommande.

HomeBrew

Homebrew est un gestionnaire de package qui permet d’installer et de mettre à jour de nombreux outils.

C’est notamment celui ci que j’utilise pour installer mes CLI.

Installation

Une commande suffit :

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

Utilisation

brew install kubectl

Il est également possible d’installer des clients lourds via les cask :

brew install --cask ghostty

Ghostty

J’ai longtemps utilisé le terminal par défaut de MacOs qui répond à la majorité de mes besoins. Je suis néanmoins récemment passé sur Ghostty qui est écrit en Rust et semble avoir la côte ces derniers temps notamment grâce à ses performances.

Installation

Soit via brew, cf. la commande juste au dessus.

Soit via cette page.

OhMyZsh + Power10k

Là encore il s’agit d’un couple d’outils largement reconnus. OhMyZsh permet de personnaliser le terminal avec des thèmes et plugins qui améliorent l’expérience du développeur.

OhMyzsh

Installation

sh -c "$(curl -fsSL https://raw.githubusercontent.com/ohmyzsh/ohmyzsh/master/tools/install.sh)"

Si tout se passe bien vous devriez avoir le message suivant :

Configuration

Le fichier de configuration est accessible via

vi ~/.zshrc

Plugins

autosuggesions
zsh-syntax-highlighting
zsh-fast-syntax-highlighting
zsh-autocomplete

git clone https://github.com/zsh-users/zsh-autosuggestions.git $ZSH_CUSTOM/plugins/zsh-autosuggestions
git clone https://github.com/zsh-users/zsh-syntax-highlighting.git $ZSH_CUSTOM/plugins/zsh-syntax-highlighting
git clone https://github.com/zdharma-continuum/fast-syntax-highlighting.git ${ZSH_CUSTOM:-$HOME/.oh-my-zsh/custom}/plugins/fast-syntax-highlighting
git clone --depth 1 -- https://github.com/marlonrichert/zsh-autocomplete.git $ZSH_CUSTOM/plugins/zsh-autocomplete

Dans ~/.zshrc chercher la ligne :

plugins=(git).

Et remplacer la par :

plugins=(git zsh-autosuggestions zsh-syntax-highlighting fast-syntax-highlighting zsh-autocomplete)

Une dernière commande pour recharger la configuration :

source ~/.zshrc

Tapez désormais votre commande bash favorite, vous devriez avoir des suggestions d’autocomplétion :

Git

OhMyZsh est installé avec un plugin git que je trouve surpuissant, voici mes commandes favorites :

glog #git log
gc -m #git commit
gsta #git stash add
gstp #git stash pop
grbm #git rebase $(git_main_branch)
gl #git pull
gpsup #git push --set-upstream origin $(git_current_branch)

Plus d’informations ici.

Power10k

git clone --depth=1 https://github.com/romkatv/powerlevel10k.git "${ZSH_CUSTOM:-$HOME/.oh-my-zsh/custom}/themes/powerlevel10k"

Dans ~/.zshrc cherchez ZSH_THEME et remplacer la ligne par :

ZSH_THEME=“powerlevel10k/powerlevel10k”

Puis encore une fois rechargez la configuration

source ~/.zshrc

Power10k va vous guider à travers la configuration du plugin pour avoir le terminal qui répond à vos goûts.

JQ & YQ

jq et yq sont deux utilitaires que j’affectionne particulièrement pour manipuler du JSON et du YAML (très utile pour les fichiers de configuration Kubernetes).

Installation

brew install jq yq

Utilisation

Les deux commandes ont une syntaxe identique.

Voici quelques exemples très utiles :

# Lister le nom de tous les pods 
kubectl get pods -A -o json | yq '.items[].metadata.name'
# Afficher l'image d'un pod
kubectl get deploy my-app -o json | yq '.spec.template.spec.containers[0].image'
# Extraire toutes les images utilisées dans le cluster
kubectl get pods -A -o yaml | yq '.items[].spec.containers[].image' | sort -u

Terraform

Pour gérer l’infrastructure, la norme est l’infrastructure as code (IaC). Le leader sur ce segment est bien évidemment Terraform, installable avec … brew !

brew tap hashicorp/tap #Repo officiel des packages Hashicorp
brew install hashicorp/tap/terraform

Si vous utilisez OpenTofu ou Pulumi, le principe est le mêmme :

brew install opentofu
brew install pulumi

AWS / Azure / GCP

Il y a de grandes chances que vous travaillez sur l’un des 3 si ce n’est plusieurs d’entre eux.

#AWS CLI
brew install awscli
#Azure CLI
brew install azure-cli
#GCP CLI
brew install --cask gcloud-cli

Mes alias

Enfin, voici quelques alias que j’utilise quotidiennement

alias k='kubectl'
alias kpf='kubectl port-forward'
alias kctx='kubectl config get-contexts'
alias kswitch='kubectl config use-context'
alias kdebug='kubectl run -i --tty debug-busybox --image=busybox --restart=Never --rm -- sh'

Administration Kubernetes

k9s

k9s pour administrer les clusters kubernetes, c’est un outil à l’apparence geek mais très puissant lorsqu’on connait ses raccourcis.

brew install k9s

Headlamp

Je m’essaie à l’utilisation de Headlamp dernièrement, son interface est agréable et il commence à avoir un paquet de plugins sympas : FluxCD, cert manager, Gateway API, etc.

Je suis moins à l’aise avec Headlamp qu’avec k9s mais je me force à l’utiliser car bien plus complet que son homologue.

brew install --cask headlamp

Conclusion

Voilà mon starter pack en 2026 pour pouvoir travailler efficacement sur du Cloud / Kubernetes sur MacOs.

J’essaierai de mettre à jour cet article au fur et à mesure.

Renovate

Fri, 15 May 2026 10:16:01 +0200

Qu’est-ce que c’est ?

Renovate est un outil d’automatisation des mises à jour de dépendances. Il permet de garder les dépendances à jour en créant automatiquement des pull requests pour les nouvelles versions, les correctifs de sécurité et les mises à jour majeures.

Exemple de PR avec Renovate

Comment ça fonctionne ?

Renovate fonctionne en scannant à intervalles réguliers les dépôts Git pour détecter les mises à jour de dépendances. Lorsqu’une mise à jour est disponible, il crée automatiquement une pull request avec les changements nécessaires, y compris un changelog et des notes de version.

Ensuite, la pull request peut être automatiquement fusionnée si les contrôles de CI sont verts, ou elle peut nécessiter une revue humaine avant d’être fusionnée.

Parfois une image vaut milles mots, alors voici une illustration du workflow de Renovate :

flowchart TD
    A([Planificateur cron]) --> B[Scan du dépôt Git / Lecture des fichiers de config]
    B --> C[Détection des mises à jour]
    C --> D{Mises à jour disponibles ?}
    D -- Non --> E[Aucune PR]
    D -- Oui --> F[Création de la PR Branche + changelog]
    F --> G[CI / Tests automatiques]
    G --> H[Automerge]
    G -.ou.- I[Review humaine]

Ce schéma a été généré avec Mermaid. J’en ferai certainement un article dédié dans le futur.

Un changement de paradigme

Dans le monde du développement logiciel, la gestion des dépendances est un défi constant. Les bibliothèques et les frameworks évoluent rapidement, et il est crucial de maintenir les dépendances à jour pour bénéficier des dernières fonctionnalités, des correctifs de sécurité et des améliorations de performance.

Autrefois (et encore aujourd’hui dans de nombreux projets), la mise à jour des dépendances n’est pas maitrisée et se fait de manière manuelle, souvent de manière ad-hoc. Cela peut entraîner des retards dans l’adoption des nouvelles versions, des risques de sécurité et une dette technique croissante.

Renovate change complètement la donne en automatisant ce processus. Plutôt que de dépendre d’une intervention humaine pour surveiller les mises à jour, Renovate prend en charge cette tâche de manière proactive. Il scanne régulièrement les dépôts, détecte les mises à jour disponibles et crée automatiquement des pull requests pour les intégrer.

Supply chain attacks

Ces derniers mois, nous avons vu une augmentation significative des attaques de la chaîne d’approvisionnement (supply chain attacks). Ces attaques ciblent les dépendances utilisées par les projets, en injectant du code malveillant dans des librairies souvent méconnues mais utilisées par tous.

En voici quelques unes :

La fin des wildcards pour les versions

L’un des avantages (ou inconvénients) majeurs de Renovate est qu’il encourage une gestion plus rigoureuse des versions. Plutôt que d’utiliser des wildcards (comme ^1.0.0 ou ~1.0.0) qui peuvent introduire des changements inattendus, Renovate propose de spécifier des versions exactes pour les dépendances.

Cela permet de mieux contrôler les mises à jour et de réduire les risques liés à l’introduction de changements non désirés.

Les concurrents

Dependabot

Dependabot est un outil similaire à Renovate qui propose également une automatisation des mises à jour de dépendances. Cependant, il est principalement intégré à GitHub et ne supporte pas autant de plateformes que Renovate. De plus, Renovate offre une plus grande flexibilité en termes de configuration et de personnalisation des règles de mise à jour.

C’est toutefois un excellent choix pour les projets hébergés sur GitHub qui souhaitent une solution simple et intégrée, sans avoir à maintenir soit même un outil supplémentaire.

Exemple d’une pull request générée par Dependabot

Vous remarquerez que le résultat est très similaire à celui de Renovate.

Le mot de la fin

Dans cet article, nous avons vu comment Renovate révolutionne la gestion des dépendances en automatisant les mises à jour et en encourageant une approche plus rigoureuse du versioning. C’est un maillon supplémentaire dans une chaîne de CI/CD qui permet à la fois de réduire les risques liés à l’introduction de changements non désirés et de réduire la friction liée à la maintenance des dépendances.

Cocogitto

Thu, 14 May 2026 08:00:00 +0200

Cocogitto est un outil de gestion de commit qui facilite la rédaction de messages de commit conformes à la convention Conventional Commit. Il propose notamment une CLI pour rédiger des messages de commit structurés et standardisés, automatiser certaines tâches liées aux commits (génération de changelog, bump de versions …).

Si vous ne savez pas ce qu’est la convention Conventional Commit, je vous invite à lire le premier article de cette série à ce sujet : Conventional Commit.

Installation

Mac/Linux :

brew install cocogitto

Windows :

choco install cocogitto

Vérification de l’installation :

cog --version

cog 7.0.0

Utilisation

Pour committer

Cocogitto propose via sa CLI la possibilité de rédiger des messages de commit conformes à la convention Conventional Commit de manière interactive.

La commit cog commit remplace alors le bon vieux git commit :

cog commit feat "ma nouvelle fonctionnalite"

Initialisation d’un projet

Tout commence avec la commande cog init qui va créer un fichier de configuration cog.toml à la racine du projet.

cog init

Ce fichier de configuration permet de personnaliser le comportement de Cocogitto, notamment les types de commit autorisés, les scopes, les préfixes, etc.

Ignorer certains type du changelog

La propriété omit_from_changelog permet d’ignorer certains types de commit dans le changelog généré par Cocogitto.

Voici un exemple de configuration pour ignorer les types chore, ci et perf dans le changelog.

[commit_types]
chore = { changelog_title = "", omit_from_changelog = true }
ci = { changelog_title = "", omit_from_changelog = true }
perf = { changelog_title = "", omit_from_changelog = true }

Git hooks

Il est également possible d’utiliser Cocogitto pour gérer les git hooks, notamment le hook commit-msg qui permet de vérifier que les messages de commit respectent la convention Conventional Commit avant de les valider.

Exemple :

[git_hooks.commit-msg]
script = """#!/bin/sh
set -e
cog verify --file $1
cog check

Une fois votre hook configuré, il suffit de l’installer dans votre projet pour qu’il soit pris en compte par Git.

cog install-hook --all

Generation du changelog

Cocogitto permet de générer un changelog à partir des messages de commit conformes à la convention Conventional Commit. Admettons que nous avons les commits suivants dans notre projet :

fdeaa9d feat: Initial commit

Il suffit alors de lancer la commande suivante pour générer un changelog à partir de ces commits :

 cog changelog
## Unreleased (fdeaa9d..1ba231e)
#### Features
- Initial commit - (fdeaa9d) - Bernedotcom2312

Depuis un tag spécifique :

cog changelog --at v1.0.0

Entre deux versions :

cog changelog v1.0.0..v2.0.0

Il est également possible de personnaliser le format du changelog généré en utilisant un template personnalisé.

Exemple :

[changelog]
path = "CHANGELOG.md"
template = "remote"   # template prédéfini : "default", "remote", "full_hash"
remote = "github.com"
repository = "mon-repo"
owner = "mon-pseudo"

Bump de version

Ceci est pour moi la feature principale de cocogitto qui permet de faire du versionning sémantique (SemVer) à partir de messages de commit.

Voici comment Cocogitto calcule la prochaine version à partir des messages de commit :

flowchart TD
    A[Calcul de la prochaine version] --> B[Exécution des pre-bump hooks]
    B --> C[Ajout des changements dans CHANGELOG.md]
    C --> D[Création d'un commit de version]
    D --> E[Création d'un tag git sur le commit de version]
    E --> F[Exécution des post-bump hooks]

La commande permettant de faire un bump de version est la suivante :

cog bump [version]

Version pouvant avoir pour valeur :

--auto: calcul automatique de la prochaine version à partir des messages de commit.
--major: incremente la version majeure.
--minor: incremente la version mineure.
--patch: incremente la version de correctif.
--version <version>: définit la version manuellement ( ex: cog bump –version 3.2.1).
--pre <metadata>: définit ou incrémente la version pré-release.
--build <metadata>: définit les métadonnées de build.

Par défaut seuls les commits de type fix, feat et BREAKING CHANGE sont pris en compte pour le calcul de la prochaine version.

En reprenant mon exemple de commit précédent, si je lance la commande cog bump --auto alors la prochaine version calculée sera la suivante :

v0.1.0

On vérifie ?

cog bump --auto
        Found feature commit fdeaa9d
Bumped version: ... -> 0.1.0

Le commit alors généré par Cocogitto pour le bump de version est le suivant :

1ba231e chore(version): 0.1.0

Le mot de la fin

Dans cet article nous avons vu comment installer et utiliser Cocogitto pour gérer les messages de commit, générer les changelogs et les numéros de version de manière automatisée à partir de messages de commit conformes à la convention Conventional Commit. Dans le prochain article nous verrons comment intégrer Cocogitto avec Renovate dans une chaine de CI/CD.

Sources

Cocogitto Documentation

Conventional Commit

Fri, 08 May 2026 08:00:00 +0200

Je démarre ici une nouvelle série d’articles sur les bonnes pratiques de développement, en commençant par une convention de commit que j’utilise au quotidien.

Introduction

Conventional Commit est une convention pour formater les messages de commit de manière structurée et standardisée. Elle permet de faciliter la lecture et la compréhension des messages de commit, ainsi que d’automatiser certaines tâches comme la génération de changelogs ou la gestion des versions.

Exemple de commit suivant la convention Conventional Commit

feat: add new feature X
fix: correct bug Y

Dans cet exemple, feat indique qu’il s’agit d’une nouvelle fonctionnalité, tandis que fix indique qu’il s’agit d’une correction de bug.

Pourquoi choisir Conventional Commit ?

Conventional est l’une si ce n’est la seule convention de commit largement utilisée dans la communauté open source et dans l’industrie. Elle est supportée par de nombreux outils et intégrations, ce qui en fait un choix populaire pour les projets de toutes tailles.

Quelques exemples d’acteurs majeurs qui utilisent Conventional Commit :

En pratique

Les types de commit possibles

Voici quelques types standard que j’utilise au quotidien dans mes projets (trier par ordre d’utilisation) :

feat : ajout d’une fonctionnalité
fix : correction de bug
chore : tâches diverses (ex : MAJ de dépendances)
docs : documentation uniquement
refactor : modification du code sans ajout de fonctionnalité ni correction de bug
test : ajout ou modification de tests

Le scope

Il est également possible d’ajouter un scope pour préciser la partie du code concernée par le commit.

Par exemple : feat(auth): add login functionality

Dans cet exemple, auth est le scope qui indique que le commit concerne la partie d’authentification du projet.

Bonnes pratiques

Utiliser des verbes à l’infinitif (ex : “add”, “fix”, “update”, etc.)
Ne pas dépasser 72 caractères pour la ligne de titre du commit
Ajouter une description plus détaillée dans le corps du commit si nécessaire
Utiliser des préfixes pour indiquer les types de commit (ex : “feat:”, “fix:”, etc.)

Un pas vers l’automatisation

Les conventional commits sont la première étape vers une chaîne de CI/CD plus automatisée. En utilisant des messages de commit structurés, il devient possible d’automatiser la génération de changelogs, la gestion des versions et même le déploiement en production.

Workflow CI/CD avec Conventional Commit

flowchart TD
    A[Développement] --> B[Conventional Commit]
    B --> C[CI/CD]
    C --> D[Tests automatiques]
    D --> E{Tests réussis ?}
    E -- Oui --> F[Génération Changelog + Versioning]
    E -- Non --> H[Correction du code et nouveau commit]
    F --> I{Déploiement ?}
    I -- Version mineur ou patch --> J[Déploiement automatique]
    I -- Version majeure --> K[Déploiement manuel]

Stratégie de versioning

En utilisant les types de commit, il est possible d’adopter une stratégie de versioning sémantique (SemVer).

Voici un exemple de politique de versioning basée sur les types de commit :

Un commit de type feat peut déclencher une nouvelle version mineure (ex : 1.0.0 -> 1.1.0)
Un commit de type fix peut déclencher une nouvelle version patch (ex : 1.0.0 -> 1.0.1)
Un commit de type refactor ou chore peut ne pas déclencher de changement de version, ou déclencher une nouvelle version patch selon la politique adoptée.

Pour réaliser ce type d’automatisation, il existe de nombreux outils comme semantic-release ou encore Cocogitto que j’apprécie beaucoup qui peuvent analyser les messages de commit et gérer automatiquement la génération de changelogs et le versioning.

Sources