Architecture Dolibarr : Kubernetes avec des exemples concrets

Guide complet pour déployer, configurer et exploiter Dolibarr (ERP/CRM) dans un cluster Kubernetes.

1. Pourquoi déployer Dolibarr avec Kubernetes ?

Avantages Explications
Scalabilité Possibilité de répliquer les pods web‑front et le worker selon la charge (ex. : HorizontalPodAutoscaler).
Disponibilité Pods redondants, liveness/readiness probes, basculement automatique.
Gestion déclarative Tout le déploiement décrit dans des manifests YAML/Helm, versionnable dans Git.
Isolation des dépendances Base de données (MariaDB/MySQL) séparée, stockage persistant via PVC, secrets centralisés.
CI/CD Intégration facile avec GitHub Actions, GitLab CI, Argo CD, etc.
Portabilité Le même packaging fonctionne sur n’importe quel cloud (GKE, AKS, EKS, OpenShift, on‑prem).

2. Schéma d’architecture proposé

+----------------------+          +----------------------+

|  Ingress / LB        |  <--->   |  Service (ClusterIP) |

+----------------------+          +----------------------+

               |                               |

               v                               v

+----------------------+          +----------------------+

|  Deployment (php‑fpm) |          |  Deployment (worker)|

|  - replicas          |          |  - workers           |

+----------------------+          +----------------------+

               |                               |

               v                               v+----------------------+          +----------------------+

|  Service (ClusterIP) |          |  Service (ClusterIP) |

+----------------------+          +----------------------+

               |                               |

               +-------------+-----------------+

                             |

                             v

+----------------------+          +----------------------+

|  PersistentVolume (PVC)  <--->  MariaDB (StatefulSet) |

+----------------------+          +----------------------+

               |

               v

        +------------------+

        |  ConfigMap / Secret   (settings.php)

        +------------------+

  • php‑fpm : conteneur qui exécute le code PHP de Dolibarr (via apache2 ou nginx).

  • worker : processus php-cli utilisé pour les tâches planifiées (cron, queue de transactions).

  • MariaDB : base de données persistante; déployée en StatefulSet pour garantir l’ordre et la stabilité du stockage.

  • Ingress : point d’entrée externe (Let’s Encrypt, TLS, auth‑proxy).

  • ConfigMap & Secret : centralisent les variables de configuration (settings.php, credentials DB).

3. Prérequis avant de commencer

Élément Version minimale / Recommandation
Kubernetes 1.23+ (avec csi pour le stockage)
Helm 3.9+ (optionnel mais fortement conseillé)
Ingress controller NGINX Ingress, Traefik, ou équivalent
Stockage Volume provisioner (OpenStorage, CSI‑ driver) qui supporte les ReadWriteOnce/ReadWriteMany selon votre besoin
Domaine DNS dolibarr.mondomaine.com (ou sous‑domaine) pointant sur l’IP de votre Ingress LB
TLS Certificat Let’s Encrypt ou équivalent (prévoir un Ingress TLS)

4. Déploiementman via les manifests Kubernetes (sans Helm)

Astuce : stockez chaque fichier sous un répertoire k8s/ versionné et appliquez kubectl apply -k ./k8s.

4.1. ConfigMap – dolibarr-configmap.yaml

apiVersion: v1

kind: ConfigMap

metadata:

  name: dolibarr-config

  labels:

    app: dolibarr

data:

  # déplacement du fichier settings.php dans /var/www/dolibarr/conf

  settings.php: |

    <?php

    <?php

    $conf->dbname = 'dolibarr';

    $conf->dbhost = 'mariadb';

    $conf->dbuser = 'dolibarr';

    $conf->dbpass = '{{db_password}}';

    $conf->photo_dir = '/var/www/dolibarr/files/';

    $conf->doc_path = '/var/www/dolibarr/docs/';

    // ... Autres paramètres (ex. activation des modules)

    ?>

Note : les {{...}} seront remplacés par les valeurs réelles via kubectl create secret (voir plus bas). ### 4.2. Secret – dolibarr-secret.yaml

apiVersion: v1

kind: Secret

metadata:

  name: dolibarr-secret

  labels:

    app: dolibarr

type: Opaque

stringData:

  DB_PASSWORD: 'MonTrèsSecret123!'

4.3. Persistent Volume Claim – mariadb-pvc.yaml

Les besoins de Dolibarr sont modestes : 5 Go suffisent pour les fichiers et la BD. 

apiVersion: v1

kind: PersistentVolumeClaim

metadata:

  name: mariadb-pvc

spec:

  accessModes: [ "ReadWriteOnce" ]

  resources:

    requests:

      storage: 10Gi

  storageClassName: standard   # à adapter à votre cluster```
### 4.4. MariaDB StatefulSet – `mariadb-statefulset.yaml`
```yaml

apiVersion: apps/v1

kind: StatefulSet

metadata:

  name: mariadb

spec:

  serviceName: mariadb

  replicas: 1

  selector:

    matchLabels:

      app: mariadb

  template:

    metadata:

      labels:

        app: mariadb

    spec:

      containers:

      - name: mariadb        image: mariadb:10.11

        env:

        - name: MARIADB_ROOT_PASSWORD

          valueFrom:

            secretKeyRef:

              name: mariadb-root-secret

              key: password

        - name: MARIADB_DATABASE

          value: dolibarr

        - name: MARIADB_USER

          value: dolibarr

        - name: MARIADB_PASSWORD

          valueFrom:

            secretKeyRef:

              name: mariadb-credentials              key: password

        ports:

        - containerPort: 3306

          name: mysql

        volumeMounts:

        - name: mariadb-data

          mountPath: /var/lib/mysql

  volumeClaimTemplates:

  - metadata:

      name: mariadb-data

    spec:

      accessModes: [ "ReadWriteOnce" ]

      resources:

        requests:

          storage: 10Gi

      storageClassName: standard

---

apiVersion: v1

kind: Service

metadata:

  name: mariadb

spec:

  ports:

  - port: 3306

    targetPort: 3306

  selector:

    app: mariadb

Remarque : vous pouvez créer les secrets mariadb-root-secret et mariadb-credentials via kubectl create secret generic.

4.5. Deployment – dolibarr-deployment.yaml

apiVersion: apps/v1

kind: Deployment

metadata:

  name: dolibarr

  labels:

    app: dolibarr

spec:

  replicas: 2                     # scaling horizontal possible

  selector:

    matchLabels:

      app: dolibarr

  strategy:

    type: RollingUpdate

    rollingUpdate:

      maxSurge: 1

      maxUnavailable: 0

  template:

    metadata:

      labels:

        app: dolibarr

    spec:

      containers:

      # ---------- PHP-FPM (nginx) ----------

      - name: php-fpm

        image: ghcr.io/dolibrarmor/dolibarr-nginx:latest

        ports:

        - containerPort: 8080

        env:

        - name: DB_HOST

          value: mariadb

        - name: DB_NAME          value: dolibarr

        - name: DB_USER

          value: dolibarr

        - name: DB_PASS

          valueFrom:

            secretKeyRef:

              name: dolibarr-secret

              key: DB_PASSWORD

        - name: APP_BASE_URL          value: https://dolibarr.mondomaine.com/

        - name: PHP_MAX_MEMORY

          value: "256M"

        resources:

          limits:

            cpu: "500m"

            memory: "512Mi"

          requests:

            cpu: "250m"

            memory: "256Mi"

        livenessProbe:

          httpGet:

            path: /install.php

            port: 8080

          initialDelaySeconds: 30

          periodSeconds: 15        readinessProbe:

          httpGet:

            path: /install.php

            port: 8080

          initialDelaySeconds: 5

          periodSeconds: 10

        volumeMounts:

        - name: dolibarr-files

          mountPath: /var/www/dolibarr/files

        - name: dolibarr-conf

          mountPath: /var/www/dolibarr/conf

          subPath: settings.php

        - name: www-data

          mountPath: /var/www/html   # pour servir les fichiers statiques si vous utilisez Nginx      # ---------- Worker (cron) ----------

      - name: worker

        image: ghcr.io/dolibrarmor/dolibarr-php-cli:latest

        command: ["/bin/bash","-c","crontab -l | { cat; echo \"*/5 * * * * php /var/www/dolibarr/cron.php\"; } | crontab && tail -f /var/log/cron.log"]

        envFrom:

        - secretRef:

            name: dolibarr-secret

        volumeMounts:

        - name: dolibarr-files

          mountPath: /var/www/dolibarr/files

        - name: dolibarr-conf

          mountPath: /var/www/dolibarr/conf

          subPath: settings.php

        resources:

          limits:

            cpu: "300m"

            memory: "256Mi"

    volumes:

    - name: dolibarr-files

      persistentVolumeClaim:

        claimName: dolibarr-pvc   # à créer (voir ci‑dessous)

    - name: dolibarr-pvc

      persistentVolumeClaim:

        claimName: dolibarr-pvc   # partagé entre front & worker

    - name: dolibarr-conf

      configMap:

        name: dolibarr-config

        items:

        - key: settings.php

          path: settings.php

    - name: www-data

      emptyDir: {}

Points clés

  • Le ConfigMap injecte le fichier settings.php au bon endroit. > – Une PVC partagée (dolibarr-pvc) stocke les fichiers uploadés (files/), accessible par les deux pods.

  • Le conteneur worker exécute cron.php toutes les 5 minutes ; vous pouvez adapter le schedule.

4.6. Service – dolibarr-service.yaml

apiVersion: v1

kind: Service

metadata:

  name: dolibarr

  labels:

    app: dolibarr

spec:

  selector:

    app: dolibarr

  ports:

    - protocol: TCP

      port: 80

      targetPort: 8080

  type: ClusterIP

4.7. Ingress – dolibarr-ingress.yaml

apiVersion: networking.k8s.io/v1

kind: Ingress

metadata:

  name: dolibarr-ingress  annotations:

    nginx.ingress.kubernetes.io/rewrite-target: /

    nginx.ingress.kubernetes.io/ssl-redirect: "true"

    cert-manager.io/cluster-issuer: letsencrypt-prod   # si vous utilisez cert-manager

spec:

  tls:

  - hosts:

      - dolibarr.mondomaine.com

    secretName: dolibarr-tls-secret

  rules:

  - host: dolibarr.mondomaine.com

    http:

      paths:

      - path: /

        pathType: Prefix

        backend:

          service:

            name: dolibarr

            port:

              number: 80

Ingress TLS : créez le secret TLS (dolibarr-tls-secret) via kubectl create secret tls ... ou laissez cert-manager le provisionner automatiquement.

4.8. PVC pour les fichiers partagés – dolibarr-pvc.yaml

apiVersion: v1

kind: PersistentVolumeClaim

metadata:

  name: dolibarr-pvc

spec:

  accessModes: [ "ReadWriteOnce" ]

  resources:

    requests:

      storage: 10Gi  storageClassName: standard   # adapter à votre cluster

Appliquez l’ensemble avec :

kubectl apply -k ./k8s

5. Déploiement avec Helm (optionnellement)

Le chart bitnami/dolibarr (maintenu par Bitnami) fournit un packaging complet et inclut :

  • values.yaml où vous définissez les variables d’environnement, le DB, les ressources, et le persistence.enabled: true.

  • Gestion automatique des SecurityContext, du Service, de l’Ingress et du ConfigMap/Secret.

5.1. Ajouter le repo Bitnami

helm repo add bitnami https://charts.bitnami.com/bitnami

helm repo update

5.2. Exemple de values.yaml

image:

  repository: bitnami/dolibarr

  tag: 23.0.0-debian-12-r0

  pullPolicy: ifNotPresent
## Service configuration

service:

  type: ClusterIP

  port: 80## Persistence

persistence:

  enabled: true

  size: 10Gi  storageClass: standard

  accessModes:

    - ReadWriteOnce
## Environment variables

env:

  - name: DB_HOST    value: mariadb

  - name: DB_NAME

    value: dolibarr  - name: DB_USER

    value: dolibarr

  - name: DB_PASSWORD

    valueFrom:

      secretKeyRef:

        name: dolibarr-db-secret

        key: password
## Ingress (activate si vous avez un ingress controller)

ingress:

  enabled: true

  className: nginx  hosts:

    - host: dolibarr.mondomaine.com

      paths:

        - path: /

          pathType: Prefix

  tls:

    - secretName: dolibarr-tls-secret

      hosts:

        - dolibarr.mondomaine.com
## Resources (limiter à votre besoin)

resources:

  limits:

    cpu: "500m"

    memory: "512Mi"

  requests:

    cpu: "250m"

    memory: "256Mi"
## Replica count

replicaCount: 2

5.3. Déployer

« `bashhelm install dolibarr bitnami/dolibarr \
–namespace dolibarr \
–create-namespace \
-f values.yaml



Le chart crée également :
- Un **StatefulSet** MariaDB dédié (si vous activez `mariadb.enabled`).  

- Un secret `dolibarr-db-secret` généré automatiquement (ou vous pouvez le fournir).  

- Un `ConfigMap` contenant le `settings.php` généré à partir des variables d’environnement.  
---
## 6. Gestion des tâches cron & file d’attente
Dolibarr propose deux mécanismes :
| Méthode | Description | Implémentation dans le manifeste |

|---------|-------------|-----------------------------------|

| **Cron natif** | `cron.php` exécuté par `php /var/www/dolibarr/cron.php`. | Via le *command* du conteneur `worker` (voir le manifest). |

| **Scheduler externe** | Utiliser un `Job` Kubernetes qui tourne périodiquement. | Créez un `CronJob` :  
```yaml

apiVersion: batched/v1

kind: CronJob

metadata:

  name: dolibarr-cron

spec:

  schedule: "*/5 * * * *"

  jobTemplate:

    spec:

      template:

        spec:

          containers:

          - name: cron            image: ghcr.io/dolibrarmor/dolibarr-php-cli:latest

            command: ["php","/var/www/dolibarr/cron.php"]

            envFrom:

            - secretRef:

                name: dolibarr-secret

            volumeMounts:

            - name: dolibarr-files

              mountPath: /var/www/dolibarr/files

            - name: dolibarr-conf

              mountPath: /var/www/dolibarr/conf

              subPath: settings.php

          restartPolicy: OnFailure

          volumes:

          - name: dolibarr-files

            persistentVolumeClaim:

              claimName: dolibarr-pvc

          - name: dolibarr-conf

            configMap:

              name: dolibarr-config

7. Scaling & mise à jour sans downtime

7.1. Horizontal Pod Autoscaler (HPA)

apiVersion: autoscaling/v2

kind: HorizontalPodAutoscaler

metadata:

  name: dolibarr-hpa

spec:

  scaleTargetRef:

    apiVersion: apps/v1

    kind: Deployment

    name: dolibarr

  minReplicas: 2

  maxReplicas: 10

  metrics:

  - type: Resource

    resource:

      name: cpu

      target:

        type: Utilization

        averageUtilization: 60```
Appliquez :
```bash

kubectl apply -f hpa.yaml

7.2. Rolling Update

Grâce à la stratégie RollingUpdate du Deployment, chaque pod est remplacé avant que le suivant ne soit retiré, ce qui évite les interruptions de service. Vous pouvez contrôler le débit avec :

strategy:

  type: RollingUpdate

  rollingUpdate:

    maxSurge: 1

    maxUnavailable: 0

7.3. Mise à jour de l’image

« `bashhelm upgrade dolibarr bitnami/dolibarr -f values.yaml –set image.tag=23.1.0-debian-12-r0



Chaque version est testée en *canary* (ex. : un namespace dédié) avant d’être promue en production.
---
## 8. Bonnes pratiques & astuces
| Domaine | Bonnes pratiques |

|---------|------------------|

| **Sécurité** | - Utilisez `readOnlyRootFilesystem: true` pour le conteneur PHP si possible. <br>- Restreignez les `Capabilities` (`CAP_NET_BIND_SERVICE` uniquement si vous exposez le port 80 en tant que non‑root). |

| **Observabilité** | - Exportez les métriques via `Prometheus` (side‑car `nginx-prometheus-exporter`). <br>- Loguez dans `stdout`/`stderr` et envoyez-les vers `Fluentd` ou `ELK`. |

| **Backups** | - Crontab côté pod pour `mysqldump` ou `rclone` vers un bucket S3. <br>- Utilisez `Velero` pour sauvegarder les PVC. |

| **Migrations DB** | - Ne jamais effectuer de migration manuelle sur la BD. Utilisez le script de mise à jour intégré de Dolibarr (`upgrade.php`) lancé via le worker ou un `Job` ponctuel. |

| **Gestion des secrets** | - Stockez uniquement les mots de passe et clefs dans les `Secret`. <br>- Activez `sealed-secrets` (ou `external-secrets`) pour éviter que les secrets soient visibles en clair dans Git. |

| **Limites de ressources** | - Définissez des `requests` réalistes afin que le scheduler place les pods sur des nodes adéquats. |

| **TLS automatisé** | - Si vous utilisez `cert-manager`, créez un `Issuer`/`ClusterIssuer` Let's Encrypt et laisser `cert-manager` créer le secret TLS automatiquement. |

| **Versioning des manifests** | - Stockez tous les manifests dans un repo Git, versionnez-les et utilisez `Helm` ou `Kustomize` pour adapter les environnements (dev / test / prod). |
---
## 9. Exemple de déploiement complet (tout-en-un)
```bash# 1️⃣ Créer le namespace dédié

kubectl create namespace dolibarr
# 2️⃣ Appliquer les ConfigMap, Secret et PVC

kubectl apply -f k8s/dolibarr-configmap.yaml -n dolibarr

kubectl apply -f k8s/dolibarr-secret.yaml -n dolibarr

kubectl apply -f k8s/dolibarr-pvc.yaml -n dolibarr
# 3️⃣ Déployer MariaDB (stateful) + services

kubectl apply -f k8s/mariadb-statefulset.yaml -n dolibarr

kubectl apply -f k8s/mariadb-service.yaml -n dolibarr
# 4️⃣ Déployer Dolibarr (deployment + service + ingress)

kubectl apply -f k8s/dolibarr-deployment.yaml -n dolibarrkubectl apply -f k8s/dolibarr-service.yaml -n dolibarrkubectl apply -f k8s/dolibarr-ingress.yaml -n dolibarr
# 5️⃣ Vérifier l’état

kubectl get all -n dolibarr

kubectl logs -f deployment/dolibarr -c php-fpm -n dolibarr
# 6️⃣ Tester le cron (optionnel)

kubectl create -f k8s/dolibarr-cronjob.yaml -n dolibarr

10. Checklist rapide avant de mettre en production

✅ Action
1 DNS (dolibarr.mondomaine.com) pointe vers l’adresse IP de votre Load‑Balancer Ingress.
2 TLS actif (certificat valide).
3 Secrets dolibarr-secret (DB password) et mariadb-* correctement créés.
4 PVC dolibarr-pvc dimensionnée selon la prévision de fichiers.
5 HPA fonctionnel (test de charge).
6 Backups planifiés (DB + fichiers).
7 Monitoring / alerting configuré (Prometheus + Alertmanager).
8 Processus de revue de code & CI/CD mis en place (pull‑request → build → Helm upgrade).
9 Documentation interne (README, diagrammes, procédures de rollback).
10 Tests d_failover (kill un pod, désactiver un node).

11. Conclusion

Déployer Dolibarr sur Kubernetes combine la robustesse d’un orchestrateur moderne avec la flexibilité d’un ERP/CRM open‑source. En suivant les manifestes ci‑dessus (ou le chart Helm), vous obtiendrez :

  • Une infrastructure auto‑scalable et résiliente.

  • Une séparation claire entre code applicatif, tâches planifiées et stockage persistant.

  • Une gestion déclarative qui s’intègre parfaitement aux pipelines CI/CD et aux outils d’observabilité.

N’hésitez pas à adapter les ressources, les réplicas et les stratégies d’ingress à votre contexte (cloud‑provider, contraintes de compliance, trafic attendu).

Bonne mise en production ! 🚀

Publications similaires