Ability to override entrypoint when building docker containers

[mhamrah]

I've been doing work with hashicorp/envconsul and docker. Envconsul automatically monitors a Consul service-discovery endpoint for changes and will reload your application when a setting has changed. You use it by wrapping it around a command, like so:

envconsul settings-key-prefix bin/your-awesome-native-packager-app

There's also few command-line arguments you should add as well. My immediate reaction was to modify the bash script template to use envconsul to call the application, but that would be a global change and would force envconsul to be available and the consul service running. Instead I just want to do this with docker so I can use an envconsul enabled docker container.

I believe the best way to do this is overriding the entrypoint setting to call envconsul and the execScript. Based on the source code this doesn't look currently possible. Before I start implementing this I'm wondering:

• Does this seem logical?
• Is there another setting I'm missing to achieve this goal?

My alternative thought is to alter the bash template to check if envconsul is available and consul is active, which seems fugly to me.

Thanks,

Mike

[muuki88]

First Thoughts

I think I don't quite understand what you are trying accomplish. Looking at your pull request you, I see:

dockerEntrypoint := Seq("bin/%s" format executableScriptName.value)

and from there on you use the dockerEntrypoint instead of the executableScriptName. I agree this is more flexible, but I'm not sure if this is needed. What an effect has a relocation of the startscript?

I believe the best way to do this is overriding the entrypoint setting to call envconsul and the execScript

If you want to change the entrypoint at runtime you can call docker with

docker run $IMAGE /opt/docker/your-awesome-app/bin/other-entrypoint
# or
docker run --entrypoint=/opt/docker/your-awesome-app/bin/other-entrypoint $IMAGE

I'm not sure about the difference :/

• Custom Docker Entrypoint
• Docker CLI

Second Thoughts

Do you want to create to startscripts?

bin/executableScriptname
bin/dockerEntrypoint

and dockerEntrypoint calling executableScriptname with envconsul settings-key-prefix executableScriptname?

cc @fiadliel

[mhamrah]

Regarding:

dockerEntrypoint := Seq("bin/%s" format executableScriptName.value)

I agree with your statement. This is only here for backwards compatibility; it was there before. I agree it makes no sense (as I stated in the PR description). What's the point of changing executableScriptName which only changes the enterypoint value, and forces you to the bin/ directory.

• The default entrypoint should be the script as produced and uploaded from sbt-native-packager
• You should override the entrypoint as you wish.

Regarding overriding the entrypoint at runtime:

I don't want to do this; it defeats the purposes of entrypoint. I want to do a docker run just like executing a command, which is what entrypoint provides. You run the container as a script, without any need for command line flags.

This is the goal: docker run the-sbt-packaged-container

[mhamrah]

Your second thoughts are more inline with what I'm thinking. I just pushed a change to #411 with an entrypoint test.

I'd like to be able to set this as my entrypoint:

ENTRYPOINT ["envconsul", "keyprefix", "bin/executableScriptname"]

envconsul is in the PATH of the docker container, and I can still easy pass any command-line arguments to the start script.

[muuki88]

Ah! Now I get it. From my limited docker knowledge, this seems like a valid usage.
We had some requests regarding parameters for your entry script, which can be handled easily with the bashscriptExtraDefines. But here we use the startscript as a parameter.

@fiadliel WDYT?

[fiadliel]

In general, it's strictly more flexible, while still doing the "right thing" for the common case; sounds good to me.