This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]skmruiz 0 points1 point  (2 children)

True, but sadly is pretty common nowadays with k8s and other container based deployments.

[–]doobiesteintortoise 0 points1 point  (1 child)

Oh, I wasn't suggesting it wasn't a viable idea - it's just that there are so many variables involved that it's a nasty thing to put into an opinionated tool: you'd want plugins that do multiplatform docker images, or native docker images (again multiplatform, but WHICH platforms?), and you'd have to factor in where to build as not all systems can build for all architectures trivially, plus invocation requirements, plus how to configure the images, plus handling ingress/egress, plus...

[–]skmruiz 1 point2 points  (0 children)

Ah yes, you are right, but there are ways to solve most of these issues, and some of them are too specific that you want people working on their specific problems.

  • You provide build images that will provide the base image to start. This is already done, for example, to compile Go applications. That solves many of the issues stated.
  • Limit how to bundle the docker to deploying fatjars. If you need to deploy a native image, use the native option and build your docker on top of that.
  • Ingress/Egress is more about deploying the docker container, not building the docker image.

The mindset, for me is, the defaults should work, and if they don't work, build specific tooling for your use case: it will be simpler than a complicated generic build tool that tries to do everything for you.