Added Docker section within Deployment and Monitoring

[rhyslbw]

I wanted to contribute the outcome of a few hours of research into the current state of available base Docker images for Meteor. While MeteorD has been the most popular due to it's importance to MUP users, it's got a bug right now and is still installing the insecure node 4.4.7 despite open PRs ready to merge.

@jshimko suggested his image

I use and maintain it regularly and I'm always open to contributions

meteor-tupperware is no longer actively supported by @chriswessels, however I feel there's still value in providing a link so that a fork could establish since this solution did have a nice bootstrapping script and provided inspiration for slimming the original MeteorD image down.

cc @mnmtanish (kadirahq)

[lorensr]

Apologies we missed getting to this earlier! Is the list still current? cc @jkrup

[jshimko]

@lorensr At the very least, I can speak for my Docker base image...

https://github.com/jshimko/meteor-launchpad

I'm heavily invested in Meteor and I have been since around v0.6, so I use that base image every day and can definitely say it isn't going anywhere any time soon. I regularly update/maintain it, so certainly feel free to recommend it in the guide.

[jkrup]

I can do a bit more research but when I looked into about 2 months ago I concluded it's not a great idea to have a Dockerfile completely convert the meteor directory to a docker image. meteor build --architecture=os.linux.x86_64 will be available on whatever machines you are developing on so I tend to opt to: meteor build then cd into that built directory. Then use a fairly straightforward nodejs Dockerimage: (for the latest version of meteorJS)

FROM node:boron
# any dependencies go here:
# ex. RUN apt-get install imagemagick
ENV NPM_CONFIG_LOGLEVEL warn
COPY . .
RUN tar -xzf BUILTAPP.tar.gz
WORKDIR bundle/programs/server
RUN npm install
WORKDIR ../../
EXPOSE 3000
CMD ["node", "main.js"]

Also, if you want to bundle mongoDB with your docker image (not recommended for production, especially unless you're going to mount the mongo volume, but useful for not needing a specified MONGO_URL=.

FROM node:boron

RUN apt-get update
RUN apt-get install -y mongodb
RUN apt-get install -y supervisor
# add any addtl. dependencies here...

VOLUME ["/data/db"]

ENV NPM_CONFIG_LOGLEVEL warn
COPY . /usr/src/app/
WORKDIR /usr/src/app
RUN tar -xzf BUILTAPP.tar.gz
WORKDIR bundle/programs/server
RUN npm install
WORKDIR ../../

COPY supervisord.conf /etc/supervisor/supervisord.conf

EXPOSE 3000
CMD ["supervisord"]

[jkrup]

But, actually if someone does want a docker image to run the meteor build step: https://github.com/jshimko/meteor-launchpad looks completely up to date and 👍 👍

[jshimko]

@jkrup I definitely considered that early on, but how would that work in a CI environment then? Or across operating systems for different users? No matter how you build your app, Meteor has to get installed (at least temporarily) to be able to do the build. That's fine if you're manually building in your local dev environment where you already have everything you need, but if you have a production CI setup, you now need to install Meteor there to do the build. That's also fine, but that means you're still dealing with those dependencies somewhere and now your local build is different than your production build. That often gets tricky quickly and that's why I prefer the entire process to be able to happen inside the container in a consistent environment. That allows you to do a git clone ... and docker build ... and not need any other dependencies installed on the machine doing the build.

My image installs the specific version of Meteor used in your app, builds the bundle, and then removes Meteor and all of the unused app source files. Once it's done, you have a lean Debian container that essentially only has Node and your app bundle on it. So it's the outcome you mentioned, but without having to do it manually outside the container.

That also guarantees your app builds in the same environment with the same dependencies every time. When you're trying automate things in production, that is extremely useful/important. So I can absolutely see the speed advantages of manually building the bundle outside of the container and popping it in there, but that means every build environment (Mac, Windows, Linux) has its own list of dependencies it needs to satisfy to do the job.

Anyway, I'd be happy to discuss creating a pre-built bundle version of my image over on my repo. Feel free to open an issue to start the conversation.

[lorensr]

Thanks a lot! 😊

[rhyslbw]

Thanks for merging this @lorensr