Support for optional and alternative docker image builder for secure, smaller and faster image builds #138
Hi @rhs, thanks a lot for maintaining this great project
For example, many docker images for rails/npm/golang/etc apps suffers from one or more reasons below:
Why not docker multi-stage builds?
Docker multi-stage builds are great as long as what you need is public library deps only.
With multi-stage builds, you'll likely end up with two images at minimum.
CAUTION: There's multiple bad points in the example below. Do not use it in production images!
What's the problem?
is very very suspicious.
If you aren't very keen for fast docker-builds, it is ok.
Where's the secrets? The metadata of the docker image.
You can see the secrets remaining in the metadata by running
ADD secrets instead of ARG?
The outcome is almost the same - except you end up leaving your secrets inside one of docker image layers instead of the image metadata now.
I believe the third point can be addressed with forge + imagebuilder.
With imagebuilder, you can basically run
imagebuilder also supports squashing for producing smaller images, faster builds because it doesn't upload a build context.
The text was updated successfully, but these errors were encountered:
I have an updated for the source-to-image thing.
What are supported/unsupported
In nutshell, it supports creating a build-pipeline either for:
In my understanding, what forge's incremental build supports is 1. above.
In other words, both doesn't support an advanced pipeline of:
What's an use-case for that?
For example, a typical internally-developed rails app would have rubygems hosted on private GitHub repos as its library dependencies. You would want to cache them so that your CI build doesn't download the library deps again and again.
You'll also want to use a different runtime image for your app. That's because your builder image may contain various *-dev(el)( packages from your linux distro containing header files for your packages like imagemagick, libxml, etc.. The header files are needed in order to successfully gcc-build ruby native extensions included in gems, but unneeded at runtime. So, ideally you'll want to exclude those *dev(el) packages from the runtime image.
source-to-image users seem to chain multiple s2i calls for that as a work-around.
Openshift does seem to have an out-of-box support in their in-cluster builder.
However, there seem to be no cli-based build tool supporting this advanced use-case.
Allow specifying an arbitrary command as an
Also, I'd like to support differentiating runtime vs builder image in service.yaml, so that forge could use an another(runtime) image other than the ones used as builders. It will perhaps require us to specify which artifacts are copied from the builder image to the runtime image.
I have no concrete design idea about the second point yet. So, please let's me POC it if this makes sense.
Hi @rhs, sorry for the lengthy post again. I'd appreciate it if you could review the idea.
I'm willing to contribute anything I can but not exactly sure what we really need.
I'm also unsure if this fits within the scope of forge. I myself believe it fits nicely to forge because all the other laternatives are low-level compared to forge(for example source-to-image only supports building image, wheares forge supports app lifecycle management), or requires you to write adhoc scripts/makefiles.