Add support for publishing docker images to a registry

[philwebb]

Currently we don't have the option to publish a locally built docker image to a remote repository. You can do it using the docker CLI, but it would be nice to have some built in support.

[jorgemoralespou]

I don't think this use case should be something the spring-boot maven plugin should do. If it did, shouldn't it also need to include goals to deploy the application/image into different platforms?
I think that users should stick to using multiple plugins rather than have one single plugin that does it all (not saying can't be provided by spring-boot). I saw that pattern in fabric8 maven plugin, and they had to slowly rollback and break that plugin into smaller ones, more single purposed.
My 2 cents.

[jorgemoralespou]

I think then thy my comment is not outdated. #21001 (comment)

[philwebb]

@jorgemoralespou Can you elaborate a bit more on the problems we might face? I was originally thinking we might be able to shell out and call docker push. I think that's currently how jib deals with it.

[jorgemoralespou]

Well, there's 2 sides:

• Technical: You'd need to be able to support private and insecure registries, and you'd need to interface with Docker on Windows/Mac/Linux in different ways, so better to not shell out to docker but rather use a library that can deal with the pushing direclty.
• Strategically: To me this is the real deal. If the spring-boot plugin start doing this, then what else? where's the line of what should be done in this plugin vs other plugins? To be honest, maven/gradle users know how to configure multiple plugins and how to call them, so what would be the difference of doing something like: mvn spring-boot:build-image spring-boot:push-image vs mvn spring-boot:build-image other-plugin:push-image.? I have in mind fabric8 times, now jKube and they struggle and broke it down as it was doing just way too much in a single place. Single purposed plugins that can be composed should be favoured in my opinion.

[philwebb]

If there was a single purpose Maven and Gradle plugin that we could lean on and perhaps automatically configure (so you don't need to give the image tag) that would be an ideal option. The only one I found when looking previously was jib, and pushing isn't really a stand-alone feature. I also didn't have much luck finding a Java library that can talk to the registry, only Go and Python seem to exist. Perhaps RegistryClient from jib will be extracted into a library at some point.

[scottfrederick]

Images can be tagged and pushed using the Docker daemon API, letting the daemon do all the work. We're in the process of adding support for authenticating to a registry from the daemon, which should suffice for pushing also.

We've generally tried to maintain parity between the Boot plugins and the pack CLI. pack supports pushing to a registry with a pack build --publish option. I don't think there's much risk of scope creep with just adding a comparable feature to the Boot plugins.

[theHilikus]

the way the maven lifecycle is structured, it seems to me that publishing should be separate from building. the build-image goal attaches to the package phase, which makes sense, but not publishing. That should be done in the maven deploy phase. I haven't been able to find a way to only build in package and only publish in deploy. Am I missing something?

[scottfrederick]

@theHilikus There is some discussion of this in #26187. We've tried to keep the focus of the Spring Boot build plugins on Cloud Native Buildpacks integration, and avoid adding features to cover the full lifecycle of an OCI image.

[theHilikus]

I missed that ticket. thank you