Configure docker container(s) for envoy - Githubissues

lambdabaa / envoy

Envoy is a multiplayer trading card game built with meteor.

1 stars 0 forks source link

Configure docker container(s) for envoy #28

Open lightsofapollo opened 10 years ago

lightsofapollo commented 10 years ago

From the README:

To run envoy locally, you must first globally install:

firefox
java
meteor
mongodb
xvfb

I would consider using docker to package your dependencies (either as one bigass container or multiple?) then using volume mounts to run stuff... its a lot lighter weight then vagrant and is much faster. I wrote a blog post about this http://lightsofapollo.github.io/2014/01/31/docker-volumes/

Sadly there are not too many options to deploy the docker containers outright (but the process is very similar to what heroku does to generate their LXC containers)

lambdabaa commented 10 years ago

I didn't know you had a blog!

lambdabaa commented 10 years ago

:tada:

lambdabaa commented 10 years ago

Just went through https://www.docker.io/learn_more/ ... it looks really cool! I want to try.

lambdabaa commented 10 years ago

Just to add a bit more detail here since the configuration ended up non-trivial, we have the following needs...

Development and Testing

Run the meteor app that lives in app/ (possible we don't need the full meteor tool and we can get away with doing https://github.com/oortcloud/heroku-buildpack-meteorite/blob/master/bin/release#L9)
Load fixtures into the live app with mongoimport
- Does the mongodb that ships with meteor include the command line tools?
Lint the codebase
- The "development container" needs access to the full tree
Instrument client-side javascript and run meteor with instrumented code
Run and talk to express/istanbul-middleware server for code coverage
Run firefox in xvfb
Run selenium server through java

Production

Run the meteor app that lives in app/ (possible we don't need the full meteor tool and we can get away with doing https://github.com/oortcloud/heroku-buildpack-meteorite/blob/master/bin/release#L9)

lambdabaa commented 10 years ago

It seems like the best thing might be to have separate development and production images. Perhaps the development one could even use the production one as the "base image".

lambdabaa commented 10 years ago

So I was planning on creating the following containers:

1. Meteor                              // Host meteor server for dev, test, prod
2. MongoDB                             // Host mongodb server for dev, test
3. Source tree, firefox, xvfb, java    // Dev, test environments

But I am running into some difficulty having containers talk to each other...

lightsofapollo commented 10 years ago

@gaye -link does this but its far from perfect or automatic