Thanks. Will have a look at it today. I don’t think mup is as bad as you make out. And I’m slightly wary of using a solution that has been on github for less than a week, but no harm in trying it.
MUP has been in solid production use for years now. It’s only since mid meteor 1.3 that it’s had some real issues.
I’m also waiting for Mup/MupX/Mup2 to become compatible with 1.4. I haven’t had any luck with the various suggested workarounds so far.
I’m hoping a fix is coming soon, but I worry that the Kadira team is (understandably) having a hard time maintaining their huge ecosystem of Meteor plugins…
The initial set up is not as quite easy as mup because it requires you to follow a set of configuration steps, albight extremely easy ones and may take up to an hour for a linux novice and at least 15 minutes for an experienced one. But with the ability of creating reusable server images, that’s something you do once and then redeploy new servers based on that image.
Anyhow, the feature benefits far outweight anything else (and even galaxy for certain usecases due to galaxy being a meteor-only solution).
Yes they have switched over to Galaxy which is a wise move because Galaxy reduces devops time to zero! Especially if you are not tight on budget and your deployment consists of meteor only.
Every solution has its pros and cons. Passenger’s are as I listed. The main disadvantage being not one-click and having to still maintain a server or set of servers that you own. For some companies (like Classcraft) that’s not desirable.
Passenger is free. It does have an enterprise version (tagged at 29$/mo/server) but frankly, I never actually needed it. And if you are using mup, you definitely don’t need it because passenger community edition is already a huge upgrade to mup considering its scalability (unless you are using mup + cluster together but that’s a whole different story) and server density utilization features.
Single most important feature passenger provides is the ability to run an infinite number of meteor apps in a small server because it has the ability to shut down unused ones and start ones that receive requests and then also scale them up if they have more requests than configured. So if you have 20 meteor apps, you don’t need 20 servers, but can easily use a $10 DO server to host all of them.
I don’t see the issue with docker. But I do like the look of your solution
and the pm2 stuff looks awesome.
I think I would have to fully understand all the parts of your deployment
process before using it, whereas with mup I’m happy to rely on the blackbox
solution that works and is tried and tested. Plus any issue I run into will
always be affecting multiple people and the community can find a solution
together.
The only issue I have using docker for Meteor is I have a special case.
I install executable I use to generate PDFs on the EC2 instance, the install is pdftk. Also, while generating the PDF, I use a directory outside of my Meteor application and store PDF templates there. I also write temporary files to the file system outside of the Meteor application. Would this be possible with a Docker container? Could I build a container with a directory structure store PDF templates in a folder structure outside of my Meteor application? It would be ideal to keep this directory and file structure in place and just update the Meteor application within the Docker container; that way I don’t have to build this each time I do a new deployment. Or would it be better to have these folders and files outside of the docker container (keeping in mind this is a dependency)?
I’ve read you can put multiple instances together, I’ve also heard maybe I need to mount volumes, but I’m not sure where to start.
The last time I used Docker on my Mac, it ran a VirtualBox, and a headless Ubuntu (using 2GB RAM) inside that VirtualBox. I remember creating 2 containers, and although Docker did not create another VM for the 2nd container as far as I can tell, it did create a VM with the creation of the first container.
Docker official website says Docker containers share the same kernel with the other containers. It does not say if if is the host kernel or not. From what I can tell, that means if the host OS is not, say, Ubuntu, Docker will create a guest OS. I may be too far off base, since I do not use Docker daily.
After a lot of research, I found out that Docker is similar to KVM in that it uses the host kernel (in Docker’s case, if possible as per my Ubuntu example above).
Long story short, if you are using a supported Linux flavor, you are safe (near-kernel speeds). Otherwise, it will run a Linux distro (Ubuntu I suppose) for you.
We’ve been using this for quite some while now, its an ansible script complete with HAProxy (optional) + nginx-passenger + Mongo deployment: https://github.com/smowden/meteor-ansible
Check out the tests directory for different configurations