Docker Refactoring - Parent Issue

[muuki88]

This parent issue summarizes the docker feature requests and improvement suggestions:

• Permission denied to execute entry point in Docker #331 Permission denied to execute entry point in Docker
• Add command in Dockerfile #385 Add command in Dockerfile
• Ability to override entrypoint when building docker containers #410 Ability to override entrypoint when building docker containers
• packageName in Docker not found #413 packageName in Docker not found
• Optionally inherit docker entrypoint, and cmd #433 Optionally inherit docker entrypoint, and cmd
• Created Volumes in Docker plugin, are not owned by daemon. #485 Created Volumes in Docker plugin, are not owned by daemon

In order to get a better user experience, we should refactor the DockerPlugin
in a way we meet all these requirements.

@fiadliel first intention when building the plugin was to be as restrictive as possible and
build a working "out-of-the-box" solution. I still think this is a good idea and keep the
working "out-of-the-box" policy, when refactoring.

Goals

• Working "out-of-the-box"
• Customize every docker command

State of the Art

At this point every configuration for the dockerfile is represented by
a custom setting:

Docker Command	Setting
FROM	dockerBaseImage
MAINTAINER	maintainer
ADD	hardcoded
WORKDIR	dockerBaseDirectory
RUN	hardcoded
ENTRYPOINT	dockerEntrypoint, executableScriptName
CMD	hardcoded
EXPOSE	dockerExposedPorts
VOLUME	dockerExposedVolumes

Possible Solutions

There are two obvious solutions that could be implemented

Setting per Command

Continue the current implementation and provide a setting for each
docker command.

Pro	Con
User can list available settings	New commands must be added manually
Less error prone as every cmd is testable	Too many settings

List of Docker Commands

A Dockerfile is a simple list of commands (CmdLike). We could expose
a setting TaskKey[Seq[CmdLike]] that gets filled by default. Users can remove,
add, replace commands as they like.

Pro	Con
More like native Docker	More complex to alter
Full customizable	Untested commands may cause strange behaviour

[huntc]

Nice summary!

[muuki88]

Do you have time for hangout/skype call? It would be awesome if we could tackle
this issue together :)

[muuki88]

Call Summary

We will take a hybrid approach like sbt/sbt-rjs and provide the
important settings as sbt settings. These will all get aggregated into an single setting (e.g. dockerCommands), which is used to generate the Dockerfile.

Important points are

1. Only commonly used docker commands will be added as sbt settings
2. Documentation for customizing the dockerCommands setting is very important

Implementation

I don't have much time for the next, as well as @huntc .

@fiadliel do you have any suggestions/additions?