Create Docker image without daemon by using Jib

[sdx-jkataja]

Change the build to use jib Gradle plugin, which can build container images without needing the Docker daemon and able to build cross platform images. See:
https://github.com/GoogleContainerTools/jib/tree/master/jib-gradle-plugin

Fixes #1

[thgoebel]

Thanks for the PR! I will respond with more details next week.

From a quick skim, I can already say that we would like to keep the Gradle files as Groovy. The benefit of Kotlin is small (it's still a custom DSL, not "straight-forward" Kotlin syntax). We'd rather keep all our projects in Groovy, to make it easier to copy things between projects. Maybe in the future we'll migrate all projects to Kotlin.

[thgoebel]

If we make these reusable, we should use Version Catalogs: https://docs.gradle.org/current/userguide/version_catalogs.html

[sdx-jkataja]

Right, I wasn't aware such thing exist. My concern is that will automated patching tools like Renovate and Dependabot be able to interpret and modify that? I would do this change in a separate pull request.

[thgoebel]

I don't know. But since Version Catalogs are a first-class Gradle feature, I would expect these tools to implement support for that (if they haven't already).

[sdx-jkataja]

Thanks for the PR! I will respond with more details next week.

👍

From a quick skim, I can already say that we would like to keep the Gradle files as Groovy. The benefit of Kotlin is small (it's still a custom DSL, not "straight-forward" Kotlin syntax). We'd rather keep all our projects in Groovy, to make it easier to copy things between projects. Maybe in the future we'll migrate all projects to Kotlin.

I see. My point of view is that Kotlin is more general purpose language, while Groovy is just used in Gradle build scripts. I strongly prefer to use the more general purpose language and try to avoid use case specific languages where I can. I used ChatGPT for the initial porting work.

For bootstrapping new Spring Boot projects the Spring Initializr is really helpful as it can generate the project with reasonably good output and avoids needing to copy the build files around: https://start.spring.io/

[sdx-jkataja]

Rebased on 1658768

[thgoebel]

Regarding Jib: I'm also not yet sure if we want to use this. Specifically, if Jib is the level of abstraction that we want. It is another magic tool that developers need to learn and understand.

For context: The docker { ... } from the com.palantir.docker plugin stemmed from copy&pasting from an old template. We haven't actually built a Docker image for the Fireblocks Custom Server with it. So I removed the plugin in b0b4e57.

As mentioned in https://docs.securosys.com/fireblocks/download, we don't have prebuilt Docker images for the Fireblocks Custom Server yet. I am using this opportunity to survey all the Securosys-internal Spring Boot projects and will look into how to unify/modernise/streamline the image build process.

From what it looks right now, we won't be taking the changes in this PR 1:1. We'll most likely pick a few things (like adding OCI labels) and leave others (like the Groovy->Kotlin). I already picked your change to remove the exec bits: 87dd36a

[sdx-jkataja]

Regarding Jib: I'm also not yet sure if we want to use this. Specifically, if Jib is the level of abstraction that we want. It is another magic tool that developers need to learn and understand.

Jib is very widely adopted with 14k stars: https://github.com/GoogleContainerTools/jib
There is nothing magic and everything is packaged with the Gradle plugin, it just packages the JAR and files into a new image layer on top of the base image, without needing a Docker daemon or Dockerfile.

For context: The docker { ... } from the com.palantir.docker plugin stemmed from copy&pasting from an old template. We haven't actually built a Docker image for the Fireblocks Custom Server with it. So I removed the plugin in b0b4e57.

Understood. I require a Docker image to test the full deployment.

As mentioned in https://docs.securosys.com/fireblocks/download, we don't have prebuilt Docker images for the Fireblocks Custom Server yet. I am using this opportunity to survey all the Securosys-internal Spring Boot projects and will look into how to unify/modernise/streamline the image build process.

Understood.

From what it looks right now, we won't be taking the changes in this PR 1:1. We'll most likely pick a few things (like adding OCI labels) and leave others (like the Groovy->Kotlin). I already picked your change to remove the exec bits: 87dd36a

Alright, you are welcome to use anything you need and leave anything you don't.