62 Juli 2013 www.it-administrator.de P R A X I S I W o r k s h o p
ava EE stellt eine Plattform auf Ba- sis diverser Softwarekomponenten und Diensten zur Verfügung und bildet neben dem .NET-Framework von Mi- crosoft den de-facto Standard in Sachen Enterprise-Anwendungen. Durch klar de- finierte APIs können dabei Komponenten unterschiedlicher Hersteller problemlos miteinander agieren. Jede Java EE-basierte Anwendung benötigt natürlich eine ent- sprechende Umgebung, in der diese ab- laufen kann und die die notwendigen Komponenten und Services zur Verfügung stellt, beispielsweise Transaktionsmanage- ment, Namens- und Verzeichnisdienste, Persistenz- und Deployment-Dienste so- wie ein Sicherheits-Framework. Eine voll- ständige Liste aller bei JAVA EE 6 einge- setzten Technologien findet sich in der Java EE-Spezifikation [1]. Der JBoss Ap- plikationsserver 7.1 (JBAS) erfüllt dabei alle Anforderungen, die im “Java Enter- prise Edition 6 Full Profile” definiert sind.
Von den Wurzeln zur Version 7 JBoss wurde Ende der 90er-Jahre als reiner EJB-Container von Marc Fleury entwi- ckelt. Dank steigender Popularität und
Verbreitung des Servers wurde dieser durch die JBoss-Commu- nity immer weiter ausgebaut und erweitert, so dass schließlich mit Version AS3 ein vollwertiger JEE-Server entstand.
2004 gründete Fleury schließlich die Fir- ma “JBoss” um professionelle Consulting- und Trainingsangebote rund um JBoss an- bieten zu können. 2006 wurde das Un- ternehmen dann vom Linux-Distributor Red Hat übernommen. Dieser vertreibt den Server im kostenpflichten Subskrip- tions-Modell mit dazugehörigem Support als Enterprise Application Platform (EAP) [2]. Das Upstream-Projekt JBoss AS exis- tiert natürlich weiterhin und die meiste Entwicklungsarbeit findet hier statt. Die Community-Version steht jedermann un- ter [3] zur Verfügung.
Die ersten Versionen von JBoss basierten auf einem sogenannten Java-Management- Extension Kernel (JMX). Sämtliche Ser- vices des Anwendungsservers wurden hier als Managed Beans (MBeans) in den JMX-Kernel geladen um Ihre Funktionen zur Verfügung zu stellen. Mit der Version AS4 begann dann die Migration auf eine Microkernel-Architektur, in der leichtge- wichtige Plain Old Java Objects (POJOs) statt MBeans zum Einsatz kamen. Die ak-
tuelle AS7-Architektur setzt sich aus ei- nem Core Service-Container auf Basis von modularen JBoss-Klassen und einer Vielzahl von Erweiterungen zusammen.
Die meisten Funktionen die der Appli- kationsserver den Anwendern zur Verfü- gung stellt, werden durch Erweiterungen zum Core Service-Container realisiert.
Der aktuelle JBoss AS7 startet nun bis zu 10 mal schneller als seine Vorgängerver- sionen, da die zum Betrieb notwendigen Komponenten nun parallel gestartet wer- den. Ein weiterer Grund für den schnel- leren Systemstart besteht darin, dass Kom- ponenten, die erst zu einem späteren Zeitpunkt benötigt werden, erst dann ge- laden werden. Auch die Konfiguration hat sich bedeutend vereinfacht: Waren die al- ten Konfigurationsdateien recht umständ- lich und mit unnötigem Ballast versehen,
J
Installation und Konfiguration von JBoss 7
Der Boss ist zurück!
von Thorsten Scherf JBoss ist im Open Source-Umfeld der weitver- breitetste Applikationsserver auf Basis der Java EE-Plattform. Der Server entspricht den Java Enterprise Edition 6-Spezifikationen und liegt
seit kurzem in der Version 7 vor. Diese bietet neben einem massiv beschleunigten System- start eine deutlich vereinfachte Konfiguration und Wege zur zentralen Administration in einer Multi-Server-Topologie. Dieser Work- shop zeigt die Administration des Servers und stellt an praktischen Beispielen die
gängigsten Konfigurationen vor.
Das JBoss Application Server-Projekt wurde Ende 2012 umbenannt. Alle neuen Versionen des Application Ser- ver hören nun auf den Namen Wildfly. Die im Artikel besprochene Version 7 ist hiervon nicht betroffen, die- se Version ist immer noch unter dem Namen JBoss AS verfügbar. Eine nähere Beschreibung und Informatio- nen zu der Namensänderung finden Sie unter [4].
Namensverwirrung vermeiden
Quelle:in domercy–
123RF
www.it-administrator.de Juli 2013 63 so findet die nahezu komplette Konfigu-
ration des Servers nun über die Datei stan- dalone.xml statt.
Den neuen Domain-Mode konfiguriert der IT-Verantwortliche über die Dateien domain.xml und host.xml. Dieser Modus er- möglicht dabei ein Management von meh- reren JBAS-Instanzen in einer Multi- Server-Topologie. Eine Konfigurationsän- derung erfolgt auf dem Domänencontroller und wird im Anschluss an alle Mitglieder der Domäne verteilt. Dies vereinfacht das Management der einzelnen Server-Instan- zen ungemein. Die Konfiguration selbst kann dabei über das benutzerfreundliche Webportal erfolgen, auch als Management Console bezeichnet. Alternativ lässt sich der Server über ein neues Kommandozei- len-Werkzeug (CLI) administrieren.
Installation im
Standalone- oder Domain-Modus Da JBAS neben dem RPM-Format für Linux-Systeme auch im ZIP-Format vor- liegt, können Sie ihn auf nahezu jedem beliebigen System installieren. Dieser Workshop basiert auf einer JBoss AS In-
stallation unter Fedora. Somit kommen zur Konfiguration die zur Verfügung gestellten Shell-Skripte zum Einsatz. Bei einer In- stallation unter Windows müssen Sie die entsprechenden Batch-Skripte einsetzen.
Nach dem Entpacken des ZIP-Archives sollten Sie zwei Punkte sicherstellen: Zum einen muss die JAVA_HOME-Variable auf die lokale Java-Installation zeigen und zum anderen müssen Sie einen erster Benutzer einrichten, der zum Management des Ser- vers dient. Das Anlegen des Benutzers er- folgt entweder über ein Shell- oder Batch- Skript aus dem bin-Ordner des Archives:
# $JBOSS_HOME/bin/add-user.sh
What type of user do you wish to add?
a) Management User (mgmt- users.properties)
b) Application User (application- users.properties)
Im dem bereits erwähnten bin-Ordner lie- gen eine Reihe weiterer Skripte, beispiels- weise zum Starten und Stoppen des Ser- vers im Standalone- und Domain-Modus.
Daneben existieren noch weitere wichtige Ordner. Beispielsweise enthält der Ordner
“modules” sämtliche Java-Bibliotheken aus denen sich die einzelnen Komponenten des Servers zusammensetzen. Im Ordner
“welcome-content” liegt die Webseite, die beim Zugriff auf den Server über den
Standard-Port 8080 angezeigt wird. Auf produktiven JBAS-Installationen sollten Sie diese Funktion abschalten oder zu- mindest den Zugriff einschränken.
Neben diesen globalen Verzeichnissen, existieren dann natürlich noch die beiden Unterordner “standalone” und “domain”.
Diese enthalten die Konfigurationen für den Betrieb des Applikationsservers im Standalone- oder Domain-Modus. Der Standalone-Modus verwendet den Ord- ner “deployments” für das Deployment von Applikationen. Im domain-Verzeich- nis findet sich dieser Ordner nicht, da das Deployment von Applikationen hier auf sogenannten Server-Groups stattfin- det. Diese Server-Groups setzen sich dann aus einzelnen Servern zusammen, die auf unterschiedlichen JBAS-Instanzen laufen können.
Konfiguration im Standalone-Modus
Der Standalone-Modus hat im Vergleich zum Domain-Modus keine echten Nachteile. Sämtliche JBoss-Komponen- ten stehen auch hier zur Verfügung und können als Subsysteme durch die Aus- wahl eines geeigneten Profiles aktiviert werden. Der einzige Unterschied zum Domain-Modus besteht in der Art und Weise, wie die einzelnen JBoss-Instanzen zu konfigurieren sind. Im Domain-Mo- dus erfolgt die Konfiguration zentral, im Standalone-Modus sind die Instanzen je- Bild 1: Die Ordnerstruktur des
JBoss-Servers im Standalone-Mode...
Bild 2: ... und im im Domain-Mode
Bild 3: Properties lassen sich über die JBoss Management Console dauerhaft in der Konfigurationsdatei des Servers speichern. Diese müssen dann nicht bei jedem Serverstart mit angegeben werden.
64 Juli 2013 www.it-administrator.de P R A X I S I W o r k s h o p
weils einzeln zu konfigurieren, falls meh- rere Einzelinstanzen existieren.
Um nun die erste JBoss-Instanz im Stan- dalone-Modus zu starten, rufen Sie das entsprechende Skript aus dem bin-Ordner auf. Geben Sie dabei kein Profil an, so kommt das default-Profil zum Einsatz.
Ansonsten bietet das Startskript über die Option “-c” die Möglichkeit, ein alterna- tives Profil aus dem Konfigurationsordner zu verwenden.
Parameter müssen Sie entweder direkt in der jeweiligen Konfigurationsdatei ändern oder Sie geben diese über sogenannte Properties beim Starten des Servers an.
Alternativ besteht die Möglichkeit, eine eigene Properties-Datei zu erstellen und diese mit allen gewünschten Werten zu versehen und dem Server beim Start mit- zugeben. Ein beispielhafter Aufruf des Servers, um diesen an ein bestimmtes Management-Interface zu binden, sieht wie folgt aus:
# $JBOSS_HOME/bin/standalone.sh -Djboss.bind.address.management=
192.168.0.100
Auf der Konsole sehen Sie nun die Start- meldungen der einzelnen Services und am Ende sollte schließlich eine Statuszeile Auskunft darüber erteilen, wie lange die Startup-Prozedur dauerte:
05:38:02,957 INFO [org.jboss.as]
(Controller Boot Thread)
JBAS015874: JBoss AS 7.1.1.Final
“Brontes” started in 1840ms - Started 133 of 208 services (74 services are passive or on-demand) Nach einem erfolgreichen Login in die Management-Konsole (der Zugriff erfolgt über den Port 9990) des Servers, gliedert sich diese in zwei Bereiche. Zum einen stehen über den Reiter “Runtime” die aktuellen Laufzeit-Informationen zur Ver- fügung. Unter dem Reiter “Profile” sind die Einstellungen der einzelnen Subsys- teme aus dem aktuell verwendeten Profil sichtbar und können an dieser Stelle auch verändert werden.
Eine Webanwendung veröffentlichen
Nachdem der JBoss-Server nun grundle- gend für den Standalone-Betrieb konfi- guriert ist, soll natürlich auch die erste Webanwendung ausgerollt werden. Dazu nutzen wir in diesem Workshop die be- liebte “Hello-World”-Beispielanwendung.
Das folgende Listing zeigt die kleine JSP- Datei, die Sie am besten im Ordner “hel- loworld” ablegen:
<!DOCTYPE HTML>
<html>
<head>
<title>IT Administrator</title>
<%! String message = “Hello, World.”; %>
</head>
<body>
<h2><%= message%></h2>
<%= new java.util.Date() %>
</body>
</html>
In einem Unterordner “WEB-INF” er- stellen Sie dann noch einen passenden Deployment-Deskriptor, damit die An- wendung auch als Webarchiv ausgerollt werden kann. Mit Hilfe des Tools “jar”
lässt sich aus diesen Dateien nun ein WAR-Archiv erstellen:
# jar cvf hello.war hello.jsp WEB-INF/
added manifest
adding: hello.jsp(in = 206) (out= 148)(deflated 28%) adding: WEB-INF/(in = 0)
(out= 0)(stored 0%)
adding: WEB-INF/web.xml(in = 65) (out= 47)(deflated 27%)
Um die Webanwendung nun auf dem Server bereit zu stellen, haben Sie meh- rere Möglichkeiten: Die sicherlich ein- fachste Variante besteht darin, das zuvor erstellte WAR-Archiv in das Deploy- ment-Verzeichnis des JBoss-Installations- verzeichnis zu kopieren. JBoss nimmt in diesem Falle sofort Notiz von der neuen Web-Anwendung und veröffentlicht die- se unmittelbar. Natürlich bietet auch die Management-Konsole die Möglichkeit, Webanwendungen bequem auf dem Ser- ver auszurollen. Hier müssen Sie jedoch nach dem Upload der Anwendung daran denken, diese noch zu aktivieren.
Schliesslich besteht die Möglichkeit, die Anwendung mittels des neuen Kom- mandozeilen-Werkzeugs “jboss-cli” auf dem Server bereitzustellen. Hierfür stel- len Sie zuerst eine Verbindung zum ge- wünschten Server her, bevor Sie mittels Bild 4: Das Bereitstellen einer Webanwendung über die JBoss Management-Console
gestaltet sich sehr einfach und bequem
JBoss AS7 bietet unterschiedliche Startprofile an. Die- se legen fest, welche JBoss-Subsysteme jeweils ge- startet werden. Im Standalone-Modus existiert für je- des Profil eine eigene Konfigurationsdatei, im Domain-Modus erfolgt die Zuweisung des gewünsch- ten Profils auf Servergruppen-Ebene.
Das Default-Profil umfasst: logging, configadmin, se- curity, datasources, infinispan, jpa, webservices, ee, ejb, transactions und mail. Das Full-Profile enthält alle Subsysteme des Default-Profils plus cmp, jacorb, jaxr und messaging.
Im HA-Profil finden sich alle Subsysteme des Default- Profils plus jgroups und modcluster. Das Full-HA-Profil beinhaltet darüber hinaus noch jgroups und modcluster.
Übersicht der Startprofile
Worüber
Administratoren morgen reden
Sichern Sie sich den E-Mail-Newsletter des
IT-Administrators und erhalten Sie Woche für
Woche die
> neuesten TIPPS & TRICKS
> praktischsten TOOLS
> interessantesten WEBSITES
> unterhaltsamsten GOODIES
sowie einmal im Monat die Vorschau auf die kommende Ausgabe des
IT-Administrators!
Jetzt einfach und kostenlos bestellen unter:
www.it-administrator.de/newsletter
www.it-administrator.de -connect
[standalone@localhost:9999 /] deploy /opt/jboss-as-7.1.1.Final/hello/
hello.war
Unabhängig von der verwendeten Me- thode sollte der Server die bereitgestellte Anwendung mit der folgenden (oder zu- mindest ähnlichen) Meldung bestätigen:
05:39:18,060 INFO [org.jboss.as.
repository] (management-handler- thread - 3) JBAS014900: Content added at location /opt/jboss-as- 7.1.1.Final/standalone/data/con- tent/24/738f47415959cb6ff911750599 705eceacfa14/content
05:39:18,070 INFO
[org.jboss.as.server.deployment]
(MSC service thread 1-1)
JBAS015876: Starting deployment of
“hello.war”
05:39:18,299 INFO [org.jboss.web]
(MSC service thread 1-4)
JBAS018210: Registering web con- text: /hello
05:39:18,432 INFO
[org.jboss.as.server] (management- handler-thread - 3) JBAS018559:
Deployed “hello.war”
Der Zugriff auf die Webanwendung er- folgt dann über die URL http://local- host/8080/ hello/hello.jsp und sollte als Ergebnis eine ähnliche Webseite wie in Bild 5 anzeigen.
Zentrale Konfiguration im Domain-Modus
In größeren Umgebungen bietet es sich an, JBAS im Domain-Modus zu betreiben.
Hierbei laufen mehrere AP-Instanzen in getrennten JVM-Prozessen auf unter-
ein Domänencontroller zur Verfügung. Die Kommunikation zwischen den AP-Instan- zen und dem zentralen Domämencon- troller wird dabei von einem sogenannten Host-Controller durchgeführt. Dieser läuft auf jedem Host und ist nicht nur dafür verantwortlich, die AP-Instanzen eines Hosts zu starten und zu stoppen, sondern auch die Konfiguration mit dem zentralen Domänencontroller abzugleichen.
Einzelne AP-Instanzen können dabei zu sogenannten Server-Gruppen zusam- mengefasst werden. Dies erleichtert die Konfiguration für Anwendungen, die je- weils bestimmte Konfigurationseinstel- lungen benötigen. Anders als im Standa- lone-Modus sind sämtliche vorhandenen Profile in der Datei domain.xml definiert.
Diese werden dann, ähnlich wie auch die zuvor konfigurierten Socket-Gruppen oder JVM-Einstellungen, einer Server- Gruppe zugewiesen:
<server-group name=“main-server- group” profile=“full”>
<jvm name=“default”>
<heap size=“64m” max-size=“512m”/>
</jvm>
<socket-binding-group ref=“full- sockets”/>
</server-group>
Der Vorteil dieses Aufbaus liegt darin, anstatt jeweils einzelne Systeme mit einer passen- den Konfiguration zu bestücken, diese zen- tral festzulegen und auf sämtliche Systeme, die zur gleichen Server-Gruppe gehören zu verteilen. Eine dezentrale Konfiguration ist somit nicht mehr notwendig.
Sichere Kommunikation
Zum Abschluss unseres Workshops wollen wir noch einen sicheren Zugriff auf eine Webanwendung konfigurieren. Dies ist besonders dann wichtig, wenn die An- wendung sensible Daten überträgt oder eventuell eine Benutzer-Authentifizierung – inklusive der Übertragung eines Benut- zer-Passwortes – durchführt. Für eine ge- sicherte HTTPS-Verbindung fügen Sie dem JBoss-Server einen zusätzlichen HTTPS-Connector hinzu.
Bild 5: Nach der erfolgreichen Bereitstellung der Webanwendung steht diese nun über einen Webbrowser zum Abruf bereit.
66 Juli 2013 Link-Code eingeben auf www.it-administrator.de P R A X I S I W o r k s h o p
Vor dessen Konfiguration ist es jedoch notwendig, dass Sie einen Zertifikatsspei- cher erzeugen. Dieser Speicher enthält ein X.509-Zertifikat, das entweder selbst signiert wurde oder über die Signatur ei- ner externen Zertifizierungsstelle (CA) verfügt. Mit Hilfe der Java-Anwendung
“keytool” legen Sie einen solchen Zerti- fikatsspeicher leicht an:
# keytool -genkey -alias example -keystore example.keystore -keyalg RSA
Enter keystore password:
Re-enter new password:
[…]
# keytool -list -keystore example.keystore
Enter keystore password:
Keystore type: JKS Keystore provider: SUN
Jetzt sollten Sie dafür sorgen, dass die ver- wendete JBoss-Konfigurationsdatei über einen entsprechenden HTTPS-Connector verfügt. Diesen definieren Sie in der ge- wünschten Socket-Binding Gruppe. Die Socket-Gruppen werden dabei in der je- weiligen standalone-Datei oder im jewei- ligen Profil der Datei domain.xml festgelegt:
<socket-binding-group name=
“standard-sockets” default-inter- face=“public”>
<socket-binding name=“ajp”
port=“8009”/>
<socket-binding name=“http”
port=“8080”/>
<socket-binding name=“https”
port=“8443”/>
<socket-binding name=“osgi-http” in- terface=“management” port=“8090”/>
<socket-binding name=“remoting”
port=“4447”/>
<socket-binding name=“txn-recovery- environment” port=“4712”/>
<socket-binding name=“txn-status- manager” port=“4713”/>
<outbound-socket-binding name=“mail- smtp”>
<remote-destination host=“localhost”
port=“25”/>
</outbound-socket-binding>
</socket-binding-group>
Schließlich fügen Sie den eigentlichen Con- nector dem gewünschten Profil hinzu:
<connector name=“https”
protocol=“HTTP/1.1” socket-bin- ding=“https” scheme=“https”
secure=“true”>
<ssl name=“https” password=“red- hat” certificate-key-
file=“/opt/jboss-as-
7.1.1.Final/example.keystore”/>
</connector>
Ab nun stehen sämtliche Webanwendungen auch über den gesicherten HTTPS-Port 8443 zur Verfügung und die Übertragung der Daten zwischen Applikationsserver und Client findet über eine verschlüsselte Ver- bindung statt. Da es sich in unserem Beispiel um ein selbstsigniertes Zertifikat handelt,
bringt der Browser beim Zugriff auf die so geschützte Seite eine Warnmeldung, dass die Authentizität des Zertifikates nicht ve- rifiziert werden kann. Im produktiven Ein- satz sollten Sie daher ein Zertifikat gene- rieren, das von einer Zertifikatsstelle mit einer gültigen Signatur versehen wird.
Und vieles mehr
Die behandelten Themen stellen nur einen kleinen Einblick in die Administration des JBoss-Applikationsserver dar. So besteht na- türlich über das Subsystem “Security” die Möglichkeit, eine Benutzerauthentifizierung beim Zugriff auf eine Webanwendung durchzuführen. Hierfür können reguläre Dateien, Datenbanken oder auch LDAP- Server als Backend dienen. In JBoss AP7 kommt nun HornetQ als Java Message Ser- vice zum Einsatz. HornetQ stellt über Queues und Topics sicher, dass einzelne Software-Komponenten Nachrichten über einen gemeinsamen Nachrichtenkanal aus- tauschen ohne dass dabei Verluste auftreten.
Als Cluster-Lösung greift JBAS nun auf JGroups zurück. Zusammen mit einem vorgeschalteten Proxy wird so sicherge- stellt, dass der Ausfall einer JBoss-Instanz keine Auswirkung auf Benutzerverbin- dungen hat. Dank des Infinispan-Subsys- tems werden sämtliche Cache-Objekte zwischen den einzelnen Instanzen syn- chron gehalten und stehen somit überall zur Verfügung. Möchten Sie sich näher mit den hier angerissenen Themen aus- einandersetzen, sollten Sie sich die sehr gute Dokumentation auf der JBoss-Com- munity-Webseite ansehen. Hier finden sich auch unzählige HowTos für alle nur denkbaren JBoss-Einsatzzwecke und Konfigurationen [5]. (jp)
[1] Java EE 6-Spezifikation D7P11
[2] Red Hat Enterprise Application Platform D7P12
[3] JBoss Application Server Community-Edition D7P13
[4] FAQ zu WildFly / JBoss Application Server D7P14
[5] JBoss Community-Wiki D7P15
Link-Codes Bild 6: Im Domain-Mode wird die Anwendung auf einer Server-Gruppe ausgerollt.
Dies klappt über die Managementkonsole ebenfalls sehr bequem.
