> If you have a health check that checks that php-fpm works, it should need no or minimal adaption to handle the new scenario. The only "new" thing is that the processes have a different parent process than usual and is running in different namespaces. If you didn't care about healthchecks for php-fpm before, there's no reason to care about them now.

opendais-www1 -> fails -> shoot in head, replace.

vidarh-www1 -> fails -> shoot all of the containers in the head, replace.

At this point, its the same atomic unit I originally started with. Now, I have multiple executions to perform that I have to build out. This is the very definition of wasteful added complexity. The high level process is effectively identical but you have to do more things to make it work.

> - Explicit documentation of the dependencies necessary for each components. I know it covers at least what is needed, because otherwise the component will fail; as opposed to documentation which easily becomes obsolete.

My explicit documentation also exists in the form of a Dockerfile and my configuration files. Its a self documenting process.

> - Each container is limited in what it can access, ensuring that interdependencies between the containers are documented and explicit.

How is my container not limited exactly? Because nginx and php-fpm can access the same files? o.O I don't think this is really an argument of any kind beyond the theoretical.

> Versioning of e.g. system packages can evolve separately for each component, without needing separate (heavier) full vms.

You've never seen this go wrong before in production I take it when Person X updates a component that breaks Person Y's application I take it? I have and it is not pretty. This is added complexity to manage.

> For some apps that's not an issue. For others it is, and even starting a second instance of the full stack becomes a huge waste of resources or a huge added complexity vs. starting more of a specific component.

The reason I said "To me, for my use," in the original parent comment is this is for my usage. I don't claim to speak for everyone who might use Docker. I'm sure there are people with different requirements. My requirements involve not building the sort of products you mention in the second group.

> E.g. have fun if one of the components of this container is a Postgres install and all the instances needs a consistent view of the database.

If you are storing state in an application container, it isn't a role-based container. I'm going to assume this is because I said something that was unclear.

Please explain to me how you concluded I stored state in this container:

Load Balancer w/ Builtin HTTP Health Checks <-> Application Containers [nginx+php-fpm]

> The scale I'm talking about is anything from a single, small home server, where you may want to spin up more web servers for experimentation but not need more than a single database server, to large clusters. I use Docker for 100% of my small home projects because it makes life easier and saves me time.

It doesn't save me time and adds complexity. Maybe everyone who is arguing with me is just a better developer than me. Maybe they are just people who have never worked in an environment where every added layer of complexity leads to a higher frequency of breakage because Random Team Member X forgot something.