Skip to content

DevOps

  • in DevOps
  • 8 min read

Our Motto: Automate everything

You may have recognized the famous indie game Factorio used as the picture for this article. Factorio is best described as:

Factorio is a game in which you build and maintain factories. You will be mining resources, researching technologies, building infrastructure, automating production and fighting enemies.

Basically the goal of this game is to build a fully automated supply chain to produce a rocket to escape an hostile planet where you crashed. We may find similarities in software development. When you are a small team facing huge challenges, you know your time is precious.

At OctoPerf, we strongly believe the more you automate, the more time you can spend on tasks that really need your attention. We try to automate every single thing we can. From building cloud images to deploying a version, from testing the software to checking the code quality. This is how a compact team can have a huge throughput: delegate part of your work to routines executed by a machine.

Saving time is not the only reason to automate workflows: automation also prevents human errors. Try this yourself: make a paper ball and try to throw it in the recycle bin from 2m distance. I'm pretty sure you won't succeed all the time.

In the next coming sections, i'm going to explain the different problems we have faced and how we try to automate as much as possible.

  • in DevOps
  • 4 min read

Test automation with OctoPerf's API

Even though automation is not always the best solution, you can still use some to save time on your day to day chores. And since OctoPerf is a GUI based tool we sometimes get remarks on how "unpractical" or "not devops friendly" this can be. Although I do not agree and still think that even a devops has better things to do than learning another coding language to test his code, I'd like to prove that even a GUI driven tool can be used to automate your testing.

So how does it works

And there's a simple reason for that, our backend is made of REST services. So anything that can be done through the GUI can be achieved with REST calls. That does not necessarily means that the work of our front end engineers is useless (they don't take criticism well so let's skip it) but rather that anything you need to do is possible. For today I'd like to automate a simple case to show you: updating the list of users and running a test. This is something you might want to do as part of your continuous integration pipeline, and making sure the list of users is up to date is definitely a plus when it comes to avoiding/analyzing errors. You can find the swagger of our REST api in the documentation or directly here:

API documentation

  • in DevOps
  • 7 min read

Galera Cluster for Rancher

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:

  • in DevOps
  • 8 min read

MySQL Master - Master

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: