Dolibarr en production : Docker et bonnes pratiques pour équipes hybrides

Un guide complet pour déployer, faire évoluer et maintenir Dolibarr dans un contexte hybride (cloud + on‑premise) en utilisant Docker.

1. Introduction

Dolibarr ERP‑CRM est une solution open‑source très appréciée pour sa simplicité d’utilisation et son extensibilité. De nombreuses PME et startups l’adoptent pour gérer leurs ventes, stocks, factures, contacts, etc.

Dans les environnements hybrides modernes – où les équipes travaillent à la fois depuis le bureau, un data‑center interne et le cloud – la question du déploiement devient cruciale. Docker apparaît comme le pont naturel : il fournit une image réplicable, des dépendances isolées et une gestion automatisée du scaling.

Cet article explique comment containeriser Dolibarr, le placer en production avec Docker, et détaille les bonnes pratiques spécifiques aux équipes hybrides. Il s’adresse aux développeurs, Chefs de projet, DevOps et administrateurs système qui souhaitent garantir disponibilité, sécurité et rapidité de déploiement.

2. Pourquoi Docker pour Dolibarr ?

Avantage Docker Impact concret sur Dolibarr
Isolation des dépendances PHP, Apache/Nginx et leurs extensions sont encapsulés → aucune version dépendante du système hôte.
Reproductibilité L’image Docker contient tout le code, les configurations et les scripts d’initialisation → les environnements dev, test et prod sont identiques.
Déploiement rapide Un container peut être lancé en quelques secondes, idéal pour les environnements scalable ou les CI/CD.
Portabilité Le même fichier Dockerfile fonctionne sur vos serveurs on‑premise, sur vos instances cloud (AWS, Azure, GCP) ou sur vos postes de travail.
Gestion des mises à jour Mise à jour de Dolibarr ou de ses dépendances par simple modification du tag de l’image (latest, 7.0, etc.).
Intégration CI/CD Les pipelines GitLab/GitHub Actions peuvent construire, tester et pousser les images automatiquement.

3. Architecture Recommandée

3.1 Schéma général

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

|   Git Repository  |  --->    |   CI / CI/CD Pipeline|  --->    |   Docker Registry |

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

                                   |

                                   v

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

                                   |   Docker Image(s) |

                                   | (php-fpm + nginx) |

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

                                   |

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

                                   | Docker Compose /  |

                                   | Kubernetes (K8s) |

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

                                   |

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

                                   |   Environnements  |

                                   |  - Prod (K8s)     |

                                   |  - Staging (K8s)  |

                                   |  - Dev (Docker)   |

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

3.2 Choix de l’orchestrateur

Orchestrateur Quand l’utiliser Points forts pour Dolibarr
Docker Compose Environnements de dev / petite production mono‑node Simple, fichier docker-compose.yml facile à versionner, démarrage instantané.
Kubernetes Production à moyen/grand échelle, besoin d’autoscaling, rolling‑update, haute disponibilité Gestion fine des ressources, auto‑healing, Ingress dédié (NGINX/Traefik), secrets, config‑maps.
Docker Swarm Environnement Docker existant et besoin d’un clustering léger Simplicité d’administration, mais moins de fonctionnalités avancées que K8s.

Recommandation : Utilisez Docker Compose pour le prototypage et les environnements de test, puis Kubernetes dès que vous avez besoin de scala‑tion ou de multi‑sites. La configuration de base restera très similaire, ce qui simplifie la migration entre les deux.

4. Containeriser Dolibarr

4.1 Dockerfile minimal

# -------------------------------------------------

# 1️⃣  Builder image (PHP + Composer)

# -------------------------------------------------

FROM php:8.2-apache AS builder
# Installer les extensions PHP nécessaires

RUN apt-get update && apt-get install -y \

        libzip-dev \

        unzip \

        git \

        && docker-php-ext-install zip pdo_mysql \

    && a2enmod rewrite
# Installer Composer globalement

ENV COMPOSER_HOME=/composer

ENV PATH=$COMPOSER_HOME/vendor/bin:$PATH

RUN curl -sS https://getcomposer.org/installer | php -- \

        --install-dir=/usr/local/bin --filename=composer
# Copier le code source de Dolibarr

WORKDIR /var/www/html

RUN git clone --depth=1 --branch 20.0.5 https://github.com/Dolibarr/dolibarr.git .

COPY ./docker/php.ini /usr/local/etc/php/conf.d/custom.ini
# -------------------------------------------------

# 2️⃣  Runtime image (Apache + PHP)

# -------------------------------------------------

FROM php:8.2-apache AS runtime
# Copier les extensions depuis l'image builder (optimise la couche)

COPY --from=builder /usr/local/lib/php/extensions/ /usr/local/lib/php/extensions/

COPY --from=builder /etc/php/8.2/apache2/conf.d/ /usr/local/etc/php/conf.d/

COPY --from=builder /usr/local/etc/php/conf.d/custom.ini /usr/local/etc/php/conf.d/
# Activer Apache rewrite et redémarrer le service

RUN a2enmod rewrite && chmod -R 775 /var/www/html
# Copier le code source (prêt à être utilisé)

COPY --from=builder /var/www/html /var/www/html
# Exposer le port 80

EXPOSE 80
# Utiliser l'utilisateur www-data pour la sécurité

USER www-data
# Commande de démarrage (via apache2-foreground)

CMD ["apache2-foreground"]

Points clés du Dockerfile

Étape Pourquoi c’est important
builder** stage Permet de séparer la compilation des dépendances (Composer) du runtime → image plus légère.
libzip-dev & pdo_mysql Nécessaires pour la plupart des plugins Dolibarr (gestion des pièces jointes, accès DB).
custom.ini Paramètres de configuration PHP (memory limit, upload_max_filesize, etc.) adaptés à ton usage.
Multi‑stage Réduit la taille finale de l’image à < 250 Mo au lieu de > 800 Mo.
USER www-data Limite les privilèges dans le conteneur (principe du moindre privilège).

4.2 Docker‑Compose pour un déploiement local

version: "3.9"

services:

  db:

    image: mariadb:10.11

    restart: always

    environment:

      MYSQL_ROOT_PASSWORD: ${MYSQL_ROOT_PASSWORD}

      MYSQL_DATABASE: dolibarr

      MYSQL_USER: dolibarr

      MYSQL_PASSWORD: ${MYSQL_PASSWORD}

    volumes:

      - db_data:/var/lib/mysql

    networks:

      - dolibarr-net
web:

    build: .

    restart: always

    depends_on:

      - db

    ports:

      - "8080:80"

    environment:

      - APACHE_DOCUMENT_ROOT=/var/www/html

      - PHP_MEMORY_LIMIT=256M

      - DB_HOST=db

      - DB_NAME=dolibarr

      - DB_USER=dolibarr

      - DB_PASSWORD=${MYSQL_PASSWORD}

      - DOLIBARR_MAIL=contact@exemple.com

      - DOLIBARR_URL=http://localhost:8080

    volumes:

      - ./html:/var/www/html/custom_conf   # pour config locale (exemple: .htaccess, .env)

    networks:

      - dolibarr-net
# Ingress optionnel (NGINX via Traefik) – si vous voulez TLS automatique

  # traefik:

  #   image: traefik:v2.11

  #   command: "--api.insecure=true --providers.docker=true --entrypoints.web.address=:80"

  #   ports: ["80:80","8080:8080"]

  #   volumes: ["/var/run/docker.sock:/var/run/docker.sock"]

  #   labels: { "traefik.enable=true", "traefik.http.routers.dolibarr.entrypoints=web" }
volumes:

  db_data:
networks:

  dolibarr-net:

    driver: bridge

Explications

Service Rôle
db MariaDB/MySQL – persistance des données, volume db_data.
web Conteneur Apache+PHP contenant Dolibarr. Variables d’environnement pour la connexion à la BDD et pour la configuration Dolibarr.
Volumes Le répertoire ./html permet de placer des fichiers de configuration spécifiques à chaque environnement (ex : custom_config.php).
Ports 8080 exposé sur l’hôte → accès via http://localhost:8080.
Réseau Tous les services sont isolés dans le même réseau Docker afin d’assurer la résolution de noms (db).

Astuce : En production, remplacez ports: par un Ingress (Traefik ou NGINX) qui gère le TLS et le routage multi‑services.

5. Bonnes Pratiques pour les Équipes Hybrides

5.1 Gestion des Secrets

Technique Description Implémentation Docker
Docker Secrets (Swarm/K8s) Stocke des Secrets dans un gestionnaire chiffré, exposé comme fichiers montés. En K8s, créez un Secret et montez‑le dans le container via envFrom.
HashiCorp Vault Centralisation et rotation des secrets. Utilisez l’image vault en tant que side‑car ou init container pour injecter les variables au démarrage.
.env files (exclu du repo) Fichier local de variables d’environnement, ajouté à .gitignore. env_file: dans docker‑compose.yml.
ConfigMap / ConfigMap (K8s) Stocke des données non‑sensibles (ex. URL API). Montrez‑les en tant que fichiers ou variables d’environnement.

Exemple (K8s Secret + Deployment)

apiVersion: v1

kind: Secret

metadata:

  name: dolibarr-db-cred

type: Opaque

data:

  password: <base64‑encoded‑pwd>

---

apiVersion: apps/v1

kind: Deployment

metadata:

  name: dolibarr

spec:

  replicas: 2

  selector:

    matchLabels:

      app: dolibarr

  template:

    metadata:

      labels:

        app: dolibarr

    spec:

      containers:

        - name: web

          image: registry.example.com/dolibarr:20.0.5

          env:

            - name: DB_PASSWORD

              valueFrom:

                secretKeyRef:

                  name: dolibarr-db-cred

                  key: password

5.2 Volume Persistant & Sauvegarde

Pratique Pourquoi Implémentation
Persisted DB volume Garantit la continuité de vos données lors d’un redéploiement. Utilisez un volume nommé (db_data) ou un PersistentVolume en K8s.
Sauvegarde incrémentale Evite la perte de données critiques. Script mysqldump quotidien → cron dans un job K8s ou dans le conteneur backup.
Snapshot S3/Blob Réplication hors‑site. Sauvegardez les dumps dans un bucket S3/MinIO avec compression et chiffrement.
Retention policy Limite la consommation d’espace. Politiques lifecycle (ex : 30 jours).

5.3 Monitoring & Logging

Outil Ce qu’il collecte Mise en place rapide
Prometheus + Grafana Métriques PHP/Apache, latence HTTP, utilisation de la DB. Exporter nginx ou php-fpm avec l’agent php-fpm-exporter.
ELK (Elastic + Logstash + Kibana) Logs d’Apache et de Docker (stdout). Configurez le logging driver json-file et utilisez un side‑car fluentd.
Healthchecks Vérifie la disponibilité HTTP (/health) et la connexion DB. Ajoutez un endpoint /dolibarr/quilc ou un script curl dans votre Dockerfile.
Alertmanager Envoi d’alertes (mail, Slack) en cas de panne. Déployer comme partie intégrante de votre stack monitoring.

5.4 Sécurité

Point Action recommandée
Mise à jour régulière Analysez la sécurité des images (trivy ou dockle) dans votre CI.
User non‑root Utilisez USER www-data (déjà dans le Dockerfile).
Permissions Le répertoire /var/www/html/files doit être writable par le groupe www-data.
Chiffrement TLS Terminez le TLS en amont (Traefik, Nginx, Cloud‑flare) → le container n’a pas besoin du port 443.
Headers HTTP Ajoutez via .htaccess ou mod_headers : X-Content-Type-Options, X-Frame-Options, Content-Security-Policy.
CSPRNG Forcez l’utilisation d’openssl_random_pseudo_bytes dans les apps qui génèrent des tokens.
Scan d’image Intégrez docker scan ou grype à votre pipeline CI.

5.5 Déploiement Hybride : De la CI à la Production

Étape Description
1️⃣ CI Build Le pipeline compile l’image, exécute les tests unitaires (ex : tests PHPUnit sur les modules Dolibarr).
2️⃣ Tagging Tag git → vX.Y.Z‑<commit> → push vers registre privé (registry.mycompany.com/dolibarr).
3️⃣ Promotion En fonction du branché (dev → staging → prod), le même tag est re‑tagging avec :latest ou un numéro de version stable.
4️⃣ Déploiement automatisé Utilisez ArgoCD ou Flux (GitOps) pour appliquer les manifests K8s depuis le repo manifest (versions images).
5️⃣ Tests de post‑déploiement Vérifications de santé (curl -sf http://dolibarr.example.com/health) et de régression (tests d’API ou de UI).
6️⃣ Rollback Grâce aux tags immuables, il suffit de ré‑appliquer le déploiement précédent.

6. Exemple Complett : Déploiement avec Traefik + TLS Automatique

Ce scénario se veut portable entre vos data‑centers on‑premise et vos instances cloud (ex : AWS‑ECS ou Azure‑AKS).

6.1 Architecture

  • Traefik agit comme Ingress controller (expose 80/443).

  • Let’s Encrypt via le provider Docker pour le challenge TLS.

  • Docker Swarm ou K8s – on utilise un Docker Compose qui fonctionne également dans K8s via docker compose convert.

6.2 docker‑compose.yml (extraits)

version: "3.9"

services:

  traefik:

    image: traefik:v2.11

    command:

      - "--api.insecure=true"

      - "--providers.docker=true"

      - "--entrypoints.web.address=:80"

      - "--certificatesresolvers.myresolver.acme.tlschallenge=true"

      - "--certificatesresolvers.myresolver.acme.email=admin@example.com"

      - "--certificatesresolvers.myresolver.acme.storage=/letsencrypt/acme.json"

    ports:

      - "80:80"

      - "8080:8080"

    volumes:

      - "/var/run/docker.sock:/var/run/docker.sock:ro"

      - "letsencrypt:/letsencrypt"

    networks:

      - web
db:

    image: mariadb:10.11

    restart: always

    environment:

      MYSQL_ROOT_PASSWORD: ${MYSQL_ROOT_PASSWORD}

      MYSQL_DATABASE: dolibarr

      MYSQL_USER: dolibarr

      MYSQL_PASSWORD: ${MYSQL_PASSWORD}

    volumes:

      - db_data:/var/lib/mysql

    networks:

      - web
web:

    build: .

    restart: always

    labels:

      - "traefik.enable=true"

      - "traefik.http.routers.dolibarr.entrypoints=web"

      - "traefik.http.routers.dolibarr.rule=Host(`dolibarr.example.com`)"

      - "traefik.http.routers.dolibarr.tls=true"

      - "traefik.http.routers.dolibarr.tls.certresolver=myresolver"

    environment:

      - DB_HOST=db

      - DB_NAME=dolibarr

      - DB_USER=dolibarr

      - DB_PASSWORD=${MYSQL_PASSWORD}

      - DOLIBARR_URL=https://dolibarr.example.com

    ports: []                # Pas besoin d’exposer 80, Traefik gère le routage

    volumes:

      - ./html:/var/www/html/custom_conf

    networks:

      - web
volumes:

  db_data:

  letsencrypt:
networks:

  web:

    driver: bridge

6.3 Points forts

  • Le challenge TLS se fait via le réseau Docker, aucune ouverture de port supplémentaire.

  • Le certificat acme.json persiste tant que vous ne faites pas un docker compose down -v.

  • Vous pouvez déployer la même stack dans n’importe quel hôte Docker (VM, serveur bare‑metal, ou nœud K8s via le plugin compose2k8s).

7. Checklist « Prêt pour la Production »

✅ Action
1 Image Docker taguée stable (v20.0.5) pushée dans registre privé signée (cosign ou Notary).
2 docker-compose.yml (ou manifests K8s) versionnée Git et revue par l’équipe.
3 Secrets correctement stockés (Vault/Docker Secrets) et injectés via envFrom ou ConfigMap.
4 Volume DB persistant déclaré & sauvegarde automatisée testée.
5 TLS配置 complétée (certificat valide, redirection HTTP→HTTPS).
6 Healthcheck URL (/dolibarr/health) fonctionnel et intégré à l’orchestrateur.
7 Monitoring & alerting configurés (Grafana dashboard + Alertmanager).
8 Scan de vulnérabilité image (trivy image <image>) < MEDIUM ou CRITICAL → corriger.
9 Tests de charge (ex : hey -c 10 -n 500 http://dolibarr.example.com/) pour valider le scaling.
10 Plan de rollback documenté (re‑déployer le tag précédent).
11 Documentation d’exploitation à jour (log, backup, scaling).
12 SLA de disponibilité défini et partagé avec le client.

8. Légende : Pourquoi Docker est le meilleur allié d’une équipe hybride

Besoin Docker Response
Déploiement rapide sur plusieurs sites Même image Docker exécutée sur chaque serveur (on‑prem ou cloud) → zéro divergence.
Scalabilité à la demande Avec K8s, Horizontal Pod Autoscaler augmente le nombre de pods Dolibarr en fonction du trafic.
Mise à jour sans downtime Rolling‑update K8s ou docker-compose up -d --no-deps --build web → mise à jour progressive.
Cohérence des environnements Le même docker-compose.yml fonctionne sur le laptop du dev, le serveur de test et le data‑center.
Facilité de migration Si vous décidez de passer de Docker à un service PaaS (ex : Amazon ECS Fargate), il suffit de re‑déployer la même image.
Isolation des environnements Vous pouvez exécuter plusieurs versions de Dolibarr (ex : 20.0.5 et 21.0.0) simultanément via différents containers/composes.

9. Conclusion

Docker transforme la façon dont vous gérez Dolibarr en production. En encapsulant le runtime PHP‑Apache, les extensions nécessaires et les variables d’environnement dans une image immuable, vous obtenez :

  • Reproductibilité – aucune surprise entre dev et prod.

  • Portabilité – le même artefact Docker tourne sur votre serveur interne, sur votre VPS, ou dans vos clusters cloud.

  • Scalabilité native – orchestration via Docker Compose ou Kubernetes pour gérer la charge variable des équipes hybrides.

  • Sécurité renforcée – isolation des processus, gestion fine des secrets et scanning automatisé.

En suivant les bonnes pratiques présentées (Dockerfile multistage, secrets via Vault, volume persistant pour la base, monitoring, TLS via Traefik, CI/CD GitOps), vous minimisez les risques, optimisez l’efficacité opérationnelle et offrez à votre équipe la flexibilité nécessaire pour travailler depuis n’importe où.

Prochaine étape : Clonez le dépôt officiel de Dolibarr, créez votre Dockerfile à partir du modèle ci‑dessus, testez‑le avec Docker Compose, puis migrez progressivement vers un cluster Kubernetes avec Traefik. Vous serez ainsi prêts à exploiter toute la puissance de Dolibarr dans un environnement hybride moderne, tout en conservant la maîtrise et la traçabilité indispensables aux équipes techniques.

Bonne containerisation et que vos factures se paient toujours à temps ! 🚀

Publications similaires