© istockphoto.com/Alex_Doubovitsky
Entwickler Magazin
Teil 1: Erstellung der Containerarchitektur

Alles nur Containersache

Hätte mir jemand vor zwei Jahren erzählt, dass er alle Services seiner Webseite auf verschiedene virtualisierte Images verteilen möchte, dann hätte ich ihn vermutlich für verrückt erklärt. Man würde praktisch mittels Virtualisierungslösungen wie VirtualBox, QEMU, VMware oder Zen Images bauen, die nur dem Zweck dienen, einen spezifischen Service für eine Webseite anzubieten - inklusive eines vollumfänglichen Betriebssystems und den dafür zu reservierenden Ressourcen wie Hauptspeicher und Festplattenplatz. Vor zwei Jahren sicherlich undenkbar, heute dank Technologien wie Docker und LXC durchaus machbar. In dieser Artikelserie wird beschrieben, wie eine komplette Webseite inklusive RESTful-API und Datenbank mittels verschiedener Docker-Container realisiert wird.

Sascha Sambale


Ganz oben rechts im Buzzword-Quadranten finden wir neben Docker [1] auch immer wieder den Begriff „Microservices“. Das Konzept hinter diesen Services ist, sie so weit zu kapseln, dass sie nur einem bestimmten Einsatzzweck dienen und demnach autark operieren können. Das erhöht die Flexibilität, indem jeder Service ohne großen Aufwand durch einen anderen ersetzt und die für das bestimmte Szenario am besten geeignete Technologie genutzt werden kann. Da jeder Container dafür verantwortlich ist, einen bestimmten Zweck zu erfüllen, kann man genau dieses Konzept mit einer Containervirtualisierung auf einem höheren Level umsetzen (Loose Coupling).

Ganz genau lässt sich der Ansatz natürlich nicht übertragen, denn eine Grundvoraussetzung für einen Microservice ist, dass er über standardisierte Schnittstellen kommuniziert (z. B. über HTTP). Demnach steht ein Container, der mit einer Datenbank kommunizieren muss, in gewisser Abhängigkeit zum Datenbankcontainer, da der Datenbanktreiber der Applikation schließlich wissen muss, wie er mit einer Datenbank (z. B. MongoDB oder Oracle-SQL-Server) sprechen kann – es sei denn, sie ist über ein REST-API und ohne Treiber ansprechbar. Allerdings ist es dem Container egal, ob unter der Datenbank ein Ubuntu-, ein CentOS- oder ein Debian-Betriebssystem läuft, denn je nach Einsatzzweck hat jedes OS seine Vor- und Nachteile. Für Cloud-Dienste spielt diese Möglichkeit eine zentrale Rolle, um einzelne Applikationen als SaaS (Software as a Service) anzubieten. Für Administratoren bietet diese Architektur, neben dem zentralen Management der Container, die Möglichkeit, alle Container auf eine andere Hardware umzuziehen und wieder zu starten, denn die Konfigurationen der Server und Applikationen sind Bestandteil der portierbaren Images, beziehungsweise Teil des Docker-Hosts.

Ein weiterer wichtiger Aspekt bei der Aufteilung von Services in Container ist die Sicherheit. Denn schafft es ein Angreifer, über eine Schwachstelle in der Implementierung oder einen der genutzten Services, in das System zu gelangen, ist er vorerst im kompromittierten Container gefangen, sodass alle weiteren Services davon nicht betroffen sind.

Virtualisierung mittels VMware und Co.

Gehen wir davon aus, dass wir für eine neue Webseite fünf verschiedene Bestandteile brauchen: einen nginx-Webserver [2] als Reverse Proxy für die Verteilung aller eingehenden Requests; einen weiteren nginx-Server, der die statischen Dateien für die Webseite ausspielt; einen io.js-JavaScript-...

Entwickler Magazin
Teil 1: Erstellung der Containerarchitektur

Alles nur Containersache

Hätte mir jemand vor zwei Jahren erzählt, dass er alle Services seiner Webseite auf verschiedene virtualisierte Images verteilen möchte, dann hätte ich ihn vermutlich für verrückt erklärt. Man würde praktisch mittels Virtualisierungslösungen wie VirtualBox, QEMU, VMware oder Zen Images bauen, die nur dem Zweck dienen, einen spezifischen Service für eine Webseite anzubieten - inklusive eines vollumfänglichen Betriebssystems und den dafür zu reservierenden Ressourcen wie Hauptspeicher und Festplattenplatz. Vor zwei Jahren sicherlich undenkbar, heute dank Technologien wie Docker und LXC durchaus machbar. In dieser Artikelserie wird beschrieben, wie eine komplette Webseite inklusive RESTful-API und Datenbank mittels verschiedener Docker-Container realisiert wird.

Sascha Sambale


Ganz oben rechts im Buzzword-Quadranten finden wir neben Docker [1] auch immer wieder den Begriff „Microservices“. Das Konzept hinter diesen Services ist, sie so weit zu kapseln, dass sie nur einem bestimmten Einsatzzweck dienen und demnach autark operieren können. Das erhöht die Flexibilität, indem jeder Service ohne großen Aufwand durch einen anderen ersetzt und die für das bestimmte Szenario am besten geeignete Technologie genutzt werden kann. Da jeder Container dafür verantwortlich ist, einen bestimmten Zweck zu erfüllen, kann man genau dieses Konzept mit einer Containervirtualisierung auf einem höheren Level umsetzen (Loose Coupling).

Ganz genau lässt sich der Ansatz natürlich nicht übertragen, denn eine Grundvoraussetzung für einen Microservice ist, dass er über standardisierte Schnittstellen kommuniziert (z. B. über HTTP). Demnach steht ein Container, der mit einer Datenbank kommunizieren muss, in gewisser Abhängigkeit zum Datenbankcontainer, da der Datenbanktreiber der Applikation schließlich wissen muss, wie er mit einer Datenbank (z. B. MongoDB oder Oracle-SQL-Server) sprechen kann – es sei denn, sie ist über ein REST-API und ohne Treiber ansprechbar. Allerdings ist es dem Container egal, ob unter der Datenbank ein Ubuntu-, ein CentOS- oder ein Debian-Betriebssystem läuft, denn je nach Einsatzzweck hat jedes OS seine Vor- und Nachteile. Für Cloud-Dienste spielt diese Möglichkeit eine zentrale Rolle, um einzelne Applikationen als SaaS (Software as a Service) anzubieten. Für Administratoren bietet diese Architektur, neben dem zentralen Management der Container, die Möglichkeit, alle Container auf eine andere Hardware umzuziehen und wieder zu starten, denn die Konfigurationen der Server und Applikationen sind Bestandteil der portierbaren Images, beziehungsweise Teil des Docker-Hosts.

Ein weiterer wichtiger Aspekt bei der Aufteilung von Services in Container ist die Sicherheit. Denn schafft es ein Angreifer, über eine Schwachstelle in der Implementierung oder einen der genutzten Services, in das System zu gelangen, ist er vorerst im kompromittierten Container gefangen, sodass alle weiteren Services davon nicht betroffen sind.

Virtualisierung mittels VMware und Co.

Gehen wir davon aus, dass wir für eine neue Webseite fünf verschiedene Bestandteile brauchen: einen nginx-Webserver [2] als Reverse Proxy für die Verteilung aller eingehenden Requests; einen weiteren nginx-Server, der die statischen Dateien für die Webseite ausspielt; einen io.js-JavaScript-...

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