26,6% of all websites worldwide are running on WordPress! Now that’s a lot of sites! For those of you who thought WordPress was still a CMS relegated to bloggers, think again. 38% of all online stores worldwide run wooCommerce (WordPress’ eCommerce plugin) on top of WordPress, yowzers! But how do you scale WordPress for high traffic peaks?
In this talk, Jan Löffler (CTO at Plesk) will demonstrate how to scale WordPress on AWS and Docker using AutoScaling to make your apps and websites fly high!
43. code.talks 2016, Hamburg
Keynote:
“High traffic sites with WordPress,
Docker & AWS”
How to auto-scale WordPress on
AWS and make it fly!
Stay tuned!
Jan Löffler Marko Heijnen
47. We b D e v e l o p m e n t Ke y To o l s – w h a t w e b d e v e l o p e rs n e e d a n d
u s e
47
26,6% of all websites
worldwide
2,7% 2,2%
(high traffic sites)
70% of developers use git as primary
source management solution
Increasing usage by web agencies
38% of all online stores worldwide
runs on top of WordPress as plugin
developed by automattic
used by 30% of IT companies
increased from 13% to 30% in 12 months
further 35% plan introduction
Sources: w3techs.com, Rightscale, StackOverflow Survey 2015, 2016, Netcraft
311% growth
17.2% usage
26.8% growth
17.9% usage
14.9% growth
16% of all webservers
22% of all active sites
continuously growing,
while Apache is shrinking
48. WordPress Management
Free SSL everywhere
http2 50+ extensions
CLI
Automatic Updates
Site Migration
Free support
30+ languages
nginx
Server Security DNS
49. ✔
Plesk Onyx: Continuous Delivery Deployment Pipeline (sample)
49
Jenkins runs as
Docker container
managed by Plesk
Plesk Multi Server
Extension installs
three environments
Apps managed
by Plesk via Docker
Hinweis der Redaktion
Title: AutoScaling WordPress with Docker & AWS
Title long: WordPress Meetup Karlsruhe Plesk 2016 - AutoScaling WordPress with Docker & AWS - by Jan Lö̈ffler
Keywords: plesk, docker, web development, aws, immutable infrastructure, immutable servers, phoenix servers, autoscaling, wordpress, cms, cloud service provider, jan loeffler plesk, plesk container days, plesk, webops
Abstract: 26,6% of all websites worldwide are running on WordPress! Now that’s a lot of sites! For those of you who thought WordPress was still a CMS relegated to bloggers, think again. 38% of all online stores worldwide run wooCommerce (WordPress’ eCommerce plugin) on top of WordPress, yowzers! But how do you scale WordPress for high traffic peaks?
In this talk, Jan Löffler (CTO at Plesk) will demonstrate how to scale WordPress on AWS and Docker using AutoScaling to make your apps and websites fly high!
WordPress – der beliebteste Website-Baukasten der Welt! Hat 2003 erstmals das Licht der Welt erblickt und ist in den letzten 13 Jahren zum iPod der Webseitenerstellung geworden.
Hier könnt ihr das Wachstum sehen. Das krasse dabei ist, dass WordPress inzwischen 60% Marktanteil bei CMS-Webseiten hat und 26,6% bei allen Webseiten – weltweit. Jetzt müsste man nur noch wissen, wie viele Webseiten es überhaupt gibt auf der Welt. Weiß es noch jemand?
Bamm, über 1 Mrd Webseiten gibt es zur Zeit. Davon sind allerdings ettliche statisch und nicht regelmäßig gepflegt. Z.B. gibt es nur ca. 325 Mio TLDs. Dennoch heiß dies, dass jede vierte Webseite der Welt mit WordPres läuft.
Übrigens auch 38% aller E-Shops laufen auf WordPress zusammen mit dem WooCommerce als Plugin.
Allerdings gibt es nicht nur WordPress, sondern auch Alternativen wie Joomla! Mit 2,7% aller Webseiten weltweit und 5,9% aller CMS basierten Websiten die klare Nummer 2! Gefolgt von Drupal auf Platz 3 (2,2% und 4,9%), Magento auf Platz 4 (1,3% und 2,8%) und Blogger auf Platz 5 (1,2%).
Bei High Traffic Sites sieht es allerdings anders aus und Drupal führt mit großem Abstand das Feld an. Die Frage ist nun: Wie bekommen wir WordPress super schnell?
Wie bekommen wir WordPress super schnell? Die Antwort – das geht nur mit mehr Hardware – wie bei Drupal auch.
Die Antwort – das geht nur mit mehr Hardware – wie bei Drupal auch.
WordPress auf mehrere Server verteilen? Wie geht das denn? Wer von euch hat das schon mal gemacht?
Wir brauchen also mehrere Server, auf denen WordPress laufen soll, einen load-balancer, der die Last auf diese Server verteilt und eine gemeinsame Datenbank.
Noch besser wird es aber, wenn der ganze statische Content direkt von super schnellen Storage Systemen ausgeliefert wird, und gar nicht erst vom Webserver. Außerdem sparen wir so massiv Speicherplatz und somit Kosten –bei gleichzeitig höherer Leistung.
Und noch schneller wird es, wenn man die Dateien möglichst nah an die Kunden ranbringt, um die Latenz zu verringern. Heißt ein CDN (Content-Delivery-Network) muss her. Und auch die Datenbank kann man noch clustern.
Die nächste Frage ist nun: wollen wir das alles von Hand installieren? Wie sieht denn das Deployment aus?
Und dafür nutzen wir Docker. Wer weiß nicht was Docker ist? Docker hat für uns den großen Vorteil, dass es reproduzierbar ist, d.h. ich baue mir einmal ein Docker Image und kann beliebig viele Instanzen davon erzeugen.
Wie beliebt und verbreite Docker ist, zeigt folgende Grafik: Docker wurde 2014 veröffentlicht, hat aus dem Stand eine Nutzung von 13% erreicht und anschließend sogar innerhalb eines Jahres erneut verdoppelt. D.h. dass Anfang diesen Jahres 30% der weltweiten Software-Entwickler verwendet haben und weitere 35% den Einsatz von Docker planen. Aber warum ist Docker eigentlich so erfolgreich. Was genau wird damit anders als bisher?
Ok, wir packen also WordPress in einen Docker Container – und weiter?
Jetzt wird’s spannend – ein kleines bisschen Theorie bevor wir in die Praxis abtauchen…
Ein absoluter Trend ist aktuell „Immutable Infrastructure“ oder auch „Immutable Server“ genannt. Aber was ist „Immutable Infrastructure“ überhaupt?
Immutable bedeutet „unveränderlich“. Und bezogen auf Infrastruktur bedeutet dies, dass sie sich nicht mehr ändert nachdem sie einmal Online gestellt wurde. Die Frage ist: „wie werden dann Patches und Security-Updates installiert, geschweige denn neue Versionen“? Gar nicht – zumindest nicht in der gleichen Instanz meiner Software! Wenn ich meine Software aktualisieren möchte – ob wegen eines Security Updates der SSL Library oder nur ein Bugfix meiner Software selbst – dann nehme ich einfach einen neuen Server. Warum wir das tun sollten? Das wäre ein ganz eigener Vortrag und ich erläutere Details gerne im Nachgang. Für jetzt gibt es nur einen kleinen Vorgeschmack über die vielen Vorteile und Möglichkeiten. Wie das geht zeigt [next slide] folgendes Schaubild.
Als Infrastruktur nehme ich jetzt mal AWS, da die am weitesten verbreitet sein.
Es geht aber auch mit diesen Hostern – nur die APIs sind leider nicht standardisiert. D.h. jeder Hoster hat seine eigene API und die muss man erst mal lernen. Gut, nun zu Immutable Infrastructure...
Wie das geht zeigt folgendes Schaubild. Wir sehen eine Web Applikation die unter app.example.org erreichbar ist. Deployed ist diese App in der Version „myapp-v1“ als Docker Container auf 3 Servern von AWS (EC2 genannt). Die Last wird vom Elastic Loadbalancer gleich auf die 3 Instanzen verteilt. Diese Instanzen sind selbst „stateless“, d.h. sie speichern ihre Daten in einem zentralen Storage wie z.B. einer Datenbank.
Wenn wir nun unsere Applikation aktualisieren wollen oder es ein Systemupdate benötigt [next slide]
… dann stellen wir einfach eine neue Version inkl. des benötigten Serverstacks (also Betriebsystem, php runtime, etc.) zusätzlich online und routen etwas Traffic auf den neuen Url-Endpunkt. Und dann können wir, wenn alles zuverlässig läuft, den gesamten Traffic auf die neue Version leiten und ... [next slide]
... die alten Instanzen löschen, damit die Hosting Rechnung nicht zu hoch wird.
Um ausreichend Flexibilität bei gleichzeitig starker Sicherheit zu gewährleisten, kommt hier ein mehrschichtiges Modell zum Einsatz. Ausgangsbasis ist die Virtuelle Maschine und das Basis Image mit dem Betriebssystem (bei AWS reden wir vom AMI). Direkt beim Start einer neuen EC2 Instanz lassen wir direkt unser gewünschtes Docker Image – welches unsere Applikation in der gewünschten Version enthält – von der Docker Registry laden und starten den Container. Darin startet der Webserver z.B. nginx oder Apache oder beide und alles was unsere App benötigt.
Der Wunsch – der Entwickler ruft einfach die API auf und dann erstellt AWS die VMs, holt sich das aktuelle Docker Image mit unserem WordPress und fertig.
Die Realität sieht leider anders aus.
Alleine die EC2 API hat 210 calls parat – und leider braucht man auch ettliche von denen, um etwas automatisiert zu deployen. Aber EC2 ist nicht alles.
AWS hat noch viel mehr APIs - und das hier sind nur die, die wir wirklich alle brauchen. Und jede API hat wiederum sehr viele calls, bei denen man erst mal wissen muss, was sie tun. Und von den vielen Parametern rede ich am besten gar nicht.
Doch es gibt Abhilfe – der Plesk WordPress AWS Scaler!
Der Plesk WordPress AWS Scaler – und der ist Open Source und zwar hier.
Der Plesk WordPress AWS Scaler – und der ist Open Source und zwar hier. Und damit wird’s zum Kinderspiel
Ihr klont euch einfach das Git Repo, installiert die AWS CLI von der AWS Webseite und ruft manage-wordpress.sh auf. So leicht ist das!
War das nicht einfach? Bei Plesk haben wir uns zum Ziel gesetzt, Web Professionals das Leben zu erleichtern, indem wir deren Prozesse vereinfachen und automatisieren.
Falls ihr zu dem Projekt habt und wissen wollt, wie ich das alles genau gemacht habe, dann ...
Falls ihr zu dem Projekt habt und wissen wollt, wie ich das alles genau gemacht habe, dann schiest los
If you asked yourself what Plesk has to do with the whole talk?
Plesk is the leading Web Development platform and control panel to run, automate and grow applications, websites and hosting businesses.