10

Spring Boot 2.3.x adds the capability of building a Docker image using their plugin via spring-boot:build-image. Jib seems to allow the same functionality but is not limited to Spring boot.

Is there any specific optimizations that Spring Boot applications avail of that jib does not provide (which is why there's a spring boot plugin for it?)

Aside from being unable to use boot image with a private registry.

Archimedes Trajano
  • 35,625
  • 19
  • 175
  • 265

3 Answers3

13

The main difference between Jib and Spring Boot's image building is that the later uses Buildpacks to create the image. There's a comparison table on buildpacks.io that lists some of the most notable differences.

It's subjective, but the rebasing support is perhaps the most notable. Rebasing an image allows the layer or layers that contain the application code to be rebased on top of a new operating system or JVM layer without having to rebuild the application. This allows OS and JVM security updates to be applied far more quickly than if every application and its entire image had to be rebuilt in order to consume the update.

Andy Wilkinson
  • 108,729
  • 24
  • 257
  • 242
  • Cool now all we need to do is wait for Spring Boot to support private registries in their main line code (looks like it is in the milestones but 2.4.0-M3 isn't working as I understood from their documentation) – Archimedes Trajano Sep 24 '20 at 17:00
11

We want Jib to work well with all frameworks and our continued support for spring-boot is a high priority. If you like jib and you wish to continue to use it, you should see no difference in performance. In fact the spring team has added some configuration into the spring boot tooling that can help container builders everywhere build better containers.

Beyond that, Jib is designed to run anywhere, you don't need a container runtime, you don't need a buildpacks service and as long as you have the source and buildfile you can create a container.

Yes, rebase is valuable, but the comparison on buildpacks.io on why buildpacks are the best is obviously going to have a little marketing magic behind it. Rebase is smooth and easy because of how containers are built. A useful way to start to understand it is Building containers the hard way. The difference in how a rebase works in Buildpacks vs Jib is as follows (I think mostly):

  • Buildpacks: buildpacks base images are defined in a stack, if you chose to use a buildpack, you will use the "run image" supplied in the stack of the buildpack. If you wish to update your base image, that can only occur once the buildpack owner has updated the stacks's "run image" (EDIT: It looks like maybe this isn't true, users can use their own "run image" but I think that messes with the workflow a little?). Then running a rebase will update your image. If this fits your organizations workflow, it works out great. If you wish to be in control of updating your images, then you depend on the upstream to do so.
  • Jib: In jib, while there is a default base image, selection of the image that your application is built upon to is up to you. You can update it at will. Updating your base image is as simple as changing the base image and running a build. Because of how Jib handles caching and reproducibility across systems, you shouldn't encounter any extra costs and the result is the same as a pack rebase. The advantage here is that you are not at the mercy of the owner of the buildpack.
loosebazooka
  • 2,363
  • 1
  • 21
  • 32
4

One important aspect that I think is missing (or not clear enough imo) in the answers from Andy and loosebazooka is that Spring-Boots "create-image" DOES require a Docker Deamon to build. Traditionally creating a docker image build will call a command like "docker build ....". Create-image does something similar and therefor requires a Docker installation, either locally installed, or remote (using DOCKER_HOST setting).

JIB does not have this limitation which could be a plus for your build server.

Mario B
  • 2,102
  • 2
  • 29
  • 41