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:
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).
legacy
branch/tag)APP_DIR
(meteor build --directory); defaults to /home/meteor/www
BUNDLE_FILE
(meteor build);curl
from BUNDLE_URL
(if supplied)CURL_OPTS
if you need to pass additional parametersRELEASE
is specified, but apps run with their own versions)SRC_DIR
(defaults to /home/meteor/src
)REPO
(git clone URL)
DEPLOY_KEY
file for SSH authentication to private repositoriesBRANCH
is not the default master
(can also be a tag name)MONGO_PORT
...)MONGO_URL
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.PORT
); defaults to 3000The 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.