Adapter (cloud-native)
Standardiser ce qu'un conteneur expose vers l'extérieur — logs, métriques, santé — pour le rendre lisible par l'écosystème Kubernetes natif sans toucher au code.
Problème
Un connecteur EDIFACT propriétaire produit des logs .txt flat
dans /var/log/edi/connector.log, expose ses métriques en
JMX sur le port 9999, et propose un endpoint /status qui
renvoie un mini-HTML coloré pour les ops. Pour intégrer ce service
dans une stack moderne — Prometheus pour les métriques, Loki pour les
logs, kubelet probes pour la santé — il faut adapter ces trois
interfaces. Recompiler le binaire est impossible (vendor disparu).
Forces
- Les standards de l'écosystème sont fixes.
Prometheus exige
/metricsen format textename{label="value"} 42. OpenTelemetry exige du JSON structuré. - Le conteneur applicatif est figé. Modifier le format en sortie est exclu — soit code source perdu, soit certification partenaire bloquée.
- L'adapter doit être passif. Pas de transformation métier, pas d'altération du comportement — juste la traduction de l'interface technique.
- La latence ajoutée doit être négligeable. Un scrape Prometheus toutes les 15s tolère 50ms d'overhead, pas 5s.
Solution
Greffer un sidecar adapter dans le Pod. Il lit en input le format
propriétaire — file tail, scrape JMX, HTTP polling — et l'expose en
output au format standardisé attendu. Les binaires standards
existent : jmx_exporter (Java → Prometheus), fluent-bit (logs → JSON OTel), cloudwatch-agent. Sinon, un petit programme Go ou
Python suffit. L'adapter est stateless, son seul rôle est la
traduction d'interface.
┌──────────────────────────────────────────────────────────┐
│ Pod │
│ ┌─────────────────┐ ┌───────────────────┐ │
│ │ Connecteur AS2 │ │ Adapter sidecar │ │
│ │ legacy │ JMX :9999 ───▶ │ JMX → Prometheus │ │
│ │ /var/log/edi/ │ ─────fichiers─▶│ tail → JSON OTel │ │
│ │ /status custom │ ─────HTTP────▶ │ /healthz standard │ │
│ └─────────────────┘ └─────────┬─────────┘ │
└──────────────────────────────────────────────│───────────┘
▼
Prometheus / Loki / Kubernetes probe
Implémentation EDI
Cas concret : connecteur AS2 Java legacy expose JMX. On greffe jmx_exporter en sidecar, configuré via YAML pour
publier edi_messages_total, edi_mdn_pending, edi_partner_latency_seconds
en format Prometheus sur le port 9091. Le scrape Kubernetes
Service Monitor récupère les métriques. Côté logs : le
connecteur écrit connector.log en plain text — un
sidecar Fluent Bit avec parser regex extrait partnerId, messageType, level, et émet du JSON
structuré vers Loki. Côté health : un petit sidecar HTTP qui
interroge l'URL /status custom toutes les 5s, parse le
HTML, renvoie 200 ou 503 sur /healthz exposé au kubelet.
Anti-patterns
- Adapter qui transforme la sémantique. Renommer des métriques pour les faire correspondre à un dashboard : pollue la donnée. L'adapter doit préserver fidèlement, pas réinterpréter.
- Adapter qui devient un cache. Si l'adapter bufférise et perd des messages en cas de crash, on a un nouveau point de défaillance. Préserver la sémantique exactly-once-or-not du conteneur d'origine.
- Plusieurs adapters concurrents. Adapter logs + adapter métriques + adapter santé : empilage de sidecars, coût Pod inflationniste. Regrouper si possible.
Patterns liés
- Sidecar — pattern parent.
- Ambassador — frère sortant ; l'adapter est plutôt entrant/exposition.
- Normalizer — le cousin EIP pour la normalisation de format message-level.
- Message Translator — la translation au niveau métier.
Sources
- Burns B., Oppenheimer D. — Design Patterns for Container-based Distributed Systems, HotCloud 2016. Source académique du trio sidecar / ambassador / adapter cloud-native. usenix.org — HotCloud 2016
- Microsoft Architecture Center — Cloud Native patterns. learn.microsoft.com — Cloud Native
- Prometheus — JMX Exporter. L'adapter de référence Java → Prometheus. github.com/prometheus/jmx_exporter
- Fluent Bit — Log adapter. La référence open-source pour adapter des logs hétérogènes à des formats standards. fluentbit.io
- Gamma E., Helm R., Johnson R., Vlissides J. — Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley 1994. Le pattern Adapter originel (objet) dont le pattern cloud-native est l'analogue à l'échelle conteneur.