This blog post is the last part of a series of three tutorials dedicated to Rancher High-Availability.
We previously installed Rancher single-node using a external databases:
This time we will go full HA by installing Rancher on three servers.
This blog post is the second part of a series of three tutorials dedicated to Rancher High-Availability. We previously installed a replicated Master-Master MySQL database. This time we will install a MariaDB Galera Cluster on three servers.
The trick is that we are going to use a first Rancher to install the database cluster for a second Rancher server (used in production). In the end we will have one Rancher server that manages its own database cluster!
This tutorial explains:
This blog post is the first part of a series of three tutorials dedicated to Rancher High-Availability. And the first step towards HA is to have a fault tolerant database.
By default Rancher comes with an embedded HSQLDB database. It's fine for testing purpose but not suited to a production environment.
So this tutorial explains:
We have been listening to all your nice feedbacks this last year and decided it was time to implement a new cloud provider in our platform. That's why we are excited to announce that OctoPerf now supports Digital Ocean.
Running large tests from AWS is quite easy and their platform is very powerful but:
In these cases, it is important to be able to run load from an external location so that the tests remain realistic.
Like Martin Fowler said in TwoHardThings:
There are only two hard things in Computer Science: cache invalidation and naming things.
I've just seen too many times developers using Dependency Injection frameworks like Spring or Guice or Dagger the wrong way. Naming classes with Impl suffix is an Anti-pattern and i'm going to explain why.
Many developers, including myself years ago, are using the Interface + Impl pattern to create services which are injected by their interface. This usually looks like this:
