Configuration files and environment properties

General
1

I’ve spent a few days looking at docker and I think its really cool, I’ve done a lot of tutorials and exercises which has been fine but I’m struggling to see the bigger picture and would like some real examples.

The main thing I’m struggling with is how people manage environment variables and config files for different environments such as dev, uat and production whilst having one image that can be deployed anywhere.

Ive experimented with passing arguments to docker run but this doesn’t seem practical.

Currently we use puppet templates to manage all of the config and puppet installs and sets up httpd etc bit seems with docker all of this is embedded inside the image.

2

typically for files, config, lists of env, etc… one would put them in a folder and then mount that folder in the container, and the startup script would use them .

3

Well that seems ok, at your workplace how do you manage this config and how do you deploy it to the mount on the vm your container is running on?

Are you working with maven and jenkins?

4

the configs are in git, like the code. and so we git pull the appropriate level data to the docker host.
in some cases the mount can BE the folder with the few files in it. sometimes you need to copy them in over the few… depends on the components…

but docker is really intended to do one thing per container, getting all those containers working is always fun…

but the images generally don’t change if u do it right… they ARE infrastructure.

we use maven and gradle and jenkins.

5

Thanks for replying it’s very interesting. Do you build your images as part of your maven build and embed the war files into them at that point?

I’m looking to get a simple maven multi module app building into containers tomorrow as a proof of concept.

Ideally the war files could be ran in any environment regardless of such things as config and necessary properties such as the url’s to other services.

Appreciate the replies it’s very helpful.

6

build the war, but put it on a folder too and load it from there… no container changes…

server and java version are infrastructure… build it once, no changes allowed

app stuff is loaded from outside via config…

you need to upgrade server/java… new image, same setup…

need to lock it (production app runtime version), then make a container that IS the volume, and do volumes-from runtime container to get the files to run … (not host volume)

for test, use the host volume

7

Ah ill try this approach tomorrow morning. At the moment I’ve been embedding the war file in the image and deploying it that way.

Thanks.

8

yeh, been there… too much changes. someone gets an image somehow… what is in it… too much to track…

9

set a rule,
nothing app version volatile allowed to be stored in an image

10

then u don’t change the public images… http, db, java server, etc,etc,etc…