Pim Widdershoven

Database servers and clusters should be backed up regularly to prevent data loss when an error or disaster occurs. You can backup database servers logically using mysqldump, but you can also backup databases physically using Percona XtraBackup. XtraBackup enables you to run full and incremental backups, stream backups, compress and encrypt backups. TwinDB has simplified the usage of Xtrabackup and will automatically backup your Percona XtraDB cluster on an hourly basis.

In high-available production environments like a Software-as-a-Service Cloud environment, you have to minimize any kind of downtime as much as possible. In most cases, an application needs at least a database server. If this database server gets unavailable, the application won't function anymore. In this case, the database software is your most critical SPOF to resolve. Percona XtraDB cluster can help you to eliminate this SPOF by setting up a master-master HA cluster.

In Kubernetes it is possible to use Persistent Volumes to add persistent storage to your Docker containers. When creating a Persistent Volume (Claim) you have to configure a storage type and storage capacity. When your application gets successful and your storage exceeds the limits, you have to extend the volume or create a new persistent volume. The latter isn't a feasible solution in a production environment, but extending a persistent volume isn't supported out-of-the-box in Kubernetes. There is a solution though! Extending the volume outside Kubernetes!

Generating certificate signing requests (CSR), certificates and keys can be a hassle. CloudFlare introduced the CFSSL and CFSSLJSON tools to make this a lot easier for all of us!

The last few weeks I'm working with Kubernetes and OpenStack. It's a steep learning curve to get a production-ready Kubernetes Cluster running on OpenStack, especially because I didn't want to use the available ready-to-use tools. In the next few blog posts, I want to share my experience how to run Kubernetes on an OpenStack platform.

In this first blog post, I will discuss the infrastructure and how I use the OpenStack platform to run a production-ready Kubernetes cluster.

My continuous integration and continuous delivery pipeline use Docker containers and a private Docker registry to distribute and deploy my applications automatically. Unfortunately, the Docker command-line tool can't really control the Docker registry, actually, it is only capable of pushing and pulling image (tags). This is a bit frustrating because, when you're using your continuous integration pipeline to build containers, push them to the registry, and pull them again to run the QA, the registry will eat up all your disk space due the images are never removed. To clean up your "mess", you have to remove the images manually, but it's way cooler (and simpler) to use the Docker registry API for this job.