Should we be distributing docker images or just DockerFile with its files as we do now?

[huntc]

Should the stage task produce a docker image instead of a DockerFile and its associated files?

My thought process here is that stage is generally the prequel to dist in that the latter archives the former. If one was to distribute "docker" artifacts then, would those artifacts be images or would they be DockerFiles?

I'm now starting to wonder whether the artifact for distribution should be an image (which is a tgz), and therefore not a DockerFile and its associated files.

Supposing that images are produced for stage i.e. a docker build is run on some DockerFile created in a work folder, then publishLocal and publish are not going to have to perform the build step.

Most importantly, if something wants to skip the docker registry, or any private registry and just distribute docker artifacts, then an image seems more natural. Images do not require a build step in order to be run at runtime; docker load can be used.

WDYT?

[huntc]

One thing against this strategy is that when saving images for the purposes of subsequently loading, the files are quite huge. For example, saving an image resulted in a tgz around 1GB in size. :-)

I had always thought that the images could be saved and shipped around in their layer form, but unless I'm missing something, perhaps not - perhaps only the final image can be distributed.

[alari]

It should produce Dockerfile with files!

Right now I'm fixing Dockerfile to split image into two layers (with 3rd party libs and app itself) using bash. Also I'm fixing problems with permissions. (There are tickets for both issues I'm fixing by hands)

It would be impossible without Dockerfile and files.

[muuki88]

The splitting up is a big topic. We had a lot of discussions and a first proof-of-concept for naive splitting method. I hope to provide this as a autoplugin soon.

[huntc]

Note that my question doesn't suggest that there is no DockerFile generated. If we were to generate an image for stage, they'd still be a pre-task to build the image from the DockerFile.

The question is really asking whether images are a viable artifact for distribution. I'm now thinking not given their size. I will close but please feel free to continue the conversation. Thanks!

[mhamrah]

I like the current stage, publishLocal and publish tasks. There are plenty
of use cases where you want to edit the dockerfile, and I believe stage is
the best place for that.

On Tue, Dec 2, 2014 at 2:23 PM, Christopher Hunt [email protected]
wrote:

Note that my question doesn't suggest that there is no DockerFile
generated. If we were to generate an image for stage, they'd still be a
pre-task to build the image from the DockerFile.

The question is really asking whether images are a viable artifact for
distribution. I'm now thinking not given their size. I will close but
please feel free to continue the conversation. Thanks!

—
Reply to this email directly or view it on GitHub
#425 (comment)
.

[huntc]

I like the current stage, publishLocal and publish tasks. There are plenty
of use cases where you want to edit the dockerfile, and I believe stage is
the best place for that.

Again, I wasn't proposing that the DockerFile generation would disappear - whether it was the stage task or a dockerFIle task, there should be no difference. DockerFiles are still required to build the image of course.

BTW: Do you actually edit the DockerFile post stage? If so then I wonder if that is as a result of the generation not being good enough for all needs. Having a specific dockerFile task yielding a multi-line string, and is therefore entirely overridable may be the go here for that use-case.

[alari]

BTW: Do you actually edit the DockerFile post stage? If so then I wonder if that is as a result of the generation not being good enough for all needs. Having a specific dockerFile task yielding a multi-line string, and is therefore entirely overridable may be the go here for that use-case.

+1. We need more control over Dockerfile contents. But generally it's due to the immaturity of Docker support in SBT. Once most of current issues are solved, most of us won't need to change anything by hands.

But until that, it's good to have an option to fix Dockerfile in any manner.

[muuki88]

Okay. So @huntc you could provide a pr which adds an intermediate task that returns the dockerfile. From the outside everything stays the same?

[huntc]

Sure thing - I'll work on a PR - it'll be in the next 2 weeks though due to conferences next week etc. etc.

[muuki88]

no problem. at the moment the whole sbt native packager crew seems pretty busy :(