Data

Tools

Indexes

Applications

Experiments

Awesome

An open API service indexing awesome lists of open source software.

https://github.com/cycoresystems/docker-meteor

Dockerfile and script for running Meteor on Docker
https://github.com/cycoresystems/docker-meteor

Last synced: about 1 year ago
JSON representation

Dockerfile and script for running Meteor on Docker

Awesome Lists containing this project

README 

          
## Meteor 1.8+



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](https://github.com/CyCoreSystems/go-meteor) tool.  Binary

releases of this tool are located [here](https://github.com/CyCoreSystems/go-meteor/releases).



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.



## Meteor 1.4+



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.



## Build tag



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).



## Features:



 * 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](https://atmospherejs.com/ongoworks/spiderable);  if there is demand, please create an issue on Github, and I'll see about managing a separate branch for it.



## Versions



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.



## Modes of operation



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.



### Source mode



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.



#### Running without root



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**).



### Pre-bundled mode



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.



## Examples:



### git repo with non-default (master) branch

```sh

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

```



### app source from a local directory on host (/home/user/myapp)

```sh

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

```



### pre-bundled app from a local directory on host (/home/user/myapp)

```sh

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

```



### pre-bundled and compressed app from a local directory on host (/home/user/build.tar.gz)

```sh

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

```



### local app source directory on host (/home/user/myapp) with specific Meteor release (1.4.2.1)

```sh

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

```



### Unit file



There is also a sample systemd [unit file](meteor.myapp@.service) in the Github repository.



### Build with bundled app



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.



```bash

cd $app_source

meteor build --directory /tmp/export-meteor/build

cat >/tmp/export-meteor/Dockerfile <