© Excellent backgrounds/Shutterstock.com
Java Magazin
Ein Werkzeug für die Automatisierung des kompletten Serverlebenszyklus

The Foreman

Continuous Delivery ist in aller Munde. Dabei wird jedoch häufig nur auf die automatisierte Auslieferung der Softwareartefakte eingegangen und das zugrunde liegende Betriebssystem außer Acht gelassen. Auch dort, wo Konfigurationsmanagement- (engl. Configuration Management, CM) Werkzeuge wie Chef und Puppet für die automatische Konfiguration verwendet werden, wird das Betriebssystem selbst oft noch manuell installiert und verwaltet. Aber genau dort kommt es durch Konfigurationsänderungen im Laufe der Zeit zu einem Auseinanderdriften der Einstellungen (engl. Configuration Drifts [1]), also bspw. zu Unterschieden zwischen der Infrastruktur in Entwicklung, Test und Produktion. Dies wiederum führt dazu, dass die Ergebnisse von Tests keine Aussagekraft mehr für die Produktionsumgebung haben.

Felix Massem, Jan-Frederic Markert


The Cloud Platform Play

Um die Lücke zu schließen, die durch den Configuration Drift entsteht, hat Martin Fowler den so genannten Phoenix Server beschrieben [2]. Ein Phoenix Server zeichnet sich dadurch aus, dass er bei jeder Änderung komplett zerstört und neu aufgebaut wird – wie ein Phönix aus der Asche. Wie kann ein solcher Phoenix Server aber innerhalb einer Continuous Deployment (CD) Pipeline eingesetzt werden? An dieser Stelle kommt das Immutable Server Pattern zum Einsatz [3]. Betrachten wir die CD Pipeline in Abbildung 1, so sehen wir, dass im Schritt „Konfiguriere Infrastruktur“ ein bereits installierter und konfigurierter Server erneut konfiguriert wird. Führt man das Immutable Server Pattern ein, so wird (wie in Abbildung 2 gezeigt) in diesem Schritt der Server vollständig neu provisioniert. Dies führt dazu, dass auch kleinste Änderungen, bspw. am Betriebssystem, zu einer neuen Provisionierung des Servers führen. Server sind also unveränderlich und bleiben damit über alle Umgebungen hinweg gleich; ein Configuration Drift wird verhindert.

Abb. 1: Die herkömmliche CD Pipeline bietet viele Gefahren für Configuration Drifts

Abb. 2: Die überarbeitete CD Pipeline provisioniert den Server immer neu

Um Server aber ohne zu viel Aufwand immer wieder aus der Asche zu heben, benötigen wir ein Tool: The Foreman – ein Werkzeug für die Automatisierung des kompletten Serverlebenszyklus.

In diesem Artikel werden wir dazu zunächst auf das Thema Complete Lifecycle Management eingehen und aufzeigen, wie Foreman dieses automatisiert. Daraufhin wird anhand eines Testaufbaus gezeigt, wie Foreman dazu verwendet werden kann, Metal as a Service (MaaS) bereitzustellen. Mit dem vorgestellten Aufbau ist es möglich, neue Hardware automatisch mit einem Betriebssystem auszustatten, zu konfigurieren und zu verwalten. Hiermit wird an den ersten Teil der Artikelserie angeknüpft und der automatisierte Unterbau für eine Infrastructure as a Service (IaaS) bereitgestellt. In den folgenden Ausgaben wird ausgehend von der MaaS-Schicht nach und nach die IaaS-, PaaS-Schicht und die nötige CD Pipeline beschrieben, um das zuvor beschriebene Immutable Server Pattern umzusetzen.

Der Serverlebenszyklus und The Foreman

Der Lebenszyklus eines Servers besteht aus der initialen Installation des Betriebssystems, der anschließenden Konfiguration und schließlich der Verwaltung des Servers im laufenden Betrieb. Vielfach wird dieser Lebenszyklus schon heute teilweise automatisiert; insbesondere ...

Java Magazin
Ein Werkzeug für die Automatisierung des kompletten Serverlebenszyklus

The Foreman

Continuous Delivery ist in aller Munde. Dabei wird jedoch häufig nur auf die automatisierte Auslieferung der Softwareartefakte eingegangen und das zugrunde liegende Betriebssystem außer Acht gelassen. Auch dort, wo Konfigurationsmanagement- (engl. Configuration Management, CM) Werkzeuge wie Chef und Puppet für die automatische Konfiguration verwendet werden, wird das Betriebssystem selbst oft noch manuell installiert und verwaltet. Aber genau dort kommt es durch Konfigurationsänderungen im Laufe der Zeit zu einem Auseinanderdriften der Einstellungen (engl. Configuration Drifts [1]), also bspw. zu Unterschieden zwischen der Infrastruktur in Entwicklung, Test und Produktion. Dies wiederum führt dazu, dass die Ergebnisse von Tests keine Aussagekraft mehr für die Produktionsumgebung haben.

Felix Massem, Jan-Frederic Markert


The Cloud Platform Play

Um die Lücke zu schließen, die durch den Configuration Drift entsteht, hat Martin Fowler den so genannten Phoenix Server beschrieben [2]. Ein Phoenix Server zeichnet sich dadurch aus, dass er bei jeder Änderung komplett zerstört und neu aufgebaut wird – wie ein Phönix aus der Asche. Wie kann ein solcher Phoenix Server aber innerhalb einer Continuous Deployment (CD) Pipeline eingesetzt werden? An dieser Stelle kommt das Immutable Server Pattern zum Einsatz [3]. Betrachten wir die CD Pipeline in Abbildung 1, so sehen wir, dass im Schritt „Konfiguriere Infrastruktur“ ein bereits installierter und konfigurierter Server erneut konfiguriert wird. Führt man das Immutable Server Pattern ein, so wird (wie in Abbildung 2 gezeigt) in diesem Schritt der Server vollständig neu provisioniert. Dies führt dazu, dass auch kleinste Änderungen, bspw. am Betriebssystem, zu einer neuen Provisionierung des Servers führen. Server sind also unveränderlich und bleiben damit über alle Umgebungen hinweg gleich; ein Configuration Drift wird verhindert.

Abb. 1: Die herkömmliche CD Pipeline bietet viele Gefahren für Configuration Drifts

Abb. 2: Die überarbeitete CD Pipeline provisioniert den Server immer neu

Um Server aber ohne zu viel Aufwand immer wieder aus der Asche zu heben, benötigen wir ein Tool: The Foreman – ein Werkzeug für die Automatisierung des kompletten Serverlebenszyklus.

In diesem Artikel werden wir dazu zunächst auf das Thema Complete Lifecycle Management eingehen und aufzeigen, wie Foreman dieses automatisiert. Daraufhin wird anhand eines Testaufbaus gezeigt, wie Foreman dazu verwendet werden kann, Metal as a Service (MaaS) bereitzustellen. Mit dem vorgestellten Aufbau ist es möglich, neue Hardware automatisch mit einem Betriebssystem auszustatten, zu konfigurieren und zu verwalten. Hiermit wird an den ersten Teil der Artikelserie angeknüpft und der automatisierte Unterbau für eine Infrastructure as a Service (IaaS) bereitgestellt. In den folgenden Ausgaben wird ausgehend von der MaaS-Schicht nach und nach die IaaS-, PaaS-Schicht und die nötige CD Pipeline beschrieben, um das zuvor beschriebene Immutable Server Pattern umzusetzen.

Der Serverlebenszyklus und The Foreman

Der Lebenszyklus eines Servers besteht aus der initialen Installation des Betriebssystems, der anschließenden Konfiguration und schließlich der Verwaltung des Servers im laufenden Betrieb. Vielfach wird dieser Lebenszyklus schon heute teilweise automatisiert; insbesondere ...

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