Over a million developers have joined DZone.

Docker Containers With Gradle Application Plugin

After trying several different approaches, we came up with what we think is the most elegant way of integrating Docker into our build tool Gradle.

· Integration Zone

Is iPaaS solving the right problems? Not knowing the fundamental difference between iPaaS and dPaaS could cost you down the road. Brought to you in partnership with Liaison Technologies.

Docker and Gradle have been around for a while, and there are many tutorials, blog posts, etc. related to best practices. After trying several different approaches, we came up with what we think is an elegant way of integrating Docker with our build tool Gradle. What follows is a simple and elegant integration of the two technologies.

First, let's simply start with why we chose and how we can use Gradle's Application plugin without getting into Docker yet. The Application plugin works hand in hand with Groovy, Scala, and Java plugins to create an executable JVM application. Using the Application plugin itself also implies application of the Distribution plugin. So, when it comes to deciding what plugin to use for making executables, the Application plugin is the most official way of doing things.

Sample build.gradle snippet:

apply plugin: 'scala' //this could be java or groovy
apply plugin: 'eclipse' //eclipse is my favourite ide
apply plugin: 'application'
apply plugin: 'maven-publish'

sourceCompatibility = 1.8
targetCompatibility = 1.8
version = '1.0.0-SNAPSHOT'

sourceSets {
  main {
    scala { srcDir 'src/main/scala' }
    resources { srcDir 'src/main/resources' }
  }

  test {
    scala { srcDir 'src/test/scala' }
    resources { srcDir 'src/test/resources' }
  }
}
dependencies {
  compile 'org.apache.commons:commons-math3:3.5'
  compile 'org.scala-lang:scala-library:2.11.7'
  //Test
  testCompile group: 'junit', name: 'junit', version: '4.11'
}
//application plugin wants you to set mainClassName and jvm args
mainClassName = ""com.coolcompany.coolapp.Swag""

applicationDefaultJvmArgs = ['-Dconf=conf/config.json',
   '-Dlog4j.configuration=file:conf/log4j.xml',
   '-Xmx3g',
   '-Xms3g',
   '-XX:MaxGCPauseMillis=100',
   '-XX:+UseG1GC',
   '-XX:+UseCompressedOops',
   .....etc.]
repositories {
  maven {
    credentials {
      username nexusUsername
      password nexusPassword
    }
    url myPublicUrl
  }
}
publishing {
  publications {
    mavenJava(MavenPublication) { from components.java }
  }
  repositories {
    maven {
      credentials {
        username nexusUsername
        password nexusPassword
      }
      if(project.version.endsWith('-SNAPSHOT')) {
        url mySnapshotUrl
      } else {
        url myReleaseUrl
      }
    }
  }
}

task copyConf(type: Copy) {
  from System.getProperty('user.dir') + ""/conf""
  into ""$buildDir/conf""
}

task createConf {
  def conf = file(""$buildDir/conf"")
  outputs.dir conf
  doLast {
    conf.mkdirs()
    copyConf.execute()
  }
}
//here we copy application config into the distribution zip or tar
//When we apply docker plugin this will be added to root path
//so it will be extracted under the root directory of container
//and we will have our config files under /conf in container
distributions {
  main {
    contents {
      from(createConf) { into ""/conf"" }
    }
  }
}
//just in case, this I find useful to add it makes my eclipse more stable with
//eclipse STS plugin
eclipse.project {
  natures 'org.springsource.ide.eclipse.gradle.core.nature'
}

task wrapper(type: Wrapper) { gradleVersion = '2.10' }

Since we have a conf folder under the project dir, when we run this, the application can find the config file with no problem. And, the application starts immediately:

$ gradle run

Sample Main which reads the ""conf"" that we provided explicitly, now looks like this:

object Main {
  def main(args: Array[String]) = {
    new Main(JsonFileReader(System.getProperty(""conf""))).start
  }
}

We can also generate start scripts and distribution .zip or .tar in the following way respectively:

$ gradle startScripts
:compileJava
:compileScala
:processResources
:classes
:jar
:startScripts

$ gradle distZip
:createConf UP-TO-DATE
:compileJava UP-TO-DATE
:compileScala UP-TO-DATE
:processResources UP-TO-DATE
:classes UP-TO-DATE
:jar UP-TO-DATE
:startScripts UP-TO-DATE
:distZip

$ gradle distTar
:createConf UP-TO-DATE
:compileJava UP-TO-DATE
:compileScala UP-TO-DATE
:processResources UP-TO-DATE
:classes UP-TO-DATE
:jar UP-TO-DATE
:startScripts UP-TO-DATE
:distTar

If you check out the build/distributions folder under the project dir, you will notice .zip and .tar distributions are placed in there. If you want to extract the distribution that we just created, you can clearly see the conf folder is under the root of distribution. The bin folder for the start scripts and lib folder for dependencies are also placed there.

Now, let’s integrate the work that we have done so far with the Docker plugin. I found transmode's Docker plugin very useful for this purpose.

First, let's include the plugin:

apply plugin: 'docker'

buildscript {
  repositories {
    //this plugin will be pulled from jcenter
    jcenter()
  }
  dependencies {
    classpath 'se.transmode.gradle:gradle-docker:1.2'
  }
}

This plugin is well-integrated with Gradle's environment. Since our project is targeted for Java 1.8, it will automatically pull the base Docker image for Java 1.8, but we can extend this to use our own base image like this:

docker {
  baseImage = 'sercankaraoglu/vertx-base'
  maintainer = 'Sercan Karaoglu ""hsercankaraoglu@gmail.com""'
}

Now, if we run:

$ gradle distDocker
:createConf UP-TO-DATE
:compileJava UP-TO-DATE
:compileScala UP-TO-DATE
:processResources UP-TO-DATE
:classes UP-TO-DATE
:jar UP-TO-DATE
:startScripts UP-TO-DATE
:distTar UP-TO-DATE
:distDocker
Sending build context to Docker daemon 29.39 MB
Step 1 : FROM myprivatehub/vertx-base
 ---> 16d8873912e5
Step 2 : MAINTAINER Sercan Karaoglu ""hsercankaraoglu@gmail.com""
 ---> Using cache
 ---> 7505292ed65a
Step 3 : ADD myapplication-1.0.0-SNAPSHOT.tar /
 ---> a46be501eec7
Removing intermediate container 754c3d0875ad
Step 4 : ENTRYPOINT /myapplication-1.0.0-SNAPSHOT/bin/myapplication
 ---> Running in c417920ee712
 ---> 4e1e25abd53c
Removing intermediate container c417920ee712
Successfully built 4e1e25abd53c


BUILD SUCCESSFUL

Total time: 2.189 secs

Notice that the entrypoint to this image is a start script generated by the application plugin. Since the working directory of this image is root dir / when the application searches for conf/app.conf it will look to the path /conf/app.conf. Now, notice Step 3 above. It extracts distribution .tar under the root, so conf will be placed under the /conf/app.conf just as we want.

Now, you can run the image like this:

$ docker run myapplication:1.0.0-SNAPSHOT

Let's imagine that we want to expose 8080 port. We can do this using the Docker plugin like this:

distDocker {
    dockerfile {
        expose 8080
    }
}

That is pretty much it, I hope that you find this very helpful.

Discover the unprecedented possibilities and challenges, created by today’s fast paced data climate and why your current integration solution is not enough, brought to you in partnership with Liaison Technologies.

Topics:
docker containers ,gradle ,application ,continous integration ,deployment ,build

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

SEE AN EXAMPLE
Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.
Subscribe

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}