I’ve stopped using Meteor in favour of Webpack + React + Apollo, so am no longer actively maintaining meteor-tupperware.
If I were designing a new approach today, I’d use a two Docker image approach. One image to support the production bundle build process, and one image (built with each version) to run the app in production.
1) Build Image: For launching a container to run the meteor build
process, which would spit out the production bundle.
This image would need to download and install the relevant version of Meteor to support the build process (or have the version of Meteor baked into the image, but this would require publishing a new image every time a new version of Meteor comes out). You’d accomplish this by binding the build output directory into the container from the host machine.
It’s important this process happens inside a container so that the native extensions are compiled for the correct platform.
2) Production Runtime Image:
This image should be built by copying the generated bundle (from the build image) into a SUPER lightweight container that only has Node and any other critical dependencies.
I’d recommend this image as the base: https://github.com/mhart/alpine-node
It includes tagged images for Node 0.10 and 4, 6, etc. So it could theoretically support older versions of Meteor. It is also based on Alpine linux, and clocks in under 50mb!
Finally, I’d recommend this process happens on a CI provider like CircleCI or Travis. Both have (somewhat dodgy, but sufficient) Docker support, which means you could run the build container, and create the production image on CI. You could then push the lightweight production image to Docker Hub, Quay, GCR, etc for running on production.
Happy to provide some input, but I definitely won’t be able to maintain something like this given that I’m not longer personally invested in using Meteor.
Best,
Chris