WordPress is a popular platform for editing and publishing content for the web. In this tutorial, I’m going to walk you through how to build out a highly available (HA) WordPress deployment using Kubernetes. Read more
In the third section on data resiliency, we delve into various ways that data can be managed on Rancher (you can catch up on Part 1 and Part 2 here).
We left off last time after setting up loadbalancers, health checks and multi-container applications for our WordPress setup. Our containers spin up and down in response to health checks, and we are able to run the same code that works on our desktops in production.
Rancher Multi-container WordPress
All of this is nicely defined in a docker-compose.yml file along with the rancher-compose.yml companion that extends compose’s functionality on the Rancher cluster. The only issue is that when we terminated the MySQL container all of the data was lost. Read more
With the release of Rancher v1.0.1, setting up and running a highly-available Rancher cluster just got a whole lot easier.
Prior to this release, users were required to create and manage their own Zookeeper Ensemble, Redis Cluster, external relational database, Rancher servers and external load balancer. Monitoring of these components was a wholly manual process or required extra middleware and ramp-up time. Configuring Rancher servers to communicate with these components was another hurdle, and left more room for error and frustration.
Rancher now orchestrates and manages its own Zookeeper and Redis cluster on Docker all on its own! The simplified process is only a few steps:
Figure 1: The new, simplified Rancher HA deployment topology
Install an external database
Startup a rancher server and generate an HA deployment script
Run the deployment script on each host and configure your load balancer
Recovering from a node failure is dead simple: either repair or replace your node, delete old containers if present, and re-run the deployment script. The new node registers to the System HA environment. Zookeeper, Redis and all other internal components automatically repair themselves. If a new node is created, adjust your load balancer accordingly.
Rancher exhibits the characteristics of an active-passive HA deployment, so the number of host failures that may be tolerated is computed as `ceil(N / 2) – 1`, where N is the number of Rancher nodes. In simpler terms, a 3-node deployment survives 1 host failure, a 5-node deployment survives 2 host failures, and so on.
The latest HA iteration brings automatic Zookeeper and Redis configuration management, but why stop there? Rancher could handle its own distributed database, further reducing manual deployment and management efforts. Rancher could even manage itself. Try Rancher HA out today – we want to hear your opinions on the Rancher forums.
If you’re interested in finding out more about Rancher, please download the software from github, and visit our forums to view topics and ask questions. To learn more about using Rancher, please join our next online meetup.