Jib: do we really need yet another container builder?

In a previous article, I wrote about how easy it is to build Docker images using Spring Boot 2.3. Recently, I learned about Jib, Google’s take on building container images for Java applications.

One might wonder if we really need yet another container image builder. In my opinion, Jib has some nice features that make it stand out from the crowd.

It’s easy

Not unique to Jib, but worth mentioning anyway: Jib is really easy to use. Just add the jib-plugin to your Maven pom:

<plugin>
<groupId>com.google.cloud.tools</groupId>
<artifactId>jib-maven-plugin</artifactId>
<version>2.7.0</version>
<configuration>
<to>
<image>${project.artifactId}:${project.version}</image>
</to>
</configuration>
</plugin>

This enables us to build an image and push it to the local registry using:

mvn jib:buildDocker

It’s that simple. By the way, I’m a Maven guy, so you Gradle girls and guys out there will have to come up with your own version 😉

It’s fast!

And by fast, I mean it’s really fast! With a clear cache, it took my about 9 seconds to build an image for a small Spring Boot application.

We can largely contribute this to the distroless base images used by Jib. These images only contain the packaged application and its runtime dependencies.

I wrote a simple Spring Boot HTTP echoserver and compared image sizes. Jib gave me a 214MB image, which is less than Spring Boot’s 276MB and way less than the whopping 395MB Docker produced using Alpine as a base image.

It’s secure

Because distroless images only contain an application and its runtime dependencies, their attack surface is minimal. Therefore, distroless images are considered to be more secure.

Of course, container security is not only defined by the contents of its image, but Jib sure gives us a head start.

It doesn’t need a Docker daemon

To me, this is definitely Jib’s best feature. Jib takes care of the entire building process and doesn’t need a running Docker daemon to do so.

This removes Docker as a dependency from our build environment.

Build pipelines will be more secure, since there is no need for exposing the host’s Docker daemon socket to our build containers.

Unfortunately, it’s not all kittens and rainbows. There are a few downsides to Jib as well.

Only LTS versions

Because there are only distroless images for Java’s LTS versions, we can’t use Jib for packaging our latest and greatest Java 15 applications.

This means we have to stick with Java 11 a little longer, at least until the next LTS version, Java 17, will be released somewhere in september 2021.

More difficult to debug

Images built with Jib are also more difficult to debug than most other Docker images. This is also due to the choice for distroless base images.

Because a distroless image only contains the application and its runtime depencencies, it doesn’t have any of the utilities we often use for debugging, such as ping, curl or netcat.

Also, these utilities can’t be installed as there is no package manager. Heck, there even is no shell to begin with!

Conclusion

All in all, Jib really surprised me in a positive way. Its ease of use and the fact it doesn’t need a Docker daemon will make me consider adopting Jib in future projects.

Don’t forget to checkout my echoserver example project on GitHub 🙂

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Rens Verhage

Rens Verhage

Software engineer. World traveller and scuba diver. Cat lover. Likes rock ‘n roll music and tattoos. Aspiring marathon runner.