Key Achievements
- Aufbau automatisierter Build Prozess für Magento Docker Images
- Optimierung Deployment und Generierung der statischen Assets
- Automatisierung der verschiedenen Staging Umgebungen
Automatisierter Build Prozess
Der Endkunde verfügt bereits über eine sehr grosse Openshift Umgebung inkl. Integration ihrer bestehenden Infrastruktur, von Continuous Integration (mit Jenkins) über Storage und Datenbank (AWS RDS) bis zu Network-Loadbalancing.
Das Ziel des Projekts war es eine E-Commerce Lösung mit Magento zu entwickeln und diese auf die bestehende Openshift Installation zu deployen. Dabei sollten möglichst viele bestehenden Tools des Kunden wiederverwendet werden und so viel wie möglich mit Jenkins-Jobs automatisiert werden.
Zum Thema Magento mit Docker betreiben findet man im Internet bereits viel Informationen. Jedoch wollten wir einerseits nicht wie die meisten Apache, sondern nginx verwenden und andererseits war es für uns wichtig das Docker Prinzip „ein Prozess pro Container“ einzuhalten. Daher haben wir uns für eine Architektur entschieden die der folgenden Grafik entspricht:
Optimierung des Deployments
Magento generiert minified CSS und JS Dateien und erstellt statische HTML Assets, welche je nach Plugin und Patchlevel variieren. Daher müssen bei jedem Deployment die statischen Assets neu generiert und deployed werden. In einem ersten Versuch haben wir die statischen Assets bereits während dem Image Build generiert und in einem init-container beim Starten der Magento Pods auf das shared Volume kopiert. Da die statischen Assets aber auch abhängig von den Produkten aus der Datenbank sind, mussten sie während dem Deployment mit der aktuellen Datenbank neu generiert werden.
Da die statischen Assets aus vielen kleinen Dateien bestehen welche gelesen und neu geschrieben werden, ist die Storage Performance essentiell wenn es darum geht die Dauer des Deployments zu optimieren. Da Kubernetes Memory based emptyDir unterstützt, konnten wir das Erstellen der Assets deutlich optimieren, standen aber vor dem Problem das emptyDir nur auf einem Node existiert. Dies konnte wir lösen, in dem in einem ersten init-container die Assets in ein memory based Ordner erstellt werden und in einem zweiten Schritt die Files aus dem emptyDir in das Persistent Volume übernommen werden. Dadurch konnte zudem sichergestellt werden, dass auch Rolling Releases möglich sind da die laufenden Pods noch Zugriff auf die alten Assets haben.
Durch den Wechsel auf ein Memory basiertes Volumen, von welchem die Files nur noch ins persistente Volumen kopiert werden müssen, konnten wir die Deployment Zeit ein weiteres mal halbieren.
Ihr Ansprechpartner
