Containers voor je integratie: Docker met een ESB?

Een van de nieuwere hypes rond DevOps is Docker. Dit systeem kan gebruikt worden om software of services in een ‘container’ te plaatsen, waardoor onderhoud, deployment en beveiliging makkelijker te managen zijn. In deze blogpost gaan we in op Docker en wat de voordelen zijn als je dit combineert met een ESB. Als je nog niet bekend bent met Docker en er meer over wilt weten, kijk dan even op deze site. Deze blogpost bevat geen volledige breakdown van het product Docker, of hoe je deze kan inzetten. Wel vertellen we wat Docker kan toevoegen aan je ESB en waarom het een goed idee is dit in te zetten als je op zoek bent naar meer flexibiliteit in deployments, upgrades en algemeen onderhoud van je ESB-platform.

Door: Michiel van der Winden

Het idee van Docker

Wellicht weet je al (bijvoorbeeld via bovenstaande link) dat Docker een platform is om systemen en processen in een ‘container’ te plaatsen.
Het idee is dat je, in plaats van een VM te gebruiken, alle systemen of services in een door Docker beheerde ‘laag’ bovenop je OS draait. Hierdoor is de overhead van alle services een stuk lager dan wanneer deze in een VM draaien. Processen kunnen via Docker van elkaar ontkoppeld worden zodat ze geen impact op elkaar kunnen hebben. En, indien een service moet worden herstart (bijvoorbeeld als een configuratiefile is aangepast, of als een update beschikbaar is), dan hoeft alleen de specifieke container te herstarten en hoeven de andere systemen niet offline gehaald te worden.

Een groot voordeel van Docker is dat áls je containers werken op je eigen systeem of testserver, je ervan uit kan gaan dat ze in 99% van de gevallen ook werken op elk ander systeem waarop Docker kan draaien. Hierdoor kunnen we nagenoeg garanderen dat als alle testen slagen in de test-omgeving, dit ook exact zo zal werken in de opvolgende systemen, waardoor het continue deployen (continuous deployment/continuous integration) van nieuwe versies opeens een stuk haalbaarder wordt.

Waarom gebruiken we Docker met een ESB?

Met Docker kunnen we een ‘image’ maken van een bestaande installatie (bijvoorbeeld een Integration Server met een aantal packages) en deze vervolgens doorzetten naar een andere server. Hierdoor kunnen we op de server een container starten waarin een exacte kopie draait van de oorspronkelijke installatie, inclusief alle packages, configuratie en metadata die we oorspronkelijk hebben meegenomen.

Hierdoor kunnen we makkelijker continuous integration en continuous deployment opzetten. We weten immers dat alles wat we doorzetten altijd op dezelfde manier zal werken als op de voorgaande systemen. Een ander bijkomend voordeel is dat we een upgrade kunnen starten op onze eigen ontwikkelsystemen, hier controleren of alles werkt en het vervolgens gemakkelijk kunnen doorzetten naar elke opvolgende omgeving. Hierdoor minimaliseert Docker de overhead van het overstappen naar een nieuwe versie, wordt het testen een stuk effectiever en zorgt het ook nog eens voor een veel lagere doorlooptijd van upgrades/installaties door de operationeel specialisten!

Docker gebruiken met een ESB – de basis

Elke installatie van een Integration Server (vanaf versie 9.12) komt met een zogenaamde Dockerfile, een simpel maar effectief startpunt waarin metadata over de te maken image vastgelegd is. Hierdoor kun je snel starten met Docker in combinatie met een ESB.

Figuur 1: Het maken van een base image. De Dockerfile gebruikt de (meta)data uit de installatie om de daadwerkelijke image (waar onze service in zit) te maken.

Zoals uit figuur 1 blijkt, kan een ‘base image’ makkelijke ‘out of the box’ gemaakt worden; na het installeren van de service laten we Docker de Dockerfile gebruiken om een image te maken waarna deze direct klaar is voor gebruik.

Helaas hebben we aan een standaardinstallatie van een Integration Server niet veel op het gebied van test of productie. Om daadwerkelijk zulke systemen te vervangen moeten we de base image uitbreiden met zelfgemaakte packages en configuratie. Een van de opties is om alle packages en configuratie vooraf in te laden in onze basisinstallatie, maar deze manier van werken heeft als nadeel dat het een stuk minder herbruikbaar is (de base image raakt als het ware vervuild). De tweede, meer ‘Docker-like’ optie, is om de base image te gebruiken als de basis voor een volgende image:

Figuur 2: De base image gebruiken als startpunt van een nieuwe image zodat we (meta)data kunnen toevoegen en deze image kunnen gebruiken als de basis voor, bijvoorbeeld, een productieomgeving.

Alhoewel dit wat meer werk kost, voorkomt het dat we voor elke omgeving een nieuwe image moeten maken; als we deze manier van werken aanhouden, kunnen we de base image gebruiken voor meerdere doeleinden (bijvoorbeeld één container voor al het synchrone verkeer, en een andere container voor al het asynchrone verkeer). Zoals uit figuur 2 blijkt, gebruiken we de base image in onze zelfgemaakte Dockerfile als startpunt waarna we de nodige packages en configuratiefiles mee kunnen laten nemen naar onze volgende image. Op deze manier kunnen we zeer gemakkelijk een ‘test’, ‘acceptatie’ en ‘productie’ image maken, waar elke omgeving zijn eigen configuratiefile krijgt zodat deze met de juiste externe databases en services gekoppeld kunnen worden.

Conclusie

Docker is zo’n systeem dat het leven van onze DevOps’ers een stuk makkelijker maakt. Dankzij Docker is het ontwikkelwerk, testen en de daadwerkelijke deployment en management van services een stuk makkelijker, zonder dat ‘t echt iets kost. Natuurlijk bestaat er het punt van de eerste opzet, maar na deze tijdsinvestering verdient Docker zich binnen no-time terug in de vorm van gemak en snelheid. We zijn erg enthousiast over deze technologie en zullen hier zeker meer onderzoek naar doen.

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.