Configure JBoss EAP with native SSL support

Ever tried to get all information you need to get JBoss EAP up and running using native SSL? No? Here's the Alex way getting EAP 6.1.0 with native SSL support up and running on Windows Server 2008 R2 64bit.

Prerequisite

• JBoss EAP 6.1.0 GA
• No usage of welcome-root (otherwise set flag enable-welcome-root to true in standalone.xml)
• Windows Server 2008 R2 64bit
• SSL private key file as plain text PEM format (RSA)
• SSL certificate as plain text PEM format
• SSL CA bundle as plain text PEM format

Solution

• Download Windows Server 2008 R2 64bit native libs from here (login required)
• Unpack and move lib folder including all sub content to your JBoss installation - say C:\jboss-eap-6.1\modules\system\layers\base\org\jboss\as\web\main
• Add/edit standalone.xml (Example path: C:\jboss-eap-6.1\standalone\configuration) as follows - important: set native attribute to true!

<subsystem xmlns="urn:jboss:domain:web:1.4" default-virtual-server="default-host" native="true"> <connector name="http" protocol="HTTP/1.1" scheme="http" socket-binding="http" redirect-port="${jboss.https.port:8443}"/> <connector name="https" protocol="HTTP/1.1" scheme="https" socket-binding="https" secure="true">   <ssl name="ssl" certificate-key-file="../../cert/ssl-private-key.key" verify-client="false" certificate-file="../../cert/ssl-certificate.crt" ca-certificate-file="../../cert/ssl-cabundle.cabundle"/> </connector> <virtual-server name="default-host" enable-welcome-root="false">   <alias name="localhost"/>   <alias name="example.com"/> </virtual-server> </subsystem>

• Restart JBoss
• Check server.log for ERRORs - SSL loading is fine if

[org.apache.coyote.http11] (MSC service thread 1-3) JBWEB003000: Coyote HTTP/1.1 starting on: http-/0.0.0.0:443

• DONE

DevOps - Was bisher geschah

Vergesst die Tools
Tools sind ein unabdingbarer Bestandteil von DevOps. Puppet, Chef, Vagrant und Co. sind nicht wegzudenken und ohne sie DevOps kaum umsetzbar. Dennoch bedeutet DevOps zu 95% Änderungen der Organisation, der Zusammenarbeit, der Prozesse. Der Rest sind Tools. Daher dürfte der Versuch, DevOps im Unternehmen mittels entsprechender Tools zu etablieren in den meisten Fällen fehl schlagen.

DevOps ist Unternehmenspolitik
DevOps wird nicht eingeführt. DevOps wird gelebt. Alle Hierarchien eines Unternehmens sind involviert. Allen voran natürlich Entwickler und Operatoren. Daneben aber auch Product Manager, Product Owner, Tester und nicht zuletzt und vielleicht am wichtigsten: Das Management.

Oft betont in diesem Zusammenhang: DevOps ist keine Stellenbeschreibung, sondern Unternehmenskultur. Man kann keine DevOps-Stelle im Unternehmen besetzen. DevOps beschreibt vielmehr das Zusammenspiel der Entwickler- und der Operatorenwelten. Denkbar sind hier viele Variationen:

• Regelmäßige Jour Fixe zwischen Entwicklern und Operatoren
• Einbindung der Operatoren in agile Methoden, z.B. das Daily Scrum
• Ständige Anwesenheit von Operatoren in agilen Entwicklerteams

Besonders letzteres wird sich kaum ein Unternehmen leisten (können), obgleich dieser Zustand sicherlich wünschenswert wäre. Nur geht es in den wenigsten Fällen um Wünsche und was schön wäre, sondern um harte Fakten. Im Zweifel also um Geld.

DevOps != Agil
DevOps wird in den meisten Fällen immer im Zusammenhang mit agiler Softwareentwicklung gesehen. Dennoch kann DevOps auch in klassischen Entwicklungsprojekten zum Einsatz kommen. Im Umkehrschluss bedeutet dies, dass DevOps besonders beim agilen Ansatz in der Softwareentwicklung zum Einsatz kommen muss, um die dort verstärkt auftretenden Probleme anzugehen.

DevOps kostet Geld
Überrascht? Für Sprints durchgetaktete Entwickler sollen sich neben Weiterbildung und Support ihrer Anwendungen nun auch noch um Deploy und Betrieb kümmern? Ja! Nur so entsteht ein Verständnis dafür, wie sich die Anwendungen im echten Leben verhalten statt diese dem IT-Betrieb als Deploymentpackage über die Mauer zu werfen und davon zu laufen. 

Viel aufwändiger wird das Thema, wenn wir uns den Bereich der Operatoren ansehen. Sich mit den Einzelheiten von Applikationsservern auseinander zu setzen, sich für oder gegen eine einzelne Virtualisierungstechnik zu entscheiden, das Monitoring auf die Anwendung abzustimmen und im Fehlerfall zu wissen, wie welche Informationen und Logdaten zu interpretieren sind, wird sicherlich nicht für umsonst zu haben sein.

Dev überholt Ops
Eine der größten Hürden, für welche es bisher keine Lösung gibt: Dev ist schneller als Ops. Durch die Einführung agiler Softwareentwicklung und das Aufkommen immer neuer Frameworks sind die Entwickler den Operatoren immer mehrere Schritte voraus. Auf der einen Seite innovationsgetriebene Softwareentwicklung mit immer kürzeren Releasezyklen stehen auf der anderen Seite einem auf Stabilität und Verfügbarkeit ausgerichteten IT-Betrieb gegenüber. Änderungen im Tages- oder gar Stundentakt sind hier undenkbar. Ein System möglichst lange unverändert zu betreiben ist eines der großen Ziele des Betriebes von Infrastruktur und Anwendungen.

DevOps braucht Spezialisten, weniger Generalisten. Hier tritt eine weitere Hürde zu Tage. Während Entwickler in die Tiefen der von Ihnen entwickelten Software eintauchen können und müssen, sieht das bei den Operatoren meist anders aus. Sie betreuen ein in höchstem Maße heterogenes Infrastrukturumfeld, wo jede einzelne Software ihre ganz eigenen Anforderungen hat. Hier müssen Generalisten her, welche den Überblick über Hardware, Netzwerke, Sicherheit, Firewalls, Betriebssysteme, Virtualisierung, Applikationsserver, Performancetuning, Storage, Monitoring, usw. behalten. Hier wird eine typische 1:n Beziehung, wie aus dem Datenbankumfeld, sichtbar: Ein Operator kümmert sich um n Projekte und deren Betrieb, während n Projekte/Entwickler auf einen Operator zurückgreifen wollen.

Dieses Dilemma aufzulösen ist eine der großen Aufgaben von DevOps.

Lückenschluss
Den Bereich DevOps zu umschreiben, würde ich auf den Todesstreifen einer Grenzbefestigung zweier nicht befreundeter Staaten zurückgreifen. Keiner traut sich hinein, jeder arbeitet auf der für ihn angedachten Seite der Befestigung, Annäherung gibt es nur unter staatlicher (also unternehmerischer) Kontrolle. Diesen Streifen wieder zu beleben ist Aufgabe derer, die an der Grenze arbeiten und vor allem derer, welche im Hintergrund Entscheidungen treffen. Bei DevOps geht es nicht allein um die Überwindung einer räumlichen Trennung, vielmehr darum, Ideologin aus den Köpfen der Beteiligten zu verbannen und sich sachlich auf Fakten zu konzentrieren.

Das von Dr. Patrick Peschlow in der javamagazin Ausgabe 1.2014 S. 34 beschrieben Blame Game macht deutlich, wie wichtig ein gemeinsames und faktenorientiertes Finden von Lösungen ist.

Devs
Die Lücke zwischen Entwicklern und Operatoren zu schließen, dürfte in den meisten Fällen den Entwicklern ein Stück leichter fallen. Durch bereits etablierte Tools wie Git oder Jenkins ist es denkbar, zukünftig Infrastructure as Code zu etablieren, wodurch Entwickler in die Lage versetzt werden, Infrastruktur für ihre Zwecke automatisiert unter Kontrolle zu bringen.

Ops
Etwas pessimistischer sehe ich den Bereich der Operatoren. Hier sind die Änderungen viel weitreichender:

- Einführung agiler Methoden für den IT-Betrieb - hier sind wir Jahre im Rückstand
- Große Lernkurve, um die Arbeit der Entwickler im Detail zu verstehen und zu adaptieren
- Raus aus der reaktiven Tätigkeit als Feuerwehr hin zum pro-aktiven Dienstleister

Management
Tragt zu DevOps bei - sonst ist es zum Scheitern verurteilt. Entwickler und Operatoren finden zusammen auch die richtigen Kennzahlen, mittels welcher sich der Erfolg von DevOps messen lässt. Der Erfolg wird sich aber nicht morgen einstellen, sondern muss mittelfristig geplant werden. Je größer das Unternehmen, desto länger voraussichtlich der Zeitraum, bis konkrete Ergebnisse vorliegen.

DevOps ist Unternehmensstrategie und -kultur.

Wer fehlt?
Die Tester! Bei aller Automatisierung, bei aller Personalunion Entwickler=Tester. Tester sind unabdingbarer Bestandteil von Softwareentwicklungsprozessen. Und gerade Tester können von der automatisierten Bereitstellung von Infrastruktur - wiederholbar mit immer gleicher Ausgangskonfiguration - profitieren.

Fazit
Stabilität, Verfügbarkeit und ITIL treffen auf agile Softwareentwicklung. Verantwortlichkeiten für zig Projekte treffen auf Verantwortlichkeiten für ein Projekt oder Produkt. Daher:

- Dev und Ops gehören an einen Tisch - vor und während der Entwicklung, beim Betrieb und beim Support der Anwendung
- Scrum muss um den Bereich Deploy, Betrieb und Support erweitert werden

Ein kleines Projekt oder ein Produkt wie z.B. eine überschaubare mobile App sind ein guter Ausgangspunkt, um DevOps zu pilotieren. Steht beiden Seiten hierzu ausreichend Freiraum zur Verfügung, kann sich dies zum Vorzeigemodell entwickeln. Richtet einen Blog ein, geht an die Öffentlichkeit, und sei es "nur" das Unternehmens-Intranet. Behaltet euren Erkenntnisgewinn, auch Rückschläge, nicht für euch. Macht einen guten Job und infiltriert andere Projekte. Seid offen, publiziert Webcasts zu einzelnen Themen. Auch das kann ein wichtiger Teil von DevOps sein.

DevOps greift eine Idee neu auf, welche durch die immer mehr davon preschende Softwareentwicklung verloren gegangen ist - nämlich Entwickler und Operatoren an einen Tisch zu bringen. Es geht um einen respektvollen Umgang, es geht um die Akzeptanz des Fachwissens der jeweils anderen Seite, es geht darum, genau daraus zu lernen und es geht darum, gemeinsam eine für das jeweilige Unternehmensziel praktikable Lösung für DevOps zu finden. Auf Augenhöhe unvoreingenommen miteinander zu sprechen und beste Anwendungen samt deren Betrieb für die Kunden zu liefern sollte ganz oben auf der Liste der Ziele von DevOps stehen.