CyCoreSystems/docker-meteor: Dockerfile and script for running Meteor on Docker · GitHub

We are working on a more modern system for this package which will integrate the benefits of the multi-stage builder. In the mean time, however, I invite you to take a look at our new Dockerfile generator.

We have developed a multi-stage Dockerfile which provides:

• much faster container startup
• more reliable builds
• better CI/CD compatibility
• better version support of Node

To generate a multi-stage Dockerfile for your Meteor app, you can use the meteor-dockerfilegen tool. Binary releases of this tool are located here.

This tool reads your Meteor application and builds the Dockerfile with appropriate versions of Node and Meteor, as specified by your Meteor application's metadata.

The latest Docker tag and the master git branch are for Meteor 1.4+. For prior versions of Meteor, please use the legacy tag and branch.

In order to keep the size of the image down, the current tag does not include build-essential tools. If you are using modules which do not supply binary versions for your platform, please use the build tag, which does include build-essential.

NOTE build-essential is necessary if you use the bcrypt module, which is used by the accounts-password package, so if you are using password-based logins on your site, you must use the :build Docker tag (build git branch).

• Meteor 1.4+ package/bundle support (for previous Meteor versions, use the legacy branch/tag)
• Bundle-based execution
  • directory referenced as APP_DIR (meteor build --directory); defaults to /home/meteor/www
  • compressed directory referenced as BUNDLE_FILE (meteor build);
  • downloaded with curl from BUNDLE_URL (if supplied)
  • set CURL_OPTS if you need to pass additional parameters
• Source-based build/execution
  • Downloads latest Meteor tool at runtime (always the latest tool version unless a RELEASE is specified, but apps run with their own versions)
  • Supply source at SRC_DIR (defaults to /home/meteor/src)
  • Supply source from REPO (git clone URL)
    • Optionally specify a DEPLOY_KEY file for SSH authentication to private repositories
    • Optionally specify a BRANCH is not the default master (can also be a tag name)
• References your external MongoDB database
  • Uses Docker links (i.e. MONGO_PORT...)
  • Explicit Mongo URLs by at MONGO_URL
  • NOTE: This does NOT set MONGO_OPLOG_URL. There were too many potential complications. As a result, unless you explicitly set MONGO_OPLOG_URL, Meteor will fall back to a polling-based approach to database synchronization. Note that oplog tailing requires a working replica set on your MongoDB server as well as access to the local database.
• Optionally specify the port on which the web server should run (PORT); defaults to 3000
• Non-root location of Meteor tree; the script will search for the first .meteor directory
• NOTE: PhantomJS is no longer pre-installed. This package was swelling the size of the image by 50%, and it is not maintainable with the standard Docker Node images. Instead, please use one of the docker-friendly (read port-based) spiderable packages on Meteor, such as ongoworks:spiderable; if there is demand, please create an issue on Github, and I'll see about managing a separate branch for it.

The Meteor tool (if required; see Modes of Operation below) is downloaded at runtime, so it is no longer packaged and the version of this docker image does not matter for the version of meteor.

You can specify which version of Meteor you want to be installed by setting the RELEASE as required. However, this release of ulexus/meteor does require a minimum version of 1.4 for your Meteor application.

There are two basic modes of operation for this image: source and pre-bundled. The source method allows the greatest flexibility, since it builds and bundles Meteor on the deployment system inside the same container. However, it also takes much longer and requires a much larger disk footprint.

To utilize source mode, define one of SRC_DIR or REPO:

• SRC_DIR If you put your application source in the directory pointed to by SRC_DIR (/home/meteor/src, by default), this container will download the Meteor tool, build your application, bundle it, then execute it. It is usually sufficient to simply pass docker run an argument like -v /srv/myApp:/src/app.

• REPO If you populate the REPO environment variable, it is presumed that this is where your application source resides. This container will git pull your REPO, change to master or the supplied BRANCH (which can also be a tag). The source tree will be placed in APP_DIR, and the script will pick up processing APP_DIR (above) from there.

When the container is run, the appropriate version of the Meteor tool will be downloaded and installed, your application will be built/bundled, and then it will be run. This process can take several minutes to complete.

As of Meteor 1.4.2, running Meteor as root has been strongly dissuaded. As a result, we now drop root privileges after starting the container. This means that if you are bind-mounting your source or bundle directories, the files must be readable and writable by the container's unprivileged user (UID 1000).

To utilize the pre-bundled mode, DO NOT define SRC_DIR or REPO. Instead define one of APP_DIR or BUNDLE_DIR:

• APP_DIR If you put your bundled application in the directory pointed to by APP_DIR (/home/meteor/www, by default), this container will attempt to find a Meteor bundle in this directory and then start Node to run that bundle. The Meteor tool will not be installed (as a bundled Meteor app needs only Node). The default APP_DIR is /home/meteor/www, so you may attach that as a volume, for greatest simplicity. Something like: -v /srv/myApp:/home/meteor/www.
• BUNDLE_FILE If you put your compressed (*.tar.gz) application in the directory pointed to by BUNDLE_FILE, this container will attempt to find a compressed Meteor bundle in this directory, decompress the file, and then start Node to run that bundle. The Meteor tool will not be installed (as a bundled Meteor app needs only Node). You may attach that as a volume, for greatest simplicity. Something like: -e BUNDLE_FILE='home/meteor/build.tar.gz -v /srv/build.tar.gz:/home/meteor/build.tar.gz.
• BUNDLE_URL If you populate BUNDLE_URL, the container expects to find a bundled tarball, as generated by meteor build ./ at this URL. The tarball is downloaded (with curl... so you may set CURL_OPTS as required) and extracted to the bundle directory, and the process continues from BUNDLE_DIR (above).

When the container is run, the Meteor tool will NOT be downloaded. Instead, npm install will be run to resolve any dependencies for the server, and your application will be run directly with NodeJS.

docker run --rm \
  -e ROOT_URL=http://testsite.com \
  -e REPO=https://github.com/yourName/testsite \
  -e BRANCH=testing \
  -e MONGO_URL=mongodb://mymongoserver.com:27017/mydatabase \
  -e MONGO_OPLOG_URL=mongodb://mymongoserver.com:27017/local \
  ulexus/meteor

docker run --rm \
  -e ROOT_URL=http://testsite.com \
  -v /home/user/myapp:/home/meteor/src \
  -e MONGO_URL=mongodb://mymongoserver.com:27017/appdb \
  -e MONGO_OPLOG_URL=mongodb://mymongoserver.com:27017/local \
  ulexus/meteor

docker run --rm \
  -e ROOT_URL=http://testsite.com \
  -v /home/user/myapp:/home/meteor/www \
  -e MONGO_URL=mongodb://mymongoserver.com:27017/appdb \
  -e MONGO_OPLOG_URL=mongodb://mymongoserver.com:27017/local \
  ulexus/meteor

docker run --rm \
  -e ROOT_URL=http://testsite.com \
  -e BUNDLE_FILE=/home/meteor/build.tar.gz \
  -v /home/user/build.tar.gz:/home/meteor/build.tar.gz \
  -e MONGO_URL=mongodb://mymongoserver.com:27017/appdb \
  -e MONGO_OPLOG_URL=mongodb://mymongoserver.com:27017/local \
  ulexus/meteor

docker run --rm \
  -e ROOT_URL=http://testsite.com \
  -v /home/user/myapp:/home/meteor/src \
  -e MONGO_URL=mongodb://mymongoserver.com:27017/appdb \
  -e MONGO_OPLOG_URL=mongodb://mymongoserver.com:27017/local \
  -e RELEASE=1.4.2.1 \
  ulexus/meteor

There is also a sample systemd unit file in the Github repository.

Pre-bundling your Meteor application will make it start much faster and will allow the container to maintain a smaller storage footprint. However, it does require that you build for the same architecture on which you will be deploying.

cd $app_source
meteor build --directory /tmp/export-meteor/build
cat >/tmp/export-meteor/Dockerfile <<ENDHERE
FROM ulexus/meteor
COPY build /home/meteor/www
RUN chown -R meteor:meteor /home/meteor/
ENDHERE
cd /tmp/export-meteor
docker build -t myapp .
docker push myapp

There is a complete example with build script of building and running a versioned container in kubernetes in the examples directory.