I’ve created a new Docker base image for use by Meteor apps:
This image both caches Meteor and also produces a final image that’s minimal in size, running on Node Alpine, thanks to a multistage Dockerfile. You might want to use this base because:
You can build/bundle your Meteor app as part of building your Docker image, rather than outside of Docker before the Docker build. This means the machine doing the building need not have Node or Meteor installed, which is important for continuous integration setups; and ensures repeatable builds, since the build environment is isolated and controlled.
Using a multistage
Dockerfile on your app’s side means that you can publish a much smaller final Docker image that doesn’t have Meteor included, and you can also use an Alpine Linux base which is good for passing security scans (as it presents much less surface area in which scanners might find vulnerabilities).
Why this image, instead of some others? There are several great Meteor Docker images out there. I built this one because none of the existing open source ones met my needs:
jshimko/meteor-launchpad is great, but it’s based on
debian:jessie, which fails the security scan my company runs on all of our Docker images. Debian is also larger than Alpine. This project also always downloads and installs Meteor on every production build, rather than caching it as this base image does.
meteor/galaxy-images and Treecom/meteor-alpine both require building the Meteor app in the host machine, before copying the built app into the Docker container. We wanted to avoid needing Node and Meteor installed on our CI servers, and we want the predictability of building within the Docker environment.
Other projects I looked at generally had one or more of the disadvantages cited above. Multistage Docker builds have only been possible since Docker 17.05, which came out in May 2017, and most projects on the Web were designed before then and therefore don’t take advantage of the possibilities offered by a multistage architecture.
Please let me know what you think, feedback and pull requests welcome!
How to integrate with meteor-up
This takes a different approach than meteor-up. That project builds your Meteor app outside of a Docker environment and then copies it in: https://github.com/zodern/meteor-up/blob/3c7120a75c12ea12fdd5688e33574c12e158fd07/src/plugins/meteor/assets/prepare-bundle.sh#L42. Therefore you need to have Node, Meteor and so on installed wherever you’re building. This image does everything within Docker, so that the only thing you need to have installed in your building environment is Docker itself. See https://github.com/disney/meteor-base/tree/master/example and its
Congratulations, and thanks for doing this!
Does this image support running Meteor locally in dev mode (
meteor run with its file watching etc)? If not, could you share some pointers on how I could extend the image to achieve that?
This is meant to be used as a base, with your own image looking something like this: https://github.com/disney/meteor-base/blob/master/example/Dockerfile. That’s basically set up to do a production build, and copies your app into the container. You could instead mount your app’s folder as a volume and just run
meteor run (untested):
# The tag here should match the Meteor version of your app, per .meteor/release
# Assumes you’re mounting a volume of your app folder into /opt/src
ENTRYPOINT ["meteor", "run"]
Again I haven’t tested this, so please let us know what ends up working for you.
Thanks @GeoffreyBooth, I’ll give that a shot
First, thanks @GeoffreyBooth !
I found out about meteor-base on this meteor-now issue regarding build image size: https://github.com/jkrup/meteor-now/issues/116
Now, please forgive my ignorance, but I know nothing about how docker works. I see that meteor-now has an option to supply a
--docker-image flag. Do you know if it would be possible to use meteor-base for a multistage image build, and then pass that into meteor-now?
I’m not familiar with
meteor-now, but from looking at their code, they expect the
--docker-image parameter to be a base like
node, which then gets followed by Docker instructions that conflict with
meteor-base. The instructions include lines that start with
apt-get, which require a Debian environment such as Ubuntu, not the Alpine environment of my image (which uses
apk instead of
apt-get to install dependencies).
meteor-now also builds the Meteor app outside of the image and copies it in, like two of the other images I cited above. I think it’s better to build the app inside of the Docker environment, so that the build process happens in a controlled environment and runs identically on both developers’ machines and CI servers.
I have reduced my file size by 350MB using your approach, so that’s great, but after deploying to Zeit, the log in and sign up features throw a 502 error, which cannot be reproduced locally making it difficult to debug. Also, the log in and sign up features work using
meteor-now and cloud v1, but the transition to cloud v2 is urgent given cloud v1 is no longer aligned with the future vision of Zeit leadership.
I’m discussing with the Zeit support team here: https://spectrum.chat/thread/1aa23b5e-4307-4c1c-a97e-a8ec44e13301
Any chance you can lend your expert opinion to resolve the issue?
You cannot reproduce it locally even when running in Docker, e.g. using the example Dockerfile from that repo? The whole thing about Docker is that it’s an isolated environment, so within Docker it should run the same on both your machine and Zeit’s.
The only thought I have is to look into any native extensions you might be using, like
bcrypt. Perhaps they’re not building correctly in the Alpine environment, or the NPM module only includes a prebuilt binary that doesn’t run in Alpine.
Hi @GeoffreyBooth Yes. It was bcrypt. Adapting the Dockerfile from the example as shown below is working thus far:
RUN apk add --no-cache make g++ python
RUN rm -rf node_modules && npm install --build-from-source
RUN npm install bcrypt --build-from-source
RUN apk del make g++ python
RUN ls -l
I also need to take a closer look at your build-meteor-npm-dependencies.sh file. Promises to be good reading next Sunday afternoon while watching golf
Thanks for posting these examples. They’ve been a big help.
Just saw this recent post on Docker images. I am shopping around for a new image to host our application since
Hopefully this is where we should be looking !
I just wanted to share my solution with a multi stage build too.
(don’t forget to run
docker rmi $(docker images -q --filter "dangling=true") to free some space if needed)
Here is the docker image I use https://github.com/chneau/docker-meteor/tree/alpine
And here is a Dockerimage I use on my pipelines, I basically just copy past this file on all my meteor projects and it just works:
Basically the first image is a alpine glibc with Meteor working (should be at latest version).
The second file is a multi stage that will build your final image in 3 steps:
- [image alpine with Meteor] Copy your project, install npm modules and meteor packages, create bundle.
- [image alpine with python make g++ nodejs] Copy bundle, install npm packages
- [image alpine with nodejs] Copy bundle.
For a “medium” project, (with around 30 different pages), it takes around 5 min to build.
If you have any advice or tips, I’m here to listen
The only thing I know is that I could save 15 sec if the second image was already containing python make g++.