haha, I really like the name of that project. Never thought of an antonym to it.
I think making a PHP-FPM plugin would be the very hardest plugin you could do. For that to work, each webserver container would also have to be aware of those PHP-FPM containers, so there needs to be a more general concept for them as well to allow for different upstream locations on demand. Mount points must match, user/group id inside container must match, etc. Hard, but not impossible. I guess before actually tackling this one, you should have a very clearly defined protocol that must be implemented by both: web-server and php-fpm. With that protocol being defined, one could also replace the php-fpm with python or anything else.
A more simple approach for a plugin system be a web-server independent container: DB, Cache, monitoring, etc. Even for that, there must be first a protocol defined, so that the intranet page is able to properly present this container. (At least for the plugin system).
I do like the approach for separation, but only in combination with extra value for the project, e.g. the plugin system. This one now really caught my attention, unfortunately I try not to explore this yet, as I first need to get rid of a few more painspots, before adding more features:
- Everything as Volumes (except the projects) to satisfy Windows
- Rebuilt AutoDNS to satisfy DockerToolbox and MacOS (and get rid of all socat port-forwards in PHP-FPM container)
- Docker-sync integration to satisfy MacOS performance (drastically)
Time-wise all three could be achievable in Q1 with ordered difficulty of: 1, 3, 2
Once this is done, I guess (and hope) all pain points are resolved and I can actually go on with major features which is most likely going to be the plugin system with logical separation of container definition.
We should keep this idea active nevertheless and see what else pops out of our heads regarding this.
I am eager to see progress on the Angelbox especially in terms of separating configuration.