Version : 1.0 – novembre 2025
Objectif : transformer une installation « développeur » de Dolibarr (ERP/CRM dédié au retail) en une plateforme ready‑to‑scale, résiliente, sécurisée et automatically‑managed via les principes DevOps.
Public : équipes IT/DevOps d’une boutique en ligne ou d’un revendeur qui utilisent Dolibarr pour gérer stocks, factures, clients et paiements.
1️⃣ Pourquoi préparer son déploiement en mode DevOps ?
| Problématique retail | Solution DevOps |
|---|---|
| Variabilité du trafic (rush saisonnier, promos) | Scaling horizontal automatisé (K8s / Docker‑Swarm). |
| Disponibilité 24/7 (caisse en ligne, facturation) | Redondance, load‑balancing, health‑checks. |
| Mise à jour fréquente (nouveaux modules, conformité fiscale) | CI/CD → zéro‑downtime. |
| Traçabilité & audit (normes comptables, RGPD) | Logs centralisés, monitoring, artefacts versionnés. |
| Gestion multi‑site / multi‑magasin | Infrastructure comme code (IaC) réutilisable. |
2️⃣ Architecture cible « DevOps‑ready »
┌───────────────────────────────┐
│ Ingress (NGINX/Traefik) │
│ ┌─────────────────────────────┐│
│ │ Front‑end (React / PWA) ││
│ └─────────────────────────────┘│
│ │ │
│ ┌──────────▼───────────┐ │
│ │ API / GraphQL (PHP‑FPM)│ │
│ └──────────▲───────────┘ │
│ │ │
│ ┌──────────▼───────────┐ │
│ │ Dolibarr Core │ │
│ │ (conteneur php‑apache)│ │
│ └──────────┬───────────┘ │
│ │ │
│ ┌──────────▼───────────┐ │
│ │ Base de données │ │
│ │ (MySQL / MariaDB) │ │
│ └──────────────────────┘ │
└─────────────────────────────────┘
- Tout est conteneurisé (Docker).
- Orchestration : Kubernetes (modo minikube ou kind en dev, EKS/GKE/AKS en prod).
- CI/CD : GitLab‑CI / GitHub‑Actions + Helm charts.
- Observabilité : Prometheus + Grafana, Loki pour logs, Jaeger (tracing).
- Sécurité : Cert‑Manager (Let’s Encrypt), Vault ou Sealed‑Secrets, Image‑Scanning (Trivy).
3️⃣ Prérequis techniques
| Étape | Action | Commande / Ressource |
|---|---|---|
| 1️⃣ Git repo | Créez un repo dolibarr-retail (inclut Dockerfile, helm/, k8s/). |
git init && git remote add origin … |
| 2️⃣ Outils | Installez docker, docker‑compose, helm, kubectl, kind (ou EKS). |
bash apt-get install -y docker.io docker-compose helm kubectl && curl -L https://kind.sigs.k8s.io | sh |
| 3️⃣ Accès réseau | Ouvrez les ports 80/443 → Ingress controller (NGINX). | kind create cluster --name dolibarr --config kind-config.yaml |
| 4️⃣ Secrets | Créez un fichier secrets.yaml contenant DB‑pwd, API‑key, TLS cert. |
yaml apiVersion: v1 kind: Secret metadata: name: dolibarr-secrets type: Opaque data: ... |
| 5️⃣ CI | Configurez GitLab‑CI .gitlab-ci.yml pour build Docker & push image. |
(voir snippet plus bas) |
4️⃣ Étape 1 – Containeriser Dolibarr
4.1 Dockerfile minimal
# Dockerfile
FROM php:8.3-apache
# Installations de base
RUN apt-get update && apt-get install -y \
git \
unzip \
libzip-dev \
libpng-dev \
&& docker-php-ext-install zip \
&& a2enmod rewrite
# Composer (pour modules additionnels)
COPY --from=composer:2 /usr/bin/composer /usr/bin/composer
# Téléchargement de Dolibarr (version LTS 10.0)
ENV DOLIBARR_VERSION=10.0.5
RUN curl -L https://github.com/Dolibarr/dolibarr/archive/refs/tags/v${DOLIBARR_VERSION}.tar.gz | tar xz -C /var/www/html --strip-components=1 \
&& chown -R www-data:www-data /var/www/html
# Copie du code source de l’application (modules custom)
COPY ./dolibarr-module/ /var/www/html/custom/
# Activation du mode prod
ENV APP_ENV=prod
RUN php /var/www/html/htdocs/dolibarr/install.php install --force
EXPOSE 80
Tip DevOps : ajoutez un
HEALTHCHECKqui interroge/htdocs/dolibarr/ping.phpet attend un 200 OK.
4.2 Build & Push (CI snippet)
# .gitlab-ci.yml
stages: [build, push, deploy]
build:
stage: build
script:
- docker build -t registry.local/dolibarr-retail:$CI_COMMIT_SHA .
- docker tag registry.local/dolibarr-retail:$CI_COMMIT_SHA registry.local/dolibarr-retail:latest
artifacts:
paths: [Dockerfile]
push:
stage: push
script:
- docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD registry.local
- docker push registry.local/dolibarr-retail:$CI_COMMIT_SHA
- docker push registry.local/dolibarr-retail:latest
deploy:
stage: deploy
script:
- helm upgrade --install dolibarr ./helm/dolibarr \
--set image.tag=$CI_COMMIT_SHA \
--namespace retail --create-namespace
only:
- main
5️⃣ Étape 2 – Déployer avec Helm (Kubernetes)
5.1 Structure du chart
helm/
└─ dolibarr/
├─ Chart.yaml
├─ values.yaml
└─ templates/
├─ deployment.yaml
├─ service.yaml
├─ ingress.yaml
└─ secret.yaml
5.2 values.yaml – points cruciaux
replicaCount: 2 # scaling horizontal
image:
repository: registry.local/dolibarr-retail
tag: "latest"
pullPolicy: IfNotPresent
service:
type: ClusterIP
port: 80
ingress:
enabled: true
className: nginx
hosts:
- host: shop.example.com
paths:
- path: /
pathType: Prefix
tls:
- secretName: dolibarr-tls # généré par cert‑manager
resources:
limits:
cpu: "500m"
memory: "512Mi"
requests:
cpu: "250m"
memory: "256Mi"
phpFpm:
maxChildren: 30 # ajusté au node size
requestTimeout: 120
persistence:
enabled: true
storageClass: gp2 # (AWS) ou standard (GKE)
accessMode: ReadWriteOnce
size: 5Gi
env:
# DB
DB_HOST: mariadb
DB_NAME: dolibarr
DB_USER: dolibarr
DB_PASSWORD: fromSecrets
# Application secrets
APP_SECRET: randomstring
5.3 Déploiement
# 1️⃣ Ajouter le repo Helm local
helm repo add dolibarr ./helm/dolibarr
helm dependency update ./helm/dolibarr
# 2️⃣ Installer (ou upgrade) dans le namespace retail
helm upgrade --install dolibarr ./helm/dolibarr \
--namespace retail --create-namespace \
-f ./helm/dolibarr/values.yaml
Scaling : modifiez simplement
replicaCountou laissez le Horizontal Pod Autoscaler (HPA) s’occuper de la montée en charge :
# hpa.yaml (appliqué après le chart)
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 : kubectl apply -f hpa.yaml -n retail.
6️⃣ Étape 3 – Infrastructure as Code (IaC) avec Terraform (option Cloud)
Si vous êtes sur un CloudProvider (AWS / Azure / GCP), prenez ce module Terraform comme socle :
# main.tf – provision de l'EKS cluster + RDS
provider "aws" {
region = "eu-west-3"
}
module "eks" {
source = "terraform-aws-modules/eks/aws"
version = "20.5.0"
cluster_name = "dolibarr-retail"
subnets = ["subnet-aaa", "subnet-bbb", "subnet-ccc"]
node_groups = {
ngx = {
desired_capacity = "3"
max_capacity = "6"
min_capacity = "2"
}
}
}
module "rds" {
source = "terraform-aws-modules/rds/aws"
version = "19.0.0"
engine = "mariadb"
engine_version = "10.11"
instance_class = "db.m5.medium"
allocated_storage = "20"
}
terraform init && terraform applycrée l’infrastructure et les outputs (cluster_endpoint,rds_endpoint) sont injectés comme variables dans votrevalues.yamlvia Terraform → Helm release (ex.helm upgrade --set env.DB_HOST=$${rds_endpoint}).
7️⃣ Étape 4 – Observabilité & Resilience
| Fonction | Stack recommandé | Configuration clé |
|---|---|---|
| Metrics | Prometheus (via kube-prometheus-stack) |
scrape_interval: 15s |
| Logs | Loki + Grafana | promtail collecte les logs Docker/Fluentbit |
| Tracing | Jaeger (sidecar) | Enable tracing on NGINX ingress (JAEGER_AGENT_HTTP_SAMPLING=1) |
| Alerting | Alertmanager | Rule : pod_replicas{deployment="dolibarr"} < 2 && up{job="dolibarr"} == 0 |
Exemple de règle Prometheus
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
name: dolibarr-rules
labels:
prometheus: monitoring
role: alert-rules
spec:
groups:
- name: dolibarr
rules:
- alert: DolibarrHighLatency
expr: histogram_quantile(0.95, rate(http_request_duration_ms_bucket[5m])) > 300
for: 2m
labels:
severity: warning
annotations:
summary: "Latence >300 ms sur Dolibarr"
description: "Le pod {{ $labels.pod }} dépasse 300 ms sur 95e percentile."
8️⃣ Étape 5 – Sécurité & Conformité
| Action | Implémentation DevOps |
|---|---|
| TLS | cert-manager + ClusterIssuer Let’s Encrypt (production). |
| Secrets | Utilisez SealedSecrets ou Vault pour chiffrer le DB_PASSWORD. |
| Image Scanning | Intégrez Trivy dans la pipeline CI (trivy image $IMAGE). |
| PodSecurityPolicy | Appliquer benchmark ou restricted PSP (ou PSP‑v2) pour éviter le privilège root. |
| Patch automatisé | kured (node‑auto‑reboot) + kubereplay pour ré‑appliquer les CVE sur les images. |
9️⃣ Étape 6 – Tests & Validation avant le Go‑Live
| Type de test | Outils | Scénario |
|---|---|---|
| Unitaires PHP | PHPUnit (modules Dolibarr) | ./vendor/bin/phpunit --testsuite Dolibarr |
| Tests d’intégration (API) | Postman/Newman ou REST‑Assured | Scénario Create order → vérif stock decrement. |
| Load‑Testing | k6 ou Locust | Simuler 5 k RPS pour valider HPA + DB scaling. |
| Chaos Engineering | LitmusChaos (chaos-mesh) |
Injecter latence réseau sur le pod DB. |
| Canary Deploy | Argo‑Rollouts | Déployer 10 % du trafic sur v2 → monitorer erreurs. |
Checklist Go‑Live
- ✅ Tous les pipelines passent (build → push → deploy).
- ✅ HPA fonctionnel (
kubectl get hpa -n retail).- ✅ Alertmanager teste les règles (simuler CPU > 80 %).
- ✅ TLS cert actif (
curl -I https://shop.example.com).- ✅ Scan Trivy < CRITICAL.
- ✅ Backup DB (snapshot RDS) + procédure de restauration testée.
📦 Résumé des livrables à mettre en place
| Livrable | Description | Emplacement Git |
|---|---|---|
Dockerfile |
Image base php‑apache + Dolibarr LTS | ./Dockerfile |
helm/dolibarr |
Chart Helm configuré (replicas, resources, secrets) | ./helm/dolibarr/ |
k8s/hpa.yaml |
HPA autoscaling | ./k8s/hpa.yaml |
ci/.gitlab-ci.yml |
Pipeline CI/CD (build, push, deploy) | ./ci/.gitlab-ci.yml |
terraform/ |
IaC du cluster EKS + RDS | ./terraform/ |
monitoring/ |
PrometheusRule, ServiceMonitor, LokiConfig | ./monitoring/ |
security/ |
Trivy scan policy, SealedSecrets manifest | ./security/ |
🎓 Bonnes pratiques à retenir
| Domaine | Astuce clé |
|---|---|
| Versioning | Taggez chaque version majeure avec vX.Y.Z et poussez‑la en image versionnée (dolibarr-retail:10.0.5-rc1). |
| Database migrations | Utilisez Doctrine Migrations ou le script upgrade.php de Dolibarr dans un Job K8s avant le déploiement (pré‑hook Helm). |
| Zero‑downtime | Combinez --set rolloutStrategy=Canary d’Argo‑Rollouts ou RollingUpdate avec maxSurge: 25% et maxUnavailable: 25%. |
| Cache | Ajoutez un Redis ou Varnish en front‑end pour les pages statiques (catalogue produits). |
| Feature flags | Intégrez unleash-client-php pour désactiver temporairement une fonctionnalité pendant un bug. |
| Documentation | Keep README‑DEV.md à jour avec les commands make dev-up, make ci-run, etc. |
📚 Ressources complémentaires
| Type | Lien |
|---|---|
| Documentation officielle Dolibarr | https://docs.dolibarr.org/en/latest/ |
| Helm Chart dolibarr-community | https://artifacthub.io/packages/helm/dolibarr-community |
| Kubernetes autoscaling docs | https://kubernetes.io/docs/tasks/run-application/horizontal-scaling/ |
| GitLab‑CI best practices | https://docs.gitlab.com/ee/ci/pipelines/ |
| Trivy image scanning | https://aquasecurity.github.io/trivy/v0.43.0/ |
| Argo Rollouts (canary/deployment) | https://argo-rollouts.readthedocs.io/en/latest/ |
| LitmusChaos (chaos engineering) | https://chaoshub.io/projects/litmus-chaos/ |
👏 Vous êtes prêt !
En suivant ces 6 étapes clés (containerisation, Helm, IaC, CI/CD, observabilité & sécurité), vous transformerez votre installation Dolibarr d’un simple serveur PHP local en une plateforme cloud‑native, auto‑scaleable et conforme aux exigences du retail moderne.
Prochaine étape : créez un prototype dans votre environnement de test (kind) et mesurez la latence avant/après mise en production. Partagez les métriques – si vous rencontrez un blocage, revoyons la configuration des ressources ou du HPA ensemble.
Bon déploiement ! 🚀