This is much more powerful than forever. It is a higher level tool. Forever is just here to make your script start again after a crash. This looks like a complete production deployment tool.
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.
One of the things I love about the node community is the way it embraces the philosophy of Unix. To that end, I'll be interested to see how much adoption this gets - certainly looks useful, but it's doing a lot of things.
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 would not call it "embracing" at all. Node community suffers from NIH syndrome and tries to reinvent everything in JavaScript.
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.
> 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.
Awesome tool. This is something I was struggling with node.. I had so many processes starting with "node /...." that it was a real pain to track what was doing what, which one to restart, which ones are zombies, etc etc. I won't lie, this is actually one of the reason I was still hacking the backend with python/django.. the virtualenv, gunicorn and supervisor just made it awesome. I'll definitely give PM2 a try though.
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?
I use supervisor with all of my node.js deployments... It seems straightforward for me just to drop a new .conf script in, it's agnostic to what code it's starting/monitoring (I use it with ruby as well) so I'm confused as to what problems have you had using it with node?
That said, this looks pretty cool, I'm going to try it out.
I simply look into /proc and see which log files are held open by the process. I automated it with a couple of sed/awk scripts, so I can restart whichever node process I want.
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.
Kind of off topic, but I didn't get what your company was doing. How does it fit in the ecosystem? Are you a replacement for tools like Chef and Puppet? To give you a little bit of background, I recently set up my Linode VPS from scratch, complete with upstart processes, a custom CI server, node staging and production environments, python and virtualenv, mongodb with daily backups via dropbox. Didn't find it too difficult even though I knew nothing before. I'm sure I made some mistakes and my infrastructure is far from flawless or scalable, but it seemed like I should be in your target market and I wasn't able to understand what you were doing after reading your website thrice.
We haven't done a great job at updating the main site; we have a whole bunch of changes that will be pushed in the next week that should make things much clearer.
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.
This is seriously promising. When i first read the description at Github i was like "AHA, this is it.". The only thing holding me from using PM2 is the Coffeescript support. If you put CS support in this than it's a clear winner over forever.
Seriously. Why show a feature comparison chart that looks all amazing and then just leave off one thing... CoffeeScript? There isn't even discussion about why that is missing. Is there some bias by the OP for it?
I can't talk for my colleague Alex, but we tend not to work with CS very much. I'm not gonna open the troll gates on that one, we've heard the arguments from both sides enough already. We tend to prefer writing stuff in regular JS and I think Alex thought it was worth mentioning we didn't support CS.
This looks great! The monitor feature looks interesting. We used node-usage for a while but it seemed to eat up a lot of memory. Maybe I could take a another look into it.
This is great. I just submitted a pull request to node-usage to add OSX support, so hopefully we'll be able to run PM2 in both production and local development soon.
You're welcome. We're launching (publicly) soon and are in the process of releasing a half a dozen such projects, from AngularJS dashboarding tools to full-fledged node.js frameworks. Stay tuned :)
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.