© saicle/Shutterstock.com
PHP Magazin
Docker am praktischen Beispiel - mit WordPress

Hübsch verpackt

Technologischer Fortschritt, der im Web stattfindet, hat ein sehr eindeutiges Alleinstellungsmerkmal: Alles Neue muss schneller sein und besser skalieren. Und das macht die Sache für uns gerade erst spannend, denn die kontinuierlich sinkenden Kosten - sowohl für Hardware als auch Know-how im Open-Source-Umfeld - machen es uns leichter, uns an Lösungen zu wagen, die früher noch zu kostspielig waren.

Vsevolod Dolgopolov


Noch vor nicht all zu langer Zeit galt es als Standard, völlig voneinander unterschiedliche Services auf gleichem Server laufen zu lassen: Mailserver, Datenbank, Webserver, Runtime Environment, Storage etc. Parallelen zu unseren Desktoprechnern waren nicht zu übersehen.

Heute allerdings – hier rede ich von der PHP-Welt – ist es so gut wie ausnahmslos so, dass PHP und die Datenbank in der Produktivumgebung auf verschiedenen Servern laufen. Lokal bleibt es aber eher wie gehabt: Hier wird weiterhin alles zusammen auf der gleichen Maschine laufen. Der Grund ist meistens erst einmal der, dass unsere Rechner eine zusätzliche VM nicht immer ohne Weiteres verkraften. Und da lokal sowieso meistens keine großartig vielen Daten gebraucht werden, wird meist darauf verzichtet, eine oder mehrere zusätzliche VMs darauf zu schalten.

Alles hat seinen Preis

Das hat natürlich seinen Preis. Wenn die Topologie der lokalen Entwicklungsumgebung nicht mit der von Production oder Staging übereinstimmt, führt das dazu, dass die Applikation, einmal online gestellt, plötzlich anders funktioniert; wenn überhaupt. Die Lösung: Container. Sie nehmen den gesamten Overhead, den ein Virtual Machine Hypervisor wie VirtualBox mit sich bringt, komplett weg. Man bleibt weiter bei gleichem Kernel, legt lediglich einen neuen User Space darauf und besitzt so eine neue, komplett isolierte Umgebung. Das Problem war bis jetzt die Verwaltung der Container. Das erforderte spezielle Kenntnisse, die Applikationsentwickler nicht unbedingt haben sollten bzw. benötigten. Doch Docker hat diese Lage ordentlich umgekrempelt: Das Containermanagement ist jetzt so einfach geworden wie nie.

Genau das wollen wir uns genauer am Beispiel eines lokalen WordPress-Set-ups ansehen. Wir trennen PHP und MySQL voneinander und bleiben einem Konzept des guten Softwaredesigns treu: dem „Separation of Concerns“. Dabei lassen wir auch den Webserver (NGINX) als eigenständige Network Instance separat von der Skriptausführungsumgebung laufen.

Bevor wir beginnen, müssen wir uns zunächst überlegen, welche Abhängigkeiten wir verwalten müssen. Dabei lassen wir die Securityaspekte erst mal außen vor, uns geht es in erster Linie ums Konzept: die drei Container für NGINX, PHP und MySQL für eine WordPress-Applikation.

Es wird gleich klar, dass MySQL von den anderen Containern eigentlich nichts wissen muss. Die einzige Aufgabe ist es, den Clients Daten zur Verfügung zu stellen. Dabei muss PHP sehr wohl vom MySQL-User Bescheid wissen, wobei NGI...

PHP Magazin
Docker am praktischen Beispiel - mit WordPress

Hübsch verpackt

Technologischer Fortschritt, der im Web stattfindet, hat ein sehr eindeutiges Alleinstellungsmerkmal: Alles Neue muss schneller sein und besser skalieren. Und das macht die Sache für uns gerade erst spannend, denn die kontinuierlich sinkenden Kosten - sowohl für Hardware als auch Know-how im Open-Source-Umfeld - machen es uns leichter, uns an Lösungen zu wagen, die früher noch zu kostspielig waren.

Vsevolod Dolgopolov


Noch vor nicht all zu langer Zeit galt es als Standard, völlig voneinander unterschiedliche Services auf gleichem Server laufen zu lassen: Mailserver, Datenbank, Webserver, Runtime Environment, Storage etc. Parallelen zu unseren Desktoprechnern waren nicht zu übersehen.

Heute allerdings – hier rede ich von der PHP-Welt – ist es so gut wie ausnahmslos so, dass PHP und die Datenbank in der Produktivumgebung auf verschiedenen Servern laufen. Lokal bleibt es aber eher wie gehabt: Hier wird weiterhin alles zusammen auf der gleichen Maschine laufen. Der Grund ist meistens erst einmal der, dass unsere Rechner eine zusätzliche VM nicht immer ohne Weiteres verkraften. Und da lokal sowieso meistens keine großartig vielen Daten gebraucht werden, wird meist darauf verzichtet, eine oder mehrere zusätzliche VMs darauf zu schalten.

Alles hat seinen Preis

Das hat natürlich seinen Preis. Wenn die Topologie der lokalen Entwicklungsumgebung nicht mit der von Production oder Staging übereinstimmt, führt das dazu, dass die Applikation, einmal online gestellt, plötzlich anders funktioniert; wenn überhaupt. Die Lösung: Container. Sie nehmen den gesamten Overhead, den ein Virtual Machine Hypervisor wie VirtualBox mit sich bringt, komplett weg. Man bleibt weiter bei gleichem Kernel, legt lediglich einen neuen User Space darauf und besitzt so eine neue, komplett isolierte Umgebung. Das Problem war bis jetzt die Verwaltung der Container. Das erforderte spezielle Kenntnisse, die Applikationsentwickler nicht unbedingt haben sollten bzw. benötigten. Doch Docker hat diese Lage ordentlich umgekrempelt: Das Containermanagement ist jetzt so einfach geworden wie nie.

Genau das wollen wir uns genauer am Beispiel eines lokalen WordPress-Set-ups ansehen. Wir trennen PHP und MySQL voneinander und bleiben einem Konzept des guten Softwaredesigns treu: dem „Separation of Concerns“. Dabei lassen wir auch den Webserver (NGINX) als eigenständige Network Instance separat von der Skriptausführungsumgebung laufen.

Bevor wir beginnen, müssen wir uns zunächst überlegen, welche Abhängigkeiten wir verwalten müssen. Dabei lassen wir die Securityaspekte erst mal außen vor, uns geht es in erster Linie ums Konzept: die drei Container für NGINX, PHP und MySQL für eine WordPress-Applikation.

Es wird gleich klar, dass MySQL von den anderen Containern eigentlich nichts wissen muss. Die einzige Aufgabe ist es, den Clients Daten zur Verfügung zu stellen. Dabei muss PHP sehr wohl vom MySQL-User Bescheid wissen, wobei NGI...

Neugierig geworden?


   
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang