Continuous Delivery is just another buzzword if it's not an accomplished fact, and part of your daily routine. Ideally, this means "No Excuses" - including cost and effort.

 

Docker is the last domino to fall in this chain of events. We can now take anyone from a standard Java workspace to Continuous Delivery - "No Excuses" style - running on their favorite cloud or data center server.

It's not totally automated, you still have to go in manually and set up your Jenkins and Nexus servers with the appropriate project metadata via the UI. But that's too little work left to make for a good excuse not to do Continuous Delivery. Few minutes and you're done.

Side Note: Two separate hard core devops friends have now - each individually - called us on the carpet for even using a technology "that required touching a UI". A complete blasphemy. My o my, how quickly our world has changed.

To Start - A Very Standard Java Workspace/App

  • Written in Java - a corporate standard.
  • Comprised of many projects of modules
  • Deployed to Tomcat as webapp
  • Built and also released via Maven
  • Binaries archived on Nexus
  • Source committed to Git (Bitbucket in our case)
  • Jenkins as CD server.

Each of the above has great alteratives - Gradle for Maven, SVN for Git, etc. These are not discussed here - but neither would a change in one of these create an excuse to not migrate to Continuos Delivery.

Server Setup

  • One real or VM server as minimum number, to eliminate cost as an excuse.
  • Docker containers for each of
    • Tomcat
    • Nexus
    • Jenkins
    • data, for all of above

So the basic idea is that anyone can afford to fire up a single Rackspace or AWS server, or else fire up one in the enterprise or even in your house or even, god forbid, as a separate VM on your own box. No Excuses, yada yada.

Once you have that server, Docker maintains each of the containers so that you can allocate resources appropriately, and your build/release never gets to starve your running app.

What It Looks Like

We set this up for our SMOSLT research app. Pretty much exactly how you'd expect. One each of 3 different webapp views.

  • Tomcat
  • Nexus
  • Jenkins

How It Runs

  • Your box is set up to run Chef 11 and above
  • Familiarity with Chef test-kitchen for running locally first
  • Download df_box_smoslt from github
  • Test on your own box
  • Run on designated server or vm (AWS, Rackspace, etc)
  • Manual configuration using UI
    • Each Java project is a Jenkins project
    • Set up releases and binaries in Nexus
    • Set up release deployment and build deployments in Jenkins and Maven both

Backup and Recovery

We detail the backup and recovery piece here, but the high level is that if things go south, modest preparation will let you recover pretty painlessly because of a separate "data container". You DO need to script a tar and scp command to a remote server for double protection, but that's easy and fast.

We tested this ever so loosely and by blowing away and re-creating both Nexus and Jenkins containers. Worked flawlessly, at least for that one test.

Glossing Over Some Details?

The details that are missing above are training issues. You get familiarity with Jenkins, Nexus, Maven through the years. We could be more explicit, but then we'd be duplicating great documentation which is already out there, and not to your benefit, either.