Na onze laatste blogpost over Docker hebben we een hoop werk gestoken in het onderzoeken hoe we Software AG’s producten in containers kunnen draaien. De beste plek om te beginnen lijkt de Integration Server aangezien dit dé spil is waar webMethods om draait. In deze blogpost bespreken we de do’s en don’ts, onze voortgang op dit gebied en welke uitdagingen we gaandeweg zijn tegengekomen.

Door: Michiel van der Winden

De Integration Server in een container stoppen

Software AG heeft veel voortgang geboekt in de wereld van containers. De nieuwste versies van hun producten zijn nu voorbereid op integratie met Docker en dus zijn er betere handvatten om de Integration Server in een container te krijgen. Het programma dat gebruikt wordt voor het installeren van de Integration Server bevat nu een optie om Dockerondersteuning te installeren. Dit houdt in dat er een script geïnstalleerd wordt welke gebruikt kan worden om een Dockerfile te genereren. Deze Dockerfile kunnen we weer gebruiken voor het bouwen van e. en image welke op zijn beurt gebruikt kan worden voor het starten van een Integration-Server-container.

De stappen zijn relatief simpel:

  1. Zoek het script in de installatiefolder van de Integration Server:
    Voorbeeld: {installatiefolder}/is/IntegrationServer/docker/is_container.sh
  2. Start dit shell script met de parameter createDockerFile
  3. De Dockerfile kan worden gebruik met de Docker command line om zodoende een image te bouwen
    De hierboven gemaakte image kan door Docker aangeroepen worden om een container te bouwen aan de hand van de meegegeven parameters. Als dit is gedaan zal het volgende zichtbaar zijn (ik gebruik Kitematic als schil bovenop de Docker command line. Dit is aangeraden maar niet verplicht):

Integration Server

Figuur 1: Integration Server in de Docker container.
Aan de linkerkant zien we Safari, met daarin de administratiepagina van de Integration Server
Rechts zien we Kitematic met de draaiende Docker container, met mapping van de interne poort naar localhost:5555.

Nadat de container is opgestart kan de Integration Server gebruikt worden voor meerdere doeleinden: local service development (Designer kan worden verbonden op de normale manier), als doel voor package deployments via WmDeployer of zelfs als productiesysteem. Er moet worden vermeld dat er op dit moment nog geen packages (behalve de Wm* packages) en configuratiebestanden (behalve de files uit de originele installatie) zijn ingeladen waardoor de container weinig nuttigs zal doen.

Het toevoegen van packages aan deze base image bestaat uit het bouwen van een nieuwe Dockerfile met daarin een referentie naar de packages die moeten worden ingeladen. Verder gebruiken we als startpunt de base image. Uit deze Dockerfile kan dan een nieuwe image gebouwd worden welke de verwachte packages bevat en gebruikt kan worden. Een overzicht van het proces is te zien in onze vorige blogpost over Docker (zie Figuur 2).

Een aantal uitdagingen

Tijdens het onderzoeken van dit onderwerp zijn we een aantal uitdagingen tegengekomen. Omdat we proberen een zo generiek mogelijk proces op te zetten om zodoende makkelijk (nieuwe) klanten om te zetten van een normale installatie naar containers liepen we direct tegen een uitdaging omtrent configuratie aan.

De Integration Server heeft een aantal soorten configuratie(bestanden) nodig om te werken, waaronder de service configuratie (adapters, global variables etc.), verbindingen met andere servers (bijvoorbeeld proxy servers, UM, SAML etc.), serverconfiguratie (aantal toegewezen CPU-cores, geheugen etc.) en de licentiebestanden. Een aantal van deze bestanden zijn te vinden in de config folders van de Integration Server zelf, maar andere bestanden zijn moeilijker te vinden (of zelfs voorzien van encryptie!) of worden vernieuwd/gebouwd tijdens deployment van packages.

Om toch bij onze wens van een generieke manier van bouwen te blijven zijn we in het automatiseren van de bouw en het onderhoud van dit soort bestanden gedoken. Dit kan onder andere door de gegevens van de configuratiebestanden op te nemen in externe parameters (bijvoorbeeld AWS’ Parameter Store, of als environment variable in Docker) evenals het (her)genereren van zaken als Global Variables, UM connectieparameters en andere zaken. Op deze manier is het mogelijk om van één image meerdere omgeving-specifieke containers te bouwen waardoor de nood voor omgeving-specifieke images vervalt (en dus de richtlijn van Docker wordt gevolgd).

Een andere uitdaging bestaat uit het deployen van de correcte packages naar de correcte omgeving. Dit zou gedaan kunnen worden door scripts te bouwen die de nieuwe of aangepaste packages uitrolt naar een nieuwe image welke op zijn beurt weer een specifiek versienummer krijgt. Door het versienummer te koppelen aan gegevens in een CVS als Git of SVN is te traceren welke wijzigingen er in een bepaalde versie van het image zijn opgenomen. Aan te raden is in dit geval het gebruik van Git als versiebeheer aangezien Software AG hier een zeer veel betere ondersteuning voor heeft ingebouwd en deze goed te integreren valt met build tools als Jenkins of Gitlab om zodoende de hele CI/CD pipeline te kunnen scripten.

Do’s en don’ts

Gedurende de periode waarin wij geprobeerd hebben producten van Software AG om te zetten naar containers hebben we ondervonden dat de meeste producten die wij gebruiken hier ondersteuning voor hebben. De vraag is echter of dit zo’n goed idee is.

Potentiële producten:

  • Integration Server (IS, in ons geval inclusief de TN packages)
  • Universal Messaging Server (UM)
  • My webMethods Server (MWS)

Tijdens het testen werd al snel duidelijk dat het geheel ombouwen tot containers vooral handig is als we bijvoorbeeld een nieuwe collega willen voorzien van een werkomgeving voor local development. Het is een kwestie van de juiste images doorsturen en deze omzetten tot een set containers waarna de collega in kwestie direct aan de slag kan.

Wat tevens opviel was dat containers vooral geschikt zijn voor schaalbaarheid, de mogelijkheid tot verplaatsen en het voorkomen van de “works on my machine”-issues. Dit betekent dat we alleen zaken in een container willen stoppen welke voldoen aan de bovenstaande eisen. Zaken als UM en MWS voldoen potentieel aan de schaalbaarheidseis, maar hoeven vaker niet dan wel verplaatst of vervangen te worden.
Uiteindelijk blijft de IS over. Als de gehele CI/CD-pipeline goed opgezet is denken wij dat containers een geweldige toevoeging of vervanging van de huidige omgevingen kan zijn aangezien het betekent dat we veel meer schaalbaarheid en onderhoudbaarheid kunnen garanderen op deze manier. Ook het uitrollen van fixes aan packages of zelfs de IS zelf (denk aan hotfixes of volledige updates) wordt zo een stuk makkelijker en sneller.

De do’s en don’ts kunnen we nu simpelweg opsommen:

  1. Gebruik containers voornamelijk voor de Integration Server, tenzij hier een nood voor is (bijvoorbeeld als MWS of UM schaalbaar moeten zijn, of als er gebruik wordt gemaakt van container-only-providers als Amazon ECS/EKS)
  2. Verander de “way of working” door alles zo stateless mogelijk te maken (dit is handig voor de schaalbaarheid, het betekent minder afhankelijkheden tussen de containers)
  3. Vervang alle huidige installaties van de Integration Server door containers om zodoende een beter te onderhouden en sneller te verplaatsen/uit te breiden omgeving te hebben
  4. Maak scripts voor alles van het bouwen van de base image tot de images van de daadwerkelijke productieomgeving om zodoende zo min mogelijk fouten tijdens deployment tegen te komen.

Conclusie

We hebben ondervonden dat Docker zeer bruikbaar en waardevol is als het aankomt op de producten van Software AG. Het kunnen opspinnen van een volledige omgeving met meerdere Integration Servers en potentieel andere producten betekent minder downtime, meer tijd om producten en functionaliteit te ontwikkelen en vergemakkelijkt het onderhoud op de koop toe.

inQdo blijft bezig met onderzoek naar Docker en de toepassing binnen producten van Software AG waardoor wij hopelijk binnen afzienbare tijd zowel ons als uw bedrijf kunnen verbeteren en meer toekomstbestendig kunnen maken.

Kunnen we jou helpen?

Onze integratieteams staan voor je klaar om je te helpen met al je integratievragen. Hulp nodig bij een kwestie? Neem gerust contact met ons op.

iso 27001 & isae 3402 certificaat inQdo BV

simplifying cloud and integration together

inQdo B.V.

Coltbaan 1-19

3439 NG Nieuwegein

info@inqdo.com

+31 85 2011161

Verzend