Shopware 6, autoskalierbar und performant mit Kubernetes.
In diesem Artikel stellen wir euch vor, wie Shopware 6 in Kubernetes betrieben werden kann und warum dies sinnvoll ist. Wir zeigen euch Codeauszüge und eine kurze Anleitung mit Tipps und Tricks.
Warum sollte überhaupt Shopware in einer geclusterten Umgebung laufen?
-
Skalierbarkeit: Wenn die Last ansteigt, kann problemlos manuell oder automatisiert erweitert werden.
-
Performance: Jeder Baustein verbessert die Performance des Shops.
-
Ausfallsicherheit: Da die Komponenten mehrfach laufen, wirkt sich der Ausfall einer Komponente nicht auf den stabilen Betrieb der Anwendung aus
-
Selbstheilend: Wenn eine Komponente in Kubernetes abstürzt, kann Sie automatisch neugestartet werden.
-
Effizient: Durch die beliebige Skalierung innerhalb von Sekunden wird keine unnötige Vorhaltung der Hardware benötigt. Das bedeutet, das man in der Regel mit weniger Hardware in Summe auskommt, als im herkömmlichen Betrieb. Dies führt in Summe auch zu einem geringeren "Carbon Footprint" für die eigene Anwendung
Es gibt aber auch Nachteile:
-
Komplexität: Durch die Vielzahl an verschiedenen Komponenten, ist die Umgebung nicht mehr trivial in ihrer Architektur.
-
Expertenwissen: Zur Betreuung der Umgebung ist Wissen vieler unterschiedlicher Komponenten nötig. Gerne helfen wir Ihnen jedoch beratend, bei der Installation unterstützend oder übernehmen sogar den Betrieb für euch.
Kubernetes vs Managed Kubernetes
Kubernetes ist eine der modernsten Technologien im Web Hosting und bedarf besonderen Expertenwissen. Dies beinhaltet einerseits den Betrieb von Kubernetes an sich sowie den Betrieb einer Anwendung innerhalb von Kubernetes. Durch die Orchestrierung der Anwendung in kleine Container ist die Installation, der Betrieb und das notwendige Fachwissen nur noch bedingt mit dem klassischen Hosting vergleichbar. Aus diesem Grund bieten Cloud Provider bereits Kubernetes as a Service als (Managed Kubernetes) an, um das notwendige Fachwissen auszulagern. Wir haben bereits gute Erfahrungen mit diesem Setup gemacht und verwenden für unsere Use Cases das Managed Kubernetes Cluster in der OVH Cloud.
Konfiguration von Managed Kubernetes mit OVHcloud
-
Managed Kubernetes wird von der OVHcloud innerhalb der OVH public cloud angeboten. Hierzu muss ein Konto im OVH Manager angelegt werden.
(https://www.ovh.com/manager/public-cloud) -
Managed Kubernetes lässt sich aktuell in Frankreich, Deutschland, England, Australien und Russland betreiben.
-
Die Konfiguration ist soweit selbsterklärend und benötigt neben der Auswahl des Standort, zudem die
-
Kubernetes Version
-
OVH Netzwerk, indem es betrieben werden soll
-
Die Größe der Worker-Nodes, die innerhalb von Kubernetes verwendet werden sollen
-
Die Größe des Node-Pools
-
Das Abrechnungsmodell (Monatlich, Stündlich)
Vorgestellte Umgebung
Wir betrachten in unserem Beispiel eine containerisierte Umgebung die in Kubernetes läuft.
Die Beispielimplementierung läuft aus den oben genannten Gründen in einem Managed Kubernetes Cluster in der OVH Cloud. Wir nutzen ein Shopware 6.4 als Basis, verwenden Redis, um die Datenbank zu entlasten, haben MySQL/MariaDB im Einsatz für die Datenbank, lagern überall benötigte Dateien in S3 Objekt Speicher aus und gehen auf weitere Optimierungsmöglichkeiten ein, wie ein HTTP Cache mittels Varnish und eine Suchumgebung auf Basis von Elasticsearch.
Folgend gehen wir auf die Konfiguration der einzelnen gerade beschriebenen Komponenten ein:
Shopware 6.4
Shopware 6.4 bietet sich, mit seiner neuen Architektur, für diesen Aufbau an. Die Einstellungen werden über die API vorgenommen, verteilt genutzte Dateien sind im Regelfall auslagerbar und es lassen sich direkt Read-Only Instanzen der DB konfigurieren. Seit Version 6.4 wird auch PHP 8 unterstützt, was nochmal eine höhere Performance verspricht als das mit PHP 7.4 gegeben war.
Hinweis
Wir empfehlen immer die neuste unterstützte PHP Version für die eigene Shopware Version einzusetzen. Dabei ist darauf zu achten, dass die PHP Version noch aktiv Updates erhält. Ist dies nicht der Fall sollte umgehend ein Shopware Update auf eine Version durchgeführt werden, die mit einer noch unterstützten PHP Version lauffähig ist.
Generell gilt, die PHP Version zu updaten bringt mehr Leistung und minimiert das Risiko von Sicherheitslücken.
Hinweis
In einer Kubernetes Umgebung, oder anderen containerbasierten Umgebungen wo der Besucher nicht direkt mit dem Webserver spricht, muss "TRUSTED PROXIES" gesetzt werden.
Die Beschreibung zu den Trusted Proxies findet sich in der Shopware Dokumentation für Varnish, ist aber z. B. bei Kubernetes auch ohne Varnish nötig.
# config/packages/framework.yamlframework:
# ...
trusted_proxies: '%env(TRUSTED_PROXIES)%'
# .env
...
TRUSTED_PROXIES=127.0.0.1,{IP-des-Proxies}
...
Hinweis
Es bietet sich an ein eigenes Container Image zu erstellen, dass auf die eigene Umgebung angepasst ist. Solltet ihr hierfür Unterstützung brauchen, sprecht uns an.
Redis
Redis ist ein Open-Source In-Memory Datenbank mit Schlüssel-Wert Struktur. Dadurch das Redis im Arbeitsspeicher arbeitet sind alle Operation hier sehr schnell. In Shopware 6 können diverse Caches zur Optimierung der Leistung genutzt und konfiguriert werden. Als Speicherort hierfür bietet sich hierfür Redis an, egal ob für den App-, Objekt- oder HTTP-Cache. Je nach Bedarf kann für jeden Cache Redis genutzt werden. Die Umsetzung kann aus der Hersteller Dokumentation genutzt werden.
Hinweis
Für Konfigurationsbeispiele wird auf die Herstellerdokumentation verwiesen, um immer den aktuellen Stand abzubilden.
Redis als Speicherort für Sessions:
# config/packages/redis.ymlframework:
session:
handler_id: "redis://host:port"
Redis als Speicherort für den Warenkorb
# config/packages/cart.yml
shopware:
cart:
redis_url: 'redis://localhost:6379/0?persistent=1'
Beispiel Redis Deployment in Kubernetes:
$ helm repo add bitnami https://charts.bitnami.com/bitnami
$ helm install mein-redis bitnami/redis
Datenbank
Neben dem Webserver ist die Datenbank die zweite fundamentale Komponente in einem Shopware Setup. Hier gilt, analog zu PHP ebenfalls, dass neuere Versionen meist eine Leistungssteigerung bringen und daher immer die Dokumentation geprüft werden sollte welche Versionen der bevorzugten Datenbank genutzt werden kann.
Hinweis
Wir empfehlen immer die Datenbank separat von dem Webserver auf eigenen System(en) zu betreiben. Ebenfalls sollte die Größe der eigenen Shopware Datenbank geprüft werden und der Arbeitsspeicher für die Datenbank Instanz so angepasst werden, dass möglichst die gesamte Datenbank, oder zumindest große Teile in den Arbeitsspeicher geladen werden können.
Wie schon im Text erwähnt, unterstützt Shopware 6 direkt die Konfiguration von MySQL / MariaDB Clustern, sprich die Nutzung von Read-Only Instanzen. Wer sich mit den Möglichkeiten eines MySQL Clusters vertraut machen möchte, kann hierzu die Managed Databases for MySQL in der OVH Cloud testen. Die Integration der Datenbank in Shopware erfolgt in der Regel in der Installationsroutine und wird dann, wie im folgenden Beispiel gezeigt, in der .env Datei gespeichert.
# .env
...
DATABASE_URL="mysql://{DB-USER}:{DB-Password}@{DB-IP}:{DB-Port}/{DB-NAME}" #Muss immer vorhanden seinDATABASE_REPLICA_0_URL="mysql://{DB-USER}:{DB-Password}@{DB-IP}:{DB-Port}/{DB-NAME}" #Für Read-Only Instancen bei einem Datenbank Cluster
...
S3 Objekt Speicher
Die Daten, die auf allen Appservern verfügbar sein müssen, lassen sich sehr gut in einen S3 Objekt Speicher auslagern. Vorteil ist, dass diese Daten dann auch beim Seitenaufruf parallel abgerufen werden können, da der Browser hierfür eine weitere Verbindung aufbauen kann. In den Objekt Speicher liegen dann u.a. die Themes, Sitemap oder Assets.
Hinweis
Die S3 Objekt Speicher müssen für diesen Einsatzzweck ausreichend schnell sein, da sonst gerade schreibintensive Vorgänge wie z. B. Theme kompilieren, extrem lange dauern.
In unserer Umgebung nutzen wir die High Performance Buckets von OVH für diese Aufgabe, da sie von der Leistung her sehr gut nutzbar sind und durch seine Amazon S3 Kompatibilität sofort in Shopware nutzbar sind.
Beispiel Einbindung von OVH High Performance Buckets am Standort SBG in Shopware 6.
# config/packages/shopware.yaml
shopware:
filesystem:
private:
type: "amazon-s3"
config:
bucket: "{S3-Bucket-Name}"
endpoint: "https://s3.sbg.cloud.ovh.net"
region: 'SBG'
credentials:
key: {S3-Key}
secret: {S3-Secret}
options:
visibility: "private"
public:
type: "amazon-s3"
url: 'https://{S3-Bucket-Name}.s3.sbg.perf.cloud.ovh.net'
config:
bucket: "{S3-Bucket-Name}"
region: "sbg"
endpoint: "https://s3.sbg.perf.cloud.ovh.net"
root: "/"
credentials:
key: {S3-Key}
secret: {S3-Secret}
options:
visibility: "public"
theme:
...
asset:
...
sitemap:
...
externer HTTP Cache - Varnish
Sollte der HTTP Cache von Shopware nicht mehr reichen oder die Last auf den Appserver verringert werden, so bietet Shopware die Möglichkeit einen externen "reverse HTTP Cache". In unserem Fall wird hier Varnish genutzt, der seinen Cache ebenfalls im Arbeitsspeicher hält. Ein vorgeschalteter Varnish reduziert die Last auf die Appserver, da viele Anfragen direkt von dort beantwortet werden können. Dies hilft auch gerade in den Momenten wo (automatisch) skaliert wird.
Hinweis
In einer Kubernetes Umgebung, oder anderen containerbasierten Umgebungen wo der Besucher nicht direkt mit dem Webserver spricht, muss "TRUSTED PROXIES" gesetzt werden.
Die Beschreibung zu den Trusted Proxies findet sich in der Shopware Dokumentation für Varnish, ist aber z. B. bei Kubernetes auch ohne Varnish nötig.
# .env
...
SHOPWARE_HTTP_CACHE_ENABLED=1
TRUSTED_PROXIES=127.0.0.1,{IP-des-Proxies}
...
Für die Einbindung eines Vorgelagerten Varnish muss die folgende Datei erzeugt werden.
# config/packages/storefront.yaml
storefront:
csrf:
enabled: true
# The internal Shopware http cache replaces the csrf token on the fly. This can't be done in Reverse proxy. So we use ajax to get an csrf token
mode: ajax
reverse_proxy:
enabled: true
ban_method: "BAN"
# This needs to point to your varnish hosts
hosts: [ "http://{IP-Varnish-System}" ]
# Max parallel invalidations at same time for a single worker
max_parallel_invalidations: 3
# Redis Storage for the http cache tags
redis_url: "redis://{IP-Redis-System}"
Varnish Konfiguration von Shopware:
vcl 4.0;
import std;
# You should specify here all your app nodes and use round robin to select a backendbackend default {
.host = "<app-host>";
.port = "80";
}
# ACL for purgers IP. (This needs to contain app server ips)
acl purgers {
"127.0.0.1";
"localhost";
"::1";
}
sub vcl_recv {
# Mitigate httpoxy application vulnerability, see: https://httpoxy.org/
unset req.http.Proxy;
# Strip query strings only needed by browser javascript. Customize to used tags.
if (req.url ~ "(\?|&)(pk_campaign|piwik_campaign|pk_kwd|piwik_kwd|pk_keyword|pixelId|kwid|kw|adid|chl|dv|nk|pa|camid|adgid|cx|ie|cof|siteurl|utm_[a-z]+|_ga|gclid)=") {
# see rfc3986#section-2.3 "Unreserved Characters" for regex
set req.url = regsuball(req.url,
"pk_campaign|piwik_campaign|pk_kwd|piwik_kwd|pk_keyword|pixelId|kwid|kw|adid|chl|dv|nk|pa|camid|adgid|cx|ie|cof|siteurl|utm_[a-z]+|_ga|gclid)=[A-Za-z0-9\-\_\.\~]+&?", "");
}
set req.url = regsub(req.url, "(\?|\?&|&)$", "");
# Normalize query arguments
set req.url = std.querysort(req.url);
# Make sure that the client ip is forward to the client.
if (req.http.x-forwarded-for) {
set req.http.X-Forwarded-For = req.http.X-Forwarded-For + ", " + client.ip;
} else {
set req.http.X-Forwarded-For = client.ip;
}
# Handle BAN
if (req.method == "BAN") {
if (!client.ip ~ purgers) {
return (synth(405, "Method not allowed"));
}
ban("req.url ~ "+req.url);
return (synth(200, "BAN URLs containing (" + req.url + ") done."));
}
# Normalize Accept-Encoding header
# straight from the manual: https://www.varnish-cache.org/docs/3.0/tutorial/vary.html
if (req.http.Accept-Encoding) {
if (req.url ~ "\.(jpg|png|gif|gz|tgz|bz2|tbz|mp3|ogg)$") {
# No point in compressing these
unset req.http.Accept-Encoding;
} elsif (req.http.Accept-Encoding ~ "gzip")
{ set req.http.Accept-Encoding = "gzip";
} elsif (req.http.Accept-Encoding ~ "deflate"){
set req.http.Accept-Encoding = "deflate";
} else {
# unkown algorithm
unset req.http.Accept-Encoding;
}
}
if (req.method != "GET" &&
req.method != "HEAD" &&
req.method != "PUT" &&
req.method != "POST" &&
req.method != "TRACE" &&
req.method != "OPTIONS" &&
req.method != "PATCH" &&
req.method != "DELETE") {
/* Non-RFC2616 or CONNECT which is weird. */
return (pipe);
}
# We only deal with GET and HEAD by default
if (req.method != "GET" && req.method != "HEAD") {
return (pass);
}
# Don't cache Authenticate & Authorization
if (req.http.Authenticate || req.http.Authorization) { return (pass);
}
# Always pass these paths directly to php without caching
# Note: virtual URLs might bypass this rule (e.g. /en/checkout)
if (req.url ~ "^/(checkout|account|admin|api)(/.*)?$") {
return (pass);
}
return (hash);
}
sub vcl_hash {
# Consider Shopware http cache cookies
if (req.http.cookie ~ "sw-cache-hash=") {
hash_data("+context=" + regsub(req.http.cookie, "^.*?sw-cache-hash=([^;]*);*.*$", "\1"));
} elseif (req.http.cookie ~ "sw-currency=") {
hash_data("+currency=" + regsub(req.http.cookie, "^.*?sw-currency=([^;]*);*.*$", "\1"));
}
}
sub vcl_hit {
# Consider client states for response headers
if (req.http.cookie ~ "sw-states=") {
set req.http.states = regsub(req.http.cookie, "^.*?sw-states=([^;]*);*.*$", "\1");
if (req.http.states ~ "logged-in" && obj.http.sw-invalidation-states ~ "logged-in" ) {
return (pass);
}
if (req.http.states ~ "cart-filled" && obj.http.sw-invalidation-states ~ "cart-filled" ) {
return (pass);
}
}
}
sub vcl_backend_response {
# Fix Vary Header in some cases
# https://www.varnish-cache.org/trac/wiki/VCLExampleFixupVary
if (beresp.http.Vary ~ "User-Agent") {
set beresp.http.Vary = regsub(beresp.http.Vary, ",? *User-Agent *", "");
set beresp.http.Vary = regsub(beresp.http.Vary, "^, *", "");
if (beresp.http.Vary == "") {
unset beresp.http.Vary;
}
}
# Respect the Cache-Control=private header from the backend
if (
beresp.http.Pragma ~ "no-cache" ||
beresp.http.Cache-Control ~ "no-cache" ||
beresp.http.Cache-Control ~ "private"
) {
set beresp.ttl = 0s;
set beresp.http.X-Cacheable = "NO:Cache-Control=private";
set beresp.uncacheable = true;
return (deliver);
}
# strip the cookie before the image is inserted into cache.
if (bereq.url ~ "\.(png|gif|jpg|swf|css|js|webp)$") {
unset beresp.http.set-cookie;
}
# Allow items to be stale if needed.
set beresp.grace = 6h;
# Save the bereq.url so bans work efficiently
set beresp.http.x-url = bereq.url;
set beresp.http.X-Cacheable = "YES";
# Remove the exact PHP Version from the response for more security
unset beresp.http.x-powered-by;
return (deliver);
}
sub vcl_deliver {
## we don't want the client to cache
set resp.http.Cache-Control = "max-age=0, private";
# remove link header, if session is already started to save client resources
if (req.http.cookie ~ "session-") {
unset resp.http.Link;
}
# Set a cache header to allow us to inspect the response headers during testing
if (obj.hits > 0) {
unset resp.http.set-cookie;
set resp.http.X-Cache = "HIT";
} else {
set resp.http.X-Cache = "MISS";
}
# Remove the exact PHP Version from the response for more security (e.g. 404 pages)
unset resp.http.x-powered-by;
# invalidation headers are only for internal use
unset resp.http.sw-invalidation-states;
set resp.http.X-Cache-Hits = obj.hits;
}
Hinweis
Wenn die Webseite mit Basic Auth geschützt ist, z. B. in der Testphase, muss die authentisierend vor dem Varnish passieren, sonst werden die Daten nicht gecached.
Elasticsearch
Eine Elasticsearch kann sinnvoll sein, wenn im Shop sehr viele Kategorien oder Artikel(varianten) genutzt werden. Elasticsearch benötigt eigene Shopware Komponenten. Die Installation und Einrichtung von Elasticsearch ist in der Shopware Dokumentation zu finden.
Hinweis
Gerade vor dem Einsatz einer Elasticsearch sollte genau geprüft werden, ob dies notwendig ist. Shopware bietet auch eine Enterprise Suche an die ebenfalls auf der Elasticsearch Einbindung basiert.
Einbindung einer Elasticsearch in Shopware 6:
#.env
...
SHOPWARE_ES_HOSTS="elasticsearchhostname:9200"SHOPWARE_ES_ENABLED="1"
SHOPWARE_ES_INDEXING_ENABLED="1"
SHOPWARE_ES_INDEX_PREFIX="sw"
SHOPWARE_ES_THROW_EXCEPTION=1
...
Fazit
Kubernetes bietet unschlagbare Vorteile. Wer auf ausfallfreie Deployments, rasante Skalierung und Ausfallsicherheit nicht verzichten will, sollte über eine Transition in Kubernetes nachdenken. Gerne unterstützen wir beratend, schulen sie in Kubernetes oder führen die Transition für euch durch.
