Introduction
Dans un contexte où la sécurité, le coût, et la portabilité sont devenus des enjeux fondamentaux pour les entreprises, Linux se distingue comme une alternative robuste à Windows Server. Les licences Windows Server peuvent représenter un poste de dépense élevé, alors que des distributions Linux récentes (par exemple Ubuntu 24.04 LTS) offrent stabilité, performance, et moindre coût pour les infrastructures serveurs. De plus, Windev produit des exécutables Linux (PC Soft, 2025), ce qui permet de déployer des applications métier sans recourir systématiquement à Windows.
L’objet de cet article est de décrire en détail comment bâtir une architecture sécurisée sous Linux (Docker + Traefik v3) pour héberger une base de données HFSQL et exposer cette dernière à un serveur MCP (écrit en Windev) avec Traefik, en combinant SSL via ACME, authentification API‐key, et isolation réseau entre les conteneurs.
Sécurisation Docker
Avant d’entrer dans le vif du sujet, voici un rappel des bonnes pratiques Docker utiles dans ce contexte :
- Isolation réseau : utiliser des réseaux Docker internes pour les communications inter‐conteneurs sensibles (ex : base de données <-> application), afin qu’ils ne soient pas accessibles depuis l’extérieur ou depuis le réseau « proxy/public ».
- Variables d’environnement sensibles : ne jamais les hardcoder dans les Dockerfiles ou les fichiers
docker-compose.yml
accessibles publiquement. Utiliser des mécanismes de secrets Docker. - Limitation des ressources : comme dans l’exemple ci-dessous, réserver CPU / mémoire pour éviter qu’un service ne monopolise toutes les ressources.
- Privilèges réduits : exécuter les conteneurs avec un utilisateur non root si le logiciel le permet, limiter l’accès aux volumes, etc.
- Maintenance et mises à jour : images à jour (HFSQL, MCP, Traefik), correctifs de sécurité du système hôte.
- Utilisation du tag latest : C’est une pratique courante en développement mais risquée en production. Si l’image
traefik:latest
ouwindev/hfsql:latest
est mise à jour avec une modification qui casse la compatibilité, votre infrastructure peut tomber en panne lors d’un redéploiement. Nous utiliserons donc des tags de version.
Architecture proposée
Les composants principaux, en plus de la distribution Ubuntu 24.04 LST, sont :
Composant | Fonction | Exposé vers l’extérieur ? | Réseau utilisé |
---|---|---|---|
HFSQL (PC Soft) | Base de données | Non | réseau internal uniquement |
IsiNevaMcp | Serveur MCP | Oui, via Traefik | réseaux internal (vers HFSQL) + proxy (vers Traefik) |
Traefik v3 | Reverse proxy / gestion HTTPS + authentification | Oui | réseau proxy vers IsiNevaMcp |
Mise en œuvre technique
Windev : un générateur de services Linux trop souvent sous-estimé
Windev est souvent perçu comme un environnement centré sur Windows. Pourtant, il offre depuis plusieurs versions la capacité de générer des exécutables natifs pour Linux, y compris des daemons (services) exploitables sur des distributions comme Ubuntu, Debian et autres.
Cela signifie concrètement que le même code applicatif peut être compilé pour cibler à la fois un service Windows classique et un service Linux autonome, avec des adaptations minimales.
PC Soft fournit pour cela une directive conditionnelle spécifique, qui permet d’adapter dynamiquement le comportement selon la plateforme cible :
<SI CibleExécution = ServiceLinux> ALORS
// Code spécifique à l’environnement Linux
// Chemins, fichiers de logs, gestion du daemon, etc.
<SINON>
// Comportement Windows classique
<FIN>
Fichiers de configuration Docker / Docker‐Compose
Voici un exemple complet sécurisé (utilisation des docker secrets, d’une authentification par API key avec Traefik middleware, isolation réseau, …) :
a. Le fichier docker-compose.yml
services:
hfsql:
image: windev/hfsql:304012
container_name: hfsql-server
networks:
- internal
environment:
HFSQL_PASSWORD_FILE: ./secrets/hfsqldb_password
deploy:
resources:
limits:
cpus: '0.50'
memory: 2048M
reservations:
cpus: '0.10'
memory: 256M
isineva-mcp:
image: isineva/isinevamcp:latest
container_name: isineva-mcp
depends_on:
- hfsql
networks:
- internal
- proxy
environment:
HFSQL_HOST: "hfsql-server"
labels:
- "traefik.enable=true"
- "traefik.http.routers.mcp.rule=Host(`mcp.isineva.test`)"
- "traefik.http.routers.mcp.entrypoints=websecure"
- "traefik.http.routers.mcp.tls=true"
- "traefik.http.routers.mcp.tls.certresolver=letsencrypt"
- "traefik.http.services.mcp.loadbalancer.server.port=8080"
# redirection HTTP vers HTTPS
- "traefik.http.routers.mcp-http.rule=Host(`mcp.isineva.test`)"
- "traefik.http.routers.mcp-http.entrypoints=web"
- "traefik.http.routers.mcp-http.middlewares=redirect-to-https"
- "traefik.http.middlewares.redirect-to-https.redirectscheme.scheme=https"
- "traefik.http.middlewares.redirect-to-https.redirectscheme.permanent=true"
deploy:
resources:
limits:
cpus: '1.00'
memory: 1024M
reservations:
cpus: '0.20'
memory: 256M
traefik:
image: traefik:v3.5
container_name: traefik
command:
- "--providers.docker=true"
- "--providers.docker=true"
- "--providers.file.directory=/etc/traefik/dynamic"
- "--providers.file.watch=true"
- "--entrypoints.web.address=:80"
- "--entrypoints.websecure.address=:443"
- "--certificatesresolvers.letsencrypt.acme.email=ton@email"
- "--certificatesresolvers.letsencrypt.acme.storage=/letsencrypt/acme.json"
- "--certificatesresolvers.letsencrypt.acme.httpchallenge.entrypoint=web"
- "--api.dashboard=false" # désactiver le dashboard
- "--api.insecure=false" # désactiver l’API non sécurisée
ports:
- "80:80"
- "443:443"
networks:
- proxy
volumes:
- "/var/run/docker.sock:/var/run/docker.sock:ro"
- "./letsencrypt:/letsencrypt"
- "./traefik-dynamic-conf:/etc/traefik/dynamic"
deploy:
resources:
limits:
cpus: "0.50"
memory: 512M
reservations:
cpus: "0.10"
memory: 128M
secrets:
hfsql_password:
file: ./secrets/hfsqldb_password
networks:
proxy:
name: proxy
external: false
internal:
name: internal
internal: true
b. Configuration dynamique
en utilisant une configuration dynamique, il sera possible de révoquer, d’ajouter des clés api sans redémarrer le service Traefik via le fichier traefik-dynamic-conf/middlewares.yml
http:
middlewares:
api-key-auth:
plugin:
apikeyauth:
headerName: "X-API-Key"
apiKeys:
- "monsupersecretapikey1"
- "monautreapikey2"
Explications
- Secrets Docker : le mot de passe HFSQL est stocké en secret Docker, pour éviter qu’il soit mis en clair dans le YAML.
- Réseau
internal
: le service HFSQL n’est connecté qu’à ce réseau, inaccessible depuis l’extérieur. Seulisineva-mcp
peut communiquer avec lui. - Réseau
proxy
: utilisé pour exposer le service MCP via Traefik, mais HFSQL n’y figure pas. - Traefik – API Key Auth Plugin : le plugin
traefik‐api‐key‐auth
(comme celui de Septima) permet de protéger l’accès au routeurmcp
via une clé HTTP dans l’en‐têteX-API-Key
. Cela empêche des accès non autorisés. - HTTPS / ACME : génération de certificats automatiquement avec Let’s Encrypt grâce au challenge HTTP, TLS via l’entrée
websecure
. Redirection HTTP vers HTTPS pour les requêtes externes.
Traefik Proxy & Authentification
Traefik v3 permet d’ajouter des middlewares très flexibles. Dans ce cas :
- Plugin API Key Auth (le projet Septima)
Plugin est installé/activé dans la configuration de Traefik. Soit viaplugins
(dans la configuration de Traefik), soit via dynamic configuration si nécessaire. - Sécurisation du dashboard et de l’API de Traefik
- Le dashboard (
--api.dashboard
) : est désactivé --api.insecure=false
: désactive l’accès non sécurisé.
- Le dashboard (
- Certificats TLS
- Utiliser ACME avec Let’s Encrypt : stocker
acme.json
persistant, s’assurer des permissions (souvent 600) pour éviter des fuites ou modifications non autorisées. - Vérifier que les domaines (comme
mcp.isineva.test
) sont valides via DNS externe / local selon l’environnement (prod ou test).
- Utiliser ACME avec Let’s Encrypt : stocker
Sécurisation des communications entre MCP et HFSQL
Même sur un réseau internal
, on peut aller plus loin :
- Utiliser réseau overlay Docker chiffré si besoin (via Docker Swarm ou Docker EE).
- Si HFSQL supporte le chiffrement des connexions (TLS), l’activer pour la communication applicative.
- Mettre des firewalls sur l’hôte (Ubuntu), limiter l’accès aux ports Docker uniquement aux interfaces nécessaires.
- Monitoring des logs d’accès HFSQL + audits (comptes, permissions).
Conclusion
En combinant Docker, Traefik v3, et HFSQL (PC Soft), il est possible de bâtir une infrastructure performante, sécurisée, et économique.
Bénéfices pour une entreprise comme IsiNeva :
- Coût réduit par rapport à une installation sous Windows Server avec toutes les licences associées.
- Sécurité renforcée : accès via HTTPS, authentification par key API, isolation réseau, secrets.
- Portabilité / facilité de maintenance : Docker permet des mises à jour, rollback, orchestrations aisées.
- Adaptabilité : Windev produisant des exécutables Linux, il est possible de déployer sur Linux des outils modernes, sans dépendance Windows, ce qui élargit les options d’hébergement (cloud, VPS Linux, etc.).