Docker Java Application Mit Solr, Mongo, & Cassandra: Planung, Bereitstellung, Service Discovery, und Management in Produktion
Sie können diese Probe "Namensverzeichnis" Java-Anwendung von GitHub klonen.
Eine Schritt für Schritt Anleitung für Dockerizing und eine Java-Anwendung verwalten, bestehend aus:
- Apache HTTP Server (httpd) und Nginx ( für den Lastausgleich )
- JBoss , Tomcat und Jetty ( als Anwendungsserver )
- Solr ( für die Volltextsuche )
- Mongo , Cassandra , MySQL und Oracle ( für die Datenbank )
Dies ist Erweiterung dieses Projekts xtension dieses Projekts ( https://github.com/dchqinc/dchq-docker-java-example ). Die Anwendung unterstützt jetzt Solr für Volltextsuche und sowohl Mongo & Cassandra als die unterstützten Datenbanken.
Zum Ausführen von & die Verwaltung 24 Java - Anwendungsvorlagen in diesem Projekt auf 13 verschiedenen Wolken und Virtualisierungsplattformen (einschließlich vSphere, Openstack, AWS, Rackspace, Microsoft Azure, Google Compute Engine, DigitalOcean, IBM Softlayer, etc.), stellen Sie sicher , dass Sie entweder :
- Herunterladen DCHQ On-Premise Standard Edition kostenlos - http://dchq.co/dchq-on-premise-download.html
Hintergrund
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 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 die CPU, Speicher überwachen und I / O der Laufbehälter, erhalten Benachrichtigungen und Alarme, und Zugriff auf Anwendungssicherungen, automatische Waage in / out-Workflows zu bekommen, und Plug-in-Ausführung Workflows aktualisieren Container ausgeführt wird. 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 früheren Blogs haben wir gezeigt , die End-to-End - Bereitstellung Automatisierung verschiedener Java - Anwendungen (wie Pizza Shop - und Film - Store - Anwendungen) auf Multi-Tier - Docker-basierte Anwendungs - Stacks über 13 verschiedene Wolken und Virtualisierungsplattformen. Eine vollständige Auflistung dieser Blogs, können Sie diese Seite besuchen: http://dchq.co/docker-java-applications.html
Doch viele Anwender wurden auf einige der grundlegenden Aspekte der Anwendungsmodellierung immer noch verwirrt. Diese Fragen sind:
- Wo diese Umgebungsvariablen kommen in Ihrem YAML-basierten Anwendungsvorlage?
- Wie wird die Datenbank mit den entsprechenden Schemata initialisiert benötigt von meiner Java - Anwendung?
- Ich habe bereits ein Einsatzplan für meine WebLogic Application Server. Kann ich mein eigenes Skript ausführen eine Java - Anwendung für die Bereitstellung?
Um diese Fragen zu beantworten, haben wir eine Probe "Namensverzeichnis" Java-Anwendung in diesem GitHub Projekt, das auf diesen Anwendungsstapel eingesetzt werden können:
- Apache HTTP Server (httpd) und Nginx (für den Lastausgleich)
- JBoss, Tomcat und Jetty (als Anwendungsserver)
- Solr (für die Volltextsuche)
- Mongo, Cassandra, MySQL und Oracle (für die Datenbank)
In diesem Projekt werden wir einen Schritt-für-Schritt-Anleitung für die Konfiguration, Bereitstellung und Verwaltung dieser Java-Anwendung mit verschiedenen Anwendungs-Stacks und auf verschiedenen Cloud / virtuellen Infrastruktur.
Wir behandeln:
- Konfigurieren der Java-Dateien für Datenbank- und Solr Verbindung Umgebungsvariablen
- Mit der liquibase-Bean der angeschlossenen Datenbank zu initialisieren
- Der Bau der YAML-basierten Anwendungsvorlagen, die wiederverwendet kann auf jedem Linux-Host überall läuft
- Provisioning & automatische Skalierung der zugrunde liegenden Infrastruktur auf jeder Cloud (mit Rackspace das Beispiel in diesem Blog zu sein)
- Bereitstellen der Multi-Tier-Java-Anwendung auf dem Cluster-Rackspace
- Die Überwachung der CPU, Speicher und I / O der Laufbehälter
- die kontinuierliche Lieferung Workflow-mit Jenkins Aktivieren der WAR-Datei der laufenden Anwendungen zu aktualisieren, wenn ein Build ausgelöst wird
- Skalierung über das Application Server-Cluster, wenn die Anwendung mit begrenzten Ressourcen der Service Discovery Rahmen mit der Load-Balancing-Dienst zu aktualisieren
Konfigurieren des Java-Dateien für Datenbank- und Solr Anschluss Umgebungsvariablen
Sie können diese Probe "Namensverzeichnis" Java-Anwendung von GitHub klonen.
Dies ist der wichtigste Schritt in "Dockerizing" Ihre Java-Anwendung. Um die Umgebungsvariablen zu nutzen Sie passieren kann, wenn die Behälter läuft, müssen Sie sicherstellen, dass Ihre Anwendung in einer Weise konfiguriert ist, das Ihnen erlaubt, bestimmte Eigenschaften auf Anfrage zeit zu ändern - wie:
- Die Solr URL & Port möchten Sie verwenden
- Der Datenbanktreiber möchten Sie verwenden
- Die Datenbank-URL
- Die Datenbank-Anmeldeinformationen
- Alle anderen Parameter, die Sie möchten, dass zum Zeitpunkt der Anforderung zu ändern (zB min / max Anschluss Poolgröße, Leerlaufzeit, etc.)
Um dies zu erreichen, haben wir mehrere Java-Dateien, die Umgebungsvariablen zu erklären, müssen wir mit der Datenbank verwenden und Solr zu verbinden. Die Java-Dateien können im Verzeichnis config zu finden:
Lassen Sie uns zuerst examine SolrConfig.java : https://github.com/dchqinc/dchq-docker-java-solr-mongo-cassandra-example/blob/master/src/main/java/dchq/dbconnect/config/SolrConfig.java
Sie werden feststellen , dass solr_host und solr_port werden als Umgebungsvariablen erklärt , die Sie passieren kann , wenn der Anwendungsserver - Container ausgeführt wird .
Jetzt lass uns examine DatabaseConfig.java : https://github.com/dchqinc/dchq-docker-java-solr-mongo-cassandra-example/blob/master/src/main/java/dchq/dbconnect/config/DatabaseConfig.java
Sie werden feststellen , dass database_driverClassName , database_url , Datenbank - und database_password werden als Umgebungsvariablen erklärt , die Sie passieren kann , wenn der Anwendungsserver - Container ausgeführt wird . Diese werden verwendet , MySQL, PostgreSQL und Oracle - Datenbanken zu verbinden.
Als nächstes werden wir examine MongoConfig.java : https://github.com/dchqinc/dchq-docker-java-solr-mongo-cassandra-example/blob/master/src/main/java/dchq/dbconnect/config/MongoConfig.java
Sie werden feststellen , dass mongo_url als Umgebungsvariablen deklariert ist , dass Sie passieren kann , wenn der Anwendungsserver - Container ausgeführt wird .
Doch die MongoConfig.java wird auch zum Auffüllen der Datenbank mit dem richtigen Schema & Tabelle beim Start verwendet - wenn diese Tabelle nicht bereits gefunden.
Schließlich werden wir examine CassandraConfig.java : https://github.com/dchqinc/dchq-docker-java-solr-mongo-cassandra-example/blob/master/src/main/java/dchq/dbconnect/config/CassandraConfig.java
Sie werden feststellen , dass cassandra_url als Umgebungsvariablen deklariert ist , dass Sie passieren kann , wenn der Anwendungsserver - Container ausgeführt wird .
Verwenden der Liquibase Bean an die angeschlossenen MySQL, PostgreSQL und Oracle-Datenbanken initialisieren
Normalerweise empfehlen wir das Datenbankschema als Teil der Bereitstellung Java-Anwendung initialisiert sich. Auf diese Weise müssen Sie sich nicht um die Aufrechterhaltung separate SQL-Dateien kümmern, die separat auf der Datenbank ausgeführt werden müssen.
Wenn Sie jedoch bereits diese SQL - Dateien haben und Sie immer noch lieber , sie auf der Datenbank separat ausgeführt wird - dann kann DCHQ helfen, diesen Prozess durch seine Plug-in - Rahmen zu automatisieren. Sie können auf diese verweisen Abschnitt für weitere Informationen.
Initialisieren der Mongo und Cassandra Datenbanken in den MongoConfig.java und CassandraConfig.java Dateien abgedeckt.
Für MySQL, PostgreSQL und Oracle, die Liquibase ist Bean in der DatabaseConfig.java Datei verwendet , um die Datenquelle zu überprüfen und SQL - Anweisungen von upgrade.sql laufen. Liquibase Spuren , die Changelog - Anweisungen für jede Datenbank ausgeführt haben.
Hier ist die eigentliche upgrade.sql Datei mit den SQL-Anweisungen für die Initialisierung des Schemas auf dem angeschlossenen MySQL, PostgreSQL oder Oracle-Datenbank.
Der Aufbau des YAML-basierte Anwendungsvorlagen, die überall wiederverwendet werden kann auf jedem Linux-Host ausgeführt wird
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 erstellt 24 Anwendungsvorlagen , die unter Verwendung von offiziellen Bilder von Docker Hub für die gleiche "Namensverzeichnis" Java - Anwendung - aber für verschiedene Anwendungsserver und Datenbanken.
Die Vorlagen sind Beispiele für die folgenden Anwendungsstapel (für die gleiche Java-Anwendung):
- Apache HTTP Server (httpd) & Nginx - für den Lastausgleich
- Solr - für die Volltextsuche
- Tomcat, Jetty und JBoss - für die Anwendungsserver
- Mongo, Cassandra, MySQL und Oracle XE - für die Datenbanken
Plug-Ins auf Web-Server und Anwendungsserver zum Zeitpunkt der Anforderung Konfigurieren & Post-Provision
Über all diesen Anwendungsvorlagen, werden Sie feststellen, dass einige der Behälter zum Zeitpunkt der Anforderung, um BASH-Skript-Plug-Ins aufrufen, den Behälter zu konfigurieren. Diese Plug-Ins können post-Bereitstellung als auch ausgeführt werden.
Diese Plug-Ins können durch Navigation erstellt werden , um Plug-Ins . Sobald die BASH - Skript zur Verfügung gestellt wird, wird das DCHQ Agent dieses Skript ausführen innerhalb des Behälters . Ein Benutzer kann Argumente angeben , die zum Zeitpunkt der Anforderung und nach Bestimmung außer Kraft gesetzt werden kann. Alles , was von der voran $ Zeichen ist ein Argument betrachtet - zum Beispiel $ file_url kann ein Argument sein , die Entwickler die Download - URL für eine WAR - Datei angeben können. Dies kann zum Zeitpunkt der Anforderung und nach Bestimmung außer Kraft gesetzt werden , wenn ein Benutzer das Java - WAR - Datei auf einem laufenden Container zu aktualisieren.
Das Plug-in-ID muss zur Verfügung gestellt werden, wenn die YAML-basierte Anwendungsvorlage definieren. Um zum Beispiel ein BASH-Skript-Plug-in für Nginx aufzurufen, würden wir die Plug-in-ID Referenz wie folgt:
In den Beispielvorlagen werden den Aufruf wir 4 BASH-Skript-Plug-Ins.
Nginx ist Aufrufen eines BASH - Skript - Plug-in , das IP - Containers der Anwendungsserver in der default.conf - Datei (oder zum Zeitpunkt der Anforderung) dynamisch einspritzt. Das Plug-in - ID ist 0H1Nk .
Apache HTTP Server (httpd) aufruft eine BASH - Skript - Plug-in , dass injiziert Behälter IP der Anwendungsserver in der Datei httpd.conf dynamisch (oder zum Zeitpunkt der Anforderung). Das Plug-in - ID ist uazUi .
Die Schönheit der Nginx und Apache HTTP Server (httpd) Plug-Ins ist , dass sie nach der Bestimmung im Rahmen des Application Server - Cluster - Skala in oder skalieren ausgeführt werden können. Dies ermöglicht es , automatisch angelegte Politik zu definieren, die den Web - Server (oder Lastenausgleich) automatisch aktualisiert. Dies ist Teil des DCHQ des Service Discovery - Framework.
Service Discovery Mit Plug-In Lebenszyklusstadien
Der Lifecycle - Parameter in Plug-Ins können Sie die genaue Bühne oder ein Ereignis geben Sie den Plug-in auszuführen. Wenn nicht - Lebenszyklus angegeben wird, standardmäßig wird das Plug-in ausführen werden on_create . Hier sind die unterstützten Lebenszyklusphasen:
- on_create - führt das Plug-in , wenn der Behälter zu schaffen
- on_start - führt das Plug-in nach ein Behälter beginnt
- on_stop - führt das Plug-in vor einem Behälter Anschläge
- on_destroy - führt das Plug-in vor , einen Behälter zu zerstören
- post_create - führt das Plug-in , nachdem der Behälter erstellt und ausgeführt wird
- post_start [: Knoten] - führt das Plug-in nach dem anderen Behälter beginnt
- post_stop [: Knoten] - führt das Plug-in nach dem anderen Behälter Anschläge
- post_destroy [: Knoten] - führt das Plug-in nach dem anderen Behälter zerstört wird
- post_scale_out [: Knoten] - führt das Plug-in nach dem anderen Cluster von Containern wird skaliert
- post_scale_in [: Knoten] - führt das Plug-in nach dem anderen Cluster von Containern in skaliert
Um Zugriff auf die Nginx und Apache HTTP Server erhalten (httpd) Plug-Ins unter dem EULA Lizenz, stellen Sie sicher, dass Sie entweder:
- Herunterladen DCHQ On-Premise Standard Edition kostenlos - http://dchq.co/dchq-on-premise-download.html
Die Anwendungsserver (Tomcat, Jetty und JBoss) berufen sich auch ein BASH-Skript-Plug-in die Java-WAR-Datei von der zugänglichen GitHub URL zu implementieren.
Tomcat, JBoss und Jetty sind exakt die gleichen BASH - Skript - Plug-in (Plug-in - ID: Aufruf oncXN ) - mit Ausnahme der WAR - Datei wird auf verschiedenen Verzeichnissen eingesetzt zu werden :
- Tomcat - dir = / usr / local / tomcat / webapps / ROOT.war
- Jetty - dir = / var / lib / Jetty / webapps / ROOT.war
- JBoss - dir = / opt / jboss / Wildfly / Standalone / Installationen / ROOT.war
Solr ist eine andere BASH - Skript - Plug-in aufrufen (Plug-in - ID: doX8s ), die die names.zip Datei bekommen und entpacken Sie es in / opt / Solr / server / Solr /
Parameter CLUSTER_SIZE Und Host für HA-Bereitstellung über mehrere Hosts
Sie werden feststellen , dass der CLUSTER_SIZE Parameter können Sie die Anzahl der Container angeben zu starten (mit den gleichen Anwendungsabhängigkeiten).
Der Host - Parameter können Sie den Host an Sie für Container - Implementierungen verwenden möchten. Dies ist möglich , wenn Sie ausgewählt haben , Weave als Netzwerkschicht , wenn Ihr Cluster zu schaffen. 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. - kann der Benutzer die tatsächliche IP - Adressen angeben , für Behälter 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 ,
Environment Variable Bindings Über Bilder
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 mehrere Bindungen gemacht - einschließlich database_url = jdbc: mysql: // {{MySQL | container_hostname}}: 3306 / {{MySQL | MYSQL_DATABASE}} - bei dem der Datenbank-Container Name wird dynamisch zum Zeitpunkt der Anforderung gelöst und wird verwendet, um sicherzustellen, dass die Anwendungsserver, eine Verbindung mit der Datenbank herstellen.
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 Namen 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 | 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.
Hier sind vier Beispiele. Sie können finden anpassen und alle 24 Vorlagen selbst zu betreiben.
Multi-Tier Java (Nginx-Tomcat-Solr-Mongo)
Multi-Tier Java (Nginx-JBoss-Solr-Oracle-XE)
Multi-Tier Java (ApacheLB-Tomcat-Solr-Cassandra)
Multi-Tier Java (ApacheLB-Jetty-Solr-Mongo)
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 12 verschiedene Cloud-Endpunkte, einschließlich VMware vSphere, Openstack, Cloud, Amazon Web Services, Rackspace, Microsoft Azure, DigitalOcean, IBM die Bereitstellung und automatische Skalierung von Clustern zu automatisieren 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. Die Auto-Scale - Politik kann beispielsweise die maximale Anzahl von VMs (oder Cloud - Server) auf 10 festgelegt.
Ein Benutzer kann jetzt Bestimmung eine Reihe von Cloud-Server auf der neu erstellten Cluster entweder über den UI-basierten Workflow oder durch ein einfaches YAML-basierten Maschine Compose Vorlage definieren, die von der Self-Service-Bibliothek angefordert werden kann.
UI-basierte Workflow - Ein Benutzer kann durch Navigieren zu Rackspace Cloud Server anfordern 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. Ports sind standardmäßig auf Rackspace Cloud Server geöffnet einige der Port - Anforderungen (zB 32.000-59.000 für Dockarbeiter, 6783 für Weave und 5672 für RabbitMQ) gerecht zu werden . Ein Cluster wird dann ausgewählt , und die Anzahl der Cloud - Server spezifiziert werden.
YAML-basierte Maschine Compose Vorlage - Ein Benutzer kann zunächst eine Maschine Compose Vorlage für Rackspace erstellen , indem Sie auf die Navigation Maschinen und klicken Sie auf die + Taste, wählen Sie dann die Maschine Compose .
Hier ist die Vorlage, um ein 4 GB Cloud Server für Ihr Interesse.
Die Parameter, die für die Maschine Compose Vorlage werden im Folgenden zusammengefasst:
- Beschreibung : Beschreibung der Plan / template
- instanceType : Cloud - Provider bestimmten Wert (zB general1-4)
- Region : Cloud - Anbieter bestimmten Wert (zB IAD)
- Bild : Verpflichtend - vollständig qualifizierte Bild ID / Name (zB IAD / 5ed162cc-b4eb-4371-b24a-a0ae73376c73 oder vSphere VM Template Name)
- Benutzername : Optional - nur für vSphere VM Template Benutzername
- Kennwort : Optional - nur für vSphere VM Template verschlüsselte Passwort. Sie können das Passwort mit dem Endpunkt verschlüsseln https://www.dchq.io/#/encrypt
- Netzwerk : Optional - Cloud - Provider bestimmten Wert (zB Standard)
- Security : Cloud - Provider bestimmten Wert (zB DCHQ-security-Gruppe)
- KeyPair : Cloud - Provider bestimmten Wert (zB privater Schlüssel)
- Openports : Optional - durch Komma getrennte Portwerte
- zählen : gesamte Anzahl der VMs, standardmäßig 1.
Sobald die Maschine Compose Vorlage gespeichert wird, kann ein Benutzer dieses Gerät aus der Self-Service anfordern Bibliothek . Ein Benutzer kann klicken anpassen und dann die Auswahl Cloud - Anbieter und Cluster für die Bereitstellung von Cloud - Server diese Rackspace zu verwenden.
Bereitstellen der Multi-Tier Java-Anwendung auf dem Cluster 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 klicken Maschinen erstellen .
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.
Für die Tomcat-Bereitstellung zum Beispiel, haben wir die Eingabeaufforderung, um sicherzustellen, dass die Java-WAR-Datei im Verzeichnis / usr / local / tomcat / webapps / Verzeichnis bereitgestellt wurde.
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.
Entwickler als Ergebnis haben immer die neueste Java-WAR-Datei auf ihre laufenden Container in DEV / TEST Umgebungen eingesetzt.
Skalieren von den Tomcat Application Server-Cluster und Hebelwirkung Der Service Discovery Framework Der Load Balancer aktualisieren
Wenn die laufende Anwendung Ressource eingeschränkt wird, kann ein Benutzer die Anwendung zu skalieren, um die zunehmende Belastung gerecht zu werden. Darüber hinaus kann ein Benutzer die Skala während der Geschäftszeiten zu planen und die Waage in den Wochenenden zum Beispiel.
Um den Cluster von Tomcat - Server von 1 bis 2 skalieren, kann ein Benutzer klicken Sie auf den Aktionen Menü der laufenden Anwendung und wählen Sie dann Scale - Out . Ein Benutzer kann dann geben Sie die neue Größe für den Cluster und klicken Sie dann auf Jetzt ausführen .
Da die Skala aus ausgeführt wird, wird der Service Discovery Rahmen der Lastenausgleichs zu aktualisieren verwendet werden. Ein Plug-in wird automatisch auf Apache HTTP - Server ausgeführt werden , Apache HTTP Server httpd.conf - Datei zu aktualisieren , so dass sie von dem neuen Anwendungsserver hinzugefügt bewusst ist. Das ist , weil wir festgelegt haben post_scale_out: AppServer als Lifecycle - Ereignis für dieses Plugin.
Eine Anwendung Zeitlinie zur Verfügung steht jede Änderung an der Anwendung für die Prüfung und Diagnose gemacht zu verfolgen. Dies kann aus dem expandierbaren Menü am unteren Rand der Seite einer laufenden Anwendung zugegriffen werden. In diesem Fall ausgeführte Service Discovery Rahmen des Apache HTTP - Server - Plugin automatisch direkt nach dem Cluster Application Server wurde skaliert.
Warnungen und Hinweise sind für, wenn Behälter oder Hosts sind oder wenn die CPU & Speicher Nutzung entweder auf Hosts oder Behälter einen definierten Schwellenwert überschreitet.
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.
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.
No comments:
Post a Comment