Dockerizing a proof of concept

Few weeks back I was working on a proof of concept to demonstrate a long running workflow based orchestration scenario. More about the architecture behind the PoC can be found at WSO2 solutions architecture blog. But this blog is not related to the architecture, this is simply about delivering the proof of concept in a completely contained environment.

What inspired me to do this: As a day to day job I happened to show how enterprise solutions architectures work in real world. I cook up a use-case in my machine, often with couple of WSO2 products (like the ESB/DSS/DAS/API-M) and some other non-WSO2 ones, then demonstrate the setup to who ever the interested party. I always thought it would be cool if the audience can run this themselves after the demo without any hassle (They can run it even now with bit of work 😉 but thats time someone can easily save). The other motivation is to save my own time by re-using the demos I’ve build.

Docker ! Docker ! Docker !

I’ve been playing with docker on and off, thought its a cool technology and I found that creating and destroying containers in a matter of milliseconds is kind of fun 😀 okey jokes aside I was looking for a way to do something useful with Docker, and finally found inspiration and the time.

I took the orchestration PoC (Bulk ordering work-flow for book publishers) as the base model that I am going to Dockerize.

architecture

I made sure that I cover my bases first with making everything completely remotely deployable. If am to build a completely automated deployment and a start up process I shouldn’t configure any of the products from the management UI.

The artifacts:

https://github.com/nuwanbando/bookshop-sample/tree/master/artifacts

All the ESB and DSS artifacts went to a .car file {bookshop-app_1.0.0.car} with ESB and DSS profiles respectively. The long running orchestration was developed as a BPMN workflow and that was exported to a .bar file {BookOrderApprovalProcess.bar}

Thats pretty much I had to do. After that its more or less bit of dev-ops work and automation. Some of the decisions I took along the dev-ops process were

[1] Not to create Docker images (and maybe push to docker-hub) from WSO2 product bundles + artifacts. Why: Mainly because then the images will get too heavy (~700MB)

[2] Use docker-compose instead of something like Vagrant. Why: I was bit lazy to explore something new and also wanted to stick to one tool for simplicity. And also docker-compose served the purpose.

With #1 deciton I wrote a dockerfile for each of the product so anyone can build an image with a simple command. The bookshop PoC touches WSO2 ESB, DSS, BPS and additionally to store the book orders I created a database in an external mysql server. Its altogether four Dockerfiles

ESB Dockerfile gist:

Once thats done, docker-compose does the wiring.

Docker compose definitions gist:

The composition will build all the images, expose the ports to the host machine and start-up all the containers in an isolated docker network.

# build and start the containers
$ docker-compose up -d

# Stop and kill all the containers with their images
$ docker-compose down --rmi all

Thats about it. The project can be found at github and you can find instructions to run the PoC on the readme fine.

I intend to build all my PoC demos in the above fashion, so unless I get really lazy 😀 I should be publishing docker compositions more often.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s