disney / meteor-base Goto Github PK

How would you reference an external settings.json file in docker-compose.yml?

Hey guys, thanks for the great work.

Everything works nicely when using default.dockerfile. However, I need native bcrypt installed as it prompts about bcrypt js implementation in use that is 3x slower. So I copied app-with-native-dependencies.dockerfile and now getting this:

#17 8.856 > node-pre-gyp install --fallback-to-build
#17 8.856 
#17 8.861 sh: node-pre-gyp: not found
#17 8.865 npm ERR! code ELIFECYCLE
#17 8.865 npm ERR! syscall spawn
#17 8.865 npm ERR! file sh
#17 8.865 npm ERR! errno ENOENT
#17 8.868 npm ERR! [email protected] install: `node-pre-gyp install --fallback-to-build`
#17 8.868 npm ERR! spawn ENOENT
#17 8.868 npm ERR! 
#17 8.868 npm ERR! Failed at the [email protected] install script.
#17 8.869 npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

Any help would be appreciated.

Running macOS 11.2
Docker desktop 3.5.1 (3.5.1.7)

Hey,

Thank you very much for this docker image, this is very useful and made my life much simpler! 👍
Just one detail, following your update to 1.10.2 today, you did not create the image on docker hub, I get:

ERROR: Service 'app' failed to build: manifest for geoffreybooth/meteor-base:1.10.2 not found: manifest unknown: manifest unknown

On both an m1 MacBook pro with Docker Engine 20.10.12, and CircleCI with remote docker 20.10.11, the meteor application bundle step runs indefinitely without terminating. Here is the output from the run on CircleCI with the job time limit increased to 1 hour.

Remote docker engine config:

Allocating a remote Docker Engine
Requesting version: 20.10.11

Assigned Docker Engine request id: 170788321
  provisioning: ..........
Remote Docker engine created. Using VM 'default-02187608-8fd8-49bb-a8ad-57293ead20f8'
Using volume: 5181069
Created container accessible with:
  DOCKER_CERT_PATH=/tmp/docker-certs2196902227
  DOCKER_HOST=tcp://104.196.215.227:2376
  DOCKER_MACHINE_NAME=170788321
  DOCKER_TLS_VERIFY=1
  NO_PROXY=127.0.0.1,localhost,circleci-internal-outer-build-agent,104.196.215.227:2376

Server Engine Details:
  Version:          20.10.11
  API version:      1.41 (minimum version 1.12)
  Go version:       go1.16.9
  Git commit:       847da18
  Built:            2021-11-18T00:35:15.000000000+00:00
  OS/Arch:          linux/amd64
  Experimental:     false

Build output in CircleCI

Sending build context to Docker daemon  84.63MB
Step 1/20 : FROM ***********************/meteor-base:2.5.6
 ---> 28c5689c3549
Step 2/20 : COPY ./package*.json $APP_SOURCE_FOLDER/
 ---> Using cache
 ---> 684f619df327
Step 3/20 : RUN bash $SCRIPTS_FOLDER/build-app-npm-dependencies.sh
 ---> Using cache
 ---> a6229caf7f58
Step 4/20 : COPY . $APP_SOURCE_FOLDER/
 ---> fc2d7aa90d37
Step 5/20 : RUN bash $SCRIPTS_FOLDER/build-meteor-bundle.sh
 ---> Running in 3001cce38711

[-] Building Meteor application bundle...

    This container can use 7454M memory in total.
    If it aborts with an out-of-memory (OOM) or ‘non-zero exit code 137’ error message,
    please increase the container’s available memory.

    See https://github.com/meteor/meteor/issues/9568 for details.


Even with METEOR_ALLOW_SUPERUSER or --allow-superuser, permissions in your app
directory will be incorrect if you ever attempt to perform any Meteor tasks as
a normal user. If you need to fix your permissions, run the following command
from the root of your project:

  sudo chown -Rh <username> .meteor/local

Browserslist: caniuse-lite is outdated. Please run:
npx browserslist@la**** --update-db

Why you should do it regularly:
https://github.com/browserslist/browserslist#browsers-data-updating


Too long with no output (exceeded 1h0m0s): context deadline exceeded

HI thanks heaps for this image.

What should params/Dockerfile look like if I am just running this in my Meteor project folder and the Dockerfile, docker-compose.yml files are directly in the that folder?

BTW. I am on Meteor 2.3.5.. but was getting a not found so tried using 2.3.4 image below

Here are the files

Dockerfile:

FROM geoffreybooth/meteor-base:2.3.4

# Copy app package.json and package-lock.json into container
#COPY ./package*.json $APP_SOURCE_FOLDER/

RUN bash $SCRIPTS_FOLDER/build-app-npm-dependencies.sh

# Copy app source into container
COPY ./ $APP_SOURCE_FOLDER/

RUN bash $SCRIPTS_FOLDER/build-meteor-bundle.sh


# Use the specific version of Node expected by your Meteor release, per https://docs.meteor.com/changelog.html; this is expected for Meteor 2.3.5
FROM node:14.17.5-alpine

ENV APP_BUNDLE_FOLDER ./
ENV SCRIPTS_FOLDER ./

# Install OS build dependencies, which stay with this intermediate image but don’t become part of the final published image
RUN apk --no-cache add \
	bash \
	g++ \
	make \
	python

# Copy in entrypoint
COPY --from=0 $SCRIPTS_FOLDER $SCRIPTS_FOLDER/

# Copy in app bundle
COPY --from=0 $APP_BUNDLE_FOLDER/bundle $APP_BUNDLE_FOLDER/bundle/

RUN bash $SCRIPTS_FOLDER/build-meteor-npm-dependencies.sh --build-from-source


# Start another Docker stage, so that the final image doesn’t contain the layer with the build dependencies
# See previous FROM line; this must match
FROM node:14.17.5-alpine

ENV APP_BUNDLE_FOLDER ./
ENV SCRIPTS_FOLDER ./

# Install OS runtime dependencies
RUN apk --no-cache add \
	bash \
	ca-certificates

# Copy in entrypoint with the built and installed dependencies from the previous image
COPY --from=1 $SCRIPTS_FOLDER $SCRIPTS_FOLDER/

# Copy in app bundle with the built and installed dependencies from the previous image
COPY --from=1 $APP_BUNDLE_FOLDER/bundle $APP_BUNDLE_FOLDER/bundle/

# Start app
ENTRYPOINT ["/docker/entrypoint.sh"]

CMD ["node", "main.js"]

Docker -compose.yml:

version: '3'

services:
  app:
    build:
      context: .
      dockerfile: Dockerfile
    ports:
      - '80:3000'
    depends_on:
      - mongo
    environment:
      ROOT_URL: http://localhost
      MONGO_URL: mongodb://mongo:27017/meteor
      PORT: 3000

  mongo:
    image: mongo:latest
    command:
      - --storageEngine=wiredTiger
    volumes:
      - data:/data/db

volumes:
  data:

First of all thx for this great Meteor image ... but when using "start": "meteor run --settings ./settings.json" app unable to connect to mongodb ? and work fine without run settings...

I've looked through the build steps and noticed that the script for installing the npm packages will always install all the packages. Since you are very cautious about the size of your image - as am I - I wonder why you use npm install instead of npm install --production, which would leave out all the dev-dependencies, defined in the packages.json file.

See: https://github.com/disney/meteor-base/blob/master/src/docker/build-app-npm-dependencies.sh

An idea by me would be to add a variable which could be passed to the script to add this parameter to the call.

EDIT: I just read that it's enough to set the environment variable NODE_ENV to production (https://docs.npmjs.com/cli-commands/install.html). Would be nice if you could add this hint in the sample file.

I tried in your example, but get this

Even with METEOR_ALLOW_SUPERUSER or --allow-superuser, permissions in your app
directory will be incorrect if you ever attempt to perform any Meteor tasks as
a normal user. If you need to fix your permissions, run the following command
from the root of your project:

  sudo chown -Rh <username> .meteor/local

Please help me

Hi guys,

I've been using this project for version 2.2 of Meteor for some time now without hiccups.

I'm now attempting to update the version to 2.5 and the following step fails during Docker build:

RUN bash $SCRIPTS_FOLDER/build-meteor-npm-dependencies.sh --build-from-source

I'm using example/app-with-native-dependencies.dockerfile with very minor modifications (Just some extra startup scripts etc.)

The only clear difference I could see between the previous template file, and the new 2.5 one, are the base and node images being used.

The feedback loop for trying to figure out exactly what is going wrong is very long since this step happens at the 15 minute mark, I'm also unable to run the build locally due to resource issues so all debugging happens in a CI pipeline 😭

I just wanted to see if anyone else has hit, and hopefully solved, this before I start diving into the rabbit hole.

Thanks!

Can you publish a Meteor 1.9 image please?

https://forums.meteor.com/t/meteor-1-9-is-out/51358

Where should I define the version to build for my app when i run docker-compose up?

My app in running [email protected]

Hello,

Is there any way to install sharp properly.

Please see below the error message.

> [email protected] install /opt/bundle/bundle/programs/server/npm/node_modules/sharp
> (node install/libvips && node install/dll-copy && prebuild-install) || (node install/can-compile && node-gyp rebuild && node install/dll-copy)

sharp: Installation error: 'linux-x64' binaries cannot be used on the 'linuxmusl-x64' platform. Please remove the 'node_modules/sharp' directory and run 'npm install' on the 'linuxmusl-x64' platform.
sharp: Please see https://sharp.pixelplumbing.com/install for required dependencies
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! [email protected] install: `(node install/libvips && node install/dll-copy && prebuild-install) || (node install/can-compile && node-gyp rebuild && node install/dll-copy)`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the [email protected] install script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

Thank you!

Application silently crashes when Accounts#createUser is called.

I've cloned the latest version of your repo, added accounts-password Meteor package and bcrypt npm package, called Accounts.createUser server-side and expected it to work. Application crashed with no errors and traces in the logs.

I've forked to repo to reproduce this bug. See README and last commit. Keep in mind that port 9229 is exposed and --inspect Node.js option is passed to be able to use chrome://inspect tool.

Hi @GeoffreyBooth, me again.

I'm trying to deploy an app using Heroku's build manifest file system (which relies on a heroku.yml file). During the Docker build process, the build is failing on this step:

remote: /docker/build-meteor-bundle.sh: line 11:     8 Killed                  meteor build --directory $APP_BUNDLE_FOLDER --server-only
remote: The command '/bin/sh -c bash $SCRIPTS_FOLDER/build-meteor-bundle.sh' returned a non-zero code: 137

Could this be an OOM error? If so, any advice on what I can do to get the memory size to behave with Heroku?

Hi,

First of all thank you very much for publishing this repo, it is very appreciated!
Now to the issue:
Certain node modules like Sharp won't currently work if you have them in your meteor project.
That's because the base image uses ubuntu as base, and that's where the Sharp dependency gets built with npm install, while the final images use node-alpine to run. Sharp will complain about it because of the difference between the build libraries and the runtime ones.
It is easy to deal with it by using a non-alpine image of node, but I guess it would be better to fix it differently or at least document it somewhere.
Cheers!

Thanks for providing this! It was the first script for me that worked out-of-the-box for creating containerized meteor applications.

For my current project I have an Meteor application that I build with the '--settings' flag. Is it somehow possible to get this done using your docker-file?

Thanks and best regards,

Wilco

I'm new to docker so I'm having a hard time understanding this error. I've used the app-with-native-dependencies.dockerfile example in my project, but when running docker-compose up the meteor container is giving me this error:

app_1    | /opt/bundle/bundle/programs/server/node_modules/fibers/future.js:280
app_1    | 						throw(ex);
app_1    | 						^
app_1    | 
app_1    | Error: Error relocating /opt/bundle/bundle/programs/server/npm/node_modules/meteor/accounts-password/node_modules/bcrypt/lib/binding/napi-v3/bcrypt_lib.node: unsupported relocation type 7

My searches suggested it might be an architecture issue, so I attempted to solve it with docker-compose build --build-arg TARGETPLATFORM="linux/amd64" but that gave me the same problem. I also tried running everything from a Rosetta-based Terminal, but same problem. I also tried adding npm rebuild bcrypt --build-from-source to Dockerfile after RUN bash $SCRIPTS_FOLDER/build-meteor-npm-dependencies.sh --build-from-source, still same problem.

Any ideas?

Hi there, thanks for this repo, it's super helpful. I've a quick question. From reading the docs, it looks like this project is really geared at deploying a containerized Meteor instance — so things will get minified, etc. Is there a version of the sample Dockerfile that doesn't do latter build steps and just stands up an instance I can use during development? If not, I'll roll my own, but wanted to make sure I wasn't wasting my time if something like this already exists!

Hi,
I like the way you structured this meteor build using docker, specially with multi stage, that's genius! My question is if it would be possible to make meteor-base available on docker registry, so others can benefit from it easily, just using the multi stage sample.

Thanks.

Hello, I noticed that the example located at example/app-with-native-dependencies.dockerfile is still in 2.0. I don't know why happened this (maybe could be a merge), since in my last commit I updated it to 2.1

Hey all - I'm running a meteor 2.5 app, it's erroring below on the build-meteor-npm-dependencies.sh --build-from-source step - wondering if this has come up for anyone before?

 => ERROR [stage-1 5/5] RUN bash /docker/build-meteor-npm-dependencies.sh --build-from-source                                                                                                                           10.9s
------
 > [stage-1 5/5] RUN bash /docker/build-meteor-npm-dependencies.sh --build-from-source:

....
#16 10.69 > [email protected] install /opt/bundle/bundle/programs/server/npm/node_modules/bcrypt
#16 10.69 > node-pre-gyp install --fallback-to-build
#16 10.69
#16 10.76 internal/modules/cjs/loader.js:905
#16 10.76   throw err;
#16 10.76   ^
#16 10.76
#16 10.76 Error: Cannot find module '../'
#16 10.76 Require stack:
#16 10.76 - /opt/bundle/bundle/programs/server/npm/node_modules/.bin/node-pre-gyp
#16 10.76     at Function.Module._resolveFilename (internal/modules/cjs/loader.js:902:15)
#16 10.76     at Function.Module._load (internal/modules/cjs/loader.js:746:27)
#16 10.76     at Module.require (internal/modules/cjs/loader.js:974:19)
#16 10.76     at require (internal/modules/cjs/helpers.js:93:18)
#16 10.76     at Object.<anonymous> (/opt/bundle/bundle/programs/server/npm/node_modules/.bin/node-pre-gyp:15:20)
#16 10.76     at Module._compile (internal/modules/cjs/loader.js:1085:14)
#16 10.76     at Object.Module._extensions..js (internal/modules/cjs/loader.js:1114:10)
#16 10.76     at Module.load (internal/modules/cjs/loader.js:950:32)
#16 10.76     at Function.Module._load (internal/modules/cjs/loader.js:790:12)
#16 10.76     at Function.executeUserEntryPoint [as runMain] (internal/modules/run_main.js:76:12) {
#16 10.76   code: 'MODULE_NOT_FOUND',
#16 10.76   requireStack: [
#16 10.76     '/opt/bundle/bundle/programs/server/npm/node_modules/.bin/node-pre-gyp'
#16 10.76   ]

If .meteor/local stays persistent, build time reduces. Is it possible to cache this directory?

Think I've run into a bug. My docker-compose file, which is mostly the same as your default one, specifies an app and a mongo database (and a headless browser, but that's beside the point).

After building, if I run docker-compose -f docker-compose.production.yml up, here's what I see:

$ docker-compose -f docker-compose.production.yml up
Creating network "chart-tool_chart-tool-network" with the default driver
Creating chart-tool_mongo_1       ... done
Creating chart-tool_browserless_1 ... done
Creating chart-tool_app_1         ... done
Attaching to chart-tool_browserless_1, chart-tool_mongo_1, chart-tool_app_1
app_1          | Connecting to MongoDB...
app_1          | (node:6) DeprecationWarning: current Server Discovery and Monitoring engine is deprecated, and will be removed in a future version. To use the new Server Discover and Monitoring engine, pass option { useUnifiedTopology: true } to the MongoClient constructor.

And it just waits to connect… forever. I waited 10min earlier with no connection. Oddly, running docker-compose -f docker-compose.production.yml run --service-ports app bash does actually make a Mongo connection:

$ docker-compose -f docker-compose.production.yml run --service-ports app bash
Starting chart-tool_mongo_1 ... done
Starting chart-tool_browserless_1 ... done
Connecting to MongoDB...
(node:7) DeprecationWarning: current Server Discovery and Monitoring engine is deprecated, and will be removed in a future version. To use the new Server Discover and Monitoring engine, pass option { useUnifiedTopology: true } to the MongoClient constructor.
Starting app...
bash-5.0# exit
exit

That said, I think I might have an idea of what's going on. I tested the Node script from the connect-to-mongo.sh, and running it independently results in a module missing error. Is it possible that the mongodb package isn't getting installed and available globally?

No idea why, I copied the example file, and on docker build -t myapp . the scripts fails on

Sending build context to Docker daemon  23.48MB
Step 1/14 : FROM geoffreybooth/meteor-base:1.7.0.3
 ---> 05c9372eae61
Step 2/14 : COPY ./package*.json $APP_SOURCE_FOLDER/
 ---> Using cache
 ---> 4071b4468bc7
Step 3/14 : RUN bash $SCRIPTS_FOLDER/build-app-npm-dependencies.sh
 ---> Running in e3c8917a6feb

[-] Installing app NPM dependencies...

npm ERR! write after end
npm ERR! write after end
npm ERR! write after end
npm ERR! write after end

npm ERR! A complete log of this run can be found in:
npm ERR!     /root/.npm/_logs/2018-09-28T18_47_26_273Z-debug.log
The command '/bin/sh -c bash $SCRIPTS_FOLDER/build-app-npm-dependencies.sh' returned a non-zero code: 1

npm log is not really helping:

28079 http fetch GET 200 https://registry.npmjs.org/@babel/parser/-/parser-7.0.0-beta.51.tgz 939ms
28080 http fetch GET 200 https://registry.npmjs.org/@babel/parser/-/parser-7.1.0.tgz 1025ms
28081 http fetch GET 200 https://registry.npmjs.org/ulid/-/ulid-2.3.0.tgz 387ms
28082 http fetch GET 200 https://registry.npmjs.org/wellknown/-/wellknown-0.5.0.tgz 408ms
28083 http fetch GET 200 https://registry.npmjs.org/style 417ms
28084 verbose stack Error: write after end
28084 verbose stack     at writeAfterEnd (_stream_writable.js:236:12)
28084 verbose stack     at PassThrough.Writable.write (_stream_writable.js:287:5)
28084 verbose stack     at PassThrough.Writable.end (_stream_writable.js:563:10)
28084 verbose stack     at ReadEntry.entry.on (/root/.meteor/packages/meteor-tool/.1.7.0_3.u9lhms.hf7k++os.linux.x86_64+web.browser+web.browser.legacy+web.cordova/mt-os.linux.x86_64/dev_bundle/lib/node_modules/pacote/lib/extract-stream.js:19:41)
28084 verbose stack     at emitOne (events.js:121:20)
28084 verbose stack     at ReadEntry.emit (events.js:211:7)
28084 verbose stack     at ReadEntry.emit (/root/.meteor/packages/meteor-tool/.1.7.0_3.u9lhms.hf7k++os.linux.x86_64+web.browser+web.browser.legacy+web.cordova/mt-os.linux.x86_64/dev_bundle/lib/node_modules/minipass/index.js:309:30)
28084 verbose stack     at ReadEntry.[maybeEmitEnd] (/root/.meteor/packages/meteor-tool/.1.7.0_3.u9lhms.hf7k++os.linux.x86_64+web.browser+web.browser.legacy+web.cordova/mt-os.linux.x86_64/dev_bundle/lib/node_modules/minipass/index.js:257:12)
28084 verbose stack     at ReadEntry.end (/root/.meteor/packages/meteor-tool/.1.7.0_3.u9lhms.hf7k++os.linux.x86_64+web.browser+web.browser.legacy+web.cordova/mt-os.linux.x86_64/dev_bundle/lib/node_modules/minipass/index.js:167:27)
28084 verbose stack     at Unpack.[consumeBody] (/root/.meteor/packages/meteor-tool/.1.7.0_3.u9lhms.hf7k++os.linux.x86_64+web.browser+web.browser.legacy+web.cordova/mt-os.linux.x86_64/dev_bundle/lib/node_modules/pacote/node_modules/tar/lib/parse.js:210:13)
28084 verbose stack     at Unpack.[consumeChunkSub] (/root/.meteor/packages/meteor-tool/.1.7.0_3.u9lhms.hf7k++os.linux.x86_64+web.browser+web.browser.legacy+web.cordova/mt-os.linux.x86_64/dev_bundle/lib/node_modules/pacote/node_modules/tar/lib/parse.js:391:40)
28084 verbose stack     at Unpack.[consumeChunk] (/root/.meteor/packages/meteor-tool/.1.7.0_3.u9lhms.hf7k++os.linux.x86_64+web.browser+web.browser.legacy+web.cordova/mt-os.linux.x86_64/dev_bundle/lib/node_modules/pacote/node_modules/tar/lib/parse.js:362:30)
28084 verbose stack     at Unzip.(anonymous function).on.chunk (/root/.meteor/packages/meteor-tool/.1.7.0_3.u9lhms.hf7k++os.linux.x86_64+web.browser+web.browser.legacy+web.cordova/mt-os.linux.x86_64/dev_bundle/lib/node_modules/pacote/node_modules/tar/lib/parse.js:291:59)
28084 verbose stack     at emitOne (events.js:116:13)
28084 verbose stack     at Unzip.emit (events.js:211:7)
28084 verbose stack     at Unzip.emit (/root/.meteor/packages/meteor-tool/.1.7.0_3.u9lhms.hf7k++os.linux.x86_64+web.browser+web.browser.legacy+web.cordova/mt-os.linux.x86_64/dev_bundle/lib/node_modules/minipass/index.js:309:30)
28084 verbose stack     at Unzip.write (/root/.meteor/packages/meteor-tool/.1.7.0_3.u9lhms.hf7k++os.linux.x86_64+web.browser+web.browser.legacy+web.cordova/mt-os.linux.x86_64/dev_bundle/lib/node_modules/minipass/index.js:104:17)
28084 verbose stack     at Unzip.write (/root/.meteor/packages/meteor-tool/.1.7.0_3.u9lhms.hf7k++os.linux.x86_64+web.browser+web.browser.legacy+web.cordova/mt-os.linux.x86_64/dev_bundle/lib/node_modules/minizlib/index.js:284:29)
28084 verbose stack     at Unpack.write (/root/.meteor/packages/meteor-tool/.1.7.0_3.u9lhms.hf7k++os.linux.x86_64+web.browser+web.browser.legacy+web.cordova/mt-os.linux.x86_64/dev_bundle/lib/node_modules/pacote/node_modules/tar/lib/parse.js:307:19)
28084 verbose stack     at PassThrough.ondata (_stream_readable.js:639:20)
28084 verbose stack     at emitOne (events.js:116:13)
28084 verbose stack     at PassThrough.emit (events.js:211:7)
28085 verbose cwd /opt/src
28086 verbose Linux 4.9.93-linuxkit-aufs
28087 verbose argv "/root/.meteor/packages/meteor-tool/.1.7.0_3.u9lhms.hf7k++os.linux.x86_64+web.browser+web.browser.legacy+web.cordova/mt-os.linux.x86_64/dev_bundle/bin/node" "/root/.meteor/packages/meteor-tool/.1.7.0_3.u9lhms.hf7k++os.linux.x86_64+web.browser+web.browser.legacy+web.cordova/mt-os.linux.x86_64/dev_bundle/bin/npm" "install"
28088 verbose node v8.11.3
28089 verbose npm  v5.10.0
28090 error write after end
28091 verbose exit [ 1, true ]

Hi, It would be great if the dockerfile image of meteor-base would bring installed Yarn in order to install dependencies with it. This is, because some developers (like me) we use yarn as package manager because it's faster than npm. I noticed that in these scripts use npm command:

build-app-npm-dependencies.sh
build-meteor-npm-dependencies.sh

So, I was looking for and I found out that it is possible to run meteor yarn install on linux systems.

So, I imagine configuring this part in the dockerfile as follow:

ENV PACKAGE_MANAGER yarn //by default is npm

https://forums.meteor.com/t/meteor-1-10-released/52091

Hi there !
You could use

  https://install.meteor.com/?release=METEOR_VERSION 

to get directly the good install-meteor.sh :)

docker-compose

version: '3'

services:
  app:
    build:
      context: .
      dockerfile: Dockerfile
    ports:
      - '80:3000'
    depends_on:
      - mongo
    environment:
      ROOT_URL: http://localhost
      MONGO_URL: mongodb://mongo:123/meteor
      PORT: 3000

  mongo:
    image: mongo:latest
    port:
      - 123:27017
    command:
      - --storageEngine=wiredTiger
    volumes:
      - data:/data/db

volumes:
  data:

But don't work

failed to connect to server [mongo:123] on first connect [Error: getaddrinfo ENOTFOUND mongo

I cannot see the app in browser, even with the example app in the repo. In the console I didn't see errors.

Creating example_mongo_1 ... done Creating example_app_1 ... done Attaching to example_mongo_1, example_app_1 mongo_1 | 2019-10-27T22:19:34.637+0000 I CONTROL [main] Automatically disabling TLS 1.0, to force-enable TLS 1.0 specify --sslDisabledProtocols 'none' app_1 | Connecting to MongoDB... mongo_1 | 2019-10-27T22:19:34.826+0000 I CONTROL [initandlisten] MongoDB starting : pid=1 port=27017 dbpath=/data/db 64-bit host=489523aadb16 mongo_1 | 2019-10-27T22:19:34.826+0000 I CONTROL [initandlisten] db version v4.2.1 mongo_1 | 2019-10-27T22:19:34.826+0000 I CONTROL [initandlisten] git version: edf6d45851c0b9ee15548f0f847df141764a317e mongo_1 | 2019-10-27T22:19:34.826+0000 I CONTROL [initandlisten] OpenSSL version: OpenSSL 1.1.1 11 Sep 2018 mongo_1 | 2019-10-27T22:19:34.826+0000 I CONTROL [initandlisten] allocator: tcmalloc mongo_1 | 2019-10-27T22:19:34.826+0000 I CONTROL [initandlisten] modules: none mongo_1 | 2019-10-27T22:19:34.826+0000 I CONTROL [initandlisten] build environment: mongo_1 | 2019-10-27T22:19:34.826+0000 I CONTROL [initandlisten] distmod: ubuntu1804 mongo_1 | 2019-10-27T22:19:34.826+0000 I CONTROL [initandlisten] distarch: x86_64 mongo_1 | 2019-10-27T22:19:34.826+0000 I CONTROL [initandlisten] target_arch: x86_64 mongo_1 | 2019-10-27T22:19:34.826+0000 I CONTROL [initandlisten] options: { net: { bindIp: "*" }, storage: { engine: "wiredTiger" } } mongo_1 | 2019-10-27T22:19:34.826+0000 I STORAGE [initandlisten] mongo_1 | 2019-10-27T22:19:34.827+0000 I STORAGE [initandlisten] ** WARNING: Using the XFS filesystem is strongly recommended with the WiredTiger storage engine mongo_1 | 2019-10-27T22:19:34.827+0000 I STORAGE [initandlisten] ** See http://dochub.mongodb.org/core/prodnotes-filesystem mongo_1 | 2019-10-27T22:19:34.827+0000 I STORAGE [initandlisten] wiredtiger_open config: create,cache_size=1358M,cache_overflow=(file_max=0M),session_max=33000,eviction=(threads_min=4,threads_max=4),config_base=false,statistics=(fast),log=(enabled=true,archive=true,path=journal,compressor=snappy),file_ma nager=(close_idle_time=100000,close_scan_interval=10,close_handle_minimum=250),statistics_log=(wait=0),verbose=[recovery_progress,checkpoint_progress], mongo_1 | 2019-10-27T22:19:35.629+0000 I STORAGE [initandlisten] WiredTiger message [1572214775:629831][1:0x7f1a641bcb00], txn-recover: Set global recovery timestamp: (0,0) mongo_1 | 2019-10-27T22:19:35.933+0000 I RECOVERY [initandlisten] WiredTiger recoveryTimestamp. Ts: Timestamp(0, 0) mongo_1 | 2019-10-27T22:19:36.155+0000 I STORAGE [initandlisten] Timestamp monitor starting mongo_1 | 2019-10-27T22:19:36.288+0000 I CONTROL [initandlisten] mongo_1 | 2019-10-27T22:19:36.288+0000 I CONTROL [initandlisten] ** WARNING: Access control is not enabled for the database. mongo_1 | 2019-10-27T22:19:36.288+0000 I CONTROL [initandlisten] ** Read and write access to data and configuration is unrestricted. mongo_1 | 2019-10-27T22:19:36.288+0000 I CONTROL [initandlisten] mongo_1 | 2019-10-27T22:19:36.326+0000 I STORAGE [initandlisten] createCollection: admin.system.version with provided UUID: 2b78ff52-587c-4f66-942e-ac5078f61d94 and options: { uuid: UUID("2b78ff52-587c-4f66-942e-ac5078f61d94") } mongo_1 | 2019-10-27T22:19:36.647+0000 I INDEX [initandlisten] index build: done building index id on ns admin.system.version mongo_1 | 2019-10-27T22:19:36.651+0000 I SHARDING [initandlisten] Marking collection admin.system.version as collection version: mongo_1 | 2019-10-27T22:19:36.651+0000 I COMMAND [initandlisten] setting featureCompatibilityVersion to 4.2 mongo_1 | 2019-10-27T22:19:36.652+0000 I SHARDING [initandlisten] Marking collection local.system.replset as collection version: mongo_1 | 2019-10-27T22:19:36.663+0000 I STORAGE [initandlisten] Flow Control is enabled on this deployment. mongo_1 | 2019-10-27T22:19:36.670+0000 I SHARDING [initandlisten] Marking collection admin.system.roles as collection version: mongo_1 | 2019-10-27T22:19:36.672+0000 I STORAGE [initandlisten] createCollection: local.startup_log with generated UUID: fed7f9bd-d29f-4d2e-9779-07fffc6e5161 and options: { capped: true, size: 10485760 } mongo_1 | 2019-10-27T22:19:36.930+0000 I INDEX [initandlisten] index build: done building index id on ns local.startup_log mongo_1 | 2019-10-27T22:19:36.930+0000 I SHARDING [initandlisten] Marking collection local.startup_log as collection version: mongo_1 | 2019-10-27T22:19:36.931+0000 I FTDC [initandlisten] Initializing full-time diagnostic data capture with directory '/data/db/diagnostic.data' mongo_1 | 2019-10-27T22:19:36.941+0000 I SHARDING [LogicalSessionCacheRefresh] Marking collection config.system.sessions as collection version: mongo_1 | 2019-10-27T22:19:36.941+0000 I NETWORK [initandlisten] Listening on /tmp/mongodb-27017.sock mongo_1 | 2019-10-27T22:19:36.941+0000 I NETWORK [initandlisten] Listening on 0.0.0.0 mongo_1 | 2019-10-27T22:19:36.941+0000 I NETWORK [initandlisten] waiting for connections on port 27017 mongo_1 | 2019-10-27T22:19:36.983+0000 I NETWORK [listener] connection accepted from 172.19.0.3:59042 #1 (1 connection now open) mongo_1 | 2019-10-27T22:19:36.983+0000 I NETWORK [listener] connection accepted from 172.19.0.3:59044 #2 (2 connections now open) mongo_1 | 2019-10-27T22:19:36.985+0000 I NETWORK [listener] connection accepted from 172.19.0.3:59046 #3 (3 connections now open) mongo_1 | 2019-10-27T22:19:36.985+0000 I CONTROL [LogicalSessionCacheReap] Sessions collection is not set up; waiting until next sessions reap interval: config.system.sessions does not exist mongo_1 | 2019-10-27T22:19:36.985+0000 I STORAGE [LogicalSessionCacheRefresh] createCollection: config.system.sessions with provided UUID: 585b4088-7024-4771-b62e-a59d50deb230 and options: { uuid: UUID("585b4088-7024-4771-b62e-a59d50deb230") } mongo_1 | 2019-10-27T22:19:37.000+0000 I SHARDING [ftdc] Marking collection local.oplog.rs as collection version: mongo_1 | 2019-10-27T22:19:37.008+0000 I NETWORK [conn3] received client metadata from 172.19.0.3:59046 conn3: { driver: { name: "nodejs", version: "3.0.7" }, os: { type: "Linux", name: "linux", architecture: "x64", version: "4.9.184-linuxkit" }, platform: "Node.js v8.16.2, LE, mongodb-core: 3.0.7" } mongo_1 | 2019-10-27T22:19:37.014+0000 I NETWORK [conn3] end connection 172.19.0.3:59046 (2 connections now open) mongo_1 | 2019-10-27T22:19:37.255+0000 I INDEX [LogicalSessionCacheRefresh] index build: done building index id on ns config.system.sessions mongo_1 | 2019-10-27T22:19:37.496+0000 I INDEX [LogicalSessionCacheRefresh] index build: starting on config.system.sessions properties: { v: 2, key: { lastUse: 1 }, name: "lsidTTLIndex", ns: "config.system.sessions", expireAfterSeconds: 1800 } using method: Hybrid mongo_1 | 2019-10-27T22:19:37.496+0000 I INDEX [LogicalSessionCacheRefresh] build may temporarily use up to 500 megabytes of RAM mongo_1 | 2019-10-27T22:19:37.496+0000 I INDEX [LogicalSessionCacheRefresh] index build: collection scan done. scanned 0 total records in 0 seconds mongo_1 | 2019-10-27T22:19:37.496+0000 I INDEX [LogicalSessionCacheRefresh] index build: inserted 0 keys from external sorter into index in 0 seconds mongo_1 | 2019-10-27T22:19:37.538+0000 I INDEX [LogicalSessionCacheRefresh] index build: done building index lsidTTLIndex on ns config.system.sessions mongo_1 | 2019-10-27T22:19:37.579+0000 I COMMAND [LogicalSessionCacheRefresh] command config.system.sessions command: createIndexes { createIndexes: "system.sessions", indexes: [ { key: { lastUse: 1 }, name: "lsidTTLIndex", expireAfterSeconds: 1800 } ], $db: "config" } numYields:0 reslen:114 locks:{ Para llelBatchWriterMode: { acquireCount: { r: 2 } }, ReplicationStateTransition: { acquireCount: { w: 3 } }, Global: { acquireCount: { r: 1, w: 2 } }, Database: { acquireCount: { r: 1, w: 2, W: 1 } }, Collection: { acquireCount: { r: 4, w: 1, R: 1, W: 2 } }, Mutex: { acquireCount: { r: 3 } } } flowControl:{ acq uireCount: 1 } storage:{} protocol:op_msg 594ms

I get an issue with 1.8.1 where the build is successful, but the app does not come up in browser.

I did docker-compose up --build from the example dir
dcompose_log.txt

The images come up in docker, but app does not load.

Can you confirm that docker-compose works with meteor 1.8.1?

It does come up if I run app directly with the Ubuntu Host Meteor, so I'm not sure where the bug is.

Hi,

First thanks so much for creating this great repo. So far I have followed the steps on the README and have been able to run my container without problems. Now I would like to populate the database with some data when deploying. In my local computer I usually run this command :
mongorestore -h 127.0.0.1 --port 3001 -d meteor --drop dump/meteor
where dump/meteor is the folder that contains my backup. This command would need to execute after mongo and meteor are up. Any suggestion on how I can implement this using your scripts?

I am using DC/OS marathon to run meteor web app. My meteor app is crashing with status code 139, failed to accept socket loop error. Do you have any solutions ?

ERROR: Service 'app' failed to build: manifest for geoffreybooth/meteor-base:2.1 not found: manifest unknown: manifest unknown

I'm copied your Dockerfile, docker-compose.yml and .dockerignore to the root of a project of mine. The project runs fine in my computer, but when I run docker-compose up in the server (I ssh into the server before running locally), I get the following message and the process apparently hangs:

Building app
Step 1/14 : FROM geoffreybooth/meteor-base:1.7.0.3
 ---> ac044469284c
Step 2/14 : COPY ./app/package*.json $APP_SOURCE_FOLDER/
 ---> Using cache
 ---> a5d65c4a3e42
Step 3/14 : RUN bash $SCRIPTS_FOLDER/build-app-npm-dependencies.sh
 ---> Using cache
 ---> 24c301e78737
Step 4/14 : COPY ./app $APP_SOURCE_FOLDER/
 ---> Using cache
 ---> 6700ddb24352
Step 5/14 : RUN bash $SCRIPTS_FOLDER/build-meteor-bundle.sh
 ---> Running in a6e2ad239e11

[-] Building Meteor application bundle...


Even with METEOR_ALLOW_SUPERUSER or --allow-superuser, permissions in your app
directory will be incorrect if you ever attempt to perform any Meteor tasks as
a normal user. If you need to fix your permissions, run the following command
from the root of your project:

  sudo chown -Rh <username> .meteor/local


Even with METEOR_ALLOW_SUPERUSER or --allow-superuser, permissions in your app
directory will be incorrect if you ever attempt to perform any Meteor tasks as
a normal user. If you need to fix your permissions, run the following command
from the root of your project:

  sudo chown -Rh <username> .meteor/local

Would you know how to fix this? I added the following to the environment section in the docker-compose.yml file, but it seems it had no effect:

    ...
    environment:
      ...
      METEOR_NO_RELEASE_CHECK: 'true'
      METEOR_ALLOW_SUPERUSER: 'true'

Docker version 18.06.0-ce, build 0ffa825
docker-compose version 1.23.2, build 1110ad01

Hey @GeoffreyBooth, thanks for your efforts on this project!

This issue is mainly to help people googling for these keyword: OOM, out-of-memory, non-zero exit code 137 error, aborted build.

You might be affected by meteor/meteor#9568.

meteor build can use more RAM than you expect. Setting --max-old-space-size=2048 or similar options for Node won't help (as of Meteor 1.10.2), as the source maps generation is currently using wasm and explicitly switches off GC to mitigate another issue in node-fibers.

This issue is frustrating to find in CI setups, where the container is usually just stopped - not all environments display a sensible error message for out-of-memory errors.

Potential solutions: meteor/meteor#9568 (comment)

I don't know if Meteor will adopt my suggestion from meteor/meteor#9568 (comment) - but if not, it might be a good idea to add it to this image's build scripts :)

Okay, I lied, I am having an issue.

I think it might be a perms problem, the app builds beautifully, but when firing off calls to meteor using the accounts package, the container exits with code 139. I have been banging my head against the wall all day.

I noticed the other older dockerfiles add a separate user and then change the owner to said user. I ran my app in docker rjshimko/meteor-launchpad which adds the seperate user and it works fine with the accounts package, but the file is huge. I have been playing with adding a user and modifying the perms, but still no dice. I am a docker noob. Do you have any advice or solutions to this problem?

This isn't an issue. Just wanted to say THANK YOU for open sourcing this. Saved my butt trying to deploy a lean docker file on Zeit.

Hi, is it normal this behavior in 1.11.1 ?

These logs didn't happen with 1.10.1 version, so, I wonder if that is normal? Also, I realized that take more time building the image with those logs.

My dockerfile is the following (I just add a little more code for the timezone):

# The tag here should match the Meteor version of your app, per .meteor/release
FROM geoffreybooth/meteor-base:1.11.1

# Copy app package.json and package-lock.json into container
COPY ./package*.json $APP_SOURCE_FOLDER/

RUN bash $SCRIPTS_FOLDER/build-app-npm-dependencies.sh

# Copy app source into container
COPY . $APP_SOURCE_FOLDER/

RUN bash $SCRIPTS_FOLDER/build-meteor-bundle.sh

# Use the specific version of Node expected by your Meteor release, per https://docs.meteor.com/changelog.html; this is expected for Meteor 1.9
FROM node:12.18.4-alpine

ENV APP_BUNDLE_FOLDER /opt/bundle
ENV SCRIPTS_FOLDER /docker
# Runtime dependencies; if your dependencies need compilation (native modules such as bcrypt) or you are using Meteor <1.8.1, use app-with-native-dependencies.dockerfile instead
RUN apk update
RUN apk upgrade
RUN apk --no-cache add \
                bash \
		g++ \
		make \
		python

# Copy in entrypoint
COPY --from=0 $SCRIPTS_FOLDER $SCRIPTS_FOLDER/

# Copy in app bundle
COPY --from=0 $APP_BUNDLE_FOLDER/bundle $APP_BUNDLE_FOLDER/bundle/

RUN bash $SCRIPTS_FOLDER/build-meteor-npm-dependencies.sh --build-from-source

# Start another Docker stage, so that the final image doesn’t contain the layer with the build dependencies
# See previous FROM line; this must match
FROM node:12.18.4-alpine

ENV APP_BUNDLE_FOLDER /opt/bundle
ENV SCRIPTS_FOLDER /docker

# Install OS runtime dependencies
RUN apk --no-cache add \
	bash \
	ca-certificates \
    && update-ca-certificates

RUN apk --no-cache add --update tzdata

ENV TZ America/Mexico_City
RUN rm -rf /var/cache/apk/*

# Copy in entrypoint with the built and installed dependencies from the previous image
COPY --from=1 $SCRIPTS_FOLDER $SCRIPTS_FOLDER/

# Copy in app bundle with the built and installed dependencies from the previous image
COPY --from=1 $APP_BUNDLE_FOLDER/bundle $APP_BUNDLE_FOLDER/bundle/

# Start app
ENTRYPOINT ["/docker/entrypoint.sh"]

CMD ["node", "main.js"]

First of all, thank you for this project. It is a huge life-saver in a k8s migration I'm performing.

just wanted to get feedback on this and if it's abnormal:

I'm using the Dockerfile with native dependancies, the following step:

Step 8/24 : RUN bash $SCRIPTS_FOLDER/build-meteor-bundle.sh

is taking a very long time (~22 minutes) in CircleCI. Granted, the project is quite large.

Is this expected or are there any suggested performance enhancers I could try out?

Thank you.

I followed examples and build my image. When I run two services app and mongo it works as expected. However, when I remove mongo service and dependence from app service it gave me an error as follows even If I passed the correct MONGO_URL.

Connecting to MongoDB...
(node:7) DeprecationWarning: current Server Discovery and Monitoring engine is deprecated, and will be removed in a future version. To use the new Server Discover and Monitoring engine, pass option { useUnifiedTopology: true } to the MongoClient constructor.
Successfully connected to MongoDB
Starting app...
(node:1) [DEP0131] DeprecationWarning: The legacy HTTP parser is deprecated.
/opt/bundle/bundle/programs/server/node_modules/fibers/future.js:313
                                                throw(ex);
                                                ^
MongoServerSelectionError: connect ECONNREFUSED 127.0.0.1:27017
    at Timeout._onTimeout (/opt/bundle/bundle/programs/server/npm/node_modules/meteor/npm-mongo/node_modules/mongodb/lib/core/sdam/topology.js:439:30)
    at listOnTimeout (internal/timers.js:554:17)
    at processTimers (internal/timers.js:497:7) {
  reason: TopologyDescription {
    type: 'ReplicaSetNoPrimary',
    setName: 'rs0',
    maxSetVersion: 1,
    maxElectionId: ObjectID {
      _bsontype: 'ObjectID',
      id: Buffer(12) [Uint8Array] [
        127, 255, 255, 255, 0,
          0,   0,   0,   0, 0,
          0,  20
      ]
    },
    servers: Map {
      '127.0.0.1:27017' => ServerDescription {
        address: '127.0.0.1:27017',
        error: Error: connect ECONNREFUSED 127.0.0.1:27017
            at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1144:16) {
          name: 'MongoNetworkError'
        },
        roundTripTime: -1,
        lastUpdateTime: 1162875703,
        lastWriteDate: null,
        opTime: null,
        type: 'Unknown',
        topologyVersion: undefined,
        minWireVersion: 0,
        maxWireVersion: 0,
        hosts: [],
        passives: [],
        arbiters: [],
        tags: []
      }
    },
    stale: false,
    compatible: true,
    compatibilityError: null,
    logicalSessionTimeoutMinutes: null,
    heartbeatFrequencyMS: 10000,
    localThresholdMS: 15,
    commonWireVersion: 9
  }
}

Could use with Meteor 1.3x, 1.4.x, 1.5x?

Thanks for all of the great work. Your images are fantastic. We recently upgraded our application's Meteor version from 2.5 to 2.5.3 due to a major performance fix. What are your plans for publishing a new docker image for the 2.5.3 release. We aren't able to deploy this vital fix to our production endpoint until the image is available. Thanks.

Similar issue to #82. This is completely odd, there's something very wrong.

By way of background, everything is hunky-dory when I run the mongo container as part of my docker-compose.

This doesn't satisfy my requirements because we are running our mongo server on a different machine in the same network, so I cannot simply run it in a container.

However, when I try to pass along another IP address in the MONGO_URL environment variable (or even DNS name based on your advice from #82), I got the same message:

MongoServerSelectionError: connect ECONNREFUSED 127.0.0.1:27017

Please help, I'm not using 127.0.01 anywhere!

The base docker image does not work for meteor 1.9.2

docker pull geoffreybooth/meteor-base:1.9.2

The response is

Error response from daemon: manifest for geoffreybooth/meteor-base:1.9.2 not found: manifest unknown: manifest unknown

This line

https://github.com/disney/meteor-base/blob/main/example/app-with-native-dependencies.dockerfile#L26

does not work anymore.

docker run --rm -it node:14.18.1-alpine apk add --no-cache python
# outputs
fetch https://dl-cdn.alpinelinux.org/alpine/v3.14/main/x86_64/APKINDEX.tar.gz
fetch https://dl-cdn.alpinelinux.org/alpine/v3.14/community/x86_64/APKINDEX.tar.gz
ERROR: unable to select packages:
  python (no such package):
    required by: world[python]

# but

docker run --rm -it node:14.18.1-alpine apk add --no-cache python3
# outputs
fetch https://dl-cdn.alpinelinux.org/alpine/v3.14/main/x86_64/APKINDEX.tar.gz
fetch https://dl-cdn.alpinelinux.org/alpine/v3.14/community/x86_64/APKINDEX.tar.gz
(1/11) Installing libbz2 (1.0.8-r1)
(2/11) Installing expat (2.4.1-r0)
(3/11) Installing libffi (3.3-r2)
(4/11) Installing gdbm (1.19-r0)
(5/11) Installing xz-libs (5.2.5-r0)
(6/11) Installing mpdecimal (2.5.1-r1)
(7/11) Installing ncurses-terminfo-base (6.2_p20210612-r0)
(8/11) Installing ncurses-libs (6.2_p20210612-r0)
(9/11) Installing readline (8.1.0-r0)
(10/11) Installing sqlite-libs (3.35.5-r0)
(11/11) Installing python3 (3.9.5-r1)
Executing busybox-1.33.1-r3.trigger
OK: 56 MiB in 27 packages

I couldn't find the documentation telling why such a change happened, but I'll update this issue with the source if I find it

Hi. I'm sort of new to docker so I'm not really sure if this is a docker thing. I followed the instructions with a fresh meteor app but it's stuck at Starting app...

OS: Windows 10 Pro
Meteor version: 1.7.0.5
Docker version: 18.06.1-ce-win73
Compose version: 1.22.0

The only change in the Dockerfile is the meteor version from 1.7.0.3 to 1.7.0.5

Any ideas?

I am now planning on moving my own build script to using this package as multi stage build, and I found a neat trick in my script which might be cool to share to the users of this script.

When running my script, I have a docker-variable for the name of the base-image, which is filled with the value used in my current environment. Let me put this into an example.

In the environment of my project, I have a clear reference what version of meteor and nodejs I'm using.

A call of meteor node --version | cut -c2-99 reveals the version of nodejs and meteor --version | cut -c8-99 reveals the version of meteor.

So why not propose to start the build-script with:

ARG  METEOR_VERSION
ARG  NODE_VERSION

FROM geoffreybooth/meteor-base:${METEOR_VERSION}

[...]

FROM node:${NODE_VERSION}-alpine

[...]

And call docker build --build-arg NODE_VERSION=$(meteor node --version | cut -c2-99) --build-arg METEOR_VERSION=$(meteor --version | cut -c8-99) and use them in the multi stage build script? It's just a very neat trick, I think, people should get to know of.

But I sadly have to drop it since I cannot get a docker-build argument being passed on by another build-step. This means I cannot have a docker file which you just run and it will figure all this out 😢 Maybe it helps someone leaving it as a hint.

EDIT: Fixed the example of a Dockerfile file according to moby/moby#37345 (comment). Variables which I want to have available in all steps must be declared before the first FROM definition.

Hello, I noticed that current version of meteor-base is still in 1.11.1 version. So, I wanted to open this issue to remind that there is already a new version of Meteor.

On the other hand, I wonder if I can use geoffreybooth/meteor-base:1.11.1 to deploy a meteor app in version 1.12?

Greetings.

Same as the title.
The docker.io is still 2.1.1. I think we should update the docker image to 2.2 on the docker.io.

after building a image, the meteor inside the container always runs on port 3000, even if I have set the -e PORT=3030 or others.