DEV Community: BeardDemon

Pourquoi j'ai créé un projet pour apprendre GitLab CI/CD (et pourquoi la doc ne suffit pas)

BeardDemon — Tue, 27 Jan 2026 18:47:12 +0000

Le problème avec l'apprentissage "théorique" de la CI/CD

Quand j'ai commencé à apprendre GitLab CI/CD dans le cadre de mon TP en BUT Réseaux & Télécoms, j'ai fait comme tout le monde : j'ai lu la documentation officielle, regardé quelques tutoriels YouTube, et copié-collé des exemples.

Résultat ? Rien ne fonctionnait vraiment. Ou plutôt, ça fonctionnait… mais je ne comprenais pas pourquoi.

Pourquoi ce job reste en "pending" pendant 10 minutes ?
C'est quoi la différence entre un stage et un job concrètement ?
Pourquoi mon image Docker ne se build pas alors que le YAML est valide ?
Comment on sécurise une pipeline ? Est-ce qu'on peut juste "build et push" sans vérifier quoi que ce soit ?

La doc GitLab est excellente… pour quelqu'un qui sait déjà ce qu'il cherche. Mais quand tu débutes, tu as besoin de casser, réparer, comprendre.

C'est exactement pour ça que j'ai créé GitLab CI Learning.

L'idée : un "bac à sable" pédagogique

Au lieu de partir sur un vrai projet avec 50 fichiers et des dépendances complexes, j'ai voulu créer un repo volontairement simple, avec :

Un Dockerfile minimal (une app Python/Flask basique)

Une pipeline .gitlab-ci.yml progressive (du plus simple au plus complet)

Des étapes claires : compliance, build, security

Des commentaires explicatifs dans le code

Des erreurs documentées (celles que j'ai réellement rencontrées)

Le principe ? Apprendre par la pratique, pas juste en lisant.

Les objectifs concrets de ce repo

Objectif 1 : Comprendre la structure d'une pipeline

Avant de faire du "DevSecOps avancé", il faut maîtriser les bases :

Pipeline = l'ensemble du processus CI/CD
Stages = les grandes étapes (basic, build, test, deploy…)
Jobs = les tâches concrètes à l'intérieur de chaque stage

Dans mon projet, je pars d'une pipeline ultra-simple :

stages:
  - basic

basic:
  stage: basic
  script:
    - echo "Pipeline fonctionnelle !"

Puis j'ajoute progressivement de la complexité.

Objectif 2 : Savoir pourquoi une pipeline "casse"

Les erreurs les plus frustrantes en CI/CD ? Celles qui ne sont pas dans ton code, mais dans l'environnement :

Job bloqué en "pending" → problème de runner
"Image not found" → mauvaise configuration Docker
"Permission denied" → auth registry ratée
YAML valide mais pipeline inutile → logique métier absente

Mon repo documente toutes ces erreurs réelles que j'ai rencontrées.

Objectif 3 : Construire une CI "professionnelle"

Une bonne pipeline ne fait pas que "build". Elle doit :

Vérifier la qualité (lint du Dockerfile avec Hadolint)
Construire l'artefact (image Docker avec Kaniko)
Scanner la sécurité (détection vulnérabilités avec Trivy)

Mon projet implémente ces 3 étapes, avec des explications sur pourquoi chacune est importante.

Ce que tu vas découvrir dans cette série d'articles

Je vais publier 7 articles qui détaillent tout le processus, dans l'ordre :

Article 1 (celui-ci) → Pourquoi ce projet existe
Article 2 → Pipeline, stages, jobs : comprendre l'exécution réelle
Article 3 → Ma première pipeline fonctionnelle (et pourquoi elle cassait)
Article 4 → Ajouter une étape "compliance" avec Hadolint
Article 5 → Build d'image Docker avec Kaniko (sans Docker-in-Docker)
Article 6 → Scanner l'image avec Trivy (security)
Article 7 → Ce que j'ai appris (et les erreurs à éviter)

Pourquoi ce projet est différent des tutos classiques

La plupart des tutoriels GitLab CI te montrent un .gitlab-ci.yml tout fait, avec 200 lignes, et te disent "voilà, ça marche".

Mon approche ?

Partir du strict minimum (1 job qui fait echo)
Ajouter une complexité à la fois (lint, puis build, puis security)
Expliquer chaque choix technique (pourquoi Kaniko ? pourquoi Trivy ?)
Documenter les erreurs réelles (pas juste "ça marche du premier coup")
Fournir un repo GitHub/GitLab utilisable tel quel

Les technologies utilisées dans le projet

Outil	Rôle	Pourquoi ce choix ?
GitLab CI	Orchestration CI/CD	Standard industrie, intégré GitLab
Hadolint	Lint Dockerfile	Détecte mauvaises pratiques Docker
Kaniko	Build image Docker	Pas besoin de Docker daemon (plus sûr)
Trivy	Scan sécurité	Détecte vulnérabilités CVE dans l'image

Ce que tu peux faire avec ce repo

👨‍🎓 Si tu es étudiant

Clone le repo et teste la pipeline sur ton propre GitLab
Modifie le Dockerfile pour voir comment réagissent Hadolint et Trivy
Casse volontairement des choses pour comprendre les erreurs
Adapte la CI à ton propre projet de TP

👨‍💻 Si tu es dev/ops

Récupère des snippets réutilisables (job Kaniko, job Trivy…)
Compare avec ta CI actuelle (tu fais peut-être du Docker-in-Docker dangereux ?)
Utilise comme base pour former des juniors

Les prochaines améliorations possibles

Ce projet est un point de départ, pas une solution complète. Voici ce que je pourrais ajouter plus tard :

Déploiement automatique (Ansible, Kubernetes, Docker Swarm)
Tests applicatifs (pytest, coverage)
Multi-environnements (staging, production, feature branches)
Métriques de qualité (coverage, performance)
Secrets management (HashiCorp Vault, GitLab CI variables)

Conclusion : apprendre en cassant, pas en copiant

GitLab CI/CD, tu peux l'apprendre en une soirée… ou tu peux passer 3 jours à te battre avec une erreur mystérieuse de runner.

Ce repo, c'est mon moyen de transformer ces galères en apprentissage structuré.

Si toi aussi tu en as marre des tutos qui "marchent magiquement", clone le projet et casse tout :

👉 GitLab CI Learning sur GitLab

Et dans le prochain article, on entre dans le concret : comment GitLab exécute vraiment ta pipeline (spoiler : l'ordre des jobs ne dépend pas de l'ordre d'écriture).

Tu as des questions sur le projet ? Des suggestions d'amélioration ? Laisse un commentaire ! 👇

Tags: #gitlab #cicd #devops #learning #docker #security #python #devsecops #student #tutorial

Comment j'ai mis en place une stack de monitoring complète sur Kubernetes

BeardDemon — Wed, 21 Jan 2026 19:27:46 +0000

Le problème

Avant le monitoring, débugger c'était:

SSH sur le master
kubectl get pods pour trouver le pod qui plante
kubectl logs <pod> pour voir les logs
Répéter pour chaque pod
Perdre 30 minutes pour comprendre ce qui se passe

Résultat: c'était insupportable avec 10+ pods qui tournent.

La solution: Loki + Fluent Bit + Grafana

L'idée c'est simple:

Fluent Bit: collecte les logs de TOUS les pods
Loki: stocke les logs (comme ElasticSearch mais en plus simple)
Grafana: interface web pour chercher et visualiser

Tout centralisé, recherche en temps réel, c'est le rêve.

Architecture

┌─────────────────────────────────────────┐
│         Cluster Kubernetes              │
│                                         │
│  ┌────────┐  ┌────────┐  ┌────────┐   │
│  │  Pod 1 │  │  Pod 2 │  │  Pod N │   │
│  └───┬────┘  └───┬────┘  └───┬────┘   │
│      │           │            │        │
│      └───────────┼────────────┘        │
│                  ▼                      │
│          ┌──────────────┐               │
│          │ Fluent Bit   │               │
│          │ (DaemonSet)  │               │
│          └──────┬───────┘               │
│                 │                       │
│                 ▼                       │
│          ┌──────────────┐               │
│          │     Loki     │               │
│          └──────┬───────┘               │
│                 │                       │
│                 ▼                       │
│          ┌──────────────┐               │
│          │   Grafana    │               │
│          └──────────────┘               │
└─────────────────────────────────────────┘

Installation de Loki

Voici mon manifest Kubernetes pour Loki:

apiVersion: v1
kind: ConfigMap
metadata:
  name: loki-config
  namespace: logging
data:
  loki.yaml: |
    auth_enabled: false

    server:
      http_listen_port: 3100
      log_level: info

    common:
      path_prefix: /loki
      storage:
        filesystem:
          chunks_directory: /loki/chunks
          rules_directory: /loki/rules
      replication_factor: 1

    schema_config:
      configs:
        - from: 2020-10-24
          store: tsdb
          object_store: filesystem
          schema: v13
          index:
            prefix: index_
            period: 24h
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: loki
  namespace: logging
spec:
  serviceName: loki
  replicas: 1
  template:
    spec:
      containers:
        - name: loki
          image: grafana/loki:3.0.0
          args:
            - -config.file=/etc/loki/loki.yaml
          ports:
            - containerPort: 3100
          volumeMounts:
            - name: config
              mountPath: /etc/loki
            - name: storage
              mountPath: /loki
          resources:
            requests:
              cpu: 100m
              memory: 128Mi
            limits:
              cpu: 500m
              memory: 512Mi
      volumes:
        - name: config
          configMap:
            name: loki-config
  volumeClaimTemplates:
    - metadata:
        name: storage
      spec:
        accessModes: ["ReadWriteOnce"]
        resources:
          requests:
            storage: 5Gi

Le StatefulSet c'est important pour garder les données même si le pod redémarre.

Configuration de Fluent Bit

Fluent Bit tourne en DaemonSet (= 1 pod par node) pour collecter les logs:

apiVersion: v1
kind: ConfigMap
metadata:
  name: fluent-bit-config
  namespace: logging
data:
  fluent-bit.conf: |
    [SERVICE]
        Flush        5
        Log_Level    info

    [INPUT]
        Name              tail
        Path              /var/log/containers/*.log
        Parser            docker
        Tag               kube.*
        Refresh_Interval  5
        Mem_Buf_Limit     5MB

    [FILTER]
        Name                kubernetes
        Match               kube.*
        Kube_URL            https://kubernetes.default.svc:443
        Merge_Log           On
        Keep_Log            Off

    [OUTPUT]
        Name              loki
        Match             *
        Host              loki
        Port              3100
        Labels            job=fluentbit
---
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluent-bit
  namespace: logging
spec:
  template:
    spec:
      serviceAccountName: fluent-bit
      containers:
        - name: fluent-bit
          image: fluent/fluent-bit:3.1.9
          volumeMounts:
            - name: varlog
              mountPath: /var/log
              readOnly: true
            - name: varlibdockercontainers
              mountPath: /var/lib/docker/containers
              readOnly: true
            - name: config
              mountPath: /fluent-bit/etc/
      volumes:
        - name: varlog
          hostPath:
            path: /var/log
        - name: varlibdockercontainers
          hostPath:
            path: /var/lib/docker/containers
        - name: config
          configMap:
            name: fluent-bit-config

Explication:

[INPUT]: Lit les logs dans /var/log/containers/*.log
[FILTER]: Ajoute les métadonnées Kubernetes (namespace, pod name, etc.)
[OUTPUT]: Envoie tout à Loki

Le hostPath monte les dossiers de logs de l'hôte dans le container.

Permissions RBAC pour Fluent Bit

Fluent Bit a besoin de permissions pour lire les infos Kubernetes:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: fluent-bit
  namespace: logging
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: fluent-bit
rules:
  - apiGroups: [""]
    resources: ["pods", "namespaces"]
    verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: fluent-bit
subjects:
  - kind: ServiceAccount
    name: fluent-bit
    namespace: logging
roleRef:
  kind: ClusterRole
  name: fluent-bit
  apiGroup: rbac.authorization.k8s.io

Sans ça, Fluent Bit peut pas enrichir les logs avec les infos des pods.

Installation de Grafana

apiVersion: v1
kind: ConfigMap
metadata:
  name: grafana-datasources
  namespace: logging
data:
  datasources.yaml: |
    apiVersion: 1
    datasources:
      - name: Loki
        type: loki
        access: proxy
        url: http://loki:3100
        isDefault: true
        jsonData:
          maxLines: 1000
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: grafana
  namespace: logging
spec:
  replicas: 1
  template:
    spec:
      containers:
        - name: grafana
          image: grafana/grafana:10.0.0
          ports:
            - containerPort: 3000
          env:
            - name: GF_SECURITY_ADMIN_USER
              value: "admin"
            - name: GF_SECURITY_ADMIN_PASSWORD
              value: "monmotdepasse"
            - name: GF_PATHS_PROVISIONING
              value: /etc/grafana/provisioning
          volumeMounts:
            - name: grafana-datasources
              mountPath: /etc/grafana/provisioning/datasources
      volumes:
        - name: grafana-datasources
          configMap:
            name: grafana-datasources
---
apiVersion: v1
kind: Service
metadata:
  name: grafana
  namespace: logging
spec:
  type: NodePort
  ports:
    - port: 3000
      targetPort: 3000
      nodePort: 30300
  selector:
    app: grafana

Le ConfigMap configure automatiquement Loki comme datasource.

Déploiement avec Ansible

Mon rôle Ansible qui déploie tout:

- name: Créer namespace logging
  command: kubectl create namespace logging
  environment:
    KUBECONFIG: /etc/kubernetes/admin.conf
  ignore_errors: yes

- name: Déployer Loki
  command: kubectl apply -f /vagrant/manifests/logging/loki-values.yml
  environment:
    KUBECONFIG: /etc/kubernetes/admin.conf

- name: Attendre que Loki démarre
  command: kubectl wait --for=condition=ready pod/loki-0 -n logging --timeout=120s
  environment:
    KUBECONFIG: /etc/kubernetes/admin.conf

- name: Déployer Fluent Bit + Grafana
  command: kubectl apply -f /vagrant/manifests/logging/fluentbit-grafana.yaml
  environment:
    KUBECONFIG: /etc/kubernetes/admin.conf

- name: Afficher les infos de connexion
  debug:
    msg:
      - "Stack de Logging déployée!"
      - "Grafana: http://192.168.56.10:30300"
      - "Username: admin"
      - "Password: monmotdepasse"

Utilisation dans Grafana

Une fois connecté à Grafana (http://192.168.56.10:30300):

Explore → Loki

Requête de base:

{job="fluentbit"}

Ça affiche tous les logs.

Filtrer par namespace:

{job="fluentbit", namespace="apps"}

Filtrer par pod:

{job="fluentbit", pod="apicatalogue-xyz"}

Chercher des erreurs:

{job="fluentbit"} |= "error"

Combiner plusieurs filtres:

{job="fluentbit", namespace="apps"} |= "error" != "404"

Créer un dashboard

Dans Grafana: Dashboards → New Dashboard
Add visualization
Query:

   sum by (pod) (count_over_time({job="fluentbit"}[5m]))

Ça affiche le nombre de logs par pod sur 5 minutes

Pratique pour voir quel pod spam les logs.

Les erreurs que j'ai faites

Erreur #1: Pas assez de ressources pour Loki

Au début j'avais mis:

resources:
  limits:
    memory: 128Mi

Loki plantait dès qu'il y avait trop de logs.

Solution: Au moins 512Mi de RAM.

Erreur #2: Fluent Bit sans permissions

J'avais oublié le ServiceAccount et les ClusterRole.

Résultat: Fluent Bit tournait mais envoyait rien à Loki.

Solution: Toujours créer les permissions RBAC.

Erreur #3: Parser les logs JSON manuellement

Au début je parsais pas les logs JSON de Gunicorn.

Résultat: tout en texte brut, impossible de filtrer par niveau de log.

Solution: Ajouter un parser dans la config Fluent Bit.

Vérifier que ça marche

# Logs de Loki
kubectl logs -n logging loki-0

# Logs de Fluent Bit (sur tous les nodes)
kubectl logs -n logging daemonset/fluent-bit

# Tester l'API Loki directement
curl http://192.168.56.10:30300/loki/api/v1/query_range?query={job="fluentbit"}

Requêtes LogQL avancées

Top 10 des pods qui loguent le plus:

topk(10, sum by (pod) (count_over_time({job="fluentbit"}[1h])))

Logs d'erreurs des 10 dernières minutes:

{job="fluentbit"} |= "ERROR" [10m]

Rate de logs par seconde:

rate({job="fluentbit"}[1m])

Conclusion

Cette stack m'a vraiment changé la vie pour le debug:

Plus besoin de SSH
Recherche instantanée dans tous les logs
Dashboards custom
Historique complet (tant que le PVC tient)

Le seul défaut: ça consomme pas mal de ressources (Loki + Grafana = ~700MB de RAM).

Mais ça vaut le coup, vraiment.

Code complet: [GitHub]

Mon architecture microservices e-commerce (et les erreurs à éviter)

BeardDemon — Wed, 21 Jan 2026 19:27:11 +0000

L'architecture complète

4 APIs indépendantes qui communiquent entre elles:

┌──────────────┐
│   Frontend   │ (Django/port 8004)
└──────┬───────┘
       │
       ├──→ API Clients    (Django/port 8000) → MariaDB
       ├──→ API Catalogue  (Django/port 8001) → MariaDB
       ├──→ API Panier     (Flask/port 8002)  → Redis
       └──→ API Commandes  (Django/port 8003) → MariaDB

Chaque API:

A sa propre base de données (MariaDB ou Redis)
Tourne dans son propre container Docker
Est déployée indépendamment sur Kubernetes
A son propre repo Git

API Clients : authentification centralisée

C'est le point d'entrée pour tout ce qui touche aux utilisateurs.

Endpoints principaux:

POST /api/auth/register/  → Créer un compte
POST /api/auth/login/     → Se connecter (retourne un token)
GET  /api/auth/validate-token/  → Valider un token
GET  /api/auth/profile/   → Récupérer son profil

Modèle User:

class User(AbstractUser):
    ROLE_CHOICES = [
        ('client', 'Client'),
        ('vendeur', 'Vendeur'),
        ('admin', 'Administrateur'),
    ]

    role = models.CharField(
        max_length=10,
        choices=ROLE_CHOICES,
        default='client'
    )

Le truc important: les autres APIs ne gèrent PAS l'auth. Elles font juste une requête à l'API Clients pour valider le token.

Authentification externe pour les autres APIs

Voici comment j'ai fait l'auth dans les autres services:

# api/authentification.py (API Catalogue/Commandes)
class ExternalUser:
    def __init__(self, user_id: int, first_name: str, last_name: str, role: str):
        self.id = user_id
        self.first_name = first_name
        self.last_name = last_name
        self.role = role

    @property
    def is_authenticated(self) -> bool:
        return True

class ExternalTokenAuthentication(authentication.BaseAuthentication):
    def authenticate(self, request):
        auth_header = request.META.get("HTTP_AUTHORIZATION", "")
        if not auth_header:
            return None

        parts = auth_header.split()
        if len(parts) != 2 or parts[0] not in {"Bearer", "Token"}:
            raise exceptions.AuthenticationFailed("Format invalide")

        # Appel à l'API Clients
        response = requests.get(
            "http://apiclients:8000/api/auth/validate-token/",
            headers={"Authorization": auth_header},
            timeout=3
        )

        if response.status_code != 200:
            raise exceptions.AuthenticationFailed("Token invalide")

        data = response.json()
        user = ExternalUser(
            user_id=data['user_id'],
            first_name=data['first_name'],
            last_name=data['last_name'],
            role=data['role']
        )

        return user, None

Ça me permet d'utiliser les permissions DRF normalement dans toutes les APIs.

API Catalogue : produits et avis

Gère tout ce qui touche aux produits.

Modèles principaux:

class Category(models.Model):
    name = models.CharField(max_length=100, primary_key=True)
    description = models.TextField()
    enabled = models.BooleanField(default=True)

class Item(models.Model):
    name = models.CharField(max_length=100)
    description = models.TextField()
    price = models.DecimalField(max_digits=10, decimal_places=2)
    picture = models.ImageField(max_length=255)
    stock = models.IntegerField(default=0)
    average_rating = models.FloatField(default=0)
    category_name = models.ForeignKey(Category, on_delete=models.CASCADE)
    id_seller = models.IntegerField()  # Référence vers l'API Clients

class Review(models.Model):
    item = models.ForeignKey(Item, on_delete=models.CASCADE)
    rating = models.FloatField()
    comment = models.TextField()
    id_client = models.IntegerField()  # Référence vers l'API Clients

Le truc cool: Les avis mettent à jour automatiquement la note moyenne grâce aux signals Django:

# api/signals.py
from django.db.models import Avg
from django.db.models.signals import post_save, post_delete

@receiver(post_save, sender=Review)
def on_review_save(sender, instance, **kwargs):
    agg = Review.objects.filter(item_id=instance.item_id).aggregate(avg=Avg('rating'))
    Item.objects.filter(id=instance.item_id).update(
        average_rating=round(agg['avg'] or 0.0, 2)
    )

@receiver(post_delete, sender=Review)
def on_review_delete(sender, instance, **kwargs):
    # Même chose pour la suppression

Gestion du stock

J'ai ajouté un endpoint spécial pour réduire le stock:

def reduce_stock(self, quantity):
    if self.stock < quantity:
        raise ValueError("Stock insuffisant")
    self.stock -= quantity
    self.save()

Cet endpoint est appelé par l'API Commandes quand une commande est validée.

API Panier : Flask + Redis

Contrairement aux autres, celle-ci est en Flask (plus léger pour un simple panier).

Stockage:

# Clé Redis: cart:<user_id>
# Valeur: JSON array d'IDs d'items

def get_cart_for_user(user_id):
    cart_key = f"cart:{user_id}"
    cart_data = redis_client.get(cart_key)
    if cart_data:
        return json.loads(cart_data)
    return []

def save_cart_for_user(user_id, items):
    cart_key = f"cart:{user_id}"
    redis_client.set(cart_key, json.dumps(items))

Endpoints:

GET    /items          → Récupérer son panier
POST   /items          → Ajouter un item
PUT    /items          → Remplacer tout le panier
DELETE /items          → Vider le panier
DELETE /items/<id>     → Supprimer un item

Pourquoi Redis ? Parce que c'est temporaire. Si le serveur redémarre, on s'en fout de perdre les paniers.

API Commandes : l'orchestrateur

Celle-ci coordonne les autres services.

Workflow de création de commande:

def post(self, request):
    # 1. Récupérer les infos des items depuis l'API Catalogue
    for item_input in data['items']:
        item_data = fetch_item_info(item_input['item_id'])

        # 2. Vérifier et réduire le stock
        stock_response = requests.post(
            f"http://apicatalogue:8001/api/items/{item_id}/stock/",
            json={'quantity': quantity}
        )

        if stock_response.status_code != 200:
            return Response({'error': 'Stock insuffisant'}, 400)

    # 3. Créer la commande
    order = Order.objects.create(id_buyer=data['id_buyer'])

    # 4. Sauvegarder les items (snapshot à l'instant T)
    for item_info in items_info:
        OrderItem.objects.create(
            order=order,
            item_id=item_info['item_id'],
            name=item_info['name'],      # Snapshot du nom
            price=item_info['price'],    # Snapshot du prix
            id_seller=item_info['id_seller'],
            quantity=item_info['quantity']
        )

Pourquoi sauvegarder un snapshot ?

Parce que si le vendeur change le prix ou le nom du produit après, la commande doit refléter ce qui était affiché au moment de l'achat.

Génération de PDF

Bonus: chaque commande peut être exportée en PDF avec ReportLab:

from reportlab.platypus import SimpleDocTemplate, Table
from reportlab.lib.pagesizes import A4

def get(self, request, order_id):
    order = Order.objects.get(id=order_id)

    buffer = BytesIO()
    doc = SimpleDocTemplate(buffer, pagesize=A4)

    # Tableau des items
    items_data = [['Article', 'Prix', 'Quantité', 'Total']]
    for item in order.items.all():
        items_data.append([
            item.name,
            f"{item.price}€",
            str(item.quantity),
            f"{item.price * item.quantity}€"
        ])

    table = Table(items_data)
    doc.build([table])

    pdf_content = buffer.getvalue()
    response = HttpResponse(pdf_content, content_type='application/pdf')
    response['Content-Disposition'] = f'attachment; filename="commande_{order.id}.pdf"'
    return response

Les pièges de la communication inter-services

Erreur #1: Timeout par défaut trop court

Les requests Python ont un timeout par défaut infini. J'ai ajouté des timeouts partout:

response = requests.get(url, timeout=3)  # 3 secondes max

Erreur #2: Pas de gestion d'erreur

Si l'API Catalogue est down, l'API Commandes plantait. J'ai ajouté des try/catch:

try:
    response = requests.get(url, timeout=3)
except requests.RequestException:
    return Response({'error': 'Service indisponible'}, 502)

Erreur #3: Circular dependencies

Au début, l'API Catalogue appelait l'API Commandes qui appelait l'API Catalogue. Mauvaise idée.

Solution: Communication unidirectionnelle:

Frontend → APIs
API Commandes → API Catalogue (pour vérifier le stock)
API Catalogue ← Jamais d'appel sortant

Permissions et rôles

Chaque API a ses propres permissions:

# API Catalogue: seul le vendeur peut modifier ses items
class IsItemSeller(permissions.BasePermission):
    def has_object_permission(self, request, view, obj):
        return request.user.id == obj.id_seller

# API Commandes: seul l'admin peut supprimer
class UserAdminPermission(permissions.BasePermission):
    def has_permission(self, request, view):
        return request.user.role == 'admin'

Déploiement Kubernetes

Chaque API a son deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: apicatalogue
spec:
  replicas: 1
  template:
    spec:
      initContainers:
        - name: wait-for-db
          image: busybox:1.36.1
          command: ['sh', '-c', 'until nc -z dbcatalogue 3307; do sleep 2; done;']
      containers:
        - image: ghcr.io/uha-sae53/api-catalogue:latest
          ports:
            - containerPort: 8001
          env:
            - name: DB_CATALOGUE_HOST
              value: "dbcatalogue"

Le initContainer attend que la base soit prête avant de lancer l'API.

Conclusion

Cette archi microservices m'a appris:

La communication inter-services c'est chiant
Les timeouts sont ESSENTIELS
Un service = une responsabilité
Les snapshots de données évitent les incohérences

C'est plus complexe qu'un monolithe, mais ça scale mieux et c'est plus fun à développer.

Code complet: [GitHub]

GitOps avec ArgoCD : comment j'ai automatisé mes déploiements Kubernetes

BeardDemon — Sat, 17 Jan 2026 12:41:19 +0000

Pourquoi ArgoCD ?

Avant ArgoCD, mon workflow de déploiement c'était:

Push le code sur GitHub
GitHub Actions build l'image Docker
L'image est push sur GHCR (GitHub Container Registry)
SSH sur le master Kubernetes
kubectl apply -f manifests/
Croiser les doigts

Résultat ? Souvent des erreurs genre "oups j'ai oublié de mettre à jour le manifest" ou "attends c'est quelle version qui tourne là ?".

Avec ArgoCD, c'est devenu:

Push le code
C'est tout. Vraiment.

ArgoCD surveille mon repo GitHub et déploie automatiquement les nouvelles versions.

Installation d'ArgoCD sur le cluster

Voici mon rôle Ansible qui installe ArgoCD:

- name: Créer namespace argocd
  command: kubectl create namespace argocd
  environment:
    KUBECONFIG: /etc/kubernetes/admin.conf
  ignore_errors: yes

- name: Installer ArgoCD
  command: kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml
  environment:
    KUBECONFIG: /etc/kubernetes/admin.conf
  retries: 3

- name: Attendre les deployments ArgoCD
  command: kubectl wait --for=condition=available --timeout=300s deployment --all -n argocd
  environment:
    KUBECONFIG: /etc/kubernetes/admin.conf

- name: Patcher service en NodePort
  command: kubectl patch svc argocd-server -n argocd -p '{"spec":{"type":"NodePort","ports":[{"port":443,"targetPort":8080,"nodePort":30808}]}}'
  environment:
    KUBECONFIG: /etc/kubernetes/admin.conf

- name: Récupérer mot de passe admin
  shell: kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d
  environment:
    KUBECONFIG: /etc/kubernetes/admin.conf
  register: argocd_password

- name: Afficher les infos ArgoCD
  debug:
    msg:
      - "ArgoCD installé avec succès"
      - "URL: https://192.168.56.10:30808"
      - "Login: admin"
      - "Password: {{ argocd_password.stdout }}"

Après ça, je peux accéder à l'interface web d'ArgoCD sur https://192.168.56.10:30808.

ArgoCD Image Updater : le vrai game changer

Le truc cool avec ArgoCD Image Updater, c'est qu'il surveille mon GitHub Container Registry et met à jour automatiquement mes manifests quand une nouvelle image est dispo.

Installation:

- name: Télécharger manifeste ArgoCD Image Updater
  get_url:
    url: https://raw.githubusercontent.com/argoproj-labs/argocd-image-updater/stable/config/install.yaml
    dest: /tmp/argocd-image-updater.yaml

# IMPORTANT: Tout mettre dans le namespace argocd
- name: Modifier les namespaces vers argocd
  shell: |
    sed -i 's/namespace: argocd-image-updater-system/namespace: argocd/g' /tmp/argocd-image-updater.yaml
    sed -i 's/namespace: argocd-image-updater/namespace: argocd/g' /tmp/argocd-image-updater.yaml

- name: Installer ArgoCD Image Updater
  command: kubectl apply -f /tmp/argocd-image-updater.yaml
  environment:
    KUBECONFIG: /etc/kubernetes/admin.conf

- name: Configurer le log-level à debug
  shell: kubectl patch deployment argocd-image-updater -n argocd --type json -p '[{"op": "add", "path": "/spec/template/spec/containers/0/args/-", "value": "--loglevel=debug"}]'
  environment:
    KUBECONFIG: /etc/kubernetes/admin.conf

Créer une Application ArgoCD

Voici comment je déclare mon API Catalogue dans ArgoCD:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: catalogue-manager-application
  namespace: argocd
  annotations:
    # Config pour Image Updater
    argocd-image-updater.argoproj.io/image-list: catalogue-manager=ghcr.io/uha-sae53/api-catalogue
    argocd-image-updater.argoproj.io/catalogue-manager.update-strategy: latest
    argocd-image-updater.argoproj.io/catalogue-manager.force-update: "true"
    argocd-image-updater.argoproj.io/write-back-method: argocd
spec:
  destination:
    namespace: apps
    server: https://kubernetes.default.svc
  source:
    path: ansible-provisioning/manifests/apicatalogue
    repoURL: https://github.com/uha-sae53/Vagrant.git
    targetRevision: main
  project: default
  syncPolicy:
    automated:
      prune: true        # Supprime les ressources qui sont plus dans Git
      selfHeal: true     # Remet en place si on modifie à la main
    syncOptions:
      - CreateNamespace=true

Les annotations argocd-image-updater c'est ce qui fait la magie:

Il surveille ghcr.io/uha-sae53/api-catalogue
Dès qu'un tag :latest est push, il met à jour le manifest
force-update: true = il force même si le tag existe déjà (utile pour :latest)

Le workflow complet

Je push du code sur main
GitHub Actions:

   - name: Build and push Docker image
     uses: docker/build-push-action@v4
     with:
       context: .
       push: true
       tags: |
         ghcr.io/uha-sae53/api-catalogue:latest
         ghcr.io/uha-sae53/api-catalogue:${{ github.sha }}

ArgoCD Image Updater détecte la nouvelle image
Il update le manifest dans ArgoCD (pas dans Git, dans ArgoCD)
ArgoCD sync automatiquement sur le cluster
Mes pods redémarrent avec la nouvelle version

Temps total: ~3 minutes.

Config GitHub Actions (le CI)

Voici ma CI complète pour l'API Catalogue:

name: Django CI

on:
  push:
    branches: [ "main", "dev" ]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v4
    - name: Set up Python
      uses: actions/setup-python@v3
      with:
        python-version: 3.13
    - name: Install Dependencies
      run: |
        pip install -r requirements.txt
    - name: Run Tests
      run: |
        python projet/manage.py test

  build-and-push-docker:
    needs: test
    runs-on: ubuntu-latest
    steps:
      - name: Checkout repository
        uses: actions/checkout@v4

      - name: Log in to GitHub Container Registry
        uses: docker/login-action@v2
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}

      - name: Build and push Docker image
        uses: docker/build-push-action@v4
        with:
          context: .
          file: ./Dockerfile
          push: true
          tags: |
            ghcr.io/uha-sae53/api-catalogue:latest
            ghcr.io/uha-sae53/api-catalogue:${{ github.sha }}

Les erreurs que j'ai faites

Erreur #1: Images privées sans secret

Au début mes images GHCR étaient privées. ArgoCD Image Updater pouvait pas les pull.

Solution: Passer les images en publiques. C'est un projet d'école, pas besoin de les cacher.

Erreur #2: Namespaces multiples pour Image Updater

J'avais laissé le namespace par défaut argocd-image-updater-system. Ça créait des conflicts de droits.

Solution: Tout mettre dans le namespace argocd avec le sed.

Erreur #3: Pas de `force-update`

Sans force-update: true, Image Updater mettait pas à jour si le tag :latest existait déjà.

Résultat ? Mes nouveaux builds étaient ignorés.

Vérifier que ça marche

# Voir les applications ArgoCD
kubectl get applications -n argocd

# Logs d'Image Updater
kubectl logs -n argocd deployment/argocd-image-updater -f

# Voir l'état de sync
kubectl get app catalogue-manager-application -n argocd -o yaml

Dashboard ArgoCD

Dans l'interface web d'ArgoCD, je vois:

Tous mes services
Leur état de sync (vert = ok)
L'historique des déploiements
Les différences entre Git et le cluster

C'est pratique pour voir d'un coup d'œil ce qui tourne.

Conclusion

GitOps c'est pas juste un buzzword. Ça m'a vraiment simplifié la vie:

Plus de kubectl apply manuel
Traçabilité complète (tout est dans Git)
Rollback facile
Pas de drift entre environnements

Le seul défaut ? C'est un peu overkill pour un cluster de dev. Mais bon, c'est cool à mettre sur le CV.

Code complet: [lien GitHub]

J'ai réduit mes images Docker de 800MB à 120MB (et vous pouvez faire pareil)

BeardDemon — Tue, 13 Jan 2026 12:50:53 +0000

Le problème de départ

Mes premières images Docker pour le projet e-commerce:

API Clients: 847 MB
API Catalogue: 823 MB
API Commandes: 891 MB

Totalement ridicule pour des APIs Django qui font juste du CRUD.

Le pire ? Mes workers Kubernetes galéraient à pull les images. Ça prenait 2-3 minutes par image. Sur un cluster de 2 workers avec 4 services, faites le calcul...

Ce que j'ai changé

Après optimisation:

API Clients: 127 MB (-85%)
API Catalogue: 119 MB (-86%)
API Commandes: 132 MB (-85%)

Et le meilleur : elles marchent EXACTEMENT pareil.

La technique : multi-stage build + from scratch

Étape 1 : Builder (Alpine)

FROM python:3-alpine AS builder

# Installer les outils de compilation
RUN apk add --no-cache gcc python3-dev musl-dev mariadb-dev pkgconf

# Créer un venv
RUN python -m venv /opt/venv
ENV PATH="/opt/venv/bin:$PATH"

COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

# Virer pip (on en a plus besoin)
RUN pip uninstall pip -y

# Nettoyage agressif
RUN find /opt/venv -type d \( \
        -name 'tests' -o \
        -name '__pycache__' -o \
        -name '*.dist-info' \
    \) -exec rm -rf {} + 2>/dev/null || true

Cette étape compile tout. C'est gros, c'est moche, mais c'est temporaire.

Étape 2 : Syscollector (récupérer juste ce qu'il faut)

FROM python:3-alpine AS syscollector

RUN apk add --no-cache mariadb-connector-c

RUN mkdir -p /rootfs/lib /rootfs/usr/lib /rootfs/usr/local/bin

# Copier Python + stdlib complète
RUN cp /usr/local/bin/python3* /rootfs/usr/local/bin/ && \
    cp -r /usr/local/lib/python3* /rootfs/usr/local/lib/

# Copier sh (pour le entrypoint)
RUN cp /bin/sh /rootfs/bin/

# Récupérer les dépendances avec ldd
RUN ldd /usr/local/bin/python3* /bin/sh 2>/dev/null | \
    grep "=>" | awk '{print $3}' | \
    sort -u | xargs -I '{}' cp '{}' /rootfs/lib/

# Dynamic linker
RUN cp /lib/ld-musl-*.so.1 /rootfs/lib/

# Libs MariaDB
RUN find /usr/lib -name 'libmariadb*.so*' -exec cp {} /rootfs/usr/lib/ \;

Ici, je récupère UNIQUEMENT ce dont j'ai besoin. Pas de package manager, pas d'outils de debug, rien.

Étape 3 : Image finale (from scratch)

FROM scratch

COPY --from=syscollector /rootfs /
COPY --from=builder /opt/venv /opt/venv
COPY . /app

ENV PATH="/opt/venv/bin:/usr/local/bin:/bin" \
    LD_LIBRARY_PATH="/lib:/usr/lib:/usr/local/lib" \
    PYTHONDONTWRITEBYTECODE=1 \
    PYTHONUNBUFFERED=1

WORKDIR /app/project
EXPOSE 8000

ENTRYPOINT ["sh", "/app/docker-entrypoint.sh"]

FROM scratch = littéralement RIEN. Même pas un shell de base. C'est pour ça qu'il faut copier /bin/sh dans l'étape 2.

Les pièges que j'ai rencontrés

Piège #1 : Supprimer les *.dist-info

Au début j'ai fait:

find /opt/venv -name '*.dist-info' -exec rm -rf {} +

Résultat ? Plus rien marchait. Python utilisait ces fichiers pour importer les packages.

Solution: Garder les métadonnées critiques, virer que le superflu.

Piège #2 : Oublier le dynamic linker

standard_init_linux.go:228: exec user process caused: no such file or directory

Ce message cryptique = j'avais oublié de copier /lib/ld-musl-*.so.1.

Piège #3 : MariaDB qui fait des siennes

MariaDB a besoin de plein de libs partagées. J'utilisais ldd pour les trouver:

ldd /usr/lib/libmariadb.so.3

Et je copiais toutes les dépendances dans /rootfs/lib.

Comparaison avant/après

Avant (image basique)

FROM python:3

COPY requirements.txt .
RUN pip install -r requirements.txt
COPY . /app
WORKDIR /app

CMD ["gunicorn", "app:app"]

Taille: 847 MB

Layers: 12

Temps de pull: 2min 34s (sur mon cluster)

Après (optimisée)

Taille: 127 MB

Layers: 7

Temps de pull: 14s

Le gain de temps sur les déploiements est ÉNORME.

Le docker-entrypoint.sh

Petit bonus, mon script d'entrypoint fait les migrations automatiquement:

#!/bin/bash
set -e

echo "Running migrations..."
python3 manage.py makemigrations api
python3 manage.py migrate --noinput

echo "Collecting static..."
python3 manage.py collectstatic --noinput

echo "Starting Gunicorn..."
exec gunicorn project.wsgi:application --bind 0.0.0.0:8000

Métriques finales

Métrique	Avant	Après	Gain
Taille image	847 MB	127 MB	-85%
Temps de build	4min 12s	3min 8s	-25%
Temps de pull	2min 34s	14s	-91%
Layers	12	7	-42%

Conclusion

Est-ce que ça vaut le coup ? Pour moi, OUI:

Déploiements plus rapides
Moins de bande passante
Images plus sécurisées (surface d'attaque réduite)

Par contre, c'est plus complexe à débugger. Pas de apt install, pas de curl, rien. Si vous avez besoin de débugger, utilisez une image de dev normale.

Le code complet est sur mon GitHub : [lien vers le repo]

Des questions ? Ping moi sur Twitter [@tonhandle]

J'ai galéré pendant 3 semaines pour monter un cluster Kubernetes (et voilà ce que j'ai appris)

BeardDemon — Sat, 10 Jan 2026 09:08:21 +0000

Le contexte

Bon, soyons honnêtes. Au début, j'avais un gros bordel de scripts bash éparpillés partout. Genre 5-6 fichiers avec des noms comme install-docker.sh, setup-k8s-FINAL-v3.sh (oui, le v3...). À chaque fois que je devais recréer mon infra, c'était 45 minutes de galère + 10 minutes à me demander pourquoi ça marchait pas.

J'avais besoin de quelque chose de plus propre pour mon projet SAE e-commerce.

Ce que je voulais vraiment

Pas un truc de démo avec minikube. Non. Je voulais:

3 VMs qui tournent vraiment (1 master + 2 workers)
Tout automatisé - je tape une commande et ça se déploie
ArgoCD pour faire du GitOps (parce que push to deploy c'est quand même cool)
Des logs centralisés (Loki + Grafana)
Et surtout : pouvoir tout péter et tout recréer en 10 minutes

L'architecture (spoiler: ça marche maintenant)

┌─────────────────────────────────────────┐
│           Mon PC (Debian)               │
│  ┌──────────┐  ┌──────────┐  ┌─────────┐
│  │ Master   │  │ Worker 1 │  │ Worker 2│
│  │ .56.10   │  │ .56.11   │  │ .56.12  │
│  └──────────┘  └──────────┘  └─────────┘
└─────────────────────────────────────────┘

Chaque VM a 4Go de RAM et 4 CPUs. Oui, ça bouffe des ressources. Non, ça passe pas sur un laptop pourri.

Comment c'est organisé

J'ai tout mis dans un repo bien rangé (pour une fois):

ansible-provisioning/
├── Vagrantfile              # Les 3 VMs
├── playbook.yml             # Le chef d'orchestre
├── manifests/               # Mes applis K8s
│   ├── apiclients/
│   ├── apicatalogue/
│   ├── databases/
│   └── ... (toutes mes APIs)
└── roles/                   # Les briques Ansible
    ├── docker/
    ├── kubernetes/
    ├── k8s-master/
    └── argocd/

Chaque rôle fait UN truc. C'est ça qui a changé ma vie.

Shell scripts → Ansible : pourquoi j'ai migré

Avant (la galère)

J'avais un script prepare-system.sh qui ressemblait à ça:

#!/bin/bash
swapoff -a
sed -i '/swap/d' /etc/fstab
modprobe br_netfilter
# ... 50 lignes de commandes
# Aucune gestion d'erreur
# Si ça plante au milieu, bonne chance

Le pire ? Si je relançais le script après un fail, tout pétait. Genre le sed essayait de supprimer une ligne qui existait plus. Classique.

Après (je respire enfin)

Maintenant j'ai un rôle Ansible system-prepare:

- name: Virer le swap
  shell: swapoff -a
  ignore_errors: yes

- name: Enlever le swap du fstab
  lineinfile:
    path: /etc/fstab
    regexp: '.*swap.*'
    state: absent

- name: Charger br_netfilter
  modprobe:
    name: br_netfilter
    state: present

La différence ?

Je peux relancer 10 fois, ça fait pas de conneries
C'est lisible par un humain
Si ça plante, je sais exactement où

Le Vagrantfile (ou comment lancer 3 VMs d'un coup)

Vagrant.configure("2") do |config|
  config.vm.box = "debian/bullseye64"

  # Config libvirt (KVM/QEMU)
  config.vm.provider "libvirt" do |libvirt|
    libvirt.memory = 4096
    libvirt.cpus = 4
    libvirt.management_network_address = "192.168.56.0/24"
  end

  # NFS pour partager les manifests
  config.vm.synced_folder ".", "/vagrant", 
    type: "nfs", 
    nfs_version: 4

  # Le master
  config.vm.define "vm-master" do |vm|
    vm.vm.network "private_network", ip: "192.168.56.10"
    vm.vm.hostname = "master"
  end

  # Les 2 workers
  (1..2).each do |i|
    config.vm.define "vm-slave-#{i}" do |vm|
      vm.vm.network "private_network", ip: "192.168.56.1#{i}"
      vm.vm.hostname = "slave-#{i}"
    end
  end

  # Ansible se lance automatiquement
  config.vm.provision "ansible" do |ansible|
    ansible.playbook = "playbook.yml"
    ansible.groups = {
      "master" => ["vm-master"],
      "workers" => ["vm-slave-1", "vm-slave-2"]
    }
  end
end

Un vagrant up et boom, tout se monte tout seul.

Le playbook : l'ordre c'est important

---
# 1. Tous les nœuds en même temps
- name: Setup de base
  hosts: k8s_cluster
  roles:
    - system-prepare    # Swap off, modules kernel
    - docker            # Docker + containerd
    - kubernetes        # kubelet, kubeadm, kubectl

# 2. Le master d'abord
- name: Init master
  hosts: master
  roles:
    - k8s-master        # kubeadm init + Flannel

# 3. Les workers ensuite, un par un
- name: Join workers
  hosts: workers
  serial: 1             # IMPORTANT: un à la fois
  roles:
    - k8s-worker

# 4. Les trucs bonus sur le master
- name: Dashboard + ArgoCD + Monitoring
  hosts: master
  roles:
    - k8s-dashboard
    - argocd
    - logging
    - metrics-server

Le serial: 1 c'est crucial. J'avais essayé sans, les deux workers essayaient de join en même temps et ça partait en cacahuète.

Les rôles en détail

Rôle: k8s-master (le chef d'orchestre)

C'est lui qui initialise le cluster. Voici les parties importantes:

- name: Init cluster k8s
  command: kubeadm init --apiserver-advertise-address=192.168.56.10 --pod-network-cidr=10.244.0.0/16
  when: not k8s_initialise.stat.exists

- name: Copier config kubectl
  copy:
    src: /etc/kubernetes/admin.conf
    dest: /home/vagrant/.kube/config
    owner: vagrant
    group: vagrant

- name: Installer Flannel (réseau pod)
  shell: |
    kubectl apply -f https://github.com/flannel-io/flannel/releases/latest/download/kube-flannel.yml
  environment:
    KUBECONFIG: /home/vagrant/.kube/config

- name: Générer commande join pour les workers
  copy:
    content: "kubeadm join 192.168.56.10:6443 --token {{ k8s_token.stdout }} --discovery-token-ca-cert-hash sha256:{{ k8s_ca_hash.stdout }}"
    dest: /vagrant/join.sh
    mode: '0755'

- name: Créer fichier .master-ready
  copy:
    content: "Master initialized"
    dest: /vagrant/.master-ready

Le fichier .master-ready c'est un flag pour dire aux workers "go, vous pouvez join maintenant".

Rôle: k8s-worker (le suiveur patient)

- name: Attendre que le fichier .master-ready existe
  wait_for:
    path: /vagrant/.master-ready
    timeout: 600

- name: Joindre le cluster
  shell: bash /vagrant/join.sh
  args:
    creates: /etc/kubernetes/kubelet.conf
  register: join_result
  failed_when:
    - join_result.rc != 0
    - "'already exists in the cluster' not in join_result.stderr"

- name: Attendre que le node soit Ready
  shell: |
    for i in {1..60}; do
      STATUS=$(kubectl get node $(hostname) -o jsonpath='{.status.conditions[?(@.type=="Ready")].status}')
      if [ "$STATUS" = "True" ]; then
        exit 0
      fi
      sleep 5
    done
    exit 1

Le worker attend gentiment que le master soit prêt avant de faire quoi que ce soit.

Les galères que j'ai rencontrées

Galère #1: NFS qui marche pas

Au début, le partage NFS entre l'hôte et les VMs plantait.

Symptôme:

mount.nfs: Connection timed out

Solution:

# Sur l'hôte
sudo apt install nfs-kernel-server
sudo systemctl start nfs-server
sudo ufw allow from 192.168.56.0/24

Le firewall bloquait les connexions NFS. Classique.

Galère #2: Kubeadm qui timeout

Le kubeadm init prenait 10 minutes et finissait par timeout.

Cause: Pas assez de RAM sur les VMs (j'avais mis 2Go).

Solution: Passer à 4Go par VM. Ça bouffe mais c'est nécessaire.

Galère #3: Les workers qui join pas

Les workers restaient en NotReady même après le join.

Cause: Flannel (le CNI) était pas encore installé sur le master.

Solution: Attendre que Flannel soit complètement déployé avant de faire join les workers:

- name: Attendre Flannel
  command: kubectl wait --for=condition=ready pod -l app=flannel -n kube-flannel --timeout=300s
  environment:
    KUBECONFIG: /etc/kubernetes/admin.conf

Galère #4: Ansible qui relance tout à chaque fois

Au début, chaque vagrant provision refaisait TOUT depuis zéro.

Solution: Ajouter des conditions when partout:

- name: Init cluster k8s
  command: kubeadm init ...
  when: not k8s_initialise.stat.exists  # ← Ça sauve des vies

L'idempotence c'est vraiment la base avec Ansible.

Les commandes utiles au quotidien

# Lancer tout
cd ansible-provisioning && vagrant up

# Vérifier l'état du cluster
vagrant ssh vm-master -c 'kubectl get nodes'

# Voir les pods
vagrant ssh vm-master -c 'kubectl get pods -A'

# Refaire le provisioning (sans détruire les VMs)
vagrant provision

# Tout péter et recommencer
vagrant destroy -f && vagrant up

# SSH sur le master
vagrant ssh vm-master

# Logs d'un pod
vagrant ssh vm-master -c 'kubectl logs -n apps apicatalogue-xyz'

ArgoCD et les applications

Une fois le cluster monté, ArgoCD déploie automatiquement mes apps.

Voici comment je déclare l'API Catalogue:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: catalogue-manager-application
  namespace: argocd
spec:
  destination:
    namespace: apps
    server: https://kubernetes.default.svc
  source:
    path: ansible-provisioning/manifests/apicatalogue
    repoURL: https://github.com/uha-sae53/Vagrant.git
    targetRevision: main
  project: default
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

ArgoCD surveille mon repo GitHub. Dès que je change un manifest, ça se déploie automatiquement.

Metrics Server et HPA

J'ai aussi ajouté le Metrics Server pour l'auto-scaling:

- name: Installer Metrics Server
  shell: |
    kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml
  environment:
    KUBECONFIG: /etc/kubernetes/admin.conf

- name: Patcher pour ignorer TLS (dev seulement)
  shell: |
    kubectl patch deployment metrics-server -n kube-system --type='json' \
    -p='[{"op": "add", "path": "/spec/template/spec/containers/0/args/-", "value": "--kubelet-insecure-tls"}]'

Avec ça, mes pods peuvent scaler automatiquement en fonction de la charge CPU/RAM.

Le résultat final

Après tout ça, voici ce que je peux faire:

# Démarrer tout de zéro
vagrant up
# ⏱️ 8 minutes plus tard...

# Vérifier que tout tourne
vagrant ssh vm-master -c 'kubectl get pods -A'

# Résultat:
# NAMESPACE     NAME                          READY   STATUS
# apps          apicatalogue-xyz              1/1     Running
# apps          apiclients-abc                1/1     Running
# apps          apicommandes-def              1/1     Running
# apps          api-panier-ghi                1/1     Running
# apps          frontend-jkl                  1/1     Running
# argocd        argocd-server-xxx             1/1     Running
# logging       grafana-yyy                   1/1     Running
# logging       loki-0                        1/1     Running
# kube-system   metrics-server-zzz            1/1     Running

Tout fonctionne, tout est automatisé.

Conclusion

Ce que j'ai appris:

Ansible > scripts shell (vraiment, vraiment)
L'idempotence c'est pas un luxe
Tester chaque rôle séparément avant de tout brancher
Les workers doivent attendre le master (le serial: 1 sauve des vies)
4Go de RAM minimum par VM pour K8s

Le code complet est sur GitHub: https://github.com/uha-sae53/Vagrant

Des questions ? Ping moi sur Twitter ou ouvre une issue sur le repo.

Et si vous galérez avec Kubernetes, vous êtes pas seuls. J'ai passé 3 semaines là-dessus, c'est normal que ce soit compliqué au début.

DEV Community: BeardDemon

Pourquoi j'ai créé un projet pour apprendre GitLab CI/CD (et pourquoi la doc ne suffit pas)

Le problème avec l'apprentissage "théorique" de la CI/CD

L'idée : un "bac à sable" pédagogique

Les objectifs concrets de ce repo

Objectif 1 : Comprendre la structure d'une pipeline

Objectif 2 : Savoir pourquoi une pipeline "casse"

Objectif 3 : Construire une CI "professionnelle"

Ce que tu vas découvrir dans cette série d'articles

Pourquoi ce projet est différent des tutos classiques

Les technologies utilisées dans le projet

Ce que tu peux faire avec ce repo

👨‍🎓 Si tu es étudiant

👨‍💻 Si tu es dev/ops

Les prochaines améliorations possibles

Conclusion : apprendre en cassant, pas en copiant

Comment j'ai mis en place une stack de monitoring complète sur Kubernetes

Le problème

La solution: Loki + Fluent Bit + Grafana

Architecture

Installation de Loki

Configuration de Fluent Bit

Permissions RBAC pour Fluent Bit

Installation de Grafana

Déploiement avec Ansible

Utilisation dans Grafana

Explore → Loki

Créer un dashboard

Les erreurs que j'ai faites

Erreur #1: Pas assez de ressources pour Loki

Erreur #2: Fluent Bit sans permissions

Erreur #3: Parser les logs JSON manuellement

Vérifier que ça marche

Requêtes LogQL avancées

Conclusion

Mon architecture microservices e-commerce (et les erreurs à éviter)

L'architecture complète

API Clients : authentification centralisée

Authentification externe pour les autres APIs

API Catalogue : produits et avis

Gestion du stock

API Panier : Flask + Redis

API Commandes : l'orchestrateur

Génération de PDF

Les pièges de la communication inter-services

Erreur #1: Timeout par défaut trop court

Erreur #2: Pas de gestion d'erreur

Erreur #3: Circular dependencies

Permissions et rôles

Déploiement Kubernetes

Conclusion

GitOps avec ArgoCD : comment j'ai automatisé mes déploiements Kubernetes

Pourquoi ArgoCD ?

Installation d'ArgoCD sur le cluster

ArgoCD Image Updater : le vrai game changer

Créer une Application ArgoCD

Le workflow complet

Config GitHub Actions (le CI)

Les erreurs que j'ai faites

Erreur #1: Images privées sans secret

Erreur #2: Namespaces multiples pour Image Updater

Erreur #3: Pas de force-update

Vérifier que ça marche

Dashboard ArgoCD

Conclusion

J'ai réduit mes images Docker de 800MB à 120MB (et vous pouvez faire pareil)

Le problème de départ

Ce que j'ai changé

La technique : multi-stage build + from scratch

Étape 1 : Builder (Alpine)

Étape 2 : Syscollector (récupérer juste ce qu'il faut)

Étape 3 : Image finale (from scratch)

Les pièges que j'ai rencontrés

Piège #1 : Supprimer les *.dist-info

Piège #2 : Oublier le dynamic linker

Piège #3 : MariaDB qui fait des siennes

Comparaison avant/après

Avant (image basique)

Après (optimisée)

Le docker-entrypoint.sh

Erreur #3: Pas de `force-update`