Containers on Strings – Puppetizing Docker

Docker is taking the IT world by storm, and if you haven’t been working in a cave without internet access you have likely heard about it. Or even better, you have already played around with it. At least for me, after getting a handle on it I was wondering why infrastructure management was ever done differently. Still coming from a pet store tutorial to a real world project showed some interesting challenges on the path.

“Commissioner, light up the Bat-Signal!”

One of our recent client projects featured an Angular client backed and served by an Apache HTTPD, JBoss Wildfly and a PostgreSQL database, where all the backend components run as Docker containers. A great place to start with such a container is to go to Docker Hub: You find many prebuilt Docker images, many even coming officially from the product vendors. That’s what I did to start with the Wildfly image, where the container was supposed to host the Angular REST backend. After initially playing around with it, I realized that I had to add

  • a deployment of the REST backend artifact (which needs to be downloaded first from the password protected artifact repository)
  • configure an admin user for the Wildfly console
  • change logging configuration so we see the logs on the host system
  • add a datasource for the PostgreSQL DB
  • …oh, PostgreSQL driver is missing, we need a module for that. And we need to download the driver JAR first.
  • configure system properties

Long list short story: Docker hub gives you the Bruce Wayne, what we need is the Batman!

We need the Batman!

Custom Docker Images

Of course you can just grab a shell and hack the next best script to do all of this to create the custom Docker image, or even do all of this in the Dockerfile itself as far as possible. But in a mature continuous delivery setup, your infrastructure is likely managed by a configuration management tool like Ansible, Chef or – as in our case – Puppet. Why not reusing this tooling setup to not only run your Docker containers but also to create them?


Puppet Forge features a Docker module which allows to run containers, manage and also create images. This is as simple as including a

All that has to be done before is putting the required resources into a staging directory containing a Dockerfile, As you see in the code snippet above, it also plays nicely with variables you might have for your Puppet runs (like the current REST backend version to deploy) which might come from the Puppet Hiera DB (so they can also be environment specific).

Preparing the full image might look like

The last Puppet resource is actually quite interesting. We’re able to template our Dockerfile. This could look like

Of course this also allows nice parameterization (we skipped a few possible other ones here for simplicity).

Development Environment Magic

Noticed the if statement towards the end in the Dockerfile template? For your infrastructure deployments, you want your application to be bundled with your image. For your local dev environment this is pretty useless though. Being able to template your Dockerfile, you open the possibility to also use the whole infrastructure setup more effectivrely in your dev env as well – immediate integration loops across your developer team included. In case of Wildfly, this also integrates nicely into your IDE. E.g. for Eclipse, you have the still work-in-progress Docker tools available, which features a Docker explorer, allows to control containers and also shows the container logs directly in the IDE:


Docker Explorer view:


Docker Container view (also has start, stop and pause controls):


Docker Logs:

A detailed description on how to add a WTP Wildfly server based on Docker you can find in Arun’s blog post. Also here having Puppet comes in handy as you have to add an additional volume depending on whether you’re in your dev env or not.


If you work with Docker (and therefore likely in a DevOps like setup), combining this with Puppet has more benefits the more complexity your Docker image requires. You also open up possibilities when it comes to reuse containers in your development environment, which usually requires more flexibility in terms of configurability. The approach lined out here also works well if you are in a “slim” environment:

  • You don’t need a Puppet Master server, you can apply Puppet directly on the target nodes
  • You don’t need an internal Docker hub, as the image is build directly on the target server. This even allows to build the image environment-specific (not only referring to the Dev environment here, e.g. to use different Wildfly admin user and password) if Docker variables are too tedious to use.

The second point has definitely room for discussion – it is in general preferrable to build the image artifact once and move this through the environments – although this requires then again a Docker hub (or a similar repository like Artifactory).

What’s your experience on customizing Docker images? Happy to hear about it!

Never miss an update by following us and subscribing to our monthly newsletter!


Tom Hug

Senior Technology Specialist at Atos Consulting
Tech nerd, OSS contributor and JVM aficionado. Coder at day, gamer at night. The rest of my time belongs to my family.

I have more than 15 years experience building distributed systems, and also know how to deploy and run them. Fluent in Java, and currently polishing again my language skills in Kotlin, C#, JavaScript and Python (in that order of preference).
Containers on Strings - Puppetizing Docker
Article Name
Containers on Strings - Puppetizing Docker
Docker is taking the IT world by storm, and if you haven't been working in a cave without internet access you have likely heard about it.
Publisher Name
Atos Consulting CH
Publisher Logo

Leave a Reply

Your email address will not be published. Required fields are marked *