In the preceding example, we saw how easy it is to have our build package the application in a Docker container. The additional Gradle-Docker plugin does the bulk of the work of the Dockerfile creation, image building, and publishing; all we have to do is give it some instructions on what and how we want the image to be. Because the Spring Boot Gradle plugin uses a boot distribution, the Gradle-Docker plugin does not know that it needs to use a bootified TAR archive. To help with that, we override the distDocker task. Let's examine these instructions in detail:

• The group and description attributes merely help with displaying the task properly when the ./gradlew tasks command is executed.
• The inputs.files project.bootDistTar directive is very important. This is what instructs the distDocker task to use the TAR archive created by the Spring Boot distribution, instead of the generic one.
• The def installDir = "/" + project.bootDistTar.archiveName - ".${project.bootDistTar.extension}" directive is creating a variable, containing the directory where the untarred artifacts will be placed inside the Docker container.
• The exposePort directive tells the plugin to add an EXPOSE <port> instruction to the Dockerfile so that when our container is started, it will expose these internal ports to the outside via port mapping. We saw this mapping while running the docker ps command.
• The addFile directive tells the plugin to add an ADD <src> <dest> instruction to the Dockerfile so that when the container is being built, we will copy the file from the source filesystem in the filesystem in the container image. In our case, we will need to copy the .keystore certificate file that we configured in one of our previous recipes for the HTTPS connector, which we instructed in tomcat.https.properties to be loaded from ${user.home}/.keystore. Now, we need it to be in the /root/ directory directory as, in the container, our application will be executed under the root. (This can be changed with more configurations.)

If you look at the resulting Dockerfile, which can be found in the build/docker/ directory at the root of the project, you will see the following two instructions:

ADD ch6-boot-0.0.1-SNAPSHOT.tar / 
ENTRYPOINT ["/ch6-boot-0.0.1-SNAPSHOT/bin/ch6"] 

The ADD instruction adds the TAR application archive that was produced by the bootDistTar task and contains our application bundled up as a tarball. We can even see the contents of the produced tarball by executing tar tvf build/distributions/ch6-boot-0.0.1-SNAPSHOT.tar. During the building of the container, the contents of the TAR file will be extracted in the / directory in the container and later used to launch the application.

It is followed by the ENTRYPOINT instruction. This tells Docker to execute /ch6-boot-0.0.1-SNAPSHOT/bin/ch6, which we saw as part of the tarball content, once the container is started, thus automatically launching our application.

The first line in the Dockerfile, which is FROM aglover/java8-pier, is the instruction to use the aglover/java8-pier image, which contains the Ubuntu OS with Java 8 installed as a base image for our container, on which we will install our application. This image comes from the Docker Hub Repository and is automatically used by the plugin, but can be changed via the configuration settings, if so desired.

If you created an account on Docker Hub, we can also publish the created Docker image to the registry. As fair warning, the resulting image could be many hundreds of megabytes in size so uploading it could take some time. To publish this image, we will need to change the tag to tag "<docker hub username>/<docker hub repository name>" and add the push true setting to the distDocker task definition in build.gradle:

task distDocker(type: Docker,  
                overwrite: true,  
                dependsOn: bootDistTar) { 
    ... 
    doFirst { 
        tag "<docker hub username>/<docker hub repository name>" 
        push true 
        ... 
    } 
} 

The tag property sets up the created image tag and, by default, the plugin assumes that it is residing in the Docker Hub Repository. This is where it will be publishing it if the push configuration is set to true, as it is in our case.

When launching a Docker image, we use the -d and -P command-line arguments. Their uses are as follows:

• -d: This argument indicates the desire to run the container in a detached mode where the process starts in the background
• -P: This argument instructs Docker to publish all the internally exposed ports to the outside so that we can access them