Generally it's best to have one role (some would say one process but that isn't always pragmatic) per container. This approach advocates having multiple roles within the same container (e.g. app, db).
I can appreciate the benefits of the underlying phusion-baseimage for addressing some common pitfalls and hurdles, but this layer on top takes things too far in my opinion. Ok, you have the option to customise it, but that comes across as an optional extra rather than an advised approach.
This is false. This image does NOT advocate multiple roles in the same container. Passenger-docker does NOT come with a database.
It provides the option to have memcached and Redis inside the container, but it is optional and not installed by default. You have to explicitly enable them.
Passenger-docker only handles a single role: the app. Depending on your viewpoint, caching may or may not be considered to be a logical part of the app. This is why we provide the option. But again, disabled by default because we go for lightweight by default.
I didn't say that it came with a database, I said that it advocates multiple roles per container - skim down the list of what's included and you see multiple languages, web server, app server, aux services and tools. First impressions are that this image is one-size-fits-all (Whilst I can perceive a distinction myself, I can understand why others in this thread have taken this to be an attempt at emulating a VM).
I take your point that there may be situations where it's pragmatic to have memcached/Redis in the same container as your app, and that they are disabled by default, but I still feel the balance of the README is wrong as it doesn't sound any kind of warning that you probably don't want to do that in most cases.
I'd suggest the README could be improved to better communicate the intended use cases of the images.
But they're not all included in the same image. We have 8 variants, 6 of which only contain a single language. There is 1 which contains everything, and there's 1 which contains nothing and is meant for customization.
> web server, app server
The web server and the app server are the same thing. Passenger is an Nginx module.
> aux services and tools.
Only the minimum possible to allow regular administration, inspection and debugging.
> First impressions are that this image is one-size-fits-all
But it is not. That's why we have 8 variants. Early in development we've explicitly made this a many-sizes-fit-all thing.
> and that they are disabled by default, but I still feel the balance of the README is wrong as it doesn't sound any kind of warning that you probably don't want to do that in most cases.
Fair enough, though I disagree. I'd rather assume the user knows what he's doing. If he chose to enable Redis then there's probably a good reason for that.
I realise all this now. So do you - more so than most people as you're intimately familiar with the image.
I'm explaining the impression that it gives, rightly or wrongly, to those not as intimately familiar with it as you; those less familiar with Docker who may read through the README and come away thinking that it's ok to mix roles without appreciating the unwritten use cases you actually had in mind; those newer to Docker who have a Node app and a Ruby app and think "hey, this passenger-full image looks convenient, I'll use that" without appreciating the implications.
> It's even better than that: Redis and Memcached aren't even INSTALLED by default. Thus, no warning is needed. If you don't explicitly choose to use them, you do not pay any price.
Doesn't say that in the README, just says they're disabled. The fact they're not installed doesn't impact on the impression that's given.
I can appreciate the benefits of the underlying phusion-baseimage for addressing some common pitfalls and hurdles, but this layer on top takes things too far in my opinion. Ok, you have the option to customise it, but that comes across as an optional extra rather than an advised approach.