Once upon a time I sat together with Thomas Lohner from ScaleCommerce and built a demo setup for Lizards and Pumpkins. It was great but most of the work he did, because he was (and most likely is still the docker master of the two of us). It was a great setup: We (and this is always him) built a Dockerfile which created a single container with everything we needed for Lizards: PHP, nginx, Redis, Magento, MySQL. The container ran a Magento based on the demo data and the Lizards plugin which wrote an XML file each time something changed on the products. In the backound either a supervisord worker or a cronjob took care, that the changes of the XML file are rendered and written to the Redis instance. This way each time a change on Magento took place the change immediately was visible on the rendered Lizards frontend as well.
The magic behind all of this was a fancy nginx setup on the host machine which somehow (I can’t remember) knew which subdomain belonged to which docker container and routed the setups through and brought the response back to the visitor.
How stages should be
If you have such a setup it is great, because you only deploy your docker container for your branch and if the branch is merged, you delete the docker container and voilà, done.
What is “such a setup”?
“Such a setup” means, that you have configured and running docker container which have everything you need for your setup, be it one container or multiple.
It means you have a server which runs docker container for you and somehow manages the routing for the URLs on the branched of the different setups – this can be subdomains or paths.
But overall this is – at least from my point of view – a lot to maintain and therefore too big for us, although we have one person who can built all this for us. But: Bus factor anyone?
So instead of taking the risk, having a fancy cool setup, we prefer to have a less fancy setup I’ll tell you about in the next post.