sbt-native-packager

sbt-native-packager copied to clipboard

https://very-serio.us/2018/02/27/zen-minimalism-with-distroless-images/

It may be interesting to have these base images as an option. Due to their nature, they would require a separate startup script etc.

Thanks for the information :smile:

The multistage build shouldn't be an issue as this is a docker "internal" feature. You can define the dockerCommands freely.

Due to their nature, they would require a separate startup script etc.

Can you elaborate on this? I haven't any production experience with docker (only for small dev environments). What changes would be required? What can't be done with current native-packager implementation and what is boilerplate that we should provide?

The startup scripts currently depend on either bash or ash. Neither are available in these distroless images. Applications are meant to be started with the java command directly.

When I have some free time, I may do some more research into the possibility of integrating the images.

Sounds great 🤩 thanks for spending your spare time on this if possible.

I guess the start command can be built from the classpath and javaOptions.

I got this working with a bit of hackery: https://github.com/jamesward/hello-uzhttp/blob/master/build.sbt#L25-L37

Note the use of the LauncherJarPlugin

Thanks a lot for sharing :hugs: @jamesward Even with the new docker layering implementation :nerd_face:

So this doesn't require toooo much, right?

• new dockerBaseImage
• LauncherPlugin enabled
• ExecCmd altered

This can be an archetype plugin that applies these settings, requires the LauncherPlugin and then this should work. Probably I'm missing something here :thinking:

Yup! It'd be great to have support for this somehow built-in. Note that some of the usual user permission & intermediate layer removal stuff don't work due to the absence of usual unix tools in the base image.

Oh, and the ENTRYPOINT on gcr.io/distroless/java basically is java -jar so that is why just the jar file needs to be specified as the CMD but I'm not sure if that is a pattern for other slim Java base containers.

I was planning to check distroless images this weekend but @jamesward was first :) I played around and tied his code with the DockerPlugin. https://github.com/jamesward/hello-uzhttp/pull/1 Maybe it would be even better to put xxx.jar path in the entry point. This makes possible to pass args[] to the main class.

Yup! That is a great way to do it. Thank you.

@ppiotrow that looks pretty straightfoward :heart: Would you like to put this into a small archetype plugin? The last pull request was already amazing :wink:

I don't know about archetypes. Is it better than just having example in external repository? I plan to focus on file creation timestamps in docker images first, maybe someone else?

I plan to focus on file creation timestamps in docker images first, maybe someone else

That's amazing as well. Pick what ever you like. I'm happy for all contributions :heart_eyes:

I don't know about archetypes. Is it better than just having example in external repository?

That's probably a good start. And often enough :+1: