Mule ESB Enterprise mit Docker

1 Kommentar

Motivation

In den letzten Jahren ist der Bedarf unserer Industrie an Automatisierung sowohl in der Entwicklung als auch im Betrieb gestiegen und durch eine steigende Anzahl an Werkzeugen in diesem Bereich zunehmend befriedigt worden. Wir haben die Industrialisierung der Virtualisierung erlebt, die DevOps Automatisierung erst möglich gemacht hat, den Aufstieg von Provisionierungswerkzeugen wie Chef, Puppet oder die Neulinge Ansible und YADT, und Hypervisor-Lösungen zur Optimierung und Isolation von Systempaketen wie Docker oder SmartOS oder auch unternehmensweite Monitoring Lösungen wie AppDynamics oder Nagios. All diese unterschiedlichen Teile lassen sich unter dem Buzzword DevOps zusammenfassen.

In dem Kontext eines Projekts, welches eine Entwicklungs- und Testumgebung für Ende-zu-Ende Systemtests erforderte, haben wir den Bedarf identifiziert, mehrere MuleEE Instanzen auf einmal zu erzeugen. Der DevOps Ansatz und seine Werkzeuge waren die natürliche Wahl. Wir entschieden uns, Docker zu nutzen, welches ressourcensparend mehre Instanzen erstellen und dadurch den gesamten System-Overhead in Systemtests niedrig halten kann. Während unserer Nachforschungen haben wir nur Docker Images für die Mule Community Edition gefunden, um virtuelle Mule Instanzen zu erzeugen. Folglich entstand bei uns die Motivation, das gleiche für eine Enterprise Version bereitzustellen.

In diesem Blog Artikel werden wir zeigen, wie man für seine Unternehmensinfrastruktur ein eigenes Mule ESB Enterprise Image mit Docker erstellen kann unter der Annahme, dass eine entsprechende Lizenz und MuleEE Version verfügbar sind.

Verwandte Arbeit

Es existieren bereits zwei Docker Images im Docker Hub, welche eine Image-Paket mit Mule ESB bereitstellen. Leider handelt es bei diesen Mule ESB Versionen um die Community Version:

Mule ESB Infrastruktur

In einem typischen Mule ESB Unternehmensszenario haben wir zwei Knotentypen:

  • MuleEE Server Knoten welche die Mule ESB Funktionalität zur Verfügung stellen und für hohe Verfügbarkeit zu Clustern gruppiert werden können
  • Und einen Mule Management Konsolen (MMC) Knoten welcher für das Deployment, das Monitoring und die Verwaltung der MuleEE Server und ihrer Applikationen eine administrative Oberfläche zur Verfügung stellt

Wie in der folgenden Abbildung dargestellt, kann die MMC separat vom MuleEE Server deployt werden. Der deployte MMC Agent auf dem MuleEE Server hilft dabei der MMC bei der automatischen Identifizierung und Registrierung aller verfügbaren MuleEE Instanzen.

MMC-architecture

Abbildung 1: Architektur der Mule Management Konsole (MMC) (Source:http://www.mulesoft.org/documentation/display/current/Architecture+of+the+Mule+Management+Console)

Auszug aus der Dokumentation zur Erklärung der Abbildung:

MMC-1Die Mule ESB Instanz überwacht von MMC. Diese kann als Server, als eingebettete Instanz oder als Cluster betrieben werden.
MMC-3Der MMC Agent innerhalb der Mule Instanz, welcher verantwortlich ist für:

  • Erleichterung des Daten Transfers zwischen Mule Instanzen und MMC
  • Anwendung von Änderungen (z.B. Thread Pools, und Änderungen von Konfigurations Dateien) an den Mule Applikationen
MMC-2Die MMC Instanz, die Web-basierte Schnittstelle welche mit Mule interagiert durch:

  • den MMC Agenten
  • von dem Mule veröffentlichte JMX Funktionalität. (Mehr Informationen zu JMX Management, sind zu finden auf der JMX Management Seite)

Die MMC Instanz ist eine Web-Applikation paketiert als WAR Datei welche in einem Web Servlet Container ausgeführt wird (z.B. Tomcat, JBoss, etc.).

Bau eines Mule ESB Server Docker Images

Im Internet gibt es viele gute Artikel, die eine Einführung zu Docker anbieten. Deswegen setzen wir an dieser Stelle voraus, dass der Leser bereits Erfahrung mit Docker hat.

Erstellung des Docker Basis Images

Wir haben eine Dockerfile Datei angelegt, welche das Skript für die Schritte zum Bau eines Docker Basis Images enthält. Zuerst werden ein Test Distributionspaket mit MuleEE und MMC genommen, die Dateien extrahiert, die Mule Lizenz installiert –  welche vom Nutzer bereitgestellt werden muss – , unnötige Dateien entfernt und die Ports für das Docker Basis Image konfiguriert. Dieses Dockerfile kann von GitHub heruntergeladen werden, dies wird als Voraussetzung angenommen. Durch die Restriktionen der Enterprise Version muss das Docker Image für die individuelle Verwendung vorbereitet werden. Es ist notwendig:

  • die Enterprise Version vom Mule ESB Server von Mulesoft bereitzustellen. Das Dockerfile in diesem Artikel geht von einem Herunterladen des Test Distributionspakets von mulesoft.com aus, welches sich dann im gleichen Ordner wie das Dockerfile befindet.
  • die Enterprise Lizenz Datei von Mulesoft, welche sich dann im gleichen Ordner wie das Dockerfile befindet.

Der vorbereitete Ordner sieht deswegen wie folgt aus:

  • ./Dockerfile
  • ./mmc-distribution-mule-console-bundle-3.5.1.zip
  • ./mule-ee-license.lic

Nun kann das Docker Basis Image gebaut und gleichzeitig getaggt werden:

docker build --tag="mule-ee" .

Image Typen

Es gibt zwei Möglichkeiten das Docker Basis Image zu nutzen, abhängig vom gewählten Szenario:

  • das Basis Image kann verwendet werden zur Erstellung und zum Starten –  in einem klassischen betrieblichen Sinn – von mehreren Mule ESB Server Instanzen und einer MMC Instanz. Diese können später in einem Cluster zusammengeschlossen werden und das Deployment von Applikationen kann dann per MMC durchgeführt werden.
  • oder – was wir empfehlen würden – ein Docker Image für jede Mule ESB Applikation zu bauen, um Applikationen auf einer Betriebssystemebene von einander zu isolieren und auf diese Weise die Erstellung und den Start von mehreren Mule ESB Server Instanzen und einer MMC Instanz durchzuführen. Dies ist eine Option in einem Micro Service oder SOA Szenario, wo eine explizite Kontrolle über die Container benötigt wird. In so einem Szenario muss man aber die Lizenzbedingungen im Hinterkopf behalten.

Applikationsspezifische Container Images

Basierend auf dem MuleEE Docker Basis Image kann ein applikationsspezifisches Image gebaut werden. Das korrespondierende Dockerfile kann wie folgt aussehen, wobei eine konkrete Umsetzung dem Leser überlassen wird:

FROM                    mule-ee:latest
.
.
ADD                     mule-app/target/mule-app-1.0.0-SNAPSHOT.zip /opt/mule-standalone-3.5.1/apps/

Erstellung eines applikationsspezifischen Docker Images:

docker build --tag="my-mule-app-image" .

Erstellung eines Mule Management Konsolen (MMC) Docker Images

Nach der Erstellung des Basis Docker Images, benötigen wir ein MMC spezifisches Docker Image. Wie im vorherigen Docker Image wurde eine Dockerfile vorbereitet, welches von GitHub heruntergeladen werden kann, und das Auschecken der Datei wird als Vorbedingung angenommen. Zusätzlich wird die Mule Management Konsole (MMC) im gleichen Ordner wie das Dockerfile von Mulesoft erwartet. Folglich sollte der Ordner wie folgt aussehen:

  • ./Dockerfile
  • ./mmc-distribution-mule-console-bundle-3.5.1.zip

Danach kann das Docker Image gebaut und sofort getaggt werden:

docker build --tag="mule-mmc" .

Testfahrt der Mule ESB Infrastruktur mit Docker

Nach der Erstellung beider Image Typen oder mehrerer applikationsspezifischer Images machen wir eine Testfahrt mit der Infrastruktur, zum Beispiel starten wir zwei Mule ESB Enterprise Instanzen:

docker run -t -i --name='mule-ee-node1' mule-ee
docker run -t -i --name='mule-ee-node2' mule-ee

Um ein applikationsspezifisches Image zu starten, muss man folgendes Kommando ausführen:

docker run -t -i --name='mule-app-nodeX' my-mule-app-image

Und wir starten eine Mule MMC Instanz:

docker run -t -i -p 8585:8585 --name='mule-mmc-node' mule-mmc

Anmerkung: Auf OS X benötigt das VBox von boot2docker ein Port Forwarding vom Host -> VBox -> Docker

 boot2docker ssh -L 8585:localhost:8585

Nun können wir einen Blick auf die laufenden Docker Instanzen werfen und wir sehen zwei MuleEE Knoten und einen MMC Knoten:

cpoepke:mule-mmc cpoepke$ docker ps
CONTAINER ID        IMAGE               COMMAND                CREATED             STATUS              PORTS                                        NAMES
f77b8b2bcabd        mule-ee:latest      /bin/sh -c /opt/mul   2 days ago          Up 3 seconds        1098/tcp, 5000/tcp                           mule-ee-node2    
500499fa5054        mule-ee:latest      /bin/sh -c /opt/mul   2 days ago          Up 1 seconds        5000/tcp, 1098/tcp                           mule-ee-node1   
a23cfc4c9df0        mule-mmc:latest     /bin/sh -c /opt/mmc   2 days ago          Up 2 minutes        5000/tcp, 1098/tcp, 0.0.0.0:8585->8585/tcp   mule-mmc-node

Und wie erwartet landen wir nach der Eingabe von http://localhost:8585/mmc-3.5.1 auf dem MMC Login Bildschirm. Zusätzlich erkennen wir, dass unsere MuleEE Knoten automatisch vom MMC Knoten entdeckt wurden. Folglich verifiziert das uns, dass die Verbindung zwischen den Knoten auch aufgebaut wurde:

MMC Mule ESB instances

Abbildung 2: Die Mule Management Konsole (MMC)  mit den automatisch erkannten MuleEE Instanzen

Fazit

In diesem Blog Artikel haben wir gezeigt, wie man eine MuleEE Docker Basis Image und ein MMC Docker Image erstellen kann. Diese können, abhängig von der Entwicklungs- und Betriebsstrategie des Unternehmens verwendet werden, um Entwickler-, Test- oder Produktionsumgebungen schneller und einfacher aufzubauen.

 

Ich freue mich auf Kommentare und eine angeregte Diskussion!

Conrad ist Business Development Manager bei der codecentric AG. Er sieht sich selbst als „Coding-Software-Architekt“, Entwickler und in allen anderen Rollen, die für die erfolgreiche Durchführung eines Projekts vonnöten sind. Derzeit fokussiert er sich auf dem Aufbau der Partnerschaft mit Amazon Web Services und auf die in dem Rahmen entstehenden Projekte. Sein persönliches Ziel ist es, nach neuem Wissen in der IT-Industrie zu streben.

In seiner Freizeit macht er sich in Berlin für die IT Community stark, als Gründer und Hauptorganisator des Microservices Meetups Berlin, Co-Organizer des DDD Meetups, des Serverless Meetups und als Mitglied im Organisations-Komitee der MicroXchg Konferenz und KanDDDinsky der Berliner DDD Konferenz.

Share on FacebookGoogle+Share on LinkedInTweet about this on TwitterShare on RedditDigg thisShare on StumbleUpon

Kommentare

  • Tobias Schaber

    3. November 2014 von Tobias Schaber

    Hi together,

    @Yamen the Memory Overhead is quiet big. I’ve tried a similar Scenario with the community Edition and it took me about 300mb of ram for each instance, that means, for each app. That was expected due to the jvm starting up for each app. But you also get a great benefit from this fact. If your runtime is going down, only one app is affected and not all apps running on the machine.

    Kind regards,

    tobias

Kommentieren

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.