This blog describes steps to migrate Rancher 2.1.x from a single node installation to a high availability installation.
Objective: In this article, we will walk through running a distributed, production-quality database setup managed by Rancher and characterized by stable persistence. We will use Stateful Sets with a Kubernetes cluster in Rancher for the purpose of deploying a stateful distributed Cassandra database. Pre-requisites: We assume that you have a Kubernetes cluster provisioned with a cloud provider. Consult the Rancher resource if you would like to create a K8s cluster in Amazon EC2 using Rancher 2.
In this tutorial Rancher looks at the steps of building out a highly available WordPress deployment using Kubernetes and MySQL. Visit us to learn more.
Note: this is Part 4 in a series on building highly resilient workloads. Parts 1, 2, and 3 are available already online. In Part 4 of this series on running resilient workloads with Docker and Rancher, we take a look at service updates. Generally, service updates are where the risk of downtime is the highest. It doesn’t hurt to have a grasp of how deployments work in Rancher and the options available within.
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.
In Part 1: Rancher Server HA, we looked into setting up Rancher Server in HA mode to secure it against failure. There now exists a degree of engineering in our system on top of which we can iterate. So what now? In this installment, we’ll look towards building better service resiliency with Rancher Health Checks and Load Balancing. Since the Rancher documentation for Health Checks and Load Balancing are extremely detailed, Part 2 will focus on illustrating how they work, so we can become familiar with the nuances of running services in Rancher.
Containers and orchestration frameworks like Rancher will soon allow every organization to have access to efficient cluster management. This brave new world frees operations from managing application configuration and allows development to focus on writing code; containers abstract complex dependency requirements, which enables ops to deploy immutable containerized applications and allows devs a consistent runtime for their code. If the benefits are so clear, then why do companies with existing infrastructure practices not switch?
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.
[Since the availability of Rancher’s Beta release a few weeks ago, I’ve been pretty excited about the new scheduling and service discovery capabilities in the platform. To help people understand the impact of these capabilities, today I’m going to show how to use these features to deploy a fully clustered and HA implementation of a Node.js application. I’m going to use ][Let’s Chat as our example application, It is an excellent ][open-source, Slack-like team chat application.