Add dockerfile

[Tathanen]

There's been some interest in adding a dockerfile to the v3 drone wall release, @athieriot I believe you mentioned you'd be interested in taking a stab at it?

[athieriot]

I am looking at it at the moment. I might need some advices on how to use Dominatr though if you have a minute.

tl;dr; In order to use the official Nginx Docker image I need a property file easily accessible to configure Drone Wall without Grunt. Does Dominatr allow Grunt config overriding?

---

Basically, I had like to just bundle the ./build directory using the Nginx Docker image directly. There is really no reason to have Grunt nor Node.js in the final container as the website can be build on the build machine and then it's not used again.

However, we would still need a way to override the few properties (apiroot, token, etc...) via environment variables. Generally I tend to do that by having a property file with place holders in it and replacing the values (in a copy) in a little bash script ran on startup (Much like what grunt:copy is doing but more primitive).

So at the moment, I've got a tiny Angular module holding only the necessary constants but I can't find a way to NOT bundle in in the build.js file.

Is it possible then to override Dominatr config in order to exclude my module from the minified Javascript? (So I have a nice little file to replace environment variables from?)

I hope this make sense and if you have any other ideas I'm all ears :)

Aurélien

[bradrydzewski]

However, we would still need a way to override the few properties (apiroot, token, etc...) via environment variables.

I do not believe the default image need to provide a way to override these variables. It is generally not recommended to compile these variables into the source (like your token). If someone wants to embed the variables inside the compiled javascript they should compile their own version.

I believe the default image should be a quick and easy way to use the wall and if someone wants a more customized build we should provide the instructions to create their own image.

[athieriot]

I knew I wasn't being very clear.

You last sentence is exactly what I intend to do. "Override" was merely a way for me to say "set" or configure or define.

I am not sure to get your first statement though but ultimately, what I have in mind is something like this (Or equivalent):

  docker run -d \
     -p 9000:80 \
     -e API_ROOT=<Drone URL> \
     -e TOKEN=<Drone token> \
     -e THEME=<dark|light> \
     drone-wall

Are we on the same track with that Docker command line?

[bradrydzewski]

@athieriot these variables should be set at runtime when you first visit the wall (from the browser)

The apiroot, token, and theme vars can be changed via the Wall interface at any time. Once set, they'll be stored in localstorage so you don't have to reenter them.

[athieriot]

Ah ! That changes everything.

Sorry I didn't see that before.

[athieriot]

Out of interest, why is the reason your not in favour of the Env variable approach?

[bradrydzewski]

@athieriot remember that if you provide the token it will get embedded directly into the javascript and will be available to anyone that visits the site. @Tathanen I have to admit I'm a bit worried about having this option available since the security implications aren't entirely clear

Out of interest, why is the reason your not in favour of the Env variable approach?

the primary use case for the wall is persistent, large screen installations. I think the installation process should be optimized for the primary use case, which is generally going to be a 1-time setup. Also security implications mentioned above

[athieriot]

That's a very good point. I guess I was having the mindset of a back end application

[bradrydzewski]

I recommend providing a simple, small base image. This will provide a 6mb total download including the parent docker layers:

FROM fnichol/uhttpd
EXPOSE 80
ADD build /www

[athieriot]

God :) At that point you are probably thinking your should have done it yourself.

[Tathanen]

@bradrydzewski re: baking in the token, would some more forceful language in the readme make you more comfortable? I'm happy to crank it up, since you're right, it's not super clear as-is. I would like to still leave the option there for people who might run the wall locally on a machine hooked to a TV and have no external access possibility.

[bradrydzewski]

@Tathanen yep I think some strong language or explanation of the intended us would be great

@athieriot sorry I ended up having a pretty strong opinion on how the Docker image should work and submitted an initial implementation. Hope you don't mind, but open to any suggestions to improve!

docker run -d -p 80:80 drone/drone-wall

[bradrydzewski]

@athieriot I setup the .drone.yml so that the docker image will auto-publish :)

no need for the makefile in this case, since the commands are pretty simple

[athieriot]

There is some test scenario provided if you want aircover on this