Goodbye node-forever, Hello PM2
devo.ps
devo.ps
And it seems great.
One of the problems newcomers face when starting with node is the deployment of apps. Currently, if you try to search for "the right way", you will find many different methods ranging from custom scripts, modifying your application in some way, to external tools like upstart and monit. Of course, if you use a PaaS solution like heroku, cloudfoundry or similar, some of this problems go away.
All this deployment possibilities are great, in their own way. Pm2 is not here to replace them. It is here to give you a good production ready solution without much hassle. You want to publish your app? Use pm2. If you are facing a larger project, with many special details, then you might consider a custom solution for deployment.
Personally, I am planning to try this out for various smaller apps that need to be up 'n running, but don't have time to setup proper production environments and maintain all those environments.
Case in point: 'forever' itself is essentially a convenience program built on top of the 'forever-monitor' API (oversimplifying somewhat, but you get my point). And while 'forever' may not use JSON config files, 'forever-monitor' does (I only mention that because of the comparison table in the article... FWIW none of 'forever' is written in coffeescript).
No disrespect to the devo.ps team - good work on releasing PM2!
I love Node, my main products run on it. But I still use other specialized tools outside Node ecosystem to create environment for it. I use init/upstart/whatever is available on the machine to restart the process if it dies. I use stunnel to proxy SSL connections, I use HAProxy for load balancing.
I'm not saying this is a bad thing. Since 0.8 whose main goal has been to run on Windows, it seems that Node has taken a sideway path from Unix philosophy and decided to build everything into it, so that you can run the same thing on different platforms. A good thing is that everything is modular, so you don't have to use all those add-ons if you don't want.
That my friend is the essence of the philosophy of Unix. It has nothing to do with re-implementing things or actual operating systems - do one thing, do it well, and build complexity via composition.
To other node.js users: How do you cope with this problem? I know friends who by-pass all this by using heroku (or similar platform), is that what you do? What about managing multiple node projects on a single linode instance?
At least, that's what I've done before I discovered REPL module. Now I simply log into it on specific TCP port. You just need to keep a list of ports somewhere.
That said, this looks pretty cool, I'm going to try it out.
Why does a process control system needs to be written in the language of the process that it is running?
The core idea of our service is to go a bit further than Puppet and Chef. They're great tools, but that's what they are: tools, with pretty high barriers of entry. We let you describe your infrastructure (and automation) in a much more portable and straightforward way using readable JSON files (not unlike package.json). Want to add CouchDB to your server? Just add one line (`"couchdb": "*",`), we'll make sure this is done according to best practices (properly set up the init script, adding monitoring, following security guidelines...). And if you want to override our defaults, you can do so.
Hope that clarifies it until we get our new landing pages up.
If you just want a cluster manager then i'd recommend https://npmjs.org/package/cluster-manager
This is a very good addition - I'm using forever extensively in production over many services for the last year and a half.
While it's great, it has a few corner cases which looks like you guys also bumped into and solved.
Can't wait to give this a go.
$ pm2 kill // let's simulate a pm2 stop
$ pm2 resurect // All my processes are now up and running
Goddamn I love the FOSS community. Thanks guys!