Run GlitterGallery in a container

[Alwahsh]

I tried to learn about Docker and managed to run GlitterGallery in a container for development through this docker file.

Instructions:
-install docker.
-cd to GG directory
-run docker build -t glittergallery .
-run docker run -d -v $PWD:/srv -p 3000:3000 glittergallery
-navigate to "localhost:3000" and enjoy :)

To make this run in production, I think we need to setup another container with mysql and connect them. Also we might want to use Passenger.

I just want to make sure that I'm working on the right track for handling #239 .

[Alwahsh]

@sarupbanskota, @EmilyDirsh I hope you can help me with this :)

[rohitpaulk]

It's good to specify a version number, usually the LTS version - which would be 14.04.

[Alwahsh]

Sure. That should definitely done in production :)

[rohitpaulk]

docker build -t container_name .

You're building an image here, not a container. I'd suggest replacing container_name with image_name, or better suited for our case - just glittergallery.

docker run -p 3000:3000 image_name

That's good to run GlitterGallery in a setup where you just want to set it up and forget about it. If you're actively developing, it's better to mount a volume from the docker host into the container - here's how that'd look:

docker run -d -v $PWD:/glittergallery -p 3000:3000 image_name

This way, all changes made to files will reflect in the container. I'm a bit doubtful about how this will work with bundler (if gems are installed in the /glittergallery folder, they'll be overwritter). If that is the case, we'll have to configure bundler to install gems elsewhere.

One more advantage of this is - you'd retain the development database even if you launch a new container.

[Alwahsh]

@rohitpaulk Thank you very much for the detailed feedback :)

I posted this just as a starting point.
docker build -t container_name . was just for explaining what that argument is. When I ran it locally, I named it glittergallery indeed ✋ :) .

That's good to run GlitterGallery in a setup where you just want to set it up and forget about it.

Yeah, or in other words "production" :)
I don't actually develop with using Docker. I just wanted to run it in my environment to get used to it and know what's needed to run it in production and to get some feedback here before making a real production version Dockerfile where I'd set the port to 80 and the ENV to production and everything :).

Thanks again. I really appreciate your feedback

[EmilyDirsh]

Feel free to continue to work on this Ubuntu based image, if that's what you prefer working with. I'd want our promoted "official" image to be Fedora based, given that Glitter Gallery originated with the Fedora design team :)

[Alwahsh]

@EmilyDirsh I'm planning to change it to Fedora :)... Funny thing here is that I was actually downloading Fedora for my own machine during the past few days(internet here is not the fastest 😢 ) I was facing problems on my old system getting the image to run(discovered at the end that I had no space left in my root.) Just today as I removed my old system and switched to Fedora that I got this Ubuntu based image to work :).

[Alwahsh]

@rohitpaulk I've applied the suggestions you made(updated my description as well). I could run the app in development, make modifications and see them directly. I think next step is to run a container with guard running :)

@EmilyDirsh now using Fedora :)

[sarupbanskota]

Do we really need rvm in the container? The only reason I can think of wanting to switch ruby versions within a container I'm going to use for GG development is to check if some bug is introduced in a project because of a change we introduced when we were on a previous version. That's something that'll have to reflect on the Dockerfile anyway.

Am I missing something?

[Alwahsh]

@sarupbanskota yeah I was thinking actually about that but found out that the official available ruby packages is not always the last one. The easiest alternative is RVM. If you think I should use another way to get the latest ruby with specifying the version, please let me know it :).

[EmilyDirsh]

I'm thinking we should have the Dockerfile in a separate repo. That's standard from what I've seen of other docker repos.

[Alwahsh]

@EmilyDirsh well, I was thinking of including that file in the repo here and adding something in the instructions in the Get Involved page to tell contributors they can optionally develop that way since this dockerfile is now for development. For the production one(probably won't be a single file), it might be better to move them into another repo.
I'm not sure though. If this file looks good and you want to host it in another repo, please do :)

[EmilyDirsh]

@Alwahsh that's a good point, but I still think it's best to keep it in it's own repo. If we want to include it in this repo at some point, then we can do that through a submodule. I'll make it a todo for myself to create the repo.

[EmilyDirsh]

Fixes #239