Phusion Passenger 4.0 beta 1 is here
blog.phusion.nl
blog.phusion.nl
I have a handful of pet Ruby projects in the pipeline which won't make money, and I'd like to run them on a VPS using the Passenger Enterprise mass deployment feature with rolling restarts. At $249/year, I'm not too keen. But at $99/year I'd go for it.
As things stand, Ruby hackers can either host their pet projects on Heroku or come up with a DIY solution to manage virtual hosts and graceful restarts on a VPS.
In my opinion, the convenience of mass deployment and rolling restarts is worth $99 for projects that do not make money, but it becomes a questionable annual expense at $249. From the upvotes on my initial comment, I think that others in my position may feel the same. And it seems like a good way to encourage people who build things for fun to look to Passenger Enterprise for their bigger, paid projects too.
We're looking at Node.JS, Python, Haskell, Mono(C#), PHP. Do any of these tickle your fancy or is there one missing?
I use Passenger for my Ruby projects, but use nginx with gunicorn for Python - no reason behind that choice whatsoever except that is the stack that I found nice blog articles on how to get working with gevent
Any big reasons to use it over said config?
I can only wonder what the phusion guys are thinking. Either way, stick with unicorn.
We also implement rolling restarts more conveniently than Unicorn:
* There are multiple ways to implement rolling restarts in Unicorn. One of them is by sending SIGUSR2. This makes Unicorn fork off a new master with the same number of workers. However this requires twice the memory usage during a restart.
* There are ways to script Unicorn to make it restart process-by-process, but this requires some effort.
* Phusion Passenger Enterprise implements rolling restarts with a single config option (PassengerRollingRestarts on), and it performs process-by-process restarting so that you don't need twice the memory usage. It automates everything for you.
* The "deployment error resistance" feature, which can be used in combination with rolling restarting, ensures that in case your new app version doesn't start, it keeps the old processes around until an administrator manually tells it to restart again.
There are many other features in Phusion Passenger Enterprise which Unicorn does not implement (e.g. live IRB console), or that we implement better. Take a look, you may like it.
We are flattered that you like Unicorn. Being Unicorn contributors ourselves, it's always good to see people contend with technology that we've contributed to. :) Phusion Passenger 4 is the combination of all the experience that we've built up in the past few years, in both Phusion Passenger and Unicorn.
I just wanted to point out that your free product lacks a critical, basic feature. Many passenger-users don't seem to be aware that they are serving HTTP 502/503 error pages to their users during every deploy unless they pay $10 per server and month for your convenience.
It is not a secret which features are and aren't available in Enterprise. The documentation and the website are very clear on this.
For the longest time (until 2 months ago) your documentation and website were not clear about it at all. It was simply not mentioned because passenger didn't support it.
Since you take every opportunity here to inject your marketing hyperbole I'll provide my counterweight: In my experience passenger is far from the "very best" in any regard. Admittedly the last version I have used was 3.0.11.
The build-system used to be a trainwreck, plain and simple. At runtime I've run into more than one failure mode where passenger would get stuck silently, not providing any error message (not quite acceptable for a commercial product). These were usually related to the Spawner getting stuck or file/permission issues. I also once had a deployment where merely running 'passenger-status' would inexplicably hang the running passenger! (I did not set that one up and never figured out the root-cause, we just migrated it to unicorn).
In general, when people sit down and write training-wheels[1] for your product, then you might want to strike a tad more humble tone in a hacker-forum.
That's because Phusion Passenger Enterprise and the rolling restart feature were only released 2 months ago. You can't exactly document something that doesn't exist yet, can you? However we've already mentioned as early as last year on the mailing list that there will be a commercial version and that rolling restarts will only be available in there.
"The build-system used to be a trainwreck, plain and simple."
I do not know what you mean by trainwreck here. Our build system is a simple Rakefile with building rules that invoke the compiler, plus an installer script that invokes Rake. Our build system goes through great pains to autodetect as many things as possible, to avoid burdening the user. It even goes as far as detecting bugs in the system and working around them. You can read some of the source code here:
https://github.com/FooBarWidget/passenger/blob/master/lib/ph...
https://github.com/FooBarWidget/passenger/tree/master/lib/ph...
As far as I know we are the only piece of software in our category trying so hard. But if you are having problems with compilation, we would be happy to help you.
"At runtime I've run into more than one failure mode where passenger would get stuck silently, not providing any error message (not quite acceptable for a commercial product)."
Alright, here are the facts. Errors are always logged to the web server error log. There are a limited number of known cases in which that does not happen, or does not seem to happen:
1. The user is looking in the wrong file. As strange as this might seem, it actually happens. A classical example involves declaring the Nginx 'error_log' directive inside the 'http' block. This makes Nginx open a log file, and all the Nginx error logging functions write to that file, but it does not redirect stderr to that log file. Since Phusion Passenger usually writes error messages to stderr, the error message does not appear in that file, and the user is confused. The solution is to move the 'error_log' directive outside the 'http' block and into the global context.
2. Sometimes the error is written to stdout. Thanks to weird environment issues on some systems (some OS X versions, I'm looking at you), stdout is sometimes redirected to /dev/null so you don't see the error at all.
In Phusion Passenger 4 we've taken more extreme measures to ensure that errors always get logged. For example we forcefully redirect stdout to stderr. If all else fails, we provide a config option with which you can tell Phusion Passenger to redirect its stdout and stderr to a file.
If you still encounter cases in which no error is shown, then we consider this a bug and we could be happy to work with you to solve this problem.
"These were usually related to the Spawner getting stuck or file/permission issues."
So here are the facts again.
Phusion Passenger 3 and earlier assume that the app behaves correctly during startup and shutdown. That's why it did not enforce any timeouts on these operations. We have documented this extensively in our blog post "The right way to deal with frozen processes on Unix": http://blog.phusion.nl/2012/09/21/the-right-way-to-deal-with...
However, starting from Phusion Passenger 4, we've much improved in this area. Application processes now have a 1 minute limit to start. Otherwise, they are killed with SIGKILL. Similarly, when you shut down the web server, the Watchdog now kills all application processes with SIGKILL after a short timeout, to ensure that no garbage processes stay behind.
If you still find the spawner getting stuck in Phusion Passenger 4, then we consider this to be a bug and we would be happy to help you get to the bottom of this. I do not know what you mean by file or permission issues, but again, we would be happy to help you.
"I also once had a deployment where merely running 'passenger-status' would inexplicably hang the running passenger!"
There was in issue in the 2.0 series where passenger-status could corrupt internal data structures because a mutex was not being properly locked, but this has been solved later in the 2.0 series. If this was not your issue, then we would be happy to help.
"In general, when people sit down and write training-wheels[1] for your product, then you might want to strike a tad more humble tone in a hacker-forum."
The training wheels you mention predate Phusion Passenger Enterprise. Similar training wheels exist for other app servers. However the existence of these training wheels are not an indication of quality. Remember the Mongrel days and that people had to monitor them using monit? This was not because of a flaw in Mongrel itself, it was the apps and the libraries that caused crashes, memory leaks, etc. Mongrel lacked protection against these kind of things, and as a result got blamed for a lot of problems, but Mongrel was certainly not the cause of these problems.
Similarly, Phusion Passenger only offered limited protection against externally-caused problems. However with Phusion Passenger 4 and Phusion Passenger Enterprise, we are moving more and more towards supervising every single aspect of the system and making sure that things work even in the event of external problems.
We do not, and have never, claimed that our products were without flaws. However we are committed to fixing any flaws with continuing to add awesome features. And by charging money we are in a much stronger position to commit to this.
Node.js and python support will be nice.
I didn't find it too difficult to setup uWSGI, but I can see how it can suck if you have too many apps, or apps of different types.
I didn't have to configure Emperor mode on my new Ubuntu machine - it has a directory where configs are stored. I remember 8 or 10 months ago, you had to configure emperor mode and set the "vassals" directory, not anymore I guess.