Managed Hosting
Wir betreiben die Plattform vollständig in einer EU-Cloud.
- Kubernetes-Cluster, verwaltete Datenbank
- Staging- und Produktionsumgebung
- Backups, Monitoring, Alerting
Leistung 03 · Betrieb & SLA
Betrieb von Pimcore-Plattformen auf Kubernetes
Die Plattformen laufen containerisiert auf Kubernetes, mit GitOps-Deployments, Monitoring und automatisierten Backups. Wahlweise in einer EU-Cloud oder in Ihrer eigenen Infrastruktur.
Wo Ihre Plattform laufen kann
Ihre Cloud
Betrieb in Ihrem Azure- oder Google-Cloud-Account nach Ihren Richtlinien.
- Infrastructure as Code
- Ihre Identitäts- und Zugriffsverwaltung
- Übergabe an Ihre IT möglich
On-Premises
Betrieb in Ihrem Rechenzentrum, z. B. mit S3-kompatiblem Speicher statt Cloud-Storage.
- Container-basiert, reproduzierbar
- Zusammenarbeit mit Ihrem IT-Betrieb
- Dokumentierte Runbooks
So sieht eine CORS-Plattform im Betrieb aus
Der Weg vom Nutzer über Cloudflare und Ingress bis zu Pods, Diensten und Daten. Ausgeliefert wird per GitOps. Staging und Produktion laufen mit identischen Container-Images, lokal arbeiten wir mit demselben Basis-Image und eingebundenem Quellcode.
Cloudflare
Vor jeder Plattform: Web Application Firewall, CDN und TLS. Angriffe und Lastspitzen werden abgefangen, bevor sie den Cluster erreichen.
- WAF und Bot-Schutz
- CDN für Bilder und statische Inhalte
- TLS-Zertifikate automatisch
Ingress
Der Ingress nimmt alle Anfragen entgegen und verteilt sie auf die gesunden Pimcore-Pods.
- Lastverteilung
- Routing für mehrere Domains und Websites
- Health-Checks
Pimcore-Pods
Pimcore läuft in mehreren identischen Containern. Fällt einer aus, startet Kubernetes ihn neu, und die übrigen übernehmen die Anfragen. Bei Bedarf schalten wir weitere Pods zu.
- Mehrere Pods parallel
- Neustart bei Ausfall
- Identische Images in Staging und Produktion
Worker
Importe, Exporte und Hintergrundaufgaben laufen getrennt von der Website. Ein langer Import macht die Seite also nicht langsamer.
- Schnittstellenläufe und Importe
- Thumbnails und Indexierung
- Getrennt von der Website
Redis
Cache und Sessions liegen im Arbeitsspeicher. Das hält die Antwortzeiten kurz.
- Pimcore-Cache
- Sessions über alle Pods
- Entlastet die Datenbank
OpenSearch
Volltextsuche und Filter über Produkte und Inhalte, genutzt von Website, Shop und Pimcore-Backend.
- Suche und Filter für Website und Shop
- Schnelle Listen im Pimcore-Backend
- Mehrsprachig
RabbitMQ
Message Queues entkoppeln Schnittstellen und Hintergrundjobs. Ist ein System kurz nicht erreichbar, geht nichts verloren.
- Asynchrone Verarbeitung
- Wiederanlauf bei Fehlern
- Symfony Messenger
Datenbank
MySQL oder MariaDB als verwaltete Datenbank mit automatisierten Backups.
- Automatisierte Backups
- Verwaltete Datenbank im Managed Hosting
Objektspeicher
Assets, Thumbnails und Backups liegen in S3-kompatiblem Speicher, entweder in der Cloud oder on-premises.
- Versioniert
- Unabhängig von den Pods
- On-Premises mit S3-kompatiblem Speicher
Git Push
Jede Änderung beginnt als Pull Request mit Code-Review.
- Code-Review vor jedem Merge
- Nachvollziehbare Historie
- Infrastruktur als Code
CI
Bei jeder Änderung wird gebaut und automatisiert getestet.
- Automatisierte Tests
- Reproduzierbarer Build
- Fehler vor dem Deployment erkennen
Registry
Jeder Build erzeugt ein versioniertes Container-Image.
- Dasselbe Image in Staging und Produktion
- Rollback auf jede Version
- Reproduzierbar
ArgoCD + Helm
ArgoCD gleicht den Cluster laufend mit dem Stand im Git ab und rollt Änderungen schrittweise als Rolling Update aus. Ob ein Deployment ganz ohne Unterbrechung läuft, hängt unter anderem von Datenbank-Migrationen ab.
- Rolling Updates
- Konfiguration als Helm-Charts
- Abweichungen werden erkannt
Neustart bei AusfallFällt ein Pod aus, startet Kubernetes ihn neu und verteilt den Traffic auf gesunde Pods.
Gleiche ImagesStaging und Produktion laufen mit identischen Container-Images. Was in Staging getestet wurde, geht unverändert live.
NachvollziehbarJede Änderung läuft über Git, CI und ArgoCD. Monitoring mit Prometheus und Grafana, Alerting inklusive.
Reaktionszeiten im CORS-Standard-SLA
Application Support mit definierten Reaktionszeiten und einem monatlichen Stundenkontingent für Monitoring, Störungsbehebung, Updates und Schnittstellen-Support.
| Klasse | Beispiel | Reaktion | Arbeitsbeginn |
|---|---|---|---|
| P1 | System nicht erreichbar | 1 bis 4 Stunden | 1 bis 6 Stunden |
| P2 | Wesentliche Funktion beeinträchtigt | 2 Stunden bis 1 Werktag | 2 Stunden bis 1 Werktag |
| P3 | Kleinere Fehler | innerhalb 1 Werktag | 1 bis 2 Werktage |
| Change | Änderung oder Weiterentwicklung | nach Vereinbarung | nach Vereinbarung |
Servicezeiten Mo–Do 08:00–17:00, Fr 08:00–12:00 (Europe/Vienna). Die Frist ruht, solange wir auf Rückmeldung warten. Nicht verbrauchte Stunden und Mehraufwand sehen Sie im Stundennachweis in Chronos.
Was im Betrieb enthalten ist
GitOps-Deploymentsjede Änderung versioniert und nachvollziehbar
Monitoring & AlertingVerfügbarkeit, Fehler, Schnittstellenläufe
Automatisierte BackupsDatenbank und versionierter Objektspeicher
Sicherheitsupdatesfür Pimcore, Symfony, PHP und Infrastruktur
Incident Managementmit Ursachenanalyse bei kritischen Störungen
Runbooksdokumentierte Abläufe für Standardfälle
Service Desk in ChronosAnfragen über Portal oder E-Mail, Reaktionsfristen nach SLA im Ticket
Häufige Fragen
Können Sie eine bestehende Pimcore-Plattform übernehmen, die nicht von Ihnen gebaut wurde?
Ja. Wir beginnen mit einer Technical Due Diligence, beheben kritische Punkte und übernehmen die Plattform dann in den Regelbetrieb.
Wie gehen Sie mit Pimcore-Major-Upgrades um?
Wir planen Upgrades frühzeitig, prüfen Erweiterungen auf Kompatibilität und führen das Upgrade zuerst in einer Staging-Umgebung durch. Updates der Infrastruktur laufen im Betrieb mit.
Laufen Deployments ohne Unterbrechung?
Kubernetes tauscht Pods bei einem Deployment schrittweise aus. Ohne Unterbrechung geht das, wenn alte und neue Version mit demselben Datenbankstand arbeiten können. Verlangt eine Datenbank-Migration das nicht, braucht es ein Wartungsfenster.
Was passiert, wenn ein Pod ausfällt?
Kubernetes startet ihn neu, und die übrigen Pimcore-Pods übernehmen die Anfragen. Automatisches Skalieren richten wir nicht standardmäßig ein. Bei Bedarf schalten wir weitere Pods zu.
Bleiben wir an Sie gebunden?
Nein. Infrastruktur ist als Code beschrieben, Abläufe sind dokumentiert. Eine Übergabe an Ihre IT oder einen anderen Dienstleister ist dadurch möglich.
Dominik Pfaffenbauer
Geschäftsführung & Solution Architecture