In Part 1 I talked about the reasons behind why I believe a Docker based distributed Magento installation makes sense. In this post I continue with how it could work and some of the problems to overcome.

Hosting Provider Images

Getting onto a hosted solution, it is easy to get an Ubuntu or similar distribution up. This does mean for Docker you then need to get additional software installed. I am hoping over the next 6 months images such as CoreOS will become more commonly available. CoreOS for example is a minimum Linux distribution that includes docker and etcd preinstalled. Yes, you can get a Puppet script or similar going to install Docker and supporting tools on top of Ubuntu or similar, but having an image available out of the box just takes that one extra step out of the process, saving resources at the same time.  (CoreOS is stripped back compared to a full installation.)

This is an area I am expecting good progress in however. Hosting providers that make VMs available all typically offer a range of OS images, so it would just be a matter of them adding one with Docker preinstalled. (In my limited experience, I have quite liked CoreOS so far – had all the commands I needed to get serious work done.)

Managing a Distributed Installation

The other week I read an interesting thought piece on the evolution of Docker and its impact on AWS. It highlighted the idea that software to manage a cluster should not be tied to a hosting partner. With Docker and its portability, you really can have a distributed solution across data centers and hosting providers. The management tools don’t have to sit in the same data center as your cluster. This I think is particular interesting because:

• Generic cluster management solutions are likely to emerge. Magento won’t need to solve that problem.
• Having cluster management independent to a data center would simplify the geographic distribution of VMs.

I have also been looking at new emerging tools like Panamax. Initially I was thinking tools like Panamax should support the whole cluster, dynamically balancing and allocating containers across the cluster. But the more I thought about it, defining a VM level template is not such a bad idea. It is simple, you can share images (container definitions) to assemble several different templates, and then you can deploy the same templates to different VMs.

For example, if I set up a Varnish cache intended for a large installation, I would put it on its own host (or VM) and give it all the available memory. I would not put the Varnish cache on the same host as a web server. It helps improve isolation in the case of failures. (A Varnish cache that goes insane cannot take down a web server with it.) It also makes things simpler to understand – I can describe my topology in terms of host types instead of the larger number of container types. I think being able to give things names is really valuable in making complex systems understandable.

Service Discovery

One of my next investigations is going to be into etcd a simple distributed key/value store (similar to Zoo Keeper). It sounds really simple conceptually to use (just HTTP requests) which I like. In particular, etcd can be used to implement service discovery with Docker. Service discovery is where containers are not prewired to other containers, but instead discover them via a service registry as they join and leave the cluster. The benefit of etcd is it handles the distributed synchronization of key/value updates, taking into account various failures that can occur.

What I plan to do is to get each web server and each Varnish instance to add itself to the distributed etcd registry. Interested VMs can then watch as other servers appear and disappear. This means the Varnish container can include a process to watch for new web servers joining the cluster, updating the Varnish configuration to add the new web server (Varnish includes load balancing support). Similarly, web servers can watch for new Varnish servers (in Magento 2, the web server can tell Varnish about entries to knock out of its cache due to some database updates). So web servers know which Varnish servers they need to communicate with.

It also means that if I want to add new monitoring software later to collect metrics, it can watch for both Varnish and web server instances and collect stats about both. No changes are required to the Varnish or web server containers.

Oh, and as a bonus, etcd entries can also have Time to Live (TTL) settings and so disappear automatically if a host goes down. (Containers would generate heart beat updates to refresh the entry while the server is up.)

Conclusions

Docker is getting a lot of noise. I heard one claim “it is the fastest growing open source project today”. I think a lot of people see the potential in the standardization it offers. Docker in many ways is not a radical new approach. In the video in part 1 I think it was expressed well – it has come along at right time. Hosting and cloud is now common and there are greater expectations that systems will scale.

Make applications scalable is not magic. Some applications will scale across multiple machines easier than others. In Magento, the application tier does horizontally scale pretty well – the central choke point is primarily in the database. If NewSQL technologies such as Clustrix get the database scalability up significantly beyond a single machine, that will be a great result. It leaves the responsibility of the really hard distributed technology problems with teams of experts, allowing other developers to focus on their value add. And this is an important point. You don’t want to have to find teams of distributed system experts to build your Magento site. You want to find teams who are experts in e-commerce and Magento and not have to worry (so much) about distributed systems.

Any system will eventually hit some limit. Technologies such as Docker (including supporting technologies such as etcd) and NewSQL are helping make building distributed systems easier without developers having to be distributed system experts. Because thresholds are hit later or avoided by being able to just add more hardware (compared to re-architecting your system complete), this allows developers focus on delivering value for their customers with lower risk and lower effort. I think some exciting times are coming as the Docker and NewSQL communities continue to forge ahead making the construction of more scalable solutions more of the norm rather than the exception.

What next? For me, it’s time to play around with some shell or simple PHP scripts talking to etcd.