@pierreozoux I agree. I’m glad we found some interesting contributions. My vote is for us to use @abernix fork of meteord as a starting point. Any other ideas?
2 Likes
I’m genuinely sorry to interject, but I do hope you all reach out to the folks working on the “wefork” Wekan project. The developers there are clearly very motivated and they have an open issue to push their Docker image to Docker hub : https://github.com/wefork/wekan/issues/33
Really, it would be great if the broader Meteor community could agree on a common Dockerfile. Such a project might be best housed by the wefork team, as they seem really keen on Docker best practices.
In any case, please take a look at what they’ve built : https://github.com/wefork/wekan/blob/devel/Dockerfile
Looking forward to more Meteor + Docker 
@abernix Now that you are at Meteor, do you have any new input on how to promote a “reference docker image”. Thanks
It’s been mentioned before (in fact, you referenced it yourself in your opening topic on this thread), but the likeliness of a MDG-backed Docker image is low, perhaps zero. The Docker image would not used internally on any internal apps and therefore would be subject to falling out of date quickly.
Additionally, even before I started, I barely used the Docker images I’ve provided already and for my apps there’s just no simple Docker configuration that I could rely on (nor am I sure there would ever be) without focusing too much attention on them when it came to scaling, etc. I prefer a simpler approach.
I guess I’m not sure why you’re not embracing one of the many forks mentioned above as a community? There are many in play and many of them work. Sure they have their various shortcomings, but isn’t that something that the community should work through and iron out?
As far as a community “base” image suggestion, while my meteord fork is fine (and functioning) for those using MUP with Meteor >= 1.4 and my spaceglue version has what I believe to be some valuable changes, I wouldn’t “vote” for either of mine to be used as the base for a community (or even Docker “official”) image – they create extremely, extremely large images. Again, probably good for MUP users though.
Based on what I’ve seen, I’ve liked https://github.com/aedm/minimeteor the most. Maybe it’s no longer important for MUP to be supported, or maybe a new tool could come into existence, I’m not sure.
I have been silent on this thread just watching, now I can’t resist the urge.
Why would a Docker image be useful? Personally, I found Docker to be a lot of maintenance, a black box that is hard to update or monitor. It was cool when it came out (‘Yay! Another layer of virtualization that eats up our memory and CPU’ – sorry for the sarcasm 
).
What may be more useful are build scripts that build your app from scratch from available packages (even hard coding versions if you needed) – including maybe even Mongo.
Case in point: look how hard MUPX is to maintain (it uses Docker).
1 Like
Docker has a very low overhead for the advantages it gives. There’s a reason it has become so popular. Let me give a simple example where I’d find a Docker image very useful, even mandatory.
I’m working on deploying my app to the cloud and automate as much as possible. Currently everything is managed manually using DO droplets and its a lot of work. So I want to setup the whole thing - CI, CD, auto deploy etc.
Docker would make this so much simpler as I wouldn’t have to write and test all kinds of batch files which depend on the environment. I could then use my Docker image and use Kubernetes/ECS etc and let them do all the hard work, instead of manually managing instances, images, scripts etc.
Even if I was doing it on a single host, I’d still prefer Docker, because I want nginx/haproxy, some monitoring stuff etc, all of that is easier to install/configure via docker-compose than manually.
I’m not sure why Docker is hard to maintain. Once it works, it’ll just keep working as there are no external dependencies. I can give the exact same image to my colleagues to have them test in production on their dev machines.
I personally feel this should be done by MDG but obviously that sentiment is not shared
@abernix The issue I have is that the community contributions are very fragmented. My only request is that Meteor officially promote one in the docs. Ideally MDG would contribute to a default image, as you have done.
To answer your question, I have been using many different versions, including yours, and have posted issues to each of github repositories. I think you have done a good job at maintaining your image. But you’ll agree having many eyes on one project, is better than the opposite.
So I’ll rephrase my question, with your new role will you continue contributing to your/any Docker implementation?
1 Like
Hi @dirkgently, after battling for 3 days to get my staging environment working again with meteor up I finally switched to settlin/meteord-portal:latest docker image which includes node 4.7.2 and the deps for canvas (including cairo and pkg-config).
Hey thanks, I will try that out. Are you using mup for deployment, did you write your own scripts?
I’m using MUP latest (1.2.2) and project is on Meteor latest (1.4.2.6) and it deploys to an Ubuntu 16.10 x64 droplet on Digital Ocean.
1 Like
Yay! Another layer of virtualization that eats up our memory and CPU
Docker doesn’t do that though, unlike a virtual machine it doesn’t just set aside a huge chunk of resources. A Docker container shares a lot of its resources with the host so it’s WAY more performant, I can run 15 containers on my machine fine but 3 virtual machines slows it to a crawl.
Why would a Docker image be useful?
One great example is for 100% replicable developer environments. Consider this scenario:
- you’ve got a set up where you’re using the Redis oplog package, that requires a certain version of Redis is installed manually on your machine
- you’ve also got a second Meteor app that just serves up an API and you let your first app handle the UI
- you’ve got to manually run that second app on a different port and connect the two apps
- you’re seeing an issue in production because your prod servers are running Red Hat Enterprise Linux and you can’t replicate the issue on an OSX or windows laptop, you have to install RHEL manually on your machine to debug
All of these are solved with docker, you would just run docker-compose up and have a full dev environment with all dependencies pre-installed, with multiple apps connected to each other automatically on their own internal network, on the exact same operating system that your production servers are running, all from just running one command on your terminal
I found Docker to be a lot of maintenance, a black box that is hard to update or monitor.
On the contrary, each container and image is controlled from a single file and you can see the exact commands that were run in sequence on a brand new operating system to create that image, and you can see exactly what command is being run inside a container that uses that iamge. There is no “black box”, it’s totally transparent as to what created your image or container. It requires no maintenance once it’s created, as it is 100% replicable and will always behave the exact same on every machine in every environment, whether it’s on your local or in AWS. If you do need to update it, it’s as easy as modifying your docker-compose.yml or your Dockerfile. You can have the exact same functioning dev environment as anyone else on your team with only a single command run on your machine, it’s really incredible.
4 Likes
I don’t see a difference between settlin/meteord-portal and abernix/meteord…?
I think its this bit that makes the difference if you require canvas.
@abernix I agree that http://github.com/aedm/minimeteor is a strong candidate. I think it has a good balance of priorities. What would it take to get meteor to include it in the official guide?
@aedm How much work is involved to make package backward compatible with MUP? Or should we not bother?
@sashko You had once offered to set up a continuous integration tests for a docker image the community chose. What would that entail for this image.
Sure I’d be glad to help, is there a consensus? I think the first step is to send a PR to the guide to replace mup.
@aedm How much work is involved to make package backward compatible with MUP? Or should we not bother?
I never tried MUP myself, but I don’t see a reason why it shouldn’t work. I’ll try to allocate some to investigate it in the near future.
@sashko You had once offered to set up a continuous integration tests for a docker image the community chose. What would that entail for this image.
I’ve set up a basic CI test for MiniMeteor. It builds and runs a helloworld-level Meteor project each time a new MiniMeteor commit is made or a new Meteor release is tagged on GitHub. It runs the test against every Meteor release (1.3.3 and up) to make sure nothing is broken. If we come up with a more detailed integration test beyond a helloworld, I believe I could integrate it to this workflow relatively easily.
3 Likes
@sashko @abernix
This thread has been going on for some time, here’s my sense of how each package stacks up:
In short, I think we only have two options for a reference docker. Spaceglue and Minimeteor. Some developers with most experience in this have suggested a aedm/minimeteor approach. And it seems to be among the most tested and maintained. It also successfully builds on Docker Cloud which is a notoriously difficult environment for Meteor to build on. It would just need to work with MUP to be feature complete (but we may want to stop supporting MUP if it’s not being maintained anyways). @arunoda
@sashko How does this work, do we take a vote?
1 Like
I took some time and made a mup-compatible version of MiniMeteor.
Warning: it’s quite experimental at the moment. But if you want to give it a try, update your mup.js file to use the development branch:
docker: {
image: 'aedm/minimeteor:development',
}@aedm, minimeteor looks perfect. I have a simple question - how can I update the dependencies installed? My project uses node canvas and to get it to work I had a to install a bunch of extra stuff.
I suppose its as simple as copying the scripts, and modifying them to add in the ‘apt-get’ lines. Right?
@dirkgently: adding a simple “RUN sudo apt-get ...” to your Dockerfile might do the trick.
I’ll probably add preinstall and postinstall hooks to MiniMeteor sometime to make it easier.