Makes sense, though if I were you, I would keep that as a separate module. I think it is good for the users to see what happens in these scripts, separately. They can then be called together from another script, or simply called manually in the CLI, in succession.
What we tend to do, as we have quite a beast on our hands (Nginx, Meteor + Mongo, Postgres, clustered Java services on Tomcat, plus more), is to separate the batch scripts into modules, then we have a routine that calls all (or only some), depending on the setup input from the user.
It won’t be too hard to write a simplified version of that, for Meteor + Mongo, Tengine (and potentially SSL and basic server hardening). It’s just that time is the most expensive currency we are dealing with, right now…
P.S. Ever since we started using pm2 for running the Meteor process, more or less because of an older post by you, I never looked back. But since we deploy with bash scripts over SSH, not sure how I can use pm2’s backup capabilities - hence me saying I don’t trust it for this sort of operation.
It fascinates me how almost everyone seems to be unaware of phusion passenger which is a feature-rich process manager integrated into nginx, with support of automatic scaling, sticky sessions, ssl, websocets and the whole nine yards.
It is a breeze to set it up and integrate into any workflow. It supports docker as well- if that’s your thing.
Provides nice visibility into app instances and their loads, resource consumption etc.
One of the largest commercial meteor deployments, Classcraft had been using it - before switching over to galaxy for their inherently better rolling deployment support. They used to serve [tens of] thousands of simultaneous connections with it.
I’ve seen it handle ~1000 simultaneous connections (online K12 testing app for students) consistently for about an hour - the duration of the test - on a 4GB digital ocean machine, without even breaking sweat, at the same time running a management app instance (connected teacers and faculty) and a static web site.
Oh yeah, it can serve multiple apps, multiple types of apps (node, meteor, ruby, php, static…) at the same time and scale them all independently.
Thanks @serkandurusoy seems like it implements some of the basic things out of the box, sticky session, maybe load balancing. Can you comment on the advantage of using Phusion Passenger vs. straight nginx with the needed modules (in our case we use tengine, an nginx fork, with sticky session, round robin load balancing).
The main difference is passenger’s not a web server. It employs nginx with some add-on modules of its own for listening for http(s) but the main benefit goes on behind the scenes where app instances get fully managed.
As I said, it can host one or more of any one or more of a
node app
meteor app
ruby/rails app
php app
static web site
start, scale, cap, warm up, stop, crash-recover them independently, fully utilizing the server resources you have at hand. This increases server density, repurposes your idle computing power from idle apps.
This should inherently be a much better form of scaling compared to round robin.
And besides, this is a product which has optional commercial support with even more advanced features (tbh I never needed them)
