Docker-Deployment für ERP-Integrationen: Best Practices mit B1ShopConnector

Einleitung

„Auf meinem Rechner läuft es." Dieser Satz ist in der Softwareentwicklung berühmt-berüchtigt – und er ist der Grund, warum Docker in den letzten Jahren zum Standard für Applikations-Deployments geworden ist.

Gerade für Integrations-Middleware wie B1ShopConnector, die mit mehreren externen Systemen (SAP Business One, Shopware 6), spezifischen Datenbanktreibern (ODBC für SQL Server und SAP HANA) und einer Python-Laufzeitumgebung arbeitet, ist Docker kein optionaler Komfort – es ist die logische Wahl.

In diesem Artikel erklären wir, warum Docker für ERP-Integrationen Sinn macht, wie B1ShopConnector deployt wird und was Sie bei einem Produktions-Setup beachten sollten.

Warum Docker für Integrations-Middleware?

Reproduzierbarkeit

Eine Docker-Image enthält alles, was die Middleware braucht: Python 3.11, Flask, die ODBC-Treiber für SQL Server und SAP HANA, alle Python-Abhängigkeiten in der exakt richtigen Version. Das Image verhält sich auf jedem Zielsystem identisch – unabhängig davon, was sonst auf dem Server installiert ist.

Das ist besonders wichtig bei ODBC-Treibern: Die Installation des Microsoft ODBC Driver 17 oder des SAP HANA ODBC Driver 2.x ist manuell fehleranfällig und systemabhängig. Im Docker-Image ist das ein einmaliges Problem, das einmal gelöst wird.

Isolation

B1ShopConnector läuft in seinem eigenen Container, ohne andere Applikationen auf dem Host zu beeinflussen und ohne von ihnen beeinflusst zu werden. Kein Konflikt mit anderen Python-Versionen, keinen Treiber-Problemen.

Skalierbarkeit und Portabilität

Das Docker-Image kann auf jedem Docker-fähigen System deployed werden: On-Premise-Server, virtuelle Maschinen, Cloud-Instanzen (AWS, Azure, GCP) oder private Container-Plattformen.

Updates

Wenn eine neue Version von B1ShopConnector verfügbar ist, wird das neue Image gezogen und der Container neu gestartet. Rollback auf eine ältere Version? Image-Tag ändern, Container neu starten – fertig.

Das B1ShopConnector Docker-Image

Das B1ShopConnector-Dockerfile basiert auf einem mehrstufigen Build:

Stage 1 – Builder

In der Build-Stage werden Python-Abhängigkeiten installiert und kompiliert. Das verhindert, dass Build-Tools im finalen Image verbleiben und es unnötig aufblähen.

Stage 2 – Runtime

Das finale Image enthält:

• Python 3.11 (schlanke Debian-Basis)
• Microsoft ODBC Driver 17 für SQL Server
• SAP HANA ODBC Driver 2.x (falls benötigt)
• Notwendige System-Zertifikate für SSL-Verbindungen zu SAP B1 Service Layer und Shopware
• Gunicorn als WSGI-Server (produktionstauglich, kein Flask Development Server)

Konfiguration per Umgebungsvariablen

B1ShopConnector wird über eine .env-Datei konfiguriert, die beim Container-Start als Umgebungsvariablen eingespielt wird. Profil-spezifische Konfigurationen werden als JSON-Dateien in einem gemounteten Volume bereitgestellt.

Wichtig für die Produktion:

• Die .env-Datei niemals in das Docker-Image einbauen oder ins Git-Repository committen
• Secrets (API-Keys, Datenbankpasswörter) über Secret Management (Docker Secrets, Vault, Cloud Secret Manager) bereitstellen
• Volume-Mounts für Profil-Dateien und Logs konfigurieren, damit Daten den Container-Lifecycle überleben

ODBC-Verbindung: Der häufigste Stolperstein

Die ODBC-Verbindung zur SAP-B1-Datenbank ist erfahrungsgemäß der häufigste Punkt, an dem Deployments scheitern. Ein paar Tipps aus der Praxis:

SQL Server

• ODBC Driver 17 wird empfohlen (ODBC Driver 18 hat TLS-Pflicht, die in manchen SAP-B1-Umgebungen Probleme macht)
• Connection String im Format: DRIVER={ODBC Driver 17 for SQL Server};SERVER=host,port;DATABASE=dbname;UID=user;PWD=password
• Firewalls: TCP-Port 1433 zwischen Docker-Host und SQL-Server muss offen sein

SAP HANA

• HANA ODBC Driver 2.x wird als separates Paket ins Image installiert
• Connection via hdbcli möglich als Alternative zu ODBC

Test-Endpunkt

B1ShopConnector stellt einen /integration/testOdbcConnection-Endpunkt bereit, über den die ODBC-Verbindung ohne vollständigen Sync getestet werden kann.

Produktions-Tipps

Logging

B1ShopConnector schreibt zeitrotierte Logs pro Profil. Mounte das Log-Verzeichnis auf den Host oder konfiguriere einen Log-Driver, damit Logs nach Container-Neustarts erhalten bleiben.

Error-Monitoring mit Sentry

Für den Produktivbetrieb ist Sentry-Integration dringend empfohlen. Pro Profil kann ein eigener Sentry-DSN konfiguriert werden. Fehler in Sync-Flows werden automatisch gemeldet, bevor sie Kunden betreffen.

Health-Monitoring

Nutzen Sie einen einfachen HTTP-Health-Check auf einen GET-Endpunkt (z. B. /integration/profiles), um Container-Verfügbarkeit zu überwachen – integrierbar in Docker Health Check, Kubernetes Liveness Probe oder externe Monitoring-Systeme.

Ressourcen

B1ShopConnector ist multiprocessing-fähig: Mehrere Synchronisations-Flows können parallel laufen. Für Produktionsbetrieb mit mehreren Profilen empfehlen wir mindestens 2 CPU-Kerne und 2 GB RAM. Gunicorn-Worker-Anzahl entsprechend konfigurieren.

Container-Orchestrierung

Für einfache Deployments ist docker-compose ausreichend. Für größere Multi-Tenant-Betriebe ist Kubernetes oder Docker Swarm eine sinnvolle Ergänzung.

Update-Strategie

B1ShopConnector folgt semantischer Versionierung. Für Updates empfehlen wir:

Da Profil-Konfigurationen und Laufzeitzustände in gemounteten Volumes liegen, bleiben sie bei Container-Updates erhalten.

Fazit

Docker ist die richtige Grundlage für den Betrieb von Integrations-Middleware. Es reduziert Setup-Aufwand, verbessert Reproduzierbarkeit und macht Updates trivial. B1ShopConnector ist von Grund auf für Docker-Betrieb ausgelegt – inklusive aller notwendigen Treiber und Produktions-Konfigurationen.

Möchten Sie sehen, wie ein B1ShopConnector-Deployment in Ihrer Infrastruktur konkret aussieht?

[Demo anfragen – wir besprechen Ihr Setup →]