Smashing Docker Container

[terraboops]

There are several Docker containers for Dashing, we should investigate them and take the best bits to make an official Smashing container.

[suhussai]

A simple search on Docker Hub shows several attempts at setting up a Dashing/Smashing Docker Container.

Personally, I really like this one: https://hub.docker.com/r/siweis/dashing/
It's super simple to get up and running which is why I think that if an official Docker container is being created, I think it would be sweet to follow a similar approach.

[terraboops]

@suhussai Yeah, there are lots of good containers for Dashing (not Smashing) that we can evaluate and borrow from. Can you please elaborate on what you like about the approach they use?

Personally, I am not sure that using Alpine is the distro we want to use. However, I haven't really looked into this much.

[suhussai]

What I really like about the one from siweis is that it is really easy to setup and use. You build the container from the parent directory of the smashing project and the dockerfile simply pulls all the files into the container carrying all of the config files such as jobs, dashboards, widgets, etc.

The current leading project https://hub.docker.com/r/frvi/dashing/ uses a different approach and it can be argued that that approach is a bit more flexible in that it allows you to pull in jobs, dashboards and other config files from different places on your computer, rather than just the directory you build the container in. It involves setting up a different volumes on the container to pull in the different config files. It also seems that gems must be passed in as an env variable.

As for the choice to use Alpine, I think it might be to reduce the amount of space the container uses. Right now, the latest alpine is 4.8MB whereas the latest ubuntu is 129MB.

What are some of the things that you'd like to see on the official smashing/dashing docker container? I'd be down to take a stab at writing up a draft for the dockerfile over the weekend.

[terraboops]

Sounds like you've looked into this quite a bit. I will play along and pretend I have no knowledge of this and also pretend to be amazed. Wow! 😉

Anyway, I want the container to be:

• Small - so maybe Alpine is a good fit, or perhaps you just want to build from scratch
• Extensible - it should be easy for people to write their own Dockerfiles that extend off of ours
• Easy to Schedule - Ideally I'd like this container to run in Kubernetes, Mesos or Nomad with no changes
• Self-Contained - The entirety of Smashing should be shipped into the container, to simplify scheduling

Acceptance Criteria:

• Runs on Docker Engine (would be great to test on Windows, Linux and OSX)
• A new project created with smashing new project and configured with a Twitter API key works reliably for 30 minutes

[suhussai]

@tylermauthe here is a first draft of the Dockerfile. I've got it setup on Dockerhub so you can test it out with the Dockerfile there.

https://hub.docker.com/r/suhussai/containerized-smashing/

The instruction to run the container is the following:

# Run container
$ docker run -p 3030:3030 -v=/full/path/to/your/dashboard/:/dashboard suhussai/containerized-smashing

Or if you want to run the default setup for the smashing dashboard, you can just run

$ docker run -p 3030:3030 suhussai/containerized-smashing

It's been minimally tested, but I think the concept is sound so I want to show it here before moving forward with it.

As you can see, its quite simple to get up and running. It combines elements of the previous dockerfiles I mentioned. No need for even a Dockerfile. The command above should pull the container down and using volumes, you can stick your dashboard in which will pull the config/jobs/widgets files and make them available for the container or just use the default setup.

As for the things you mentioned. The way this Dockerfile is setup, its not meant to be used as a base image. It goes all the way in that it sets up your dashboard instead of the just environment for the dashboard. So if extensibility is so super important, this Dockerfile might need to be refactored.

It is self-contained and relatively small. As you can see from the Dockerfile on docker hub, I am using Alpine. I've yet to test with any container orchestration engines.

I'll work on the acceptance criteria after getting some feedback here.

So, what do you think?

[terraboops]

Just gave it a brief look, it's a great start. I haven't tried it out yet, but a couple quick things I noticed: - it's pulling in Dashing, not Smashing - it's using volumes to mount the dashboard code -- I think it might be better to actually ship the code into the container for simplicity

…

On Jan 16, 2017, at 11:27 AM, Syed Umair Hussain ***@***.***> wrote: @tylermauthe here is a first draft of the Dockerfile. I've got it setup on Dockerhub so you can test it out with the Dockerfile there. https://hub.docker.com/r/suhussai/containerized-smashing/ The instruction to run the container is the following: # Run container $ docker run -p 3030:3030 -v=/full/path/to/your/dashboard/:/dashboard suhussai/containerized-smashing Or if you want to run the default setup for the smashing dashboard, you can just run $ docker run -p 3030:3030 suhussai/containerized-smashing It's been minimally tested, but I think the concept is sound so I want to show it here before moving forward with it. As you can see, its quite simple to get up and running. It combines elements of the previous dockerfiles I mentioned. No need for even a Dockerfile. The command above should pull the container down and using volumes, you can stick your dashboard in which will pull the config/jobs/widgets files and make them available for the container or just use the default setup. As for the things you mentioned. The way this Dockerfile is setup, its not meant to be used as a base image. It goes all the way in that it sets up your dashboard instead of the just environment for the dashboard. So if extensibility is so super important, this Dockerfile might need to be refactored. It is self-contained and relatively small. As you can see from the Dockerfile on docker hub, I am using Alpine. I've yet to test with any container orchestration engines. I'll work on the acceptance criteria after getting some feedback here. So, what do you think? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[suhussai]

Thanks for taking a look @tylermauthe!

Ah okay, so I'll replace gem install dashing with gem install smashing. I did see the smashing gem, but I wasn't sure it was the right one.

About your second point, the way I have it designed allows for users to simply run the command I've indicated and get up and running. I think what you are referring to is likely to use the COPY or ADD command in a Dockerfile and copy parts of the build context into the container. To do that, it would involve having users to create a Dockerfile locally and then pulling in my dockerfile as the base image, kind of like https://hub.docker.com/r/siweis/dashing/

This is because the Dockerfile and the build context are difficult to segregate (I haven't found a way to do it.) i.e you can't use a Dockerfile located remotely along with a build context that is local.

So to save users from having to create their own Dockerfile, no matter how minimal, I added the docker volume /dashboard. This way, users can pull a remote Dockerfile (which uses its own build context in the building process) and then, using volumes they can add relevant bits of their own build context when running the container.

Hope that makes sense!

[terraboops]

I think it makes sense, I'll have to find some time to run it and play around with it to see if I like it.

Thanks!

[suhussai]

Cool!

No rush, I just wanted to get a solution out there. I am definitely open to new ideas to ensure that the needs of the project are met.

[terraboops]

#wishyouwerehere

[derro]

We are currently running Dashing on one of our servers and want to move everything to small Docker containers. Therefore I can help to test a Smashing Docker container if needed.

[suhussai]

Hey @derro, it'd be great if you could test the container on your environment!

Here is the container we want to test out https://hub.docker.com/r/suhussai/containerized-smashing/

I've wrote up some instructions on the README there.

You are probably going to want to test your own dashboard configuration so you want to run the following:

docker run -p 3030:3030 -v=/full/path/to/your/dashboard/:/dashboard suhussai/containerized-smashing

Let me know how it goes!

[ghost]

For me this is working quite nice https://hub.docker.com/r/rgcamus/alpine_smashing/

[sjernigan]

Thanks for the reference @blackness90 Working great so far.

[sjernigan]

rgcamus forked worked great..untill it didn't. We're running in kubernetes and use a git-sync sidecar container to copy a repo into the smashing container. However, the rgcamus fork wanted a bunch of individual mounts when git-sync just wanted to export the one. And since the repo is a full smashing project for local development, having it create a new project and link in all the directories didn't make sense. github.com/reverbnation/alpine_smashing just expects one volume with a full project. The container should rarely need to be rebuilt and could probably be replace with a generic ruby alpine with some onbuild commands. YMMV

[terraboops]

That is exactly the reason I want everything required to run your dashboard shipped inside the container. No mounts, no problems. Everything needed to run a dashboard is pretty small. It can be done!

[suhussai]

@sjernigan @tylermauthe This docker hub repo: https://hub.docker.com/r/siweis/dashing/ might be what you guys are looking for. According to the README:

Create a Dockerfile in the root directory of your dashing project containing one simple line:

FROM siweis/dashing
Thats it!

Two ON BUILD hooks will add all your files to the image and execute bundle on your Gemfile.

I've used it before and it's easy to get started. It also doesn't require any mounts, but it does require a simple Dockerfile however.

[sjernigan]

I can definitely see something like that working and understand the justifications in many cases for having a self-contained deployable container. We take this approach for many of our containers that are scaled, need rollback, blah blah blah.
However, and this will probably get me kicked out of DockerCon, it's too much for my dashboard use case. Other than developer adding a widget, there's only a single instance and it isn't mission critical. Let's compare the workflow. I could set some hooks in our container repository to automatically build the container and make it available. That's repeatable and eases developer setup but introduces a delay and needless commits (commit, wait for the automated build cycle, pull the new image, and restart my container). I could build locally for less of a delay but that demands more from each development environment setup, defeating many of the benefits of using universally deployable containers. Contrast that with mounting the repo into a fix container. No extra demands on development environment. For many changes, I simply save the file and refresh the browser. Worse case, I kill the container and it restarts. Works the same in prod using standard sidecar containers. I don't need to roll-back, but could checkout a tag/branch of the repo. More than likely, if there is a problem, I'll just fix it. Look, I know this is paramount to Docker heresy and I'm not leading a movement. But in MY case, I don't see a downside and I'll take development speed over unmotivated adherence to a general approach.
[NB There is a caveat to my current container. I throw away the compiler/libs so if I need a gem with a native extension, I'll have to wait for the automated container rebuild. Ok trade for a 79.5M image.]

[terraboops]

My goal is to make something that is as simple as possible. Other containers exist, please feel free to use them or build your own.

For the officially supported container, I want something that anybody can use in any situation. Simplicity is key.

This is all in an effort to minimize support requests. Typical support requests are issued by people who don't know Ruby or modern operational tooling. Heck they often don't even read the contribution guidelines. I want to have two steps: install Docker and start your container. Slow builds won't generate support requests.

[sjernigan]

Two steps...I think you left out the git checkout but perhaps you want a demo container that can't be altered. So maybe we are saying the same thing cause that what I have (install docker, git checkout, run with volume mount). I thought you were arguing for an additional container build step(s) to get the user's code into the container (without a volume mount).
Thinking about how to minimize support requests is smart. I would alter my container to not remove the libs so bundler can compile any native extensions the user adds.
Anyhow, thanks for your efforts.

[derro]

I tried a lot of dashing docker containers of the posted ones in the comments.
They all work pretty good with new dashboards, but somehow I can't manage to extend the docker containers to use an already existing dashboard (with own widgets, jobs and config files).

Does anyone already tried this and got this working? I also tried to alter the Dockerfile to use the files from an external source but I wasn't able to get this working.
Thanks for any help!

[sjernigan]

Derro,

As you can see by tylermauthe's comments, this is not official....but if you had a smashing project created at ~/smashing, you should be able to run

docker run -d -p 3030:3030 -v ~/smashing:/etc/git_repo/smashing quay.io/reverbnation/alpine-smashing:latest

wait a second for bundler to run and then open a browser to localhost:3030 to see your dashboard.

[ScottBrenner]

Is there an "official" Docker image for Smashing? See a few on Docker Hub, wondering which is "recommended". (sorry for posting in an old issue)

[miketwo]

@ScottBrenner Not sure if there's an official but I've been using visibilityspots/smashing with decent success.

[bodsch]

I build also an (alpine based) container and use them in an extended project for Icinga2.
i include some updates (e.g. jquery, jquerui and font-awesome) into it.
and both works well

[MartynKeigher]

Hey @tylermauthe!

Long time no speak! Hope all has been well since last time we were in touch! :)

Is there, and if so which is, an 'official' docker container for this project ? I'll 2nd @ScottBrenner's question here, and push for a 'recommended' instance!

-Thanks.
://mk

[ScottBrenner]

@MartynKeigher I ended up forking this slightly and creating my own.