GCP – Now it’s personal: Containerizing Java applications with Jib
When it comes to building Docker images for Java applications, Jib has become a developer favorite; even if you’re brand new to Docker, Jib can turn any Java app into a space-efficient, optimized container image. Jib builds container images reproducibly in a declarative manner, delivers an impressively short edit-compile-test development cycle, transparently applies container best practices, and doesn’t require you to install Docker or write a script-like Dockerfiles.
Better yet, Jib increasingly supports the broader Java development ecosystem. Since Jib became generally available last year, we’ve really focused on expanding the Jib ecosystem—improving its technical capabilities, but also growing the user base and community. Let’s take a look at some recent highlights.
Introducing the Jib Plugin Extension Framework
Do you love Jib, but wish it could do just one more thing? With the powerful Jib Plugin Extension Framework, now you can easily extend and tailor Jib to your liking. For example, you could write an extension that adds custom image layers whose contents come from a ZIP file. Or, perhaps someone else has written just such an extension. With the Jib Plugin Extension Framework, you can just take that extension and apply it to your project.
First released in June, the Jib Plugin Extension Framework allows you to tweak every aspect of the image you want to build. It’s powered by Container Build Plan Specification–a general, tool-agnostic way to describe how to build an image.
We think that the extension framework opens up a lot of possibilities, from fine-tuning image layers to containerizing GraalVM native images for fast startup or jlink images for small footprint. Check out the Jib Extensions repository on GitHub, where you can discover useful extensions for your builds, and join the core Jib team in creating extensions from which the community can benefit!
Improved app framework support
Spring Boot
Among Java app frameworks, Spring Boot enjoys significant market share, and natively supports creating a fat JAR in its Spring Boot format. But while Spring Boot provides a great developer experience for building Java apps, its approach can be a bit proprietary. We understand the importance of Spring Boot and have been very supportive of implementing first-party integration for Spring Boot in Jib. For example, Jib’s packaged containerizing-mode now works out of the box for Spring Boot, containerizing the original thin JAR rather than the fat Spring Boot JAR that’s unsuitable for containerization.
And that’s just one example of Jib’s native support for Spring Boot. For example, we recently released the first iteration of Maven and Gradle Jib extensions for Spring Boot, which provide a convenient way to address the long-standing “spring-boot-devtools” issue. Going forward, we also plan to enhance first-party support via the extension framework to improve the user experience.
Quarkus
Quarkus is another framework that is gaining in popularity. You could already direct Quarkus to create an optimized image with the core Jib engine without applying the Jib build plugin. However, we also wanted to support Quarkus for Jib build plugin users. To that end, we published first-party Jib Maven and Gradle extensions to cover Quarkus’ special containerization needs. Compared to Quarkus’ built-in Jib engine-powered containerization, using Jib build plugins enables finer-grained control over how to build and configure your image (and now even more so with the Jib Extensions Framework).
GraalVM
Finally, for GraalVM “native images” (not to be confused with container images), now there’s a Maven Jib extension. In the near future, we also plan to add support for Gradle.
Improving CI/CD performance
Did you know that Jib can build and push an image without having to download a base image? As such, it’s no surprise that a lot of organizations use Jib as an image building tool to augment their CI/CD tools. Using Jib as a part of your CI/CD process saves you time, bandwidth, and space.
For example, without Jib, when you write FROM openjdk:11-jre-slim in Dockerfile, the Docker engine first downloads a base image that includes a large JRE. And because with CI/CD, you don’t normally save and restore the internal image cache of a Docker engine, your CI/CD environment must re-download the same base image every time you run a new pipeline. But Jib is smart and skips downloading a base image whenever possible. This will always be the case unless you are pushing an image to a completely empty repository for the first time.
Better local Kubernetes development with Skaffold
Jib works out of the box with Skaffold File Sync. Using the keyword auto, you can take advantage of remote file synchronization to a running container with zero sync configuration. This mechanism is designed to build and sync your files as you change them without having to configure the sync block in your skaffold.yaml. Check out the documentation for more information.
Setting a course for Java containers
Jib has come a long way since it went GA, and now has a sizable community around it. The core Jib team has been working hard to expand the ecosystem, and we’re confident that the community will only grow larger. If you have questions or feedback, visit our Gitter channel or the GitHub repo. You can also ask questions on Stack Overflow.
We think everyone should use Jib to simplify and accelerate their Java development—and to build their container images right. To get started with Jib, check out our samples and these Codelabs:
Read More for the details.
