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!
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
FROM geoffreybooth/meteor-base:1.7.0.3
# Assumes you’re mounting a volume of your app folder into /opt/src
WORKDIR /opt/src
ENTRYPOINT ["meteor", "run"]
Again I haven’t tested this, so please let us know what ends up working for you.
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.
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:
WORKDIR /app/programs/server
RUN apk add --no-cache make g++ python
RUN rm -rf node_modules && npm install --build-from-source
WORKDIR ./npm
RUN npm install bcrypt --build-from-source
WORKDIR ../../..
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.
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)
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++.
