Deployment Automation Of Docker WebLogic Cluster On Any Cloud

Deployment Automation von Docker WebLogic Cluster auf einer beliebigen Wolke

Hintergrund

Java-Entwickler und DevOps Fachleute haben lange gekämpft, um die Bereitstellung von Enterprise-Java-Anwendungen zu automatisieren. Die Komplexität dieser Anwendungen bedeutete in der Regel, dass Anwendungsabhängigkeiten und externe Integrationen konfiguriert wieder werden musste jedes Mal, wenn eine Anwendung in DEV / TEST Umgebungen eingesetzt wurde.

Viele Lösungen beworben, die "einmal modellieren, implementieren überall" Nachricht für Applikations-Deployments. In Wirklichkeit aber es gab immer Feinheiten, die es sehr schwierig, wieder zu verwenden, um eine Anwendungsvorlage über beide aus einer On-Premise virtuellen vSphere-Umgebung und einer AWS-Umgebung, zum Beispiel.

Vor kurzem populär Docker Container jedoch die Idee der Verpackung Anwendungskomponenten in Linux Container, die genau so lange das gleiche auf jedem Linux-Host bereitgestellt werden können als Docker Engine installiert ist.

Leider Anwendungen Enterprise-Java-containerizing ist nach wie vor eine Herausforderung vor allem, weil bestehende Anwendung Zusammensetzung Rahmenbedingungen befassen sich nicht mit komplexen Abhängigkeiten, externe Integrationen oder automatische Skalierung Workflows post-Bereitstellung. Außerdem bedeutete die ephemeren Design von Behältern, dass die Entwickler neue Behälter zu drehen musste und neu zu erstellen, die komplexen Abhängigkeiten und externe Integration mit jeder Version zu aktualisieren.

DCHQ, in gehosteten und On-Premise-Versionen adressiert all diese Herausforderungen und vereinfacht die Containerisierung von Enterprise-Java-Anwendungen über eine vorzeitige Anwendung Zusammensetzung Rahmen, der Docker Compose mit Quer Bild Umgebungsvariable Bindungen, erweiterbare BASH-Skript-Plug-Ins, die können sich zum Zeitpunkt der Anforderung oder nach der Bereitstellung und Anwendungs-Clustering für Hochverfügbarkeit über mehrere Hosts oder Regionen mit Unterstützung für automatische Skalierung aufgerufen werden.

Sobald eine Anwendung bereitgestellt wird, kann ein Benutzer überwachen die CPU, Speicher, und I / O der Laufbehälter, erhalten Benachrichtigungen und Alarme und Tag-2-Operationen wie der geplante Backups durchführen, Container Updates BASH-Skript-Plug-ins verwenden und Skalierung in / Out. Out-of-box-Workflows Darüber hinaus, die mit Jenkins Continuous Delivery erleichtern ermöglichen es Entwicklern, die Java-WAR-Datei von einer laufenden Anwendung zu aktualisieren, ohne die vorhandenen Abhängigkeiten und Integrationen zu stören.

In diesem Blog werden wir die End-to-End-Bereitstellung Automatisierung eines Docker-basierten WebLogic Cluster gehen. Wir behandeln:

• Erstellen des Anwendungsvorlage für WebLogic Cluster, die überall auf jedem Linux-Host ausgeführt wird wiederverwendet kann
• Provisioning & automatische Skalierung der zugrunde liegenden Infrastruktur auf jeder Cloud (mit Rackspace das Beispiel in diesem Blog zu sein)
• Bereitstellen des WebLogic Cluster auf den Cloud-Server Rackspace
• Bereitstellen der Einkaufswagen Java WAR-Datei auf dem Admin-Server
• Zugriff auf den In-Browser-Terminal für Container Lauf
• die kontinuierliche Lieferung Workflow-mit Jenkins Aktivieren der WAR-Datei der laufenden Anwendungen zu aktualisieren, wenn ein Build ausgelöst wird
• Die Überwachung der CPU, Speicher und I / O der Laufbehälter

Erstellen der Anwendung Vorlage für den Oracle WebLogic 12c Cluster

Einmal DCHQ angemeldet (entweder die gehostete DCHQ.io oder On-Premise - Version) kann ein Benutzer zu navigieren App & Machine und klicken Sie dann auf die + Taste , um eine neue zu erstellen Docker Compose Vorlage.

Wir haben eine WebLogic Cluster Anwendungsvorlage mit einem benutzerdefinierten Bild haben wir Radu Dobrinescu das Image gebaut Nutzung (radudobrinescu / wls12c: 2.0).

Sie werden feststellen , dass der CLUSTER_SIZE Parameter können Sie die Anzahl der Container angeben zu starten (mit den gleichen Anwendungsabhängigkeiten). Wir verwenden diese die Managed Server - Cluster - Größe zu definieren.

Der Host - Parameter können Sie den Host an Sie für Container - Implementierungen verwenden möchten. Auf diese Weise können Sie für Ihren Anwendungsserver - Cluster über verschiedene Hosts (oder Regionen) mit hoher Verfügbarkeit gewährleisten und Sie können mit Affinitätsregeln einhalten , um sicherzustellen , dass die Datenbank auf einem separaten Host zum Beispiel läuft. Hier sind die Werte für den Host - Parameter unterstützt:

• host1, host2, host3 usw. - wählt einen Host zufällig innerhalb eines Datenzentrums (oder Cluster) für Container - Implementierungen
• <IP - Adresse 1, IP - Adresse 2 usw.> - ermöglicht es dem Benutzer die tatsächliche IP - Adressen angeben für Container - Implementierungen verwenden
• <Hostname 1, Hostname 2 usw.> - ermöglicht es dem Benutzer die tatsächlichen Host - Namen angeben , für Container - Implementierungen verwenden
• Wildcards (zB "db- *" oder "app-SRV *") - die Platzhalter festlegen , die in einem Host - Namen zu verwenden ,

Zusätzlich kann eine Benutzerumgebung Quer Bild Variablenbindungen erstellen, indem Sie einen Verweis auf ein anderes Bild der Umgebungsvariable zu machen. In diesem Fall haben wir eine verbindlich gemacht diese caes: ADMIN_HOSTNAME = {{Admin | ip}} - bei dem der Admin-Server Host-IP wird dynamisch zum Zeitpunkt der Anforderung aufgelöst und wird verwendet, um sicherzustellen, dass die Managed Server eine Verbindung mit dem Admin-Server herstellen können.

Hier ist eine Liste der unterstützten Umgebungsvariablen Werte:

• {{alphanumeric | 8}} - erzeugt eine zufällige 8-stellige alphanumerische Zeichenfolge. Dies ist besonders nützlich für die Erstellung von zufällige Passwörter.
• {{<Image Name> | ip}} - können Sie die Host - IP - Adresse eines Containers als Wert für eine Umgebungsvariable einzugeben. Dies ist am nützlichsten zum Ermöglichen des Middleware - Ebene eine Verbindung mit der Datenbank herzustellen.
• {{{<Image Name> | container_ip}} - können Sie den Containernamen eines Containers als Wert für eine Umgebungsvariable einzugeben. Dies ist besonders praktisch , wenn es die Middleware Tier eine sichere Verbindung mit der Datenbank herzustellen (ohne den Datenbankport ausgesetzt).
• {{<Bildname> | container_private_ip}} - ermöglicht es Ihnen , die interne IP eines Containers als Wert für eine Umgebungsvariable einzugeben. Dies ist besonders praktisch , wenn es die Middleware Tier eine sichere Verbindung mit der Datenbank herzustellen (ohne den Datenbankport ausgesetzt).
• {{<Image Name> | port _<Port Number>}} - können Sie die Port - Nummer eines Containers als Wert für eine Umgebungsvariable einzugeben. Dies ist am nützlichsten zum Ermöglichen des Middleware - Ebene eine Verbindung mit der Datenbank herzustellen. In diesem Fall spezifiziert die Portnummer muss der interne Port - Nummer zu sein - also nicht den externen Anschluss, der mit dem Behälter zugeordnet ist. Beispiel : {{PostgreSQL | port_5432}} wird dem tatsächlichen externen Port übertragen werden , dass die Middleware - Ebene ermöglichen , eine Verbindung mit der Datenbank herzustellen.
• {{<Image Name> | <Environment Variable Name>}} - können Sie den Wert eines Bildes Umgebungsvariable in ein anderes Bild der Umgebungsvariable einzugeben. Die Anwendungsfälle sind hier endlos - wie die meisten Multi-Tier - Anwendungen Quer Bild Abhängigkeiten haben.

Der eigentliche Bau des Bildes Docker WebLogic kann auch durch DCHQ automatisiert werden. Ein Benutzer kann auf klicken   Image erstellen und klicken Sie dann auf die Schaltfläche +. Ein Benutzer kann ein Bild erstellen entweder mit einem Dockerfile oder eine private / öffentliche GitHub Projekt , das eine Dockerfile hat.

Das Bild , das wir für WebLogic erstellen wurde Radu Dobrinescu das Bild gebaut mit (radudobrinescu / wls12c: 2,0) ( https://hub.docker.com/r/radudobrinescu/wls12c/ ). Wir haben ein paar Änderungen an dem Bild in unserer eigenen Dockerfile und schob dann das neue Bild auf unser eigenes Repository (DCHQ / WebLogic: neueste). Das Gebäude der Bilder kann mit Hilfe eines Cron - Ausdrucks geplant werden. Darüber hinaus kann ein Benutzer verwenden {{Zeitstempel}} im Namen des Tags , um mit jedem neuen Build einzigartigen Tag - Namen zu erstellen. Auf diese Weise ein Benutzer zurück auf ältere Bilder für das Backup wiederherstellen können.

Provisioning & Auto-Skalierung der zugrunde liegenden Infrastruktur auf jeder Cloud

Sobald eine Anwendung gespeichert wird, kann ein Benutzer ein Cloud-Provider registrieren Sie sich auf 13 verschiedene Cloud-Endpunkte, einschließlich vSphere, Openstack, Cloud, Amazon Web Services, Rackspace, Microsoft Azure, DigitalOcean, HP Öffentlichkeit die Bereitstellung und automatische Skalierung von Clustern zu automatisieren Wolke, IBM Softlayer, Google Compute Engine, und viele andere.

Erstens kann ein Benutzer ein Cloud - Provider für Rackspace (zum Beispiel) registrieren , um von der Navigation  Cloud - Anbieter und dann auf dem Anklicken + Taste zur Auswahl von Rackspace . Die Rackspace API Key muss zur Verfügung gestellt werden - die aus dem Kontoeinstellungen Abschnitt der Rackspace Cloud Control Panel abgerufen werden können.

Ein Benutzer kann dann einen Cluster mit einer Auto-Scale - Richtlinie erstellen automatisch neue Cloud - Server zum Hochdrehen. Dies kann durch die Navigation zu erfolgen   Cluster Seite und dann auf dem Anklicken + Taste. Sie können eine kapazitätsorientierte Platzierung Richtlinie auswählen und dann Weave als Netzwerkschicht , um sicher zu erleichtern, passwortgeschützten Quer Container Kommunikation über mehrere Hosts innerhalb eines Clusters.

Ein Benutzer kann jetzt Bestimmung eine Reihe von Cloud - Server auf dem erstellten Cluster neu durch die Navigation in Maschinen und dann auf dem Anklicken + Taste zur Auswahl von Rackspace . Sobald der Cloud - Provider ausgewählt ist, kann ein Benutzer wählen Sie die Region, Größe und Bild benötigt. Ein Cluster wird dann ausgewählt , und die Anzahl der Cloud - Server spezifiziert werden.

Bereitstellen des WebLogic-Cluster mit dem Cloud-Server Rackspace

Sobald die Cloud-Server bereitgestellt werden, kann ein Benutzer eine Multi-Tier-Bereitstellung-Docker basierte Java-Anwendungen, die auf der neuen Cloud-Server. Dies kann durch die Navigation auf der Self-Service-Bibliothek und klicken Sie dann auf Anpassen getan werden, um eine Multi-Tier-Anwendung zu beantragen.

Ein Benutzer kann ein Umwelt-Tag (wie DEV oder QE) auswählen und das Cluster erstellt, bevor sie auf Rackspace Ausführen klicken.

Sobald der WebLogic Cluster bereitgestellt wird, kann ein Benutzer die Admin - Server - Konsole zugreifen , um sicherzustellen , dass die Managed Server entdeckt und ausgeführt wird . Die URL wäre http: // <admin_server_host_ip>: 7001 / console . Die Standard - Anmeldeinformationen würden WebLogic / welcome1 sein.

Bereitstellen der Einkaufswagen, Java WAR-Datei mit dem Plug-In-Rahmen

Sobald der WebLogic Cluster ist und läuft, kann ein Benutzer ein BASH - Skript - Plug-in ausführen eine Java - WAR - Datei auf einem der Server zu implementieren. In diesem Fall aufgerufen wir einfach ein Plug-In den Einkaufswagen - Anwendung auf dem Admin - Server zu implementieren. Von der Aktionen Menü kann ein Benutzer wählen Plug-Ins und dann auf den Container (n) auswählen , auf dem das Plug-in ausgeführt wird. Ein Benutzer kann dann für das Plug-in zu suchen und die Argumente außer Kraft ausgesetzt.

In diesem einfachen Plug-in, du greifen wir drei Dateien von einem entfernten, zugänglichen Server, um die Anwendung zu implementieren.

• deploy.py
• deploy_app.sh
• shoppingcart.war

Hier sind die eigentlichen Dateien verwendet:

deploy.py

---------------------

deploy_app.sh

---------------------

Der Zugriff auf In-Browser-Terminal für den Laufbehälter

Eine Eingabeaufforderung Symbol sollte neben dem Container 'Namen auf der Live-Apps-Seite zur Verfügung. Dies ermöglicht Benutzern, den Container mit Hilfe eines sicheren Kommunikationsprotokolls durch die Agenten-Nachrichtenwarteschlange einzugeben. Eine weiße Liste der Befehle können vom Mieter Admin definiert werden, um sicherzustellen, dass die Nutzer keine schädlichen Änderungen an den Lauf Container zu machen.

In diesem Fall haben wir die Eingabeaufforderung, um sicherzustellen, dass die deploy.py Datei tatsächlich auf den Admin-Server heruntergeladen wurde. Durch eine einfache Katze /oracle/fmwhome/wlst_custom/deploy.py tun - wir waren in der Lage zu überprüfen, ob die Datei auf diesem Container vorhanden ist in der Tat.

Wir zugegriffen dann die Admin-Server-Konsole und navigiert Deployments zu in den Warenkorb Anwendung stellen Sie sicher, war in der Tat zum Einsatz.

Schließlich erreicht man die tatsächliche Anwendung auf http: // <admin_server_host_ip>: 7001 / Warenkorb

Die CPU-Überwachung, Speicher und I / O-Auslastung der Laufbehälter

Sobald die Anwendung in Betrieb ist, überwachen unsere Entwickler die CPU, Speicher, und E / A der laufenden Container Benachrichtigungen zu erhalten, wenn diese Metriken eine vordefinierte Schwelle überschreitet. Dies ist besonders nützlich, wenn unsere Entwickler funktionale Leistungsfähigkeit und Lasttests.

Ein Benutzer kann historische Monitoring Analysen durch und Fragen im Zusammenhang mit Container - Updates korrelieren oder Installationen aufzubauen. Dies kann durch einen Klick auf das getan werden Aktionen Menü der laufenden Anwendung und dann auf Überwachung . Ein benutzerdefinierten Zeitraum kann CPU, Speicher zu lesen und E / A - historisch ausgewählt werden.

Die kontinuierliche Lieferung Aktivieren Workflow mit Jenkins So aktualisieren Sie die WAR-Datei der laufenden Anwendung Wenn A Körperbau ausgelöst wird

Für Entwickler, die die "unveränderliche" Container-Modell zu folgen, indem sie Bilder Docker Wiederaufbau der Anwendungscode und Spinnen neue Container mit jeder Anwendung zu aktualisieren, DCHQ stellt ein automatisiertes Build-Funktion, die es Entwicklern ermöglicht, automatisch erstellen Docker Bilder von Dockerfiles oder private GitHub Projekte, enthaltend Dockerfiles.

Viele Entwickler können jedoch wollen die laufenden Anwendungsserver - Container mit der neuesten Java - WAR - Datei zu aktualisieren , statt. Dafür ermöglicht DCHQ Entwickler eine kontinuierliche Lieferung Workflow mit Jenkins zu ermöglichen. Dies kann durch einen Klick auf das getan werden Aktionen Menü der laufenden Anwendung und wählen Sie dann Continuous Delivery . Ein Benutzer kann eine Jenkins - Instanz auswählen , die bereits mit DCHQ registriert wurde, ist die tatsächliche Job auf Jenkins, die die neueste WAR - Datei, und dann ein BASH - Skript - Plug-in diesem Build zu greifen produzieren und sie auf einem laufenden Anwendungsserver bereitstellen. Sobald diese Richtlinie gespeichert wird, die neueste WAR - Datei von Jenkins jedes Mal , wenn ein Build ausgelöst greifen DCHQ wird und stellen Sie sie auf dem laufenden Anwendungsserver.

Beachten Sie, dass die BASH-Skript-Plug-in kann angepasst werden, um sicherzustellen, dass die richtige Reihenfolge der Schritte für den WebLogic Server genommen wird. Zum Beispiel kann ein Benutzer wünschen, einen bestimmten Einsatzplan zu verwenden, oder einige Skripte vor un-entfalte laufen und dann die neue WAR-Datei bereitstellen.

Entwickler als Ergebnis haben immer die neueste Java-WAR-Datei auf ihre laufenden Container in DEV / TEST Umgebungen eingesetzt.

Schlussfolgerung

Enterprise-Java-Anwendungen containerizing ist nach wie vor eine Herausforderung, vor allem, weil bestehende Anwendung Zusammensetzung Rahmenbedingungen befassen sich nicht mit komplexen Abhängigkeiten, externe Integrationen oder automatische Skalierung Workflows post-Bereitstellung. Außerdem bedeutete die ephemeren Design von Behältern, dass die Entwickler neue Behälter zu drehen musste und neu zu erstellen, die komplexen Abhängigkeiten und externe Integration mit jeder Version zu aktualisieren.

DCHQ, in gehosteten und On-Premise-Versionen adressiert all diese Herausforderungen und vereinfacht die Containerisierung von Enterprise-Java-Anwendungen über eine vorzeitige Anwendung Zusammensetzung Framework, das Cross-Bild-Umgebungsvariable Bindungen, erweiterbare BASH-Skript-Plug-Ins ermöglicht, die bei aufgerufen werden kann fordern Zeit oder nach der Bereitstellung und Anwendungs-Clustering für Hochverfügbarkeit über mehrere Hosts oder Regionen mit Unterstützung für automatische Skalierung.

Melden Sie sich kostenlos auf http://DCHQ.io oder herunterladen DCHQ On-Pemise

Zugang zu den Out-of-Box Multi-Tier-Java-Anwendungsvorlagen zusammen mit Application-Lifecycle-Management-Funktionalität wie Überwachung, Container-Updates, Skala in / out und kontinuierliche Lieferung zu erhalten.