APP_DIR (meteor build --directory); defaults to /var/wwwcurl 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 /src/app)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_URLMONGO_OPLOG_URL. There were too many potention 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 80The Meteor tool (if required) is now 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.
There are three basic modes of operation for this image:
BUNDLE_DIR
If you put your bundled application in the directory pointed to by BUNDLE_DIR (/target, 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).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).APP_DIR
If you put your application source in the directory pointed to by APP_DIR (/var/www, by default), this container will first try to find an existing
bundle. If that fails, it will download the Meteor tool, build your application, bundle it, then execute it. It is usually sufficient to simply
pass the docker run an argument something like -v /srv/myApp:/var/www.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.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 \
-e APP_DIR=/app \
-v /home/user/myapp:/app \
-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:/src/app \
-e MONGO_URL=mongodb://mymongoserver.com:27017/appdb \
-e MONGO_OPLOG_URL=mongodb://mymongoserver.com:27017/local \
-e RELEASE=1.0.5 \
ulexus/meteor
There is also a sample systemd unit file in the Github repository.
Content type
Image
Digest
Size
173.7 MB
Last updated
over 10 years ago
docker pull risul/meteor