1

I am fairly new to JavaEE, so I have some concepts still missing. I am learning Docker to use it in our DEV / CI Build environments. I could make it work on my machine. But for it to work in the CI server, my current approach would be to store the docker-compose.yml and dockerfiles in git and, in the CI server download it, build the images and start it.

To setup the docker image for the web container (Wildfly) I had to add:

  • DB Drivers (.jar files)
  • Standalone.xml (.xml file)
  • Modules we use (mix of .xml and .jar files)

But these files are not present in the CI server. I could download the DB drivers when building the image, but the modules and standalone.xml are not available online.

Is this approach the reasonable? If so, where would one store these files so they get updated when needed and the CI Server is able to download them to build the image?

2

For point 1. and 3. You could create private Ivy repository and fetch DB Drivers and Modules from it via your Build tool ( Mvn, Ant, Gradle support getting dependencies from Ivy repos ) when building your app.

And for .xml files - you can have git repository for your Test Environment config files. Or have them encrypted in your app repository, and configure CI script to encrypt those files with key that will be embedded in that CI script. ( encrypt, so people with git access to your app won't get password to your test DB )

  • I am going this path, except for the encryption because it is a experimental project and I am the only one with access. Nothing serious is stored there. If I store the test env files in their own repo, where would I store the production ones? (In the same repo, but encrypted?) – JSBach Jan 29 '16 at 8:35
  • 1
    I just have example.conf with filled all options app needs, just without password, and then I provide passwords during deployment phase ( via Ansible ). – Marqin Jan 29 '16 at 10:52
1

You need a reproducible build - this means you do not want your CI server downloading things from the internet on demand. You need to download them and otherwise collect everything needed for the build and store it somewhere accessible to the CI server.

Now the easiest and most future-proof way of doing that is to store these things in their own source-controlled repository. Then you can update it or create a new set from different configurations with ease. You can also build a historical version if necessary.

So: create a new repo for your Docker config, put what you need in there, and have your CI server grab both the docker config and application files from both repositories when it builds. You could even put the docker config in your source repo in a different directory if it makes more sense to you.

Alternatively, you can store these things on the CI server directly as an installation of build tools (eg you already have to install a JDK) and simply keep it referenced as a known pre-requisite to setting up your system. The decision over which to use usually comes down to the size of the files.

  • I am not able to store anything in the CI Server, because it is a hosted solution that builds VMs for each build. But I get the overall idea, which seems very interesting :) – JSBach Jan 29 '16 at 8:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.