Upgrade meteor?

[kaihendry]

IIUC current version Meteor is 1.8. https://www.meteor.com/install

Will I have issues running Meteor 1.8 developed code in this Docker image?

[Ulexus]

You should not have any problems, no. The script detects the Meteor version required and installs it.

[kaihendry]

But I think node is not updated. https://github.com/CyCoreSystems/docker-meteor/blob/master/Dockerfile#L10

Meteor 1.8 for example requires Node 8.

[Ulexus]

Yeah, I see, thanks. This whole repo needs some updating; it has languished for a while, since most of my sites are off Meteor, nowadays. I'm running through everything right now, though.

[kaihendry]

What did you migrate to if you're off Meteor out of curiosity?

[Ulexus]

What I moved to isn't really a replacement for Meteor; I just started running away when it looked like we were going to have React shoved down our Meteor throats. I'm mostly using Echo (Go) on the backend and Vue on the front. I've cobbled together some tooling to take the edge off, but it is nothing like Meteor, really.

[Ulexus]

Just an update: this is what I currently have, for a functional multi-stage builder

FROM node:8.11.4 AS builder

# For some reason, the container ships with an old version of npm
RUN npm install -g npm

RUN su -c "curl -o /tmp/meteor.sh 'https://install.meteor.com?release=1.8.0.2'; sh /tmp/meteor.sh; rm -f /tmp/meteor.sh" node
RUN cp "/home/node/.meteor/packages/meteor-tool/1.8.0_2/mt-os.linux.x86_64/scripts/admin/launch-meteor" /usr/bin/meteor
RUN mkdir /src /bundle
RUN chown -R node /src /bundle

USER node:node

WORKDIR /src
COPY --chown=node:node . .
RUN meteor npm install --production
RUN meteor build --directory /bundle
RUN cd /bundle/bundle/programs/server && npm install

FROM node:8.11.4-slim

USER node:node

COPY --from=builder /bundle /app
WORKDIR /app/bundle

EXPOSE 3000

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

[Ulexus]

Advantages:

• much smaller image size
• starts up a whole lot faster
• builds entirely in my CI/CD directly from unmolested source

Still needed:

• manual version control of Node
• distribution method beyond simply a Dockerfile template

[kaihendry]

So IIUC you introduce another stage to alleviate the whole fibers install on my current Dockerfile?

Looks good https://media.dev.unee-t.com/2019-03-05/docker-meteor.txt !

Why not a more straightforward curl https://install.meteor.com/ | sh without specifying release? Also I honestly prefer to use latest instead of 8.11.4 et al. Why aren't latest stable releases good enough here?

Is there a way to escape specifying user permissions? Gives me heart burn.

Otherwise, looking really promising. If I could only figure out what port it's on. https://media.dev.unee-t.com/2019-03-05/port.mp4 Not sure why I can't get perms to install lsof.

[Ulexus]

multiple stages

The main thing about the second stage is that we can exclude a whole bunch of the compilation detritus. The compilation tools and the various required sources take up a huge amount of space. While Node software is generally interpreted, there are a number of components (including fibers and bcrypt) which are compiled. As such, they are architecture-dependent. Since many developers use things like MacOS and Windows or even 32-bit x86 or ARM, while most servers are Linux/x86-64, the dev compilation artifacts are often very different from the service artifacts.

Using a multi-stage build simplifies both of these things.

User ownership

No. Not only is it good practice, but Meteor now enforces it.

Meteor:latest

It is always going to be more efficient (and safer) to use the same version of the meteor tool as the project. It's probably safe to use a later (latest, perhaps) version, but safer is better.

Web service port

The port on which Meteor listens is completely controlled by the PORT environment variable. By default (so the docs say), it listens on port 80... but since it does not run as root inside the container, it most likely does not have permission to listen on port 80. I'd guess it failed to listen at all but did not die catastrophically (as one might have expected). Just set the PORT variable to something above 1024, and you should be fine. I generally use 3000, since that matches the port that the meteor tool uses, by default.

[Ulexus]

On the subject of the PORT variable, the README in the server directory specifies four important environment variables:

  $ export MONGO_URL='mongodb://user:password@host:port/databasename'
  $ export ROOT_URL='http://example.com'
  $ export MAIL_URL='smtp://user:password@mailhost:port/'

Use the PORT environment variable to set the port where the
application will listen. The default is 80, but that will require
root on most systems.

[kaihendry]

Ok, I think there is some https redirect that was messing with me https://media.dev.unee-t.com/2019-03-05/https.mp4

I still think user perms in a Docker image is just a time wasting exercise. :P

[Ulexus]

You probably have the plugin which forces a TLS connection (I can't remember the name). That is normally dormant when you are in development mode, but since you are running in production mode, it will have been in force. Of course, it can't work, since you don't have any TLS assets (I presume), but it doesn't know any better.

[kaihendry]

My colleague removed force-ssl and now it works! :champagne:

The meteor build stage takes a long time. I was wondering already if things can be optimised to keep development iterations sane.

Normally I would develop with npm run start etc, but still things need to deployed on staging and the quicker the build and deploy is, the better my existence on this rock orbiting the sun. ;)

[Ulexus]

I don't know of anything to do to speed it up yet, but I agree that it takes an unpleasantly long time to build. It is also curiously variable. Sometimes it takes as little as 7 minutes on my CI; other times it takes twice that.

[kaihendry]

Tried building using AWS CodeBuild and I am getting the error below with https://github.com/unee-t/frontend/pull/725

Step 9/18 : COPY --chown=node:node . .
 ---> e1e59f6eec66
Step 10/18 : RUN meteor npm install --production
 ---> Running in 33c788ccb4e4
 > bcrypt@1.0.3 install /src/node_modules/bcrypt
> node-pre-gyp install --fallback-to-build
 [bcrypt] Success: "/src/node_modules/bcrypt/lib/binding/bcrypt_lib.node" is installed via remote
added 299 packages from 296 contributors and audited 2352 packages in 14.026s
found 55 vulnerabilities (22 low, 29 moderate, 4 high)
 run `npm audit fix` to fix them, or `npm audit` for details
Removing intermediate container 33c788ccb4e4
 ---> df6d9743d605
Step 11/18 : RUN meteor build --directory /bundle
 ---> Running in 640c8241ac38
·[91mErrors prevented bundling:
While processing files with nathantreid:css-modules (for target web.browser):
packages/modules-runtime.js:231:12: Cannot find module 'postcss-easy-import'
at makeMissingError (packages/modules-runtime.js:231:12)
at require (packages/modules-runtime.js:241:19)
at R.forEach.pluginEntry (packages/mss/postcss-plugins.js:70:46)
at forEach
(/home/node/.meteor/packages/nathantreid_css-modules/.3.1.4.sredt2.213y++os+web.browser+web.cordova/plugin.mss.os/npm/node_modules/meteor/mss/node_modules/ramda/dist/ramda.js:1874:13)
at
/home/node/.meteor/packages/nathantreid_css-modules/.3.1.4.sredt2.213y++os+web.browser+web.cordova/plugin.mss.os/npm/node_modules/meteor/mss/node_modules/ramda/dist/ramda.js:390:80
at Object.f2
(/home/node/.meteor/packages/nathantreid_css-modules/.3.1.4.sredt2.213y++os+web.browser+web.cordova/plugin.mss.os/npm/node_modules/meteor/mss/node_modules/ramda/dist/ramda.js:434:22)
at loadPlugins (packages/mss/postcss-plugins.js:68:5)
at new CssModulesProcessor (packages/mss/css-modules-processor.js:28:27)
at CssModulesBuildPlugin.processFilesForTarget
(packages/mss/css-modules-build-plugin.js:77:32)
 While processing files with nathantreid:css-modules (for target
web.browser.legacy):
packages/modules-runtime.js:231:12: Cannot find module 'postcss-easy-import'
at makeMissingError (packages/modules-runtime.js:231:12)
at require (packages/modules-runtime.js:241:19)
at R.forEach.pluginEntry (packages/mss/postcss-plugins.js:70:46)
at forEach
(/home/node/.meteor/packages/nathantreid_css-modules/.3.1.4.sredt2.213y++os+web.browser+web.cordova/plugin.mss.os/npm/node_modules/meteor/mss/node_modules/ramda/dist/ramda.js:1874:13)
at
/home/node/.meteor/packages/nathantreid_css-modules/.3.1.4.sredt2.213y++os+web.browser+web.cordova/plugin.mss.os/npm/node_modules/meteor/mss/node_modules/ramda/dist/ramda.js:390:80
at Object.f2
(/home/node/.meteor/packages/nathantreid_css-modules/.3.1.4.sredt2.213y++os+web.browser+web.cordova/plugin.mss.os/npm/node_modules/meteor/mss/node_modules/ramda/dist/ramda.js:434:22)
at loadPlugins (packages/mss/postcss-plugins.js:68:5)
at new CssModulesProcessor (packages/mss/css-modules-processor.js:28:27)
at CssModulesBuildPlugin.processFilesForTarget
(packages/mss/css-modules-build-plugin.js:77:32)
 ·[0mThe command '/bin/sh -c meteor build --directory /bundle' returned a non-zero code: 1

https://media.dev.unee-t.com/2019-03-07/cloudbuild.mp4

Build is fine on my local machine. Any ideas?

[Ulexus]

Sorry, no. What vagaries may be hidden inside AWS's CodeBuild would require actual work to comprehend, and I avoid that wherever possible.

[kaihendry]

meteor build --directory /bundle appears to build a Web browser. Why is that? https://media.dev.unee-t.com/2019-03-08/building-a-browser.mp4

Try build git@github.com:unee-t/frontend.git for yourself. Am I living in the future?

[Ulexus]

The verbiage is a bit misleading. When it says it is building a "web browser," it means it is building the Meteor application for the web browser. There are three components: server, browser, and mobile. The output for both the server and the browser is required for the server, since the browser obtains the code from the server.

[kaihendry]

Btw why is npm install run twice?

1. RUN meteor npm install --production
2. RUN cd /bundle/bundle/programs/server && npm install

[kaihendry]

I've been studying other similar Dockerfiles, and I'm puzzled where npm t testing comes into the CI flow. Or shouldn't it happen in the Dockerfile build process?

[Ulexus]

I don't follow. This package is for building the final container image. Any testing can be done presequent or subsequent to it, either on the source (presequent) or the image (subsequent). The particulars of testing to CI flow are out of scope.

If there is something I can do to make thing easier for that, I'm willing to make changes, but the testing itself is something I am considering to be out of scope.