I'm gradually getting serious about switching to Docker to deploy lemp webapps. I've chased the topic of best practices around the web for a while and landed on information like http://phusion.github.io/baseimage-docker/ docker/compose#928 and https://groups.google.com/forum/#!topic/docker-user/gk-oSwgxyo4
I basically maintain "two" roughly mirrored environments: one webdevs are working against in vagrant and one in the cloud (qa, staging, prod). The webdev's typically work on 2-5 sites at a time depending on the SLA and new client volume. I began using fig and am about to migrate to docker-compose. If I store everything in a client specific fig file, it tends to rapidly consume the memory of the vm. This makes it complicated for the webdev to switch between client webapps. I've seen this more readily when dealing with the database containers.
In my mind, the answer to the memory problem is to have one db container that can run databases for multiple clients. Are there other approaches that I should consider? Do I manually orchestrate the provisioning of the "master" db container and then use the equivalent of fig.yml to link based on an assumption that the db container already exists? I couldn't readily discover how to accomplish this as fig seems to provision everything in a prefixed context. I feel like I'm missing something.
The second strategy I'm trying to wrap my head around is related to specifics of the phpfpm container and the webapp itself. Typically, these webapps will have something like composer in place for dependency management. I think it makes sense to build the phpfpm container and run the composer install so that composer is not invoked at deployment. I get confused when it comes to how many webapps should share that container vs launching the containers in a client specific context ala something like fig. Do I expose the same type of resource issues as the db if I try to do this on a per webapp basis? Is there a way to associate what is defined in fig with a more "global" container like phpfpm or mysql in these examples?
The third question relates to the versions of these webapps. I'll use Drupal and Wordpress as examples. In both of those "frameworks" there is an untouched core structure that needs to share a single directory with the host for customizations. Does it make sense to create containers for each version of these webapps that can be reused so that I can focus on a repository for the developers that closely represents that single shared directory. Our strategy to date has been to have the repository represent the entire webapp as well as the customizations, usually invoking some type of a build process for dependencies.
Any help clearing my confusion, or helping me understand how to ask the correct questions is greatly appreciated.