In my previous post, I detailed my struggles with bare-metal setups of applications and how Docker saved me from the pain of installing and configuring PHP. In this post, I shall outline the process through which I (finally) started clustering.

I assume that you already have knowledge on and some experience with Docker and docker-compose. If you don’t, I’d suggest referring to my previous post which should give you some context.

Identity crisis and more Phpain

Even though docker-compose was great, there was still one problem.

Docker-compose runs all the services defined on a single machine.

There’s no point to the cluster I built if everything ends up running on a single machine is there?

Besides the identity crisis my cluster faced, the WordPress site deployed with docker-compose was also going down occasionally for no apparent reason. When that happened, I had to manually SSH into the cluster and run docker-compose up -d again to restart the stack.

For a service to be reliably self-hosted, I needed a way to ensure that my WordPress site does not go down in the event that php runs out of memory. This forced me to start looking into the concept of high-availability.

High availability_ (HA) is a characteristic of a system which aims to ensure an agreed level of operational performance, usually uptime, for a higher than normal period._

A quick google search on docker high-availability yielded my first foray into true cluster management and container orchestration: Docker Swarm

Hello Docker Swarm!

Docker Swarm — A Swarm of (Docker) Mobys carrying stacks of containers shipping services. Brilliant.

Docker Swarm is a framework embedded within Docker Engine that allows you to create and manage stacks, each stack comprising of multiple services, each service run on arbitrary node(s), in a cluster of swarm nodes.

In Docker Swarm, a swarm consists of a cluster of machines, each can hold the role of either a manager or a worker but not both. Much like a typical organization, managers are responsible for receiving instructions from the administrator and subsequently making decisions on where to run a container, workers receive instructions from managers and run containers.

The most minimalistic cluster may consist of just 1 manager node. This is because manager nodes are configured to not just run manager-specific, system-critical containers but also worker-destined containers by default, hence doubling as a worker node. In practice though, running worker-destined containers on manager nodes is not advisable given that the _liveness _of the manager node is critical to the sustenance of the swarm.

#wordpress #docker #docker-swarm #raspberry-pi #clustering