I think having two different images for development and production is absolutely the way to go. But having identical environments is key for Docker Images, so I'd propose to build up a graph like this:
- - > alpine-meteor-development (installs meteor with curl, "devbuild" way, starts with meteor + args + env)
- - > alpine-meteor-production (like @chriswessels explained)
The way @martinezko solved the "production-runtime" problem is really cool I think but it depends on a direct version of node where as every meteor version could possibly demand for another version.
I tried to pull out all of the scripts and simplify it for my needs + having the possibility to specify the node & npm version during build time (not pushed to docker, just a poc): https://github.com/pozylon/meteor-docker-runtime/blob/master/Dockerfile
As you can see node and npm version is specified as ENV. I think that we'll propably need some kind of very small CLI which actually allows for generating the production Dockerfile and the bundle for simplicity:
fireball init --server=https://asdfasdf:443
1. Initializes a .deploy folder if it does not exist.
2. Takes all the arguments passed and pass it to meteor build, if --architecture is not provided, add it. build it into ./.deploy/*.tar.gz
3. Runs meteor npm --version & meteor node --version inside the meteor app's folder to find out how exactly we have to build the underlying node environment.
4. Add a new Dockerfile to .deploy, looking something like, or just update the ENV's to match the current versions:
fireball build [--repository]
1. docker build inside .deploy tagging with package.json information: [repository]/MAINTAINER-APP_NAME:APP_VERSION
With the work that abernix started with his v2 image, we could even go further and offload testing/building into a DIND/docker.socket link environment, spinning up a container which actually builds the bundle ^^ What do you guys think?