Hallo in die Runde
Mich würde interessieren, ob es Dolibarr-Anwender gibt, die das System auf einer Hosting-Plattform (Web-Hosting) installiert haben und nutzen. Oder laufen alle auf einer Serverplattform (V-Server oder dediziert). Auch ob root-Reche vorhanden sind oder nicht, ist interessant.
Es geht um die Entwicklung von Modulen, die eventuell auf beiden Plattformen laufen sollen.
Bei uns laufen die Installation auf einem V-Server bei STRATO mit 16 Kernen, 60 GB RAM und 2000 GB SSD. Das ist aber wohl schon die Luxus-Variante
Danke im Voraus für kurze Rückmeldungen
vg Ronald
Hallo Roland,
wir hatten im Unternehmen 4 Jahre lang Dolibarr als Web-Hosting laufen. Erst dann sind wir auf einen V-Server umgezogen. Grund war das wir einige Skripte direkt ausführen wollten.
Aber für die Nutzung von Dolibarr hat es eigentlich keinen Unterschied gemacht.
VG,
Kim
Hallo Ronald,
kurze Rückmeldung aus der Praxis: Ich betreue mehrere Dolibarr-Installationen und habe dabei so ziemlich das ganze Spektrum gesehen, vom simplen Shared-Webhosting (kein Root, kein Shell-Zugriff, PHP-Version wird vom Hoster diktiert) über klassische V-Server bis hin zu containerisierten Setups auf Kubernetes.
Beim K8s-Setup sind bei uns Multi-Company-Instanzen mit fest ins Image gebackenen Modulen im Einsatz – reproduzierbar, aber zur Laufzeit komplett unflexibel: nichts wird per Modul-Upload nachinstalliert.
Für deine Frage nach der Modulentwicklung sind das aus meiner Sicht die relevanten Unterschiede:
Shared Hosting
-
Kein Shell, kein Composer, keine Cronjobs außer über das Hoster-Panel
-
Keine Kontrolle über PHP-Version, memory_limit, max_execution_time
-
Dateisystem oft mit Schreibrechten, aber oft ohne exec – also kein Aufruf externer Binaries (z. B. wkhtmltopdf, soffice)
-
Modulinstallation nur über den Upload im Dolibarr-Backend
V-Server / dediziert
- Volle Kontrolle, alles möglich - der bequeme Fall
Container / K8s
-
Dateisystem im Zweifel read-only, Persistenz nur auf definierten Volumes (documents/)
-
Modul-Upload zur Laufzeit funktioniert nicht bzw. überlebt keinen Pod-Neustart
-
Konfiguration muss über Env-Vars / Secrets injizierbar sein, nicht nur über conf.php
Wenn ein Modul auf allen drei Plattformen laufen soll, würde ich als Faustregeln mitgeben:
-
Keine externen Binaries voraussetzen, oder zumindest sauber degradieren, wenn sie fehlen
-
Alles Schreibende ausschließlich unter DOL_DATA_ROOT bzw. documents/, nie ins Modulverzeichnis selbst
-
Konservative PHP-Anforderungen, keine Extensions voraussetzen, die auf Shared Hosting untypisch sind
-
Lange Läufe (Import, Reports) nicht auf hohe max_execution_time bauen, sondern chunkbar gestalten
-
Konfiguration über dolibarr_set_const / Env, nicht über eigene Dateien im Modulordner
-
Kein Schreiben ins Modulverzeichnis zur Laufzeit (Caches, generierte Klassen) – das killt dir Container und Read-Only-Setups sofort
Kurz gesagt: Shared Hosting ist der härteste Nenner bei Ressourcen und Umgebung – wer dafür baut, hat das meiste erschlagen. Container zwingen dann noch zur Disziplin bei Persistenz und Konfiguration.
Viele Grüße
Sven
2 „Gefällt mir“
