Integration von Bereitstellungsautomatisierung und Konfigurationsmanagement

Mein Kollege Robert van Loghem und ich haben in den letzten Wochen über die Bereitstellung von Java EE gebloggt. Und das nicht ohne Grund. Wir haben Deployit entwickelt, ein Produkt zur Automatisierung von Java EE-Bereitstellungen. Wir haben es bereits in einigen unserer Podcasts und Blogs erwähnt, so dass jetzt vielleicht ein guter Zeitpunkt ist, um einige der Konzepte hinter unserem Produkt zu erklären.

Das Problem

Das Problem, mit dem sich unser Produkt befasst, besteht darin, dass Java EE-Bereitstellungen mühsam und unvorhersehbar sind und zudem sehr von spezifischen Kenntnissen abhängen können. Die Jungs von ZeroTurnaround haben eine Umfrage zu den Zeiten für die Neubereitstellung und den Neustart von Java EE durchgeführt. Die Ergebnisse sind interessant, insbesondere wenn man bedenkt, dass diese Zeiten für eine Neuverteilung in einer Entwicklungsumgebung gelten. Bedenken Sie die Herausforderungen, die sich in einer Produktionsumgebung mit einem Anwendungsserver-Cluster, mehreren Webservern, Datenbanken usw. ergeben, die alle konfiguriert und neu gestartet werden müssen . Ich glaube, dass die einzige Möglichkeit, Anwendungen zuverlässig und effizient bereitzustellen, darin besteht, diese Aufgabe zu automatisieren. Etwas, das auch IT-Analysten wie Gartner und Forrester als ein aufstrebendes und heißes Thema sehen.

Bei unseren Erfahrungen mit diesem Thema haben wir festgestellt, dass Middleware-Umgebungen so komplex sein können, dass niemand den vollständigen Überblick hat. Es ist wie in der Geschichte von den blinden Männern und dem Elefanten, wo einige blinde Männer einen Elefanten berühren, um herauszufinden, wie ein Elefant aussieht. Der eine berührt den Rüssel, der andere den Schwanz und wieder ein anderer einen Stoßzahn. Jeder von ihnen kennt einen kleinen Teil des Elefanten, aber keiner von ihnen hat das komplexe Bild des Elefanten. Für Middleware-Umgebungen bedeutet dies, dass die OS-Leute über alle Boxen im Netzwerk Bescheid wissen, die Java EE-Leute über die Anwendungsserver und die darauf laufenden Anwendungen, die DBAs über alle Datenbanken und die vorhandenen Schemata, während die Netzwerkleute wissen, was mit was verbunden ist. Ohne ein angemessenes Konfigurationsmanagement kann sich niemand ein vollständiges Bild machen, ohne sich mit all diesen Gruppen abzusprechen. Da es bei der Bereitstellung von Anwendungen darauf ankommt, zu wissen, was bereits vorhanden ist, und dann herauszufinden, was geändert werden muss, damit die Anwendung in Produktion gehen kann, bin ich der Meinung, dass Sie die Bereitstellung ohne ein angemessenes Konfigurationsmanagement nicht effektiv automatisieren können. Aus diesem Grund kombiniert unser Produkt zur Automatisierung der Bereitstellung, Deployit, diese beiden Aspekte. Wie macht Deployit das also? Lassen Sie mich das erklären, indem ich auf jede der drei beteiligten Komponenten eingehe:

1. die Datenbank der Konfigurationsverwaltung,
2. die Engine zur Auflösung von Änderungen und
3. die Ausführungsmaschine.

Die Datenbank zur Konfigurationsverwaltung

Die erste Komponente von Deployit, die Sie beim Starten der Flex-Benutzeroberfläche sehen, ist die Konfigurationsmanagement-Datenbank (CMDB). In der CMDB werden alle Informationen über die Middleware-Umgebung gespeichert. In der Abbildung rechts (Sie können darauf klicken, um sie zu vergrößern) sehen Sie eine Deployit CMDB für eine sehr einfache Demoumgebung. Jede Zeile steht für ein Konfigurationselement (CI) und die CMDB lässt sich wie folgt zusammenfassen:

• Die beiden Hosts, "Apache 2.2 host (VMWare)" und "WAS 6.1 host (VMWare)", sind die Hosts, auf denen die Middleware läuft. Wie der Name schon sagt, laufen diese Hosts auf VMWare.
• Das CI "Apache 2.2 Testserver" steht für eine Apache HTTP Server-Instanz, die auf dem "Apache 2.2 Host (VMware)" läuft.
• Die CIs, deren Name mit "WAS 6.1" beginnt, repräsentieren die IBM WebSphere Application Server 6.1-Installation auf "WAS 6.1-Host (VMware)".
• Die CIs, deren Name mit "PetClinic" beginnt, repräsentieren v1.0 der PetClinic-Demoanwendung; eine EAR-Datei (PetClinic-1.0.ear) und einige statische Inhalte (petclinic.zip).
• Die CI mit dem Namen "Testumgebung" ist eine Gruppe aller CIs, die die Testumgebung bilden. In diesem Fall wären das die CIs "Apache 2.2 test server" und "WAS 6.1 test cluster".
• Die KI "Einsatz von PetClinic in der Testumgebung" schließlich steht für die Tatsache, dass die PetClinic-Anwendung in unserer Testumgebung eingesetzt wurde. In Deployit ist eine Bereitstellung nicht nur eine Aktion, sondern ein Zustand der Umgebung. So wie eine Hochzeit der glückliche Tag ist und die Ehe der Zustand ist, in dem Sie sich von diesem Moment an befinden.

Die Engine zur Auflösung von Änderungen

Die CMDB in Deployit gibt Ihnen einen Überblick über den aktuellen Zustand Ihrer Umgebung. Aber wie hilft Ihnen das bei der Implementierung? Nun, dazu wechseln Sie auf die Registerkarte Design. Nehmen wir als Beispiel das Szenario, in dem wir die bereitgestellte Anwendung aktualisieren möchten. Wie bereits erwähnt, ist dieses Szenario weitaus häufiger als die ursprüngliche Bereitstellung. Wir wechseln also auf die Registerkarte Design und importieren die Version 2.0 unserer Anwendung in die CMDB. Und dann ändern wir das Deployment-CI so, dass es widerspiegelt, dass wir v2.0 in unserer Testumgebung bereitstellen möchten. Damit teilen wir Deployit deklarativ mit, dass wir ein Upgrade durchführen möchten, und die Change Resolution Engine von Deployit definiert die auszuführenden Schritte. Das Schöne daran ist, dass jeder ein Deployment durchführen kann, weil es so einfach ist wie das Ändern des Deployments in der Benutzeroberfläche. Dasselbe gilt für Middleware-Konfigurationsaktionen wie das Hinzufügen eines Clustermitglieds, das Ändern einer Datenquelle usw. Um herauszufinden, welche Schritte die Change Resolution Engine für notwendig erachtet, wechseln wir auf die Registerkarte Changeplan in der Benutzeroberfläche. Dort sehen wir eine Liste der Änderungen (um die vorgenommenen Änderungen zusammenzufassen) und die Liste der zu ergreifenden Schritte:

• Die erste Version 1.0 der PetClinic-Anwendung wird gestoppt und nicht mehr bereitgestellt.
• Dann wird die Version 2.0 der Anwendung bereitgestellt und gestartet.
• Aber das ist noch nicht alles! Die neue Version unserer PetClinic-Anwendung sollte über das WebSphere-Plugin im Apache verfügbar gemacht werden. Daher generiert Deployit die Konfiguration des WebSphere-Plugins und kopiert die generierte Datei in den Apache.
• Der alte statische Inhalt wird vom Apache-Host gelöscht und der neue statische Inhalt wird dorthin kopiert.
• Abschließend startet Deployit den Apache neu, damit er die aktualisierten WebSphere-Plugin-Informationen aufnimmt.

Die Ausführungsmaschine

Wenn wir alle gewünschten Änderungen vorgenommen und die Schritte nach unseren Vorstellungen überprüft haben, klicken wir auf die Schaltfläche "Bereitstellen" in der oberen Schaltflächenleiste, um die Schritte auszuführen. Die Ausführungs-Engine von Deployit meldet sich bei den Zielcomputern an und führt die Schritte aus. Sobald alle Schritte ausgeführt wurden, aktualisiert Deployit die CMDB, um die vorgenommenen Änderungen widerzuspiegeln: v2.0 der PetClinic-Anwendung ist nun auf der Registerkarte "Actual" sichtbar und die CI "Deployment of PetClinic on the test environment" zeigt an, dass PetClinic v2.0 in der Testumgebung bereitgestellt wurde.Die Ausführungs-Engine von Deployit benötigt keine Agenten, die auf dem Zielsystem installiert werden. Sie verwendet SSH, um sich bei den Zielcomputern anzumelden, und verwendet dort die nativen Schnittstellen der Ziel-Middleware (z.B. wsadmin oder WLST), um die notwendige Arbeit auszuführen.

Vorteile

Die Integration der Konfigurationsverwaltung in die Bereitstellungsautomatisierung bietet eine ganze Reihe von Vorteilen:

• Es ist nicht mehr nötig, Textdateien, Excel-Tabellen oder Wikis mit dem aktuellen Stand Ihrer Umgebung zu aktualisieren.
• Die tatsächliche Umgebung und die Datenbank für die Konfigurationsverwaltung bleiben synchron, wenn alle Änderungen automatisiert werden. Und das ist doch genau das, was wir wollen, oder?
• Die Schritte, die zur Durchführung einer Änderung erforderlich sind, werden anhand der Informationen in der CMDB und der daran vorgenommenen Änderungen bestimmt. Das System kann automatisch herausfinden, ob eine erstmalige Bereitstellung oder ein Upgrade durchgeführt werden soll. Oder ob eine WebSphere Plugin-Konfiguration erstellt werden soll oder nicht.
• Handbücher für die Bereitstellung sind nicht mehr nötig, auch nicht solche, die beschreiben, welche Skripte ausgeführt werden sollen!
• Jeder kann eine Bereitstellung durchführen; es gibt keine Abhängigkeit mehr von bestimmten Ressourcen.

Dies ist eine sehr kurze Zusammenfassung, wie Deployit funktioniert. In späteren Blogs werde ich die Konzepte hinter unserem Produkt erläutern.