A quick Introduction to Jib

Hey guys, last week I stumbled upon an announcement on the Google Cloud Platform. They presented a new open-source tool which aims to ease the containerization of your Java project. Without even reading the whole announcement, I declared it the topic of my next blog post. Well, here it is 🙂

What is Jib?

Jib is a containerizer for Java applications you can seamlessly integrate into your favourite build management tool (given it is either Maven or Gradle). The essence of the functionality is pretty simple: It abstracts most of the steps of packaging your application into a Docker image and pushing it to a registry. As a result you don’t have to write Dockerfiles and besides that you don’t even have to have Docker installed on your computer, which is pretty cool.

several steps are needed to push your image to a registry
Build flow without Jib
Jib handles all intermediary steps between building your application and publishing a docker image to a registry
build flow with jib

Why should you use Jib?

Google promises three major points that improve your development process if you use Jib:

  1. Simple
  2. Fast
  3. Reproducible

I thought this to be very interesting, as I have been struggling with writing Dockerfiles ever since I started using Docker. I decided to take it easy at first and start out with trying out Jib on a simple Hello World application, since I was a bit cautious because it is still in the beta phase (Version 0.9.6 as of now). My precautions turned out to be partly justified, due to the (to me) confusing credential management.

All examples shown in this post are done with the Maven plugin, the steps and configuration parameters are similar for gradle though.

Hello World

Alright, let’s containerize a simple Hello World application! I’m gonna spare you the Hello World code and jump right into the pom.xml.


As you can see Jib is a simple maven plugin with, in this case, the configuration optionsxml<to> and xml<container>. xml<to> specifies the registry you want your image automatically pushed to and your preferred credential helper. xml<container> lets you configure your image to your likings, just like you would in a normal Dockerfile. You can set the main class, some jvm flags, arguments and the ports you want your container to expose. For a more detailed documentation of the configuration options visit the extended usage part of the jib documentation.

Credential management

I composed this configuration rather quick and as I was already using the wincred credential helper on my Windows 10 laptop and was logged into my DockerHub account, I was certain that it was going to work out of the box. Sadly, it didn’t 😔. It didn’t work because I wasn’t aware that my credential helper had stored my credentials for the official DockerHub API Url “https://index.docker.io/v1/”. You have to store the credentials for the exact URL you specified in the xml<image> tag of your pom.xml, so in my case “registry.hub.docker.com”. Hence, it doesn’t work when you specify a protocol either, as I tried out with the registry URL “https://registry.hub.docker.com”.

This confused me for longer than it should have, because at first I didn’t even know how to store new credentials in the credential helper. Furthermore, there are no examples in the documentation of the plugin nor on the documentation of the credential-helper itself. Eventually, I was able to store the credentials for the example above in the docker-credentials-wincred using the Windows PowerShell with following command:

type .\credentials.txt | .\docker-credential-wincred.exe store

The content of credentials.txt is

    "ServerURL": "registry.hub.docker.com",
    "Username": "craftcodecrew", 
    "Secret": {my-super-secret-password} 

The type command is similar to cat on Linux systems, so the command pipes the contents of the credentials.txt file into the standard input. The docker-credential-wincred application reads from and stores a new credential into the application.
I could have just put the credentials in the settings.xml in my .m2 folder, but I just had to get it done with the credential helper. I realize that this is probably quite a rookie mistake, but Jib is supposed to be especially designed for Java Developers who are not very experienced with containerization.
Therefore, I would have appreciated a little more documentation for the credential management either on the plugin or the credential management website. Hopefully my struggle with the credentials helps you getting your configuration done faster than me.

After I figured this out, the build process worked smoothly and I was able to push my containerized Hello World application effortlessly to DockerHub with the following command

mvn compile jib:build

If this command is too long for you to type you can also bind the Jib containerization to a Maven lifecycle of your liking, for example package. You just have to add a <execution> tag to the plugin definition of Jib


Now you can build a jar, make a container image out of it and finally push it to a docker registry by simply typing mvn package. If that isn’t convenient I don’t know what is. You can try out my awesome Hello world container by typing the command

docker pull craftcodecrew/jibdemo
docker run craftcodecrew/jibdemo

The example code is available in our GitHub organization.


Coming back to the three promises Google made, I can confirm all three of them as confidently as someone who containerized a Hello World application with it. The only real struggle was the fumbling around with the credentials and the credential helper, but that was only partly the “fault” of the Jib plugin. I will try to set up Jib for more complex applications in the near future, propably on some Spring Boot applications, so stay tuned for an update on this post.


About The Author

Leave a Reply

Your email address will not be published. Required fields are marked *