Package as Docker image

[pataquets]

I've discovered KeyBox and found it a very great app. Congrats and thanks for it.
I now plan to package it into a Docker image and help create a Docker Hub official image.
The problem is that I'm no Java programmer nor have any experience with Maven.
My goal as of now is to provide an image which:
a) contains a source-built and ready-to-run artifact. I don't want to package any pre-built release, since the whole point of it is to link the Docker image to the latest sources and, optionally, to specific git tags/branches.
b) After having (a), I need another command that just runs the previously built artifact without triggering any further download or build process.
Note tha this should be break, so to happen in two separate steps, to build a downloadable image that will be run afterwards.
My problem now is that, whatever the steps I do, I can build a .war file, but when I try to run the built file, it ends downloading stuff and building again. :(
I tried several combinations, ranging from mvn install/mvn jetty:run to war:war, jetty:deploy-war, jetty:run-war with no luck. I've also browsed the release tarballs, but found no helpful info.
Official Maven docs are not useful to me because of my limited Java/Maven knowledge.

[skavanagh]

mvn package

should just build the war file

mvn package jetty:run

would build the war file and run it with jetty. If you do 'jetty:run' then it downloads the jetty libraries, so that maybe what you are seeing.

[pataquets]

Can't be the Jetty libraries downloaded in advance at build time?

[pataquets]

Also, what are pros/cons of dowloading in advance, apart from startup time and requiring connectivity? Any recommendation or good practice on that?

[skavanagh]

It's only going to download jetty if you use the plugin. There isn't many options for the jetty plugin, but you could maybe try

mvn package jetty:effective-web-xml

to do the build, then do

mvn jetty:run

and that should keep the download/build separate from running the server.

[pataquets]

It works! Thanks.
I think we're nearing it. Left:

• Delete SSL cert/key present inherited from the base image, if any.
• Generate an autosigned SSL cert/key at container creation time
• Customize KeyBoxConfig.properties to get values from environment vars, if possible (help requested). Env vars are the container bootstrap configuration common practice.

Meanwhile, feel free to create an account and organization at Docker Hub to host the built images. Create a new 'Automated build' and link it to your Github repo. Add 'pataquets' to the organization existing 'owner' group.

[pataquets]

No standard /etc/ssl private key/cert found. Learnt about keystores. Found keystore files:

• src/test/resources/keystore
• target/test-classes/keystore

IMO, no built-in cert/key should be provided, except if warned on docs/install as it's done now.
Also found that you can pass keystore file and pass as options and this would be enough. Rolling your own cert/key would be involved, anyways. Just want to make sure no false sense of security is given.
Will submit an initial Dockerfile version soon without any further cert/key management.

[pataquets]

Submitted PR #91

[francislavoie]

Two years later, the Dockerfile is in the wrong branch after the PR was merged. Any chance this will get fixed @skavanagh ?

[skavanagh]

uhh.. no it wasn't. It was merged to master and removed here ef069c8

Probably b/c the docker file doesn't have the DB on a volume outside the container, like how these projects have.

https://github.com/schmas/docker-keybox
https://github.com/garywiz/docker-keybox

[kevindice]

A container should only have 1 process in it. While that Dockerfile may feel "batteries not included", there's value in the single responsibility principle. Perhaps someone wants to use a non-containerized DB? If the KeyBox container's DB connection config is derived from environment variables, then you get this flexibility.

If the Dockerfile were brought back, an accompanying docker-compose file could help demonstrate what a full setup with a KeyBox container and DB container would look like.

[PackElend]

is https://github.com/e-COSI/docker-bastillion related to this discussion?

[lucapalano]

@PackElend Yes.
That's not an "official docker image" but may be useful also for #314 .

[modem7]

Any updates on this one from an official point of view?

[pataquets]

No longer using KeyBox, but found this open issue while doing some issue cleanup.
Reading through comments, a bit of summary and opinion:

• Looks like there is still interest in an official image, or at least a canonical Dockerfile (Is thare an official docker image for this project? #314). 3rd parties are not as auditable and, by the very nature of this software, this it's a big concern, IMO.
• Also, images mentioned by @skavanagh above look like quite outdated (by just looking to last commit date).
• The Dockerfile was removed on ef069c8, only because no having volumes, which does not affect usage (volumes can always be declared at container launch time). Declaring volumes might even be counterproductive if you don't want to use them, since they can't be "undeclared"

I don't know if the deleted Dockerfile would still work, but it would be useful if there are enough Docker users interested in keeping it up-to-date, as it would also serve as sort of canonical build docs.
Notice that no image needs to be published, as it can be built on demand from the git repo with this one-liner:

docker build -t keybox https://github.com/bastillion-io/Bastillion

I think this approach would be a good compromise for most users. WDYT?
Just my 2c.

[mietzen]

No longer using KeyBox, but found this open issue while doing some issue cleanup. Reading through comments, a bit of summary and opinion:

• Looks like there is still interest in an official image, or at least a canonical Dockerfile (Is thare an official docker image for this project? #314). 3rd parties are not as auditable and, by the very nature of this software, this it's a big concern, IMO.
• Also, images mentioned by @skavanagh above look like quite outdated (by just looking to last commit date).
• The Dockerfile was removed on ef069c8, only because no having volumes, which does not affect usage (volumes can always be declared at container launch time). Declaring volumes might even be counterproductive if you don't want to use them, since they can't be "undeclared"

I don't know if the deleted Dockerfile would still work, but it would be useful if there are enough Docker users interested in keeping it up-to-date, as it would also serve as sort of canonical build docs. Notice that no image needs to be published, as it can be built on demand from the git repo with this one-liner:

docker build -t keybox https://github.com/bastillion-io/Bastillion

I think this approach would be a good compromise for most users. WDYT? Just my 2c.

I didn't new that there was a Docker file so I forked the above mentioned e-COSI Image and I'm now keeping it up-to-date.
I hope this doesn't count as advertisement, I mostly maintain it for myself, but if someone else wants to use it... feel free.
https://github.com/mietzen/docker-bastillion
https://hub.docker.com/r/mietzen/bastillion